Eine Ablehnung trifft ein
Szene 5 von 13
Apple lehnte Version 1.0 am 20. September ab: sechs offene Punkte unter Guideline 2.1. Bevor irgendetwas repariert wird, muss der tatsächliche Zustand festgestellt werden.
Erklärung
Lenn und Jakob, eine Ablehnung ist kein Rätsel — sie ist eine Liste. Bevor irgendetwas repariert wird, muss der Ist-Zustand feststehen: Welche Version ist abgelehnt? Welcher Build ist tatsächlich getestet? Ist das ein neuer App-Store-Prüfungsvorgang oder ein interner TestFlight-Beta-Vorgang — zwei verschiedene Apple-Prozesse, die leicht verwechselt werden. Die erste Handlung war deshalb keine Reparatur, sondern eine schreibgeschützte Bestandsaufnahme über die App-Store-Connect-API: Version, Build, Einreichungs-ID, Freigabeart. Nichts wurde verändert, bevor der Ist-Zustand feststand. Merkt euch drei getrennte Begriffe: die Version trägt den App-Store-Zustand und die Freigabeart; der Build ist eine konkrete kompilierte Binärdatei; die Prüfungseinreichung ist der eigentliche Vorgang bei Apple — „erneut einreichen“ bearbeitet diese Einreichung, es entsteht keine neue.
Drei Zustände, drei Fragen
- Version
- Trägt den App-Store-Zustand (abgelehnt, in Prüfung, bereit) und die Freigabeart.
- Build
- Eine konkrete kompilierte Binärdatei mit eigener Kennung.
- Prüfungseinreichung
- Der eigentliche Vorgang bei Apple mit eigenem Status.
Denkpause
Ein interner TestFlight-Build ist als „bereit für Beta-Prüfung“ markiert. Bedeutet das, Apples App-Prüfung läuft bereits?
Ja, jeder TestFlight-Build wird automatisch geprüft.
TestFlight-Beta-Prüfung und App-Store-Prüfung sind getrennte Vorgänge.
Nein — interne Verfügbarkeit, externe Beta-Prüfung und App-Store-Einreichung sind drei verschiedene Zustände.
Richtig. Drei verschiedene Zustände, drei verschiedene Fragen.
Nein, TestFlight-Builds werden nie geprüft.
Eine externe TestFlight-Beta-Prüfung existiert, wurde hier aber nie angefordert.
Belege
Bestandsaufnahme · Live-Zustand dokumentiert · Add App Review submission package for build 1.0 (9): BLOCKED on two owner decisions
2026-09-23 · docs/lernbegleiter/engineering/app-review-submission-package-2026-09-23_06-34-27.md · 978ed8d2d4dfbe821e8a4026bb97487e2f929575
| App Store version | `1.0`, state **REJECTED**, `releaseType = MANUAL` (manual release confirmed) |
| Build currently attached to the version | `1.0 (1)` (`b95cefed…`, stale, Sep 20) — **must be replaced** |
| Owner-accepted candidate | `1.0 (9)` (`38300f7e…`), `processingState VALID`, uploaded 2026-09-23 06:13 CEST, `usesNonExemptEncryption = false` (export compliance answered) |
| Build 9 TestFlight state | internal group only: `internalBuildState IN_BETA_TESTING`, `externalBuildState READY_FOR_BETA_SUBMISSION` → **no external TestFlight Beta App Review has been requested** (distinct from App Store review) |
| Review submission | `9396181b…`, state `UNRESOLVED_ISSUES` (Guideline 2.1 Information Needed, Sep 20). Resubmission = edit this submission ("Resubmit to App Review"), not a new one |
| Build 9 provenance | source `5f59f2c4`, contains crash fix `58069ab2` and nav fix `089a774f` (merged); `ios/fastlane/.env` BUILD_NUMBER 1→9 was the only working-tree delta; IPA SHA256 `3323cd06…` (receipt `ios-testflight-build9-receipt-2026-09-23_06-16-06.md`, worktree `ios-combined`) |
| **Backend baked into build 9** | `https://study-dev.emedys.com` (Release-Dev scheme). `pecs.emedys.com` today still lacks the 4-language login work (`/static/i18n.js` 404, `otp-login.js` last-modified 2026-09-21) |
Build 9 is reused; no demonstrated requirement forces a replacement. A replacement would only
be needed if the owner chooses the `pecs` backend (§7.2), which requires a Release-scheme build
under a new build number and a production deployment that is not authorized.Mit meinem Konto im Hörsaal öffnen →