Slicing: o que é, princípio de funcionamento e relação com App Thinning

O que é Slicing

Slicing é um componente do App Thinning responsável por criar variantes (fatias) do arquivo binário do aplicativo no lado da App Store. Quando o desenvolvedor envia um binário universal (fat binary) contendo código e recursos para todas as configurações suportadas, a App Store o analisa e gera múltiplas fatias: separadamente para iPhone com processador A17, separadamente para iPad com M4, separadamente para Apple Watch. Cada fatia contém apenas os fragmentos de código e recursos necessários para aquela combinação específica de arquitetura e resolução.

Antes do iOS 9, os desenvolvedores criavam manualmente arquivos binários separados para diferentes dispositivos ou distribuíam um fat binary universal que continha tudo de uma vez. O Slicing automatizou completamente esse processo: o desenvolvedor prepara um projeto no Xcode, envia um arquivo para o App Store Connect, e o Slicing no lado do servidor cria a quantidade ideal de variantes. O usuário nunca vê o processo de fatiação — ele recebe um .app pronto, otimizado para seu dispositivo.

O Slicing se aplica não apenas a código e imagens, mas também a shaders Metal. A GPU da Apple usa seu próprio conjunto de instruções (Metal Shading Language), que difere das instruções PowerVR ou ARM Mali. O Slicing inclui na fatia apenas shaders para a família de GPU do dispositivo alvo. Isso é especialmente importante para jogos com shaders personalizados — por exemplo, efeitos de pós-processamento de alta qualidade são compilados apenas para dispositivos com GPU potente (iPad Pro M4, iPhone 16 Pro Max).

Diferença entre Slicing e compilação simples por arquitetura

O compilador do Xcode cria um fat binary com múltiplas arquiteturas (armv7, arm64, arm64e), mas não remove recursos — todas as imagens para todas as resoluções permanecem dentro do .app. O Slicing vai além: ele analisa Asset Catalogs, shaders Metal e bibliotecas Swift, removendo de cada fatia o que não é necessário para o alvo específico. Por exemplo, gráficos @3x não vão para a fatia do iPhone SE, e controladores específicos do iPhone (se extraídos em recursos separados) não vão para a fatia do iPad Air.

Como funciona o Slicing

O processo de Slicing começa após o envio do build para o App Store Connect e consiste em três etapas: análise, fatiação e empacotamento. Na etapa de análise, o servidor da App Store analisa o arquivo binário, extrai informações sobre arquiteturas, dispositivos, resoluções de tela e versões do iOS suportadas. A App Store usa um mapeamento de todos os modelos comerciais da Apple para suas especificações técnicas — o Banco de Dados de Dispositivos é atualizado a cada versão do iOS.

Na etapa de fatiamento, o servidor cria cópias separadas do arquivo binário para cada combinação única. Para isso, a App Store extrai imagens dos Asset Catalogs com tags específicas (idiom, subtype, scale), seleciona apenas aquelas que correspondem ao dispositivo alvo e monta um novo pacote de recursos. A biblioteca padrão do Swift também é submetida ao fatiamento — símbolos e métodos não utilizados são removidos dela (dead code stripping).

Na etapa de empacotamento, cada fatia é colocada em um pacote de distribuição separado e vinculada a metadados — uma lista de modelos de dispositivo para os quais esta fatia é destinada. Quando o usuário baixa o aplicativo, a App Store seleciona a fatia apropriada de acordo com o modelo do dispositivo, versão do iOS e tipo de conexão. Se não houver correspondência exata, o servidor usa a fatia mais próxima em características. A Apple armazena todas as variantes na rede CDN do CloudKit para entrega rápida em todo o mundo.

Slicing no contexto do App Thinning

O Slicing é um dos três mecanismos do App Thinning, mas é o que mais contribui para reduzir o tamanho do download. O Bitcode é responsável pela otimização do código de máquina, o On-Demand Resources pelo gerenciamento de recursos no dispositivo, e o Slicing por remover recursos redundantes na etapa de distribuição. Sem o Slicing, os dois primeiros mecanismos ainda funcionam, mas os usuários recebem recursos para todos os dispositivos, aumentando o tamanho em 20–40% dependendo da quantidade de Asset Catalogs.

