Is it possible to submit an app to App store with a dynamic framework that has the simulator slice in it?

I found out that some apps had been rejected because they had the simulator slice in a dynamic framework, but I then noticed that some dynamic frameworks like Parse have the simulator slice and there are apps using it in the app store.

We make a framework that we provide to our customer to embed in their apps and we want to know if we can make it a dynamic framework instead of a framework with a static library in it that we build the framework symlinks after the build using a shell script. We would like to distribute our framework as a dynamic framework.

We need to know if we have to provide our clients with two frameworks, one with the simulator slice in it, for debugging and another one without it, for release, so our clients can submit their apps for approval.

To distribute a framework, you need to build two versions, one for the simulator, and one for devices.

If you don't want to alienate your client, you'll have to use lipo to create a fat binary (just search Stackoverflow with keywords "lipo fat framework" and you'll have a quick tutorial).

There is no such thing as "rejecting because of debug build", as when submitting to the app store only "release build" exists.

The problem in this topic is about architectures slices, where a bug on certains old versions of Xcode made it unable to strip the simulator (x86) slice. Sadly, this bug is back, which means we'll have to alienate our clients ¥by asking them to lipo strip the architecture from our frameworks.

The bug is still there it seems, but no update from Apple nor any admin/engineer here.

I'm unaware of any workaround besides giving two versions of the framework, which isn't an option for us.

I wonder how Facebook, Twitter and other companies deliver all their frameworks as a dynamic one. I guess they have some script somewhere hooked automatically to Build Phases that slices the framework accordingly.

I think we can create a universal framework which consists of both simulator as well as device architectures. You can find it here how to do that.I also found out the script which people are currently using to strip the simulator architectures. You can see the installation instructions of Realm-Cocoa framework here.

I am not sure if Facebook is distributing its framework as dynamic one. Last time I saw they have ResourcesBundle as well along with .framework files. May be they are distributing static frameworks only.

You should be providing both debug and release optimized versions of your frameworks anyway. Personally, I would simply leave the simulator slice out of the release version. Release testing should always be done on a device

We deliver frameworks not only to large clients, but also small developers, and we can't expect them to "delete" and "re-import" each ramework each time they have to switch build target.

The release is something else, but even during development it's a hassle to deal with. And this is a huge backward move compared to static libraries which were automatically stripped (actually, even the dynamic one were, the bug appeared somewhere around Xcode 6.3, disappeared and back again in 7).

I'm also facing the same problem. My team is developing a dynamic framework, which is not open source. The only way to distribute the framework to our customers is by building a fat framework. But bad luck, Apple is rejecting the apps, only because the framework contains simulator slices.

This is not fair actually. Apple should provide us some kind of option to create a dynamic library which can run on both simulator and devices.

Distributing a framework for simulator and for devices separately is a cumbersome process for both developers and customers.

The problem still seems to persist, any update from Apple moderator here? Are they planning not to fix this or are they planning to fix this? If planning then a quarter or a month would help us to decide which actions or workaround to take.

More Like This

Incoming Links

This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Developer Forums Participation Agreement.