Le développement multiplateforme vous permet de créer une application mobile qui fonctionnera simultanément sous iOS et Android. Il s'agit d'une alternative peu coûteuse à la création d'une application pour chaque système d'exploitation séparément.

Caractéristiques du développement multiplateforme

Développer une application pour différentes plates-formes est à la fois une bonne et une mauvaise chose. Bien, car cela peut être fait plus rapidement et à moindre coût que plusieurs applications pour chaque système d'exploitation. Et c'est mauvais, car le compromis affecte le fonctionnement de l'application.

Ces caractéristiques doivent être prises en compte avant de démarrer le projet :

• Dans un environnement multiplateforme, le code est écrit une seule fois. Pour faire fonctionner l'application sur un autre système d'exploitation, le code est traduit dans un autre langage de programmation. Le temps et l’argent consacrés au développement sont 1,5 fois inférieurs.
• Les applications peuvent ne pas fonctionner correctement. Dans le développement multiplateforme, il est impossible de prendre en compte toutes les nuances du travail avec l'architecture de chaque système d'exploitation, de sorte que les applications peuvent s'exécuter plus lentement que celles développées spécifiquement pour iOS ou Android.
• Les exigences d’interface et de conception des éléments varient selon les systèmes d’exploitation.. Par exemple, iOS n’a pas de bouton Retour comme Android. Lors du développement d'un design unifié, ce point doit être pris en compte : sous iOS, le bouton soit restera, mais ne fonctionnera pas, soit il devra être découpé manuellement, ce qui implique un travail supplémentaire avec le code.

La plupart des erreurs lors de la migration d'une plateforme à une autre peuvent être résolues manuellement, mais il est impossible de résoudre complètement les problèmes d'adaptation à un système d'exploitation « non natif ».

Le développement multiplateforme est donc mauvais ?

Non, le développement multiplateforme est acceptable tant que vous n'en exigez pas plus que ce qu'il peut donner.

Cette option peut être sélectionnée dans les cas suivants :

• Couvrez tous les systèmes d’exploitation avec un budget limité. Si public cible Si vous utilisez iOS ou Android plus activement, vous pouvez commencer avec une application native pour un système d'exploitation. Si une couverture maximale est importante d’emblée, il est préférable de choisir une option multiplateforme.
• Vérifier le créneau. S'il existe une idée prometteuse, mais que vous n'êtes pas sûr qu'elle fonctionnera, il est risqué d'investir immédiatement un budget important dans le développement. Il est logique de commencer par le développement multiplateforme, d'étudier les réactions des utilisateurs et de prendre des décisions stratégiques sur cette base.
• L'application n'utilise pas d'animations complexes et n'effectue pas de calculs. Ces opérations chargent sérieusement l'appareil et l'application multiplateforme n'est pas optimisée pour une utilisation complète des ressources d'une plateforme particulière.
• L'application utilise uniquement les fonctions de base de l'appareil. Afficher des informations, télécharger des fichiers, utiliser la géolocalisation, passer une commande - l'application multiplateforme peut gérer tout cela. Une intégration plus profonde des capacités de l'appareil est requise - vous devrez choisir le développement natif.
• Application d'entreprise pour les employés. Si l'application est développée pour des tâches internes restreintes et que les utilisateurs travailleront avec elle via des gadgets personnels, une application multiplateforme sera la meilleure option.

Il n’existe pas de réponse universelle à la question de savoir si des solutions multiplateformes peuvent être utilisées pour votre projet. Remplissez le formulaire ci-dessous : nous étudierons votre projet et sélectionnerons la meilleure option pour sa mise en œuvre.

Applications multiplateformes – être ou ne pas être ? La question n’est pas facile, puisque chaque entreprise a ses propres objectifs et exigences en matière d’applications mobiles. Mais aujourd'hui, nous déterminerons certainement quel développement vous convient le mieux.

Que sont les applications multiplateformes ?

Les applications multiplateformes sont des applications développées puis exécutées sur Android et iOS. L'essence du développement est que code source L'application est traduite en natif, c'est-à-dire compréhensible par un appareil mobile spécifique. En conséquence, le programme peut interagir avec le logiciel installé dessus. système opérateur.

Rappelons-le : les applications natives, contrairement aux applications multiplateformes, sont écrites pour un OS spécifique.

Avantages du développement multiplateforme

• expansion de la base d'utilisateurs grâce à l'apparition de l'application dans plusieurs magasins simultanément ;
• Le code source unique élimine le besoin d'embaucher plusieurs développeurs pour chaque plate-forme ;
• 75 % de la base de code d'une application multiplateforme peut être réutilisée, en l'adaptant à de nouveaux projets.

Inconvénients du développement multiplateforme

1. Forte dépendance à un appareil mobile

Les applications multiplateformes ne fonctionnent généralement pas hors ligne. Par conséquent, leurs capacités dépendent fortement de la présence d’une connexion Internet stable par l’utilisateur. La version du système d'exploitation et le modèle de l'appareil sont également importants. Il est presque garanti qu’une application multiplateforme réduira les performances d’un appareil vieux de plus d’un ou deux ans. Alors qu'une application native fonctionnera de manière stable même sur un ancien gadget doté d'un firmware obsolète. Donc, si vous ne voulez pas que vos clients lisent des critiques mécontentes sur la façon dont votre application a finalement « terminé » le smartphone de quelqu'un, choisissez le développement natif.

2. Interface utilisateur peu conviviale

Les utilisateurs s'habituent tellement à l'apparence et aux fonctionnalités de leurs gadgets qu'ils attendent une réactivité maximale de la part des applications installées sur eux. Ils veulent être sûrs que chaque bouton sera à sa juste place, que la page défilera à la vitesse optimale pour eux et que toute action qu'ils entreprendront sera suivie d'une réponse immédiate. Les applications multiplateformes ont généralement du mal à s'adapter à l'appareil et ne peuvent pas se vanter de performances.

Le problème est qu'il n'existe pas de lignes directrices pour le développement multiplateforme - des normes de développement émanant des créateurs du système d'exploitation. Par conséquent, une application multiplateforme conçue « pour Android » ne conviendra pas à un utilisateur iOS, et vice versa. Vous pouvez bien sûr créer des conceptions distinctes pour chaque plate-forme, mais en termes de coûts de main-d'œuvre, cela équivaudra à créer deux applications différentes, bien que dans le même langage.

3. La lutte pour la primauté des outils de développement

Sur le marché des solutions de développement multiplateformes, la concurrence devient chaque jour plus rude. Jusqu'à présent, React Native et Xamarin sont les plus populaires parmi les développeurs, mais ils pourraient bien être surpassés, par exemple, par Vue Native. Dans ce cas, les anciens leaders de la course perdront leur avantage le plus important : la prise en charge du code opérationnel. Et cela peut arriver avec n’importe quel outil multiplateforme.

Le développement autochtone n’a pas peur d’un tel problème. L'introduction de nouveaux outils se fait progressivement, et la connaissance de plusieurs langages de programmation, obligatoire pour un spécialiste, lui permettra d'appréhender rapidement toutes les innovations. De plus, il existe d'énormes communautés professionnelles autour de chaque système d'exploitation, de sorte que toute difficulté qui survient est résolue en recherchant un problème similaire sur des forums, où des milliers de personnes sont prêtes à suggérer et à aider à le résoudre.

Quelle application convient à votre entreprise ?

Avant de répondre à cette question, il est essentiel d’analyser votre entreprise. Les segments de consommateurs, la valeur des ressources en temps et en argent, la profondeur souhaitée d'intégration de l'application avec les appareils des utilisateurs, ainsi que des objectifs à long terme clairement définis - le minimum dont dépendra votre choix. Mais nous vous faciliterons la tâche si vous répondez dès maintenant aux questions pertinentes.

1. Qu’est-ce que votre public utilise ?

Si vous savez que le ratio d’utilisateurs iOS et Android parmi vos clients est proche de 50/50, choisissez le développement natif. Cela montrera que vous respectez également les besoins de tous vos clients, quel que soit leur niveau de revenu.

Le lien entre le choix d'un appareil mobile et le niveau de solvabilité a été une nouvelle fois confirmé par App Annie. Suite à des recherches sur le nombre de téléchargements et le volume des ventes applications mobiles V Google Play Et Magasin d'applications au premier trimestre 2018, il s'est avéré que les utilisateurs de smartphones Android téléchargeaient 135 % d'applications en plus que les visiteurs des magasins iOS. Dans le même temps, l'App Store rapportait à ses propriétaires 85 % de revenus supplémentaires que Google Play.

La voie du succès est évidente : jouer sur deux terrains à la fois. Plus précisément, dans deux magasins. Calculez simplement dans lequel d'entre eux l'application doit apparaître en premier. Bien sûr, sauf si une sortie simultanée fait partie de votre stratégie digitale).

2. De combien de temps de développement disposez-vous ?

Les coûts financiers du projet dépendent de la réponse à cette question. Le fait est que du point de vue du temps consacré au développement, une application multiplateforme semble seulement être une solution plus rentable. En fait, l’adapter aux plates-formes peut prendre presque autant de temps que la création de deux applications natives, puisque les développeurs devront écrire des morceaux de code supplémentaires pour résoudre les problèmes.

Avec une application native, il n'y aura certainement pas de tels problèmes, ce qui est très important pour fidéliser un public extrêmement intolérant aux erreurs et aux bugs. Selon les statistiques de Compuware, 79 % des utilisateurs sont prêts à redémarrer une application si celle-ci n'a pas fonctionné correctement lors du premier lancement, mais seulement 16 % acceptent de lui donner une autre chance. D'autres désinstalleront probablement simplement le programme.

3. Quelles fonctionnalités de l’appareil comptez-vous utiliser ?

Nous avons déjà évoqué le fait que seules les applications natives sont capables de reproduire rapidement et sans perte de qualité des graphiques lourds. Mais les avantages techniques du développement natif ne se limitent pas à cela. Prenons l'exemple de l'application Facebook. Grâce à la sortie de versions distinctes pour Android et iOS, le défilement est devenu plus fluide, les temps de chargement des images ont été réduits et tous les problèmes de cache ont été résolus.

De plus, les applications natives ont un accès direct à tous les services de l'appareil, vous permettant d'obtenir des informations sur la géolocalisation de l'utilisateur ou sur sa liste de contacts. Les applications multiplateformes doivent utiliser des plugins natifs spéciaux, ce qui affecte négativement la vitesse de transfert des données et les surcharges. BÉLIER appareils.

4. Quels résultats recherchez-vous ?

La stratégie numérique est une liste d'objectifs que votre entreprise peut atteindre avec l'aide de instruments numériques. Le choix de ce dernier dépend en grande partie des avantages que vous souhaitez obtenir au final.

Décomposez le processus de l’idée au résultat point par point en tenant compte de toutes les ressources disponibles. Les découvertes peuvent être les plus inattendues.

Par exemple, vous constaterez peut-être qu'il est trop coûteux de transformer votre site Web réactif, qui regorge de fonctionnalités et d'éléments interactifs, en une application multiplateforme comme vous le souhaitiez à l'origine. Ou enfin, assurez-vous qu'un site mobile perd toujours face à une application mobile, tout comme le développement multiplateforme perd face au développement natif. Et parmi les raisons, vous retrouverez celles que nous avons décrites ci-dessus.

Conclusion : une application multiplateforme n'est bénéfique que dans un cas : vous créez une version de démonstration de l'application, limitée en temps, en argent et en spécialistes hautement spécialisés. Dans tous les autres cas, une application native vous apportera bien plus d'avantages, puisqu'il s'agit d'un niveau de développement qualitativement différent.

Le marché des applications mobiles existe depuis plus de dix ans, mais il continue de se développer rapidement. La demande des entreprises est en constante augmentation et elle dépasse encore largement l'offre, ce qui entraîne une augmentation constante du coût de développement. Une solution pour réduire le coût de ce processus est le développement multiplateforme, lorsque le même code est utilisé sur toutes les plateformes.

La dernière fois, nous avons abordé le développement d'applications mobiles multiplateformes et beaucoup de choses ont changé depuis. Il est temps de reparler de méthodes et d’outils.

Reprenons d’abord la terminologie.

Parents

