yourpart3/android/NATIVE_ANDROID_APP_PLAN.md

Native Android App Plan fuer YourPart3

Stand: 2026-07-08

Zielbild

Dieses Dokument plant eine komplette native Android-App fuer YourPart3 als langfristige Ablösung bzw. Ergänzung der aktuellen Capacitor-Hybrid-App.

Ziel ist eine echte Android-App mit:

• Kotlin
• Jetpack Compose
• MVVM bzw. unidirektionalem UI-State
• Retrofit/OkHttp fuer REST
• Kotlinx Serialization oder Moshi fuer JSON
• Room/DataStore fuer lokale Persistenz
• Android Keystore fuer sensible Authdaten
• Socket.IO/WebSocket-Clients fuer Realtime
• Coil fuer Bilder
• WorkManager fuer Hintergrundjobs
• FCM fuer Push Notifications

Das vorhandene Backend bleibt die maßgebliche Datenquelle. Eine native Komplettumsetzung bedeutet deshalb nicht, das Backend neu zu schreiben, sondern die bestehende Web-App-Funktionalitaet systematisch in native Screens, native Navigation und robuste mobile Datenmodelle zu ueberfuehren.

Grundentscheidung

• Die bestehende Hybrid-App bleibt als lauffaehige Zwischenloesung erhalten.
• Die native App wird parallel aufgebaut.
• Nicht als Big Bang migrieren. Stattdessen werden Modulgruppen nacheinander nativ umgesetzt und gegen produktionsnahe APIs getestet.
• Admin- und Adult-Bereiche werden nicht im ersten nativen MVP umgesetzt.
• Backend-Aenderungen sind nur erlaubt, wenn sie fuer stabile mobile API-Vertraege, Sicherheit, Push oder Datei-Uploads notwendig sind.

Native Zielarchitektur

android-native/
  app/
  core/
    network/
    auth/
    database/
    realtime/
    design/
    common/
  feature-auth/
  feature-home/
  feature-social/
  feature-chat/
  feature-falukant/
  feature-vocab/
  feature-settings/
  feature-media/
  feature-minigames/
  feature-admin/        # spaeter

Empfohlener Pfad im Repository:

• Entweder /android/native fuer die neue native App neben der Capacitor-App.
• Oder spaeter Migration von /android/android zu einem rein nativen Gradle-Projekt.

Empfehlung: /android/native, damit die Hybrid-App weiter testbar bleibt.

Technische Zielentscheidungen

• Sprache: Kotlin.
• UI: Jetpack Compose, Material 3, eigene YourPart-Design-Tokens.
• Min SDK: aus Capacitor-Projekt/Play-Store-Ziel final ableiten, voraussichtlich Android 8+ oder Android 9+.
• Navigation: Compose Navigation mit typed Routes.
• Dependency Injection: Hilt.
• REST: Retrofit + OkHttp Interceptors.
• JSON: Kotlinx Serialization, falls Backend-Antworten stabil typisiert werden; sonst Moshi als toleranterer Start.
• Lokale Einstellungen: DataStore Preferences.
• Lokale Daten: Room fuer Cache, Entitaeten, Outbox.
• Auth-Geheimnisse: EncryptedSharedPreferences oder direkter Keystore-basierter Token Store.
• Bilder: Coil.
• Datei-Uploads: OkHttp Multipart, Android Photo Picker.
• Realtime: Socket.IO Android Client plus separater OkHttp WebSocket fuer Daemon.
• Push: Firebase Cloud Messaging.
• Tests: JUnit, Turbine, MockWebServer, Compose UI Tests.

API-Strategie

Die Web-App nutzt aktuell viele direkte REST-Aufrufe aus Komponenten. Fuer native Android muss daraus ein klarer API-Client entstehen.

Native API-Schichten:

• AuthApi
• SettingsApi
• MenuApi
• SocialApi
• GalleryApi
• ForumApi
• ChatApi
• FalukantApi
• VocabApi
• CalendarApi
• BlogGuideApi
• MinigamesApi
• AdminApi spaeter

Wichtige Backend-Vertraege:

