Nach dem ersten erfolgreichen Play-Store-Release: expo-updates in mobile/ installieren und konfigurieren, damit kuenftige reine JS-/UI-Aenderungen (kein neues Permission, kein Icon-Wechsel, keine neue native Bibliothek) ohne erneute Play-Store-Pruefung als Over-the-Air-Update ausgeliefert werden koennen, statt jedes Mal einen neuen nativen Build + Store-Review zu brauchen.
Aufgaben:
expo-updates Package installieren
runtimeVersion-Policy festlegen (app.json)
updates.url + channel pro eas.json-Build-Profil konfigurieren
Einen Build machen, der expo-updates enthaelt (einmalig noetig, danach OTA moeglich)
eas update Workflow dokumentieren (README.md in mobile/)
Bewusst zurueckgestellt, bis die laufende erste Play-Store-Pruefung abgeschlossen ist - ein weiterer nativer Build waehrend der Pruefung waere kontraproduktiv.
Nach dem ersten erfolgreichen Play-Store-Release: expo-updates in mobile/ installieren und konfigurieren, damit kuenftige reine JS-/UI-Aenderungen (kein neues Permission, kein Icon-Wechsel, keine neue native Bibliothek) ohne erneute Play-Store-Pruefung als Over-the-Air-Update ausgeliefert werden koennen, statt jedes Mal einen neuen nativen Build + Store-Review zu brauchen.
Aufgaben:
- expo-updates Package installieren
- runtimeVersion-Policy festlegen (app.json)
- updates.url + channel pro eas.json-Build-Profil konfigurieren
- Einen Build machen, der expo-updates enthaelt (einmalig noetig, danach OTA moeglich)
- eas update Workflow dokumentieren (README.md in mobile/)
Bewusst zurueckgestellt, bis die laufende erste Play-Store-Pruefung abgeschlossen ist - ein weiterer nativer Build waehrend der Pruefung waere kontraproduktiv.
Erledigt in Commit bad24e6 (mobile 1.0.2, versionCode 3): expo-updates installiert, per eas update:configure eingerichtet (runtimeVersion policy "appVersion", eigene EAS-Update-Channels je eas.json-Build-Profil: development/preview/production). App ist mit diesem Build live (Closed Testing, 2026-09-08). Kuenftige reine JS/UI-Fixes koennen ab jetzt per eas update --branch production ausgeliefert werden, ohne neuen Play-Store-Review.
Erledigt in Commit bad24e6 (mobile 1.0.2, versionCode 3): expo-updates installiert, per `eas update:configure` eingerichtet (runtimeVersion policy "appVersion", eigene EAS-Update-Channels je eas.json-Build-Profil: development/preview/production). App ist mit diesem Build live (Closed Testing, 2026-09-08). Kuenftige reine JS/UI-Fixes koennen ab jetzt per `eas update --branch production` ausgeliefert werden, ohne neuen Play-Store-Review.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Nach dem ersten erfolgreichen Play-Store-Release: expo-updates in mobile/ installieren und konfigurieren, damit kuenftige reine JS-/UI-Aenderungen (kein neues Permission, kein Icon-Wechsel, keine neue native Bibliothek) ohne erneute Play-Store-Pruefung als Over-the-Air-Update ausgeliefert werden koennen, statt jedes Mal einen neuen nativen Build + Store-Review zu brauchen.
Aufgaben:
Bewusst zurueckgestellt, bis die laufende erste Play-Store-Pruefung abgeschlossen ist - ein weiterer nativer Build waehrend der Pruefung waere kontraproduktiv.
Erledigt in Commit
bad24e6(mobile 1.0.2, versionCode 3): expo-updates installiert, pereas update:configureeingerichtet (runtimeVersion policy "appVersion", eigene EAS-Update-Channels je eas.json-Build-Profil: development/preview/production). App ist mit diesem Build live (Closed Testing, 2026-09-08). Kuenftige reine JS/UI-Fixes koennen ab jetzt pereas update --branch productionausgeliefert werden, ohne neuen Play-Store-Review.