expo-dev-client

Überblick über den expo-dev-client-Skill

Was der expo-dev-client leistet

Der expo-dev-client-Skill hilft dir zuerst zu entscheiden, ob du überhaupt einen Expo Development Client brauchst, und führt dich dann durch Konfiguration und Build – lokal mit EAS Build oder für TestFlight. Sein eigentlicher Nutzen ist nicht bloß „einen Build erzeugen“, sondern „eine testbare App mit nativen Fähigkeiten ohne Rätselraten durch die Expo-Doku auf echte Geräte bringen“.

Für wen sich dieser Skill eignet

Dieser Skill passt besonders gut für:

• Expo-Teams, die native Module ergänzen
• Entwickler, die lokale Expo-Module oder eigenen nativen Code testen
• Apps mit Apple-spezifischen Targets wie Widgets, App Clips oder Extensions
• Teams, die einen wiederholbaren Weg für internes iOS-Testing über TestFlight brauchen

Wenn deine App vollständig in Expo Go läuft, ist dieser Skill in der Regel nicht nötig.

Die zentrale Installationsentscheidung

Die wichtigste Frage vor der Einführung ist einfach: Brauchst du überhaupt einen Development Client? Genau hier ist der expo-dev-client-Skill besonders wertvoll, weil er diese Entscheidung früh klärt. Er fordert ausdrücklich dazu auf, zuerst Expo Go mit npx expo start zu testen. Das spart unnötige Build-Zeit und vermeidet EAS-Komplexität, wenn sie gar nicht gebraucht wird.

Was expo-dev-client von einem generischen Expo-Prompt unterscheidet

Ein allgemeiner Prompt könnte einem Agenten einfach sagen, er solle „Expo dev client einrichten“. Dieser Skill ist aber stärker auf die Entscheidung selbst ausgerichtet. Er konzentriert sich auf:

• die Schwelle, ab der ein Dev Client wirklich nötig ist
• die erforderliche Struktur von eas.json
• den Unterschied zwischen lokalen Builds und Cloud-/TestFlight-Builds
• den praktischen Befehlsweg für deployment-nahe Tests auf physischen Geräten

Dadurch ist er für Setup- und release-nahe Workflows deutlich nützlicher als ein breit formulierter Expo-Assistent.

So verwendest du den expo-dev-client-Skill

Den expo-dev-client-Skill installieren

Installiere ihn in deiner skills-kompatiblen Umgebung mit:

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

Da dieser Skill kompakt ist und sich auf SKILL.md konzentriert, geht es bei der Installation vor allem darum, ihn für wiederkehrende Expo-Workflows rund um Native-Testing verfügbar zu machen.

Mit dem eigentlichen Ziel starten, nicht mit dem Befehl

Bevor du den expo-dev-client-Skill aufrufst, formuliere das konkrete Ziel:

• „Ich habe ein natives SDK ergänzt und muss auf einem iPhone testen“
• „Wir brauchen einen branch-spezifischen Dev Client für QA“
• „Unsere App enthält jetzt ein Widget, daher reicht Expo Go nicht mehr“
• „Wir möchten einen iOS-Development-Build über TestFlight verteilen“

Das ist wichtig, weil der Skill dann am stärksten ist, wenn der Bedarf an eigenem nativen Code klar benannt ist.

Zuerst prüfen, ob Expo Go ausreicht

Ein häufiger Fehler ist, zu früh zu expo-dev-client zu greifen. Der empfohlene erste Test ist:

npx expo start

Wenn deine App in Expo Go funktioniert, solltest du dort bleiben. Ein Development Client bringt zusätzliche Build-Zeit, Signing-Anforderungen und Verteilungsaufwand mit. Nutze diesen Skill nur dann, wenn native Funktionen diesen Schritt wirklich erzwingen.

Die typischen Auslöser kennen

Setze expo-dev-client ein, wenn dein Projekt Folgendes enthält:

• lokale Expo-Module
• eigenen nativen Code
• native Third-Party-Module, die in Expo Go nicht verfügbar sind
• Apple-Targets wie Widgets, App Clips oder Extensions

In genau diesen Fällen wird ein Dev Client aus „optional“ schnell „erforderlich“.

Die Mindestinformationen für einen Agenten vorbereiten

Wenn ein Agent den expo-dev-client-Skill sinnvoll einsetzen soll, gib ihm Folgendes mit:

• Zielplattform: ios, android oder beides
• geplanter Verteilungsweg: lokale Installation, internes Testing oder TestFlight
• ob EAS bereits für die App eingerichtet ist
• dein aktuelles eas.json
• ob die App native Module nutzt, die von Expo Go nicht unterstützt werden
• eventuelle Vorgaben zu Versionierung oder Signing

Ohne diesen Kontext kann der Agent zwar Befehle vorschlagen, trifft aber womöglich nicht das passende Build-Profil oder empfiehlt unnötig viel Setup.

