Apple sandboxing friend or enemy

So, I was almost done testing the application that we wanted to release on mac app store, I tested that thing on almost 10 different mac machines, and it was working like a charm.

So, on the late Monday night we went to itunes connect and looked for things that we were gonna need to upload the application to the app store.
I have to say, apple are very damn strict about who uploads the app to the app store, and it took us nearly 2 days to go through all the stuff as it was our first time. Its not just about paying $99.0 to apple, there is more to it than just that.
But we did upload it eventually.

Certificates…. lots and lots of certificates, not just for the app but for also the developer who is working on the app.

And after that what you need is thing called developer profile, which took most of our time. A developer profile is a single file containing all the information needed to upload the app.
It contains the distribution profile, developer certificates, etc.

And.. with a lot of efforts it was done.
We had passed all the hurdles to submit the app to apple, but little did we know, that a storm was brewing at apple, they were gearing up with their weapons to go against us developers..
After submitting the application they came back to us almost immediately saying

1- the app was not sandboxed.
2- one of the library is compiled for ppc7400.

Sandboxing is easy, but after enabling that few features in our app were disabled, without giving any errors or warnings, which is very bad, because we had tested the application and it was working fine, we were not aware of the fact that we’ll have to test it again.

Whatever options that you see in Xcode 5 to handle entitlements they are not enough, if your application plays sound and does some other stuff, you’ll have to add your new entitlements to the sandboxing in order to enable that.

To enable the sound in our app, we had to put 3 different entitlements to the entitlement file.

This one allows your application to access the microphone.

com.apple.security.device.microphone

This allows talking to the MIDI Server which coordinates all the Midi functionality across applications.

com.apple.security.temporary-exception.mach-lookup.global-name

This allows talking to audio components which are not itself sandboxed.

com.apple.security.temporary-exception.audio-unit-host

Was it worth going through all this trouble, I don’t think so, sandboxing is a good option for mobile devices, but for iMacs and macbooks apps need to do many more things in order to run properly. C’mon even to access file you need to add that entitlement to sandboxing.
Its a good feature, but apple should release some set of entitlments which will be used by application commonly. [such as games need sound+file access+game controller{if any}, etc.]

If you’re getting issues like one of the library is compiled for ppc7400 and you’re not developing for ppc7400, you can remove that architecture form the dynamic library that is causing the issue.
You can remove the architecture from any dylib using lipo command with -remove flag.. it is used as follow..

 sudo lipo libfmodex.dylib -remove ppc7400 -output libfmodexx.dylib

 lipo [input_file] -remove [architecture to remove] -output [output_file]

Happy Coding folks!