18.1.x dynamic XCFrameworks (arm64 + arm64e) fail to load on iOS 17/18 after App Store update: "could not register fairplay decryption, mremap_encrypted() => -1"

Checklist before submitting a bug report

I've updated to the latest released version of the SDK
I've searched for existing GitHub issues
I've looked for existing answers on Stack Overflow, the Facebook Developer Community Forum and the Facebook Developers Group
I've read the Code of Conduct
This issue is not security related and can safely be disclosed publicly on GitHub

Xcode version

26.2 (17C52)

Facebook iOS SDK version

18.1.1

Dependency Manager

SPM

SDK Framework

Core

Goals

Update from facebook-ios-sdk 18.0.1 to 18.1.1 without breaking app launch for users on iOS versions below 26.

Expected results

The app launches normally after the App Store update on every supported iOS version (our deployment target is iOS 16.0).

Actual results

After shipping 18.1.1, users on iOS 17.6 – 18.7 (iPhone 12, iPhone 14 Pro, iPhone 16 observed) crash at launch before any app code runs. dyld cannot load FBSDKCoreKit:

Termination Reason: DYLD 1 Library missing
Library not loaded: @rpath/FBSDKCoreKit.framework/FBSDKCoreKit
Referenced from: <2FC56459-...> /Volumes/VOLUME/*/heymoon.app/heymoon
Reason: tried: '/usr/lib/swift/FBSDKCoreKit.framework/FBSDKCoreKit' (no such file, not in dyld cache),
'/private/preboot/Cryptexes/OS/usr/lib/swift/FBSDKCoreKit.framework/FBSDKCoreKit' (no such file),
'/private/var/containers/Bundle/Application/.../heymoon.app/Frameworks/FBSDKCoreKit.framework/FBSDKCoreKit'
(could not register fairplay decryption, mremap_encrypted() => -1)

Because the process dies inside dyld, no crash reporter (Crashlytics/Sentry/Datadog) captures it; we found it via Xcode Organizer and .ips files from affected devices.

Conditions that we confirmed:

Only when the app is installed via an App Store update from a version that shipped 18.0.1. Fresh installs, delete-and-reinstall, and TestFlight installs (including TestFlight updates) work fine with the exact same binary. Affected users are fixed by deleting and reinstalling.
Only on iOS < 26. Users on iOS 26.x/27 load the same framework without problems.
Nothing else about the Facebook integration changed between the two releases.

The difference between the two SDK versions is the architecture layout of the dynamic XCFrameworks:

18.0.1 FBSDKCoreKit.xcframework/ios-arm64 -> arm64
18.1.0 FBSDKCoreKit.xcframework/ios-arm64_arm64e -> arm64 arm64e
18.1.1 FBSDKCoreKit.xcframework/ios-arm64_arm64e -> arm64 arm64e

(same for FBSDKCoreKit_Basics and FBAEMKit; checked with lipo -archs on the release zips.)

So starting with 18.1.0 the embedded frameworks are fat arm64+arm64e binaries. When the App Store applies FairPlay encryption and delivers the update, dyld on iOS 17/18 fails to register decryption for these fat frameworks. This is the same failure mode other SDKs avoid by publishing arm64e builds as a separate variant (e.g. sentry-cocoa ships Sentry-Dynamic and Sentry-Dynamic-WithARM64e separately). Related: #2626 (arm64e build support request).

Workaround: pin facebook-ios-sdk back to 18.0.1. Stripping arm64e from the embedded frameworks in a build phase should also work.

Request: please ship the default dynamic XCFrameworks as arm64-only again and offer the arm64e slice as an opt-in variant, or document that 18.1.x requires stripping arm64e for apps that support iOS < 26.

Steps to reproduce

App with deployment target iOS 16.0, facebook-ios-sdk 18.0.1 via SPM (FacebookCore), released on the App Store.
Update the dependency to 18.1.1, submit to the App Store, release.
On an iPhone running iOS 17.x or 18.x that already has the 18.0.1 build installed, update the app from the App Store and launch it.
The app terminates in dyld with the "could not register fairplay decryption" reason above.

Note: this does not reproduce via Xcode, TestFlight, or a fresh App Store install. It only reproduces through the App Store update path, so it is very hard to catch before release.

Code samples & details

Package pin (Xcode project):
  https://github.com/facebook/facebook-ios-sdk  exactVersion 18.1.1  (products: FacebookCore)

Embedded framework layout from the 18.1.1 zips:
  FBSDKCoreKit        ios-arm64_arm64e  minos 12.0  sdk 26.5  (DTXcode 2660)
  FBSDKCoreKit_Basics ios-arm64_arm64e  minos 12.0  sdk 26.5
  FBAEMKit            ios-arm64_arm64e  minos 12.0  sdk 26.5

Affected devices/OS from crash reports:
  iPhone13,2 (iPhone 12)      iOS 17.6.1
  iPhone15,2 (iPhone 14 Pro)  iOS 17.6.1, 18.3.2
  iPhone17,3 (iPhone 16)      iOS 18.1.1, 18.3.2, 18.7.8

Thanks for the valuable information. We’ve confirmed the same behavior in our environment: the issue only occurs with the App Store build and cannot be reproduced via TestFlight.

It also doesn’t appear in Crashlytics and is only visible in Xcode Organizer. We’ve also confirmed that downgrading to 18.0.1 resolves the issue.

Confirming this on a Flutter app (com.denga, App Store) with a larger sample than the reports so far, plus one detail I have not seen posted yet: there is a hard iOS-version gate.

Scale: 133 unique devices in Xcode Organizer, all non-beta, all iPhone. Two affected builds, both shipping facebook-ios-sdk 18.1.0:

build	devices
6.9.0 (584)	119
6.10.0 (586)	106

iOS version distribution of the affected population:

iOS 18.7 -> 95     iOS 18.2 -> 2
iOS 18.3 -> 10     iOS 18.1 -> 2
iOS 18.5 ->  9     iOS 17.5 -> 2
iOS 18.6 ->  8     iOS 18.0 -> 1
iOS 17.6 ->  3     iOS 17.7 -> 1
                   iOS 16.0 -> 1
                   iOS 16.2 -> 1

Zero on iOS 26 or 27. For context, ~86% of our sessions on the same build run iOS 26+, and not one of them is affected. The failure is confined entirely to iOS <= 18.

Reinstalling is not a durable fix. Five crash reports collected in a single morning are all on the latest build 6.10.0 (586), all iPhone XR, on iOS 18.3.2 / 18.7.3 / 18.7.9, across four distinct bundle UUIDs. While the binary still ships arm64e, delete-and-reinstall only re-rolls the dice.

Only the fat binaries fail, and it is not simply "the first embedded framework". Our bundle embeds 24 frameworks. FBSDKCoreKit, FBAEMKit and FBSDKCoreKit_Basics are the only three that are arm64 arm64e; the other 21 are arm64 only, as is the main executable. On the crashing device, dyld loads three arm64-only frameworks first and registers FairPlay decryption for each of them successfully, then aborts on FBSDKCoreKit — the first fat one it reaches. So three framework-level FairPlay registrations succeed on the same device, in the same launch, immediately before the failure.

Size and alignment do not discriminate either: the main executable's crypt region is 21.6 MB and decrypts fine, versus 1.6 MB for FBSDKCoreKit, and every framework in the bundle has cryptoff 16384 with 16 KB-aligned segments.

We have pinned facebook-ios-sdk to 18.0.3 (arm64-only) as a workaround.

Strongly agree with the request in the original report. Shipping arm64e as a separate variant — the way sentry-cocoa does with Sentry-Dynamic vs Sentry-Dynamic-WithARM64e — would avoid this for every app still supporting iOS <= 18.

One note for anyone searching for this: it is invisible to Crashlytics, because dyld aborts before Firebase initializes. It only appears in Xcode Organizer, which is why it can run for weeks before anyone notices.

We’re seeing this across three different apps using Facebook SDK 18.1.0, with the same could not register fairplay decryption, mremap_encrypted() => -1 launch failure.

The Facebook SDK version stayed the same between older and affected releases. Comparing their App Store IPAs, we found:

DTAppStoreToolsBuild changed from 17F106 to 27A261.
Older packages contain arm64-only Facebook frameworks; newer packages retain arm64 + arm64e.
This affects FBAEMKit, FBSDKCoreKit, FBSDKCoreKit_Basics and FBSDKLoginKit. All other embedded binaries remain arm64-only.
Xcode stayed unchanged within each comparison.

This points to an App Store processing change, with Apple starting to retain slices it previously stripped. Our inspected releases place the change between September 3 and September 10, 2026; the exact rollout date is unknown.

We’ve pinned one app to 18.0.3 as a workaround, pending confirmation through an App Store update.

The shared build settings append arm64e to ARCHS_STANDARD, so a normal device build always produces a fat arm64 and arm64e binary. Those extra slices are baked into the dynamic XCFrameworks that get embedded and FairPlay-encrypted, and dyld on iOS 17 and 18 cannot register decryption for that layout.

Common.xcconfig and FacebookSDK-Project.xcconfig now set ARCHS to $(ARCHS_STANDARD) only, which keeps a default device build at arm64.

#4012

Same here

Navigation Menu

Repository navigation

18.1.x dynamic XCFrameworks (arm64 + arm64e) fail to load on iOS 17/18 after App Store update: "could not register fairplay decryption, mremap_encrypted() => -1" #3997

Checklist before submitting a bug report

Xcode version

Facebook iOS SDK version

Dependency Manager

SDK Framework

Goals

Expected results

Actual results

Steps to reproduce

Code samples & details

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

18.1.x dynamic XCFrameworks (arm64 + arm64e) fail to load on iOS 17/18 after App Store update: "could not register fairplay decryption, mremap_encrypted() => -1" #3997

Description

Checklist before submitting a bug report

Xcode version

Facebook iOS SDK version

Dependency Manager

SDK Framework

Goals

Expected results

Actual results

Steps to reproduce

Code samples & details

Activity

shimastripe commented on Sep 19, 2026

luanbatistadenga commented on Sep 24, 2026

petermnt commented on Oct 16, 2026

mvanhorn commented on Oct 20, 2026

alex-pan-invos commented on Oct 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions