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

Any luck? ... It's so annoying right now.

Hello trvdatnielsen.

I think you have to build different versions of your library in order to make it available for simulator and Devices.

I started to build a framework to distribute to my clients as well.

I have a question. What steps you follow to archive your framework? Will the Debug version be rejected by Apple validation?

Regards,

It wasn't directed to me, but I'll try to answer.

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.

Hope it helps.

Hey @EinharchAltPlus

Is the app store submission bug is still there ? Any workarounds you figured out around this issue ?

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

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.

Sorry, it's not an option for us.

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).

Hey EinharchAltPlus

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.

But I hope Apple fixes this bug on priority basis.

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.

Thanks.