Si les développeurs, en train d'écrire une application, utilisent le langage de programmation adopté pour une plate-forme spécifique, qu'il s'agisse d'Objective-C et de Swift pour iOS ou, une telle application sera appelée native (de l'anglais native - native, natural).

Avantages des applications natives :

• vitesse et réponse de l'interface. L'application répond instantanément aux clics, il n'y a pratiquement aucun retard dans l'animation, le défilement, la réception et la sortie des données ;
• accès clair et facile aux fonctions et aux capteurs de l'appareil. Pour le développeur, travailler avec la géolocalisation, les notifications push, prendre des photos et des vidéos via l'appareil photo, le son, l'accéléromètre et d'autres capteurs n'est pas un problème ;
• la capacité de travailler en profondeur avec les fonctions du smartphone. Comme dans le paragraphe précédent, des éléments tels que les animations, la création d'interfaces complexes et le fonctionnement de réseaux neuronaux directement sur les appareils sont mis en œuvre, peut-être pas simplement, mais de manière prévisible ;
• . Les applications natives fonctionnent généralement avec des éléments d'interface « plateforme » : les menus, la navigation, les formulaires et tous les autres éléments de conception sont extraits du système d'exploitation et sont donc familiers et compréhensibles pour l'utilisateur.

Il n'y a qu'un seul inconvénient : le coût élevé de développement et de support, notamment parce que vous devez écrire votre propre code pour chaque plate-forme.

Avec la croissance du marché des applications mobiles, les développeurs sont devenus non seulement coûteux, mais très coûteux, et le développement natif n'est pas quelque chose que tous les propriétaires d'entreprise peuvent se permettre. Mais ne pas développer d’application mobile pourrait vous coûter plus cher à l’avenir. Live Typing peut vous aider à économiser de l'argent - décrivez votre idée et indiquez le budget approximatif que vous souhaitez respecter, au format .

Et pas des proches

Les applications multiplateformes sont écrites pour plusieurs plates-formes à la fois dans un langage autre que le langage natif. Comment un tel code peut-il fonctionner sur différents appareils? Il existe également deux approches ici.

La première est qu'au stade de la préparation de la candidature à la publication, celle-ci est convertie en natif pour une plateforme spécifique à l'aide d'un transpileur. En fait, un langage de programmation multiplateforme est « traduit » en un autre.

La seconde est qu'un certain wrapper est ajouté au code résultant, qui, fonctionnant déjà sur l'appareil, traduit à la volée les appels du code non natif en fonctions système natives.

On suppose que la majeure partie de ce code peut être transférée entre les plates-formes - il est évident que, par exemple, la logique consistant à effectuer des achats, à enregistrer des marchandises dans le panier, à calculer un itinéraire pour un taxi, à écrire un message dans le messager ne change pas. selon que le client dispose d'Android ou d'iOS. Nous avons juste besoin d'améliorer l'UI et l'UX des plates-formes, mais désormais, dans certaines limites, même cela peut être combiné - par exemple, le menu hamburger est activement utilisé sur Android et iOS. Ainsi même apporter des corrections à l'interface pour que l'application réponde à l'esprit et à la lettre de la plateforme souhaitée est une question d'envie, de rapidité et de qualité de développement requises.

Avantages :

• coût et rapidité de développement. Comme il faut écrire beaucoup moins de code, le coût du travail est réduit ;
• la capacité d'utiliser les ressources internes de l'entreprise. Comme nous le montrerons plus tard, le développement d'applications multiplateformes peut souvent être réalisé par vos programmeurs existants.

Défauts:

• interface non native ou, au minimum, la nécessité de travailler avec l'interface de chaque plateforme séparément. Chaque système a ses propres exigences pour la conception des éléments et parfois elles s'excluent mutuellement. Ceci doit être pris en compte lors du développement ;
• problèmes de mise en œuvre fonctions complexes ou problèmes possibles travailler même avec des procédures simples en raison d'erreurs dans les cadres de développement eux-mêmes. L'environnement multiplateforme traduit uniquement les requêtes vers les appels système et les interfaces dans un format que le système comprend, et donc à ce stade, des difficultés de compréhension et des erreurs peuvent survenir dans le cadre lui-même ;
• rapidité de travail. Étant donné que l'environnement multiplateforme est une « superstructure » sur le code (pas toujours, mais dans certaines situations), il a ses propres retards et pauses dans le traitement des actions de l'utilisateur et l'affichage des résultats. Cela était particulièrement visible il y a quelques années sur les smartphones qui étaient moins puissants qu'aujourd'hui, mais maintenant, avec une productivité croissante. appareils mobiles, cela peut déjà être négligé.

Comme vous pouvez le constater, ces deux méthodes sont pratiquement image miroir- que le développement d'applications natives présente des avantages, le développement d'applications multiplateformes présente des inconvénients, et vice versa.

Plateformes et outils populaires pour le développement mobile multiplateforme

Comme nous l'avons écrit ci-dessus, il existe deux approches : transformer le code en natif au stade de l'assemblage ou ajouter un certain wrapper qui traduit les appels vers et depuis le système.

Cordova et PWA sont deux outils qui fonctionnent précisément dans l'idéologie d'un wrapper.

Cordoue et HTML5

L'un des domaines les plus populaires de la programmation multiplateforme, souvent appelé PhoneGap. En fait, un site Web mobile est créé, qui est « enveloppé » dans un petit code de plate-forme qui transmet les appels du système à l'application et inversement.

Tous les inconvénients et avantages sont exprimés ici plus clairement que partout ailleurs. Vous pouvez faire appel à des développeurs Web (HTML, CSS et JavaScript comme technologies de base) et créer la première version de l'application en un mois, voire quelques semaines, pour relativement peu d'argent. Oui, son fonctionnement sera lent et sa géolocalisation ne sera peut-être pas tout à fait précise, mais il fonctionnera sur tous les appareils et vous permettra, au minimum, de tester la demande des clients sur les appareils mobiles.

Un grand nombre de frameworks ont été créés pour cette approche, mais ils font tous essentiellement la même chose. La différence entre eux est que Cordova (PhoneGap) ne définit pas de restrictions ni de modèles sur la logique et l'interface utilisateur de votre projet HTML5, et les frameworks fonctionnent avec leurs propres éléments d'interface utilisateur prêts à l'emploi qui imitent les plates-formes mobiles et leur propre logique de développement. Un exemple de cette approche est : Ionic Framework - wrapper ; Framework7, Mobile Angular UI, Sencha Touch, Kendo UI - frameworks d'interface.

PWA

La technologie à la mode de Google est constituée des mêmes applications Web, mais grâce à l'utilisation de certaines technologies (principalement les soi-disant Service Workers - travaillant dans arrière-plan scripts et Web App Manifest - une description de l'application Web de manière compréhensible système mobile formulaire), ils peuvent fonctionner comme des fichiers natifs sans le wrapper PhoneGap. Ils peuvent être installés sur écran d'accueil contourner l'App Store, travailler hors ligne, travailler avec des notifications push, avec des fonctions natives.

Le problème est que toutes les plateformes ne prennent pas encore en charge ces « certaines technologies ». Cela concerne principalement Apple, qui n’apprécie apparemment pas vraiment la possibilité de distribuer des applications en contournant l’App Store.

Compte tenu de toutes les lacunes des solutions HTML5, de nombreuses entreprises ont créé des outils qui permettent d'écrire du code dans une langue non native, puis de le traduire en natif. Cela fait d'une pierre deux coups : il n'y a qu'une seule base de code et les applications sont aussi proches que possible du natif.

Xamarin

Plateforme Microsoft. Le langage de programmation standard pour le développement d'entreprise est C# et l'environnement de développement multiplateforme est Visual Studio. Le résultat est des applications natives pour iOS, Android et Windows. Certes, de taille relativement grande.

Réagir natif

Plateforme de - les applications sont écrites en JavaScript et utilisent des styles de type CSS. L'interface s'avère native, et le code est interprété sur la plateforme, ce qui lui confère la flexibilité nécessaire.

Étant une plate-forme relativement jeune, React Native souffre encore évidemment (mais pas de manière catastrophique) d'un manque d'outils de développement et de documentation.

Battement

Naturellement, un géant comme Google ne pouvait ignorer le sujet du développement multiplateforme d'applications Android et iOS. Flutter, bien qu'actuellement uniquement en version bêta, adopte une approche différente de React Native et Xamarin. Il ne transforme pas le code source en code natif, qui est exécuté par la plateforme, mais dessine en fait une fenêtre sur l'écran du smartphone et restitue lui-même tous les éléments. Le langage utilisé est Dart « propriétaire », créé par Google comme une version améliorée de JavaScript.

