chahine/rebreak-monorepo
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
rebreak-monorepo/ops/mac-version-research.md
chahinebrini 5d6c322129 wip: KeyboardAwareSheet migrations + Snake/Tetris UI + iron.png + useMe live-update 
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>
2026-05-10 23:59:25 +02:00

17 KiB
Raw Blame History

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