A caixinha de mídia social da App Store e o que ela custa

Dois campos booleanos da API do App Store Connect carregam todo o peso de um requisito de submissão que começa em setembro: socialMedia e socialMediaAgeRestricted.¹ O segundo custa um entitlement, a adoção de uma API e uma ramificação de comportamento dentro do seu app.

A Apple anunciou o requisito em 8 de junho de 2026: “A partir de setembro de 2026, você precisará indicar se seu app ou jogo inclui recursos de mídia social para poder enviar novas versões ou atualizações à App Store, ou para notarização para distribuição em marketplaces alternativos de apps.”² Em 9 de julho a Apple colocou no ar a mudança no questionário e acrescentou uma frase que decide como você deve gastar as semanas até lá: “Você pode revisar e responder a essas perguntas a partir de hoje.”³

Resumo

• A declaração já está no ar no App Store Connect e se torna obrigatória em setembro de 2026, então a janela entre o disponível e o obrigatório é sua para gastar com uma decisão, e não com um prazo.²³
• A Apple de fato define “recursos de mídia social”, em quatro lugares, e três deles não batem entre si. Junho limita o escopo a feeds “que espalham conteúdo de forma visível para muitos usuários”; julho abandona a ressalva por completo.²³⁴
• A API do App Store Connect expõe a resposta como dois booleanos graváveis e mantém userGeneratedContent e messagingAndChat como perguntas separadas, com pisos de classificação separados. Mídia social é um eixo novo, não um renome.¹⁴
• Ficar fora do grupo “mídia social para menores de 13 anos” exige três condições, não uma. O anúncio da Apple cita a API Declared Age Range; a Ajuda do App Store Connect acrescenta que usuários menores de 13 anos não têm acesso algum e que “Apenas UGC apropriado para a idade é entregue.”²⁴
• A API Declared Age Range existe no iOS, iPadOS, Mac Catalyst e macOS, e em nenhum outro lugar.⁵ Um app de tvOS, visionOS ou watchOS ainda responde à pergunta em setembro, e o caminho documentado para se qualificar à exceção não existe na plataforma dele.

A única mudança deste ciclo disparada por um calendário

Toda outra mudança incompatível que cobri neste ciclo espera que você se mexa primeiro. O requisito de launch screen dispara quando você compila contra o SDK do iOS 27.0. A macro @State dispara quando você abre o projeto no Xcode 27. A descontinuação do On Demand Resources dispara um aviso do compilador que você pode ignorar indefinidamente. Deixe sua toolchain em paz e nenhuma delas chega até você.

A declaração de mídia social chega de qualquer forma, porque a Apple a amarrou a um mês e a um ato que você ia praticar de todo jeito. Uma correção de bug de uma linha percorre o mesmo pipeline de submissão que um lançamento de recurso, e em setembro esse pipeline faz a pergunta.

O escopo é estreito e vale a leitura literal. O requisito cobre “novas versões ou atualizações à App Store” e “notarização para distribuição em marketplaces alternativos de apps.”² Julho repete o par como “novos apps ou atualizações à App Store” e “apps para notarização para distribuição alternativa.”³ Nenhum dos dois anúncios menciona versão de SDK, deployment target ou plataforma. Apps já publicados continuam vendendo. A barreira fica na porta da próxima submissão.

O que a resposta custa a você é o lugar em um grupo que os pais podem limitar. As Time Allowances chegam no segundo semestre deste ano, junto com Ask to Browse, Schedules e uma Screen Time redesenhada, dando aos pais “formas mais flexíveis de gerenciar o tempo que os filhos passam em apps de diferentes categorias, incluindo Entretenimento, Jogos e Mídia Social”, com orientação ajustada à idade como ponto de partida.¹⁶ O enquadramento em Entretenimento e Jogos segue a categoria escolhida no App Store Connect. O enquadramento em Mídia Social segue apenas a resposta do questionário, “independentemente da categoria selecionada no App Store Connect.”² Um jogo de quebra-cabeça com um feed cai na categoria que os pais limitam primeiro, diga o que disser a página do produto.

A Apple define o termo, e as definições não param quietas

O modo clássico de errar numa pergunta de política é chutar o sentido de uma palavra indefinida. A Apple publicou uma definição, o que estreita o chute, e a publicou quatro vezes com bordas diferentes.

Junho formula de modo inclusivo: “Isso inclui a capacidade de redistribuir, amplificar ou interagir com conteúdo gerado por usuários por meio de um feed social ou método de descoberta semelhante que espalhe conteúdo de forma visível para muitos usuários.”²