Cela présente à la fois des avantages (par exemple, des interfaces identiques en externe) et des inconvénients (par exemple, redessiner l'interface nécessite une certaine quantité de mémoire et de temps CPU).

La plateforme se développe rapidement et Google y investit beaucoup d'efforts et d'argent. Mais comparé à Flutter, même React Native semble être un écosystème très établi et impressionnant.

Que choisir

Vous avez probablement déjà la tête qui tourne, mais vous ne savez toujours pas quoi choisir. Présentons une liste simple de questions pour vous aider :

• Cela devrait-il fonctionner sur n’importe quel appareil ? Choisir HTML comme base;
• Vous disposez de suffisamment de fonds, n'êtes pas pressé et souhaitez une candidature de la plus haute qualité ? Vous avez un chemin direct vers développement natif;
• Avez-vous un développeur web « intégré » ou souhaitez-vous simplement tester rapidement et facilement une application mobile en action ? Ici, nous pouvons recommander Cordova/HTML ou PWA;
• Avez-vous votre propre système CRM et un développeur C# qui le prend en charge ? Prends-le Xamarin;
• vous « voulez essayer », mais vous avez besoin de tout rendre beau et à la mode ? Détourner les yeux Réagir natif ou Flutter.

Vous pouvez également passer de l'autre côté. Examinez les fonctionnalités dont vous aurez besoin dans votre application et partez de là :

• une simple application de carte de visite ? Prendre React Native ou HTML5 et vous obtiendrez deux plateformes pour un prix minime ;
• avez-vous un site Web avec forte fréquentation et vous avez besoin de tester votre hypothèse de présence dans l'espace mobile ? HTML5;
• applications complexes avec accès à fonctions nécessaires des appareils ? Développement natif, Xamarin, React Native.

Le développement multiplateforme n'est pas une panacée

Lors du choix, vous devez partir des tâches assignées et des ressources existantes. Le développement multiplateforme est une direction bonne et compréhensible, mais avec ses propres avantages et inconvénients qu'il faut garder à l'esprit avant de lancer le projet. Une application multiplateforme terminée est évidemment meilleure qu’une application native non créée. Vous pouvez le développer rapidement et à moindre coût, le télécharger dans le magasin et vérifier simplement la demande des utilisateurs - si quelqu'un recherche votre application, s'il l'installe, quelles fonctions il utilise. Sur la base des résultats d'une telle expérience, il sera possible de décider du sort de la direction mobile dans votre entreprise et des investissements dans celle-ci.

Avez-vous encore des doutes et des questions sur les applications multiplateformes ? Découvrez comment nous avons créé une application permettant d'obtenir rapidement un abonnement à l'une des institutions sportives de la ville et essayez l'application permettant de payer toutes sortes de services - du logement et des services communaux aux commandes dans les magasins en ligne. Mieux encore, inscrivez-vous consultation gratuite, indiquant le budget approximatif et brève description idées ou contactez notre manager Katya par téléphone

Les smartphones continuent de gagner de plus en plus de place au soleil, non seulement comme outil de consommation de photos de chats et de vidéos XXX, mais aussi comme outil de travail. Par conséquent, la demande de développement mobile augmente. Il est généralement admis que travail et cool sont Objective-C/Swift pour iOS et Java/Kotlin pour Android. Pas de doute, c'est laborieux et cool, mais ça existe grand nombre des scénarios réels dans lesquels l’utilisation de frameworks multiplateformes est préférable aux outils natifs.

Certains développeurs s'attendent à ce que les frameworks multiplateformes résolvent tous leurs problèmes de vie, tandis que d'autres leur sont hostiles. Les deux « camps en guerre » ont leurs propres idées fausses causées par un manque de compréhension de comment et de ce qui fonctionne. Cela alimente le feu, puisque les émotions sont utilisées à la place des arguments techniques.

Parmi les développeurs, en particulier les débutants, il existe de nombreux mythes sur les frameworks mobiles multiplateformes. Dans notre article, nous analyserons les plus populaires d'entre eux. Mais d’abord, regardons le développement mobile à travers les yeux d’une entreprise qui finance tout le blackjack informatique.

Pourquoi avons-nous besoin d’outils multiplateformes ?

Historiquement, il y a toujours eu de la concurrence sur le marché informatique, et chaque fabricant fournissait l'ensemble optimal d'outils dits natifs pour développer des applications pour ses systèmes d'exploitation et ses appareils.

Outils natifs = fournis par le propriétaire de l'écosystème.

Tous les autres signes de « natif » sont SECONDAIRES : comportement et interface de l'application, accès aux capacités du système d'exploitation, performances, etc.

De plus, il s'est presque toujours avéré que les outils natifs sont incompatibles entre eux non seulement au niveau des langages de développement, des conventions et des architectures acceptées, mais également au niveau des mécanismes de travail avec le système d'exploitation et les bibliothèques. En conséquence, pour implémenter les mêmes algorithmes et interfaces, il était nécessaire d'écrire une application pour plusieurs environnements dans différentes langues programmation, puis la prendre en charge à raison « d’une commande par plateforme ». En même temps, les possibilités et apparence les applications sur différentes plates-formes sont presque toujours identiques à 90 %. Juste pour vous amuser, comparez l'implémentation de vos programmes préférés pour iOS et Android.

Le deuxième point important est la présence des connaissances et de l'expérience nécessaires au sein de l'équipe : si elles ne sont pas là, alors il faudra du temps pour apprendre.

Afin de résoudre ces deux problèmes, des outils de développement multiplateformes (et pas seulement mobiles) sont apparus depuis longtemps sur le marché, proposant :

• maximiser la base de code commune dans un seul langage de programmation afin que le produit soit plus facile à développer et à maintenir ;
• utiliser les compétences et les spécialistes existants pour mettre en œuvre des applications sur de nouvelles plates-formes.

Puisqu'il existe désormais de nombreux langages (et environnements) de programmation (et de spécialistes qui parlent ces langages), il existe un bon nombre d'outils pour le développement multiplateforme. À titre d'exemple, nous nous concentrerons sur les plus populaires dans notre région PhoneGap, Xamarin, React Native et Qt.

Nous pouvons maintenant parler de mythes.

Mythe 1. Magie

Le mythe le plus répandu qui hante l'esprit des développeurs débutants est lié à la croyance dans les super-algorithmes (et dans les super-programmeurs qui les ont créés) qui transforment comme par magie les applications multiplateformes en applications natives. Quelque chose du genre « convertir du code JavaScript en Swift, puis compiler une application Swift ». Ce mythe est alimenté par les développeurs d’outils multiplateformes eux-mêmes, promettant ainsi la création d’« applications natives ». Et ce n’est pas que quiconque ment ici, mais une imagination riche et une incompréhension des mécanismes de base amènent parfois les développeurs à réfléchir aux techniques chamaniques.

Le principe principal des solutions multiplateformes est de diviser le code en deux parties :

• multiplateforme, vivant dans un environnement virtuel et ayant accès limité aux capacités de la plate-forme cible via un pont spécial ;
• indigène, qui assure l'initialisation et la gestion des applications cycle de vie installations clés et a un accès complet à API système.

Afin de connecter le monde « natif » et le monde « multiplateforme », il est nécessaire d'utiliser un pont, c'est lui qui détermine les capacités et les limites des frameworks multiplateformes.

Lors de l'utilisation d'un pont, les performances sont toujours réduites en raison de la conversion des données entre les « mondes », ainsi que de la conversion des appels API et des bibliothèques.

Ainsi, toutes les applications multiplateformes doivent avoir une partie native, sinon le système d'exploitation ne pourra tout simplement pas les lancer. Examinons donc de plus près les API et mécanismes système fournis par iOS, Android et Windows eux-mêmes. Passons au mythe suivant.

Mythe 2. Pas natif !

Nous avons donc une partie multiplateforme de l'application qui vit dans un environnement virtuel et interagit avec le système d'exploitation via l'infrastructure-cadre et le pont.

Tous les systèmes d'exploitation : iOS, Android et Windows UWP donnent accès aux sous-systèmes suivants (ensembles d'API système) :

• WebView (un navigateur Web intégré à l'application) est utilisé dans les mashups basés sur PhoneGap et agit essentiellement comme un environnement d'exécution pour le site Web local ;
• Les moteurs JavaScript sont utilisés dans React Native et leurs analogues pour une exécution rapide du code JS et l'échange de données entre Native et JS ;
• OpenGL ES (ou DirectX) est utilisé dans les moteurs de jeux et les applications basés sur Qt/QML ou analogues pour le rendu de l'interface ;
• Le sous-système UI est responsable de l’interface utilisateur native de l’application, qui est pertinente pour React Native et Xamarin.

Les applications multiplateformes ont une partie native et le même accès complet aux API système que les applications natives. La différence est que la méthode système est appelée via le pont et l'infrastructure framework :

Vue Web- l'application réside dans son navigateur Web, semblable à un site Web d'une seule page. Il n'y a pas d'accès aux contrôles natifs (boutons, listes, etc.), tout est basé sur HTML/CSS/JavaScript. D’un autre côté, un développeur Web se sentira comme un poisson hors de l’eau.

Moteurs JavaScript est devenu populaire relativement récemment, puisqu'un mécanisme similaire n'a été ajouté à iOS que dans la version 7.0. L'une des fonctionnalités à prendre en compte est la nécessité de sérialiser des structures de données complexes transférées entre les environnements JavaScript et natifs dans JSON. Pour décrire brièvement cette classe de solutions, le code JS qui contrôle l'application native est exécuté dans l'environnement JavaScript.

OpenGL ES et DirectX sont des sous-systèmes de bas niveau et sont utilisés pour le rendu interface utilisateur dans les jeux et, par exemple, Qt/QML. Autrement dit, lors de l'utilisation d'OpenGL/DirectX, les développeurs dessinent eux-mêmes des contrôles et des animations, qui ne peuvent être similaires qu'à ceux natifs. D’un autre côté, il s’agit d’un sous-système de bas niveau doté de très hautes performances, c’est pourquoi il est également utilisé dans les moteurs de jeux multiplateformes.

Toutes les applications multiplateformes ont une partie native, et donc potentiellement le même accès complet aux API système que les applications natives. De plus, les applications multiplateformes sont assemblées et regroupées par des outils « natifs » en outils « natifs ». paquets d'installation. La question clé est de savoir comment s’organise l’interaction entre la partie multiplateforme et la partie native. Par exemple, dans WebView ou en utilisant Open GL ES / DirectX, il n'existe aucun moyen de créer une interface utilisateur avec une apparence entièrement native, mais en même temps, il existe un accès complet au GPS, aux notifications push et à d'autres fonctionnalités. Et le code en JavaScript ou C# peut contrôler assez librement l’application native et son comportement, offrant ainsi une apparence totalement native.

Pour résumer, oui, c'est « non natif » du point de vue des outils de développement utilisés (pas d'Apple, Google). Mais une application peut être entièrement native en termes d’accès aux API système et offrir une apparence et une convivialité totalement natives. Et nous passons au mythe suivant.

