Ce que j’ai appris: En créant ma première application mobile

· Blishikata Blog

Ce que j’ai appris: En créant ma première application mobile #

Origine de l'idée #

Quand j'avais 14 ans, mon style de jeu favori c'était le roleplay. À l’époque, les serveurs RP sur Minecraft, GMod ou GTA faisaient fureur. Les vidéos RP sur le sujet débarquaient à foison sur YouTube avec des centaines de serveurs RP ouverts, de quoi occuper nos week-ends… Pourquoi je vous raconte cela ? Car cette nostalgie m'a donné les premières idées d'app que je voulais créer.

À l'époque, il y avait des dizaines de serveurs ouverts, mais tous n'avaient pas autant de joueurs que les autres, cela varie en fonction des jours ou des évènements en jeu. Pour me décider sur quel serveur jouer, je devais lancer chaque modpack Minecraft, lancer GMod etc pour savoir sur quel serveur il y avait du monde. Je perdais dix minutes juste à chercher un serveur actif. La plupart des serveurs n'ont pas de site internet ou un Bot Discord pour donner le nombre de joueurs connecté. La majorité des cas, c'était manuel.

Et à chaque fois je me disais: Ce serait bien une app qui permet de connaître l'état de ses serveurs favoris en un seul clic.

Premiers pas techniques #

Lors de mes études d'IT, j'ai commencé à apprendre le développement web, et les joies de faire du JavaScript/TypeScript. J'ai débuté par faire des bots Discord, puis j'ai ensuite découvert ExpressJS et c'est là que j'ai commencé à faire mes premières API. Je vous le donne en mille sur quelle API j'allais me concentrer….. Une API qui permettait de tracker des serveurs Minecraft, Source et FiveM. Sauf que ce que j'ai un peu honte à avouer, c'est que toute la logique pour contacter le serveur, ce n'est pas moi qui l'ai développée, c'était une librairie externe téléchargée sur NPM. Sur GitHub, on pouvait retrouver des packages dédiés pour faire des requêtes pour Minecraft Java / Source.

La seule chose qui était de ma main c'était pour les réponses en provenance des serveurs FiveM, mais même jusqu'ici, cela n'avait rien de compliqué. La communication est un simple appel HTTP (j'y reviendrai). Pour débuter dans l'apprentissage de comment faire une API c'était un bon départ mais j'avais conscience que le projet manquait un peu de challenge. Par contre faire la même chose pour une application mobile sans librairie externe, c'est plus intéressant comme défi. Voilà que je me suis donné un nouveau défi: Faire une app iOS.

Depuis enfant, j'étais déjà fasciné par Apple et je voulais faire une application iOS. Mais je n'avais jamais trouvé le déclic de le faire auparavant. Après avoir terminé mon API pour tracker les serveurs (qui existe toujours: gameservertracker.io), l'idée de faire une application mobile me venait en tête.

Sauf que j'ai passé beaucoup de temps dans ma tête à me demander:

En bref…je perdais mon temps à faire des plans alors que je n'avais même pas créé le projet sur GitHub.

Très récemment, j'ai lu le bouquin de Mark Manson: "L'Art Subtil de S'en Foutre". Il y a une phrase que j'ai notée qui aurait dû être mon premier réflexe:

"Ne reste pas assis là, fais quelque chose, les réponses vont suivre"

Apprentissage du Swift #

En décembre 2024, je décide de m'offrir un Mac pour Noël et c'est à ce moment que je me dis:

Au prix où tu l'as payé autant le rentabiliser. Tu n'as plus aucune excuse pour ne pas apprendre le développement mobile sur iOS.

Dès le début de l'année 2025, je me suis mis à apprendre le développement mobile.

Pour le choix du langage, je suis parti sur du Swift. Étant un fan de l'écosystème Apple. D'autant plus qu'il y a de fortes chances que je n'aie pas de package dédié pour faire les requêtes, je vais devoir les faire moi-même, me rajoutant du challenge.