Julho formula de modo definicional, e mais curto: “Um recurso de mídia social é definido como a capacidade de redistribuir, amplificar ou interagir com conteúdo gerado por usuários por meio de um feed social ou método de descoberta semelhante.”³ O qualificador sobre espalhar conteúdo de forma visível para muitos usuários sumiu.

A Ajuda do App Store Connect traz a versão mais longa, mantém o qualificador e acrescenta exemplos: “Redistribuição, amplificação ou interação com conteúdo gerado por usuários por meio de um feed social ou método de descoberta semelhante que espalhe conteúdo de forma visível para muitos usuários. Pode incluir: usuários repostando, curtindo, comentando, reagindo ou tornando conteúdo gerado por usuários mais visível por meio de um feed social, comunidade, busca ou outras ferramentas de compartilhamento e descoberta.”⁴

Três das quatro exigem alcance visível e amplo. Uma não exige, e para um app na fronteira essa diferença decide a resposta. Eu trataria a página de Ajuda como a versão que vale, porque o questionário aponta para ela e anúncios envelhecem; ler assim é inferência minha, não instrução da Apple. “Pode incluir” também pesa: a Apple lista exemplos em vez de fechar o conjunto, então um recurso que não se parece com nenhum dos cinco verbos listados ainda pode se enquadrar.

O que afia a fronteira é a vizinhança do descritor. A Apple define Conteúdo Gerado por Usuários em separado, como “a ampla distribuição de conteúdo criado por usuários como componente da experiência pretendida do app”, e Mensagens e Chat em separado de novo, como usuários que “podem se comunicar diretamente entre si por meio de recursos dentro do app.”⁴ A API do App Store Connect preserva a divisão exatamente, carregando userGeneratedContent, messagingAndChat e socialMedia como três booleanos independentes.¹

As classificações divergem com a mesma nitidez. Conteúdo gerado por usuários e mensagens aparecem ambos na definição de 4+ da Apple. Mídia social aparece pela primeira vez em 13+.⁴ Um app pode hospedar conteúdo de usuários, deixar as pessoas se enviarem mensagens e ainda assim receber 4+; acrescente um feed que amplifique esse mesmo conteúdo para estranhos e o piso salta nove anos. Ambos os descritores de mídia social existem apenas no esquema de classificação do OS 26 em diante, e a tabela da Apple para versões anteriores do OS não traz nenhuma entrada de mídia social em classificação alguma.⁴

O campo já pode ser respondido hoje

Três artefatos da Apple confirmam que a mudança no questionário já foi ao ar, que é o ponto prático de todo este texto.

O anúncio da Apple de 9 de julho diz que o questionário “agora inclui perguntas sobre os recursos de mídia social do seu app” e convida você a responder de imediato.³ A API do App Store Connect documenta socialMedia como “Um valor booleano que indica se o app inclui recursos de mídia social” e socialMediaAgeRestricted como “Um valor booleano que indica se os recursos de mídia social do app têm restrição de idade.”¹ A especificação OpenAPI publicada pela Apple traz ambos como booleanos graváveis e anuláveis.¹ Eles ficam ao lado de ageAssurance, acrescentado pela reformulação anterior do questionário, cuja definição cita a “API declared age range” como mecanismo qualificador.⁴¹⁵ Adotar a exceção, portanto, também coloca você dentro dessa definição, o que para mim soa como uma segunda pergunta a revisitar, não uma para deixar quieta.

Quem automatiza submissões deve aprender o formato agora: leia a declaração em GET /v1/appInfos/{id}/ageRatingDeclaration, grave em PATCH /v1/ageRatingDeclarations/{id} e passe qualquer um dos booleanos ao parâmetro fields[ageRatingDeclarations].¹ Um pipeline que monta payloads de classificação etária na mão continua passando até o dia em que não passa mais.

Uma consequência só apareceu em julho: “Apps com esses recursos exibirão um novo descritor de conteúdo Mídia Social na página do produto na App Store.”³ Responder sim muda sua listagem, não apenas um grupo de controle parental.

Então abra o questionário esta semana e leia a classificação que o App Store Connect calcula. Fazer isso não compromete nada até você submeter, e converte um prazo em uma decisão que você já tomou.

A exceção tem três condições, não uma

