expo-dev-client

Visão geral da skill expo-dev-client

O que a expo-dev-client faz

A skill expo-dev-client ajuda você a decidir se realmente precisa de um Expo development client e, em seguida, orienta a configurar e gerar esse client com EAS Build localmente ou para o TestFlight. O papel dela não é só “fazer uma build”, e sim “colocar um app de teste com capacidades nativas personalizadas em dispositivos reais sem ficar adivinhando pela documentação do Expo”.

Quem deve usar esta skill

Esta skill é mais indicada para:

• times que usam Expo e estão adicionando módulos nativos
• desenvolvedores testando módulos Expo locais ou código nativo customizado
• apps que usam targets específicos da Apple, como widgets, app clips ou extensions
• equipes que precisam de um caminho repetível para testes internos no iOS via TestFlight

Se o seu app roda totalmente no Expo Go, esta skill expo-dev-client normalmente não é necessária.

A principal decisão de instalação

A maior pergunta antes de adotar é simples: você precisa mesmo de um development client? A skill expo-dev-client é valiosa porque responde isso logo no início. Ela orienta explicitamente a testar primeiro com Expo Go usando npx expo start, o que evita tempo perdido com builds e complexidade desnecessária no EAS.

O que diferencia a expo-dev-client de um prompt genérico sobre Expo

Um prompt genérico pode mandar um agente “configurar Expo dev client”, mas esta skill expo-dev-client é mais orientada à decisão. Ela foca em:

• qual é o limiar a partir do qual um dev client passa a ser necessário
• qual formato o eas.json precisa ter
• a diferença entre builds locais e builds em nuvem/TestFlight
• o caminho prático de comandos para testes em dispositivos físicos no estilo de distribuição

Isso a torna mais útil para setup e fluxos próximos de release do que um prompt amplo sobre Expo.

Como usar a skill expo-dev-client

Instale a skill expo-dev-client

Instale no seu ambiente compatível com skills com:

npx skills add https://github.com/expo/skills --skill expo-dev-client

Como esta skill é enxuta e está concentrada em SKILL.md, a instalação serve principalmente para deixá-la disponível para reutilização em tarefas de teste nativo com Expo.

Comece pelo objetivo do trabalho, não pelo comando

Antes de acionar a skill expo-dev-client, defina o objetivo real:

• “Adicionamos um SDK nativo e precisamos testar em um iPhone”
• “Precisamos de um dev client por branch para QA”
• “Nosso app agora inclui um widget, então o Expo Go já não basta”
• “Queremos uma development build de iOS distribuída via TestFlight”

Isso importa porque a skill expo-dev-client funciona melhor quando a necessidade de código nativo customizado está claramente estabelecida.

Verifique primeiro se o Expo Go já resolve

Um erro comum é recorrer à expo-dev-client cedo demais. O primeiro teste recomendado é:

npx expo start

Se o app funcionar no Expo Go, pare por aí. Um development client adiciona tempo de build, exigências de assinatura e overhead de distribuição. Use esta skill expo-dev-client só quando as capacidades nativas realmente exigirem esse passo.

Entenda os sinais de melhor encaixe

Use expo-dev-client quando o projeto incluir:

• módulos Expo locais
• código nativo customizado
• módulos nativos de terceiros indisponíveis no Expo Go
• targets da Apple, como widgets, app clips ou extensions

São esses os casos em que um dev client deixa de ser “opcional” e passa a ser “obrigatório”.

Prepare o mínimo de contexto que um agente precisa

Se você quer que um agente use bem a skill expo-dev-client, informe:

• plataforma de destino: ios, android ou ambas
• caminho de distribuição pretendido: instalação local, teste interno ou TestFlight
• se o app já tem EAS configurado
• o seu eas.json atual
• se o app usa módulos nativos não suportados pelo Expo Go
• quaisquer restrições de versionamento ou assinatura

Sem esse contexto, o agente ainda pode sugerir comandos, mas pode errar o profile de build ou prescrever configuração demais.