• Login liefert User inklusive id und authCode.
• REST-Requests brauchen Header userid und authcode.
• Socket.IO registriert User per setUserId.
• Daemon-WebSocket nutzt eigene Events und User-Kontext.
• Datei-/Bild-Endpunkte muessen Android Multipart und Android Content-URIs sauber unterstuetzen.

Migrationsprinzip

Jedes Modul wird in vier Schritten umgesetzt:

1. API-Vertrag erfassen: Endpunkte, Payloads, Fehler, Rechte.
2. Domain-Modelle definieren: Kotlin DTOs, Mapping, UI-State.
3. Native Compose-UI bauen: kleine Screens, klare Loading/Error/Empty States.
4. Gegen Backend testen: Emulator, echtes Geraet, Offline/Resume, Realtime.

MVP-Schnitt

Ein sinnvoller nativer MVP ist nicht "alles", sondern:

• Login/Logout
• Session-Persistenz
• Home/Dashboard
• native Navigation
• Settings: Sprache und Account-Basis
• Friends/Search/Profile light
• Chat light
• Falukant Overview + Status + Branch-Liste light
• Vokabeltrainer Course/Lesson light
• Push-Grundlage optional

Alles Weitere wird danach iterativ migriert.

Nicht-Ziele fuer den nativen MVP

• Kein vollstaendiger Admin-Bereich.
• Keine vollstaendige Falukant-Wirtschaftssimulation in Version 1.
• Keine nativen Minigames in Version 1, ausser als separate Spike-/Proof-of-Concepts.
• Keine 3D-Charakterdarstellung in Version 1.
• Keine Offline-First-Synchronisation fuer alle Module.
• Keine Store-Verteilung vor Datenschutz-/UGC-/Adult-Compliance.

Risiken

• Sehr breite Web-App-Funktionalitaet: ein nativer Rewrite ist ein Mehrmonatsthema, nicht ein Scaffold-Thema.
• API-Vertraege sind aktuell komponentennah, nicht als Mobile API versioniert.
• Auth nutzt userid/authcode statt standardisiertem Bearer Token.
• Viele Screens erwarten Web-Layout, Dialoge und dynamische Menues.
• Falukant ist daten- und realtime-intensiv.
• Chat, Galerie, Adult Content und UGC erfordern Store-Compliance.
• Native 3D/Minigames brauchen eigene Performance-Entscheidungen.

Abhakbare Roadmap

0. Projektentscheidung und Scope

Entscheidungen:

• Native App wird unter /android/native aufgebaut.
• Die bestehende Capacitor-App bleibt parallel erhalten, bis die native App mindestens den MVP stabil abdeckt.
• Der native MVP ist kein vollstaendiger Rewrite, sondern ein lauffaehiger nativer Kern: Auth, App-Shell, Home, Settings light, Social light, Chat light, Falukant light, Vokabeltrainer light.
• Admin wird aus dem nativen MVP ausgeschlossen.
• Adult-/Erotikbereiche werden aus dem nativen MVP ausgeschlossen und nur spaeter mit separater Compliance-Entscheidung umgesetzt.
• Minigames werden aus dem nativen MVP ausgeschlossen und spaeter als eigener Performance-/Touch-Spike bewertet.
• 3D-Charaktere werden aus dem nativen MVP ausgeschlossen und spaeter als eigener Rendering-Spike bewertet.
• Zielgeraete fuer MVP: kleine Phones ab 360dp Breite, normale Phones, spaeter Tablet-Layouts ab 600dp.
• Mindest-Android fuer MVP: Android 8.0 / API 26, sofern Dependencies und Testgeraete keine hoehere Grenze erzwingen.
• Distribution fuer MVP: interne Debug-/Test-APK. Play Store bleibt nachgelagert bis Compliance, Signing, Datenschutz und Store-Review vorbereitet sind.

Todo:

• Entscheiden, ob die native App unter /android/native angelegt wird.
• Entscheiden, ob die Capacitor-App langfristig parallel gepflegt bleibt.
• Native MVP-Funktionsumfang final freigeben.
• Admin-Bereich aus MVP ausschliessen oder explizit aufnehmen.
• Adult-/Erotikbereiche aus MVP ausschliessen oder explizit mit Compliance-Aufwand aufnehmen.
• Minigames aus MVP ausschliessen oder als separaten Spike aufnehmen.
• 3D-Charaktere aus MVP ausschliessen oder als separaten Spike aufnehmen.
• Zielgeraete festlegen: kleine Phones, Tablets, Mindest-Android-Version.
• Play-Store-Zieltermin oder interne Distribution als Ziel definieren.

1. Native Projektbasis

Stand 2026-07-09:

• Native Projektbasis ist unter /android/native angelegt.

• Gradle Kotlin DSL ist aktiv.

• Separate Native-App-ID ist bewusst gewaehlt: de.yourpart.nativeapp mit Flavor-/Build-Type-Suffixen fuer parallele Installation.

• Flavors local, staging, production sind angelegt.

• Build Types debug, release sind angelegt.

• Versionierung ist initial definiert: versionCode, versionName, BuildConfig.GIT_SHA.

• Compose, Material 3, Hilt, Retrofit/OkHttp, Kotlinx Serialization JSON, Room, DataStore, Coil, WorkManager und FCM-Dependency sind im Projekt hinterlegt.

• Ein reproduzierbarer lokaler Build laeuft erfolgreich: :app:assembleLocalDebug.

• Neues natives Gradle-Projekt unter /android/native erstellen.

• Kotlin DSL fuer Gradle verwenden.

• App-ID de.yourpart.app oder separate Dev-ID de.yourpart.native.dev entscheiden.

• Produktflavors anlegen: local, staging, production.

• Build Types anlegen: debug, release.

• Versionierung definieren: versionCode, versionName, Git-Hash im Build.

• Compose aktivieren.

• Material 3 aktivieren.

• Hilt einrichten.

• Retrofit/OkHttp einrichten.

• JSON-Library festlegen und einrichten.

• Room einrichten.

• DataStore einrichten.

• Coil einrichten.

• WorkManager einrichten.

• FCM Dependency vorbereiten, aber noch nicht aktiv schalten.

• Lint, Detekt oder Ktlint einrichten.

• CI-Build-Script fuer native App definieren.

2. Design System

• YourPart-Farbpalette aus Web-App ableiten.
• Typography fuer Android definieren.
• Spacing-Skala definieren.
• Shape-/Radius-System definieren.
• Button-Komponenten definieren.
• TextField-Komponenten definieren.
• Dialog-Komponenten definieren.
• Error-/Info-/Success-Komponenten definieren.
• Loading/Empty-State-Komponenten definieren.
• Avatar-/Image-Komponenten definieren.
• Status-Chips fuer Backend/Daemon definieren.
• Light Theme implementieren.
• Dark Theme bewusst entscheiden: sofort, spaeter oder nicht.
• Kleine Displaybreiten 360dp und 393dp als Design-Baseline testen.

3. App Shell und Navigation

• Root Compose App mit Theme erstellen.
• Top App Bar definieren.
• Bottom Navigation fuer Hauptbereiche definieren.
• Navigation Drawer fuer Sekundaerbereiche definieren.
• Typed Routes fuer Auth, Home, Social, Falukant, Vocab, Settings anlegen.
• Rollen-/Rechte-basierte Menueeintraege modellieren.
• Backend-Menue-Response analysieren und native Menue-Policy definieren.
• Deep-Link-Struktur definieren.
• Android Back Button Verhalten definieren.
• Dialog-Back-Handling implementieren.
• Session-expired Navigation implementieren.
• Offline-Banner implementieren.
• Backend-/Daemon-Status sichtbar, aber kompakt darstellen.

4. Konfiguration und Environments

• API Base URLs fuer local, staging, production definieren.
• Socket.IO URLs je Flavor definieren.
• Daemon WebSocket URLs je Flavor definieren.
• Lokale Emulator-Regel dokumentieren: Host-Rechner ist 10.0.2.2.
• Release-Build gegen lokale URLs blockieren.
• Network Security Config fuer Debug und Release definieren.
• TLS-only fuer Release sicherstellen.
• Secrets aus APK fernhalten.
• Feature Flags definieren: Admin, Adult, 3D, Minigames, Push.