Einen besseren Prompt verwenden als „set up expo-dev-client“

Ein schwacher Prompt:

Set up expo-dev-client.

Ein stärkerer Prompt:

Use the expo-dev-client skill to determine whether this Expo app needs a dev client. We added a third-party native iOS SDK and need a TestFlight-distributed development build for internal QA. Review this eas.json, identify missing settings, and give the exact commands for building and submitting.

Warum das besser funktioniert:

• zuerst wird die Eignung geprüft
• der native Auslöser ist klar benannt
• der Ziel-Workflow ist konkret
• die Konfiguration liegt für gezielte Korrekturen vor

eas.json korrekt konfigurieren

Die wichtigste Konfiguration, die der Skill herausarbeitet, ist ein Development-Build-Profil mit developmentClient: true, meist zusammen mit automatischer Versionierung:

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

Die entscheidenden Felder sind:

• developmentClient: true: weist EAS an, den Development Client mit einzubinden
• autoIncrement: true: verringert Reibung bei Build-Nummern
• appVersionSource: "remote": hält die Versionierung über EAS hinweg konsistent

Für TestFlight bauen, wenn Remote-Tests auf Geräten wichtig sind

Für iOS-Teams ist der wertvollste expo-dev-client usage-Pfad oft TestFlight:

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

Das ist der praktische „expo-dev-client for Deployment“-Ablauf, wenn du eine entwicklungsfähige App an Tester verteilen musst und nicht nur ein lokales Artefakt brauchst. Dabei werden Cloud-Build und Submission kombiniert, was in der Praxis meist schneller ist, als einzelne Schritte separat zusammenzusetzen.

Lokale Builds nutzen, wenn Geschwindigkeit oder Datenschutz wichtiger sind

Wenn du TestFlight nicht brauchst, sind lokale Builds oft der bessere Workflow:

• schnellere Iteration in manchen Umgebungen
• mehr Kontrolle über lokale Tooling-Setups
• sinnvoll für Gerätetests vor einem breiteren internen Rollout

Wähle lokal, wenn du das Setup debuggst oder eine native Integration auf deinem eigenen Gerät validierst. Wähle TestFlight, wenn du mit QA oder nichttechnischen Testern koordinierst.

Zuerst die richtige Repository-Datei lesen

Dieser Skill ist bewusst einfach aufgebaut: Starte mit SKILL.md. Es gibt in diesem Skill-Pfad keine zusätzlichen Hilfsverzeichnisse wie resources/, rules/ oder Helper-Skripte, daher steckt der Großteil der nutzbaren Hinweise bereits dort.

Das bedeutet aber auch: Erwarte keine tiefe Automatisierungslogik. Dieser Skill ist in erster Linie ein praktischer Leitfaden für Entscheidungen und Workflows.

Empfohlener Workflow für reale Projekte

Ein verlässlicher expo-dev-client guide-Workflow sieht so aus:

1. Prüfen, ob Expo Go aus nativen Gründen scheitert.
2. eas.json prüfen oder neu anlegen.
3. Ein development-Profil mit developmentClient: true ergänzen.
4. Zwischen lokalem Build und TestFlight-Verteilung entscheiden.
5. Den passenden EAS-Befehl für deine Plattform ausführen.
6. Auf einem physischen Gerät testen.
7. Profileinstellungen erneut prüfen, falls Versionierung oder Submission nicht wie erwartet funktionieren.

Diese Reihenfolge vermeidet unnötige Build-Schleifen und fängt früh den Fall ab, dass ein Dev Client gar nicht nötig war.

FAQ zum expo-dev-client-Skill

Ist expo-dev-client nur für fortgeschrittene Expo-Apps?

Größtenteils ja. Einsteiger können ihn zwar ebenfalls nutzen, aber am relevantesten wird der Skill, sobald eine App wegen nativer Anforderungen über Expo Go hinauswächst. Wenn du dich noch vollständig im reinen Managed-Workflow bewegst, bringt er dir wahrscheinlich noch wenig Mehrwert.

Ist expo-dev-client dasselbe wie einfach expo-dev-client in einem Projekt zu installieren?

Nein. Der expo-dev-client-Skill ist eine Anleitung für den Workflow rund um Development-Client-Builds. Er hilft bei der Frage, wann man sie einsetzen sollte, wie EAS zu konfigurieren ist und welcher Build-Pfad sinnvoll ist. Er ist nicht einfach nur eine Erinnerung daran, ein Paket zu installieren.

Wann sollte ich den expo-dev-client-Skill nicht verwenden?

Verwende ihn nicht, wenn:

• deine App bereits in Expo Go funktioniert
• du nur auf JavaScript-Ebene iterieren musst
• du eine vollständige Anleitung für Release-Builds suchst statt für Development-Client-Setup
• dein Problem nichts mit nativen Fähigkeiten oder Build-Verteilung zu tun hat

