Store sob Ternus: como devs iOS devem se preparar

A notícia que veio do Olhar Digital sobre a possível reformulação da App Store sob John Ternus me chamou atenção por um motivo simples: a App Store não é só uma vitrine — é o motor de receita mais previsível da Apple, e qualquer mudança nela respinga direto no código, na estratégia de monetização e na arquitetura de qualquer produto que roda em iOS. E eu, como dev, já vi muita gente tomar decisões ruins justamente porque ignorou como essa engrenagem funciona por dentro.

Por que a App Store importa mais do que parece

Muita gente olha para a App Store como “um lugar onde o app fica exposto”. Na prática, ela é uma camada de infraestrutura comercial que influencia desde a escolha de linguagem até o modelo de assinatura. Quando a Apple mexe nas comissões, no review guideline ou na política de assinaturas, eu preciso repensar:

• O pricing tier do meu app;
• Se vale manter compra única ou migrar para assinatura;
• Como implementar StoreKit 2 de forma resiliente;
• Se vou usar o próprio sistema de pagamento ou cair para a regra do “External Purchase Link” (que no Brasil ainda tem suas particularidades).

Quando Ternus assume com Eddy Cue puxando a estratégia de Serviços, o sinal é claro: a Apple quer crescer receita recorrente. E onde cresce receita recorrente? Em assinaturas, no IAP (In-App Purchase) e em serviços como Apple Music, iCloud e Apple TV+. O iOS dev que ignora isso vai continuar brigando por 70/30 enquanto concorrentes ajustam o jogo.

O que muda (de verdade) com Ternus

O ponto central da reportagem é a saída de Phil Schiller, que discordava de medidas mais rígidas. Schiller sempre foi o “escudo” dos desenvolvedores dentro da Apple — alguém que, mesmo aplicando as regras, ouvia a comunidade. Com ele como Apple Fellow, a linha de frente muda.

Na minha experiência, três coisas tendem a acontecer quando uma big tech troca o “rosto diplomático” por um perfil mais focado em margem:

1. Compressão de exceções: regras que eram interpretadas com bom senso passam a ser aplicadas à risca;
2. Novas categorias de taxa: lembrem do “Apple Tax” para apps que usam sistemas externos de pagamento — 27% na União Europeia e 12% nos EUA em casos específicos;
3. Padronização de fluxos de receita: a Apple tende a fechar portões, não abrir.

Isso não é teoria. Foi exatamente o que aconteceu quando a Apple abriu brechas para reader apps e links externos após pressão da Digital Markets Act. Foi uma exceção, não uma diretriz. Ternus provavelmente vai tratar exceções como negócio, não como concessão.

Comparativo real: App Store vs. Google Play vs. alternativas

O que eu vejo no dia a dia é que devs pequenos (< 100k MRR) ainda vivem confortavelmente no fee reduzido de 15%. Já produtos escalando acima disso precisam tomar uma decisão estratégica: continuam pagando a "Apple Tax" inteira ou se preparam para um mundo onde parte do faturamento vai pra fora da loja?

Na Prática: implementando StoreKit 2 com fallback resiliente

Se você tem um app iOS hoje, minha recomendação é abandonar o StoreKit 1. Ele está deprecated e qualquer mudança regulatória pode quebrar seu fluxo de verificação de recibos. Veja um exemplo funcional em Swift de como validar uma transação e restaurar compras:

import StoreKit

@MainActor
final class SubscriptionManager: ObservableObject {
    @Published private(set) var products: [Product] = []
    @Published private(set) var activeEntitlements: Set<String> = []

    func loadProducts() async {
        do {
            let ids = ["pro_monthly", "pro_yearly"]
            self.products = try await Product.products(for: ids)
        } catch {
            print("Falha ao carregar produtos: \(error)")
        }
    }

    func purchase(_ product: Product) async throws -> Transaction? {
        let result = try await product.purchase()
        switch result {
        case .success(let verification):
            let transaction = try checkVerified(verification)
            await updateEntitlements(with: transaction)
            await transaction.finish()
            return transaction
        case .pending, .userCancelled:
            return nil
        @unknown default:
            return nil
        }
    }

    func restorePurchases() async {
        for await result in Transaction.currentEntitlements {
            if case .verified(let transaction) = result {
                activeEntitlements.insert(transaction.productID)
            }
        }
    }

    private func checkVerified(_ result: VerificationResult<Transaction>) throws -> Transaction {
        switch result {
        case .verified(let transaction):
            return transaction
        case .unverified(_, let error):
            throw error
        }
    }

    private func updateEntitlements(with transaction: Transaction) async {
        if transaction.revocationDate == nil {
            activeEntitlements.insert(transaction.productID)
        } else {
            activeEntitlements.remove(transaction.productID)
        }
    }
}

Esse padrão cobre três cenários que a Apple costuma apertar na revisão: compra legítima, restauração em outro dispositivo e revogação. Quando Ternus apertar as regras, é esse tipo de implementação que sobrevive a um app review sem rejeição.

