Cross-Platform vs. alkuperäiset mobiilisovellukset

(Jacob Muchow ) (15. lokakuuta 2020)

Suunnittelija

Johdanto

Alustojenvälisistä sovelluksista on tullut markkinoille menevä ratkaisu monille teknologia-alan startup-yrityksille. He lupaavat pystyvänsä kirjoittamaan helposti yhden koodipohjan, joka toimii sekä iOS- että Android-laitteissa. Monet yritykset kuitenkin valitsevat edelleen perinteisen reitin ja kehittyvät luonnollisesti mahdollisista eduista huolimatta.

Molemmat ratkaisut ovat kelvollisia – ei ole olemassa yhtä ”oikeaa” tapaa tehdä asioita (ainakaan vielä! ). Oikean tien valitseminen tiimillesi riippuu tavoitteistasi ja rajoituksistasi, ja tekniikan valinnan tulisi perustua enemmän kuin henkilökohtaiseen vakaumukseen. Tässä viestissä vertaillaan kahta vaihtoehtoa, jotka auttavat sinua tekemään parhaan päätöksen yrityksellesi.

Cross-Platform

Tällä hetkellä on olemassa useita kilpailevia vaihtoehtoja alustojen väliseen kehittämiseen : React Native, Flutter, Xamarin, Ionic mainitsemaan valtavirrat. Tässä viestissä aiomme välttää jokaisen selittämistä ja keskustella koko alustan välisen kehityksen eduista / haitoista.

Jokainen näistä alustoista antaa tiimillesi mahdollisuuden kirjoittaa yhden sovelluksen koodi, joka voidaan ottaa käyttöön sekä Google Play Kaupassa että App Storessa. Tämän kustannussäästömahdollisuudet ovat tietysti valtavat, jos ne toteutetaan tehokkaasti.

