5d6c322129
Sheets via neuer KeyboardAwareSheet-Composable (in Modal pattern, auto-grow mit Tastatur, paddingBottom-Lift): EditMail, AddDomain, CreateRoom, ConnectMail. GameOverScreen behält Spring-Slide-In, nutzt RN Keyboard.addListener für Lift. - KeyboardAwareSheet.tsx — universal modal with sheet-grow + keyboard-padding - react-native-keyboard-controller installiert + KeyboardProvider in Root - Snake: time + ScoreProgressBar + useSnakeSounds (haptic, audio TODO) - Tetris: title weg, Buttons zentriert, kein Pressable mit style-fn - DPad-Buttons 60→48, more bg, no scale - useMe: pub-sub listener pattern für app-weite avatar/nickname-Updates - dm.tsx: resolveAvatar wrap (iron.png-Warning) - Mail-error-humanizer + locales Recovery-Doc-Update in docs/internal/RECOVERY_LOG_2026-05-10.md Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
245 lines
17 KiB
Markdown
245 lines
17 KiB
Markdown
# ReBreak macOS — Entscheidungsgrundlage
|
||
|
||
**Stand:** 2026-05-10
|
||
**Scope:** Research only. Kein Prototype, kein Code, keine Dependencies.
|
||
**ReBreak-Stack:** Expo SDK 54, RN 0.81, NEFilterDataProvider (iOS App Extension), FamilyControls/ManagedSettings, Hermes + NewArch.
|
||
|
||
---
|
||
|
||
## 1. TL;DR
|
||
|
||
Pfad 4 (Browser-Extension) ist der schnellste Weg zu einem funktionierenden macOS-Blocker ohne App-Umbau. Pfad 3 (Native Swift Mac-App) ist der langfristig sauberste Weg mit echtem System-Level-Blocking, aber erfordert einen separaten Greenfield-Build. Pfad 1 und 2 scheitern beide am selben fundamentalen Problem: FamilyControls und NEFilterDataProvider in ihrer iOS-Form existieren auf macOS nicht — die RN-zu-Mac-Bridges kaufen dir UI-Portierung, lösen aber nicht das Kernproblem Blocking.
|
||
|
||
---
|
||
|
||
## 2. Pfad-Vergleich-Tabelle
|
||
|
||
| Pfad | Effort (Wochen) | Blocking funktioniert? | Cross-platform? | Maintenance | Risiko |
|
||
|---|---|---|---|---|---|
|
||
| 1 — Mac Catalyst | 6–10 | Nein (FamilyControls iOS-only) | Nein | Hoch (Apple API-drift) | Sehr hoch |
|
||
| 2 — RN macOS | 8–14 | Nein (kein FamilyControls, NEFilter anders) | Nein | Mittel-Hoch | Hoch |
|
||
| 3 — Native Swift | 8–12 | Ja (NEFilterDataProvider System Extension) | Nein (nur Mac) | Niedrig | Mittel |
|
||
| 4 — Browser-Extension | 3–5 | Eingeschränkt (kein App-Bypass, kein HTTPS-Intercept ohne Proxy) | Ja (Win/Mac/Linux) | Niedrig | Niedrig |
|
||
| 5 — MDM-Profil | 0 | Ja (DNS-Level, kein Bypass ohne IT-Admin) | Nein (nur eigenes Device) | Null | Null |
|
||
|
||
---
|
||
|
||
## 3. Pfad-Details
|
||
|
||
### Pfad 1: Mac Catalyst
|
||
|
||
**Was funktioniert:**
|
||
- react-native-bottom-tabs explizit macOS-fähig (Callstack hat Screenshots im README)
|
||
- nativewind: README sagt "works on all RN platforms"
|
||
- react-native-screens: keine aktiven macOS-spezifischen open Bugs
|
||
- Nuxt-unabhängige Logik (API-calls, Auth via Supabase-JS) wäre ohne Änderung nutzbar
|
||
|
||
**Was bricht:**
|
||
|
||
FamilyControls und ManagedSettings sind iOS/iPadOS-only. Apple hat diese Frameworks nie auf macOS portiert, auch nicht via Catalyst. `@available(macOS, unavailable)` ist in Apples eigenen Headers gesetzt. Das bedeutet: der gesamte Screen-Time-Layer (AppShield, App-Blocking, Activity-Monitoring) ist auf macOS nicht verfügbar. Kein Workaround ohne komplettes Redesign.
|
||
|
||
NEFilterDataProvider auf iOS ist ein App Extension, der ohne Sondergenehmigung läuft. Auf macOS Catalyst ist das Framework technisch präsent, aber Network Extension Content Filter auf macOS erfordert die Entitlement `com.apple.developer.network-extension.content-filter`, die bei Apple manuell beantragt werden muss und an System Extensions (nicht App Extensions) gebunden ist. Catalyst-Apps sind keine System Extensions.
|
||
|
||
Konkrete Module-Probleme:
|
||
- `react-native-mmkv` v3+: README nennt nur iOS/Android/Web. GitHub zeigt 47 offene Issues, macOS/Catalyst nicht erwähnt. Das Library liefert ab v3 precompiled XCFrameworks — und das `maccatalyst`-Slice fehlt laut Issue #1268 (Stand Mai 2026 open, keine Aktivität).
|
||
- `@react-native-async-storage/async-storage`: Issue #1268 (open, März 2026): v3 liefert kein `maccatalyst`-Slice im XCFramework mehr. Build bricht.
|
||
- `@lodev09/react-native-true-sheet`: Issues gefunden unter macOS "Designed for iPhone"-Modus (macOS führt iOS-Apps seit macOS 11 aus, aber das ist kein Catalyst-Build). Fix-PR für diesen Modus war in Arbeit, Status unklar.
|
||
- `rive-react-native`: Kein macOS-Support erwähnt, iOS/Android only laut README.
|
||
- `lottie-react-native`: 0 macOS/Catalyst Issues — deutet darauf hin dass niemand es versucht (kein positiver Support-Signal).
|
||
- `expo-apple-authentication`: Funktioniert technisch auf macOS Catalyst (Sign in with Apple ist verfügbar), aber ist nicht dokumentiert.
|
||
- `expo-haptics`: No-op oder crash auf macOS (kein Taptic Engine).
|
||
|
||
**Geschätzter Effort:** 6–10 Wochen allein für Build-Green auf Catalyst, ohne dass Blocking funktioniert.
|
||
|
||
**Blocking-Fazit:** Nicht machbar. Catalyst löst nur das UI-Problem, nicht das Kern-Feature.
|
||
|
||
---
|
||
|
||
### Pfad 2: React Native macOS (Microsoft Fork)
|
||
|
||
**Maintenance-State:**
|
||
- Aktuelles Release: v0.81.2 (2026-02-11) — exakt kompatibel mit ReBreaks RN 0.81.5
|
||
- Repo aktiv: zuletzt geupdated 2026-05-09, 4.327 Stars, 96 open Issues
|
||
- NewArch (Fabric): teilweise implementiert. Aktive open Bugs: TextInput multiline scrollt nicht in Fabric, Focus-Ring-Verhalten, Transform-Clipping. Grundlegende Fabric-Issues sind aber weiter zugemacht worden (Text selectable, platform colors etc.) — die Richtung stimmt.
|
||
- RN macOS unterstützt macOS 11 (Big Sur) und neuer.
|
||
|
||
**Expo-Kompatibilität:**
|
||
RN macOS ist ein Fork von facebook/react-native, nicht kompatibel mit Expo Managed Workflow. Expo prebuild (bare workflow) ist theoretisch möglich, aber Expo-Module sind nicht für RN macOS gebaut. expo-modules-core enthält keine macOS-Targets. Kein Expo SDK Modul (expo-av, expo-notifications, expo-haptics, expo-apple-authentication etc.) hat offiziell RN macOS Support.
|
||
|
||
Das bedeutet: alle Expo-Module müssten durch native macOS Äquivalente ersetzt oder komplett gestripped werden.
|
||
|
||
**Was funktioniert:**
|
||
- react-native-bottom-tabs: explizit macOS-Support vorhanden (Callstack README zeigt macOS Screenshot)
|
||
- react-navigation/native: läuft auf RN macOS (Microsoft nutzt es intern für Teams/Outlook-Teile)
|
||
- zustand, react-query, i18next: pure JS, kein Problem
|
||
- Supabase-JS: pure JS, kein Problem
|
||
|
||
**Was bricht / fehlt:**
|
||
- Kein FamilyControls, kein ManagedSettings — exakt gleiche Lage wie Pfad 1
|
||
- NEFilterDataProvider auf macOS: ANDERS als auf iOS. Auf macOS muss der Filter-Provider als System Extension laufen (eigener Prozess, privilegiert, separate App-Bundle-Component). RN macOS hat kein Framework dafür — das wäre nativer Swift/ObjC Code komplett außerhalb des RN-Layers.
|
||
- react-native-mmkv: iOS/Android/Web only (README explizit). Kein macOS-Target.
|
||
- react-native-reanimated: 354 offene Issues mit "macos" im Search-Context, aber keines bezieht sich auf RN macOS spezifisch. Reanimated macht seine eigene JSI-Integration und ist nicht für RN macOS portiert (Hypothese, ungeprüft — kein positiver Hinweis auf Support).
|
||
- react-native-gesture-handler: hat 151 macOS-related Issues, aber die meisten beziehen sich auf Mac Catalyst oder unrelated. Keine explizite RN macOS Unterstützung in der README.
|
||
- rive-react-native: iOS/Android only
|
||
- lottie-react-native: 0 macOS Issues (kein positiver Signal)
|
||
- expo-router: nicht kompatibel mit RN macOS (Expo-Abhängigkeit)
|
||
|
||
**Effort-Schätzung:**
|
||
- Woche 1–2: RN macOS initialisieren, Build-System aufsetzen, Podfile anpassen
|
||
- Woche 3–5: Expo-Module ersetzen (expo-av → AVFoundation nativ, expo-notifications → NSUserNotifications, etc.)
|
||
- Woche 6–8: mmkv durch NSUserDefaults oder nativem Äquivalent ersetzen, Reanimated patchen oder ersetzen
|
||
- Woche 9–12: Rive-Animationen entfernen/ersetzen, Layout-Bugs fixen (Fabric-Issues), macOS-spezifische UI (Fenster-Resize, Menübar, Kontextmenüs)
|
||
- Woche 13–14: Testing, kein Blocking-Feature
|
||
|
||
Mindestens 12–14 Wochen, und am Ende kein Blocking. Das ist die Investition ohne das Kern-Feature.
|
||
|
||
**Blocking-Fazit:** Nicht machbar mit vertretbarem Aufwand. System Extension ist nativer Swift-Code komplett außerhalb des RN-Layers, und der Aufwand dafür überschneidet sich mit Pfad 3.
|
||
|
||
---
|
||
|
||
### Pfad 3: Native Swift Mac-App (Greenfield)
|
||
|
||
**NEFilterDataProvider auf macOS — Status:**
|
||
NEFilterDataProvider ist auf macOS seit macOS 10.15 als System Extension verfügbar (via `NetworkExtension.framework`). SelfControl (4.344 Stars, aktiv, zuletzt 2026-05-10 geupdated) nutzt als Alternative `/etc/hosts`-Manipulation + Berkeley Packet Filter (`pf`) via `PacketFilter.m` und `HostFileBlocker.m`. Das ist der einfachere Weg, erfordert aber Adminrechte.
|
||
|
||
System Extension NEFilterDataProvider (kein Root nötig, aber):
|
||
- Entitlement `com.apple.developer.network-extension.content-filter` muss bei Apple beantragt werden (kein normales Developer-Account-Feature). Apple erwartet Use-Case-Begründung.
|
||
- System Extension muss vom User in Systemeinstellungen > Sicherheit aktiviert werden (macOS-Gatekeeper-Flow).
|
||
- Build-Komplexität: separate Bundle-Target in Xcode, eigener App-Lifecycle, IPC zwischen Main-App und Extension.
|
||
- Gut dokumentiert in Apple Human Interface Guidelines und Network Extension Programming Guide.
|
||
|
||
Kein öffentliches Swift-Beispiel auf GitHub gefunden (API-Suche lieferte 0 Ergebnisse für NEFilterDataProvider + Swift + macOS in Repositories). Das deutet auf closed-source-Landschaft hin (Freedom, Focus, Cold Turkey, Parental Controls etc. sind alle proprietär).
|
||
|
||
Alternativer Ansatz — NEDNSProxyProvider (DNS-Level-Filter):
|
||
- Einfachere Entitlement, kein System Extension Review-Prozess
|
||
- Blockiert auf DNS-Ebene (kein per-Request-Filtering, kein HTTPS-Inspection)
|
||
- Wirksam gegen ~208k Casino-Domains wenn die Blocklist als lokaler DNS-Resolver fungiert
|
||
- Vergleichbar mit NextDNS/AdGuard DNS-Approach
|
||
|
||
Reuse vom Backend:
|
||
- REST-API (Nuxt Nitro auf Hetzner): vollständig wiederverwendbar
|
||
- Blocklist JSON (208k Domains): format-kompatibel, nur laden + DNS-Lookup-Check
|
||
- Auth-Flow (Supabase JWT): standard HTTP, kein Problem
|
||
- Nur die iOS-UI und die iOS-spezifischen APIs müssen neu gebaut werden
|
||
|
||
**Notarization:**
|
||
Apple Developer Account (Raynis e.K.) ist vorhanden. Notarization ist Standard-Prozess bei Xcode Archive. kein Zusatz-Review nötig (im Gegensatz zu App Store).
|
||
|
||
**Minimaler Feature-Scope für ersten Build:**
|
||
1. Login via Sign in with Apple (macOS unterstützt das)
|
||
2. Blocklist laden von API oder gebündelt
|
||
3. NEDNSProxyProvider aktivieren (DNS-Blocking)
|
||
4. Status-Anzeige (aktiv/inaktiv, Anzahl blockierter Anfragen)
|
||
5. Ein-/Ausschalten
|
||
Das ist eine kleine App, nicht feature-parity mit der iOS-App.
|
||
|
||
**Geschätzter Effort:**
|
||
- Woche 1–2: Xcode-Projekt setup, Network Extension Target, Entitlement-Antrag bei Apple
|
||
- Woche 3–4: NEDNSProxyProvider implementieren + Blocklist-Integration
|
||
- Woche 5–6: Auth (Sign in with Apple + Supabase), API-Sync der Blocklist
|
||
- Woche 7–8: Minimal-UI (SwiftUI, Menübar-App oder Hauptfenster), Notarization
|
||
- Woche 9–10: Testing, Edge-Cases, macOS 13/14/15 Kompatibilität
|
||
|
||
Realistisch: 10–12 Wochen für einen funktionsfähigen, testbaren Build. Feature-parity (Streak, SOS-Chat, Games) wäre deutlich mehr.
|
||
|
||
**Risiken:**
|
||
- Entitlement-Genehmigung: Apple kann Anfragen für `com.apple.developer.network-extension.content-filter` ablehnen oder verzögern. Mit NEDNSProxyProvider ist dieses Risiko geringer.
|
||
- System Extension Activation: User muss explizit in macOS Systemeinstellungen bestätigen. Onboarding-Hürde.
|
||
- macOS Gatekeeper + Notarization: kann bei Libraries/Deps Probleme machen, aber mit reinem SwiftUI + Apple Frameworks ist das manageable.
|
||
|
||
---
|
||
|
||
### Pfad 4: Browser-Extension (Safari / Chrome / Firefox)
|
||
|
||
**Blocking-Mechanismus:**
|
||
WebExtension Standard (MV3): `declarativeNetRequest` API blockiert Requests bevor sie das Netzwerk erreichen.
|
||
|
||
Chrome MV3 Limits:
|
||
- Static Rules (in Extension Bundle): bis zu 330.000 Regeln via mehrere `rule_resources`-Rulesets (jedes bis zu 30.000 Regeln, 11 Rulesets möglich)
|
||
- Dynamic Rules (laufzeit-änderbar): 5.000 (Issue bei w3c/webextensions #319 für Erhöhung auf 30.000 ist offen, Stand Mai 2026 noch nicht merged)
|
||
- 208k Domains als static ruleset: realisierbar mit ~7 Rulesets à 30k Regeln
|
||
|
||
Limitierung:
|
||
- Browser-Extension blockiert nur Browser-Traffic. Native Apps (Casino-Apps, andere Browser) sind nicht betroffen.
|
||
- Kein HTTPS-Inspection nötig für Domain-Blocking (anders als Port-based Blocking)
|
||
- User kann Extension deaktivieren (kein Self-Binding-Enforcement wie bei iOS)
|
||
|
||
**Cross-Browser-Status:**
|
||
- Chrome/Chromium: MV3 vollständig, declarativeNetRequest stabil
|
||
- Firefox: MV3 Support seit Firefox 127 (Mai 2024), declarativeNetRequest verfügbar aber mit leicht anderen Limits
|
||
- Safari: Web Extensions seit Safari 14 (MV2 + einige MV3 Features). declarativeNetRequest in Safari 16.4+. Webkit Content Blocker (separates Format, bis 150k Regeln) ist eine Safari-Alternative.
|
||
|
||
**Effort-Schätzung:**
|
||
- Woche 1: Extension-Scaffolding (Manifest V3, background service worker, popup UI)
|
||
- Woche 2: declarativeNetRequest ruleset generation aus der bestehenden 208k-Domain JSON-Blocklist
|
||
- Woche 3: Auth-Integration (Popup login via Supabase, JWT-Sync), Account-check ob aktiv
|
||
- Woche 4: Safari-spezifisches Xcode-Wrapping (Safari Web Extensions brauchen ein macOS/iOS App-Bundle), Notarization
|
||
- Woche 5: Testing Chrome + Firefox + Safari, Edge-Cases (subdomain handling, www-prefix)
|
||
|
||
3–5 Wochen für einen ersten funktionierenden Chrome + Firefox Build. Safari kostet 1–2 extra Wochen (Xcode-Packaging).
|
||
|
||
**Vorteile:**
|
||
- Läuft auf Windows und Linux ebenfalls (ohne Mehraufwand)
|
||
- Kein Apple-Entitlement-Antrag nötig
|
||
- Extension Store Distribution: Chrome Web Store + Firefox Add-ons sind einfach
|
||
- Safari über App Store Distribution möglich (aber kein Pflicht, Sideloading geht auch)
|
||
|
||
**Nachteile:**
|
||
- Kein Bypass-Schutz: User kann die Extension deaktivieren
|
||
- Kein App-Blocking (Native Casino-Apps auf macOS sind nicht betroffen)
|
||
- Kein Awareness-Feature (Streak, SOS-Chat) integrierbar ohne Login-Popup
|
||
- Blocklist-Updates: müssen als Extension-Update gepusht werden (oder dynamisch via API mit dem 5k-Limit, was für 208k nicht ausreicht — static rulesets bleiben Pflicht)
|
||
|
||
---
|
||
|
||
### Pfad 5: Persönliches MDM-Profil (Web Content Filter Payload)
|
||
|
||
Apple Configuration Profile mit `WebContentFilter`-Payload:
|
||
- Filtert DNS-Requests oder URLs via Supervised-Device-Mechanism
|
||
- Für einzelnes Device: `.mobileconfig`-Datei installieren in Systemeinstellungen > Allgemein > VPN und Geräteverwaltung
|
||
- kein Produktfeature — nur für Chahine selbst, nicht für andere ReBreak-User deploybar (außer man baut eine MDM-Infrastruktur, was Scope-mäßig Pfad 3 übersteigt)
|
||
- SelfControl-Alternative: kostenlos, Open-Source, kein Dev-Aufwand, läuft heute
|
||
|
||
**Für Chahine persönlich:** SelfControl (selfcontrolapp.com) macht genau das, ohne ein einziges Line Code zu schreiben. Blocklist importieren, Timer setzen.
|
||
|
||
---
|
||
|
||
## 4. Empfehlung
|
||
|
||
**Heute (wenn Luft da ist): Pfad 4 — Browser-Extension**
|
||
Niedrigster Aufwand, sofortiger Mehrwert für alle ReBreak-User (nicht nur macOS). Blocking für Browser-Traffic (Hauptweg ins Online-Casino) funktioniert. Kein Apple-Entitlement nötig. Chrome + Firefox in 3–4 Wochen machbar. Safari kommt als +1-Woche-Add-on über Xcode-Wrapper.
|
||
|
||
**Bei ARR > 50k EUR oder DiGA-Zulassung: Pfad 3 — Native Swift Mac-App**
|
||
Erst dann rechtfertigt sich der Aufwand für echtes System-Level-Blocking. Greenfield-Build, NEDNSProxyProvider als Blocking-Engine, SwiftUI-UI wiederverwendend keine iOS-RN-Komponenten. Backend-API vollständig wiederverwendbar.
|
||
|
||
**Pfad 1 und 2: nicht verfolgen.**
|
||
Beide kaufen nur UI-Portierung, lösen aber das Kern-Feature (Blocking) nicht. Der Aufwand für Pfad 2 übersteigt Pfad 3 bei gleichzeitig schlechterem Ergebnis.
|
||
|
||
**Pfad 5 (MDM): für Chahine persönlich sofort** — SelfControl installieren, Blocklist aus ReBreak JSON importieren. Kein Dev-Aufwand.
|
||
|
||
---
|
||
|
||
## 5. Offene Fragen (ungeprüft / hypothetisch markiert)
|
||
|
||
- **Hypothese, ungeprüft:** `com.apple.developer.network-extension.content-filter` Entitlement — wie lange dauert Apples Review-Prozess aktuell? Apple-Forum-Posts aus 2023 beschreiben 2–4 Wochen. Stand 2026 unbekannt.
|
||
- **Hypothese, ungeprüft:** react-native-reanimated läuft nicht auf RN macOS. Keine Issues gefunden, aber auch kein positiver Hinweis. Wäre durch Testbuild verifizierbar.
|
||
- **Hypothese, ungeprüft:** Safari declarativeNetRequest mit 208k static rules ist performant genug. WebKit's Content Blocker (alternatives Format) wäre eine Safari-native Alternative ohne diese Unsicherheit.
|
||
- **Offen:** Firefox MV3 Static-Ruleset-Limits — 330k-Limit ist Chrome-spezifisch. Firefox-Limits bei mehreren rule_resources nicht abschließend recherchiert.
|
||
|
||
---
|
||
|
||
## 6. Quellen
|
||
|
||
- react-native-macos Repo: https://github.com/microsoft/react-native-macos
|
||
- react-native-macos releases: v0.81.2 (2026-02-11)
|
||
- react-native-bottom-tabs macOS support: https://github.com/callstack/react-native-bottom-tabs (README, Platform-Tabelle)
|
||
- async-storage Catalyst Issue #1268 (open, März 2026): https://github.com/react-native-async-storage/async-storage/issues/1268
|
||
- w3c/webextensions Issue #319 (dynamic rules limit, open): https://github.com/w3c/webextensions/issues/319
|
||
- SelfControl macOS app (BlockManager + PacketFilter approach): https://github.com/SelfControlApp/selfcontrol
|
||
- Apple Network Extension Programming Guide: https://developer.apple.com/documentation/networkextension
|
||
- Apple FamilyControls (iOS/iPadOS only): https://developer.apple.com/documentation/familycontrols
|
||
- react-native-mmkv platform support (iOS/Android/Web): https://github.com/mrousavy/react-native-mmkv
|
||
- rive-react-native platform support (iOS/Android): https://github.com/rive-app/rive-react-native
|
||
- Chrome declarativeNetRequest (static rulesets, 330k total limit): https://developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest
|
||
- Safari Web Extensions: https://developer.apple.com/documentation/safariservices/safari-web-extensions
|