La case « réseaux sociaux » de l'App Store et ce qu'elle coûte

Vos seuils ne sont qu’indicatifs. Le système peut renvoyer des tranches d’âge qui l’emportent sur les seuils que vous spécifiez, en fonction de la localisation de la personne et de la réglementation applicable ; et lorsque la réglementation locale impose des seuils précis, la tranche renvoyée reflète les exigences réglementaires plutôt que les bornes que vous avez définies.⁷ Un code qui suppose que les bornes renvoyées correspondent à la demande déraille d’abord dans les juridictions les plus strictes.

Deux champs booléens de l’API App Store Connect portent à eux seuls tout le poids d’une exigence de soumission qui entre en vigueur en septembre : socialMedia et socialMediaAgeRestricted.¹ Le second coûte un entitlement, l’adoption d’une API et une bifurcation comportementale dans votre application.

Apple a annoncé l’exigence le 8 juin 2026 : « Starting September 2026, you’ll be required to indicate whether your app or game includes social media capabilities in order to submit new versions or updates to the App Store, or for notarization for distribution on alternative app marketplaces. »² Le 9 juillet, Apple a livré la modification du questionnaire en y ajoutant une phrase qui décide de la façon dont vous devriez employer les semaines qui restent : « You can review and answer these questions starting today. »³

En bref

• La déclaration est déjà active dans App Store Connect et devient obligatoire en septembre 2026 : l’écart entre « disponible » et « exigé » vous appartient, à consacrer à une décision plutôt qu’à une échéance.²³
• Apple définit bel et bien les « social media capabilities », à quatre endroits, et trois d’entre eux ne concordent pas. En juin, la portée est limitée aux fils « that visibly spreads content to many users » ; en juillet, la proposition disparaît purement et simplement.²³⁴
• L’API App Store Connect expose la réponse sous forme de deux booléens accessibles en écriture et conserve userGeneratedContent et messagingAndChat comme questions distinctes, avec des planchers de classification distincts. Les réseaux sociaux constituent un nouvel axe, pas un changement de nom.¹⁴
• Rester hors de la catégorie Réseaux sociaux pour les moins de 13 ans demande trois conditions, pas une. L’annonce d’Apple nomme l’API Declared Age Range ; l’aide App Store Connect ajoute que les utilisateurs de moins de 13 ans n’y ont aucun accès et que « Only age-appropriate UGC is delivered ».²⁴
• L’API Declared Age Range existe sur iOS, iPadOS, Mac Catalyst et macOS, et nulle part ailleurs.⁵ Une application tvOS, visionOS ou watchOS répond quand même à la question en septembre, et le moyen documenté de bénéficier de la dérogation n’existe pas sur sa plateforme.

Le seul changement de ce cycle déclenché par un calendrier

Tous les autres changements incompatibles que j’ai traités ce cycle attendent que vous bougiez en premier. L’exigence d’écran de lancement se déclenche lors d’une compilation contre le SDK iOS 27.0. La macro @State se déclenche à l’ouverture du projet dans Xcode 27. La dépréciation des On Demand Resources déclenche un avertissement du compilateur que vous pouvez ignorer indéfiniment. Laissez votre chaîne d’outils tranquille et aucun ne vous atteint.

La déclaration de réseaux sociaux, elle, vous atteint quoi qu’il arrive, parce qu’Apple l’a arrimée à un mois et à un geste que vous accomplissiez de toute façon. Une correction de bug d’une ligne emprunte le même pipeline de soumission qu’une nouvelle fonctionnalité, et en septembre ce pipeline pose la question.

La portée est étroite et mérite une lecture au mot près. L’exigence couvre « new versions or updates to the App Store » et « notarization for distribution on alternative app marketplaces ».² Juillet reprend le duo sous la forme « new apps or updates to the App Store » et « apps for notarization for alternative distribution ».³ Aucune des deux annonces ne mentionne de version de SDK, de cible de déploiement ni de plateforme. Les applications déjà en ligne continuent de se vendre. La barrière se dresse à la porte de la prochaine soumission.

