Pourquoi nous construisons des applications iOS natives avec Swift plutôt que des frameworks multiplateformes
La tentation multiplateforme
Soyons clairs : nous aimons Flutter. Nous l'utilisons pour de nombreux projets clients où la portée multiplateforme prime sur les fonctionnalités spécifiques à la plateforme. React Native est solide aussi. Mais pour nos propres applications iOS alimentées par l'IA — celles qui exploitent CoreML, utilisent la caméra à 60 ips et doivent être indistinguibles des applications Apple — nous choisissons systématiquement Swift natif et SwiftUI.
Ce n'est pas une position idéologique. C'est une décision pratique basée sur la livraison de vrais produits et la mesure de ce qui compte : la performance, la rétention des utilisateurs, les évaluations sur l'App Store et la vélocité de développement.
L'écart de performance de CoreML est réel
Quand votre application exécute un pipeline ML faisant de la vision par ordinateur à 60 ips, les frais généraux du pont des frameworks multiplateformes deviennent un vrai goulot d'étranglement. L'intégration de CoreML en Swift n'a aucun surcoût — le modèle s'exécute sur le Neural Engine, les résultats reviennent sous forme de types Swift natifs, et l'interface utilisateur se met à jour dans la même image.
Nous avons comparé un modèle de détection d'objets YOLOv8 sur trois approches : Swift natif avec CoreML, Flutter avec un pont de canal de plateforme vers CoreML, et React Native avec un module natif. Les résultats étaient frappants :
Swift natif : 12 ms de temps d'inférence moyen. Pont Flutter : 28 ms (le pont ajoute ~16 ms de surcoût de sérialisation par image). React Native : 35 ms. À 30 ips d'entrée caméra, ce surcoût du pont consomme presque la moitié de votre budget d'images. À 60 ips, c'est impossible pour le multiplateforme.
Pour les applications où l'inférence IA se produit occasionnellement (un filtre photo, une fonction d'analyse de texte), ce surcoût est négligeable. Mais pour l'IA en temps réel — le traitement de caméra en direct, l'analyse continue des capteurs, la transcription audio en continu — Swift natif avec CoreML est la seule option qui offre une expérience fluide.
SwiftUI s'est transformé en une puissance de productivité
SwiftUI a considérablement mûri avec iOS 17 et 18. Les piles de navigation, les macros observables et les nouvelles API d'animation rivalisent avec tout ce qui existe dans le monde multiplateforme. Notre vitesse d'itération avec les aperçus SwiftUI est en fait plus rapide que le rechargement à chaud dans de nombreux cas, car les aperçus se rendent sans recompiler l'application entière.
La macro Observable dans Swift 5.9 a éliminé la plupart du code passe-partout qui rendait la gestion d'état SwiftUI pénible. Combinée au nouveau système de navigation, la création de flux multi-écrans complexes est maintenant simple et sûre au niveau des types. Nous passons moins de temps à combattre le framework et plus de temps à construire des fonctionnalités.
Pour les applications qui doivent se sentir natives — gestes iOS appropriés, retours haptiques, intégration Dynamic Island, Live Activities, widgets — SwiftUI vous les offre gratuitement. Les frameworks multiplateforme ne peuvent pas accéder à ces fonctionnalités ou nécessitent des implémentations de canaux de plateforme complexes qui éliminent les économies de temps.
L'avantage de l'App Store
Apple examine les applications et peut faire la différence. Les applications natives Swift bénéficient de processus d'examen plus fluides, d'un accès aux dernières API le premier jour et de meilleures opportunités de mise en avant. Apple promeut activement les applications qui présentent ses dernières fonctionnalités de plateforme — et vous ne pouvez pas utiliser ces fonctionnalités à partir de frameworks multiplateforme jusqu'à ce que quelqu'un construise un pont, ce qui prend souvent des mois.
Nos applications natives ont une note moyenne de l'App Store de 4,7 étoiles. Les avis positifs les plus courants mentionnent la vitesse et la façon dont l'application semble à sa place sur iOS. Cette sensation native est presque impossible à reproduire avec des frameworks multiplateforme, en particulier pour les animations, les transitions et les interactions gestuelles.
Quand la multiplateforme est le bon choix
Le cross-platform a du sens quand : votre application est principalement une interface CRUD soutenue par une API, vous avez besoin d'iOS et Android dès le premier jour avec un budget limité, vos fonctionnalités d'IA sont entièrement côté serveur, ou vous construisez un MVP pour valider un concept avant d'investir dans du natif. Nous utilisons Flutter exactement pour ces scénarios dans notre travail client.
Pour tout le reste — en particulier les applications avec du ML sur appareil, des pipelines de caméra personnalisés, l'intégration d'ARKit, ou l'intégration profonde du système d'exploitation comme HealthKit ou HomeKit — optez pour le natif. L'investissement initial se rentabilise en performance, satisfaction utilisateur et maintenabilité à long terme.
Notre recommandation
Si vous êtes une startup qui choisit entre natif et cross-platform, posez-vous une seule question : la proposition de valeur principale de votre application est-elle liée à une capacité spécifique à la plateforme ? Si la réponse est oui — et pour la plupart des applications d'IA c'est le cas — optez pour le natif. Si la réponse est non, Flutter ou React Native vous serviront bien et vous feront gagner du temps.
Chez iHux, nous sommes agnostiques face à la plateforme dans nos recommandations et spécifiques à la plateforme dans notre exécution. Nous vous dirons honnêtement quelle approche convient à votre produit, puis nous la construirons correctement.