O anúncio da Apple faz o caminho para menores de 13 anos soar como uma única chamada de API: “Se você indicar que seu app ou jogo inclui recursos de mídia social, mas eles estão desativados para qualquer pessoa com menos de 13 anos, ele não será incluído na categoria de Time Allowance de Mídia Social para usuários com menos de 13 anos… Você também precisará usar a API Declared Age Range (no mínimo) para verificar as faixas etárias dos usuários.”²

A Ajuda do App Store Connect enuncia o mesmo descritor como três requisitos: “Usuários com menos de 13 anos não têm acesso a recursos de mídia social. No mínimo, a API Declared Age Range é chamada para verificar as faixas etárias dos usuários antes de habilitar recursos de mídia social. Apenas UGC apropriado para a idade é entregue.”⁴

A terceira frase é a que ninguém cita. “Apenas UGC apropriado para a idade é entregue” é uma obrigação de moderação sem API associada, sem limiar publicado e sem teste que você possa rodar. A Apple não define nem o que é apropriado para a idade nem o mecanismo de entrega. Um time que adota a verificação de idade e entrega o mesmo feed sem filtro a uma criança de 12 anos cumpriu uma das três condições, pelo próprio texto da página de Ajuda.

Repare também no que a exceção não compra. A própria frase da Apple continua dizendo que esse app “permanecerá na categoria Mídia Social para usuários de 13 anos ou mais.”² A isenção cobre apenas usuários com menos de 13 anos, então alguém de 14 ainda esbarra em qualquer limite que um pai tenha definido para Mídia Social.

As tabelas de classificação carregam uma tensão que não consegui resolver. O anúncio da Apple diz que a opção restrita deixa suas “respostas gerais no questionário de classificação etária” determinarem a classificação, o que “pode resultar em uma classificação inferior a 13+.”² Ainda assim, a tabela global da Apple lista tanto “Mídia social” quanto “Mídia social desativada para usuários com menos de 13 anos” sob Recursos em 13+, e as tabelas regionais colocam as duas juntas em 16+ na Austrália, A16 no Brasil, 15+ na Coreia e 16+ no Vietnã.⁴ Lida como todas as outras linhas se leem, em que um descritor define um piso, a opção restrita também parece um piso de 13+. A Apple não concilia nada, e não vou chutar qual documento a calculadora implementa. Selecione a opção no questionário ao vivo, leia a classificação calculada e confie na calculadora acima dos dois textos.

Seguindo a caixinha até dentro do app

Digamos que você adote a exceção. Você habilita a capability Declared Age Range no target no Xcode, o que adiciona o entitlement com.apple.developer.declared-age-range: “Um valor booleano que indica se seu app pode solicitar a faixa etária de uma pessoa.”⁶ Depois você chama a API com os limiares que interessam, o que no SwiftUI chega como uma ação de ambiente:⁵

A Apple associa uma regra de posicionamento a essa ação: use-a “em resposta a interações do usuário”, e o próprio exemplo da Apple põe a chamada atrás de um botão.⁵ A requisição pode abrir uma sheet do sistema, então dispará-la de .task ou onAppear joga um pedido de permissão na cara de alguém que ainda não pediu nada. Pendure-a no toque que entra na superfície protegida.

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
    }
}

Quatro detalhes nessa listagem decidem se a barreira se sustenta.

Você tem no máximo três limiares. Ambas as sobrecargas param em três: a ação do SwiftUI é callAsFunction(ageGates threshold1: Int, _ threshold2: Int? = nil, _ threshold3: Int? = nil), e o método do UIKit só acrescenta a âncora de apresentação.⁷ Quatro faixas é o teto. Se você precisa de 13 pela regra da Apple e de 16 pela lei australiana, já gastou três de quatro antes de projetar qualquer coisa.

Um limite inferior nulo é a resposta, não um erro. AgeRange.lowerBound e upperBound são ambos Int?, e a Apple diz o caso nulo com todas as letras: “Quando esse valor é nil, a faixa etária da pessoa está abaixo da sua menor idade especificada, indicando que ela está abaixo do seu requisito mínimo de idade.”⁸ Código que faz unwrap otimista inverte a barreira exatamente sobre a população que ela existe para proteger.

Recusar é uma ramificação real, e a Apple não diz o que fazer com ela. AgeRangeService.Response carrega .sharing(range:) e .declinedSharing.⁹ Em algumas regiões reguladas “o sistema fornece automaticamente a faixa etária da pessoa” e as pessoas “não podem recusar o compartilhamento”; em regiões não reguladas “Se a pessoa recusar, você recebe uma resposta declinedSharing.”¹⁰ Uma recusa é indistinguível de um adulto que preza pela privacidade: trate-a como menor de 13 e você bloqueia gente grande, trate-a como adulto e você abre a barreira que prometeu fechar. A Apple deixa o padrão por sua conta. Eu falharia para o lado fechado e diria isso na interface.

