iTranslated by AI
[iOS] Why Release xcframeworks are larger than Debug versions
This article is for the 25th day of the [iOS Advent Calendar 2025].
Introduction
While checking the build artifacts of an SDK, I noticed the following phenomenon.
| Platform | Debug Version | Release Version |
|---|---|---|
| Android | 2.0 MB | 1.5 MB |
| iOS | 5.0 MB | 10.0 MB |
*Note: Sizes are examples.
While Android is Debug > Release, iOS is Release > Debug.
Is this normal behavior? I have summarized the results of my investigation below.
Conclusion
It is normal behavior.
The reason the Release version is larger in iOS is due to Xcode's Build Active Architecture Only setting.
What is Build Active Architecture Only?
This setting determines whether to limit the build target to only the "current development environment."
Setting it to YES makes it faster and smaller, while NO makes it slower and larger.
Where to find the setting
You can check it in Xcode by following these steps:
- Select the project or target.
- Open the Build Settings tab.
- Search for "architecture" and check Build Active Architecture Only.
Default Settings
| Setting | Debug (Default) | Release (Default) |
|---|---|---|
| Build Active Architecture Only | YES | NO |
| Architectures built | Only one | All |
| File size | Smaller | Larger |
Meaning of the settings
-
YES: Builds only one architecture for the device/simulator currently connected.
- To reduce build time.
-
NO: Builds all architectures for distribution.
- To ensure it runs in any environment.
Reference sites:
View original text
By default in Debug mode Build Active Architecture Only value is YES.
What this mean that Xcode will build the architecture which is specified in the target.
For Release mode, the default value will be NO.
When we specify the value for Build Active Architecture Only as NO, Xcode will build all the architectures which are specified under Valid Architectures.
In debug mode, the default value for "Build Active Architecture Only" is YES.
This means Xcode will build only the architecture specified for the target.
In release mode, the default value is NO.
Setting the value of "Build Active Architecture Only" to NO causes Xcode to build all the architectures specified under "Valid Architectures."
Why the Release Version is Larger
In the Release version (Build Active Architecture Only = NO), the following architectures are included:
MySDK.xcframework/
├── ios-arm64/ ← For physical devices (arm64)
└── ios-arm64_x86_64-simulator/ ← For simulators (arm64 + x86_64)
The reason why two architectures are included for the simulator:
| Mac Type | CPU | Required Architecture |
|---|---|---|
| Intel Mac | x86_64 | x86_64 |
| Apple Silicon Mac (M1/M2/M3) | arm64 | arm64 |
The Release version includes both so that development can be done on either type of Mac.
Reference sites:
View original text
Simulators (x86_64 or arm64): Simulators running on Intel-based Macs (before the M1 transition) use x86_64architecture.
However, if you’re using a Mac with Apple Silicon (M1, M2, etc.), the simulator uses the arm64architecture, just like real devices.
When creating an XCFramework, you need to bundle versions of the framework for both device (arm64) and simulator (x86_64 and/or arm64) architectures
Why different architectures are needed for XCFrameworks
Physical devices (arm64): Since iOS devices such as iPhones and iPads use ARM-based processors, the framework must be compiled for the arm64 architecture to run natively on these devices.
Simulators (x86_64 or arm64): Simulators running on Intel-based Macs (before the M1 transition) use the x86_64 architecture.
However, if you are using a Mac with Apple Silicon (M1, M2, etc.), the simulator uses the arm64 architecture, just like physical devices.
When creating an XCFramework, you need to bundle versions of the framework for both device (arm64) and simulator (x86_64 and/or arm64) architectures.
How to Check Architectures
By looking at the folder structure of the xcframework, you can see which architectures are included.
From the folder names, you can see that two architectures, arm64 and x86_64, are included for the simulator.
Diagram
I found that the difference between the Debug and Release versions is the number of architectures included in the simulator binary.
[Debug Version (Build Active Architecture Only = YES)]
┌─────────────────────────────────────────────┐
│ ios-arm64/ → arm64 │ ← For physical device
│ ios-arm64_x86_64-simulator/ → arm64 only │ ← Only one matching current Mac
└─────────────────────────────────────────────┘
Total: approx. 5.0MB
[Release Version (Build Active Architecture Only = NO)]
┌─────────────────────────────────────────────┐
│ ios-arm64/ → arm64 │ ← For physical device
│ ios-arm64_x86_64-simulator/ │
│ ├ arm64 ← For Apple Silicon Mac │
│ └ x86_64 ← For Intel Mac │
└─────────────────────────────────────────────┘
Total: approx. 10.0MB (Simulator part is approx. 2x larger)
Differences Between Android and iOS
Why is it the opposite (Debug > Release) for Android?
Android: Why the Debug Version is Larger
The Debug version is larger because it contains debugging information:
- Debug symbols (variable names, line numbers, etc.)
- Logging code
- Unused code
In the Release version, these are removed or compressed (via ProGuard/R8), making it smaller.
iOS: Why the Release Version is Larger
The Release version is larger because it includes all architectures for distribution:
- Debug version: Only 1 architecture
- Release version: arm64 + x86_64 (for simulator)
| Factor | Android | iOS |
|---|---|---|
| Main factor affecting size | Presence of debug info | Number of architectures |
| Debug Version | Contains debug info → Large | 1 architecture → Small |
| Release Version | Optimization/Compression → Small | All architectures → Large |
Android reference:
Debug APKs are larger because they include symbols and logs.
Summary
- It is normal for the Release version to be larger than the Debug version in iOS.
- The cause is the
Build Active Architecture Onlysetting (Debug=YES, Release=NO). - The Release version includes multiple architectures to support both Intel Macs and Apple Silicon Macs.
Discussion