Jag bygger native, och jag säger till dig när cross-platform räcker.
En senior native-utvecklares raka bedömning av när Flutter eller React Native kostar dig och när en delad kodbas är rimlig, så att beslutet passar din produkt. Dagspris: 500 € eller 600 $.
Det vore enkelt att säga att native alltid vinner, men det är inte sant. Cross-platform-ramverk som Flutter och React Native är rimliga för många standardappar: formulär, listor, CRUD, innehåll som inte lutar sig mot plattformsspecifik media eller hårdvara. Sylvains intresse är att din produkt släpps väl, så rekommendationen bygger på vad du bygger snarare än på att sälja fler native-dagar.
Påfrestningen visar sig på specifika ställen: videouppspelning och DRM, där du slåss mot bron för att nå AVPlayer och ExoPlayer; tv-plattformar, där Flutter och React Native har svagt stöd; djup native API-åtkomst; appens binärstorlek; och felsökning som korsar JavaScript- eller Dart-bron in i native kod. Att hänga med i varje ny OS-release är också långsammare när du är beroende av ett ramverk för att exponera nya API:er. Om din produkt lever i dessa områden vinner native oftast på tid och kvalitet.
Om appen mest är skärmar med data, teamet redan kan React eller Dart, och det inte finns något tungt media-, hårdvaru- eller tv-krav, kan en delad kodbas verkligen spara pengar och släppas snabbare. Kompromissen är acceptabel när de svåra delarna av din produkt inte är de delar ett ramverk kämpar med. Sylvain säger det rakt ut när det är situationen, även om det inte är han som skulle bygga det.
Rätt val kommer från produkten, inte från en trend. Sylvain tittar på dina kärnfunktioner, ditt team, dina plattformsmål och din underhållshorisont, och ger sedan en rekommendation du kan agera på. När native är svaret bygger han det i Swift, SwiftUI och Kotlin. När det inte är det säger han till dig, så att du inte betalar för native där det inte tillför något.
Samma fasta dagspris på 500 € eller 600 $, remote. En ärlig bedömning är oftast ett litet antal dagar, och den kan spara dig långt mer än så genom att undvika fel arkitektur.
Ja. Jag granskar befintliga native- eller cross-platform-appar, säger vad som är friskt och inte, och kan ta över native iOS- eller Android-arbete. Jag läser koden innan jag bildar mig en uppfattning.
Ja. Om din produkt passar bra för Flutter eller React Native säger jag det, även om native är vad jag bygger. En felaktig rekommendation kostar dig mer än ett ärligt samtal.
Video, DRM, offline-nedladdningar och tv-plattformar lutar sig kraftigt mot plattformsspecifika API:er som AVPlayer, FairPlay och Apple TV-fokusmotorn. Att nå dem genom en cross-platform-bro är där det mesta av smärtan och kvalitetsförlusten visar sig.
Mitt praktiska byggande är native: Swift, SwiftUI och Kotlin. Jag förstår cross-platform-ramverken tillräckligt väl för att råda om avvägningen, men min leverans är native kod på varje plattform.
En beskrivning av dina kärnfunktioner, dina plattformsmål (iOS, Android, tv, webb), ditt teams befintliga kompetens, och hur länge du förväntar dig att underhålla appen. Med det kan jag ge en tydlig, produktbaserad rekommendation.
Skicka produktkontexten, målplattformen, repository-status och tidsplan. Jag säger snabbt om jag kan hjälpa.