till/mana-swift-ui
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
mana-swift-ui/devlog/2026-05-13/macher.md
Till JS e284240f3c devlog: 1 Tag geschrieben (v0.1.0–v0.5.0 Sprint) 
ManaAuthUI-Initialsprint mit 5 Versions-Schritten in einer Session.
spieler.md + macher.md hand-curated.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-15 22:21:39 +02:00

3.3 KiB
Raw Blame History

date day view weekday commits review
2026-05-13 1 macher Mittwoch 5 written

Mittwoch, 2026-05-13 — Tag 1 (Macher-Sicht)

Initialer Sprint des Pakets. Aus drei fast-byte-identischen LoginView.swift-Files in cards-native, manaspur-native und memoro-native wird ein gemeinsames Swift-Package — plus das, was bisher gar nicht da war: Sign-Up, E-Mail-Verifikation, Passwort-Reset, Account-Management. Und 2FA, weil die Lücke beim Aufräumen sichtbar wurde.

Stats

5 Commits, +4 247 / −4 LoC, 39 Files. Sessionspanne 17:22 → 01:08, ~48 aktive Minuten in einem Durchstich. Bei +4 243 netto ist das v0.1.0 mit allem Anhang, nicht „aktive Tipparbeit" — die Inhalte flossen aus den drei App-Repos zusammen.

Versionsschritte des Tages

  • v0.1.0 — vollständige Auth-Reise als SwiftUI: Login, Sign-Up, Email-Verify-Gate, Forgot-/Reset-Password, Change-Email, Change-Password, Delete-Account. ViewModels strikt getrennt von Views, jeder Flow eigene @Observable-State-Maschine.
  • v0.2.0 — ManaAuthGate, der „bitte-erst-einloggen"-Wrapper für Action-Level-Eskalation. Cards/Manaspur/Memoro brauchen das pro Aktion, nicht pro Screen.
  • v0.3.0 — ManaTwoFactorChallengeView für den Login-Step, wenn der Server 2FA verlangt.
  • v0.4.0 — ManaTwoFactorEnrollView (QR-Code + Verify) und ManaTwoFactorDisableView (Passwort-Bestätigung).
  • v0.5.0 — ManaTwoFactorAccountRow für den Account-Tab und ManaBackupCodeRegenerateView.

Fünf Tags in einer Session ist viel — der Schnitt war pro Feature-Komplex, damit Consumer-Apps gezielt minor-bumpen können ohne 2FA mitzunehmen, das sie noch nicht zeigen.

Architektur-Entscheidungen

  • Pure SwiftUI, keine UI-Lib — gleiche Regel wie ManaCore. Senkt Drift-Risiko zwischen Vereins-Apps.
  • App injiziert ManaBrandConfig — Pakets-Sources kennen keinen App-Namen, keine Farben. forest/mana/künftige Themes leben in der konsumierenden App, bis Token-Theme-Variants kommen.
  • ViewModel-zuerst-Pattern. Tests gehen gegen ViewModels via URLProtocol-Mock, Views sind dünn und ungetestet — das passt zum Swift-Test-Realismus auf macOS-CI.
  • Account-Löschung ist Pflicht (App-Store-Guideline 5.1.1(v)); ManaDeleteAccountView ist Bestandteil jedes Sign-Up-Anbieters.
  • 2FA-Flow läuft komplett über ManaCore v1.2.0 (Guest-Mode + Refresh-Resilience), keine eigenen API-Wrapper in UI.

Trade-offs

  • 4 243 netto Zeilen für „v0.1.0 + v0.5.0 in einer Session" — das hat nur funktioniert, weil drei Source-Repos schon Login-Code in ähnlicher Form hatten. Hätten wir Sign-Up parallel in drei Apps gebaut, wäre der Tag dreimal so lang.
  • Sprache deutsch im Public-API. Lokalisierungs-Refactor später, wenn EN-Bedarf real wird; jetzt würde die Indirection bremsen.
  • 2FA UI ist da, aber Server-seitig fehlt der Endpoint in mana-auth noch in mancher Form — die Views laufen daher zunächst gegen Stub-Antworten.

Offene Punkte

  • ManaTokens-Theme-Variants → erst dann ManaBrandConfig ersetzen.
  • Snapshot-Tests für Views fehlen; ViewModel-Tests laufen.
  • Localizable.xcstrings (EN) noch nicht angelegt — kommt mit der ersten konkreten EN-Anforderung.
  • Cross-App-Probelauf: 2FA-Enroll von cards-native gegen Production noch nicht durchgespielt.