Rejets 4.3 de l’App Store : être premier donne-t-il un avantage ?

Que signifie la règle 4.3 de l’App Store d’Apple ?

La règle d’Apple sur le spam couvre deux problèmes liés. La section 4.3(a) vise le fait de soumettre la même app sous plusieurs Bundle ID, par exemple en créant une app de plan distincte pour chaque ville. La section 4.3(b) vise les apps pratiquement impossibles à distinguer des offres existantes. Dans les catégories établies, Apple exige une « expérience sensiblement différente ou améliorée ». Ses exemples comprennent les apps de rencontre, les apps de fonds d’écran et les minuteurs simples.

Je comprends l’objectif. Prendre le produit de quelqu’un d’autre, changer les couleurs et le soumettre sous un autre nom crée du travail pour les examinateurs et du désordre pour les clients. En produire cent variantes ne le rend pas plus utile. Apple prévient lui-même que des soumissions essentiellement identiques consomment la capacité de l’App Review.

L’échelle est considérable. Dans sa mise à jour de mai 2026 sur l’App Store, Apple a indiqué avoir examiné plus de 9,1 millions de soumissions en 2025 et en avoir rejeté plus de 371 000 pour copie d’autres apps, spam ou tromperie des utilisateurs. Cette catégorie combinée compte des soumissions, pas des apps uniques rejetées spécifiquement au titre de la règle 4.3. Elle ne nous dit pas à quelle fréquence des apps légitimes ont été rejetées par erreur.

L’IA complique les choses, car il n’est plus nécessaire d’acheter un modèle pour reproduire un produit familier. On peut écrire une implémentation indépendante d’essentiellement la même expérience. Posséder le code ne rend pas automatiquement le résultat sensiblement différent.

J’utilise l’IA pour créer des logiciels. Elle peut aider les développeurs à résoudre des problèmes techniques difficiles et à servir des clients négligés. Elle peut aussi rendre moins cher d’inonder une place de marché d’apps à peine différenciées. Les outils rendent les deux possibles ; la qualité du résultat compte toujours.

Pourquoi des développeurs contestent-ils les rejets pour spam au titre de la 4.3 ?

Un constat de similarité peut être difficile à contester quand le développeur ne voit pas ce qu’Apple compare. Des témoignages publics récents montrent combien il peut être difficile de démontrer ce qui différencie une app, surtout quand sa valeur repose sur un flux de travail spécialisé.

Sebastian Röhl, développeur de FocusKit, a signalé deux rejets au titre de la 4.3(a) avant le lancement de son minuteur de concentration en novembre 2025. Plusieurs jours d’échanges pour expliquer ses différences ont mené à l’approbation. C’est une issue encourageante, mais démontrer qu’une app mérite d’être admise a demandé du travail supplémentaire avant que les clients puissent l’essayer.

En septembre 2026, le développeur de YanPian a signalé un rejet au titre de la 4.3(a) pour une app de vidéo d’escalade. Parmi ses fonctions figuraient la synchronisation des données de fréquence cardiaque de l’Apple Watch avec les images d’escalade, le suivi d’un grimpeur dans un plan large et un contrôle optionnel de stabilisateur. Le développeur a reconnu que, sans images d’escalade à importer, l’écran d’accueil pouvait ressembler à une app photo générique. Le fil public rapporte un appel sans résolution publiée.

Ces témoignages n’établissent pas qu’Apple a rejeté chaque app parce que sa catégorie était pleine. Nous n’avons pas non plus les dossiers de révision complets d’Apple. Ils montrent en revanche combien il peut être difficile de comprendre ce qu’on demande à un développeur de prouver.

La situation de YanPian me fait penser à Dumpling. Une app spécialisée peut partager ses ingrédients de base avec une app généraliste tout en faisant des choix différents sur la façon dont ils fonctionnent ensemble. Reconnaître ces choix peut exiger de suivre un flux de travail précis ou de comprendre le problème qu’elle résout. C’est un jugement plus difficile que de vérifier si une app plante.

Les règles anti-spam de l’App Store avantagent-elles les premiers arrivés ?

Je pense que oui, potentiellement. Une app qui arrive dans une catégorie relativement ouverte a moins de produits établis par rapport auxquels juger sa singularité. Un arrivant plus tardif peut devoir expliquer en quoi son approche diffère assez d’un ensemble croissant d’apps disponibles.