Worin unterscheidet sich das von einem normalen Expo-Troubleshooting-Prompt?

Ein normaler Prompt liefert oft generische Build-Ratschläge. Der expo-dev-client skill ist enger zugeschnitten und deshalb besser für Installations- und Einführungsentscheidungen geeignet: Er betont den Prüfpunkt „Brauchen wir überhaupt einen Dev Client?“ und die konkreten EAS-Profildetails, an denen die Einführung häufig scheitert.

Ist expo-dev-client auch für Android nützlich?

Ja, aber die stärksten expliziten Hinweise im Skill-Auszug beziehen sich auf iOS und TestFlight. Die zugrunde liegende Logik gilt trotzdem auch für Android-Development-Builds, wenn eigener nativer Code einen Dev Client statt Expo Go erforderlich macht.

Eignet sich das für Deployment-Workflows?

Ja, innerhalb klarer Grenzen. expo-dev-client for Deployment ist am besten als interne Verteilung von Development-Builds zu verstehen, besonders über TestFlight für QA oder branch-basiertes Testing. Es ist kein Ersatz für die Planung eines vollständigen Production-Releases.

So verbesserst du den expo-dev-client-Skill

Den aktuellen Projektstatus von Anfang an mitgeben

Um bessere Ergebnisse mit dem expo-dev-client-Skill zu bekommen, solltest du Folgendes angeben:

• dein eas.json
• Zielgeräte und Plattform
• ob es nur lokal bleiben soll oder über TestFlight laufen muss
• welches native Modul oder Target die Änderung ausgelöst hat
• ob Expo Go bereits ausprobiert wurde

So kann der Agent von allgemeinen Hinweisen zu konkreten Änderungen und exakten Befehlen übergehen.

Erst nach der Entscheidung fragen, dann nach den Schritten

Ein guter Prompt beginnt mit:

First determine whether this app truly needs expo-dev-client.

Diese eine Anweisung verbessert die Ausgabequalität deutlich, weil der größte Mehrwert des Skills darin liegt, unnötiges Dev-Client-Setup zu vermeiden.

Konfigurationsausschnitte zur Prüfung mitgeben

Wenn du dein bestehendes eas.json einfügst, kann ein Agent:

• fehlendes developmentClient: true erkennen
• Korrekturen an der Versionierung vorschlagen
• submit- und build-Profile aufeinander abstimmen
• vermeiden, Konfiguration zu erfinden, die du gar nicht brauchst

Das ist deutlich besser, als ganz ohne Ausgangsbasis zu fragen.

Die Distributionsabsicht klar benennen

Der richtige Befehl hängt davon ab, ob du Folgendes möchtest:

• einen lokalen Development-Build
• einen Cloud-Build zur Installation auf Geräten
• einen per TestFlight eingereichten iOS-Build

Wenn du das nicht angibst, kann die erste Antwort technisch zwar korrekt sein, für dein Team operativ aber am Ziel vorbeigehen.

Auf das wichtigste Fehlermuster achten

Der häufigste Fehler ist, expo-dev-client für Apps zu verwenden, die eigentlich in Expo Go bleiben sollten. Der zweithäufigste ist, die EAS-Konfiguration zu ungenau zu beschreiben und dann dem Skill die vage Ausgabe vorzuwerfen. Beides lässt sich vermeiden, wenn du die native Anforderung und die aktuelle Konfiguration konkret angibst.

Nach der ersten Antwort gezielt nachschärfen

Nach der ersten Antwort helfen Rückfragen wie:

• „Validate this eas.json against a dev-client TestFlight workflow.”
• „Rewrite the build commands for Android only.”
• „Assume our app uses a widget extension; what changes the decision?”
• „Minimize the setup to the smallest working development profile.”

So entwickelt sich der expo-dev-client skill von einer allgemeinen Erklärung hin zu einer projektspezifischen Umsetzung.

Die Team-Einführung mit einem Standard-Prompt verbessern

Wenn mehrere Entwickler diesen Skill nutzen sollen, erstelle eine wiederverwendbare interne Prompt-Vorlage wie:

Use expo-dev-client to assess whether this Expo app requires a development client. Here is our eas.json, target platform, distribution goal, and native dependency list. Return: 1) decision, 2) config changes, 3) exact commands, 4) likely blockers.

Das macht die Ergebnisse konsistenter und reduziert Reibung beim Onboarding.

Den Skill als Gate nutzen, nicht nur als Rezept

Der beste Weg, expo-dev-client usage zu verbessern, ist, den Skill als Entscheidungsgate vor dem Build zu behandeln. Wenn das Team ihn erst nutzt, nachdem es sich bereits auf einen Dev Client festgelegt hat, geht sein größter Vorteil verloren: unnötigen Overhead im nativen Build-Workflow zu vermeiden.