Hvis din app begyndte i FlutterFlow, React eller Flutter, og du nu vil have SwiftUI på iOS eller Jetpack Compose på Android, er det første spørgsmål ikke, hvilket sprog du skal omskrive alt i. Spørgsmålet er, om en omskrivning løser et reelt produkt- eller vedligeholdelsesproblem.
Find først ud af, hvad du har
React til web viser en brugerflade i browseren. React Native er et separat mobilframework med egne UI-komponenter. Noget forretningslogik og API-arbejde kan måske genbruges, men webskærme bliver ikke til SwiftUI eller Compose. Fastslå den nuværende stack, før du beder om et estimat.
FlutterFlow eksporterer et Flutter-projekt som kildekode. Dokumentation om FlutterFlow-eksport.
Betragt eksporten som et udgangspunkt i Flutter. Planlæg og afgræns arbejdet med at nå frem til native Swift- og Kotlin-apps; gå ikke ud fra, at det kan konverteres med ét klik.
Flutter kompilerer Dart til native maskinkode på mobilen, men renderer brugerfladen gennem sit eget framework. Flutters arkitektur.
En Flutter-app kan altså kompileres til mobil uden at skærmene består af native SwiftUI- eller Compose-elementer. Hvis platformens udseende, tilgængelighedsadfærd eller systemintegration er grunden til skiftet, så undersøg, om netop det behov retfærdiggør ændringen.
Vælg den mindste vej, der løser problemet
- Behold den nuværende app, hvis den opfylder produktets, kvalitetens og supportens behov. Bekræft, at du har kildekoden, adgang til builds og en tydeligt ansvarlig, før du ændrer noget.
- Undersøg og refaktorér, hvis appen fungerer, men har konkrete problemer som svær vedligeholdelse af genereret kode, langsomme releases eller dyre afhængigheder. Ret de dele, der skaber problemerne.
- Tilføj en native-bro til en afgrænset funktion, der kræver platformens API'er. Flutter-platformkanaler lader Dart kommunikere med Swift- eller Kotlin-kode. Dokumentation om platformkanaler.
- Planlæg en native-omskrivning kun hvis kerneoplevelsen kræver native brugerflade eller adfærd i så mange flows, at målrettede ændringer ikke længere giver mening. Sammenlign omfanget med omkostningen og risikoen ved at beholde appen.
- Opfylder den nuværende app behovene? Behold og vedligehold
- Konkrete mangler? Undersøg og refaktorér
- Én platformfunktion? Tilføj en native-bro
- Kræver kerneflows native UI? Planlæg en trinvis omskrivning
Gå kun videre, når grundlaget viser, at det forrige valg ikke løser problemet.
Kortlæg, hvad der skal bevares
Lav en oversigt over det, brugere og forretningen allerede er afhængige af, før du vælger skærme, der skal bygges om: konti og login, backendregler, køb og gendannelse, butikssider og app-id'er, gemte data, dybe links, pushbeskeder, analyse og samtykke, tilladelser samt links til privatliv og support. Udpeg en ansvarlig for hvert punkt.
Medtag den nuværende butiksidentitet og signering i migrationsplanen, og afstem dem med kontoejeren. Notér, hvilke data der ligger på serveren, og om lokale data skal flyttes. Behold købsprodukter, validering af kvitteringer eller transaktioner, kontoadgang og gendannelse i scope; en ny brugerflade må ikke lydløst ødelægge dem.
Migrér i faser omkring reelle brugerflows
- Fastlæg udgangspunktet. Skriv appens kritiske flows, kendte fejl, understøttede enheder og releaseproces ned. Notér, hvem der ejer hvert system og hver konto.
- Aftal kriterier for paritet. Vælg de første flows, for eksempel login, hovedopgaven, køb og gendannelse samt dybe links. Definér, hvad der skal fungere på iOS og Android, før I går videre.
- Byg ét komplet flow. Implementér et værdifuldt flow fra start til slut i SwiftUI og Compose, inklusive backendkald og platformintegrationer. Sammenlign resultatet med de aftalte kriterier, før scope udvides.
- Udgiv med en ansvarlig. Planlæg kvalitetstjek, indsendelse til butikkerne, overvågning og gendannelse. Overdrag kodearkiver, adgang til signering og konti, byggevejledninger, driftsnoter og en navngiven ansvarlig for fremtidige releases.
Få et tilbud på et defineret scope
Et brugbart tilbud starter med en gennemgang af appen og et skriftligt omfang. Mangler der dokumentation, aftales først omfang og pris for en teknisk vurdering. En fuld betalt gennemgang er ikke altid nødvendig. Beskriv flows, platforme, integrationer, dataarbejde, test, udgivelse, overdragelse og undtagelser.
En omskrivning er ikke automatisk en forbedring. Hvis appen er stabil, og hovedproblemet er én integration eller en flaskehals ved releases, kan en målrettet refaktorering eller bro være nok. Sammenlign mulighederne i native kontra Flutter, React-udvikling og Flutter-udvikling.
Vil du tale om næste skridt? Send links til App Store og Google Play, din nuværende stack og den konkrete blokering via native appudvikling eller appmodernisering. Vi kan tage udgangspunkt i det scope, du faktisk har.