A diferença entre Slicing e Bitcode está no ponto de aplicação: o Slicing trabalha no nível de recursos (imagens, shaders, arquivos NIB), o Bitcode no nível de código de máquina. O Slicing divide o código por arquiteturas (arm64 vs arm64e), o Bitcode permite que a Apple recompile o código para novas arquiteturas. Bitcode + Slicing juntos fornecem a máxima otimização: o Bitcode gera código para uma arquitetura específica, e o Slicing remove os recursos desnecessários para essa arquitetura.

A relação com On-Demand Resources — Slicing e ODR não se sobrepõem. O Slicing determina quais recursos chegarão à distribuição no dispositivo, enquanto o ODR gerencia quando esses recursos são carregados e descarregados. O desenvolvedor pode marcar um recurso com uma tag ODR, e o Slicing o incluirá na fatia se corresponder ao dispositivo. A Apple recomenda usar os três mecanismos simultaneamente para o tamanho mínimo de instalação.

Variantes de Slicing para diferentes dispositivos

O Slicing cria fatias separadas de acordo com várias dimensões: arquitetura do processador, tamanho da tela (resolução), versão do iOS e família de GPU (para Metal). A arquitetura determina o conjunto de instruções da CPU: arm64 — conjunto básico de 64 bits (iPhone 5s — iPhone X), arm64e — conjunto estendido com suporte a Pointer Authentication e PAC (iPhone XS e posteriores, iPad Pro com A12X+). A fatia para arm64e inclui código com instruções de proteção de memória não disponíveis em dispositivos arm64.

Resolução de tela — a segunda dimensão chave do Slicing. A Apple usa escalas @1x (iPhone 3GS), @2x (iPhone 4 — iPhone SE 3), @3x (iPhone 6 Plus e posteriores) e específicas para iPad (2x e 3x com métricas adicionais). O Slicing inclui na fatia apenas imagens com a escala correspondente ao dispositivo alvo. Com a organização adequada dos Asset Catalogs no Xcode, isso elimina a necessidade de gerenciar manualmente conjuntos de recursos — basta adicionar uma imagem ao catálogo, indicando os tipos de dispositivo suportados.

Família de GPU — a terceira dimensão, de importância crítica para aplicativos Metal. A Apple classifica as GPUs por gerações: Apple GPU family 1 (A7), family 2 (A8), ... family 8 (M4). Os shaders Metal são compilados para cada família separadamente, pois o conjunto de instruções do Metal Shading Language se expande a cada geração de GPU. O Slicing inclui na fatia apenas shaders para a família de GPU do dispositivo alvo, reduzindo significativamente o tamanho de jogos e aplicativos que usam Metal para renderização.

Impacto da arquitetura no tamanho da fatia

A arquitetura da CPU afeta diretamente o tamanho da fatia: o código arm64e contém instruções adicionais de Pointer Authentication (PAC) e Signed Return Address, que aumentam o arquivo binário em 5–10% em comparação com arm64. No entanto, esse aumento é compensado pelo fato de que o Slicing inclui código arm64e apenas em fatias para dispositivos com processadores A12+. Para o iPhone SE (terceira geração) com A15 Bionic, o Slicing cria uma fatia separada otimizada para as capacidades deste chip.

Configuração do Slicing no Xcode

A configuração do Slicing no Xcode é mínima — a configuração principal é feita através de Asset Catalogs e Build Settings. O Asset Catalog deve conter recursos organizados por tipo de dispositivo (Any, iPhone, iPad, Apple Watch, Apple TV) com a escala e o modo de exibição corretamente indicados. O Xcode inclui automaticamente na compilação apenas os recursos que correspondem aos dispositivos alvo especificados nas configurações de Deployment Target.

A configuração chave do Slicing no Xcode é o Build Setting App Thinning. Valores disponíveis:

• None — Slicing desativado, o aplicativo é distribuído como fat binary universal
• Automatic — Xcode ativa o Slicing com configurações padrão
• Manual — o desenvolvedor seleciona combinações específicas para o Slicing

