Plattformuavhengig utvikling av mobilapper

Vi utvikler apper for iOS og Android fra én React Native-kodebase: ett team, én backend, lansering i begge appbutikkene samtidig. Er produktet bedre tjent med native, sier vi det før estimatet.

Når én kodebase er riktig svar

Plattformuavhengig utvikling fungerer når appen dreier seg om innhold og forespørsler til en server. Den fungerer dårlig når produktet lever av tung grafikk, konstant bakgrunnsprosessering eller helt nye plattformfunksjoner.

Dere trenger en MVP på både iOS og Android og vil teste markedet før dere betaler for to native apper
Appen er bygd rundt feeder, kataloger, skjemaer, bestillinger, profiler og meldinger
Nye funksjoner må nå brukere på iPhone og Android samme dag
Budsjettet dekker ett utviklingsteam, ikke to
Webplattformen deres trenger en tilhørende app med de samme kontoene og dataene
Dere har en React Native-app fra et annet team som må ferdigstilles eller oppdateres

Hva som inngår

Vurdering av plattform

Før estimatet går vi gjennom funksjonene og forteller om React Native passer. Trenger en kritisk del native kode, viser vi hvor den er og hvor mye av appen den påvirker.

Design for begge plattformer

Ett design tilpasset konvensjonene i iOS og Android: navigasjon, bevegelser, systemdialoger, tilbake-knapp. Ikke et iPhone-design som er strukket over Android.

Utvikling i React Native

Felles kode for skjermbilder, forretningslogikk og serverforespørsler. Arbeidet går i sprinter, og hver sprint avsluttes med en versjon for begge plattformer som dere kan installere og prøve.

Native moduler

Der felles kode ikke strekker til, for eksempel ved en leverandørs SDK, en maskinvarefunksjon eller bakgrunnsarbeid, skriver vi native moduler i Swift og Kotlin og kobler dem til appen.

Én backend for begge appene

API, database, administrasjonspanel og push-varsler bygges én gang og brukes av begge appene, og av en webversjon om dere trenger det. Python eller PHP (Laravel), valgt ut fra oppgaven.

Testing, publisering og oppdateringer

Testing på ekte iPhoner og Android-telefoner, publisering i App Store og Google Play og oppdateringer etter lansering, inkludert oppgradering av React Native og bibliotekene.

Hvor plattformuavhengig fungerer, og hvor det ikke gjør det

Én kodebase for iOS og Android koster som regel merkbart mindre enn to native apper og tar kortere tid, fordi det meste av koden, designet og testingen er felles. Avveiningen fungerer når appen viser innhold, lister og skjemaer og kommuniserer med en server. Den fungerer dårlig når produktet er avhengig av animasjonstunge grensesnitt, kamerabaserte funksjoner, lang bakgrunnsprosessering eller plattform-API-er som kommer til native SDK-er først. Vi forteller dere hvilken av de to typene produktet deres er før estimatet, ikke etter første lansering.

Passer godt: innholdsapper, kataloger, markedsplasser, booking- og tjenesteapper
Passer godt: MVP-er som må være i begge appbutikkene fra første dag
Bedre native: tung grafikk og animasjon, kamerabaserte funksjoner
Bedre native: konstant bakgrunnsarbeid og de nyeste plattform-API-ene

Ett team, én backend, én lanseringsplan

Med to native apper har dere to kodebaser, to sett med feil og ofte to lanseringsdatoer. Med React Native skrives en funksjon én gang og publiseres i begge appbutikkene samtidig, og de samme folkene har ansvaret for begge plattformene. Serverdelen er også felles: ett API og ett administrasjonspanel betjener begge appene og ved behov en webklient. Metacognit.me, en app for metakognitiv korreksjon og psykotypediagnostikk, er bygd nettopp slik: en React Native-klient for iOS og Android og en backend i Python.

Klar for overgang til native, hvis det en dag blir aktuelt

Å starte plattformuavhengig binder dere ikke. Backenden og API-et overlever en overgang til native; klientkoden gjør det ikke. Derfor utformer vi API-et slik at en fremtidig native klient eller webklient kan bruke det uendret, og holder plattformspesifikke deler isolert i native moduler. Vi har gjennomført migreringer begge veier. For Quaker, en matlagingsapp for et matleveringsselskap i Dubai, erstattet vi en hybridapp på utdatert teknologi med to native klienter da forskjellene mellom plattformene begynte å bety noe for produktet.