Ce que votre réponse vous coûte, c’est un placement dans une catégorie que les parents peuvent plafonner. Les Time Allowances arrivent cet automne, aux côtés d’Ask to Browse, des Schedules et d’un Temps d’écran redessiné, offrant aux parents « more flexible ways to manage the time their kids spend in apps across categories, including Entertainment, Games, and Social Media », avec des recommandations adaptées à l’âge comme point de départ.¹⁶ Le placement dans Entertainment et Games découle de votre catégorie App Store Connect. Le placement dans Social Media découle de la seule réponse au questionnaire, « regardless of the category selected in App Store Connect ».² Un jeu de réflexion doté d’un fil d’actualité atterrit dans la catégorie qu’un parent bride en premier, quoi qu’affiche votre fiche produit.

Apple définit le terme, et les définitions dérivent

Le mode d’échec habituel, face à une question de règles, consiste à deviner le sens d’un mot jamais défini. Apple a publié une définition, ce qui réduit la part de devinette, mais l’a publiée quatre fois avec des contours différents.

Juin cadre les choses de façon inclusive : « This includes the ability to redistribute, amplify, or interact with user-generated content through a social feed or similar discovery method that visibly spreads content to many users. »²

Juillet adopte un cadrage définitionnel, et plus bref : « A social media capability is defined as the ability to redistribute, amplify, or interact with user-generated content through a social feed or similar discovery method. »³ La restriction sur la diffusion visible à de nombreux utilisateurs a disparu.

L’aide App Store Connect porte la version la plus longue, conserve la restriction et ajoute des exemples : « Redistribution, amplification, or interaction with user-generated content through a social feed or similar discovery method that visibly spreads content to many users. May include: users reposting, liking, commenting, reacting, or making user-generated content more visible through a social feed, community, search, or other sharing and discovery tools. »⁴

Trois des quatre exigent une diffusion large et visible. La quatrième non, et pour une application proche de la frontière, cet écart décide de la réponse. Je considérerais la page d’aide comme faisant foi, puisque le questionnaire y renvoie et que les annonces vieillissent ; cette lecture relève de ma déduction, pas d’une consigne d’Apple. Le « May include » compte lui aussi : Apple énumère des exemples sans clore la liste, si bien qu’une fonctionnalité ne ressemblant à aucun des cinq verbes cités peut malgré tout entrer dans le champ.

Ce qui affine la frontière, c’est la compagnie que fréquente ce descripteur. Apple définit séparément le User-Generated Content comme « the broad distribution of content created by users as a component of the app’s intended user experience », et séparément encore le Messaging and Chat comme des utilisateurs qui « can directly communicate with one another through features within the app ».⁴ L’API App Store Connect préserve exactement cette séparation, en portant userGeneratedContent, messagingAndChat et socialMedia comme trois booléens indépendants.¹

Les classifications divergent tout aussi nettement. Contenu généré par les utilisateurs et messagerie figurent tous deux dans la définition du 4+ chez Apple. Les réseaux sociaux apparaissent d’abord à 13+.⁴ Une application peut héberger du contenu d’utilisateurs, leur permettre de s’écrire, et rester classée 4+ ; ajoutez un fil qui amplifie ce même contenu auprès d’inconnus et le plancher bondit de neuf ans. Les deux descripteurs de réseaux sociaux n’existent que dans le barème de classification pour OS 26 et versions ultérieures, et le tableau d’Apple pour les versions antérieures ne comporte aucune entrée « réseaux sociaux », à quelque classification que ce soit.⁴

Le champ est renseignable dès aujourd’hui

Trois documents d’Apple confirment que la modification du questionnaire est déjà livrée, ce qui constitue l’intérêt pratique de tout cet article.

L’annonce d’Apple du 9 juillet indique que le questionnaire « now includes questions about your app’s social media capabilities » et vous invite à répondre immédiatement.³ L’API App Store Connect documente socialMedia comme « A Boolean value that indicates whether the app includes social media features » et socialMediaAgeRestricted comme « A Boolean value that indicates whether the app’s social media features are age restricted ».¹ La spécification OpenAPI publiée par Apple porte les deux comme booléens accessibles en écriture et nullables.¹ Ils voisinent avec ageAssurance, ajouté lors de la précédente refonte du questionnaire, dont la définition nomme la « declared age range API » parmi les mécanismes admissibles.⁴¹⁵ Adopter la dérogation vous fait donc entrer aussi dans cette définition, ce qui à mes yeux constitue une seconde question à réexaminer plutôt qu’un point à laisser en l’état.

