iOS ist die Hauptfassung. Diese hier ist der
Vollständigkeit halber gebaut und hinkt hinterher. Sie läuft, steht aber nicht
im Play Store und kann weniger.
Eigene Codebasis in Kotlin, kein geteiltes Modul mit iOS. Portiert sind der
Kern und die Rechenregeln: Satz loggen, Pausentimer, Gerätekatalog,
Gewichtsvorschlag, Aufwärmrampe und das geschätzte Maximum. Deutsch und
Englisch.
Kein Lauf auf einem echten Gerät. Ton und Haptik sind dadurch ungeprüft.
Alles andere ist im Emulator geprüft, auch im Release-Build.
Keine Gesundheitsdaten. Health Connect ist nicht angebunden, auf iOS
liefert HealthKit Gewicht und Cardio.
Keine Widgets. Auf iOS bringt WidgetKit den Pausentimer auf den
Sperrbildschirm, hier fehlt das Gegenstück.
Der Play-Eintrag ist nicht angelegt. Konto, Signierung, AAB, Grafiken
und Screenshots stehen. Die Datenschutzerklärung liegt unter
gym.linusfritz.com/datenschutz-android/.
02
Warum eine zweite Codebasis
Entscheidung: kein Flutter, kein Kotlin Multiplatform
Geprüft und entschieden am 27.08.2026. Flutter kompiliert beide
Plattformen aus einer Dart-Codebasis. Trotzdem verworfen. Die iOS-App ist
live bei 1.1 mit 426 grünen Tests. Dart wäre eine neue Sprache. Widgets und
Live Activities kann Flutter nicht, der plattformspezifische Code bleibt also
ohnehin. Und Nutzer der laufenden Fassung verlieren ohne Migration ihre
Datenbank.
Kotlin Multiplatform bleibt der spätere Weg, wenn zwei Codebasen zu teuer
werden. Der geht aus dieser Kotlin-Codebasis heraus, ohne die iOS-App
anzufassen.
Eine Quelle für die Rechenregeln
Das Risiko bei zwei Codebasen ist Drift. iOS schlägt eine Pausenlänge vor,
Android eine andere. Das fällt niemandem auf, weil beide für sich plausibel
aussehen.
Dagegen steht eine gemeinsame Fall-Sammlung statt geteiltem Code:
shared/coach-cases.json. Die Datei enthält 32 Fälle mit
Eingabe und erwartetem Ergebnis. 10 für das geschätzte Maximum nach Epley,
12 für die Pausenlänge, 10 für die Aufwärmrampe.
Beide Apps lesen dieselbe Datei in ihren Tests. Weicht Android ab, wird
CoachCasesTest rot. Die Regel dazu: Ändert sich eine Coach-Regel,
ändert sich zuerst coach-cases.json. Danach werden beide Apps
grün gemacht, nicht umgekehrt.
Der Gerätekatalog wird generiert
Die 90 Geräte sind reine Daten und werden hier nicht von Hand gepflegt.
Ein Python-Skript liest die iOS-Quelle und schreibt den Android-Katalog:
EquipmentStore.swift plus Localizable.xcstrings
ergeben equipment-catalog.json. Alle 90 tragen einen deutschen und
einen englischen Namen.
Was auf beiden Plattformen anders heißt
Aufgabe
iOS
Android
Oberfläche
SwiftUI
Jetpack Compose, Material 3
Datenbank
SwiftData
Room 2.7.1
Testrahmen
Swift Testing
JUnit 4
Gesundheitsdaten
HealthKit
fehlt
Widgets, Live Activity
WidgetKit, ActivityKit
fehlt
Coach-Regeln
Eine gemeinsame Fall-Sammlung
Gerätekatalog
Quelle
generiert
Die Testlücke
426 Tests auf iOS, 29 hier. Die Lücke ist echt und nicht schöngerechnet.
iOS ist seit Juli 2026 im Store, die Suite ist mit jedem Feature
mitgewachsen. Android ist im August portiert worden. Die 29 Tests decken die
Stellen, an denen die Plattformen auseinanderlaufen können: Pausentimer,
Satzzählung, Formatierung, Gerätekatalog und die geteilten Coach-Fälle. Dort
ist der Schaden am größten, weil ein Unterschied dem Nutzer nicht auffällt.
Die Oberfläche ist bisher von Hand geprüft.
Hauptfassung
Der Aufbau, die Coach-Rechnungen und die Entscheidungen stehen auf der
iOS-Seite. Dort läuft die App, die veröffentlicht ist.