Seus limiares são apenas indicativos. O sistema “pode retornar faixas etárias que prevalecem sobre os limiares que você especificou, com base na localização da pessoa e nas regulamentações aplicáveis”, e quando regulamentações locais exigem limiares específicos, “a faixa etária retornada reflete requisitos regulatórios em vez dos limites dos seus limiares de idade.”⁷ Código que presume que os limites retornados correspondem ao pedido começa a se comportar mal justamente nas jurisdições mais rígidas.

Mais um comportamento pertence ao design, e espero que ele gere chamados de suporte. A Apple armazena a resposta em cache: “Quando a idade de uma pessoa cruza para uma nova faixa (por exemplo, quando ela faz 13 anos), a API continua retornando a faixa anterior até o aniversário da declaração original.”¹⁰ Uma criança que faz 13 anos na segunda-feira pode continuar sendo lida como menor de 13 por meses. O remédio é um caminho em Ajustes que o usuário percorre sozinho, sob o próprio nome, depois Informações Pessoais, depois Faixa Etária para Apps.¹⁰ Qualquer app que use 13 como barreira precisa dessa instrução na própria UI, porque ninguém acha isso de outro jeito.

Dois detalhes menores pesam na hora de projetar. isEligibleForAgeFeatures informa se a pessoa está em uma região que exige verificação de idade, e no macOS ele “retorna false porque o sistema não exige Age Assurance para a pessoa ou o dispositivo”, então um app de Mac chama requestAgeRange direto.¹¹ E AgeRangeDeclaration, que informa como a idade foi definida, já mudou: seis casos granulares no 26.2, nomeando pagamento, documento oficial e outros métodos para a pessoa e o responsável, colapsaram em um único caso confirmed no 26.5.¹² Pergunte qual método verificou um usuário e a API atual não responde mais.

Depois vem o piso de plataforma, que os metadados de disponibilidade informam e nenhuma fonte em prosa menciona. Declared Age Range publica iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0 e macOS 26.0, e nada mais: sem linha de tvOS, sem linha de visionOS, sem linha de watchOS.⁵ As Time Allowances chegam às mesmas famílias, “iOS 27, iPadOS 27 e macOS 27, ou posterior”, enquanto o requisito de declaração não traz qualificador de plataforma nenhum.²³ Um app de tvOS ou visionOS com feed social, portanto, responde em setembro e não consegue cumprir o mínimo documentado da exceção, porque a API que ela cita não existe ali. Ler o descompasso como lacuna e não como isenção intencional é inferência minha; a Apple não publicou nada em nenhuma das direções.

O que oito apps meus declaram

Fiz o levantamento antes de escrever sobre código dos outros: oito projetos Xcode, 491 arquivos Swift.¹³ Nenhum contém CKShare, UICloudSharingController, um banco CloudKit compartilhado ou público, GameKit, ou qualquer símbolo de Declared Age Range. Nenhum app do conjunto move conteúdo de uma pessoa para outra. Quatro projetos não têm superfície sinalizada alguma. Os outros quatro têm superfícies sobre as quais uma pessoa cuidadosa poderia hesitar, e elas vêm em três tipos sobre os quais vale raciocinar em voz alta.

O Get Bananas tem uma lista de compras compartilhada, e “compartilhada” é mais estreito do que parece. O app grava um documento JSON em um contêiner de ubiquidade do iCloud e o lê de volta no iPhone, no Apple Watch e no Mac, com com.apple.developer.icloud-services definido como CloudDocuments e nenhum compartilhamento CloudKit em lugar algum do projeto.¹³ A lista é compartilhada entre os dispositivos de uma pessoa, não entre pessoas, então nada é redistribuído e não há um segundo usuário para quem espalhar. A resposta muda no dia em que eu adicionar CKShare para colaboração doméstica, e mesmo assim ela muda para conteúdo gerado por usuários, não para mídia social, porque uma lista de compras de duas pessoas não tem feed nem superfície de descoberta. A linha que vale acompanhar está mais adiante: listas compartilhadas mais uma galeria pública de modelos mais curtidas é um feed com passos extras.