Quiconque automatise ses soumissions a intérêt à en apprendre la forme dès maintenant : lire la déclaration via GET /v1/appInfos/{id}/ageRatingDeclaration, l’écrire via PATCH /v1/ageRatingDeclarations/{id}, et passer l’un ou l’autre booléen au paramètre fields[ageRatingDeclarations].¹ Un pipeline qui fabrique à la main ses charges utiles de classification par âge continue de fonctionner jusqu’au jour où il cesse.

Une conséquence n’a fait surface qu’en juillet : « Apps with these capabilities will display a new Social Media content descriptor on their App Store product page. »³ Répondre oui modifie votre fiche, et pas seulement une catégorie de contrôle parental.

Ouvrez donc le questionnaire cette semaine et lisez la classification calculée par App Store Connect. Cela ne vous engage à rien tant que vous ne soumettez pas, et transforme une échéance en une décision que vous avez déjà prise.

La dérogation compte trois conditions, pas une

L’annonce d’Apple donne au parcours « moins de 13 ans » des airs de simple appel d’API : « If you indicate that your app or game includes social media capabilities but they are disabled for anyone under 13, it won’t be included in the Time Allowance category for Social Media for users under 13… You’ll also need to use the Declared Age Range API (at a minimum) to check users’ age ranges. »²

L’aide App Store Connect énonce le même descripteur sous forme de trois exigences : « Users under 13 don’t have access to social media capabilities. At a minimum, the Declared Age Range API is called to check users’ age ranges before enabling social media features. Only age-appropriate UGC is delivered. »⁴

La troisième phrase est celle que personne ne cite. « Only age-appropriate UGC is delivered » est une obligation de modération sans API associée, sans seuil publié et sans test exécutable. Apple ne définit ni « adapté à l’âge » ni le mécanisme de diffusion. Une équipe qui adopte la vérification d’âge et livre le même fil non filtré à un enfant de 12 ans a satisfait une condition sur trois, selon le texte même de la page d’aide.

Notez aussi ce que la dérogation n’achète pas. La phrase d’Apple poursuit en précisant qu’une telle application « will remain in the Social Media category for users 13 and above ».² L’exemption ne couvre que les moins de 13 ans : un adolescent de 14 ans se heurte toujours au plafond qu’un parent a fixé sur Social Media.

Les tableaux de classification portent une tension que je n’ai pas su résoudre. L’annonce d’Apple affirme que l’option restreinte laisse vos « overall responses in the age rating questionnaire » déterminer la classification, laquelle « may result in a rating lower than 13+ ».² Pourtant, le tableau global d’Apple range à la fois « Social media » et « Social media disabled for users under 13 » sous Capabilities à 13+, et les tableaux régionaux les placent ensemble à 16+ en Australie, A16 au Brésil, 15+ en Corée et 16+ au Vietnam.⁴ Lue comme se lisent toutes les autres lignes, où un descripteur fixe un plancher, l’option restreinte ressemble elle aussi à un plancher 13+. Apple ne réconcilie rien, et je ne me risquerai pas à deviner quel document le calculateur applique. Sélectionnez l’option dans le questionnaire en ligne, lisez la classification calculée, et fiez-vous au calculateur plutôt qu’aux deux textes.

Suivre la case à cocher jusque dans l’application

Admettons que vous preniez la dérogation. Vous activez la capacité Declared Age Range sur la cible dans Xcode, ce qui ajoute l’entitlement com.apple.developer.declared-age-range : « A Boolean value indicating whether your app may request a person’s age range. »⁶ Vous appelez ensuite l’API avec les seuils qui vous intéressent, laquelle se présente en SwiftUI sous forme d’action d’environnement :⁵

Apple assortit cette action d’une règle de placement : l’utiliser « in response to user interactions », et son propre exemple place l’appel derrière un bouton.⁵ La requête peut présenter une feuille système : la déclencher depuis .task ou onAppear jette donc une demande d’autorisation à la figure de quelqu’un qui n’a encore rien demandé. Accrochez-la plutôt au geste qui ouvre la surface protégée.