Le développeur arrivé plus tôt peut consacrer ce temps à attirer des clients, à améliorer le produit et à apprendre de l’usage. Le développeur arrivé plus tard peut le passer à expliquer pourquoi son produit devrait avoir le droit d’atteindre ces clients. Même si l’approbation finit par venir, l’incertitude et le retard ont un coût.

L’approbation n’est pas une protection permanente. Les règles d’Apple autorisent une différenciation ou une amélioration significative et prévoient le retrait des apps qui ne sont pas maintenues, améliorées ou qui n’attirent pas de clients. Les développeurs déjà en place peuvent eux aussi rencontrer des frictions lors de la révision.

En septembre 2026, Josh Dance a signalé le rejet au titre de la 4.3(a) d’une mise à jour de Pushup Hero. Il a dit que l’app était dans le store depuis 2018. Il soumettait des corrections de bugs et le mode sombre quand Apple a signalé une similarité avec une app associée à un compte résilié. Son récit décrit un appel sans indiquer son issue finale.

Ce qui me préoccupe, c’est la charge supplémentaire de celui qui arrive après qu’une catégorie s’est remplie. Cette charge pourrait influencer à la fois ce que les développeurs créent et la rapidité avec laquelle ils le soumettent.

Cela crée une incitation inconfortable : se précipiter. Le temps passé à affiner un produit devient du temps pendant lequel quelqu’un d’autre pourrait établir le point de comparaison. Un processus conçu pour améliorer la qualité pourrait augmenter, sans le vouloir, la pression de soumettre avant que le travail soit prêt.

L’IA rend-elle l’App Review plus lente ou plus stricte ?

Apple a reconnu la hausse des soumissions. Sa déclaration de mai 2026 dit que les outils de développement basés sur l’IA provoquent une vague de soumissions, tout en affirmant que l’App Review a « évolué sans accroc » pour y faire face. Apple dit aussi utiliser l’IA pour analyser la similarité entre apps et signaler aux examinateurs humains les changements potentiellement problématiques. Cela n’établit pas qu’une automatisation a pris la décision finale dans un rejet en particulier.

Dans un article de Business Insider de mars 2026, Apple a reconnu que certaines révisions étaient plus longues. Elle a indiqué avoir traité plus de 200 000 soumissions par semaine au cours des 12 semaines précédentes, avec un délai moyen de révision de 1,5 jour. Ses consignes aux développeurs précisent que 90 % des soumissions sont généralement examinées en moins de 48 heures.

Une décision de révision et une sortie réussie sont deux étapes différentes. Un développeur peut recevoir un rejet rapide et passer pourtant des semaines en échanges, en nouvelles soumissions et en appels. De bonnes statistiques de rapidité peuvent coexister avec un processus frustrant pour les développeurs dont l’app déclenche une classification contestée.

Apple a aussi répondu publiquement à des plaintes individuelles. Dans un fil de mai 2026 à propos de ByGate, le client dédié d’un service VPN, un compte identifié comme appartenant au personnel de l’App Review d’Apple a dit que des similitudes dans les binaires, les métadonnées et les concepts généraux peuvent contribuer à un constat de spam. Il a recommandé de prendre un rendez-vous avec l’App Review, sans identifier d’app de comparaison précise ni expliquer quelles caractéristiques n’étaient pas assez distinctes.

Comment les développeurs peuvent-ils répondre à un rejet au titre de la 4.3 ?

Apple propose des échanges avec l’App Review, des rendez-vous et des appels auprès de l’App Review Board. Ces mécanismes fonctionnent mieux quand le développeur comprend le grief.

Un code semblable, des captures d’écran semblables, des fonctionnalités semblables et un lien présumé avec un autre développeur sont des problèmes différents. Un développeur ne peut pas répondre intelligemment sans savoir lequel s’applique. Un rejet utile identifierait l’écran ou le flux de travail concerné, expliquerait quelles différences revendiquées ont été prises en compte, ou préciserait si le grief porte sur la paternité, sur des soumissions répétées ou sur l’expérience client.

Rien de tout cela n’exige de révéler les informations privées du compte d’un autre développeur.

Les développeurs ont aussi des responsabilités ici. Des mois de travail ne prouvent pas qu’une app offre quelque chose que les clients ne peuvent pas déjà obtenir. Nous devons rendre sa valeur visible à quelqu’un qui la découvre pour la première fois. Si cela exige des images d’escalade, des données représentatives ou une séquence d’actions précise, fournissez une démonstration fonctionnelle et des instructions de révision claires.