5. Auth und Session

• Login-Endpunkt dokumentieren.
• Login DTOs erstellen.
• Login Repository implementieren.
• Auth Interceptor fuer userid und authcode implementieren.
• Session Store mit sicherer Speicherung implementieren.
• Auto-Login beim App-Start implementieren.
• Logout implementieren.
• Session-expired Handling implementieren.
• User-Aktivstatus pruefen.
• Account gesperrt Handling implementieren.
• Registrierung API-Vertrag erfassen.
• Registrierung Screen implementieren.
• Account-Aktivierung Flow bewerten.
• Passwort-Reset Flow implementieren.
• OAuth-Provider-Liste laden.
• OAuth per Custom Tabs planen.
• App Links fuer OAuth Callback planen.
• OAuth erst nach Username/Passwort stabil aktivieren.

6. Netzwerk-Grundlage

• Zentrale ApiResult/NetworkError Struktur definieren.
• Fehlercodes und Backend-Fehlerformate erfassen.
• Retry-Policy definieren.
• Timeout-Policy definieren.
• Request Logging nur fuer Debug aktivieren.
• Auth Header Tests mit MockWebServer schreiben.
• CORS ist nativ irrelevant, aber Backend-Origin-Checks gegen mobile Clients pruefen.
• Multipart Upload Helper bauen.
• Download Helper fuer Bilder/Dateien bauen.
• Pagination Pattern definieren.
• Refresh Pattern definieren.

7. Lokale Persistenz und Cache

• DataStore fuer UI-Sprache verwenden.
• DataStore fuer Feature Flags verwenden.
• Room Schema fuer User/Profile Cache definieren.
• Room Schema fuer Friends/Search Cache definieren.
• Room Schema fuer Falukant Status light definieren.
• Room Schema fuer Vocab Course/Lesson Cache definieren.
• Cache-Invalidation Regeln definieren.
• Offline-Anzeige statt Offline-First fuer MVP festlegen.
• Outbox fuer spaetere Offline-Aktionen nur planen, nicht im MVP erzwingen.

8. Realtime

• Socket.IO Android Client evaluieren.
• Verbindung nach Login aufbauen.
• setUserId nach Verbindungsaufbau senden.
• Events erfassen: forumschanged, friendloginchanged, reloadmenu, adultVerificationChanged, moderationReportChanged, userAccessChanged.
• Falukant-Events erfassen: falukantUpdateStatus, falukantUpdateFamily, falukantUpdateChurch, falukantUpdateDebt, children_update, falukantUpdateProductionCertificate, falukantBranchUpdate, stock_change, familychanged.
• Socket Lifecycle an App Foreground/Background koppeln.
• Reconnect Policy definieren.
• Daemon-WebSocket Client implementieren.
• Daemon-Message Parsing robust gegen unbekannte Events machen.
• Realtime Events in Repositories einspeisen.
• UI-State bei Events gezielt invalidieren.
• Realtime Debug Screen fuer interne Builds planen.

9. Home und Dashboard

• Home API-Vertraege erfassen.
• Eingeloggt/Nicht-eingeloggt Home getrennt modellieren.
• Native Startseite fuer nicht eingeloggte Nutzer bauen.
• Native Startseite fuer eingeloggte Nutzer bauen.
• Dashboard Widget API-Vertraege erfassen.
• Termine/Upcoming Events als native Cards umsetzen.
• Falukant Kurzstatus als native Card umsetzen.
• News/Blog/Guide Kurzlisten bewerten.
• Backend-/Daemon-Status light anzeigen.

10. Settings

• Settings API-Vertraege erfassen: /api/settings/filter, /api/settings/update, /api/settings/account.
• Spracheinstellung nativ implementieren.
• Account-Basisdaten nativ implementieren.
• Sichtbarkeitseinstellungen modellieren.
• Personal/View/Sexuality/Flirt Settings priorisieren.
• Interessen-Settings implementieren.
• Language Assistant Settings bewerten.
• Account-Loeschung oder Anfrageprozess fuer Store-Compliance klaeren.