Maintenant, il ne restait plus qu'à regarder un cours "How to develop in Swift". Je suis tombé par hasard sur la chaîne d'un YouTubeur américain qui se nomme Sean Allen, qui a rendu publiques sur YouTube ses différentes formations pour apprendre le langage Swift. Un cours de 17 heures sur les bases du langage Swift, UIKit et SwiftUI avec comme projet de réaliser un UberEats like. Il m'aura fallu plusieurs mois de pratique le soir et le week-end pour terminer les leçons.

Le lendemain après avoir fini le bootstrap, le 10 mai 2025, je débutais le développement de ma première application iOS, nom de code: GamePing.

Début de GamePing #

Quand j'ai commencé, je ne voulais pas me décourager en me disant que j'allais faire les choses les plus compliquées direct pour qu'au final j'abandonne par flemme. J'ai décidé de partir sur 2 lots avant de sortir l'app.

Le premier lot consistait à faire une app qui se contenterait d'utiliser mon API existante pour récupérer les infos sur les différents serveurs. L'idée est d'avoir un début de prototype fonctionnel qui soit un minimum présentable.

Le lot numéro 2, consiste à ce que l'app ne soit dépendante d'aucune API tierce, mais que ce soit le téléphone qui fasse les communications UDP/TCP aux différents serveurs.

Soudain une question me vient à l'esprit:

Est-ce que mon idée n'existe pas déjà ? Est-ce que je ne vais tout simplement pas réinventer la roue ?

En cherchant dans l'App Store, il existe effectivement déjà des apps destinées à tracker les serveurs Minecraft Java/Bedrock, chacune plutôt bien notée. Cependant, une app iOS qui track les serveurs comme GMod / Counter Strike / GTA 5, il n'y en a pas une seule.

Parfait, on va faire pareil mais en mieux et avec plus de possibilités. Voilà comment c'est parti…

Pour le design ? Pour rester simple, je suis resté sur un design propre à la charte graphique d'Apple tout en essayant de faire quelque chose de pas trop ressemblant. Ne pas faire comme toutes les apps de l'époque qui utilisaient MaterialUI, c'est-à-dire se ressemblaient toutes et essayer d’avoir notre touche. Au fil de la conception, je me suis inspiré de l’App Store qui correspondait à ce que je recherchais. Cela m'a permis de me challenger à cloner l’interface d'une app d'Apple.

poc 1 poc 2
Première version du premier lot

Et le 17 juillet à 22h30, le premier lot de l'application est terminé. Il était fonctionnel, on pouvait ajouter des serveurs, voir le nombre de joueurs connectés, voir la version, etc.

Pas mal, mais ce n’est que le début. En effet utiliser une API comme intermédiaire a ses limitations:

D'autant plus que les autres apps dans le même style font les communications réseaux eux-mêmes, sans intermédiaire.

Il était enfin temps d'attaquer le lot numéro 2, et comprendre comment le client in-game communique avec un serveur.

Apprentissage du réseau #

La dernière fois que j'ai appris à faire du développement réseau, c'était lors d'un devoir d'école, on devait faire une sorte de Microsoft Teams en CLI mais avec seulement la partie message écrite en TCP/IP et avec le langage C. Le concept du réseau ne me semblait pas si compliqué, mais c'était la première fois que j'allais utiliser des protocoles réseau officiel.

Avant d'implémenter les communications réseau sur l'application, j'ai créé en parallèle un client TCP/UDP en CLI pour apprendre l'utilisation du réseau en Swift via NWConnection. NWConnection une classe Network en Swift développée par Apple annoncée en septembre 2018, afin de faciliter la tâche au développeur de faire les communications en TCP/UDP. Et c'est le cas, en un samedi, je me retrouve avec un petit client CLI pour envoyer et recevoir des messages. Il ne restait plus qu'à communiquer avec les serveurs.

Lors de mes travaux, j'ai utilisé 3 protocoles:

Source Engine #

Une des forces du moteur Source, c'est que tous les serveurs privés de n'importe quel jeu utilisant Source comme moteur, utilisent le même protocole de communication pour le multijoueur, ce qui ouvre la possibilité de communiquer avec des serveurs d'une vingtaine de jeux (Half Life, Counter-Strike, Team Fortress, Rust, Garry's Mod, et j'en passe).

Second point majeur, Valve le créateur du moteur Source est très ouvert sur la façon dont les jeux communiquent avec les serveurs. Ils nous mettent à disposition une documentation très qualitative sur la manière dont les communications sont faites.

