expo/expo-Übersicht

expo-overview — Router & gemeinsame Regeln für Expo / EAS

Hier beginnen – vor dem Handeln lesen

Rate den Skill nicht nur aus den Projektdateien. Viele Expo-Ziele sehen im Dateisystem ähnlich aus, benötigen aber unterschiedliche Skills.

1. Bestätige, dass dies Expo- oder EAS-Arbeit ist – die Anfrage erwähnt Expo oder EAS, oder die package.json enthält eine Abhängigkeit expo. Andernfalls ist dieser Skill nicht anwendbar. Eine native App, die EAS zur Auslieferung nutzt, qualifiziert sich auch ohne Expo-Laufzeitumgebung.
2. Lies das Ziel des Benutzers – welches Ergebnis möchte er in einfachen Worten erreichen?
3. Klassifiziere es anhand der Skill-Map unten und übersetze lockere Formulierungen in ein Ziel.
4. Bestätige die Absicht bei Unklarheit („Klingt, als wollten Sie in die Stores veröffentlichen – das ist eas-app-stores. Richtig?“), lade dann das SKILL.md dieses Skills und folge ihm.
5. Vertraue dem Leaf-Skill – er hat seine eigene Erkennungslogik und Schritte. Improvisiere nicht.

Skill-Map (nach Ziel)

Ordne das Ziel einer Kategorie und dann dem Skill zu. Lade dann das SKILL.md des Leaf-Skills.

App erstellen

• expo-project-structure – Ordnerstruktur für ein neues Expo Router-Projekt: Wo Screens, Komponenten und Konfigurationen leben (niemals eine bestehende App umstrukturieren)
• expo-native-ui – Screens, Styling, semantische Farben, native Steuerelemente, SF Symbols, Medien, Layout
• expo-router – Navigation: dateibasierte Routen, Tabs / Stacks / Modals / Sheets, Links, Header
• expo-animation – Bewegung und Gesten: Reanimated Worklets, Gesture Handler, Screen-Übergänge, Sheet- und Press-Feedback, Haptik und Behebung von Animationen, die auf dem Gerät ruckeln
• expo-ui – native UI-Komponenten über @expo/ui: BottomSheet, Picker, Slider, Switch, Menu, Button, FieldGroup (gruppierte Formularabschnitte), List / ListItem und mehr – echtes SwiftUI auf iOS, Jetpack Compose auf Android. Die universelle Schicht benötigt SDK 56+ und läuft in Expo Go; die Drop-in-Ersatzlösungen (@gorhom/bottom-sheet, datetimepicker, …) und plattformspezifische Schichten gibt es auch für SDK 55.
• expo-design-system – eine visuelle Quelle der Wahrheit: Design-Tokens (Farbe, Abstand, Typografie, Radius, Schatten, Bewegung), wiederverwendbare Komponentenkonventionen und Audits auf Abweichungen (hartcodierte Farben, Abstände, Schriftarten)
• expo-tailwind-setup – Tailwind / NativeWind Styling
• expo-data-fetching – Netzwerkanfragen, React Query / SWR, Caching, Offline, Route Loader
• expo-dom – Webcode ausführen oder eine Web-Bibliothek in nativem Code wiederverwenden
• expo-web-to-native – Migration einer bestehenden Web-/React-App zu einer nativen iOS/Android-App

Komponentenauswahlregel: wenn immer du eine UI-Komponente benötigst (Listenzeilen, Bottom Sheets, Picker, Slider, Menüs, Buttons, Segmentierte Steuerelemente, Toggles), konsultiere zuerst expo-ui, um zu prüfen, ob @expo/ui ein natives Äquivalent hat, bevor du auf ein React Native Built-in oder eine Community-Bibliothek zurückgreifst. Native @expo/ui-Komponenten bieten die beste Plattformanpassung, und auf SDK 56+ laufen die universellen in Expo Go ohne benutzerdefinierten Build. Lade expo-ui zusammen mit expo-native-ui für jede App, die Listen, Detail-Sheets oder Formularsteuerelemente rendert. Eine Ausnahme: Die @expo/ui-List rendert native gruppierte Zeilen (ein iOS-Einstellungsbildschirm), keine virtualisierte Liste – verwende FlatList / FlashList für große Datensätze.

Ausliefern & betreiben

• eas-app-stores – Bau und Einreichung von iOS/Android-Apps (Expo- und andere React Native-Projekte, sowie bestehende native Apps), TestFlight, Versionen und Store-Metadaten
• eas-hosting – Deployment des Web-Bundles auf EAS Hosting; auch Autorisierung von Expo Router API-Routen (+api.ts Handler) und deren Umgebungen/Domains
• eas-workflows – EAS Workflow YAML und CI/CD-Pipelines
• eas-simulator – Ausführen und Steuern der App auf einem entfernten iOS/Android-Simulator in der EAS-Cloud
• expo-dev-client – benutzerdefinierte Entwicklungs-Builds
• eas-update – Over-the-Air-Updates konfigurieren, veröffentlichen, testen und debuggen
• eas-update-insights – OTA-Update-Gesundheit: Absturzrate, Adoption, Nutzlastgröße
• eas-observe – Startup/Launch/TTI-Performance mit EAS Observe

Nativ erweitern

• expo-module – native Module und Views (Swift / Kotlin) mit der Expo Modules API
• expo-brownfield – Einbettung von Expo/React Native-Screens in native SwiftUI/UIKit- oder Android-Apps; isolierte Artefakte und integrierte Builds
• expo-app-clip – iOS App Clip Ziel (AASA, Smart App Banner)