Mythe 3. Une béquille sur une béquille

Ici, il convient de comprendre que les API natives ne sont pas considérées par défaut comme des béquilles (bien qu'il existe des opinions différentes ici), donc toute l'indignation est dirigée vers la partie multiplateforme. De toute évidence, l'environnement d'exécution (par exemple, WebView, moteur JavaScript ou Mono) est également difficile à qualifier de béquille - des solutions matures et matures avec une longue histoire.

Il semble que la béquille soit la manière dont la partie multiplateforme s'intègre à la partie native. Pour mieux comprendre le fonctionnement des différents frameworks, en utilisant l'exemple de PhoneGap, Xamarin, Qt et React Native, nous examinerons les mécanismes du système d'exploitation qui sont utilisés pour relier les parties multiplateformes et « natives ».

Nous allons commencer par PhoneGap. Vous trouverez ci-dessous l'architecture de haut niveau d'une application basée sur ce framework.

Une application sur PhoneGap est en fait une application native qui affiche une WebView comme seul contrôle d'interface utilisateur. C'est à travers elle que se produit l'interaction avec la partie native. Toutes les WebViews standard dans iOS, Android et Windows UWP prennent en charge la possibilité d'ajouter vos propres gestionnaires natifs pour les propriétés et méthodes JS. Dans le même temps, le code JS vit dans son propre environnement isolé et ne sait rien de la partie native - il extrait simplement les méthodes JS nécessaires ou modifie les propriétés JS nécessaires. Tout se trouve dans le DOM web standard, auquel sont simplement ajoutés les nouveaux éléments associés à l'implémentation native.

Lors de la création d'applications en React Native, le développeur devra presque toujours implémenter la partie native en Objective-C, Java ou C#, et la gestion de l'application native elle-même viendra de JavaScript. En fait, le moteur JavaScript est un élément WebView disponible séparément. L'interaction s'effectue via le même pont JS que dans le cas de PhoneGap. Cependant, dans React Native, le code JS ne contrôle pas l’arborescence web DOM, mais l’application native.

Veuillez noter qu'en raison des limitations d'iOS (il n'existe aucun moyen d'implémenter JIT), le code JavaScript est interprété à la volée plutôt que compilé. En général, cela n'a pas d'impact significatif sur les performances dans applications réelles, mais cela vaut la peine de le rappeler.

Examinons maintenant les classiques Xamarin.iOS et Xamarin.Android, puisque Xamarin.Forms (qui prend en charge Windows UWP) en est un module complémentaire.

Xamarin utilise la bibliothèque Mono pour interagir avec le système d'exploitation cible, ce qui vous permet d'appeler du code natif à l'aide du mécanisme P/Invoke. Il est également utilisé pour communiquer avec les API natives sous iOS/Android. Autrement dit, pour toutes les méthodes API natives publiques, les wrappers sont créés en C#, qui, à leur tour, appellent les API système. De cette façon, vous pouvez accéder à toutes les API système à partir de votre application Xamarin.

Et enfin, regardons Qt, car les développeurs expérimentés posent beaucoup de questions à ce sujet.

Qt est une « chose en soi », cela présente à la fois des avantages et des limites. Les bibliothèques Qt se connectent simplement aux API du système C++ présentes sur tous les systèmes d'exploitation. Pour restituer l'interface utilisateur, des mécanismes de bas niveau sont utilisés, mais son propre moteur graphique prend en charge le style natif. Dans ce cas, sur Android, vous devez accéder à l'API Java via un pont spécial (pont JNI), et pour Windows UWP, utilisez le convertisseur d'appel Open GL ES vers DirectX, car Open GL n'est pas disponible pour UWP.

Pour résumer : tous les frameworks multiplateformes utilisent les capacités natives standard des systèmes d'exploitation, sont matures et sont créés par des équipes expérimentées et la communauté open source avec le soutien des géants de l'industrie informatique. Et enfin, il est temps de passer à l’argument « le plus fort ».

Mythe 4. Lent

Un atout important que les gens aiment utiliser dans les conflits concernant les frameworks multiplateformes est la faible performance. Encore une fois, cela dépend de ce avec quoi comparer et des perroquets à compter.

Rappelons que la particularité des applications multiplateformes est l'existence parallèle de deux mondes reliés par un pont :

• PhoneGap : HTML/JS et Java natif / Objective-C / C# ;
• React Native : JS et Java natif / Objective-C / C# ;
• Xamarin : Java/Objective-C mono et natif ;
• Qt : C++ et Java Natif / Objective-C.

Ainsi, lors de la comparaison des performances, il faut prendre en compte la rapidité de fonctionnement :

• partie multiplateforme ;
• partie native;
• pont.

Si vous tapez dans un moteur de recherche, par exemple, les performances natives ou rapides, vous pouvez examiner de nombreux tests différents, et beaucoup d'entre eux notent que les performances chutent fortement avec l'utilisation active du pont, y compris la manipulation active de l'interface utilisateur à partir de cross- code de la plateforme. Pour Xamarin, la situation est la même : la partie multiplateforme est très rapide et comparable à la partie native en matière de traitement des données, mais lors de l'utilisation du pont, les performances peuvent chuter. Qt fonctionne généralement au niveau C++, ce qui est rapide en soi. Si nous envisageons des solutions basées sur PhoneGap, les performances dépendront grandement de WebView, mais vous ne devez toujours pas modifier activement l'interface utilisateur dans le code JavaScript ni effectuer de calculs scientifiques.

Lentement? Oui, des baisses de performances sont possibles en raison d'une interaction inappropriée avec le système d'exploitation via un pont. Cependant, les mondes multiplateformes eux-mêmes sont tout aussi rapides que les mondes natifs.

Il semblerait que nous ayons un développement multiplateforme, qui permet de créer des applications universelles pour différentes plateformes. J'ai écrit l'application plus rapidement, je l'ai immédiatement publiée partout - profitez-en ! Et aucun développement natif n’est nécessaire. Ou est-ce encore nécessaire ? Nous avons interrogé nos experts sur les nuances des deux approches du développement d'applications mobiles.

Le « développeur mobile » est un concept large. Un développeur qui implémente des parties d’un système d’exploitation mobile est également un développeur mobile. Et si l’objectif est de devenir un tel développeur, vous devez alors commencer par étudier le C++, le système d’exploitation mobile et le matériel des appareils mobiles.

Si vous parlez d'un développeur implémentant des applications mobiles personnalisées, vous devez alors commencer par le développement natif.

Pourquoi est-ce ainsi ? Le développement natif vous permet d'étudier de manière plus approfondie et plus approfondie les capacités de systèmes d'exploitation spécifiques (et de leurs applications) et du matériel mobile.

Du point de vue de l’utilisateur, le développement natif gagne définitivement. Les applications natives fonctionnent plus rapidement, leur interface est plus réactive et plus familière aux utilisateurs d'un système d'exploitation mobile spécifique, elles utilisent mieux les capacités matérielles de l'appareil, fonctionnent mieux hors ligne et sont moins boguées.

L'idée originale du développement multiplateforme est de réduire les coûts de main-d'œuvre des développeurs. Cela peut être brièvement exprimé comme suit : « Fait une fois, ça marche sur n’importe quoi. » L’idée est bonne et correcte (du point de vue du développeur), mais il y a des problèmes de qualité. Toute polyvalence implique intrinsèquement un compromis, et le domaine du développement mobile ne fait pas exception.

Lors du choix du type de développement pour une tâche spécifique, le développeur doit évaluer dans quelle mesure ce compromis est acceptable. Il existe un certain nombre de tâches pour lesquelles le recours au développement multiplateforme sera tout à fait justifié, par exemple dans les projets de test, les versions mobiles de sites Web, les jeux utilisant des frameworks comme Unity 3D.

Dans le même temps, pour les projets qui résolvent les problèmes des entreprises mobiles (avec une charge élevée, la nécessité de prendre en charge le mode hors ligne, visant un développement à long terme), le développement natif semble être le seul optimal (et pour certaines tâches, le seul possible). ) option.

