App launches fail after App Store update: dyld "could not register fairplay decryption, mremap_encrypted() => -1" on the first embedded framework; reinstall fixes it (FB24755993)

Since our 1.3.20 update reached users on Sept 11, 2026, a handful of devices terminate at launch right after the App Store auto-update. Restarting the device does not help; deleting the app and reinstalling it from the App Store does. Filed as FB24755993 with 9 crash reports, the delivered package's SC_Info/Manifest.plist and a per-binary fingerprint.

What the crash reports say (all identical)

Exception Type:  EXC_CRASH (SIGABRT)
Termination:     namespace DYLD, code 1, "Library missing"
                 (terminated at launch; ignore backtrace)
Library not loaded: @rpath/FBSDKCoreKit.framework/FBSDKCoreKit
Referenced from: <DDB434B7-...> /Volumes/VOLUME/*/Runner.app/Runner
Reason: tried: '/private/var/containers/Bundle/Application/<UUID>/Runner.app/Frameworks/FBSDKCoreKit.framework/FBSDKCoreKit'
        (could not register fairplay decryption, mremap_encrypted() => -1)
Backtrace: dyld4::prepare -> dyld4::halt -> abort_with_payload

Devices so far: iPhone XR / iOS 18.7.10 (22H374), iPhone 16 / iOS 26.6, iPhone 16 / iOS 18.7.7, plus one more not yet identified. The same package launches normally on the large majority of the ~12,000 devices that updated that day. Delivered Info.plist: DTAppStoreToolsBuild 27A261, DTXcodeBuild 17F113, MinimumOSVersion 15.0.

What we established

• The main executable decrypts fine (dyld reaches dyld4::prepare); the failure is on the first @rpath framework in the load order, which is also the first FairPlay-encrypted embedded binary. It is not specific to the Facebook SDK.
• The package Apple delivers (pulled with Apple Configurator) is structurally consistent: every binary with LC_ENCRYPTION_INFO_64 has cryptid 1 and SC_Info/<name>.supp/.supf/.supx/.v4.supp/.v5.supf (main executable, App, Flutter, FBSDKCoreKit, FBAEMKit, FBSDKCoreKit_Basics, objective_c, sqlite3, the widget appex); the Firebase/Google frameworks are cryptid 0. SC_Info/Manifest.plist has SinfPaths = [SC_Info/Runner.sinf] and SinfReplicationPaths for all 12 binaries.
• Only the main Runner.sinf ships; the framework-level .sinf files have to be produced at install time from SinfReplicationPaths. The symptom looks like that replication not being applied to the frameworks after the delta update on the affected devices, while a fresh full install performs it.
• Nothing in our bundle changed between 1.3.19 and 1.3.20 except Dart code (App.framework): same Xcode 26.6 (17F113), same Flutter engine, byte-identical Facebook SDK 18.1.1 binaries (the only fat arm64+arm64e binaries in the bundle), same Firebase SDK. Both versions run normally from TestFlight and Xcode.
• The 1.3.20 encrypted variant carries SC_Info timestamps about 18 h after Ready for Sale, coinciding with the start of the auto-update wave. We could not obtain the delivered 1.3.19 package for comparison.

Questions

1. Has anyone seen this class of failure since early September, or with packages processed by DTAppStoreToolsBuild 27A261?
2. Is there anything about a bundle (fat arm64+arm64e embedded frameworks? many encrypted frameworks?) that makes the framework .sinf replication on the delta-update path fragile?
3. Is there any developer-side mitigation other than telling users to delete and reinstall?

The closest earlier report I found is thread 718950 (2022, iOS 15.7–16.1, ~1 in 200 installs, "reinstall fixes it"); this looks like the same failure but concentrated on one update.