import SwiftUI
import DeclaredAgeRange

@available(iOS 26.0, *)
struct SocialFeedGate: View {
    @Environment(\.requestAgeRange) private var requestAgeRange
    @State private var feedEnabled = false
    @State private var checking = false

    var body: some View {
        if feedEnabled {
            FeedView()
        } else {
            Button("Open community feed") {
                checking = true
                Task {
                    feedEnabled = await resolveGate()
                    checking = false
                }
            }
            .disabled(checking)
        }
    }

    private func resolveGate() async -> Bool {
        guard let response = try? await requestAgeRange(ageGates: 13) else {
            return false          // AgeRangeService.Error: your default, not Apple's
        }
        guard case let .sharing(ageRange) = response else {
            return false          // .declinedSharing
        }
        guard let lowerBound = ageRange.lowerBound else {
            return false          // nil lower bound means below your lowest gate
        }
        return lowerBound >= 13
    }
}

Quatre détails de cet extrait décident de la solidité de la barrière.

Vous disposez de trois seuils au maximum. Les deux surcharges s’arrêtent à trois seuils : l’action SwiftUI s’écrit callAsFunction(ageGates threshold1: Int, _ threshold2: Int? = nil, _ threshold3: Int? = nil), et la méthode UIKit n’ajoute que l’ancrage de présentation.⁷ Quatre tranches, voilà le plafond. Il vous faut 13 pour la règle d’Apple et 16 pour la loi australienne, et vous avez déjà consommé trois tranches sur quatre avant d’avoir conçu quoi que ce soit.

Une borne inférieure à nil est la réponse, pas une erreur. AgeRange.lowerBound et upperBound sont tous deux des Int?, et Apple énonce le cas nil sans détour : « When this value is nil, the person’s age range is below your lowest specified age, indicating they are under your minimum age requirement. »⁸ Un code qui déballe l’optionnel avec optimisme inverse la barrière précisément pour la population qu’elle est censée protéger.

Le refus est une vraie bifurcation, et Apple ne dit pas quoi en faire. AgeRangeService.Response porte .sharing(range:) et .declinedSharing.⁹ Dans certaines régions réglementées, « the system automatically provides the person’s age range » et les personnes « can’t decline sharing » ; dans les régions non réglementées, « If the person declines, you receive a declinedSharing response ».¹⁰ Un refus est indiscernable d’un adulte soucieux de sa vie privée : traitez-le comme un moins de 13 ans et vous bloquez des adultes, traitez-le comme un adulte et vous ouvrez la porte que vous aviez promis de fermer. Apple vous laisse le comportement par défaut. Pour ma part, j’opterais pour le refus par défaut, en le disant dans l’interface.

Vos seuils ne sont qu’indicatifs. Le système peut renvoyer des tranches d’âge qui l’emportent sur les seuils que vous spécifiez, en fonction de la localisation de la personne et de la réglementation applicable ; et lorsque la réglementation locale impose des seuils précis, la tranche renvoyée reflète les exigences réglementaires plutôt que les bornes que vous avez définies.⁷ Un code qui suppose que les bornes renvoyées correspondent à la demande déraille d’abord dans les juridictions les plus strictes.

Un autre comportement mérite sa place dans la conception, et je m’attends à ce qu’il génère des tickets de support. Apple met la réponse en cache : « When a person’s age crosses into a new range (for example, when they turn 13), the API continues returning the previous range until the anniversary of their original declaration. »¹⁰ Un enfant qui fête ses 13 ans un lundi peut continuer d’être lu comme un moins de 13 ans pendant des mois. Le remède est un chemin dans les Réglages que l’utilisateur parcourt seul : son nom, puis Informations personnelles, puis Tranche d’âge pour les apps.¹⁰ Toute application qui filtre à 13 ans doit fournir cette instruction dans sa propre interface, faute de quoi personne ne la trouvera.