Dans le même temps, les principaux inconvénients du développement natif sont le temps de développement (il en faut plus) et le besoin de ressources diverses (développeurs dans différents langages de programmation natifs). Il existe des moyens d'atténuer ces inconvénients - par exemple, en utilisant pour le développement une sorte de plate-forme d'applications mobiles (classe MEAP), qui vous permet de créer des applications natives.

Promouvoir Rétrograder

, Directeur du Développement Technologique de la société informatique "ID - Management Technologies"

Toute bibliothèque ou framework multiplateforme est basé sur les mêmes mécanismes natifs sur lesquels le développement natif est directement implémenté. C'est juste que dans le cas des solutions multiplateformes, les processus de travail sont construits de manière à « aplanir les angles » en termes d'amener l'interface de la solution finale à un certain dénominateur commun.

En règle générale, l'universalisme n'est pas toujours la réponse à la tâche de création d'une solution mobile fonctionnelle : le développeur travaille d'autant mieux qu'il comprend mieux les mécanismes des différents processus de l'intérieur, comme on dit, « sous le capot ».

En outre, un modèle pleinement fonctionnel serait la maîtrise simultanée des éléments de base des deux approches ; il n'y a rien d'impossible dans une telle tâche d'apprentissage au stade initial. Par exemple, un tel scénario peut s'avérer tout à fait réalisable et prometteur : commencer à travailler dans un paradigme multiplateforme, et en même temps, indépendamment ou avec l'aide de collègues, étudier quelles capacités natives existent pour développer les solutions actuelles et comment ils peuvent être appliqués dans la pratique.

Dans ce cas, il est plus facile de parvenir à une compréhension globale du fonctionnement en principe du processus de développement mobile, appelé de bout en bout. Ceci est également utile car toute plate-forme universelle, même la plus avancée, est en retard par rapport à la plate-forme native dans ses capacités : les fabricants de matériel et de systèmes d'exploitation mobiles travaillent souvent ensemble et augmentent constamment les capacités des solutions finales - les capacités des plates-formes de développement mobile, en particulier cross -les solutions de plate-forme sont inévitablement à la traîne.

De nouveaux produits dans le segment des appareils mobiles apparaissent constamment sur le marché, certains d'entre eux sont nettement en avance sur leur temps - comme Samsung et son développement d'un appareil avec un écran pliable : il est évident que, en raison d'un frontal radicalement différent , les plateformes de développement existantes ne sont pas prêtes pour de telles choses.

C'est là que la connaissance approfondie des plates-formes natives s'avère utile : seul un développeur possédant une connaissance approfondie et systémique du développement mobile, c'est-à-dire des plates-formes natives, peut compenser le retard naturel par rapport au matériel et au système d'exploitation. Seul un tel spécialiste pourra augmenter les fonctionnalités de sa solution pour les derniers appareils mobiles sur la base des plateformes de développement pas entièrement avancées actuellement disponibles.

Le développement multiplateforme est idéal pour le prototypage, le test rapide d'idées, etc. Dès qu'il s'agit de créer des produits véritablement fondamentaux, le développeur en vient inévitablement à la nécessité d'étudier en profondeur les éléments de base du processus, c'est-à-dire le développement natif.

Promouvoir Rétrograder

, Doyen de la Faculté de développement iOS GeekUniversity, portail éducatif GeekBrains

Réponse courte : si vous n'avez aucune expérience en programmation, alors, bien sûr, vous devez choisir le développement natif. Le développement multiplateforme convient aux spécialistes qui passent de domaines connexes au développement mobile. Par exemple, si vous êtes un développeur frontend avec une bonne connaissance de JavaScript utilisant le framework React Native (construit sur le framework React), vous pouvez essayer rapidement et sans douleur de maîtriser le développement mobile. De même, il sera plus facile pour un développeur .NET de maîtriser le framework Xamarin.

Le développement multiplateforme est également bénéfique pour le client : il est plus facile de trouver une équipe de développeurs qui, selon un modèle commun, développera une application pour deux plates-formes à la fois.

Les avantages sont évidents, mais quels sont les inconvénients du développement multiplateforme ?! On pense que plus la fonctionnalité d'une application mobile est complexe et subtile, plus il est difficile, voire impossible, de la mettre en œuvre à l'aide d'outils multiplateformes - cela l'emporte souvent sur tous les avantages des outils universels. D'après mon expérience, plusieurs grandes entreprises, avec la croissance de leur application, ont été contraintes d'abandonner le multiplateforme au profit du développement natif. Ainsi, pour les petits projets et, éventuellement, les tâches indépendantes, les solutions générales suffisent, mais pour les grands projets, les solutions natives sont mieux adaptées.

La demande pour les deux domaines est assez élevée, mais pour le développement natif, elle est un peu plus élevée : sur demande de Swift sur hh.ru en Russie - 369 postes vacants, Kotlin - 397, React Native - 111, Flutter - 13 Xamarin - 18. Mais rassurez-vous , un bon spécialiste de Il n'y aura plus d'emploi dans aucun secteur.

Promouvoir Rétrograder

Pour commencer, il est important de noter que toute application mobile se compose de plusieurs couches :

• L'interface utilisateur est ce que l'utilisateur voit ;
• la logique métier est la raison pour laquelle l'application est écrite ;
• autres composants de la plate-forme : travail avec le réseau, les bases de données et d'autres composants du système utilisés par la logique métier.

En fonction de l'application spécifique, la taille des composants sur ces couches peut varier considérablement. Par exemple, une application permettant de lire des actualités sur un site Internet sera très différente d’un client VPN.

Le développement lui-même peut être divisé en trois types : natif, entièrement multiplateforme et hybride.

Développement natif

Dans le développement natif, les trois couches sont écrites à l’aide du même ensemble d’outils. Ils peuvent donc interagir les uns avec les autres sans complexité supplémentaire.

Avantages du développement natif :

Développement hybride

Ce type de développement combine les deux approches précédentes. La couche de logique métier est construite comme un composant « portable », et l'intégration de l'interface utilisateur et de la plate-forme est créée à l'aide d'outils standard. Il existe plusieurs langages pour écrire de la logique générale : C/C++ (solution mature et puissante), KotlinNative (très activement développé) et JavaScript (le moins courant).