Ammattilaiset yli alustan

  • Molemmille matkaviestinmarkkinoille on mahdollista toimittaa paljon pienemmällä budjetilla kuin kahden kehittäisi kaksi erillistä natiivisovellusta. Noin 60–70\% koodista voidaan jakaa loppuosan kanssa kummallekin alustalle.
  • Sinulla voi olla yksi mobiilikehitystiimi, joka yksinkertaistaa organisaatiotasi. Tästä voi olla hyötyä myös siinä, että saat Android- ja iOS-sovelluksiisi koherenssia, jota on vaikea saavuttaa muuten.
  • Valitusta tekniikasta riippuen talossa voi olla kehittäjiä, jotka tuntevat jo kielet ja kehitystyylit. (JavaScript, C # /. NET, Dart). Voit pystyä rakentamaan tiimin tarvitsematta aloittaa palkkaamista alusta alkaen.
  • Uudet ominaisuudet otetaan käyttöön iOS- ja Android-käyttäjillesi samanaikaisesti sen sijaan, että heillä olisi ”ominaisuusjohtaja”.

Haitat eri alustoille

  • Tässä tekniikassa kokeneiden kehittäjien palkkaaminen on paljon vaikeampaa kuin alkuperäisillä.
  • Kun teet osui tiesulkuun, ongelman ratkaisemiseen tarvitaan usein todella ammattitaitoista insinööriä.
  • iOS- tai Android-erityisominaisuuksien (esim. Health Kit / Apple Watch) kanssa työskenteleminen on erittäin vaikeaa tai mahdotonta.
  • Monimutkaisen käyttöliittymän / käyttöliittymän kehittäminen vie paljon kauemmin kuin Native. Jos ei ole valmiita komponentteja, molemmille alustoille on luotava mukautettu komponentti, joka vie aikaa.
  • Alustojen välinen käyttö ei ole usein yhtä tehokasta kuin Native, mikä toisinaan aiheuttaa jotkut jankit, joita ei oikeastaan ​​voida ratkaista. Tällä on enemmän vaikutusta sovelluksen monimutkaisempaan suuntaan.
  • Teknologioilla on vähemmän kypsät ekosysteemit kuin alkuperäisillä. Tämä tarkoittaa vähemmän työkaluja, joita tiimisi voi käyttää, ja vähemmän apua, kun he kohtaavat ongelmia.
  • Sovellukset eivät ”tunnu” iOS- tai Android-sovelluksilta. Ne luovat käyttäjälle tuntemattomia kokemuksia, jotka voivat tehdä sovelluksesta tunteen houkuttelevalta.
  • On olemassa vaara, että valittu tekniikka kuolee pois ja menettää yhteisön, sisällöntuottajan tai yrityksen tuen.

Kun on järkevää käyttää alustojen välistä käyttöä

  • Haluat kohdistaa sekä Android- että iOS-markkinoihin MVP: lle.
  • Rajoitettu mobiilibudjetti on yksi tärkeimmistä rajoitukset.
  • Mobiilisovelluksesi ei ole liiketoimintasi ydin.
  • Käyttökokemuksen tulisi olla vakio sovellustesi välillä, etkä halua ”tuntea” kuin iOS tai Android. sovellus.
  • Sovelluksesi on suoraviivainen käyttökokemuksen ja ominaisuuksien suhteen.
  • Suunnittelusi ovat lähes identtisiä molemmilla alustoilla.

Ajatuksemme

Alustojen väliset tekniikat ovat erinomainen tapa päästä nopeasti markkinoille mahdollisimman laajalle yleisölle ja vahvistaa ideasi. Jos sovelluksesi ei vaadi alustakohtaisia ​​tekniikoita, monimutkaista käyttöliittymää / monimutkaista liiketoimintalogiikkaa, sinun kannattaa harkita monialaisen ratkaisun käyttöä. MVP: n jälkeen tämä voi antaa sinun keskittyä kokonaan tuotteen iterointiin, kun taas natiiviksi tuleminen voi tarkoittaa, että sinun on harkittava täysin uuden tiimin / sovelluksen rakentamista iOS: lle tai Androidille. Native voi tulla aina myöhemmin tarvittaessa.

Native Development

”Native” -kehitys viittaa perinteiseen tyyliin kehittää koko sovellus käyttämällä Applen ja Googlen toimittamia ensimmäisen osapuolen työkaluja iOS: lle ja Android.Ekosysteemit ovat kehittyneet, mutta nykyään alan standardina on käyttää Android Studiota & Kotlinin ohjelmointikieli Androidille ja Xcode & Nopea ohjelmointikieli iOS: lle.

Tämä lähestymistapa edellyttää, että kullekin sovellukselle on kaksi erillistä kooditukea. Joukkueilla insinöörit keskittyvät yleensä yhteen tai toiseen alustaan, tai joskus niillä on kaksi täysin erillistä kehitystiimiä kullekin alustalle.

Yritykset julkaisevat usein sovelluksensa ensin joko App Storeen tai Google Playhin. keskittyä tuotteen iterointiin. Jos sovelluksen toimittaminen toisella alustalla on osa heidän strategiaansa, kun heillä on veto tai menestys ja riittävä rahoitus, he investoivat tiimin rakentamiseen toisen alustan hoitamiseksi.

Hyödyt alkuperäiseen kehitykseen

  • Sovellukset voivat hyödyntää kaikkia iOS- tai Android-erityisominaisuuksia.
  • Käyttäjäkokemus voidaan räätälöidä enemmän tai vähemmän siinä määrin kuin iOS- tai Android-käyttäjä odottaa.
  • Mukautettua, monimutkaista käyttöliittymää on paljon helpompi kehittää yleensä.
  • Jos taustalla on monimutkainen käsittely, se toimii teknisten rajoitusten vuoksi sujuvammin kuin alustojen välinen.
  • Natiivisovellukset pärjäsivät hyvin ”tuntevat olonsa paremmaksi” tavalla, johon monitasoiset sovellukset eivät tällä hetkellä kykene.
  • Seuraavan tiimisi pitäisi pystyä saamaan kiinni ensimmäisestä tiimistäsi melko nopeasti. Heidän ei tarvitse käydä läpi samoja virheitä ja oppimisia kuin ensimmäinen tiimi.
  • Työmarkkinoilla on paljon enemmän kehittäjiä, jotka ovat kokeneet iOS- tai Android-kehityksessä. Palkkaaminen on paljon yksinkertaisempaa.
  • Työkaluja ja yhteisön tukea on kehitetty mobiilisovellusten perustamisesta lähtien, ja ne ovat paljon vankempia ja kypsempiä.
  • Jos voit kuvitella sen, se voidaan usein tehdä 99\% ajasta.

Natiivin kehityksen haitat

  • Natiivisovellusten rahoittaminen voi olla hyvin kallista sekä iOS- että Android-laitteille .
  • Tarvitset lähinnä kahden kehittäjän arvoisen joukkueen, jotta molemmat voisivat toimittaa ne.
  • Seuraava foorumi on usein jäljessä ominaisuuksien suhteen, ja pariteetin saavuttaminen voi olla vaikeaa.
  • Yhteenkuuluvuuden saavuttaminen iOS- ja Android-sovellusten ja -tiimien välillä on haastavaa.

Kun on järkevää siirtyä kotimaahan

  • perusteellisesti hienosäädetystä, laadukkaasta tai vaikuttavasta käyttökokemuksesta.
  • Haluat hyödyntää alustan ominaisuuksia (esim. Health Kit / Apple Watch -integraatio).
  • Sinulla on mielessä laskennallisesti intensiiviset ominaisuudet, kuten video tai suoratoisto.
  • Se ei ole hei On erittäin tärkeää, että toimit aluksi mahdollisimman laajalle yleisölle.
  • Kohdistat tiettyyn väestörakenteeseen, jolla on taipumus käyttää yhtä tai toista alustaa.
  • Kun suunnittelusi hyödyntävät voimakkaasti natiivikomponentteja ja tyylit.

Ajatuksemme

Jos haluat toimittaa erittäin laadukkaan sovelluksen, joka tuntuu luonnollisimmalta tai tyydyttää käyttäjää, tai sinun on integroitava läheisten natiivien sovellusliittymien ja ominaisuuksien kanssa kummallekin alustalle, natiivi on oikea tapa edetä. Vaikka ennakoit tämän tulevaisuudessa, sinun kannattaa harkita kotimaista tekemistä. Kun kaikki menee sujuvasti, kahden natiivisovelluksen kehittäminen on paljon kalliimpaa. Jos törmäät esteeseen sen suhteen, mitä ominaisuuksia voit luoda, ne ovat usein ratkaistavissa alkuperäisissä versioissa, kun taas alustojen välinen yhteys saattaa jättää sinut repimään hiuksiasi.

Päätelmä

QuarkWorksilla on kokemusta useiden alustojen välisten tekniikoiden kehittämisestä sekä laaja tausta alkuperäiskehityksessä App Storen perustamisesta lähtien.

Ei ole olemassa ”yhtä todellista tapaa”, kun kyse on mobiilisovellusten kehittäminen. Kevyiden prototyyppien ja MVP: n kehittämiseksi pidämme ajatusta käyttää monitasoista alustaa aina, kun se on mahdollista, jotta ideomme saadaan nopeasti laajimman yleisön käsiin. Kuitenkin, kun haluamme luoda jotain täydellisyyttä ja todella tarjota korkealaatuisen käyttökokemuksen, suosimme silti mennä natiivikehityksen kanssa.

Arvostamme sovelluksia, jotka vain ”tuntevat” hyvää eikä ole mitään keinoa. luoda tämä tunne aivan samalla tavalla nykyisen alustojen välisen tekniikan kanssa. Olemme innoissamme joistakin uusista ratkaisuista, kuten Flutter, joiden tarkoituksena on tarjota paitsi yksi kooditieto mobiililaitteille, myös mahdollisuus jakaa koodi matkapuhelimen ja verkon välillä. Se tekee kaiken tämän samalla tehokkaana kuin alkuperäiset sovellukset. Vaikka se ei ole täydellinen, näemme, että metaforisena Pyhänä Graalina, jonka teollisuus voisi jonain päivänä saavuttaa.

Tällä hetkellä monet näistä tekniikoista ovat lupaavia, mutta eivät täytä tapoja, joista voi tulla todella turhauttavaa. työn läpi.

Kuten aina, QuarkWorks on käytettävissä kaikissa ohjelmistosovelluksissa – verkko, mobiili ja paljon muuta! Jos olet kiinnostunut palveluistamme, voit tutustua -sivustoomme .Haluaisimme vastata kaikkiin kysymyksiisi! Ota vain yhteyttä meihin Twitterissä , Facebookissa , LinkedIn tai Instagram .

QuarkWorks – Koti

Puhdas, hyvin dokumentoitu ja testattu koodi on jokaisen onnistuneen projektin perusta. Teemme tiivistä yhteistyötä sinun…

quarkworks.co