How to export "fat" Cocoa Touch Framework (for Simulator and Device)?

Question

With Xcode 6 we get ability to create own Dynamic Cocoa Frameworks.

Because of:

• Simulator still use 32-bit library

• beginning June 1, 2015 app updates submitted to the App Store must include 64-bit support and be built with the iOS 8 SDK (developer.apple.com)

We have to make fat library to run project on devices and simulators. i.e. support both 32 and 64 bit in Frameworks.

But I didn't find any manuals, how to export universal fat Framework for future integration with other projects (and share this library with someone).

Here is my steps to reproduce:

1. Set ONLY_ACTIVE_ARCH=NO in the Build Settings

   

2. Add support armv7 armv7s arm64 i386 x86_64 to Architectures (for sure)

3. Build Framework and open it in Finder:

4. Add this framework to another project

Actual result:

But in the end I still have problem with running project with this framework on devices and simulator at once.

• if I take framework from Debug-iphoneos folder - it works on devices and gets error on simulators: ld: symbol(s) not found for architecture i386

    xcrun lipo -info CoreActionSheetPicker 

  Architectures in the fat file: CoreActionSheetPicker are: armv7 armv7s arm64

• if I take framework from Debug-iphonesimulator folder - it works on simulators. and I have error on device: ld: symbol(s) not found for architecture arm64

    xcrun lipo -info CoreActionSheetPicker 

  Architectures in the fat file: CoreActionSheetPicker are: i386 x86_64

So, how to create a dynamic framework that works on devices and simulators?

This answer related to Xcode 6 iOS Creating a Cocoa Touch Framework - Architectures issues but it's not duplicate.

---

Update:

I found a "dirty hack" for this case. See my answer below. If someone knows more convenient way - please, let me know!

Answer 1

The actuality of this answer is: July 2015. It is most likely that things will change.

TLDR;

Currently Xcode does not have tools for automatic export of universal fat framework so developer must resort to manual usage of lipo tool. Also according to this radar before submission to AppStore developer who is framework's consumer also must use lipo to strip off simulator slices from a framework.

Longer answer follows

---

I did similar research in the topic (the link at the bottom of the answer).

I had not found any official documentation about distribution of so my research was based on exploration of Apple Developer Forums, Carthage and Realm projects and my own experiments with xcodebuild, lipo, codesign tools.

Here's long quote (with a bit of markup from me) from Apple Developer Forums thread Exporting app with embedded framework:

What is the proper way to export a framework from a framework project?

Currently the only way is exactly what you have done:

• Build the target for both simulator and iOS device.

• Navigate to Xcode's DerivedData folder for that project and lipo the two binaries together into one single framework. However, when you build the framework target in Xcode, make sure to adjust the target setting 'Build Active Architecture Only' to 'NO'. This will allow Xcode to build the target for multiple binarty types (arm64, armv7, etc). This would be why it works from Xcode but not as a standalone binary.

• Also you'll want to make sure the scheme is set to a Release build and build the framework target against release. If you are still getting a library not loaded error, check the code slices in the framework.

• Use lipo -info MyFramworkBinary and examine the result.

lipo -info MyFrameworkBinary

Result is i386 x86_64 armv7 arm64

• Modern universal frameworks will include 4 slices, but could include more: i386 x86_64 armv7 arm64 If you don't see at least this 4 it coud be because of the Build Active Architecture setting.

This describes process pretty much the same as @skywinder did it in his answer.

This is how Carthage uses lipo and Realm uses lipo.

---

IMPORTANT DETAIL

There is radar: Xcode 6.1.1 & 6.2: iOS frameworks containing simulator slices can't be submitted to the App Store and a long discussion around it on Realm#1163 and Carthage#188 which ended in special workaround:

before submission to AppStore iOS framework binaries must be stripped off back from simulator slices

Carthage has special code: CopyFrameworks and corresponding piece of documentation:

This script works around an App Store submission bug triggered by universal binaries.

Realm has special script: strip-frameworks.sh and corresponding piece of documentation:

This step is required to work around an App Store submission bug when archiving universal binaries.

Also there is good article: Stripping Unwanted Architectures From Dynamic Libraries In Xcode.

I myself used Realm's strip-frameworks.sh which worked for me perfectly without any modifications though of course anyone is free to write a one from scratch.

---

The link to my topic which I recommend to read because it contains another aspect of this question: code signing - Creating iOS/OSX Frameworks: is it necessary to codesign them before distributing to other developers?