Targeted Device Families em General → Deployment Info determina para quais tipos de dispositivo o aplicativo é compilado (iPhone / iPad / Universal). O Slicing depende deste parâmetro ao fatiar — se o aplicativo suporta apenas iPhone, uma fatia para iPad não é criada. O Deployment Target (versão mínima do iOS) também afeta o Slicing: versões antigas do iOS podem exigir fatias armv7, que não são necessárias para iOS 13+. A Apple recomenda definir o Deployment Target para a versão estável mais recente do iOS — isso reduz o número de fatias e o tamanho do binário.

Parâmetros do Asset Catalog para Slicing

Para máxima eficiência do Slicing, os Asset Catalogs devem usar tags específicas para cada recurso. O Xcode fornece no Attributes Inspector para imagens: Width Class (Any, Compact, Regular), Height Class (Any, Compact, Regular), Gamut (sRGB, Display P3), Memory (Any, Low, High), Graphics (Any, Low, High). Combinando essas tags, o desenvolvedor controla em quais fatias cada imagem aparece. Por exemplo, uma imagem para iPad com as tags Regular Width + Regular Height aparecerá apenas em fatias para iPad na orientação paisagem.

# Exportar fatia para um dispositivo específico
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "sliced/" \
  -exportOptionsPlist "export.plist" \
  -thinning "iPhone17,2" # iPhone 16 Pro Max

Xcodebuild com o parâmetro -thinning e o identificador do modelo cria uma fatia apenas para esse modelo. A lista de identificadores pode ser encontrada no Banco de Dados de Dispositivos da Apple (formato: iPhone17,2 — iPhone 16 Pro Max, iPad14,1 — iPad Pro 11 M4). Este método é útil para verificar o tamanho da fatia antes de enviar ao App Store Connect. CI/CD pode usar este comando para verificação automática — se o tamanho da fatia exceder o limite (por exemplo, 100 MB para download móvel), o pipeline emite um aviso.

Verificação dos resultados do Slicing

Após enviar o arquivo para o App Store Connect, a Apple fornece estatísticas detalhadas sobre os tamanhos das fatias. App Store Connect → Activity → selecione o build → App Thinning — exibe o Estimated App Store Size para cada categoria de dispositivo: iPhone, iPad, Apple Watch, tvOS. Os tamanhos são detalhados por versões do iOS e tipos de processador. Se alguma fatia exceder o tamanho esperado, o App Store Connect a marca com um aviso amarelo.

Verificação local através do Xcode Organizer: após arquivar, abra Window → Organizer, selecione o arquivo e clique em App Thinning Profiles. O Xcode mostrará os tamanhos para cada fatia possível com base na configuração atual do projeto. A opção Export também está disponível para criar um IPA com um perfil de Slicing específico. O Xcode gera um arquivo .app-thinning.plist com informações sobre quais recursos estão incluídos em cada fatia.

Para automatizar a verificação do Slicing em CI/CD, use xcodebuild com -thinning e analise o tamanho dos arquivos .app criados. A Apple fornece o utilitário de linha de comando app-size (instalado via Xcode Command Line Tools), que gera um relatório detalhado: tamanho do código, tamanho dos recursos por categoria (imagens, shaders, NIB), tamanho das bibliotecas Swift. A comparação dos tamanhos das fatias antes e depois da otimização dos Asset Catalogs ajuda a identificar recursos que não participam do Slicing devido a configuração incorreta.

# Analisar o tamanho da fatia
app-size -m "sliced/App.app" \
  --format json

App-size gera um relatório JSON detalhado por categorias de recursos. Se o Slicing estiver configurado corretamente, na seção "images" aparecerá apenas um conjunto de escala (@2x ou @3x), não todas as variantes. Um erro de configuração do Asset Catalog se manifesta quando todas as escalas (@1x, @2x, @3x) estão presentes na fatia — isso significa que o Xcode não conseguiu determinar o dispositivo alvo para essas imagens e o Slicing não funcionou.