Deux détails plus modestes comptent au moment de la conception. isEligibleForAgeFeatures indique si la personne se trouve dans une région exigeant la vérification d’âge, et sur macOS il « returns false because the system doesn’t require Age Assurance for the person or device » : une application Mac appelle donc requestAgeRange directement.¹¹ Quant à AgeRangeDeclaration, qui rapporte la manière dont l’âge a été établi, il a déjà bougé : six cas granulaires en 26.2, nommant le paiement, la pièce d’identité officielle et d’autres méthodes pour la personne comme pour son tuteur, condensés en un unique cas confirmed en 26.5.¹² Demandez quelle méthode a vérifié un utilisateur et l’API actuelle ne le dit plus.

Reste le plancher de plateformes, que les métadonnées de disponibilité énoncent et qu’aucune source rédigée ne mentionne. Declared Age Range publie iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0 et macOS 26.0, et rien d’autre : pas de ligne tvOS, pas de ligne visionOS, pas de ligne watchOS.⁵ Les Time Allowances atterrissent sur les mêmes familles, « iOS 27, iPadOS 27, and macOS 27, or later », tandis que l’exigence de déclaration ne porte aucune restriction de plateforme.²³ Une application tvOS ou visionOS dotée d’un fil social répond donc en septembre sans pouvoir satisfaire le minimum documenté de la dérogation, puisque l’API qu’elle nomme n’existe pas là. Lire cette discordance comme une lacune plutôt que comme une exemption délibérée relève de ma déduction ; Apple n’a rien publié dans un sens ni dans l’autre.

Ce que déclarent huit de mes propres applications

J’ai mené l’enquête sur mon propre code avant d’écrire sur celui des autres : huit projets Xcode, 491 fichiers Swift.¹³ Aucun ne contient CKShare, UICloudSharingController, une base CloudKit partagée ou publique, GameKit, ni le moindre symbole Declared Age Range. Pas une seule application de l’ensemble ne déplace du contenu d’une personne vers une autre. Quatre projets ne comportent aucune surface signalée. Les quatre autres présentent des surfaces devant lesquelles une personne consciencieuse pourrait hésiter, et elles se rangent en trois catégories qui méritent un raisonnement à voix haute.

Get Bananas possède une liste de courses partagée, et « partagée » est plus étroit qu’il n’y paraît. L’application écrit un document JSON dans un conteneur ubiquitaire iCloud et le relit sur iPhone, Apple Watch et Mac, avec com.apple.developer.icloud-services réglé sur CloudDocuments et aucun partage CloudKit nulle part dans le projet.¹³ La liste est partagée entre les appareils d’une seule personne, pas entre personnes : rien n’est redistribué et il n’existe pas de second utilisateur vers qui diffuser. La réponse bascule le jour où j’ajoute CKShare pour la collaboration familiale, et même alors elle bascule vers contenu généré par les utilisateurs plutôt que vers réseaux sociaux, parce qu’une liste de courses à deux n’a ni fil ni surface de découverte. La ligne à surveiller se situe plus loin : listes partagées, plus galerie publique de modèles, plus « j’aime », cela fait un fil avec des étapes en plus.

Trois applications présentent une feuille de partage, et une feuille de partage n’est pas une fonctionnalité sociale. Get Bananas, Water et l’application iOS de ResumeGeni enveloppent chacune UIActivityViewController pour confier le contenu de l’utilisateur à l’application de son choix.¹³ Le contenu part vers Messages ou Mail et ne revient jamais sur une surface que contrôle mon application, or la définition d’Apple repose sur une redistribution « through a social feed or similar discovery method », ce qu’une feuille de partage système n’est pas.⁴ Le raisonnement couvre une large tranche de l’App Store : exporter n’est pas publier.

Watch Connectivity ressemble à de la messagerie sans en être. Get Bananas et Reps utilisent tous deux WCSession, qui déplace des données entre un téléphone et une montre appairés à la même personne, alors que le descripteur Messaging and Chat d’Apple exige que « Users can directly communicate with one another ».⁴¹³ Un seul utilisateur occupe les deux extrémités.

Le résultat nul se généralise, et c’est la partie qui vaut d’être reprise. Chaque application de l’ensemble stocke du contenu pour la personne qui l’a créé et le lui restitue à elle seule. Le questionnaire demande tout autre chose : votre application prend-elle le contenu d’une personne pour le mettre sous les yeux d’autres, via un mécanisme qui le diffuse ? Les applications de suivi, les minuteurs et les outils de révision répondent non par architecture, et non par lecture du règlement. Les applications qui doivent réfléchir sont celles où existe la moindre surface sur laquelle des utilisateurs voient le travail des autres.

