Although I couldn’t find direct meantion of it in documentation or during presentations everything points into that direction.

XCFramework

XCFramework is only way to support Mac Catalyst since Fat Framework don’t contain multiple x86 slices, but since Catalyst is something new and only fraction of apps supports it isn’t priority to support - for example Carthage request for Catalyst support is opened since June 2019.

Then Swift 5.3 brings binary dependencies capability to SPM and those can only be XCFrameworks. But again - not everyone uses SPM and one could stick to Framework till this point. But things have changed when Apple Silicone Macs were introduced last month.

Status quo

Since the first iPhoneOS SDK when we were building for a real device we used iphoneos sdk and ARM architecture, when we select a simulator we would use iphonesimulator sdk and x86 architecture. Then we could use lipo to combine them into Fat Framework that would work with both device and simulator. This is how Carthage works and most precompiled frameworks are distributed.

To illustrate - we have:

• ARM ↔️ iphoneos
• x86 ↔️ iphonesimulator

This is where Apple Silicone break this order adding third pair:

• ARM ↔️ iphonesimulator

Xcode 12

One thing changed in Xcode 12, one that is not clearly visible and many developers was surprised to discover.

Did anyone encounter/found a fix for the issue where you build for Catalyst in Xcode 12.2 and Xcode just MUST build an arm64 version, ignoring the "build active architecture only” setting? I can work around by always building all archs, but dang it so slow. pic.twitter.com/tjnSzNinxa

— Peter Steinberger (@steipete) November 5, 2020

Let’s build a Framework target for simulator and investigate it:

lipo -archs  Sample.framework/Sample
x86_64 arm64

By default Xcode will build for both ARM and x86. This new behavior will break Carthage that uses lipo under the hood to produce Fat Framework.

$lipo -create iphoneos/Sample.framework/Sample iphonesimulator/Sample.framework/Sample 

fatal error: Sample.framework/Sample have the same architectures (arm64) and can't be in the same fat output file

Fortunatly there is document describing how to exclude ARM architecture from building and basically restore how it worked in Xcode 11. Of course that will only work on Intel Macs, Apple Silicone users should wait for XCFramework support to land.

Wrap up

If you distribute framework for other developers - please provide them with proper XCFramework with ARM simulator version so they can use simulator on there new Macs. I wish Apple would clearly state the need for migration to XCFrameworks so it would be done sooner - not when developers would start having compilation errors.

When XCFrameworks was introduced in last years WWDC I was really excited:

"XCFrameworks make it possible to bundle a binary framework or library for multiple platforms —including iOS devices, iOS simulators, and UIKit for Mac — into a single distributable .xcframework bundle that your developers can use within their own applications." 😲

— Kamil Pyć (@KamilPyc) June 3, 2019

I would like to share my experience with it and what roadblocks you can hit trying to replace Frameworks with XCFrameworks in you project.

Note: all of code and examples was run on Xcode 11.4.1. using Swift 5.2.

Creating XCFrameworks

Lets start from the begining - how to create XCFramework. With Frameworks that just a normal target workflow as you may know from creating app or test targets. Just select “New…” and pick Framework as target.

I would expect that from this point one can select which architectures to include and then export .xcframework. But it doesn’t work this way.

In order to produce xcframework we need to export all of the frameworks and then combine them with -create-xcframework command.

 xcodebuild -create-xcframework \
            -framework ${FRAMEWORK_SIMULATOR_DIR}/${1}.framework \
            -framework ${FRAMEWORK_DEVICE_DIR}/${1}.framework \
            -framework ${FRAMEWORK_MAC_DIR}/${1}.framework \
            -output ${OUTPUT_DIR_PATH}/xcframeworks/${1}.xcframework

You can check out full create script on Github created by Boris Bielik - it’s over 100 lines of code. Update: Boris created convinient Fastlane plugin that wraps this boilerplate up nicely.

I think that this over complication can be one of the reasons why XCFrameworks are still not supported by Carthage.

Xcode

On a first glance usage isn’t different than how we work with standard frameworks. Just add it to target’s “Frameworks and Libraries” section in general tab.

After building app in build log we can find out that XCFrameworks get different treatment than Frameworks.

There is a special ProcessXCFrameworkLibrary step that’s extracts correct .framework from all architectures contained in xcframework bundle based on target architecture.

ProcessXCFrameworkLibrary PromisesObjC.xcframework/ios-i386_x86_64-simulator/PromisesObjC.framework /Users/kamilpyc/Library/Developer/Xcode/DerivedData/NotchIt-axosvlxgvlvyerffinztzmvrhkfp/Build/Products/Debug-iphonesimulator/PromisesObjC.framework (in target 'TargetB' from project 'NotchIt')

Because of that Xcode need to have explicit list of xcframeworks to process and FRAMEWORK_SEARCH_PATHS does not work. Xcode wants to optimise the usage of ProcessXCFrameworkLibrary and ther is only one call per single xcframework. That’s will make build to fail in pretty common usage case. Let’s say we have target ModelA.framework and ModelB.framework that links same ModelCore.xcframework. Xcode selects one of this targets to include the ProcessXCFrameworkLibrary step and if this selected target will start after another target utilising same xcframework build will simply fail with Framework not found ModelCore. I took me some time to figure out this race going on when my builds fails randomly 50% of time.

WWDC2020 update: Xcode 12 fixes the race condition bug:

Fixed a race condition where multiple targets using the same XCFramework could result in non-deterministic build failures.
	

Swift

In order to produce Swift libary that’s support module stability, frameworks needs to be created with BUILD_LIBRARY_FOR_DISTRIBUTION turned on:

xcodebuild archive \
    -workspace XCFrameworks.xcworkspace \
    -scheme ${1} \
    -destination "${2}" \
    -archivePath "${3}" \
    SKIP_INSTALL=NO \
    BUILD_LIBRARY_FOR_DISTRIBUTION=YES

Under the hood this will pass -enable-library-evolution flag to Swift Compiler. That have couple of implications:

• Code is compiled differently. When I tried to replace Apollo framework with precompiled xcframework version app started crashing with swift_getEnumCaseMultiPayload.cold.1
• If you have any enums you either have to mark them @frozen or handle default case on usage. Unfortunalty that make it impossible to simply replace xcframework with .framework in case any code needs to be debugged or profiled.
• Generated .swiftinterface file is corrupted. This was is already reported but not solved, so you cannot build SwiftyJSON or RxSwift as xcframework.

Wrap up

In summary, there are few things that can block developers from using XCFrameworks expecially with Swift projects. That could explain why they are not widely popular on iOS. We are one month ahead of WWDC and I hope those get issues got resolved, because XCFrameworks are great step ahead of Framework.

I have mixed filling - right now SwifUI is great way to describe a layout, view hierachy and state managment. But if you need to do even a simple platfrom specific thing - let’s say to change windows title - there is no simple way. Things like navigationBarItems are tided to UIKit only plaftorm so that would force to switch to Mac Catalyst.

I’m eagier to find out what WWDC 2020 will bring - death of AppKit or more complex SwiftUI integration.

Anyway I was able to create simple tool to inspect frameworks to check it’s type and architecure. You can check it out in Github.

array=()

while element
do
array+= element
done

In every case array was always empty. What? 🤨 Turnes out while loop is executed in different subshell and don’t have access to variable outside of it scope.

Solution: Switch to for loop.

Check out the Jekyll docs for more info on how to get the most out of Jekyll.