azena mobile
Du baust aus einem leeren Ordner eine echte iOS/Android-App mit mindestens einem KI-Feature — mit Expo/React Native und Claude Code als Co-Autor, den du prüfst. Du wählst bewusst deinen Stack, navigierst und persistierst Daten, sprichst Device-APIs (Kamera, Storage, Notifications) an, rufst LLMs sicher auf (Key NIE in der App), testest auf echter Hardware, baust per EAS in der Cloud und reichst im Store ein — mit Blick auf die Review-Realität.
Was du danach kannst
- Native, cross-platform und Webview-Wrapper unterscheiden und den passenden Ansatz wählen
- Einen Stack begründet wählen (Expo/React Native vs Flutter vs Swift/SwiftUI)
- Mit Expo + Claude Code scaffolden, navigieren und Daten/State verwalten — jeden Diff geprüft
- Device-APIs (Kamera, Storage, Notifications) inkl. Permissions sauber einbinden
- LLMs sicher aus der App aufrufen (Key über Backend/Proxy; On-Device via Foundation Models)
- Per EAS bauen, OTA-Updates ausspielen und gegen die Store-Review-Realität einreichen
Das Curriculum
18 Lektionen · Schritt für Schritt
- 01
Die Mobile-Landschaft — Web ist nicht App
11′Native, cross-platform, PWA, Wrapper — vier Wege aufs Telefon, mit echten Konsequenzen für Stores und Nutzer.
- 02
Stack-Wahl — Expo/React Native vs Flutter vs Swift
12′Drei ernsthafte Wege zur App. Welcher passt, hängt von deinem Hintergrund und deinem Ziel ab.
- 03
Deine erste App mit KI-Hilfe (Claude Code)
11′Vom leeren Ordner zur laufenden App in Tagen — KI beschleunigt, du reviewst jeden Diff.
- 04
UI & Navigation — Screens, Tabs, Modals
10′Navigation ist das Skelett einer App. Expo Router macht aus Dateien deine Routen.
- 05
State & Daten — lokal, global, persistent, vom Server
11′Apps merken sich Dinge — im Screen, app-weit, über Neustarts hinweg und vom Server.
- 06
Device-APIs — Kamera, Storage, Notifications
11′Der Mehrwert einer echten App liegt in der Hardware — und in sauber abgefragten Berechtigungen.
- 07
AI/LLM-APIs aus der App aufrufen — sicher
12′Das KI-Feature ist der Kern dieses Tracks. Der API-Key gehört NIE in die App.
- 08
Auf echtem Gerät testen — der Simulator lügt
9′Kamera, Push, Sensoren und Performance verhalten sich auf echter Hardware anders als im Simulator.
- 09
Build & Store-Deploy — EAS, App Store, Play Store
11′Aus deinem Code wird eine signierte App, die in die Stores wandert — in der Cloud, ohne lokale Toolchain.
- 10
OTA-Updates — Fixes ohne Store-Wartezeit
9′JS-Fixes direkt an die App pushen — ohne neuen Store-Review. Aber nicht alles geht over-the-air.
- 11
Die Store-Review-Realität — warum Apps abgelehnt werden
11′Der Store ist ein Tor mit echten Wächtern. Die häufigsten Ablehnungsgründe kennst du vorher.
- 12
Push-Notifications richtig — nützlich statt nervig
11′Tokens, Berechtigungen, sinnvolle Auslöser — eine Push, die hilft, statt zu nerven und Deinstallationen auszulösen.
- 13
Offline-First & Sync — die App funktioniert auch ohne Netz
11′Mobil ist das Netz die Ausnahme, nicht die Regel. Lokal zuerst arbeiten, später sauber abgleichen.
- 14
Performance & flüssige Animationen — 60fps fühlbar machen
11′Eine App wird an ihrer Flüssigkeit gemessen. Ruckeln, langsame Listen und stockende Animationen verraten Amateurware.
- 15
Onboarding & Auth-Flows — erster Start, Login, Wiederherstellung
11′Die ersten dreißig Sekunden entscheiden. Erster Start, Login, Deep-Links und ein Konto, das man nicht verliert.
- 16
In-App-Käufe & Monetarisierung — Stores, Abos, die Plattform-Regel
11′Geld verdienen heißt auf Mobile: durch das Bezahlsystem der Stores. Wer das ignoriert, fliegt raus.
- 17
Barrierefreiheit auf Mobile — VoiceOver, Touch-Targets, dynamische Schrift
10′Eine App, die nur für perfekte Augen und ruhige Hände gebaut ist, schließt Nutzer aus — und Stores sehen genau hin.
- 18
Capstone-Sprint — deine KI-App auf dem Telefon
12′Alles zusammen: scaffolden → UI → Device-API → KI-Feature → Gerätetest → EAS-Build → Submit.
Was du baust
Echte Artefakte, keine Theorie
Scaffolden + erste navigierbare App bauen
Ergebnis: Ein laufendes Expo-Projekt mit Tabs + Detail-Stack + Modal, geprüft auf Safe Areas und Back-Verhalten.
Ein Device-API mit sauberem Permission-Flow einbinden
Ergebnis: Ein funktionierendes Kamera-Feature mit vollständigem Permission-Flow (Abfrage + Ablehnung) und gesetzten Begründungstexten.
Ein KI-Feature mit sicherem Backend-Proxy bauen
Ergebnis: Ein lauffähiges KI-Feature mit Backend/Proxy (Key serverseitig), Streaming und behandelten Fehlerfällen.
Auf echtem Gerät testen — beide Plattformen
Ergebnis: Ein Testprotokoll: App auf je einem echten iOS- und Android-Gerät geprüft, mit notierten Plattform-Unterschieden.
Capstone: KI-App bauen, auf dem Telefon, eingereicht
Ergebnis: Eine eingereichte KI-App: läuft auf physischem Gerät (Key hinter Proxy), per EAS gebaut + submittet, mit Privacy-/AI-Disclosure und abgehakter Review-Checkliste.
Vom leeren Frame zur lebendigen KI-App
Wie aus einem leeren Projekt eine App auf deinem Telefon wird — Screen für Screen, live.
Das ist eine durchgehende Reise: Aus dem leeren Projekt wächst der Screen Element für Element — Tab-Bar, Header, Liste, Button — als würde Code live gerendert. Ein Stack-Push gleitet horizontal zum Detail-Screen, dort leuchtet das KI-Feature auf und die Antwort streamt Zeile für Zeile herein. Am Ende reicht ein Submit das signierte Artefakt beim Store ein. Genau diese Kette — Scaffold → UI → KI-Feature → Build → Submit — trennt ein lauffähiges Produkt von einem Tutorial-Screenshot.
Expo / React Native
JS/TS, eine Codebase, File-based Routing
Default für neue Apps — die offizielle RN-Empfehlung.
Flutter
Dart, Impeller-Rendering
Starke Alternative, wenn dein Team aus dem Dart-Lager kommt.
Swift / SwiftUI
native iOS, On-Device-AI
Bei tiefer iOS-Integration + Apple Foundation Models.
API-Key gehört NIE in die App
Ein Cloud-LLM nie direkt aus dem Client rufen — das Bundle ist auslesbar, der Key wandert in fremde Haende. Calls laufen über ein eigenes Backend/Proxy; oder du gehst On-Device mit Apple Foundation Models (frei, offline, privat). Streaming und Fehlerfälle gehören sauber ins UX.
EAS baut und reicht in der Cloud ein
EAS Build kompiliert und signiert iOS (.ipa) und Android (.aab) in der Cloud — ohne lokale native Toolchain. EAS Submit lädt das Artefakt an App Store und Play Store. Die Signing-Credentials sind dabei der häufigste Stolperstein.
Die Review-Realität einplanen
Top-Ablehnungsgründe: Crashes und Platzhalter, fehlende Privacy-Disclosures, irreführende Metadaten und reine Webview-Wrapper (Apple Minimum Functionality). KI-Content braucht eine Report-Funktion und eine Kennzeichnung — sonst fliegt der Build zurück.
Deine erste KI-App aufs Telefon bringen — und einreichen, mit Nova als Mentor, vom Scaffold bis zum EAS-Submit.
Track startenBelege & Quellen
Jede Aussage ist belegt — echte, geprüfte Quellen statt Behauptungen.
Reinschnuppern
Gratis-VorschauGO vs. NO-GO — ein echtes Beispiel aus dem Track.
Wie der Track läuft
Mit Nova als Mentor
Dein KI-Mentor erklärt jedes Konzept, gibt dir fertige Claude-Code-Prompts und hilft bei jeder Frage.
Geprüftes Siegel
Beschreib Nova, wie du eine echte KI-App aufs Telefon bringst: warum cross-platform (und wann doch Swift), wie du mit Expo + Claude Code scaffoldest und jeden Diff prüfst, wie du navigierst und Device-APIs samt Permission-Flow einbindest, warum der LLM-Key NIE in der App liegt (Backend/Proxy) und wann On-Device passt, warum du auf echter Hardware und beiden Plattformen testest, wie EAS Build/Submit und EAS Update (OTA) funktionieren, und welche Review-Ablehnungsgründe — inkl. der KI-spezifischen — du vorab abhakst.
In deinem Tempo
Rund 195 Minuten Kerninhalt — plus deine eigenen Projekte. Jederzeit pausierbar.
Fehler, die du vermeidest
- Nur im Simulator testen — Kamera, Push, Sensoren und Performance verhalten sich auf echter Hardware anders.
- API-Keys in der App ablegen (auslesbar/missbraucht) — LLM-Calls gehören über ein Backend/Proxy.
- Plattform-Unterschiede ignorieren ('läuft auf iOS' ≠ 'läuft auf Android') — immer beide testen.
- Store-Guidelines unterschätzen: Platzhalter, fehlende Privacy-Disclosures, Webview-Wrapper, fehlende AI-Kennzeichnung.
- Veraltete KI-Antworten blind übernehmen (überholte New-Arch-Flags/Expo-APIs) — jeden Diff reviewen, gegen die aktuelle Doku prüfen.
Bereit für azena mobile?
250 Token · 18 Lektionen · von der KI geprüft.