Três apps apresentam uma share sheet, e uma share sheet não é um recurso social. Get Bananas, Water e o app iOS do ResumeGeni encapsulam, cada um, UIActivityViewController para entregar o conteúdo do próprio usuário ao app que ele escolher.¹³ O conteúdo parte para Mensagens ou Mail e nunca volta a uma superfície que meu app controla, e a definição da Apple gira em torno de redistribuição “por meio de um feed social ou método de descoberta semelhante”, que uma share sheet do sistema não é.⁴ O raciocínio cobre uma fatia grande da App Store: exportar não é publicar.

O Watch Connectivity parece mensageria e não é. Get Bananas e Reps usam WCSession, que move dados entre um telefone e um relógio pareados à mesma pessoa, enquanto o descritor Mensagens e Chat da Apple exige que “Usuários possam se comunicar diretamente entre si.”⁴¹³ O mesmo usuário está nas duas pontas.

O resultado nulo se generaliza, e essa é a parte que vale levar emprestada. Todo app do conjunto guarda conteúdo para quem o criou e o mostra de volta a essa mesma pessoa. O questionário pergunta outra coisa: seu app pega o conteúdo de uma pessoa e o coloca diante de outras por meio de algo que espalha? Rastreadores, cronômetros e ferramentas de estudo respondem “não” por arquitetura, e não por leitura de política. Os apps que precisam pensar são aqueles com qualquer superfície em que usuários vejam o trabalho uns dos outros.

Os deployment targets são o outro número a conferir logo de cara. Seis dos sete projetos com target iOS estão em iOS 26.0 ou posterior; o Ace Citizenship ainda declara 17.0 e 17.5 em alguns targets.¹³ Qualquer coisa abaixo de 26.0 não consegue chamar a API de jeito nenhum, o que elimina a exceção e deixa a declaração simples como única resposta correta.

A lacuna de plataforma aparece no mesmo levantamento, e mais amplamente que a de versão. Quatro dos oito projetos declaram xros xrsimulator em SUPPORTED_PLATFORMS: Reps, Return, Water e Yawara. Reps ainda acrescenta appletvos appletvsimulator e publica um target watchos watchsimulator separado; Return e Banana List também carregam targets watchOS.¹³ Declared Age Range publica disponibilidade para iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0 e macOS 26.0, e nenhuma linha para tvOS, visionOS ou watchOS.⁵ Cada um desses targets deve a declaração de setembro, e em qualquer um deles uma resposta afirmativa põe a exceção fora de alcance, porque a API da qual ela depende não existe ali.

Uma ressalva de método, já que errei isso na primeira passada. XROS_DEPLOYMENT_TARGET aparece em projetos que não têm destino visionOS nenhum, porque o Xcode grava esse ajuste em todas as configurações de build de qualquer jeito. O ResumeGeni carrega XROS_DEPLOYMENT_TARGET = 26.2 e compila apenas iphoneos iphonesimulator.¹³ Leia SUPPORTED_PLATFORMS, não as chaves de deployment target, ou você vai contar plataformas para as quais seu app nem é publicado.

Onde a resposta deixa de ser técnica

A Apple anexa à documentação do Declared Age Range um aviso que vale ler duas vezes: os dados “baseiam-se em informações declaradas por um usuário final, ou por seu pai, mãe ou responsável”, e “Você é o único responsável por garantir a conformidade com leis ou regulamentações associadas que possam se aplicar ao seu app.”¹⁴

Essa frase traça a linha onde o texto para. O questionário da Apple produz uma classificação e um grupo de Time Allowance, e conformidade com coisa nenhuma. A lei australiana exige, desde 10 de dezembro de 2025, que certas plataformas de mídia social impeçam menores de 16 anos de manter conta, e a orientação da Apple sobre essa lei cita a API Declared Age Range como uma ferramenta entre cinco.¹⁵ Questionário e lei se sobrepõem sem coincidir: um pergunta sobre 13, a outra sobre 16, e você tem três limiares para cobrir ambos.

Se o seu app é uma plataforma de mídia social sob determinada lei, a pergunta é para um advogado daquela jurisdição. Se ele tem recursos de mídia social sob o questionário da Apple, a pergunta é sua, respondível hoje contra a definição publicada pela Apple.

Perguntas frequentes

A pergunta sobre mídia social já está no ar no App Store Connect?

Sim. O anúncio da Apple de 9 de julho de 2026 afirma que o questionário “agora inclui perguntas sobre os recursos de mídia social do seu app” e que “Você pode revisar e responder a essas perguntas a partir de hoje.”³ A API do App Store Connect confirma de forma independente, documentando socialMedia e socialMediaAgeRestricted como atributos do recurso AgeRatingDeclaration, ambos graváveis via PATCH /v1/ageRatingDeclarations/{id}.¹ Responder agora não compromete nada: as respostas valem quando você submete, e setembro de 2026 é quando submeter sem elas deixa de funcionar.²