11. Social Basis

• Friends API-Vertraege erfassen.
• Friends Screen implementieren: bestehend, angefragt, offen, abgelehnt.
• User Search API-Vertraege erfassen.
• User Search Screen implementieren.
• User Profile API-Vertraege erfassen.
• Profile Light Screen implementieren.
• Guestbook API-Vertraege erfassen.
• Guestbook light implementieren.
• Friend Request Aktionen implementieren.
• Blockieren/Melden UX fuer Store-Compliance planen.
• Privacy/Visibility Regeln aus Backend nativ abbilden.

12. Chat

• Aktuellen Chat-Mechanismus erfassen: Dialoge, Raeume, Random Chat, MultiChat.
• Chat Backend-/WebSocket-Vertraege dokumentieren.
• Chat Room Liste implementieren.
• 1:1 Chat MVP implementieren.
• MultiChat MVP implementieren oder bewusst verschieben.
• RandomChat bewusst verschieben oder implementieren.
• Message Input mit Keyboard-Verhalten testen.
• Neue Nachrichten per Realtime anzeigen.
• Push-Kandidaten fuer Chat definieren.
• Melden/Blockieren im Chat implementieren oder als Release-Blocker markieren.

13. Galerie und Medien

• Galerie API-Vertraege erfassen.
• Folder-Struktur nativ modellieren.
• Bildliste mit Coil implementieren.
• Bilddetail implementieren.
• Android Photo Picker fuer Upload implementieren.
• Multipart Upload testen.
• Bildbearbeitung aus Web-App bewerten: MVP ja/nein.
• Sichtbarkeiten laden und setzen.
• Adult-Galerie aus MVP ausschliessen oder Compliance-Aufwand planen.
• Video-Unterstuetzung separat planen.

14. Forum

• Forum-Liste API-Vertrag erfassen.
• Topic-Liste API-Vertrag erfassen.
• Topic-Detail API-Vertrag erfassen.
• Forum-Liste native umsetzen.
• Topic-Liste native umsetzen.
• Topic-Detail native umsetzen.
• Antwort erstellen implementieren.
• Moderation Report fuer Forum implementieren.
• Realtime forumschanged integrieren.

15. Falukant MVP

• Falukant API-Endpunkte aus Web-App inventarisieren.
• StatusBar Datenmodell nativ definieren.
• Overview Screen implementieren.
• Character/Familien-Basisdaten implementieren.
• Branch-Liste implementieren.
• Branch-Detail light implementieren.
• Bank light implementieren.
• Messages/Notifications light implementieren.
• Realtime Falukant Events integrieren.
• Create Falukant Flow implementieren oder bewusst verschieben.
• Family View light implementieren.
• Church/Reputation/Health/Nobility als spaetere Phase markieren.
• Production/Storage/Sale/Director als spaetere Phase markieren.
• Karten-/Regionen-Features als spaetere Phase markieren.

16. Falukant Vollausbau

• Branch Detail vollstaendig umsetzen.
• Production Section umsetzen.
• Storage Section umsetzen.
• Sale Section umsetzen.
• Director Info umsetzen.
• Transport Routes umsetzen.
• Bank vollstaendig umsetzen.
• Family vollstaendig umsetzen.
• Health umsetzen.
• Reputation umsetzen.
• Church umsetzen.
• Nobility umsetzen.
• Politics umsetzen.
• Underground umsetzen.
• House umsetzen.
• Education umsetzen.
• Money History umsetzen.
• Performance fuer grosse Falukant-Datenmengen testen.

17. Vokabeltrainer MVP

• Vocab Languages API-Vertrag erfassen.
• Course List API-Vertrag erfassen.
• Course Detail API-Vertrag erfassen.
• Lesson API-Vertrag erfassen.
• Review API-Vertrag erfassen.
• Vocab Landing native umsetzen.
• Course List native umsetzen.
• Course Detail native umsetzen.
• Lesson Player MVP implementieren.
• Lesson Review implementieren.
• Dictionary light implementieren.
• Progress/Completion speichern.
• Keyboard-/Audio-/Touch-Verhalten testen.
• Offline Cache fuer aktive Lektion planen.

