App Thinning — o que é, de quais componentes consiste e como funciona

O que é App Thinning

App Thinning — é uma tecnologia abrangente de otimização de distribuição de aplicativos iOS, introduzida pela Apple junto com o iOS 9 (setembro de 2015). O objetivo do App Thinning é minimizar o tamanho do aplicativo que o usuário baixa em seu dispositivo, sem alterar o código-fonte e a funcionalidade. A tecnologia funciona em três níveis: na fase de compilação, no lado da App Store (distribuição) e no dispositivo (gerenciamento de recursos).

Antes do App Thinning, os desenvolvedores incluíam no arquivo binário recursos para todos os dispositivos possíveis — imagens @2x e @3x, código de 32 e 64 bits, shaders Metal para diferentes GPUs. Isso levava ao inchaço do tamanho do aplicativo: um usuário de iPhone 6 Plus com tela Retina HD recebia recursos vetoriais para iPad Pro que nunca eram usados. A Apple resolveu esse problema transferindo parte do trabalho de compilação para os servidores da App Store.

De acordo com pesquisas da Apple (WWDC 2015, Session 412), um aplicativo típico com suporte a várias arquiteturas e resoluções pode ser reduzido em 30-50% após a aplicação do App Thinning. Para jogos com grande quantidade de texturas de alta definição, o ganho pode chegar a 70-80%. A Apple continua melhorando a tecnologia: no iOS 17, foram adicionadas otimizações para ARM64e e melhorias no trabalho com On-Demand Resources para aplicativos que usam Swift Package Manager.

O problema que o App Thinning resolve

O tamanho dos aplicativos móveis continua crescendo. De acordo com a Sensor Tower (2025), o tamanho médio dos aplicativos iOS cresceu 45% nos últimos 5 anos. Para usuários com plano de dados limitado ou internet lenta, cada megabyte importa. O App Thinning resolve esse problema sem a participação do desenvolvedor — basta ativar o suporte nas configurações do projeto e enviar o build para o App Store Connect.

Como funciona o App Thinning

O processo de App Thinning começa após o upload do arquivo do aplicativo no App Store Connect. A App Store analisa o arquivo binário e o divide em segmentos por arquiteturas (armv7, arm64, arm64e), resoluções de tela (iPhone, iPad) e versões do iOS. Para cada combinação, é criada uma variante separada. Quando o usuário clica em “Baixar”, a App Store determina o modelo do dispositivo, a versão do iOS e o tipo de conexão (Wi-Fi / rede móvel) e envia apenas a variante correspondente.

Para o usuário, o processo é transparente — não há opção de “versão leve” ou diálogo de configurações. A App Store seleciona automaticamente a variante mais adequada com base nos metadados do dispositivo, que são enviados ao servidor na solicitação de download. Se o dispositivo usa Wi-Fi, a App Store pode enviar uma variante com recursos de maior qualidade (por exemplo, vídeo ProRes para iPhone 16 Pro). Ao baixar pela rede móvel, é usado o conjunto mínimo possível.

O segundo nível de otimização — Bitcode. Quando a opção ENABLE_BITCODE está ativada, o Xcode compila o aplicativo não em código de máquina, mas em uma representação intermediária LLVM. A App Store recompila o Bitcode para a arquitetura do processador do usuário, permitindo que a Apple aplique otimizações do compilador para novas gerações de chips (A17, M4) sem que o desenvolvedor atualize o aplicativo. O Bitcode é obrigatório para watchOS e tvOS, mas opcional para iOS.

Componentes do App Thinning: Slicing, Bitcode, ODR

O App Thinning consiste em três mecanismos independentes, cada um responsável por seu aspecto de otimização. O Slicing divide o arquivo binário em variantes por arquitetura e resolução de tela. O desenvolvedor configura o Slicing através dos Asset Catalogs — o Xcode inclui automaticamente no slice apenas os recursos que correspondem ao dispositivo alvo. Por exemplo, o iPhone SE (terceira geração) receberá apenas imagens @2x e código arm64, enquanto o iPad Pro M4 receberá imagens @3x e código arm64e.

Bitcode — é LLVM IR (Intermediate Representation) — uma representação do programa independente de máquina. Quando o Bitcode está ativado, o Xcode não gera o código de máquina final, mas salva a representação intermediária. O App Store Connect ao enviar o build recebe o Bitcode e o recompila para as arquiteturas de todos os dispositivos suportados. O Bitcode permite que a Apple aplique otimizações indisponíveis na fase de compilação do desenvolvedor — por exemplo, o uso de novas instruções do processador (SME, SVE) nos chips M4.

On-Demand Resources (ODR) — o terceiro mecanismo, que permite descarregar recursos do aplicativo após o uso. O desenvolvedor marca recursos (níveis de jogo, imagens para onboarding, vídeos) com tags ODR. O iOS baixa os recursos marcados conforme necessário em segundo plano e os descarrega quando há falta de memória ou após o uso. ODR é especialmente eficaz para jogos com grande quantidade de conteúdo — os primeiros níveis podem ser fornecidos com o aplicativo, e os restantes baixados conforme o progresso.

Quando escolher cada componente

A escolha dos mecanismos do App Thinning depende do tipo de aplicativo e seu público-alvo. O Slicing é recomendado sempre ativar — não requer ações adicionais do desenvolvedor além da organização correta dos Asset Catalogs e proporciona uma redução estável de 20-30% no tamanho. O Bitcode vale a pena ativar se o aplicativo usa shaders Metal personalizados ou planeja suportar novas arquiteturas da Apple sem recompilação. O ODR é justificado para aplicativos com grande volume de conteúdo — jogos, editores de foto, aplicativos de streaming.