Les cibles de déploiement sont l’autre chiffre à vérifier en premier. Six des sept projets dotés d’une cible iOS se situent à iOS 26.0 ou au-delà ; Ace Citizenship déclare encore 17.0 et 17.5 sur certaines de ses cibles.¹³ Tout ce qui reste sous 26.0 ne peut pas appeler l’API du tout, ce qui supprime la dérogation et ne laisse que la déclaration simple comme réponse exacte.

L’écart de plateformes ressort de la même enquête, et plus largement que l’écart de versions. Quatre des huit projets déclarent xros xrsimulator dans SUPPORTED_PLATFORMS : Reps, Return, Water et Yawara. Reps y ajoute appletvos appletvsimulator et livre une cible watchos watchsimulator distincte ; Return et Banana List portent également des cibles watchOS.¹³ Declared Age Range publie sa disponibilité pour iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0 et macOS 26.0, et aucune ligne pour tvOS, visionOS ou watchOS.⁵ Chacune de ces cibles est redevable de la déclaration de septembre, et sur n’importe laquelle d’entre elles une réponse positive met la dérogation hors de portée, puisque l’API dont elle dépend n’y est pas livrée.

Une mise en garde méthodologique, puisque je me suis trompé au premier passage. XROS_DEPLOYMENT_TARGET apparaît dans des projets dépourvus de toute destination visionOS, parce que Xcode inscrit le réglage dans les configurations quoi qu’il arrive. ResumeGeni porte XROS_DEPLOYMENT_TARGET = 26.2 et ne compile que pour iphoneos iphonesimulator.¹³ Lisez SUPPORTED_PLATFORMS, pas les clés de cible de déploiement, sinon vous compterez des plateformes que votre application ne livre pas.

Là où la réponse cesse d’être technique

Apple assortit la documentation de Declared Age Range d’un avertissement qui mérite deux lectures : « Data from the Declared Age Range API is based on information declared by an end user, or their parent or guardian », et « You are solely responsible for ensuring compliance with associated laws or regulations that may apply to your app ».¹⁴

Cette phrase trace la limite où l’article s’arrête. Le questionnaire d’Apple produit une classification et une catégorie de Time Allowance, et une conformité à rien du tout. La loi australienne impose depuis le 10 décembre 2025 à certaines plateformes de réseaux sociaux d’empêcher les moins de 16 ans de détenir un compte, et les recommandations d’Apple sur cette loi citent l’API Declared Age Range comme un outil parmi cinq.¹⁵ Questionnaire et texte de loi se recouvrent sans coïncider : l’un parle de 13 ans, l’autre de 16, et vous disposez de trois seuils pour couvrir les deux.

Savoir si votre application est une plateforme de réseaux sociaux au sens d’une loi donnée est une question pour un avocat de la juridiction concernée. Savoir si elle possède des fonctionnalités de réseaux sociaux au sens du questionnaire d’Apple est la vôtre, et vous pouvez y répondre dès aujourd’hui à partir de la définition publiée par Apple.

FAQ

La question sur les réseaux sociaux est-elle active dans App Store Connect en ce moment ?

Oui. L’annonce d’Apple du 9 juillet 2026 indique que le questionnaire « now includes questions about your app’s social media capabilities » et que « You can review and answer these questions starting today ».³ L’API App Store Connect le confirme de façon indépendante, en documentant socialMedia et socialMediaAgeRestricted comme attributs de la ressource AgeRatingDeclaration, tous deux modifiables via PATCH /v1/ageRatingDeclarations/{id}.¹ Répondre maintenant ne vous engage à rien : les réponses vous lient au moment de la soumission, et septembre 2026 est la date à partir de laquelle soumettre sans elles cesse de fonctionner.²

Apple définit-il les « social media capabilities » ?

Oui, à quatre endroits, avec deux portées différentes. L’aide App Store Connect en donne la version la plus complète, en exigeant une « Redistribution, amplification, or interaction with user-generated content through a social feed or similar discovery method that visibly spreads content to many users », puis cite en exemples le repartage, les « j’aime », les commentaires, les réactions et la mise en avant.⁴ Juin porte la même proposition restrictive ; juillet la supprime.²³ Comme les exemples sont illustratifs et non exhaustifs, c’est encore à vous de classer votre propre application, et je la classerais à l’aune de la page d’aide.

