Ionic eller React Native?

Ionic og React Native blir ofte trukket frem som konkurrenter, men de bygger på en grunnleggende forskjell som mange kunder overser, og som avgjør hvordan appen føles i hånden. Den ene pakker en nettside inn i et appskall; den andre tegner ekte native-komponenter. Forstår du den forskjellen, blir valget enkelt. Her er sammenligningen sett fra kundens side.

Den prinsipielle forskjellen: webview mot native

Ionic bygger appen din som en webapplikasjon (HTML, CSS og JavaScript) som kjører inne i en webview, en innebygd nettleser pakket som en app. I praksis er det en nettside i appinnpakning, og den distribueres via appbutikkene.

React Native gjør noe helt annet. Koden din styrer plattformens ekte native-komponenter, så en knapp er en ordentlig iOS- eller Android-knapp, ikke en HTML-knapp som ser ut som en. Alt annet, altså ytelse, følelse og hvor nær plattformen appen ligger, følger av denne forskjellen.

Hva forskjellen betyr for ytelse og følelse

For en innholdsdrevet app (nyheter, en enkel kundeportal, et internt skjemaverktøy) er forskjellen i praksis liten. En Ionic-app strekker fint til, og brukeren tenker ikke på hvordan den er bygd.

Jo mer interaktiv appen blir, desto mer merkes webviewen. Ved tung scrolling i lange lister, komplekse animasjoner eller raske gester kan en Ionic-app føles litt mindre flytende fordi alt rendres gjennom nettleserlaget. React Native ligger nærmere maskinvaren og arver plattformens naturlige følelse. Er appen kjerneproduktet ditt overfor krevende forbrukere, er den forskjellen ikke kosmetisk: Den påvirker hvor profesjonell appen oppleves.

Når Ionic er fornuftig

Ionic er ikke et snarveisvalg man skal skamme seg over; i riktig situasjon er det klokt. To situasjoner skiller seg ut:

• Eksisterende webkodebase og webkompetanse. Har dere allerede et webteam og en kodebase i React, Angular eller Vue, lar Ionic dere gjenbruke mye av den og levere en app raskt uten å bygge opp ny kompetanse.
• Interne verktøy. For en app som de ansatte skal bruke, der utseendet og de siste små ytelsesgevinstene ikke avgjør noe, er Ionic ofte den raskeste og billigste veien til appbutikkene.

Fellesnevneren: Ionic kommer til sin rett når gjenbruk og tempo veier tyngre enn maksimal følelse.

Et konkret scenario

Si at dere har en nettbasert tjeneste bygd i React og vil gi de ansatte en app for feltarbeid. Med Ionic kan det eksisterende webteamet deres pakke store deler av koden som allerede finnes, og ha en fungerende app i appbutikkene på kort tid. Her er Ionic fornuftig: Målgruppen er intern, kravene til polert følelse er lave, og gjenbruken er stor.

Anta i stedet at den samme tjenesten skal bli en forbrukerapp som er selve produktet, med mye interaksjon og høye forventninger til flyt. Da heller valget mot React Native fordi følelsen og ytelsen blir en del av det dere tilbyr. Velger dere likevel Ionic først og merker at appen ikke strekker til, blir neste steg en omskriving av grensesnittet: Logikken kan bli med, men UI-et bygges om.

Migreringsveier hvis du vokser ut av Ionic

Det er fullt mulig å gå fra Ionic til React Native, men vær ærlig om hva det innebærer: en omskriving av UI-laget, ikke et knappetrykk. Forretningslogikk og backend kan som regel gjenbrukes, mens selve grensesnittet bygges om fordi teknologiene rendrer helt forskjellig.

Konklusjonen for deg som kunde er å tenke et par år frem allerede når du velger. Skal appen være et internt verktøy eller en rask gjenbruk av weben, er Ionic ofte riktig. Skal den bli et langlivet, krevende forbrukerprodukt, lønner det seg å starte i React Native med en gang. Vil du sparre med oss om hva som passer dere, kan du se på tjenestene våre eller ta kontakt.