18. Vokabeltrainer Vollausbau

• Neue Sprache anlegen implementieren.
• Subscribe Flow implementieren.
• Chapter View implementieren.
• Dictionary vollstaendig implementieren.
• Practice Dialog nativ ersetzen.
• SRS-/Review-Logik gegen Backend validieren.
• Offline Lesson Cache implementieren.
• Sync-Konflikte definieren.

19. Kalender und Persoenliches

• Calendar API-Vertraege erfassen.
• Monats-/Wochen-/Listenansicht entscheiden.
• Termine laden.
• Termin erstellen.
• Termin bearbeiten.
• Termin loeschen.
• Date/Time Picker nativ einsetzen.
• Reminder/Push spaeter planen.
• Diary API-Vertrag erfassen.
• Diary light umsetzen oder verschieben.

20. Public Content

• Blog List API-Vertrag erfassen.
• Blog Detail API-Vertrag erfassen.
• Guide List API-Vertrag erfassen.
• Guide Detail API-Vertrag erfassen.
• Public Landing Screens nativ priorisieren oder aus App entfernen.
• Rich Text Rendering nativ loesen.
• Blog Editor aus MVP ausschliessen.
• Guide/Marketing Content als WebView-Fallback pruefen oder nativ rendern.

21. Minigames

• Match3 Game als native Compose/Canvas Machbarkeit pruefen.
• Taxi Game als native Canvas/OpenGL Machbarkeit pruefen.
• WebView-Fallback fuer Minigames als Zwischenloesung bewerten.
• Touch-Steuerung definieren.
• Performance auf Emulator und echtem Geraet testen.
• Leaderboard/Score API-Vertraege erfassen.
• Admin-Tools fuer Minigames aus nativer App ausschliessen.

22. Admin spaeter

• Entscheiden, ob Admin ueberhaupt in native App gehoert.
• Admin Users API-Vertraege erfassen.
• Admin Rights API-Vertraege erfassen.
• Moderation Reports API-Vertraege erfassen.
• Adult Verification API-Vertraege erfassen.
• Erotic Moderation API-Vertraege erfassen.
• Forum Admin API-Vertraege erfassen.
• Falukant Admin API-Vertraege erfassen.
• Services Status Screen fuer interne Builds planen.
• Admin nur per Feature Flag und Rollencheck sichtbar machen.

23. Adult Content und Store-Compliance

• Adult Content aus MVP entfernen oder per Feature Flag deaktivieren.
• Altersverifikation nativ modellieren.
• UGC-Melden nativ in Chat, Galerie, Forum, Profil implementieren.
• Blockieren nativ implementieren.
• Moderationserreichbarkeit dokumentieren.
• Datenschutzseite nativ erreichbar machen.
• Impressum nativ erreichbar machen.
• Kontakt nativ erreichbar machen.
• Account-Loeschung oder klare Anleitung nativ erreichbar machen.
• Play Store Content Rating vorbereiten.
• Store-Review-Risiko fuer Adult Content separat entscheiden.

24. Push Notifications

• Firebase Projekt klaeren.
• FCM in native App integrieren.
• Device Token Backend-Modell planen.
• Device Token Registration API definieren.
• Opt-in UI implementieren.
• Notification Settings implementieren.
• Chat Push definieren.
• Friend Login Push definieren.
• Falukant Event Push definieren.
• Vocab Reminder Push definieren.
• Deep Links aus Notifications implementieren.
• Token Refresh Handling implementieren.

25. Deep Links und OAuth

• App Links Domain festlegen.
• assetlinks.json planen.
• OAuth Redirect URIs fuer Android planen.
• Custom Tabs Flow implementieren.
• OAuth Callback Handling implementieren.
• Deep Links fuer Profile, Forum, Falukant, Vocab, Blog definieren.
• Deep Link Auth Guard implementieren.
• Nicht eingeloggte Deep Links nach Login fortsetzen.

26. Sicherheit

