Natif ou cross-platform : un avis honnête sur quand choisir quoi
Je construis en natif, et je vous dis quand le cross-platform suffit.
L'avis direct d'un développeur natif senior sur les cas où Flutter ou React Native vous coûtent cher et ceux où une codebase partagée est raisonnable, pour que le choix colle à votre produit. Tarif jour : €500.
Vendredi App · Bon de réparation
Nº ····
Dépôt
Votre journée, 9:00
Prêt
19:00
Vous récupérez
La correction qui tourne sur votre téléphone, et la modification dans votre code source.
Tarif jour remote
€500HT
Je construis des apps natives iOS, macOS, tvOS et Android depuis 2008 et je peux vous dire, par expérience, où le pont cross-platform tient et où il force.
Vous récupérez
- Une évaluation écrite du choix natif ou cross-platform pour votre produit précis
- Un détail des endroits où Flutter ou React Native vous coûteraient cher dans vos fonctionnalités
- Développement natif iOS (Swift, SwiftUI) et Android (Kotlin) quand le natif est le bon choix
- Une recommandation claire, y compris quand une codebase partagée est le choix raisonnable
Bon de réparation
Je construis en natif, alors voici la version honnête
Il serait facile de dire que le natif gagne toujours, mais c'est faux. Les frameworks cross-platform comme Flutter et React Native sont raisonnables pour beaucoup d'apps standard : formulaires, listes, CRUD, contenu qui ne dépend pas de média ou de matériel propres à une plateforme. Mon intérêt, c'est que votre produit sorte bien, donc la recommandation se base sur ce que vous construisez plutôt que sur la vente de jours de natif en plus.
Où le cross-platform vous coûte vraiment
La tension apparaît à des endroits précis. La lecture vidéo et le DRM, où vous bataillez contre le pont pour atteindre AVPlayer et ExoPlayer. Les plateformes TV, où Flutter et React Native ont un support faible. L'accès profond aux API natives, la taille du binaire, et le debug qui traverse le pont JavaScript ou Dart vers le code natif. Suivre chaque nouvelle version d'OS est aussi plus lent quand vous dépendez d'un framework pour exposer les nouvelles API. Si votre produit vit dans ces zones, le natif gagne d'habitude en temps et en qualité.
Où une codebase partagée est raisonnable
Si l'app est surtout des écrans de données, que l'équipe connaît déjà React ou Dart, et qu'il n'y a pas de média lourd, de matériel ni d'exigence TV, une codebase partagée peut vraiment faire économiser de l'argent et sortir plus vite. Le compromis est acceptable quand les parties difficiles de votre produit ne sont pas celles sur lesquelles un framework cale. Je le dis clairement quand c'est le cas, même si ce n'est pas moi qui la construirais.
Comment la décision devrait se prendre
Le bon choix vient du produit, pas d'une mode. Je regarde vos fonctionnalités centrales, votre équipe, vos plateformes cibles et votre horizon de maintenance, puis je donne une recommandation sur laquelle vous pouvez agir. Quand le natif est la réponse, je le construis en Swift, SwiftUI et Kotlin. Quand ce ne l'est pas, je vous le dis, pour que vous ne payiez pas du natif là où il n'apporte rien.
Questions fréquentes
Le même tarif jour fixe de €500, en remote. Une évaluation honnête tient en général en un petit nombre de jours, et elle peut vous faire économiser bien plus en évitant la mauvaise architecture.
Oui. Je relis les apps natives ou cross-platform existantes, je vous dis ce qui est sain et ce qui ne l'est pas, et je peux reprendre le travail natif iOS ou Android. Je lis le code avant de me faire une opinion.
Oui. Si votre produit est un bon candidat pour Flutter ou React Native, je vous le dis, même si c'est le natif que je construis. Une mauvaise recommandation vous coûte plus cher qu'une conversation honnête.
La vidéo, le DRM, les téléchargements hors ligne et les plateformes TV s'appuient fortement sur des API propres à la plateforme comme AVPlayer, FairPlay et le focus engine de l'Apple TV. Atteindre ces API à travers un pont cross-platform, c'est là que la plupart de la douleur et de la perte de qualité apparaît.
Ma construction concrète est native : Swift, SwiftUI et Kotlin. Je connais assez bien les frameworks cross-platform pour conseiller sur le compromis, mais ma livraison est du code natif sur chaque plateforme.
Une description de vos fonctionnalités centrales, vos plateformes cibles (iOS, Android, TV, web), les compétences actuelles de votre équipe, et la durée pendant laquelle vous comptez maintenir l'app. Avec ça, je peux donner une recommandation claire, fondée sur le produit.
Besoin d’aide mobile native senior ?
Envoyez le contexte produit, la plateforme cible, l’état du dépôt et le calendrier. Je vous dirai rapidement si je peux aider.
Réserver un appel gratuit de 20 minOu laissez un mot au comptoir
Décrivez votre projet. Je réponds tout de suite par chat si je suis disponible, sous 24 h sinon.