Use um prompt melhor do que “configure expo-dev-client”

Um prompt fraco:

Configure expo-dev-client.

Um prompt mais forte:

Use a skill expo-dev-client para determinar se este app Expo precisa de um dev client. Adicionamos um SDK nativo iOS de terceiros e precisamos de uma development build distribuída via TestFlight para QA interno. Revise este eas.json, identifique configurações ausentes e forneça os comandos exatos para build e envio.

Por que isso funciona melhor:

• pede primeiro a validação de encaixe
• explicita o gatilho nativo
• define o fluxo de trabalho alvo
• fornece configuração para correção concreta

Configure o eas.json corretamente

A configuração principal destacada pela skill expo-dev-client é um profile de development build com developmentClient: true, normalmente junto com automação de versão:

{
  "cli": {
    "version": ">= 16.0.1",
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true
    },
    "development": {
      "autoIncrement": true,
      "developmentClient": true
    }
  },
  "submit": {
    "production": {},
    "development": {}
  }
}

Os campos mais importantes são:

• developmentClient: true: informa ao EAS que ele deve empacotar o development client
• autoIncrement: true: reduz atrito com número de build
• appVersionSource: "remote": mantém o versionamento consistente via EAS

Gere para o TestFlight quando o teste remoto em dispositivos for importante

Para equipes iOS, o caminho de maior valor de uso de expo-dev-client costuma ser o TestFlight:

eas build -p ios --profile development --submit

Este é o fluxo prático de expo-dev-client for Deployment quando você precisa de um app com capacidades de desenvolvimento distribuído para testers, e não apenas de um artefato local. Ele combina build em nuvem e envio, o que normalmente é mais rápido do que montar etapas separadas.

Use builds locais quando velocidade ou privacidade importarem

Se você não precisa de TestFlight, builds locais podem ser o melhor fluxo:

• iteração mais rápida em alguns ambientes
• mais controle sobre o ferramental local
• útil para testar em dispositivo antes de ampliar o rollout interno

Escolha local quando estiver depurando o setup ou validando uma integração nativa no seu próprio dispositivo. Escolha TestFlight quando estiver coordenando com QA ou testers não técnicos.

Leia primeiro o arquivo certo do repositório

Esta skill expo-dev-client é simples: comece por SKILL.md. Não há diretórios extras de suporte como resources/, rules/ ou scripts auxiliares nesse caminho da skill, então a maior parte da orientação útil já está concentrada ali.

Isso também significa que você não deve esperar uma lógica profunda de automação; trata-se principalmente de um guia prático de decisão e fluxo de trabalho.

Fluxo sugerido da expo-dev-client para projetos reais

Um fluxo confiável de expo-dev-client guide é:

1. Confirmar se o Expo Go falha por um motivo nativo.
2. Revisar ou criar o eas.json.
3. Adicionar um profile development com developmentClient: true.
4. Decidir entre build local e distribuição via TestFlight.
5. Executar o comando exato de EAS Build para sua plataforma.
6. Testar em um dispositivo físico.
7. Revisar as configurações do profile se o versionamento ou o comportamento de envio estiverem incorretos.

Essa ordem reduz ciclos de build desperdiçados e detecta cedo o caso de “nem precisava de dev client”.

FAQ da skill expo-dev-client

A expo-dev-client é só para apps Expo mais avançados?

Na maior parte dos casos, sim. Iniciantes até podem usar, mas a skill expo-dev-client faz mais sentido quando o app supera os limites do Expo Go por causa de requisitos nativos. Se você ainda está em um cenário puramente managed workflow, talvez ela ainda não agregue valor.

A expo-dev-client é a mesma coisa que apenas instalar expo-dev-client no projeto?

Não. A skill expo-dev-client orienta o fluxo em torno de builds com development client. Ela ajuda a entender quando usar, como configurar o EAS e como escolher o caminho de build. Não é apenas um lembrete para instalar pacote.

Quando eu não devo usar a skill expo-dev-client?

Não use quando:

• seu app já funciona no Expo Go
• você só precisa iterar no nível de JavaScript
• você está buscando um guia completo de release build, e não de setup de development client
• seu problema não tem relação com capacidades nativas ou distribuição de builds

Em que isso difere de um prompt normal de troubleshooting do Expo?

Um prompt comum pode gerar conselhos genéricos de build. A expo-dev-client skill é mais específica e, por isso, melhor para orientar a decisão de instalação: ela enfatiza o checkpoint “precisa mesmo de dev client ou não?” e os detalhes exatos do profile do EAS que costumam travar a adoção.

A expo-dev-client também é útil para Android?

Sim, mas a orientação mais forte e explícita neste trecho da skill está em torno de iOS e TestFlight. A lógica subjacente continua valendo para development builds no Android quando código nativo customizado exige um dev client em vez de Expo Go.

Isso serve para fluxos de deployment?

Sim, dentro de certos limites. expo-dev-client for Deployment deve ser entendido principalmente como distribuição interna de development builds, especialmente via TestFlight para QA ou testes por branch. Não substitui um planejamento completo de release para produção.

Como melhorar o uso da skill expo-dev-client

Informe o estado atual do projeto logo de início

Para obter resultados melhores com a skill expo-dev-client, inclua:

• seu eas.json
• dispositivos-alvo e plataforma
• se o caso é somente local ou TestFlight
• qual módulo nativo ou target motivou a mudança
• se o Expo Go já foi testado

Isso ajuda o agente a sair de orientações genéricas e ir para edições e comandos exatos.

Peça uma decisão antes de pedir os passos

Um prompt de alta qualidade começa com:

Primeiro determine se este app realmente precisa de expo-dev-client.

Essa única instrução melhora a qualidade da resposta porque o principal valor da skill expo-dev-client é evitar setup desnecessário de dev client.

Inclua trechos de configuração para revisão

Se você colar o seu eas.json atual, um agente pode:

• detectar ausência de developmentClient: true
• sugerir ajustes de versionamento
• alinhar os profiles de submit e build
• evitar inventar configuração que você não precisa

Isso é muito melhor do que perguntar do zero.

Seja explícito sobre a intenção de distribuição

O comando certo depende de você querer:

• uma development build local
• uma build em nuvem para instalar em dispositivo
• uma build iOS enviada ao TestFlight

Se isso não for especificado, a primeira resposta pode estar tecnicamente correta, mas operacionalmente errada para o seu time.

Fique atento ao principal modo de falha

A falha mais comum é usar expo-dev-client em apps que deveriam continuar no Expo Go. A segunda é descrever a configuração de EAS de forma insuficiente e depois culpar a skill por uma resposta vaga. Ambas são evitáveis se você informar o requisito nativo e a configuração atual.

Itere depois da primeira resposta

Depois da primeira resposta, faça perguntas de continuação como:

• “Valide este eas.json para um fluxo de TestFlight com dev client.”
• “Reescreva os comandos de build apenas para Android.”
• “Assuma que nosso app usa uma widget extension; o que muda na decisão?”
• “Reduza o setup ao menor profile de development funcional.”

Isso leva a expo-dev-client skill da explicação genérica para uma execução específica do projeto.

Melhore a adoção no time com um prompt padrão

Se vários desenvolvedores forem usar esta skill, crie um template interno reutilizável, como:

Use expo-dev-client para avaliar se este app Expo precisa de um development client. Aqui estão nosso eas.json, plataforma-alvo, objetivo de distribuição e lista de dependências nativas. Retorne: 1) decisão, 2) mudanças de configuração, 3) comandos exatos, 4) bloqueadores prováveis.

Isso torna as respostas mais consistentes e reduz o atrito de onboarding.

Use a skill como etapa de decisão, não só como receita

A melhor forma de melhorar o uso de expo-dev-client é tratá-la como um filtro de decisão antes da build. Se a skill for usada apenas depois de o time já ter decidido adotar um dev client, você perde a maior vantagem dela: evitar overhead desnecessário de fluxo de build nativo.