Avantages :

• les composants les plus adaptés pour cela restent natifs ;
• la logique globale est créée une fois.

Défauts:

• si un composant commun doit être créé par une équipe mobile, alors il est nécessaire d'acquérir une expertise dans une langue supplémentaire ;
• il y a une surcharge pour l'intégration de composants multiplateformes.

Par quel type de développement est-il préférable de commencer ?

Afin de répondre à cette question, vous devez comprendre quel type de projets vous souhaitez créer. Les petits projets peuvent être purement multiplateformes et cela sera tout à fait justifié. Ici, je vous conseille de regarder de plus près Flutter.

Mais aujourd’hui, je commencerais par le développement natif. Premièrement, la plupart des projets actuels sont créés de manière native. Cela signifie que vous aurez plus de possibilités de changer de projet/entreprise. Deuxièmement, au fil du temps, il sera possible de passer à un développement hybride multiplateforme. Cela vous permettra de progresser dans les domaines techniques.

Promouvoir Rétrograder

Selon moi, il est préférable de commencer par du natif, puis, si vous le souhaitez vraiment, de maîtriser un ou plusieurs outils multiplateformes. La seule exception peut être le développement de jeux, car ils sont principalement écrits sous Unity, et il s'agit d'un moteur multiplateforme.

Si nous parlons des avantages du développement natif, cela signifie pour un programmeur moins d'obstacles et plus divers outils de travail. Il disposera également de plus de sources d'informations pour résoudre les problèmes complexes qui surviennent lors du processus de création d'une application - ce n'est un secret pour personne que pour le développement natif, il existe bien plus de trucs et astuces sur Internet que pour le développement multiplateforme.

Pour l'utilisateur final, le développement natif signifie que l'application aura des interfaces et des modèles de comportement familiers et prévisibles - à condition que l'application soit écrite conformément à tous les guides.

Une application multiplateforme peut ne pas toujours être en mesure de respecter pleinement les directives des deux plateformes, ce qui peut créer des difficultés supplémentaires pour le développeur et l'utilisateur. L'exemple le plus simple- la situation du bouton « Retour » : sous Android il est présent sur presque tous les écrans, alors que sous iOS il ne l'est pas. Si vous créez une application multiplateforme sans ce bouton, certains utilisateurs d'Android peuvent ressentir un inconfort.

Il convient également de mentionner les différences dans les coûts de développement. Si le projet n'est pas complexe, choisir le développement multiplateforme vous permet d'économiser votre budget, car vous ne développez en fait pas des produits séparés pour différentes plateformes, mais un pour toutes. Mais si le projet se développe, la balance commence à pencher dans l’autre sens et le développement natif peut s’avérer plus rentable.

En ce qui concerne la vitesse d'application, les produits multiplateformes sont plus lents. Par exemple, ceux basés sur les technologies web ont comme couche un navigateur, ce qui ralentit considérablement l’application.

Promouvoir Rétrograder

Le choix d'une approche multiplateforme ou native dépend en réalité de deux facteurs : la nature du développement mobile que vous souhaitez réaliser personnellement, ou la demande des employeurs avec lesquels vous souhaitez collaborer. Ainsi, par exemple, si vous regardez Upwork (une plateforme de recherche de spécialistes à distance pour des projets et des tâches), vous remarquerez une nette prépondérance d'offres en direction de Xamarin et React Native. Les avantages ici sont évidents : c'est bon marché, rapide et vous permettra de mettre en œuvre des projets sur toutes les plateformes à la fois. Cependant, si l'on considère les grandes entreprises informatiques qui recherchent des employés en interne, l'accent est mis sur le développement natif, malgré le fait que ce type prend plus de temps et coûte plus cher.

Dans notre entreprise, nous donnons la priorité et choisissons le développement natif car il permet aux concepteurs et aux développeurs de créer une UX/UI plus fluide et plus intuitive. De plus, le développement natif offre un contrôle plus flexible sur les fonctions du système.

Promouvoir Rétrograder

Si vous souhaitez devenir développeur mobile, la réponse est évidente : vous devez choisir l'un des environnements de développement natifs et vous appuyer sur Objective-C/Swift pour iOS ou Java/Kotlin pour Android. Dans ce cas, toutes les capacités du système sont à votre service ; vous pouvez contrôler presque toutes les nuances.

Si vous souhaitez simplement écrire un programme qui fonctionnera également sur les téléphones, vous n'avez pas besoin de trop réfléchir et de choisir ce qui vous passionne le plus ou dans lequel vous avez une expérience notable : C++, React Native, Xamarin ou cinq cent mille frameworks JS pour le développement multiplateforme. Ou même continuez à créer vos propres sites Web [responsive].

J'avoue que je suis assez sceptique quant à l'idée même du développement multiplateforme sur des plateformes aussi différentes (et divergentes) qu'Android et iOS. Aucun des fournisseurs n’apprécie les « mauvais » développeurs qui tentent de s’asseoir sur deux chaises en même temps. Tout le monde essaie de lier les programmeurs à des outils et à des environnements, et aucune tendance à la convergence ne peut être attendue dans un avenir proche. Que puis-je dire, Apple dans cette course a même abandonné OpenGL, la plus multiplateforme de toutes les bibliothèques après Curl, mais ils ont maintenant leur propre Metal, qui semble faire la même chose, mais en mieux et dans un langage différent.

D’un autre côté, le développement mobile implique très souvent la création de deux applications d’apparence identique pour un service réseau donné. Les clients ne sont pas toujours prêts à payer pour deux produits qui semblent totalement indiscernables, c'est pourquoi la demande de technologies de développement multiplateforme existe et, certes, est assez élevée. Les programmeurs ne sont pas non plus opposés à économiser de l'argent, surtout s'ils souhaitent vendre une application mobile et n'ont aucune envie d'apprendre Swift/Kotlin, mais JS/C# est déjà à leur portée.

Bien entendu, le développement multiplateforme apporte de nombreuses nuances non évidentes. Toutes les solutions universelles sont contraintes de construire des châteaux dans le sable : soit en s’appuyant sur des solutions technologiques complexes et fragiles (comme Xamarin), soit sur des moteurs JavaScript mobiles, comme React Native. Dans le même temps, les fournisseurs de plates-formes ne pensent même pas à prendre en charge aucune des solutions, et chaque mise à jour du SDK natif est un gros casse-tête pour tout framework multiplateforme. Sans parler de fonctionnalités spécifiques au système telles que l'accès à l'appareil photo, au trousseau ou même à une banale galerie de photos, que chacun essaie de contourner avec plus ou moins de succès. Les développeurs qui choisissent la voie universelle se retrouvent otages de leur framework, et souvent un développement qui promettait des économies significatives se transforme en une lutte avec un râteau.

Il est également courant que les solutions multiplateformes sacrifient ce que l'on appelle l'expérience utilisateur (UX) : de nombreux frameworks tentent d'utiliser des contrôles aussi généraux que possible pour les deux systèmes, et cette solution est presque toujours aussi gênante pour tout le monde. Ou ralentit. Ou bien cela se démarque du style général. Ou alors ça vide la batterie. Continuez la liste vous-même.

Se distinguent les applications multiplateformes dont les noyaux sont écrits à un niveau bas, le plus commun possible pour tous les systèmes d'exploitation : dans des langages comme C/C++. Dans ce cas, il est d'usage de généraliser l'utilisation de code au service de la logique métier, et l'interface est écrite séparément pour chaque plateforme. Idéalement, la duplication d’une partie critique de l’application serait évitée, tout en conservant une expérience utilisateur spécifique à la plateforme. Cependant, dans la vraie vie, tout est plus compliqué. Par exemple, Dropbox a essayé de vivre avec un noyau de bas niveau pendant plusieurs années consécutives, mais a finalement abandonné pour de nombreuses raisons et se contente désormais des applications de plate-forme natives. Je renvoie les personnes intéressées à leur article intéressant sur ce sujet.

