Faut-il "abandonner" Windows Phone 7 pour développer pour Windows Phone 8 ?

Avec la sortie de Windows Phone 8, puis 7.8 et aussi surtout des annonces concernant la date de fin du support de Windows Phone 7.8 et Windows Phone 8  c’est donc tout naturellement que beaucoup d’éditeurs et de développeurs Microsoft se sont posés cette question: faut-il arrêter de développer pour cibler Windows Phone 7.8 ? Entre partage de code, portabilité et compatibilité, à cette question, nous pourrions répondre oui. Mais sous conditions.

Windows Phone 8 est un système jeune, disponible depuis peu de temps (5 à 6 mois). Si ce nouveau système a beaucoup séduit, les premières années de Windows Phone auraient suffi également à faire en sorte que beaucoup d’appareils sous 7.1 (et donc avec mise à jour, 7.8) circulent. Si leur nombre total n’est pas vraiment publiquement annoncé, les premiers chiffres rassurent quant à l’adoption de la plateforme. Il est vrai toutefois, qu’il est impossible de savoir avec certitude si le nombre de téléphones sous Windows Phone 7/7.8 est supérieur au nombre de téléphones sous Windows Phone 8. Enfin, presque.

Rares sont les développeurs qui communiquent sur leurs statistiques de téléchargement. Cependant, être du milieu confère quelques avantages qui révèlent ceci :

Pour une même application existante pour Windows Phone 7 et Windows Phone 8, la quantité de sessions actives est en moyenne, beaucoup plus importante sous Phone 7 que sous Phone 8. Ce pourcentage est d’environ de l’ordre de 70 % de WP7 / 30 % de WP8 (moyenne calculée sur les statistiques données par les développeurs de la communauté Facebook Windows Phone)

Certes, Windows Phone 8 est récent, il y a une flotte « 7 » qui existe déjà, mais, cela suffit à dire que dans la population existante, nombreux sont les appareils sur la version 7 du système.

En résumé, il serait vraiment judicieux d’avoir une version Phone 7 de son application, ce n’est pas une cible à ignorer. En tout cas, pour le moment.

Il faut avouer que de l’ensemble des environnements de développement existants, ceux de Microsoft sont vraiment des outils excellents facilitant à partir d’un seul projet, le partage de code entre plusieurs versions de l’application. 

Microsoft Visual Studio 2012 + Portable Library + Project Linker (+ MangoPollo) .

Le tout arômatisé d’un peu de patience. (Mais aussi d’une bonne architecture réfléchie).

L’idée de cette chronique n’est pas d’entrer pour le moment dans le détail de l’utilisation de ces outils, des techniques, mais de pousser le lecteur dans les réflexions appropriées et de le guider vers les bonnes décisions.

L’expérience acquise dans le domaine m’a révélé 2 aspects essentiels au bon déroulement du développement « multiplateforme téléphone WP7/WP8 », aspects auxquels il convient de réfléchir avant de démarrer/poursuivre le développement : un aspect technique et un aspect business.

Dans le cas ou votre application doit utiliser des fonctionnalités propres à Windows Phone 8, il faut pouvoir trouver des équivalents ou des alternatives fonctionnelles. Prenons deux exemples.
Cas du NFC

Dépendant de l’utilisation faite de cette fonctionnalité, elle peut parfois être remplacée par d’autres moyens (un QRCode par exemple sauf si le NFC est utilisé pour partager un fichier, dans ce cas, utilisation de services …).

L’achat in-app est natif sous Windows Phone 8 et pas disponible pour Windows Phone 7.8. Il existe d’autres solutions pour Windows Phone 7 (Movend). Mais qui présente des inconvénients : la gestion des produits in-app se situe au niveau du système de Movend et non plus au niveau du compte développeur. Le partage de code est ici rendu plus difficile.

Vous l’aurez compris, l’aspect technique revient à réfléchir sur les fonctionnalités présentes sur l’une des plateformes qui peuvent avec ou pas beaucoup de difficultés, être présentes sur l’autre. Selon ce qu’il est possible d’être fait ou pas, vous commencerez à voir les intérêts d’avec le second point, l’aspect business.

C’est souvent un des aspects les plus contraignants, décisifs. Il tourne autour du facteur « temps » et du facteur « argent ».

Créer une application Windows Phone 7 et en faire une version Windows Phone 8 reste une opération relativement simple, peu couteuse. Elle repose essentiellement sur le partage de code et aussi l'écriture de code commun.

Rajouter des fonctionnalités spécifiques à la version Windows Phone 8, trouver les équivalentes pour Windows Phone 7, puis maintenir chaque version demandera un coût lié au rapport temps/argent (beaucoup de réflexions au préalable).

Si vous souhaitez rajouter des fonctionnalités d’achat in-app pour votre version WP8, et ne pas utiliser l’alternative (movend par exemple) pour Windows Phone 7, il va falloir réfléchir à un modèle de monétisation différent pour chaque version de votre application. Et etc… Cela peut aller très loin. Par exemple, imaginer la possibilité d’avoir une application gratuite avec des produits in-app dans la version 8 de votre application, et une application complètement payante sous Windows Phone 7.

Si les ressources ne vous le permettent pas, vous pouvez faire le choix de maintenir l’application Windows Phone 7 pendant quelques temps, puis de vous arrêter, un jour. Car, il faut avouer, lorsque les développeurs sont seuls, la maintenance d'une application puis plusieurs demande énormément de temps, un réel engagement. 

Attention : Si vous deviez prendre cette décision d'arrêter le support de la version 7, il est impératif de prendre le temps de l’expliquer aux utilisateurs.

Si vous partez d’une nouvelle application, il est judicieux (et plus simple) de commencer par la version Windows Phone 7, l’intégralité des contrôles, fonctionnalités de Phone 7 étant au moins supportées sous Phone 8 (excepté le contrôle de cartographie qui a un peu changé et qui demandera un petit effort pour être commun aux 2 projets).

Si vous partez d’une application existante sous Windows Phone 7, les conseils précédents sont toujours valables.

Si vous partez d’un projet Windows Phone 8 et que vous avez utilisé des fonctionnalités spécifiques, vous risquez d’avoir un peu de travail. Sans que cela ne soit complètement impossible.

S’il s’agit d’un jeu créé pour Windows Phone 8 spécialement (DirectX), le partage de code est à oublier complètement, DirectX n’étant pas supporté par l’ancienne version de l’OS. Par contre, si c’est un jeu créé spécialement pour Windows Phone 7 (XNA), la compatibilité étant assurée. Ce sera malheureusement, le point noir en terme de partage de code et les jeux.

S'il s'agit de partager du code entre 2 applications Windows Phone de versions différentes, cela reste simple (sauf pour les jeux) dans la mesure ou la très grande majorité du code n'aura pas besoin d'être réécrite ou adapté. Maintenant, s'il faut pouvoir partager du code avec une application Windows 8, cela demandera un peu plus de travail. (Probablement l'objet d'un autre article)

Microsoft a mis en place un très bel écosystème permettant aux développeurs de pouvoir rendre disponibles leurs applications sur le maximum d’appareils et sur plusieurs versions de Windows Phone. Même si vous n’êtes pas vraiment convaincus, cela constitue un excellent exercice pour anticiper les prochaines évolutions du système ou tout simplement, pour être bien présent aujourd'hui. Alors, maintenant, quels sont vos projets ?