Para um aplicativo empresarial típico (feed de dados, formulários, API REST), Slicing e configuração mínima de ODR para imagens de onboarding são suficientes. Jogos com gráficos 3D se beneficiam de todos os três mecanismos: Slicing remove shaders desnecessários, Bitcode otimiza a renderização para a GPU, e ODR descarrega níveis concluídos. De acordo com a Apple (WWDC 2024), a combinação de todos os três mecanismos reduz o tamanho inicial da instalação em média 45-55% em comparação com o binário universal.

Configurando App Thinning no Xcode

Para ativar o App Thinning em um projeto Xcode, é necessário seguir várias etapas. O Slicing é configurado através do App Thinning nas configurações de compilação: Build Settings → App Thinning. Três valores estão disponíveis: None (sem otimização), Automatic (configuração automática padrão) e Manual com seleção de variantes específicas para teste. A Apple recomenda Automatic para a maioria dos projetos.

Para Asset Catalogs, é importante organizar corretamente os recursos: as imagens são colocadas em um catálogo universal com indicação de largura/altura, e o Xcode cria automaticamente variantes @1x, @2x e @3x. O Xcode ao compilar inclui apenas as resoluções usadas no projeto. Os shaders Metal são compilados separadamente para cada família de GPU — Apple GPU, PowerVR, Mali, o que também é gerenciado através dos Asset Catalogs.

O Bitcode é ativado pela flag ENABLE_BITCODE = YES nas Build Settings. Para iOS, esta flag é opcional (desativada por padrão desde o Xcode 14), mas para watchOS e tvOS é obrigatória. Ao ativar o Bitcode em um projeto que usa bibliotecas de terceiros, todas elas também devem ser compiladas com Bitcode, caso contrário a compilação falhará. O Bitcode aumenta o tempo de compilação em 20-30%, mas oferece compatibilidade total com arquiteturas futuras.

Verificando os resultados do App Thinning

Após o upload no App Store Connect, é possível verificar os tamanhos dos slices na seção Activity → Build Metric. O App Store Connect exibe o Estimated App Store Size para diferentes dispositivos. Para verificação local, o Xcode fornece o comando xcodebuild com a flag -exportArchive e a opção thinning para criar slices na máquina local. O resultado do Slicing pode ser visto no Organizer (Window → Organizer) após a arquivação — a aba App Thinning Profiles mostra os tamanhos para diferentes dispositivos.

# Verificação local do Slicing
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "export/" \
  -exportOptionsPlist "export.plist" \
  -thinning "<thin-for-all-variants>"

O Xcodebuild com a flag -thinning cria arquivos .app para cada combinação de arquitetura, largura de bits e GPU. O parâmetro <thin-for-all-variants> cria todas as variantes possíveis — útil para verificação. Para pipelines de CI, especifique uma combinação específica, como iPhone14,4 (iPhone SE 3). Os arquivos .app resultantes podem ser analisados com o utilitário app-size.

Benefícios e impacto do App Thinning

A principal vantagem do App Thinning é a redução do tamanho do download para o usuário final. De acordo com a Apple (WWDC 2024), um aplicativo típico usando todos os três mecanismos do App Thinning é baixado em média 40% mais rápido pela rede móvel e ocupa 35% menos espaço em disco. Isso afeta diretamente a conversão de instalação: de acordo com a Sensor Tower, cada 10 MB de tamanho do aplicativo reduzem a conversão em 1%.

A segunda vantagem — otimização para dispositivos futuros através do Bitcode. A Apple pode recompilar aplicativos Bitcode para novas arquiteturas sem a participação do desenvolvedor. Por exemplo, durante a transição da Intel para Apple Silicon (M1), os aplicativos Bitcode funcionavam no macOS através do Rosetta 2 sem compilação adicional. Os desenvolvedores que não ativaram o Bitcode tiveram que recompilar seus aplicativos para arm64.

A terceira vantagem — ODR (On-Demand Resources) reduz a carga no armazenamento do dispositivo. Jogos com dezenas de níveis, como Asphalt 8: Airborne, usam ODR para baixar novas pistas conforme o progresso. O desenvolvedor pode definir Initial Install Tags para recursos que são baixados junto com o aplicativo, e Prefetch Tags para conteúdo que é baixado em segundo plano após a instalação. A Apple controla os limites de ODR: até 512 MB por solicitação e até 20 GB de cache total no dispositivo.

Limitações do App Thinning

O App Thinning tem várias limitações importantes que devem ser consideradas ao projetar o aplicativo. Primeiro, o Slicing não se aplica a aplicativos distribuídos via Enterprise (in-house) ou Ad Hoc — esses builds contêm todas as variantes e não passam pela App Store. Para testar o Slicing, o desenvolvedor pode usar o TestFlight, que também processa o Slicing nos servidores da Apple.

Segundo, o Bitcode aumenta o tempo de compilação e o tamanho do arquivo .xcarchive em cerca de 30-50%. Nem todas as bibliotecas de terceiros suportam Bitcode — se pelo menos uma dependência for compilada sem Bitcode, a compilação do projeto com ENABLE_BITCODE falhará. A Apple recomenda verificar a compatibilidade das bibliotecas antes de ativar o Bitcode. Além disso, o Bitcode não suporta o Swift Package Manager em sua totalidade — alguns pacotes Swift podem quebrar a compilação com Bitcode.

Terceiro, os On-Demand Resources não garantem disponibilidade instantânea do conteúdo — o download de ODR ocorre em segundo plano e pode ser adiado se o dispositivo estiver em modo de baixa bateria ou sinal fraco. O desenvolvedor deve implementar o tratamento dos status de download de ODR através do NSBundleResourceRequest e mostrar um indicador de progresso ao usuário. Uma falha no download de ODR não deve bloquear a funcionalidade do aplicativo — é necessário um graceful fallback.