À mon avis, les économies réalisées sur les frameworks multiplateformes sont toujours illusoires. Probablement, dans certains projets triviaux, où l'application n'est qu'une version du site principal, super optimisée pour les mobiles, l'approche généralisée fonctionne. Dans d'autres cas, vous risquez de répéter le sort de Dropbox. Mon conseil est que si vous souhaitez devenir développeur mobile, faites des efforts pour apprendre la plateforme. Ils seront toujours payants, même si vous devez participer à un projet multiplateforme.

Promouvoir Rétrograder

, développeur de logiciels senior chez Accenture Tver Technology Center

Le marché des applications mobiles se développe activement et la gamme de technologies permettant leur développement s'élargit en conséquence. Il existe de nombreux outils que vous pouvez utiliser.

Pour le développement natif sur Plateforme Android Il existe Java ou un wrapper sur la JVM - Kotlin. Pour iOS, vous pouvez utiliser Objective-C ou son wrapper - Swift. Ce sont tous des langages POO qui ont beaucoup hérité de Smalltalk et de C.

Pour le développement multiplateforme, ils utilisent actuellement Flutter de Google, pour lequel vous devrez connaître Dart. Ou React Native depuis Facebook.

Pour un développeur mobile novice, le facteur déterminant sera très probablement son expérience passée et sa connaissance des langues. Si sa boîte à outils est basée sur Java, il pourra explorer le monde du développement mobile beaucoup plus rapidement via la plateforme Android, en utilisant le même Java ou Kotlin.

Dans le même temps, le développement d'Objective-C pour iOS a beaucoup emprunté à Smalltalk, comme Java, donc si vous le souhaitez, vous pouvez faire un choix en faveur d'iOS. Mais il convient de considérer que le développement pour Android peut avoir lieu sous Windows ou Linux, mais iOS nécessite MacOS X. Mais pour un développeur JavaScript connaissant React, React Native est évidemment le moyen le plus rapide. Tout comme pour les développeurs Dart, le choix se portera en faveur de Flutter.

Une fois qu'un développeur novice aura une idée de ce qu'est le développement mobile et des avantages et des inconvénients de la voie choisie, il décidera lui-même s'il doit travailler avec une seule approche ou résoudre les problèmes en utilisant des solutions multiplateformes.

Cette approche a ses avantages : la méthode multiplateforme permet de sortir un projet dans un environnement productif un peu plus rapidement, en utilisant moins de ressources. De plus, il est plus facile à entretenir. Mais cela présente également des inconvénients évidents tant pour le développeur que pour l’utilisateur. Par exemple, un développeur n'a pas besoin de connaître les technologies natives, mais les directives de la plateforme doivent être prises en compte, car une application écrite selon les directives iOS entraînera des difficultés pour Utilisateurs Android et vice versa.

Les applications multiplateformes ne peuvent pas atteindre le même niveau d’intégration des appareils que les applications natives. Autrement dit, si l'application consiste à interagir avec un appareil, par exemple avec un appareil photo, un calendrier ou à utiliser la puissance de calcul de l'appareil, il est alors plus facile d'y parvenir en utilisant une approche native, et ce sera plus rapide et plus efficace. productif.

Lors du développement d'une application multiplateforme, les spécialistes prennent en compte les capacités du framework, qui impose des restrictions. Il convient également de considérer que pour développer un produit utilisant des technologies natives, des spécialistes sont nécessaires pour chaque plateforme.

Si vous travaillez en indépendant ou si vous avez un objectif à atteindre avec un minimum de ressources quantité maximale appareils, concentrez-vous sur le développement multiplateforme si vous vous concentrez sur les solutions mobiles ou si vous travaillez en tant que développeur front-end.

Quels sont les principaux avantages et inconvénients du développement mobile natif et multiplateforme ? Le développement natif lui-même est coûteux car l'entreprise doit investir dans deux équipes : iOS et Android. Pour les applications simples, la vitesse de développement avec Flutter/React Native est plus élevée.

Mais le plus est que l'infrastructure est déjà constituée et est compréhensible. Vous avez accès à toutes les ressources de l'appareil et pouvez développer sous montre intelligente, voitures et plus encore.

Le développement multiplateforme est également une bonne chose. Mais il n'est pas encore très développé sur le marché du travail informatique en Russie. Vous pouvez compter les spécialistes intelligents sur vos doigts. L'infrastructure-cadre est jeune, mais la situation évolue progressivement pour le mieux. Ce développement permet d'écrire pour plusieurs appareils à la fois. Même si vous écrivez dans Flutter, par exemple, il s'intègre facilement au code natif.

Promouvoir Rétrograder

Le développement multiplateforme vise des résultats rapides et des économies budgétaires significatives - nous écrivons un code pour tous les appareils. Son champ d'application est soit une solution à usage interne, où la convivialité du produit n'est pas si importante et où la fonctionnalité joue un rôle dominant, soit la création d'un projet « pilote » rapide, lorsque le client a besoin de montrer le principe ou idée de l'application. De plus, s'il n'y a pas de compréhension précise de l'appareil avec lequel le système d'exploitation sera visualisé votre prototype, le développement multiplateforme est la solution. Cependant, vous devez comprendre à l'avance que tous les appareils ont des architectures différentes, il est donc physiquement presque impossible d'exécuter une application de haute qualité en utilisant uniquement du code multiplateforme. Les scénarios complexes nécessiteront l’écriture de code natif. De plus, de par ses spécificités, le développement multiplateforme entraîne des coûts qui ne permettent pas à l'application d'être la plus efficace possible. Ceci est compréhensible ; dans ce cas, le code multiplateforme intermédiaire doit être traduit pour chacune des plateformes, ce qui rend l'application plus « lourde » du fait qu'elle contient, en plus du code fonctionnel, son environnement d'exécution.

Donnez-moi un autre avis

Tout est clair, montrez vos conclusions

Alors, quelle approche de développement adopter ?

Tout dépend de la tâche. Si vous devez écrire un prototype d'application pour plusieurs plates-formes ou version mobile site, vous pouvez alors vous tourner vers des frameworks multiplateformes. Avec leur aide, vous écrirez probablement une application plus rapidement qu'avec un développement natif, surtout si vous travaillez sur un framework similaire à votre outil habituel, tel que React Native.

D’un autre côté, la polyvalence des applications multiplateformes doit être compensée d’une manière ou d’une autre. Quelque part un élément d'interface « non natif » apparaît, quelque part l'interaction avec le système est pire, quelque part la vitesse de travail s'affaisse, etc. Malgré le fait que le développement natif nécessite plus de ressources, de nombreuses entreprises le préfèrent car le résultat est plus produit stable et d’aspect natif.

À cet égard, si vous débutez dans le développement mobile, il serait préférable de commencer par le développement natif. Vous pouvez trouver plus d’informations à ce sujet sur Internet, vous obtiendrez une compréhension plus approfondie des capacités de la plateforme et vous ne serez pas gêné par certaines nuances du développement multiplateforme. De plus, si vous décidez de vous lancer dans le développement multiplateforme à l'avenir, les connaissances acquises ne vous feront certainement pas de mal.

Nous vous rappelons que vous pouvez poser votre question aux experts, et nous rassemblerons les réponses si elle s'avère intéressante. Les questions déjà posées se trouvent dans la liste des problèmes. Si vous souhaitez rejoindre les rangs des experts et envoyer une réponse de votre entreprise ou de vous-même, alors écrivez à , nous vous expliquerons comment procéder.