Et API utformet for å betjene enhver fremtidig klient, native eller web
Plattformspesifikk kode isolert i native moduler
Et ærlig signal når appen vokser ut av den felles kodebasen
Kontoer og data som følger produktet, uansett hva klienten er skrevet i

Slik gjennomføres et plattformuavhengig prosjekt

Vurdering og estimat

Vi går gjennom funksjoner og integrasjoner og sjekker hva som krever native kode. Dere får et skriftlig omfang, en anbefaling om React Native eller native og et estimat.

Design

Prototype og ferdig brukergrensesnitt tilpasset begge plattformer. Dere godkjenner skjermbildene for iOS og Android før utviklingen.

Utvikling

Felles kode først, native moduler der det trengs, backend parallelt. Etter hver sprint installerer dere nye versjoner på begge plattformer.

Testing på enheter

Testing på ekte iPhoner og Android-telefoner med ulike skjermer og OS-versjoner. Dere får én testet versjon for begge appbutikkene.

Publisering og drift

Publisering i App Store og Google Play under deres kontoer, deretter oppdateringer, feilrettinger og oppgraderinger av rammeverket så lenge dere trenger det.

Teknologier

Plattformuavhengig

Native moduler

Backend og API

Slik kan vi samarbeide

Fast omfang

En avtalt funksjonsliste, et estimat og en tidsplan for begge plattformer. Et vanlig valg for en MVP som skal lanseres i begge appbutikkene.

Dedikert team

Ett plattformuavhengig team som jobber kontinuerlig med appen deres. Passer for produkter som lanserer ofte og planlegger veikartet sprint for sprint.

Timebasert

Betaling for timene som faktisk brukes. Passer for gjennomgang av en eksisterende React Native-app, oppgradering av rammeverket og mindre funksjoner.

Relaterte prosjekter

Metacognit.mePython, React.Native QuakerKotlin, SWIFT, PHP, Laravel

Tilbakemeldinger

Vi behandler hver kunde og prosjektet deres med omtanke.

Revol-teamet fortsetter å effektivisere kundens utviklingskapasitet med arbeid av høy kvalitet og pålitelig support. De kommuniserer godt og viser en solid forståelse av kundens behov og virksomhet.

Tomas

Daglig leder (Yukon, Canada)

Arbeidet fra Revol har fullt ut innfridd forventningene, og kunden er fornøyd. Den friske tilnærmingen og evnen til å være tilgjengelige for support har vært verdifulle. Kunder kan trygt velge dem som et kommunikativt og kundeorientert team som hjelper dem å nå målene sine.

Andrey

Daglig leder, Stellium (USA)

Ofte stilte spørsmål

Vil brukerne merke at appen ikke er native?

I de tilfellene der plattformuavhengig utvikling passer: nei. Der de ville merket det, for eksempel ved animasjonstunge grensesnitt, kamerabaserte funksjoner eller lang bakgrunnsprosessering, anbefaler vi native utvikling i stedet for å love at den felles koden skal klare det.

Hvor mye rimeligere er plattformuavhengig enn to native apper?

Som regel merkbart rimeligere og raskere, fordi det meste av koden, designet og testingen er felles. Den nøyaktige forskjellen avhenger av hvor mange plattformspesifikke funksjoner appen trenger. Vi gir konkrete tall i estimatet for appen deres i stedet for en generell prosentsats.

Kan vi starte plattformuavhengig og gå over til native senere?

Ja, og vi har gjennomført slike migreringer begge veier. Det lønner seg å planlegge tidlig, fordi backenden og API-et overlever overgangen, mens klientkoden ikke gjør det.

Publiserer dere appene i appbutikkene?

Ja. Vi klargjør versjoner, butikksider og metadata, går gjennom vurderingen i App Store og Google Play og håndterer rettelsene som kontrollørene ber om. Appene publiseres under deres egne utviklerkontoer.

Hvordan beregnes prisen?

Vi deler appen opp i funksjoner, estimerer hver av dem i timer og legger til design, backend, testing og publisering. Deretter kan dere velge fast omfang, dedikert team eller timebasert arbeid. Vi publiserer ikke priser, fordi innsatsen varierer for mye fra app til app.

Kan dere ta over en eksisterende React Native-app?

Som regel ja. Vi starter med en gjennomgang av koden: versjoner av React Native og biblioteker, native moduler, byggeprosessen. Dere får et klart bilde av appens tilstand og hva de første månedene vil innebære, også om det trengs en oppgradering eller en delvis omskriving.