C'est une bonne question. J'ai récemment dû y répondre moi-même. Je devais développer une application à la fois pour iOS et Android et j'avais besoin d'une solution pour partager la logique d'entreprise et de vue entre les deux applications. Au final, j'ai décidé d'utiliser React Native plutôt que Go pour plusieurs raisons que je vais expliquer ci-après. Il y a aussi des cas où je choisirais Go plutôt que d'autres solutions, mais nous y reviendrons plus tard.
Passons en revue les possibilités :
Application tout en Go
Vous perdez tout ce que les Frameworks fournissent et devrez réécrire beaucoup de choses qui sont déjà là. Cela pourrait être une solution si vous voulez développer un jeu mais je dirais que vous feriez mieux d'opter pour Unity ou d'autres frameworks spécifiques aux jeux.
Native iOS/Android + logique Go partagée
Au début, cela semble bien. Écrire la logique métier une fois et juste invoquer dans votre code natif. Cela fonctionne très bien mais a quelques limitations. Par exemple, vous ne pouvez pas "exporter" des tranches de structs. Nous présentons généralement des listes de données dans les applications, c'est donc le premier obstacle. Ce dont vous avez besoin, c'est d'une sorte de "couche de communication" entre native et go. Cela implique également la sérialisation et la désérialisation. Cela signifie que vous devrez écrire du code natif (Obj-C/Swift/Java) pour communiquer entre vos vues et la logique métier. Le deuxième obstacle est que vous devrez dupliquer la logique des vues. À ce stade, j'ai abandonné l'idée d'utiliser Go pour les applications. Les frameworks comme react native résolvent exactement ce problème. Avec react native, vous pouvez échanger les performances contre une vitesse de développement et de maintenance. Avec Go, vous devrez écrire deux fois votre logique de vue et connecter deux fois votre vue à la logique/état. Si votre équipe est assez grande, cela pourrait être une solution pour vous.
Cross Platform SDK's
C'est là que je vois actuellement Go briller. Si par exemple vous fournissez une api et que vous voulez développer un SDK multiplateforme pour les autres, Go est une excellente solution. Vous serez bien sûr confrontés aux mêmes problèmes que dans toutes les applications Go, les tranches. Cependant, comme vous n'avez pas à vous occuper de la logique de vue, Go peut être une solution idéale pour gagner du temps. Vous pouvez facilement intégrer le transport http, les websockets, la gestion des bases de données, etc. dans le SDK.
En fin de compte, j'ai décidé d'utiliser react native pour mon projet. Mes vues sont principalement des listes de données et j'ai besoin de la navigation. Je suis heureux de troquer un peu de performance pour la vitesse de développement.
Je ne suis pas dans les détails mais si go mobile surmonte le problème de la tranche, il serait beaucoup plus utile à beaucoup de gens. Cela étant dit, je pense que Go ne s'améliorera jamais quand il s'agit de partager la logique de vue, donc cela dépend vraiment de votre cas d'utilisation si vous voulez utiliser Go dans votre projet d'application.