A Apple define “recursos de mídia social”?

Sim, em quatro lugares, com dois escopos diferentes. A Ajuda do App Store Connect traz a versão mais completa, exigindo “Redistribuição, amplificação ou interação com conteúdo gerado por usuários por meio de um feed social ou método de descoberta semelhante que espalhe conteúdo de forma visível para muitos usuários”, e depois lista repostar, curtir, comentar, reagir e aumentar visibilidade como exemplos.⁴ Junho traz a mesma cláusula de escopo; julho a descarta.²³ Como os exemplos são ilustrativos e não exaustivos, a classificação do seu app continua sendo sua, e eu a faria pela página de Ajuda.

Meu app tem conteúdo gerado por usuários. Isso é automaticamente mídia social?

Não. A Apple mantém as duas coisas como perguntas separadas, com definições separadas e consequências de classificação separadas. Conteúdo Gerado por Usuários cobre “a ampla distribuição de conteúdo criado por usuários como componente da experiência pretendida do app”, e aparece na definição de 4+ da Apple.⁴ Mídia social exige redistribuição, amplificação ou interação por meio de um feed ou superfície de descoberta comparável, e aparece primeiro em 13+.⁴ A API espelha a divisão com booleanos independentes userGeneratedContent e socialMedia.¹ Um app em que as pessoas criam conteúdo que só elas veem não é nenhum dos dois.

O que a opção para menores de 13 anos realmente me obriga a construir?

Três coisas, e só a segunda é uma API. A Ajuda do App Store Connect exige que usuários com menos de 13 anos não tenham acesso a recursos de mídia social, que “No mínimo, a API Declared Age Range seja chamada para verificar as faixas etárias dos usuários antes de habilitar recursos de mídia social” e que “Apenas UGC apropriado para a idade seja entregue.”⁴ Então você adiciona o entitlement com.apple.developer.declared-age-range, chama requestAgeRange com 13 entre seus limiares antes que qualquer superfície social apareça, ramifica conforme a resposta — inclusive no caso de recusa, que a Apple deixa indefinido — e, à parte disso, mantém apropriado à idade o conteúdo que entrega a menores.⁵⁶ A API limita você a três limiares e mantém em cache a faixa da pessoa até o aniversário da declaração, então quem faz 13 anos continua sendo lido como mais novo até atualizar os Ajustes.⁷¹⁰

Pontos principais

Para desenvolvedores iOS: - Responda ao questionário esta semana, não em setembro. O campo está no ar, as respostas só valem na submissão, e ler a classificação calculada resolve a questão do 13+ que nenhum dos dois anúncios resolve com clareza.³⁴ - Se você adotar a exceção para menores de 13 anos, planeje-se para três condições, e não para uma chamada de API, e escreva a ramificação de recusa com intenção. .declinedSharing é idêntico a um adulto zeloso com a privacidade, e a Apple não publica orientação sobre para que lado falhar.⁴⁹

Para times em tvOS, visionOS ou watchOS: - Confira a disponibilidade antes de planejar. Declared Age Range publica linhas de iOS, iPadOS, Mac Catalyst e macOS e nada mais, então o mínimo documentado da exceção não existe na sua plataforma, enquanto a declaração de setembro continua valendo para sua submissão.²⁵ - A mesma lacuna pega qualquer target abaixo do iOS 26.0 por outro motivo: sem API, sem exceção, e a declaração simples como única resposta correta.⁵

Para gerentes de release: - Trate a data como gatilho, ao contrário do resto do ciclo. A chave de launch screen e a macro @State disparam com um SDK e uma toolchain que você controla; setembro dispara com uma submissão que você faria de qualquer jeito.² - Leve a resposta a quem responde pela página do produto. Declarar recursos de mídia social acrescenta um descritor de conteúdo Mídia Social à sua listagem na App Store, consequência que a Apple só revelou em julho.³

O ciclo 27 segue classificando suas mudanças pelo que as dispara: uma configuração de build, uma toolchain, um aviso do compilador e agora um calendário. Para a descontinuação do mesmo ciclo com os dentes mais fracos e a maior migração por trás, veja On Demand Resources e o que o Background Assets custa. O hub completo da série é a Série Ecossistema Apple.

Referências