ACTU
Epic contre Apple : la victoire d'Epic
par CBL,
email @CBL_Factor
La guerre entre Epic Games et Apple a débuté en août 2020 quand le premier a introduit son propre système de paiement dans Fortnite pour ne pas avoir à payer de commissions au second. Un an plus tard, une juge américaine demandait à Apple d'autoriser les systèmes de paiement tiers sur iOS mais la firme de Cupertino a traîné la patte. Les choses viennent de brutalement s'accélérer. La même juge vient d'ordonner à Apple d'autoriser les systèmes de paiement tiers (via une page web) sans toucher de commissions et avec interdiction de décourager la pratique.
Apple a fait appel mais, en attendant, a dû se plier à la décision de la juge et vient de changer les règles de l'App Store aux États-Unis. Spotify s'est jeté sur l'occasion et vient de sortir une mise à jour permettant de s'abonner au service sur iOS sans utiliser l'App Store et donc sans filer de thunes à Apple. On imagine que tout le monde va s'engouffrer dans la brèche. Tim Sweeney, le patron d'Epic Games, est évidemment aux anges et a annoncé que Fortnite serait de retour sur l'App Store américain la semaine prochaine. Il a aussi déclaré que, si Apple étendait ces nouvelles règles à l'échelle mondiale, il abandonnerait toutes poursuites et réintroduirait Fortnite dans tous les pays. Epic Games va aussi lancer son propre système de paiement.
On est donc entré dans un monde de plus en plus compliqué pour iOS. Aux États-Unis, les développeurs peuvent utiliser leur propre système de paiement sur l'App Store mais sont obligés de passer par la boutique d'Apple. En Europe, les règles de l'App Store restent rigides mais les développeurs peuvent passer par une autre boutique. Il est grand temps qu'Apple harmonise le tout et ouvre ses appareils pour de bon. Le gain en productivité pour les développeurs serait énorme. Autant Apple fait du très bon matos, autant la bureaucratie imposée pour développer dessus est délirante.
Mettons qu'un développeur A, appelons-le CBL, crée une application pour un client B. Quand CBL veut envoyer des builds au client, voici le processus qu'il doit suivre sur les principales plateformes :
Windows : CBL zippe le build, le colle sur un site sécurisé genre DropBox et envoie un lien avec mot de passe et date d'expiration au client. Ce dernier le télécharge sur sa machine, le dézippe et le lance. Il aura peut-être un message demandant "Êtes-vous sûr ?" mais c'est à peu près tout.
Android : CBL colle le build sur un site sécurisé genre DropBox et envoie un lien avec mot de passe et date d'expiration au client. Ce dernier active l'option "Unknown sources" sur son téléphone et ouvre le lien qui télécharge et installe directement l'appli sur son téléphone.
iOS/iPadOS : CBL doit acheter un Mac juste pour pouvoir développer sur iOS. Puis il doit payer 100 dollars par an pour devenir développeur iOS officiel. Ensuite, il doit créer un compte Apple Business Manager qui nécessite de prouver qu'on est une vraie entreprise. Puis il doit signer le build via un double système de certificats/profils lié à son compte. Le build est ensuite déposé sur les serveurs d'Apple. Puis il doit créer une appli sur l'App Store en précisant qu'elle est privée (et pas juste "non listée") et en rentrant tout un tas d'informations inutiles comme des descriptions et des captures de l'appli que personne ne verra jamais. CBL doit alors soumettre son appli en espérant que le type qui va la regarder ne se soit pas levé du mauvais pied. Une fois l'appli approuvée, il faut maintenant la distribuer. Si le client a aussi un compte Apple Business Manager, il se démerde mais sinon la solution simple consiste à générer des codes d'activation à envoyer au client.
Et tout cela pour quoi ? Uniquement pour empêcher les développeurs de sortir leurs applis sans passer par l'App Store. Ce n'est pas une question de sécurité : cette dernière est gérée par l'OS qui s'assure que les applis se lancent dans des environnements fermés et doivent demander patte blanche pour accéder à des données de type galerie photos. Même si CBL avait trouvé une faille dans le système, genre celle-là, rien dans la chaîne de validation n'aurait pu la détecter.
Apple a fait appel mais, en attendant, a dû se plier à la décision de la juge et vient de changer les règles de l'App Store aux États-Unis. Spotify s'est jeté sur l'occasion et vient de sortir une mise à jour permettant de s'abonner au service sur iOS sans utiliser l'App Store et donc sans filer de thunes à Apple. On imagine que tout le monde va s'engouffrer dans la brèche. Tim Sweeney, le patron d'Epic Games, est évidemment aux anges et a annoncé que Fortnite serait de retour sur l'App Store américain la semaine prochaine. Il a aussi déclaré que, si Apple étendait ces nouvelles règles à l'échelle mondiale, il abandonnerait toutes poursuites et réintroduirait Fortnite dans tous les pays. Epic Games va aussi lancer son propre système de paiement.
On est donc entré dans un monde de plus en plus compliqué pour iOS. Aux États-Unis, les développeurs peuvent utiliser leur propre système de paiement sur l'App Store mais sont obligés de passer par la boutique d'Apple. En Europe, les règles de l'App Store restent rigides mais les développeurs peuvent passer par une autre boutique. Il est grand temps qu'Apple harmonise le tout et ouvre ses appareils pour de bon. Le gain en productivité pour les développeurs serait énorme. Autant Apple fait du très bon matos, autant la bureaucratie imposée pour développer dessus est délirante.
Mettons qu'un développeur A, appelons-le CBL, crée une application pour un client B. Quand CBL veut envoyer des builds au client, voici le processus qu'il doit suivre sur les principales plateformes :
Windows : CBL zippe le build, le colle sur un site sécurisé genre DropBox et envoie un lien avec mot de passe et date d'expiration au client. Ce dernier le télécharge sur sa machine, le dézippe et le lance. Il aura peut-être un message demandant "Êtes-vous sûr ?" mais c'est à peu près tout.
Android : CBL colle le build sur un site sécurisé genre DropBox et envoie un lien avec mot de passe et date d'expiration au client. Ce dernier active l'option "Unknown sources" sur son téléphone et ouvre le lien qui télécharge et installe directement l'appli sur son téléphone.
iOS/iPadOS : CBL doit acheter un Mac juste pour pouvoir développer sur iOS. Puis il doit payer 100 dollars par an pour devenir développeur iOS officiel. Ensuite, il doit créer un compte Apple Business Manager qui nécessite de prouver qu'on est une vraie entreprise. Puis il doit signer le build via un double système de certificats/profils lié à son compte. Le build est ensuite déposé sur les serveurs d'Apple. Puis il doit créer une appli sur l'App Store en précisant qu'elle est privée (et pas juste "non listée") et en rentrant tout un tas d'informations inutiles comme des descriptions et des captures de l'appli que personne ne verra jamais. CBL doit alors soumettre son appli en espérant que le type qui va la regarder ne se soit pas levé du mauvais pied. Une fois l'appli approuvée, il faut maintenant la distribuer. Si le client a aussi un compte Apple Business Manager, il se démerde mais sinon la solution simple consiste à générer des codes d'activation à envoyer au client.
Et tout cela pour quoi ? Uniquement pour empêcher les développeurs de sortir leurs applis sans passer par l'App Store. Ce n'est pas une question de sécurité : cette dernière est gérée par l'OS qui s'assure que les applis se lancent dans des environnements fermés et doivent demander patte blanche pour accéder à des données de type galerie photos. Même si CBL avait trouvé une faille dans le système, genre celle-là, rien dans la chaîne de validation n'aurait pu la détecter.
Commentaires