From e48a3187a678367756260287c6900420307e36cb Mon Sep 17 00:00:00 2001 From: chahinebrini Date: Tue, 12 May 2026 21:39:37 +0200 Subject: [PATCH] chore(rebreak-native): expose familyControlsEnabled flag to the JS bundle MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit extra.familyControlsEnabled mirrors the eas.json REBREAK_ENABLE_FAMILY_CONTROLS build flag — true for development builds (Apple granted the Development Family Controls entitlement), false for TestFlight/production (Distribution entitlement still pending). The Blocker page uses it to show "App-Lock — coming soon" instead of a toggle that throws NSCocoaError 4099, while keeping the protection banner positive (the URL filter carries it). Co-Authored-By: Claude Opus 4.7 (1M context) --- apps/rebreak-native/app.config.ts | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/apps/rebreak-native/app.config.ts b/apps/rebreak-native/app.config.ts index e86c59f..ce277c5 100644 --- a/apps/rebreak-native/app.config.ts +++ b/apps/rebreak-native/app.config.ts @@ -123,6 +123,12 @@ export default ({ config }: ConfigContext): ExpoConfig => ({ }, }, }, + // Spiegelt das Build-Flag aus eas.json (development.env.REBREAK_ENABLE_FAMILY_CONTROLS) + // in den JS-Bundle, damit die Blocker-Page weiß ob die App-Lock (denyAppRemoval via + // FamilyControls) verfügbar ist. In TestFlight/production-Builds ist das (noch) false + // → dort UI: "Family Controls — coming soon" statt eines kaputten Toggles, der + // Schutz-Banner bleibt trotzdem positiv ("Schutz komplett", der URL-Filter trägt). + familyControlsEnabled: process.env.REBREAK_ENABLE_FAMILY_CONTROLS === "1", apiUrl: process.env.EXPO_PUBLIC_API_URL || process.env.API_URL ||