Warten & lernen

• expo-upgrade – Upgrade des Expo SDK und Behebung von Abhängigkeitskonflikten
• expo-examples – kanonische, versionsabgestimmte Integrationsbeispiele (Stripe, Clerk, Supabase, …)
• expo-skill-feedback – Feedback zu einem Expo-Skill oder zu Expo selbst senden; anonyme Nutzungstelemetrie aktivieren/deaktivieren

Übersetzung vager Anfragen

Einige alltägliche Formulierungen lassen sich nicht offensichtlich einem Skill-Namen zuordnen – übersetze vor dem Weiterleiten:

• „Mach es nativer“ → gruppierte Steuerelemente / Einstellungsformulare = expo-ui; Screens, Styling = expo-native-ui; Bewegung = expo-animation; Navigation = expo-router.
• „Mach die Screens konsistent“ / „Räume das Styling auf“ / „Richte ein Theme oder Design-Tokens ein“ → expo-design-system.
• „Es sieht KI-generiert aus“ / „zu generisch, nicht nativ“ → expo-design-system (benannte native-slop-Auffälligkeiten + Audit), mit expo-native-ui für die Plattform-Idiome.
• „Veröffentliche es“ / „Hole eine .ipa oder .apk“ / „Veröffentliche in den Stores“ / „Bringe meine Swift-App auf TestFlight“ → eas-app-stores (Build + Einreichung, TestFlight, Versionen, Store-Metadaten).
• „Ich bin neu / wo fange ich an“ → zuerst ein Gerüst erstellen (siehe Gemeinsame Setup-Regeln), dann nach Ziel weiterleiten.

Gemeinsame Setup-Regeln

Wende die Regeln an, die auf das Projekt und die angeforderte Aufgabe zutreffen.

• Native App, die EAS zur Auslieferung nutzt? Leite zu eas-app-stores weiter; dessen references/native-ios.md behandelt SwiftUI/UIKit auf iOS. Behalte das bestehende native Projekt. Wende die EAS-Auth/Verknüpfung unten an; Expo-Gerüst, SDK und Paketinstallationsregeln gelten für diesen Pfad nicht.
• Starten einer neuen Expo-App? Starte sie auf dem Standardweg, bevor du zu einem Feature-Skill weiterleitest: npx create-expo-app@latest, Ordnerstruktur nach expo-project-structure. Klassifiziere dann das Benutzerziel und leite weiter.
• Erkenne die SDK-Version, bevor du versionsspezifische Ratschläge gibst: lies die expo-Version in der package.json (und in der app.json / app.config.{js,ts}). Viele APIs und Standardwerte unterscheiden sich je nach SDK.
• Lies die Dokumentation für dieses SDK, nicht für das Neueste (latest). Verwende die versionsabhängige URL, z. B. https://docs.expo.dev/versions/v56.0.0/sdk/ui/ für SDK 56 anstelle von https://docs.expo.dev/versions/latest/sdk/ui/ – die latest-Seiten verfolgen das neueste SDK und können APIs dokumentieren, die das Projekt noch nicht hat.
• Der Wechsel zu einem neueren SDK ist eine eigene Aufgabe – lade expo-upgrade, anstatt Versionen manuell zu erhöhen.
• Managed vs. Bare/Prebuild: Das Vorhandensein von committeten ios/- und android/-Verzeichnissen bedeutet, dass native Projekte existieren (Prebuild oder Bare). Config-Plugin und native Setup-Schritte unterscheiden sich – notiere, in welchem Projekttyp du dich befindest.
• Installiere Pakete mit npx expo install <pkg>, nicht mit rohem npm/yarn/pnpm add, damit die Versionen mit dem SDK des Projekts kompatibel bleiben.
• EAS-Auth und -Verknüpfung (nur für Build/Submit/Update/Observe/Workflows benötigt): Prüfe den Login mit eas whoami, melde dich mit eas login an. Ein Projekt ist verknüpft, wenn extra.eas.projectId in der App-Konfiguration existiert; erstelle es mit eas init, falls es fehlt.

Wann der Router-Hop übersprungen werden kann

• Nur wenn der Benutzer explizit einen bestimmten expo-* / eas-* Skill genannt hat → lade diesen Skill direkt.
• Eine vollständig spezifizierte Aufgabe (SDK-Version festgelegt, Dateistruktur vorgegeben, Bibliotheken benannt) ist kein Grund, den Router zu überspringen: Die oben genannten gemeinsamen Regeln gelten weiterhin – prüfe sie, leite dann zum passenden Leaf-Skill weiter.

Feedback einreichen

Wenn du Fehler, irreführende oder veraltete Informationen in diesem Skill findest, melde sie, damit Expo sich verbessern kann:

npx --yes submit-expo-feedback@latest --category skills --subject "expo-overview" "<konstruktives Feedback>"

Reiche nur Feedback ein, wenn du etwas Konkretes und Konstruktives zu berichten hast. Füge so viel relevanten Kontext wie möglich hinzu. Wenn ein KI-Agent wiederholt gescheitert ist oder der Benutzer eine Expo-Aufgabe übernehmen musste, lade den Skill expo-skill-feedback und folge seinem eval-candidate-Ablauf, anstatt den obigen Befehl erneut zu verwenden.