J’ai de la sympathie pour les examinateurs qui essaient de distinguer un clone d’une idée familière bien exécutée. Un meilleur échange de preuves aiderait les deux parties à dissiper les malentendus avant qu’un développeur ne commence à redessiner une app à partir de suppositions.

Peut-on distribuer des apps en dehors de l’App Store ?

Pour les développeurs Mac, la distribution directe est une option établie. Certaines apps ont besoin d’autorisations ou d’interactions avec d’autres applications qui ne rentrent pas dans le sandbox du Mac App Store. La documentation d’Apple sur le sandbox indique que certains usages des API d’accessibilité et l’interaction avec d’autres apps sont incompatibles avec ces restrictions.

Je distribue déjà deux apps Mac de cette façon : Burly, mon routeur de liens vers des profils de navigateur, et Comoji, mon app de raccourcis emoji. Burly envoie les liens vers des profils de navigateur précis et utilise l’accès Accessibilité pour contrôler les menus de profil de Safari. Comoji apporte des raccourcis emoji aux champs de texte de tout le Mac, en utilisant la Surveillance de l’entrée pour reconnaître les raccourcis et l’accès Accessibilité pour insérer le résultat. Ces capacités sont au cœur des produits.

La signature Developer ID et la notarisation permettent aux développeurs de distribuer directement des logiciels Mac tout en conservant les contrôles d’Apple contre les logiciels malveillants et les problèmes de signature. Pour les apps qui doivent fonctionner en dehors des restrictions du store, c’est une façon établie de servir les clients.

Je m’attends à ce que l’incertitude autour des rejets pour spam donne à davantage de développeurs une raison d’investir dans cette indépendance. Un site web, un paiement, une liste de diffusion et une relation directe avec les clients offrent plus de contrôle. Ils laissent aussi la place d’expliquer un produit spécialisé au-delà d’une fiche de store.

Mais un site web ne recrée pas la portée de l’App Store. Les clients doivent encore le découvrir, faire confiance au développeur et suivre un processus d’achat et d’installation différent. Même les développeurs qui distribuent de façon indépendante peuvent vouloir une fiche dans le store. Perdre cette possibilité a un coût.

La réponse est plus restrictive pour l’iPhone et l’iPad. Apple prend actuellement en charge les places de marché alternatives et la distribution autorisée par site web dans l’Union européenne, avec des places de marché iPhone également disponibles au Japon et au Brésil. Ces options ont des exigences régionales et restent soumises à la notarisation. Un développeur qui sert des clients iPhone ordinaires aux États-Unis ne peut pas simplement remplacer une fiche rejetée par un bouton de téléchargement sur un site web.

Une version web peut convenir à certains produits, mais elle peut exiger des changements importants du produit. La distribution indépendante est une réponse bien plus complète pour un développeur Mac que pour un développeur iPhone.

Des révisions plus strictes de l’App Store décourageront-elles les clones jetables ?

J’espère que certaines des personnes qui produisent des clones à la chaîne décideront que vendre de façon indépendante demande plus d’efforts que ça ne vaut. Si la stratégie consiste à soumettre cent variantes pour voir ce qui rapporte, un rejet pourrait être le point final de certains projets.

Générer une app n’est qu’une partie de la gestion d’une entreprise de logiciels. Même si vous pouvez générer le site web tout aussi vite, il faut encore attirer des clients, gagner leur confiance, gérer les paiements et les mises à jour, et leur donner une raison de vous choisir. Quelqu’un qui espère profiter du sillage d’une app existante aura peut-être peu d’intérêt pour ce travail.

Qui a besoin d’un énième minuteur Pomodoro avec une autre icône ? Une catégorie familière peut bénéficier d’une meilleure expérience ou d’une approche conçue pour un public négligé. Reproduire le même produit sous une autre marque n’apporte presque rien.

J’espère que la distribution indépendante décourage une partie de ces comportements. J’espère aussi qu’Apple deviendra meilleure pour les distinguer d’un développeur qui a créé quelque chose qui vaut la peine d’être utilisé. Arrêter un clone jetable peut profiter à la place de marché ; le rejet opaque d’un produit réfléchi peut priver les clients d’un choix utile.

Je veux que Dumpling soit jugée sur l’expérience qu’elle offre aux personnes pour qui Alan l’a conçue. Si Apple estime que cette expérience n’est pas assez différente, elle devrait expliquer pourquoi. Le premier développeur dans une catégorie mérite une longueur d’avance auprès des clients. Le suivant devrait quand même avoir une chance équitable de leur offrir quelque chose de mieux.