Mon application comporte du contenu généré par les utilisateurs. Est-ce automatiquement du réseau social ?

Non. Apple les maintient comme des questions distinctes, aux définitions distinctes et aux conséquences distinctes sur la classification. Le User-Generated Content couvre « the broad distribution of content created by users as a component of the app’s intended user experience » et figure dans la définition du 4+ chez Apple.⁴ Les réseaux sociaux exigent une redistribution, une amplification ou une interaction via un fil ou une surface de découverte comparable, et apparaissent d’abord à 13+.⁴ L’API reflète cette séparation avec des booléens userGeneratedContent et socialMedia indépendants.¹ Une application où les gens créent du contenu qu’eux seuls voient n’est ni l’un ni l’autre.

Qu’est-ce que l’option « moins de 13 ans » m’oblige réellement à construire ?

Trois choses, dont la deuxième seulement relève d’une API. L’aide App Store Connect exige que les utilisateurs de moins de 13 ans n’aient aucun accès aux fonctionnalités de réseaux sociaux, qu’« At a minimum, the Declared Age Range API is called to check users’ age ranges before enabling social media features », et que « Only age-appropriate UGC is delivered ».⁴ Vous ajoutez donc l’entitlement com.apple.developer.declared-age-range, appelez requestAgeRange avec 13 parmi vos seuils avant l’apparition de toute surface sociale, gérez chaque branche de la réponse y compris le cas du refus qu’Apple laisse indéfini, et veillez séparément à ce que le contenu livré aux mineurs soit adapté à leur âge.⁵⁶ L’API vous plafonne à trois seuils et met en cache la tranche d’une personne jusqu’à l’anniversaire de sa déclaration : un utilisateur qui fête ses 13 ans continue donc d’être lu comme plus jeune tant qu’il ne met pas à jour ses Réglages.⁷¹⁰

À retenir

Pour les développeurs iOS : - Répondez au questionnaire cette semaine plutôt qu’en septembre. Le champ est actif, les réponses n’engagent qu’à la soumission, et lire la classification calculée tranche la question du 13+ qu’aucune des deux annonces ne règle proprement.³⁴ - Si vous prenez la dérogation « moins de 13 ans », prévoyez trois conditions plutôt qu’un seul appel d’API, et écrivez délibérément la branche du refus. .declinedSharing est en tout point semblable à un adulte soucieux de sa vie privée, et Apple ne publie aucune recommandation sur le sens dans lequel trancher.⁴⁹

Pour les équipes sur tvOS, visionOS ou watchOS : - Vérifiez la disponibilité avant de planifier. Declared Age Range publie des lignes iOS, iPadOS, Mac Catalyst et macOS, et rien d’autre : le minimum documenté de la dérogation est donc indisponible sur votre plateforme, alors que la déclaration de septembre s’applique toujours à votre soumission.²⁵ - La même lacune rattrape toute cible sous iOS 26.0, pour une autre raison : pas d’API, pas de dérogation, et la déclaration simple comme seule réponse exacte.⁵

Pour les responsables de publication : - Traitez la date comme le déclencheur, à rebours du reste de ce cycle. La clé d’écran de lancement et la macro @State se déclenchent sur un SDK et une chaîne d’outils que vous maîtrisez ; septembre se déclenche sur une soumission que vous faisiez de toute façon.² - Faites passer la réponse par la personne qui possède la fiche produit. Déclarer des fonctionnalités de réseaux sociaux ajoute un descripteur de contenu Social Media à votre fiche App Store, conséquence qu’Apple n’a révélée qu’en juillet.³

Le cycle 27 continue de trier ses changements selon ce qui les déclenche : un réglage de compilation, une chaîne d’outils, un avertissement du compilateur, et désormais un calendrier. Pour la dépréciation du même cycle qui a le moins de mordant et la plus grosse migration derrière elle, voir Les On Demand Resources et ce que coûtent les Background Assets. Le sommaire complet de la série est la série Écosystème Apple.

Références