• Authdaten nicht im Klartext speichern.
• Release Logging sensibler Daten verhindern.
• Certificate Pinning bewerten, nicht vorschnell erzwingen.
• Network Security Config fuer Release restriktiv halten.
• Root/Jailbreak Detection bewusst entscheiden.
• Screenshot-Schutz fuer Adult/Private Bereiche bewerten.
• Datei-Uploads auf MIME/Größe pruefen.
• WebView-Fallbacks minimieren.
• Dependency-Scanning fuer Android einrichten.

27. Testing

• Unit Tests fuer Auth Repository.
• Unit Tests fuer Settings Repository.
• Unit Tests fuer Error Mapping.
• MockWebServer Tests fuer Auth Header.
• MockWebServer Tests fuer API-Fehler.
• Room Migration Tests.
• Compose Tests fuer Login.
• Compose Tests fuer Navigation.
• Compose Tests fuer Home.
• Compose Tests fuer Vocab Lesson.
• Realtime Tests mit Testserver planen.
• Emulator-Testmatrix definieren: kleines Phone, grosses Phone, Tablet.
• Echtes Android-Geraet in Testmatrix aufnehmen.
• Offline/Online-Wechsel testen.
• App Kill/Restart/Resume testen.

28. Build, Release und Betrieb

• Debug APK Build einrichten.
• Release AAB Build einrichten.
• Signing-Konzept definieren.
• Keystore sicher ablegen.
• Internal App Sharing oder interne Testspur planen.
• Crashlytics oder alternatives Crash Reporting entscheiden.
• Analytics bewusst entscheiden: ja/nein, Datenschutz.
• App Version Check implementieren oder planen.
• Rollback-Strategie definieren.
• Hybrid-App und Native-App Parallelbetrieb dokumentieren.

29. Backend-Vorbereitung fuer Native

• Mobile API-Inventar aus allen Web-Komponenten erstellen.
• API-Versionierung bewerten: /api/mobile/v1 ja/nein.
• Einheitliches Fehlerformat definieren.
• Einheitliches Pagination-Format definieren.
• Auth auf Bearer Token/JWT oder bestehendes userid/authcode final entscheiden.
• Refresh Token Konzept bewerten.
• Device Token API fuer Push planen.
• Datei-Upload-Limits dokumentieren.
• Image Thumbnail Endpunkte fuer mobile Listen planen.
• Falukant Summary Endpunkte fuer mobile Screens planen.
• Vocab Lesson Endpunkte fuer mobile Offline-Caches planen.

30. Abnahmekriterien MVP

• App startet kalt unter 2 Sekunden auf Testgeraet oder Zielwert begruendet anpassen.
• Login funktioniert gegen production/staging.
• Session ueberlebt App-Neustart.
• Logout entfernt lokale Session und trennt Realtime.
• Home laedt ohne WebView.
• Navigation ist vollstaendig nativ.
• Mindestens ein Social-Basisflow funktioniert.
• Mindestens ein Falukant-Basisflow funktioniert.
• Mindestens ein Vocab-Lesson-Flow funktioniert.
• Fehler werden nativ und verstaendlich angezeigt.
• Offline-Zustand wird erkannt und blockiert keine App.
• Keine lokalen Dev-URLs im Release-Build.
• Keine Secrets im APK/AAB.
• Datenschutz, Impressum und Kontakt sind erreichbar.

Empfohlene erste Umsetzungsschritte

1. /android/native als neues Kotlin/Compose-Projekt anlegen.
2. Core Module fuer Network, Auth, Design und Navigation erstellen.
3. Login komplett nativ implementieren.
4. Session Store und Auth Interceptor stabilisieren.
5. Native App Shell mit Home und Navigation bauen.
6. Danach Social light, Falukant light und Vocab light nacheinander umsetzen.

Realistische Einordnung

Die native Komplettumsetzung ist erheblich groesser als die Hybrid-App. Die Hybrid-App ist sinnvoll als lauffaehige Zwischenloesung und Referenzimplementierung. Die native App sollte als paralleles Produkt mit klarem MVP gestartet werden, sonst entsteht ein langer Rewrite ohne nutzbaren Zwischenstand.