1Requête query vers un serveur CS:GO 2
2
3FF FF FF FF 49 02 67 61 6D 65 32 78 73 2E 63 6F    [ÿÿÿÿI.game2xs.co](http://ÿÿÿÿI.game2xs.co)
46D 20 43 6F 75 6E 74 65 72 2D 53 74 72 69 6B 65    m Counter-Strike
520 53 6F 75 72 63 65 20 23 31 00 64 65 5F 64 75     Source #[1.de](http://1.de)_du
673 74 00 63 73 74 72 69 6B 65 00 43 6F 75 6E 74    st.cstrike.Count
765 72 2D 53 74 72 69 6B 65 3A 20 53 6F 75 72 63    er-Strike: Sourc
865 00 F0 00 05 10 04 64 6C 00 00 31 2E 30 2E 30    e......dl..1.0.0
92E 32 32 00                                        .22.

Minecraft Java Edition #

Contrairement à Valve, Mojang ne nous explique pas officiellement comment la communication fonctionne, mais le wiki communautaire le plus connu Minecraft Wiki, a une section entièrement dédiée sur la communication multijoueurs entre le client & le serveur.

Contrairement à Source, la communication utilise le TCP au lieu de l'UDP. Il s’agit d’un simple “handshake” dans lequel le serveur nous retournera un JSON à traiter, ce qui nous épargne de devoir décortiquer les paquets bytes par bytes.

 1{
 2    "version": {
 3        "name": "1.21.8",
 4        "protocol": 772
 5    },
 6    "players": {
 7        "max": 20,
 8        "online": 1,
 9        "sample": [
10            {
11                "name": "cakeless",
12                "id": "0541ed27-7595-4e6a-9101-6c07f879b7b5"
13            }
14        ]
15    },
16    "description": {
17        "text": "Hello, world!"
18    },
19    "favicon": "data:image/png;base64,<data>",
20    "enforcesSecureChat": false
21}

Minecraft Bedrock Edition #

À la différence des autres, la version Bedrock de Minecraft n'utilise pas un seul protocole de communication, elle en utilise 3:

Celui qui nous intéresse est Raknet, un protocole propriétaire. Raknet était une librairie réseau propriétaire développée par Jenkins Software LLC utilisée dans divers jeux cross-platform début 2000. Depuis son rachat par Oculus en 2014, le code source est depuis disponible gratuitement sur GitHub.

Pour récupérer les infos utiles un simple message en UDP suffit pour obtenir, le nom du serveur, la version, le nombre de joueurs, etc.

10x01 | client alive time in ms (unsigned long long) | magic | client GUID
2
30x1c | client alive time in ms (recorded from previous ping) | server GUID | Magic | string length | Edition (MCPE or MCEE for Education Edition);MOTD line 1;Protocol Version;Version Name;Player Count;Max Player Count;Server Unique ID;MOTD line 2;Game mode;Game mode (numeric);Port (IPv4);Port (IPv6);

FiveM #

Pour FiveM c'est plus simple, une simple requête HTTP à faire qui nous renvoie un JSON. Les serveurs ont des routes dédiées en fonction des infos qu'on veut récupérer:

En autre le call API est une simple formalité. Mais à un détail près… Si vous avez eu l'œil, la communication se fait en HTTP pas en HTTPS (avec la couche de chiffrement TLS), ce détail peut paraître anodin mais sur iOS c'est problématique.

Au lancement de iOS 9 en septembre 2015, Apple introduit App Transport Security (ATS) dans le but d'améliorer la sécurité et la vie privée des utilisateurs. Ce système impose que toutes les requêtes soient faites en HTTPS. Cette restriction pouvait être désactivée, mais depuis janvier 2017 Apple refuse toutes les apps n'utilisant pas le HTTPS. Problème, les serveurs FiveM n'utilisent pas le HTTPS, rendant impossible la communication entre le téléphone et le serveur.

La seule façon de contourner cette contrainte était de passer par une API en HTTPS en guise d'intermédiaire pour nous restituer la réponse du serveur. En d'autres termes, on en revient au premier lot que j'avais développé au départ. Cette solution est navrante car c'est ce qu'on peut qualifier d'un point critique pour l'app si l'API tierce tombe soudainement en panne mais tant pis, au moins on aura quelque chose de fonctionnel et viable.

La partie la plus longue de mon apprentissage aura été le décodage des réponses du serveur. En fonction de la réponse reçue, je devais gérer différents data types que ce soit des Integer (8/16/32/64 bits) ou des strings. Mais aussi la gestion des paquets, en fonction du serveur, je pouvais recevoir une réponse fragmenté à reconstruire ou bien je devais renvoyer un paquet bien précis pour m'authentifier au serveur. Le langage Swift n’a pas été un frein pour implémenter la partie réseau. Il a un type dédié pour tout ce qui est les bytes buffer ce qui facilite grandement le traitement. D'autant plus qu'avec la notion des 'extensions' je peux rajouter des méthodes personnalisées au type Data pour gérer des cas spéciaux.

Je ne pensais pas que décoder un paquet réseau me ferait autant galérer, mais quand j’ai enfin vu la réponse s’afficher sur l’application, c’était la meilleure sensation du monde. Je venait de terminer le lot numéro 2.

lot 2 image 1 lot 2 image 2
Deuxième lot

Logo & Liquid Glass #

Le logo, alias la première interaction entre l'app et l'utilisateur. L’objectif: Réussir à faire comprendre à l'utilisateur ce que l'app fait dans un petit carré arrondi sans que cela soit atrocement moche.

La conception du logo a débuté le 13 juin 2025. Trois jours avant, Apple lors de la WWDC 2025 venait d'annoncer un gros changement dans son écosystème, "Liquid Glass".

Ce jour-là, en me promenant sur X, je suis tombé sur un tweet d'un développeur iOS qui parlait d'un outil qu'Apple avait conçu pour l'occasion: "Icon Composer". Un outil dédier à aider les développeurs à adapter leur logo pour le Liquid Glass.

Icon Composer
Icon Composer

Étant très curieux de cet outil, j'ai sauté sur mon Mac pour le télécharger afin de l'essayer. Mais…petit bémol, je n'ai pas de logo… Alors j'ai réduit la fenêtre du logiciel et j'ai ouvert le bloc-notes pour brainstormer sur de quoi sera composer le logo.

Pour l'élément principal, j'ai mis un serveur pour représenter le serveur de jeu, un petit cube regroupant trois racks de serveur en marche. Pour l'élément secondaire qui signifie le gaming, le fait que cette app te permet de connaître le statut d'un serveur sans que cela soit une app principalement dédiée à l'Administrateur du serveur lui-même est d'autant plus compliqué.

Pour représenter l'élément second, deux idées m'étaient venues en tête pour représenter cela:

Après plusieurs essais voici à quoi ressemblaient les premiers prototypes:

Première version du logo
Première version du logo

Le premier logo fut mon premier essai sur Figma et sur Icon Composer.

Pour conceptualiser l'élément principal du logo, je suis allé sur Flaticon pour trouver de l'inspiration. Une fois que j'ai trouvé une forme de serveur qui me convenait, il ne restait plus qu'à la concevoir sur Figma. Concernant la manette de jeu, ayant des bases novices sur Figma, je suis parti sur une manette de NES, un design simple à réaliser et qui parlera à tout le monde.

J’avais aussi imaginé une alternative où la manette était remplacée par des utilisateurs, je m'étais inspiré des icônes utilisées sur le Xbox Live pour représenter les amis

LIVE Zune
Inspiration des différentes icônes d'amis sur Xbox.

Après avoir fait différents essais sur l'app, je suis finalement parti sur la seconde version, qui rendait beaucoup mieux que ce soit en mode clair, sombre ou transparent.

Version finale du logo
Version finale du logo

Une fois la version finale du logo terminée, il suffisait de glisser le fichier de Icon Composer sur Xcode pour qu'il soit pris en charge automatiquement. Il m'aura fallu 5 soirées pour concevoir le logo de GamePing.

Déploiement sur l'App Store #

Le dernier commit avant la publication a eu lieu le dimanche 31 août 2025 vers 20h, GamePing 1.0 allait être publié sur l'App Store. Je redoutais cette partie, car travaillant actuellement dans une entreprise dans laquelle l'application mobile joue un rôle clé sur nos produits, je recevais souvent les mails du résultat de la soumission de l'App et les nombreux cas à régler ou à justifier pour être en conformité.

Quand vous déployez une app pour la première fois, vous devez remplir une dizaine de formulaires en tout genre:

Si ce n'était que ça cela serait passager. Mais ensuite il faut faire un parcours de A à Z pour tester à l'examinateur pour évaluer notre app. Dans le passé, j'avais soumis des applications pour l'App Messenger afin que le client puisse communiquer avec un chat-bot. C'était le même principe, il fallait partir du principe que vous expliquez le fonctionnement de l'app à une grand-mère située dans la Creuse, car eux ne vont pas le deviner pour vous. Si ils ne comprennent pas quelque chose….RECALÉ ! En bref, dans la case explication, vous devez littéralement écrire un manuel d'utilisation.

Mais la partie la plus difficile à laquelle il ne faut pas faire d'erreur, c'est la vitrine de votre application. Vous voyez la phrase: "Vendez-moi ce stylo", c'est la même chose, vous devez donner envie à l'utilisateur de télécharger votre app. Sur l'interface, vous devez renseigner:

Mais l'info la plus importante de toutes, les keywords. Ils permettent à un utilisateur de tomber sur votre app dans la barre de recherche même s'il ne connaît pas votre application. Exemple, si un utilisateur cherche une app pour traquer des serveurs pour Counter-Strike Global Offensive 2, il va probablement chercher ça: "CSGO server / cs server track"

Vous êtes limité en termes de mots-clés, alors le choix doit être fait intelligemment. Après Apple est indulgent, si on tape le nom de votre app ou le nom du développeur, logiquement on vous trouve direct.

Ces infos ne doivent pas être prises à la légère car contrairement à une vidéo sur YouTube, Apple ne vous laisse plus toucher à ces informations dès que l'app est publiée. Il faudra re-soumettre l'application.

Lors de ma première soumission, j'ai attendu 48h pour avoir une réponse… recalé.

Apple Answer
Réponse d'Apple

Quand vous êtes recalé, Apple vous envoie un rapport par mail et une capture d'écran pour vous montrer le problème. Dans mon cas, le testeur avait mis une adresse invalide, qui a déclenché un statut dans NWConnection que je n'avais pas géré, ce qui en conséquence a fait que l'app charge dans le vide. Finalement, le temps de corriger tout cela, la publication a été reportée pour le 9 septembre. Ironie du sort, c'était le jour de la Keynote d'Apple.

Après 5 mois de travail, le mardi 9 septembre 2025 à 20h17, je déployais "GamePing" sur l'App Store, ma première application mobile.

Apple Answer
Page de GamePing sur l'App Store

Au lancement, l'application n'était pas encore adaptée pour iOS 26 qui était sorti le 15 septembre 2025, il faudra attendre 4 jours pour que GamePing 1.0.1 sorte avec une intégration de Liquid Glass.

Conclusion #

Après neuf mois d'apprentissage, mon idée d'application a enfin vu le jour. GamePing ne deviendra sans doute pas l’app du siècle. Mais elle m’a appris plus que n’importe quel cours : Swift, le réseau, la persévérance, et surtout, à passer de l’idée à l’action. C'était vraiment le challenge que je voulais accomplir, je ne voulais pas faire quelque chose qui se contente d'aller chercher l'info sur un service tiers, j'ai voulu me donner du challenge dans un domaine auquel je n'étais pas à l'aise au départ.

Si une idée vous trotte dans la tête, ne restez pas bloqué à tout planifier : lancez-vous, les réponses viendront en chemin.

L'idée de partir sur des lots est une bonne stratégie pour garder la motivation sur le projet. Cela vous permet de rendre votre résultat moins difficile à atteindre et de vous procurer des petites victoires à chaque nouvelle tâche, vous rendant ainsi plus satisfait et vous motivant encore plus à avancer.

Bref, en partant d'une idée de joueur Roleplay nostalgique, j'ai appris le développement mobile.

#ios #swift #development #mobile-app #gameping #networking #api #game #game query
last updated: