Bug: die RebreakPacketTunnelExtension.appex wurde nach
ReBreak.app/Extensions/ statt PlugIns/ embedded → Install-Crash
AppexBundleMissingEXAppExtensionAttributesDict (klassische NSExtension
im ExtensionKit-Ordner).
Ursache (verifiziert gegen node_modules/xcode + E2E-Lauf der Plugin-Kette):
withXcodeProject-Mods laufen LIFO — withPacketTunnelTarget zuerst,
withExtensionTarget (NEURLFilter) danach. proj.addTarget() bettet die
.appex über buildPhaseObject() ein, das projektweit die erste
PBXCopyFilesBuildPhase mit Section-Comment "Copy Files" matcht. Der
NEURLFilter-Umbau ändert nur phase.name/dstSubfolderSpec, nicht den
Section-Comment → die PacketTunnel-.appex landet in der dst-16-Phase
des NEURLFilter-Targets.
Fix in withPacketTunnelTarget: die .appex aus allen Copy-Files-Phasen
herausziehen, exklusiv in die eigene dst-13-Phase legen UND deren
Section-Comment auf "Embed App Extensions" umbenennen — damit der
nachfolgende NEURLFilter-addTarget-Lookup die Phase nicht mehr matcht.
NEURLFilter-Code unangetastet (dessen Umbau matcht per .appex-Dateiname).
Verifiziert: frisches Projekt, vorhandenes URLFilter-Target, Idempotenz.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Neuer iOS-Layer-1-Filter: ein NEPacketTunnelProvider-DNS-Sinkhole — MDM-frei,
ab iOS 16, Parität zum Android-VPN-DNS-Filter. Ersetzt den Apple-seitig
blockierten NEURLFilter als Default. NEURLFilter-/PIR-Code bleibt inaktiv als
iOS-26-Upgrade-Pfad erhalten (User-Entscheidung).
Neues Extension-Target RebreakPacketTunnelExtension/:
- PacketTunnelProvider.swift — TUN-Setup (virtuelle DNS-IP 10.0.0.1, nur diese
Route ins TUN), Read-Loop, NXDOMAIN-Sinkhole, Upstream-Forward via
NWConnection zu 1.1.1.1, Blocklist-Reload via Darwin-Notification.
- DnsFilter.swift / HashList.swift / DomainHasher.swift — Swift-Ports der
Android-DNS-Filter-Logik. blocklist.bin-Format (sortierte big-endian UInt64,
SHA-256-Prefix) 1:1 beibehalten, mmap statt Heap-Load.
RebreakProtectionModule.swift:
- activateUrlFilter startet jetzt den Packet-Tunnel via NETunnelProviderManager
(Default-Layer-1, On-Demand-Auto-Reconnect aktiv).
- NEURLFilter-Code in activateNeUrlFilter ausgelagert (inaktiv, behalten).
- getDeviceState/disable lesen bzw. stoppen den Tunnel-Status.
with-rebreak-protection-ios.js: zweites app_extension-Target, klassischer
Embed-Pfad (dstSubfolderSpec 13), packet-tunnel-provider-Entitlement + App-Group.
app.config.ts: zweites appExtensions-Target.
NICHT auf echtem Gerät verifiziert — NE-Packet-Tunnel laufen nicht im
Simulator. Ungetestete Annahmen im Code mit "UNGETESTETE ANNAHME" markiert.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- familyControlsEnabled jetzt default-on (Apple-Distribution-Entitlement
freigegeben); nur REBREAK_ENABLE_FAMILY_CONTROLS=0 schaltet ab.
- gambling-domains.json ins Pod-Verzeichnis verschoben + Podspec resource_bundles
auf within-pod-Pfad korrigiert — CocoaPods buendelt keine Dateien ausserhalb
des Pod-Roots (Bundle blieb sonst leer → Layer 2 griff nicht).
- Layer 2 (webContent-Filter) damit verifiziert funktionierend.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
It was commented out wholesale in 398b7b9 so the App-Store/TestFlight provisioning
profile would build (Apple hasn't granted the *Distribution* Family Controls
entitlement yet). But that also killed it for the dev-client, so denyAppRemoval /
ManagedSettings throws "NSCocoaErrorDomain:4099 — can't talk to the helper app"
when you flip the Blocker-page App-Lock.
Gate it on REBREAK_ENABLE_FAMILY_CONTROLS, set to "1" in eas.json's development
profile (internal distribution → Development entitlement, which we do have). The
preview/production profiles stay without it until Apple approves the Distribution
entitlement — then add the flag there too + bump buildNumber.
NOTE: the next `eas build -p ios --profile development` will re-provision the main
app profile to include the entitlement; if Apple turns out NOT to have granted the
*Development* one either, that build will fail the same way the TestFlight one did.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The EAS error message "Xcode 14 resource bundle signing" was a misleading wrapper.
Pulled the actual Xcode log via the EAS CLI; the real failures were:
error: Provisioning profile "...AppStore..." doesn't support the Family Controls
(Development) capability.
error: Provisioning profile ... doesn't include the com.apple.developer.family-controls
entitlement.
error: Signing for "RebreakURLFilter" requires a development team. (in target
'RebreakURLFilter' from project 'ReBreak')
Two fixes:
1. Family Controls is requested with Apple but not yet granted (Distribution), so
EAS can't generate an AppStore provisioning profile that includes it → comment
out the family-controls entitlement claim in withMainAppEntitlements. Re-enable
once Apple grants the entitlement. The iOS Swift code still imports
FamilyControls/ManagedSettings (public frameworks, link fine without the
entitlement); activateFamilyControls would throw at runtime — handled by the
JS layer's catch. Net: TestFlight build works, iOS App-Lock feature is dormant
until the entitlement lands.
2. The RebreakURLFilter extension target had no DEVELOPMENT_TEAM set — EAS managed
credentials only set it on the main app target; sub-targets don't inherit.
Hardcoded the team ID 84BQ7MTFYK on the extension's build configurations
(matches eas.json submit.production.ios.appleTeamId).
(The resource-bundle-signing fix from the previous attempt stays — it's
not the cause here but is correct hygiene for static-frameworks builds.)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