Implicações práticas para o dev brasileiro

Trabalho com clientes no Brasil que publicam na App Store, e o que eu percebo é:

• BRL vs. USD: muitos devs ainda precificam errado por não entenderem o ajuste de tabela da Apple. A Apple faz uma atualização anual do “Developer Price Tier” e isso impacta diretamente a margem em real;
• Imposto sobre serviço digital: a App Store recolhe em alguns mercados, em outros não. No Brasil, há o ISS e a reforma tributária em curso — quem vende assinatura precisa entender de onde sai o imposto;
• Nota fiscal: sim, a Apple é intermediária, mas o dev é o prestador final do serviço em vários cenários B2B. Muitos ignoram isso;
• Latência de payout: o ciclo padrão da Apple é mensal, e atrasos acontecem. Ter um fluxo de caixa que depende 100% da App Store é arriscado.

Erros comuns que devs cometem (e que vão doer mais com Ternus)

• Ignorar o guideline 3.1.2 sobre subscrições. A Apple está rejeitando mais apps que escondem cancelamento, não mostram preço em reais ou usam linguagem enganosa no paywall;
• Esquecer o receipt validation server-side. Não adianta validar só no client. Eu sempre implemento App Store Server Notifications com endpoint próprio e idempotência;
• Acumular SKUs não vendidos. A Apple avalia o “merchandising” do seu app. SKUs paradas geram dúvida na revisão e podem atrasar updates;
• Subir versão sem atualizar privacy manifest. Desde 2024, o Privacy Manifest é obrigatório. Muitos apps antigos ainda usam SDKs sem declarar — e isso vira rejeição direta;
• Confundir “External Purchase Link” com “Sideloading”. São coisas diferentes. O primeiro é permitido (com taxa) em alguns mercados, o segundo continua proibido;
• Não monitorar a taxa de reembolso. A Apple oferece métricas no App Store Connect. Taxa alta de reembolso aciona análise manual e bloqueia updates.

O que eu faria se tivesse um app grande na App Store hoje

1. Diversificar receita. Pelo menos 30% do faturamento fora da loja: venda direta via web, B2B via invoice, white-label para outros apps;
2. Construir uma camada de billing independente. Use um gateway seu (Stripe é o padrão) e sincronize com a App Store só quando obrigatório;
3. Mapear todas as “pontas soltas” regulatórias. DMA na Europa, Lei dos Mercados Digitais em outros lugares, pressão da Epic e do CADE no Brasil — o cenário está se movendo;
4. Investir em web app e PWA. Mesmo com limitações de push e IAP, dá para capturar parcela significativa do público que não quer instalar nada;
5. Ter um fallback de comunicação. E-mail marketing e login próprio são ativos que a Apple não controla. Se o review travar seu app, você ainda fala com seu usuário.

FAQ — Perguntas que devs realmente fazem

1. A Apple pode aumentar a comissão para além de 30%?

Na prática, sim. Já existem categorias com 30% + 3% de “Apple Services Fee” para apps que usam o sistema de pagamento alternativo. A tendência, com Ternus focado em margem, é criar mais camadas, não reduzir.

2. Vale a pena sair da App Store e distribuir direto?

No Brasil e no mundo ocidental, ainda não vale. Você perde alcance, confiança e segurança. Faz sentido como complemento (web, PWA, venda B2B), não como substituição.

3. Como a saída do Phil Schiller afeta o review de apps?

Historicamente, Schiller suavizava interpretações rígidas. Sem ele na linha de frente, espere rejeições mais literais — especialmente em apps que usam APIs privadas, fazem login fora do padrão ou omitem disclosures.

4. StoreKit 2 vai substituir o StoreKit 1 definitivamente?

Sim. StoreKit 1 já está deprecated. O modelo novo, baseado em Swift async/await e JWS, é o caminho. Migrar agora evita dor de cabeça quando a Apple desligar o suporte ao modelo antigo.

5. Pequenos devs vão ser prejudicados com Ternus?

O programa de 15% para devs com menos de US$ 1M/ano deve continuar — é politicamente difícil cortar. O risco maior está nos devs médios, que pagam 30% e não têm peso político para negociar.

Considerações finais

O que o Olhar Digital trouxe como notícia, eu enxergo como sinal: a Apple está entrando em fase de “otimização agressiva” sob Ternus. Isso não significa desastre, mas exige que devs iOS parem de tratar a App Store como um monopólio benevolente. Tratem como um canal — importante, mas não único. Quem construir com resiliência, com camada própria de billing e com atenção a compliance vai surfar a mudança. Quem ignorar, vai descobrir da pior forma no próximo App Review.

Se você está publicando na App Store hoje, faça um code review do seu fluxo de IAP esta semana. Aposto que vai encontrar pelo menos uma fricção que pode te custar uma rejeição no próximo update.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.