Flutter eller nativ utveckling?

Flutter lovar samma sak som all cross-platform-teknik: en kodbas för både iOS och Android i stället för två. Men Flutter håller löftet på sitt eget sätt – med språket Dart och en egen renderingsmotor som ritar varje pixel själv. Båda valen har konsekvenser som en beställare bör förstå innan tekniken låses.

Flutters egen renderingsmotor – styrkan och priset

Nativa appar, och även React Native, bygger gränssnittet av plattformens egna komponenter. Flutter gör tvärtom: ramverket ritar hela gränssnittet med sin egen motor, ovanpå en tunn plattformsyta.

Styrkan är konsekvens. Appen ser identisk ut på en gammal Android-telefon och en ny iPhone, designsystemet återges exakt som formgivaren tänkt och animationer flyter fint. För varumärkesdrivna appar med eget formspråk är det ett genuint argument.

Priset är plattformskänslan. En iPhone-användare märker – ofta omedvetet – när rullningsfysik, övergångar och kontroller inte beter sig exakt som resten av telefonen. Flutter kan efterlikna plattformarnas beteenden, men det är just en efterlikning som ska byggas och underhållas, inte något appen får gratis. Ju viktigare det är att appen känns som en del av operativsystemet, desto mer väger den här punkten.

En praktisk följdeffekt är releasetakten: med en gemensam kodbas släpps iOS- och Android-versionerna i takt, byggda av samma team mot samma backlog. Med två nativa spår krävs aktiv samordning för att butikerna inte ska glida isär – ett arbete som sällan syns i offerten men alltid i förvaltningen.

Dart och kompetensfrågan på svensk marknad

Nativ utveckling sker i Kotlin och Swift – två språk som bär hela Android- respektive iOS-ekosystemet och därmed en stor, stabil kompetensbas i Sverige. Dart används i praktiken bara till Flutter.

För ett enskilt projekt spelar det liten roll; en erfaren byrå eller ett inhyrt team löser bygget. Frågan är vad som händer år två till tio. Appen ska förvaltas, vidareutvecklas och ibland byta händer. Då blir språkvalet en försörjningsfråga: hur snabbt hittar ni en ersättare när Flutter-utvecklaren slutar, och till vilket pris? Poolen av Dart-utvecklare växer, men den är fortfarande betydligt mindre än för Kotlin, Swift eller JavaScript. Det gör inte Flutter till fel val – men det gör kompetensplanen till en obligatorisk del av beslutet, inte en fotnot. Konkret: be leverantören redogöra för hur förvaltningen bemannas år tre, inte bara vem som bygger år ett, och räkna med en viss prispremie för smal spetskompetens om appen ska drivas vidare internt.

När nativt fortfarande är värt dubbla team

Det finns lägen där två nativa kodbaser motiverar sin dubbla kostnad:

• Appen är er huvudprodukt och ska kännas perfekt hemma på varje plattform, i varje detalj.
• Hårdvarunära kärnfunktioner – avancerad Bluetooth, bakgrundstjänster, AR eller specialkringutrustning – där plattformarnas egna API:er ger kortast väg och stabilast drift.
• Extrema prestandakrav som realtidsljud eller tung videobearbetning.
• Organisationen har redan etablerade iOS- och Android-team som levererar väl – då är omställningskostnaden ett eget projekt.

Utanför de här situationerna är det svårt att ekonomiskt försvara två parallella kodbaser: varje funktion byggs, testas och underhålls dubbelt, år efter år.

Ett konkret scenario

Tänk er en eventapp: program, biljetter, kartor, notiser. Byggd nativt krävs två utvecklingsspår som var för sig implementerar samma tio skärmar – kanske 1,2–1,8 miljoner kronor totalt. Med Flutter byggs skärmarna en gång, med gemensam logik och design, till en klart lägre totalkostnad och med samtidiga releaser i båda butikerna.

Vänd sedan på scenariot: en app vars kärna är att styra egen hårdvara via Bluetooth i bakgrunden, med krav på perfekt plattformsintegration. Där kan de nativa API:erna vara halva produkten – och dubbla team en rimlig försäkringspremie.

Beslutskriterier i korthet

Väg tre saker: hur central plattformskänslan är för er produkt, hur hårdvarunära kärnfunktionerna är och hur ni ska bemanna appen de kommande fem åren. Två av tre mot Flutter talar för nativt – annars är en gemensam kodbas oftast rätt utgångspunkt, i Flutter eller i React Native, som är vår huvudstack på Weapp. Osäker på var din app landar? Hör av dig så resonerar vi kring just ert läge.