Forums > Dev

max standalone crash on mac 10.8.2 after codesigning with entitlements

Jan 08 2014 | 1:08 pm

Scratch that, I see the test you’re referring to now in the link you provided above, thanks..

Jan 13 2014 | 4:35 am

How did you do this test? I can try with my application and see what happen.

Jan 17 2014 | 8:58 am

I did the test and I found the same possible files. Now, I don’t know. But can it be possible to open unix file in some way and delete some line commands?

Feb 07 2014 | 12:45 am

Hi, I’m having a very weird issue with code signing process: I’m using C74 .mxo in my app to communicate with iPhone and this has always worked fine, BUT now my app doesn’t want to communicate with iOS AFTER code signing my app, before code signing works perfect. Any idea?
(by the way, the C74 app designer doesn’t know anything about it and doesn’t want to waste his time figuring this out..)

Feb 15 2014 | 3:58 am

I am also being rejected by AppStore because of Quicktime API in my project. Although I do not use QT myself, the traces seem to be in Max Runtime and there’s probably not much to do about it. Can we binary hack the runtime so that Apple’s scripts wouldn’t recognize QT calls?

Feb 15 2014 | 5:36 am

That would be an awesome hack if someone could figure it out…

Feb 15 2014 | 6:49 am

Would it be possible to strip out 32bit code from Runtime? If yes, it should help as 64bit Max uses QTKit instead of QuicTime APi.

Feb 15 2014 | 7:29 am

Gave it a try but unfortunately didn’t work. I removed 32 bit architecture from my app using Xslimmer which got rid of some 15.5MB after which my app runs fine. Then re-signed everything, created new .pkg and resubmitted. Response from Application Loader is still the same: Deprecated API Usage being Quicktime API.

Feb 15 2014 | 9:50 am

Nice attempt! I think we’re just going to have to hope that Cycling can address this…

Feb 19 2014 | 5:38 am

So has anyone communicated with Cycling 74 on this topic? It’s a pretty big deal in regards to how I would like to be using their software.

Feb 19 2014 | 7:41 am

Yes, I’ve let them know about it.

Mar 16 2014 | 4:43 am

Can someone give me the exact step by step procedure they are using to determine whether their app still has QuickTime calls? I wasn’t successfully able to do the test that is in the Apple link provided above. Thanks.

Apr 04 2014 | 2:07 pm

If I understand correctly, no one has had any success in sending an app to the Apple App Store so far? (I mean after the reportedly denied apps with Quicktime API calls)

Apr 04 2014 | 2:29 pm

Unfortunately no..

Apr 05 2014 | 8:10 am

Don’t give up hope guys – I have a good feeling about this. ;-)

Apr 08 2014 | 7:41 am

Hi everyone,
I tried the "nm" command that TIMETOY suggested and it returned no results.
Does that mean that I do not have any QuickTime or QTKit API included ?

I tried yesterday to upload an app, after testing it with nm, and it was rejected because of QuickTime API usage!
So i guess we wait!


Apr 08 2014 | 7:55 am

Nikolas, you’re using this format for the nm command?

nm -m "" | egrep "QuickTime|QTKit"

If so, that’s weird that you’re not showing any QuickTime usage if so…

  • This reply was modified 2 years by  Dan Nigrin.
Apr 08 2014 | 9:50 am

Hi Dan,
I used the full path of the app.
Where should i put the app to use the command without the full path ? Does it make any defference ?

Apr 08 2014 | 9:55 am

I don’t think it makes any difference. Hmm. Makes me wonder why you are getting refused still.. Anyway, I’m optimistic that Cycling will come through for us..

Apr 08 2014 | 10:07 am

I hope so! Well, I will post if anything new comes up.

Apr 09 2014 | 2:01 am

I hope Cycling will do something for this problem..

Apr 09 2014 | 10:23 am

Just an FYI,

Tried using this, instead of the "nm" command:
otool -L /Path/

It returns the libraries that are linked to the binary.
Although there was no QuickTime linked in my app, it showed this line (among others!):

"/System/Library/Frameworks/QTKit.framework/Versions/A/QTKit (compatibility version 1.0.0, current version 1.0.0)"

Apr 11 2014 | 6:57 am

Interesting, thanks – I’ll report to the folks at Cycling.

Apr 23 2014 | 3:39 am

Max 6.1.7 released – from the release notes:

"Quicktime: removed API calls from Max kernel"

Someone who’s got an app ready to submit to Apple, please give it a test! In my testing, standalone’s now pass the "nm" test, but still not the "otool" test. Hopefully the latter will not be as important? I just don’t have an app ready to submit to Apple yet to try…

Apr 23 2014 | 4:54 am

Rejected for "Deprecated API Usage" again.
The "otool", finds the QTKit. I tested even an empty patcher build, and it still finds the QTKit, so I think the problem remains…

Will try out again and post if something changes!


Apr 23 2014 | 9:45 am

Hi Nikolas,

Thanks for the report. Have you manually removed the qtimage extension from the standalone? That would also be necessary.


Apr 26 2014 | 6:15 am

Hi Joshua,
Yes, I have removed all extension but polybuffer.mxo and setplugpath.mxo.


May 26 2014 | 11:24 am


Any news on the matter ?

Jun 13 2014 | 3:30 am

I don’t know anything. I think that this problem can be solved only by Cycling. We can’t do anything I think..

Jul 02 2014 | 11:41 am

Hi guys, any updates on the horizon? A word from Cycling about the state of things in regards to this issue would be much appreciated.

Aug 07 2014 | 2:56 pm

This seems to be good news in Max 6.1.8 !

• kernel: removed QtKit and Quicktime Frameworks for Mac App Store compatibility

I’ll try to resume work in my long pending updates and comment here.
If anyone else can test with an app ready to send to Apple and report too, it’ll be appreciated, thx!

Aug 07 2014 | 7:39 pm

I don’t have an app ready to go for the App Store, but I’ve tested with an empty patch to see if it now passes the otool test, and it does…

Aug 08 2014 | 2:35 am

Hi guys, I’m sorry but for now I don’t have any App ready to test the upload. I hope that now we can upload applications, I’m very excited. ;)

Aug 08 2014 | 6:13 am

Hi guys,
I am trying to submit an app, but I get a bunch of warning like "Invalid Signature – The nested app bundle PATH/Contents/Frameworks/MaxAPI at path PATH/Contents/Frameworks/MaxAPI.framework/ is not signed"
I think the warnings refer to every framework and .mxo that needs code signing.

I also get an error like the warning above, referring to the .app itself.

Does anyone knows if something has changed for the code signing process?

Thank you in advance,

Aug 08 2014 | 7:23 am

Nikolas, I presume when you codesigned all that stuff as per usual, there were no errors reported in the Terminal? I’m not aware of any codesigning changes with Apple, but then again, it’s been a while since I submitted anything..

Aug 08 2014 | 8:47 am

No errors in the Terminal. I will try out different approaches and report back for any news.

Aug 08 2014 | 8:58 am

I got an email from Apple a few days ago warning all developers about codesigning and Gatekeeper changes:

With the release of OS X Mavericks 10.9.5, the way that OS X recognizes signed apps will change. Signatures created with OS X Mountain Lion 10.8.5 or earlier (v1 signatures) will be obsoleted and Gatekeeper will no longer recognize them. Users may receive a Gatekeeper warning and will need to exempt your app to continue using it. To ensure your apps will run without warning on updated versions of OS X, they must be signed on OS X Mavericks 10.9 or later (v2 signatures).

If you build code with an older version of OS X, use OS X Mavericks 10.9 or later to sign your app and create v2 signatures using the codesign tool. Structure your bundle according to the signature evaluation requirements for OS X Mavericks 10.9 or later. Considerations include:
Signed code should only be placed in directories where the system expects to find signed code.
Resources should not be located in directories where the system expects to find signed code.
The –resource-rules flag and ResourceRules.plist are not supported.
Make sure your current and upcoming releases work properly with Gatekeeper by testing on OS X Mavericks 10.9.5 and OS X Yosemite 10.10 Developer Preview 5 or later. Apps signed with v2 signatures will work on older versions of OS X.

For more details, read "Code Signing changes in OS X Mavericks" and "Changes in 
OS X 10.9.5 and Yosemite Developer Preview 5" in OS X Code Signing In Depth.

@Nikolas: might these new rules be getting in your way? I haven’t read the guides yet but there might be some answers there.

Aug 09 2014 | 2:47 am

Good news everyone!

My app is waiting for review…
The code-signing must be done with the –deep option like this:
"codesign -f -s "3rd Party Mac Developer Application: YOUR NAME" /path/to/…" –deep"

You must code sign all the frameworks and mxos like that.

Other than that, everything else done as before (i.e. the installer package).
For any other news on the subject, I will make a post!


Aug 09 2014 | 3:59 am

thank you very much. this is a very good information. I’ll try it.

Aug 09 2014 | 5:22 am

Great work Nikolas! And thanks to Cycling for listening and getting the Quicktime related fixes in as well.

Aug 09 2014 | 5:26 am

Also Nikolas, did you codesign everything on a 10.9 machine, as mentioned in Juan’s post?

Aug 09 2014 | 5:35 am

Thank you guys,
and yes, the code signing (as well as the development) is done on a 10.9.4 machine.

Aug 09 2014 | 5:47 am

Good to know, thanks.

You know, there’s been a lot of changes since I wrote the original Your Max Standalone on the Mac App Store article a few years ago, together with Oli Larkin and James Howard Young. Would any of you be interested in collaborating on an update to that article? This stuff is unfortunately complicated, and there are several bits of knowledge spread across various places now, making it hard to keep up.

Aug 09 2014 | 6:09 am

Would be great to have a new guide, count on me.
… By the way I could translate to Spanish if you like.

Aug 09 2014 | 6:13 am

Hi Dan,
i think that a new guide is very useful, so if you want count on me. I can translate it in Italian ;) I was thinking also to create a max based free application all of command lines to sign the application, principally for beginners, simply with a "drag and drop".

Aug 09 2014 | 7:05 am

OK cool – I will begin (in my spare time – yeah right!) to work on an updated first draft, then will pass it by you guys (and whomever else is interested to help) for revisions/translation/etc..

Aug 09 2014 | 7:11 am

An update on the App Store guide will be very convenient, I’m in for helping too.

Aug 09 2014 | 7:18 am

I would also like to work on the new guide!

Aug 23 2014 | 7:01 am

okay, I was all optimistic about 6.1.8 and tried to submit my app to the app store, but now I’m getting "App sandbox not enabled" messages for [myapp].app/Contents/MacOS/[myapp] even though as far as I can tell I’ve included all the proper entitlements and codesigned properly. (No QT messages though, which is a relief because maybe that means this is something I can fix myself.)
I’ve read the updated security info from Apple but since I’ve been working in 10.9.4 the whole time it doesn’t seem to apply to me.
Any ideas?

Aug 23 2014 | 7:15 am

Hi Timetoy,
are you sure the entitlements you use are correct? Have you enabled the sandbox entitlement? The codesigning must be done with the –deep flag.
I know these sound like "noobie" problems, but that is what one may forget easier!
Also, you have to codesign the bundle itself with the entitlements last.
I recently submitted an app (SampleBox) and it passed through yesterday. So it is doable!!

My suggestion, start over the codesinging. Generally the terminal tells you what is not codesigned inside the bundle. If the problem persists, maybe post your entitlements file.


Aug 23 2014 | 12:06 pm

Thanks Nik, it’s good to hear that your SampleBox app made it through. Means there must be something I’m missing.

I tried again from scratch but still get the same error. Can’t figure out what I’m doing wrong. My entitlements file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">

all help is tremendously welcome

Aug 23 2014 | 8:16 pm

Can you post the codesigning commands you are using?

Aug 24 2014 | 5:54 am

this is the latest set of codesigning commands I used. I know it’s more than what’s strictly required, but it was late and I was getting desperate.

codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Frameworks/MaxAPI.framework --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Frameworks/MaxAudioAPI.framework --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Info.plist --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/MacOS/[myapp] --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/MacOS/[myapp].entitlements --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/PkgInfo --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Resources/Max.icns --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Resources/[myapp].icns --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Resources/[myapp].rsrc --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/support/ad/ad_coreaudio.mxo --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/support/ad/ad_portaudio.mxo --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/[myapp].mxf --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/[myapp].entitlements --deep
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app --deep

productbuild --component /Applications/[myapp].app /Applications --sign "3rd Party Mac Developer Installer: [developer]" --product /Applications/[myapp].app/Contents/Info.plist [myapp].pkg
Aug 24 2014 | 7:31 am

A few things wrong here.

* You don’t need to sign the Info.plist, the contents inside the MacOS folder, the .icns file, or the entitlements file

* For each of the codesign commands, you have to include the entitlements file as an option to the command. Like this:
codesign -f -s "3rd Party Mac Developer Application:[developer]" /Users/USERNAME/Desktop/[myapp].app --entitlements /Users/USERNAME/Desktop/[myapp].entitlements --deep
I see now that Nikolas didn’t add that in in his last example above, not sure if that was a mistake, or if it’s no longer a requirement? It certainly was before.

* I’ve never tried signing the app and its contents while within my actual Applications folder. It may work, but I also wonder if there may be some permissions issues. I usually just put the app on the Desktop and sign it while there.

Hope this helps!

Aug 24 2014 | 7:39 am

Hi timetoy,
firstly the framworks must be codesigned like so:
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Applications/[myapp].app/Contents/Frameworks/MaxAudioAPI.framework/versions/A –deep

also the bundle must be signed with entitlements like so:

codesign -f -s "3rd Party Mac Developer Application: [developer]" –entitlements path/to/entitlements/myapp.entitlements /Applications/[myapp].app –deep

you dont have to include the file in the bundle.

sorry I cant be more helpful now. Try it and post again your results!


Aug 24 2014 | 9:25 am

oh this is great, Dan & Nik you guys rock. Going to try this later, wish me luck…

Aug 24 2014 | 12:57 pm

when doing:
codesign -f -s "3rd Party Mac Developer Application: [developer]" /Users/MiniNew/Desktop/[myapp].app/Contents/MacOS/[myapp] --entitlements /Users/MiniNew/Desktop/[myapp].entitlements --deep

I get the error:

unsealed contents present in the root directory of an embedded framework
In subcomponent: /Users/MiniNew/Desktop/[myapp].app/Contents/Frameworks/MaxAudioAPI.framework

I had signed the MaxAudioAPI.framework beforehand just as Nik had suggested.

optimism fading, but I will persist…

Aug 24 2014 | 1:03 pm

scratch that last post… I just started over and now it works! submitting now…

Aug 24 2014 | 6:06 pm


Aug 25 2014 | 12:25 am

promising message from Apple:
"The status for the following app has changed to Waiting For Review"

happy happy.

Aug 25 2014 | 12:50 am

Congrats Timetoy!!

Aug 25 2014 | 4:21 am

One more little bit of advice: don’t be discouraged if you get denied once they review the app – there’s all sorts of pitfalls still ahead, but hopefully the collective wisdom of those of us who’ve been lucky enough to make it through will help you make it all the way through!

Sep 04 2014 | 5:03 am

Hi guys I have a new problem. When I send my .pkg file, App Store refuse my app for this reasons:

Invalid Signature – the main app bundle at path Music is not signed. The following error(s) were reported from codesign:
/tmp/mz_4123270847529686120dir/mz_6270106668677812673dir/com.robertoattanasio.musicbook.pkg/Payload/Music code object is not signed at all
In subcomponent: /private/tmp/mz_4123270847529686120dir/mz_6270106668677812673dir/com.robertoattanasio.musicbook.pkg/Payload/Music Book.mxf

The problem is that I signed everything. I signed frameworks and .mxo files, and the entire application. I used also –deep flag. So I don’t know where is the problem.

Sep 04 2014 | 10:16 am

I had that error too, and traced it to a PkgInfo file which for some reason was inside the Frameworks folder. Make sure that MaxAPI is the only file inside the MaxAPI.framework folder. I just deleted the PkgInfo file and my app still worked fine.

PS: what is the usual wait time to get a response from Apple after an app’s status is Waiting for Review?


Sep 04 2014 | 12:12 pm

Thank you I’ll try it. If I remember well, it takes 3/5 days.

Sep 04 2014 | 12:21 pm

unfortunately the app store gives me always the same error..

Sep 10 2014 | 1:36 pm

ok, I’m ready to give up on this altogether.

My app came back from the review needing a couple of small things that I could easily change.

Now I’ve codesigned the app using EXACTLY the same procedure as before and this time I’m getting the same Invalid Signature error as Roberto. It seems like something has changed at Apple, but what that is is a mystery. They recommend reading this technote ( but that offers no discernible help.

frustrated, tt

Sep 12 2014 | 5:54 am

Same problem here.
after a few minutes I upload the pkg file I get the exactly same error.

Sep 12 2014 | 8:00 am

I wonder if something has changed on the Apple side in just the last few weeks, between when Nikolas submitted and when you guys (Marvin and Timetoy) did? I’m afraid I can’t help as I have nothing to submit currently…

Sep 12 2014 | 10:00 am

so, the problem here is that on the email it says to us that the main .mxf is not signed at all.

here’s what I’ve noticed so far:

when I do the codesign I’ve always been asked to confirm the utilisation of the key (I didn’t choose "always confirm") twice, but for some reason for the .mxf file it ask me only once.

On the tech note linked you can see this:

OS X v10.9 Mavericks introduced a number of significant changes to the code signing machinery. Most of these changes apply to the resource envelope of a code signature, where the signature keeps a list of files in a bundle. The pre-Mavericks version, version 1, recorded only files in the Resources directory and ignored the rest. The Mavericks version, version 2, makes the following changes:

It records substantially all files by default. There are no default "holes".
It records nested code (frameworks, dylibs, helper tools and apps, plug-ins, etc.) by recording their code signature for verification.
It records symbolic links. Version 1 resource envelopes ignore symlinks.

A signature may contain multiple versions of resource envelopes. Mavericks generates, by default, both version 2 and version 1 resource envelopes.

I don’t have enough knowledge about this but I think it may be the reason, somehow the .mxf file doesn’t get the 2 signatures versions. but I might be wrong.

also, if you use codesign -f -s "3rd Party Mac Developer Application: [developer]" [path]/[myapp].app –deep, the deep option already sign all the other files inside the bundle (for some reason it doesn’t sign the files inside the ad folder, but that’s it), on the other hand here’s what Apple suggests:

When verifying signatures, add –deep to perform recursive validation of nested code. Without –deep, validation will be shallow: it will check the immediate nested content but not check that fully. Note that Gatekeeper always performs –deep style validation.

Important: While the –deep option can be applied to a signing operation, this is not recommended. We recommend that you sign code inside out in individual stages (as Xcode does automatically). Signing with –deep is for emergency repairs and temporary adjustments only

I’ll keep try but is getting really annoying.

Sep 12 2014 | 11:13 am

I’m almost sure that the problem for me is the signature version of the mxf file, if Timetoy and Roberto can please try this and see if it’s the same it would’ve be a starting point to fix the issues.

in the terminal type: codesign -dv [path to signed file]
you should see a report on the signature status for that specific file.

this is what I have got:

codesign -dv [path to signed file].app
Identifier= [—–]
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=72887 flags=0x0(none) hashes=3635+5 location=embedded
Signature size=4351
Signed Time=12 Sep 2014 18:14:06
Info.plist entries=25
Sealed Resources version=2 rules=12 files=51 <———- !!!!
Internal requirements count=1 size=204

codesign -dv [path to signed file].mxf
Identifier= [—–]
CodeDirectory v=20200 size=148 flags=0x0(none) hashes=1+2 location=embedded
Signature size=4351
Signed Time=12 Sep 2014 18:15:02
Info.plist=not bound
Sealed Resources=none <———- !!!!
Internal requirements count=1 size=204

codesign -dv [path to signed file]/Contents/Frameworks/MaxAPI.framework/versions/A
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=3924 flags=0x0(none) hashes=189+3 location=embedded
Signature size=4351
Signed Time=12 Sep 2014 18:13:01
Info.plist entries=16
Sealed Resources version=2 rules=12 files=2 <———- !!!!
Internal requirements count=1 size=200

that "Sealed Resources=none" it must be the problem

Sep 12 2014 | 12:07 pm

Hi Marvin, this my result:

Executable=/Volumes/AttA HD/Pubblica/Roberto/Personale/Development/Max:MSP/Max For Prototype/Music Book/Music Book
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=72894 flags=0x0(none) hashes=3635+5 location=embedded
Signature size=4359
Signed Time=04/set/2014 21:01:13
Info.plist entries=24
Sealed Resources version=2 rules=12 files=25
Internal requirements count=1 size=216

Executable=/Volumes/AttA HD/Pubblica/Roberto/Personale/Development/Max:MSP/Max For Prototype/Music Book/Music Book.mxf
Identifier=Music Book
CodeDirectory v=20200 size=194 flags=0x0(none) hashes=1+5 location=embedded
Signature size=4359
Signed Time=04/set/2014 21:01:12
Info.plist=not bound
Sealed Resources=none
Internal requirements count=1 size=196

Executable=/Volumes/AttA HD/Pubblica/Roberto/Personale/Development/Max:MSP/Max For Prototype/Music Book/Music
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=3964 flags=0x0(none) hashes=189+5 location=embedded
Signature size=4359
Signed Time=04/set/2014 21:01:09
Info.plist entries=16
Sealed Resources version=2 rules=12 files=2
Internal requirements count=1 size=204

I’m sorry but I don’t know hot to help you, this is an unknown world for me. But if need some other tests let me know.

Sep 14 2014 | 8:59 am

sounds interesting Marvin, you might be on to something. The signature status on my app looks similar to yours.

Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=72885 flags=0x0(none) hashes=3635+5 location=embedded
Signature size=4353
Signed Time=Sep 10, 2014, 10:22:52 PM
Info.plist entries=24
Sealed Resources version=2 rules=12 files=31
Internal requirements count=1 size=204

CodeDirectory v=20200 size=192 flags=0x0(none) hashes=1+5 location=embedded
Signature size=4353
Signed Time=Sep 10, 2014, 10:22:52 PM
Info.plist=not bound
Sealed Resources=none
Internal requirements count=1 size=188

when I have time to tackle this again I’m going to contact an apple engineer and see what he says.

Sep 15 2014 | 7:50 am

I think version 2 code signatures will never work for apps made with Max, because the .mxf file has to be in the /Contents directory for the app to run, and I’m afraid that apple sees the .mxf file as an "arbitrary data file" and not as code:
"These places [ie, /Contents/] are expected to contain only code. Putting arbitrary data files there will cause them to be rejected (since they’re unsigned)."

Sep 16 2014 | 2:20 pm

Fair enough..
so if it is possible to move the .mxf file into another folder, can that solve the problem?
Does somebody knows which file contains the pointer that locate the main .mxf?

Sep 17 2014 | 5:55 am

I don’t think you can change where Max expects that file to be.

What I’m struggling with here is that Nikolas was able to sign and submit his app (and have it make it all the way through), and Timetoy you were successful at least once. So I don’t think there’s something fundamentally wrong with the structure of the Max app bundle or anything, and rather that the detailed approach to signing (e.g. what you sign, and what order you sign those things) must have become a bit more complex with the v2 signatures.

Hopefully I’ll soon have something to upload to Apple, so I can chime in with my own experience…

  • This reply was modified 2 years by  Dan Nigrin.
Sep 18 2014 | 1:11 am

I think the reason my app made it through the first time is that the version 2 signature wasn’t a requirement yet, and then when I got around to re-submitting my app it was. Just unfortunate timing on my part.

Sep 30 2014 | 1:19 am

Hi mates, do you know if apple allow us to write an aiff sound file to hard drive (sfrecord) without opening the dialogue message of "open"? I’m trying to write a sound file in the same location of my app BUT when I make the bundle the recorded files are lost…, I can not find then neither inside /Contents, or MacOS… Any idea? Should I preset an absolute location? like MacintoshHD? would be possible?

Sep 30 2014 | 1:24 am

sorry, I move the message to a new Topic.

Nov 18 2014 | 3:40 am

I’m having the same problem about .mxf being "not signed at all". Tried to move my .mxf to /Contents and create an alias in .app root but Max does not load the .mxf this way. So I’m quite unhappy as I have a previous version of my app in App Store and need to upload an updated version.

Dec 16 2014 | 2:15 pm

So is this the end of Max apps in App Store? I can’t update existing apps or create new ones. I guess the only option is to recreate my apps currently pulbished on some other platform. I wonder whether I’m alone in this.

Dec 16 2014 | 6:58 pm

You’re not alone Lasseron. I’ve not made any comments myself because I simply haven’t gotten to the point yet of needing to update one of my apps on the store. I have communicated with Cycling in the past about the App Store issues we have had, and they’ve been responsive when we have had something specific for them to address. So far, I think we have had hunches as to what the current problem is, but it would be great if we could come up with the definitive cause of the current problem, along with the definitive solution. Then Cycling I’m sure would take a close look at it…

  • This reply was modified 2 years by  Dan Nigrin.
Feb 03 2015 | 3:55 am

We should have a fix for this in a forthcoming update. Thanks for your patience — the App Store is a moving target. We do our best to keep up with the changes and enable publication of standalones built with Max.


Feb 03 2015 | 3:59 am

Thanks for the update, I’m really glad to hear you’re working on it!

Feb 03 2015 | 4:19 am

Ditto, thanks Jeremy!

Feb 03 2015 | 10:49 am

Great news!! :)

Feb 03 2015 | 10:57 am

cannot express how grateful I am.

Mar 31 2015 | 9:24 am

Anyone tried uploading an app with Max 7.0.2 ?

It will probably fail, but a try doesn’t hurt! I do not have currently any app for uploading, but I will soon.
If anyone beats me to it, please post your try’s results!


Mar 31 2015 | 9:56 am

I tried with 7.01, and got through to full app review, but was then rejected at that point with these complaints:

We found that ‘/Applications/General MIDI MIDI Player’ links against : ‘@executable_path/../Frameworks/Chromium Embedded Framework.framework’ which appears to be missing.

We also found that the app links against: ‘/usr/local/lib/libplugin_carbon_interpose.dylib’ in a non standard manor which can cause stability problems.

I had removed the Chromium Embedded Framework.framework file from the app bundle because my app didn’t need it, and it was huge, but of course I could add it back in if necessary. But the other libplugin_carbon_interpose.dylib problem I did not have a way around.

Cycling knows about these issues, and is trying to address the problem.

Apr 05 2015 | 12:00 am

Following up on this error that Timetoy reported:

unsealed contents present in the root directory of an embedded framework
In subcomponent: /Users/MiniNew/Desktop/[myapp].app/Contents/Frameworks/MaxAudioAPI.framework

I was getting that too, and the solution was to remove the PkgInfo file from the root directory of that framework.

See this tech note from Apple for more on that, to quote:

* Do not put files or directories into the top directory of an app or framework bundle
* All content must be inside Contents or Versions respectively as described earlier

Timetoy I saw where you mentioned later on about removing PkgInfo to solve a different error, but perhaps this clears up the "why" of it a bit more. (A PkgInfo file, in case you’re wondering, is not required by Apple.)

Apr 05 2015 | 2:12 am

Hey Leigh and others,

My Apple Developer membership ran out recently, and I asked myself if it would be worth the hundred bucks to renew it. I found this article by Steve Jobs talking about why Flash is not allowed on mobile devices:

"We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.

Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen."

This all seems to apply to Max as well. If the app store is a ‘moving target’ for C74 then Apple is playing a game that I don’t really think we’ll win.

My conclusion: I donated the $100 to charity (UNICEF) and switched over to developing custom apps for individual clients.

Still love Max and use it every day, but in terms of using it to develop for the App Store I think the writing is on the wall unfortunately.


Apr 05 2015 | 4:26 am

Thanks Leigh for the info on PkgInfo. My $0.02, for whatever reason, I did not get that error without removing the PkgInfo, and was able to upload and get all the way to App Review…

Apr 05 2015 | 4:29 am

Timetoy, don’t disagree with your assessment. But honestly, it’s been an uphill battle from the beginning with Apple for Max and the App Store, and I for one like the challenge! For me, the appeal has always been that I don’t have the time required to get schooled enough in Objective C or whatever other language to get to the level of building a standalone app, and Max gives me the ability to rapidly get there. There’s certainly pain at this last stage, but I’m optimistic that Cycling will come through for us yet again!

Apr 05 2015 | 5:45 am

Hi guys. I’m exactly in the same situation of Dan. But I can’t also disagree with Timetoy. In fact, I’m thinking about to sell my applications privately, only because I don’t like to stop working on my applications because App Store gives to Cycling too many problems on every version they release. With this post I just want to thank you to Cycling staff for their job and I’ll continue to use Max/MSP for my applications, with or without the App Store.
Happy Patching ;)

Apr 05 2015 | 8:04 am

Also remember that you can export a gen patch in C language and later implement the dsp code into Xcode, is not a solution but it is something.
Still hopping to finally get to the app store, my thanks to all Max developer for their work.


Apr 25 2015 | 10:19 am

For the record, I have an Apple developer account for (for OS X apps, not iOS stuff), but I haven’t submitted anything to the Apple Store. I only distribute software through my own website. The signing I was doing was to make Gatekeeper not complain about running software from an "unknown developer".

Marvin brings up a good point, that Max is still an excellent environment for prototyping, and if you develop your signal processing with gen~, it’s easily ported to C++ code later.

Couple Max as a prototype environment with Apple’s new "Swift" language, and you may have an easier path to Apple-compliant OS X apps than trying to shoehorn Max to do the job. (Not to mention opening up the option of developing for iOS.)

Sep 30 2015 | 2:29 pm

Just FYI that the new version 7.0.6 that is now available once again allows for Mac App Store Max application success!

Sep 30 2015 | 3:06 pm

I’m trying it out now but get stuck. I sign the components and the whole app like this:

codesign -f -s "3rd Party Mac Developer Application: My Name"
codesign -f -s "3rd Party Mac Developer Application: My Name"
productbuild --component /Applications --sign "3rd Party Mac Developer Installer: My Name" --product my.pkg

The package gets through Application Loader but then I get an email response from Apple stating that the components are already used by another app:

"CFBundleIdentifier Collision – The Info.plist CFBundleIdentifier value ‘com.cycling74.MSPReWireDevice’ of ‘’ is already in use by another application."

Not sure whether I should remove Info.plist files from each component or replace CFBundleIdentifier by my own app indentifier or something else? Googled did not give a definite answer.

Sep 30 2015 | 5:43 pm

First, I would ask whether you are using ReWire in your standalone – if not, you can safely remove that file from your app bundle and solve your problem that way.

I’ve never included that file in any of my App Store standalones so I’m guessing, but I would go the route of modifying the Info.plist for that bundle, changing the CFBundleIdentifier to something like "com.YOUR-COMPANY-NAME.MSPReWireDevice"

Please let us know how you make out.

Oct 02 2015 | 1:00 am

Thanks for the tip, Dan! It worked. I will post a full list of steps I had to make once I’ll get through to Apple.
Right now, I seem to have one last obsticle: the good old Quicktime API. Apple reports: "Deprecated API Usage – Apple no longer accepts submissions of apps that use QuickTime or QTKit APIs."

I have not slimmed my app and have pretty much all subcomponents in the package. I started by removing /Contents/Resources/C74/extensions/max/qtimage.mxo which clearly had QT calls inside. Any hints where to look next? Probably Jitter components?

Oct 02 2015 | 5:04 am

First – I would strongly suggest slimming down your app – the less stuff in there, the fewer places for you to run into an issue with Apple.

Along these lines – have you used the new options in the standalone object Inspector to remove things? Specifically, you’ll need to uncheck CEF Support, and I would also strongly recommend unchecking Gen Support and Include C74 Resources. Try again after you do those.

Oct 02 2015 | 7:22 am

Dan, thanks again! I did not notice these new options in standalone object myself. After your tips and lots of trial and error I got my app successfully uploaded!

Oct 02 2015 | 7:26 am

Here’s how I got my app submitted to App Store with Max 7.0.6:

1. Uncheck "CEF Support" and "Include C74 Resources" from standalone object’s attributes.

Otherwise I get the error "Deprecated API Usage – Apple no longer accepts submissions of apps that use QuickTime or QTKit APIs." I did not uncheck "Gen Support" as my app uses it.

2. Build Application.

3. Edit /Contents/Info.plist file with your own app info: version numbers and "Application Category" seem to be at least mandatory.

4. Change "Bundle identifier" value from "com.CYCLING74.component" to "com.MYAPP.component" in Info.plist files inside:


Otherwise I get "CFBundleIdentifier Collision" errors.

5. Sign components:

codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Resources/C74/externals/ad/MSPReWireDevice.bundle --entitlements MYAPP.entitlements
codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/libmozjs185.dylib --entitlements MYAPP.entitlements
codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/JitterAPI.framework/Versions/A --entitlements MYAPP.entitlements
codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/JitterAPI.framework --entitlements MYAPP.entitlements
codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/MaxAPI.framework/Versions/A --entitlements MYAPP.entitlements
codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/MaxAPI.framework --entitlements MYAPP.entitlements
codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/MaxAudioAPI.framework/Versions/A --entitlements MYAPP.entitlements
codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/MaxAudioAPI.framework --entitlements MYAPP.entitlements
codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/MaxLua.framework/Versions/A --entitlements MYAPP.entitlements
codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP/Contents/Frameworks/MaxLua.framework --entitlements MYAPP.entitlements

My app is using microphone, so I have to use entitlements.

6. Sign the whole app and create package to be uploaded using Application Loader:

codesign -f -s "3rd Party Mac Developer Application: DEVELOPER NAME" MYAPP --entitlements MYAPP.entitlements
productbuild --component MYAPP /Applications --sign "3rd Party Mac Developer Installer: DEVELOPER NAME" --product MYAPP/Contents/Info.plist MYAPP.pkg

Few optional steps:

– Tweak application menus by following Dan Nigrin’s slides at
– Change the app icon which has to include both normal and retina versions:
– I could probably slim my app more by removing unnescessary components.

Oct 02 2015 | 11:48 am

Good news that you got it uploaded successfully! On quick look at your post above, one thing I wouldn’t recommend is including the C74 resources – it adds size to your app bundle, and I’ve found it to not really be necessary, but your mileage may vary. But if you do exclude those, then that will eliminate some of the work that you then have in your step #4.

Oct 29 2015 | 10:53 am

Hi guys,
I am now at the stage of signing my app before submitting it.
I get some mistakes, that I can not understand why.

I follow Lasseron’s guide, changing the "bundle identifier"and signing all that needs signing.
But, when signing "" bundle from the terminal I get the following 2 lines:
"path/to/app/ replacing existing signature"
"path/to/app/ code objects not signed at all in subcomponent : "path/to/app/"

The same happens with "path/to/app/".

I get two errors if I build the .pkg and try to upload it through the Application Loader. Once about "" and once about the", for not being signed properly, and two more errors:
"Your package contains a file ‘" with a name that contains invalid characters. Avoid using control characters in the file names."
"Your package contains a file ‘" with a name that contains invalid characters. Avoid using control characters in the file names."

I have no files named "Icon" in either directory.

Does anyone have an idea why these errors appear?


Oct 29 2015 | 3:20 pm

[Solved it]
Well, as it seems, "Google Drive" was responsible for this.

First I rebuilt the app (in my Google Drive folder), did all from scratch, same problem.
Another clean build to desktop, no problem at all.

So, don’t sign and (google) drive…
Anyway, the pkg is now uploading fine, so the signing steps by Lasseron above are very correct.


Oct 29 2015 | 4:54 pm

Glad you solved it Nik! That makes sense; Google Drive was probably modifying the file icon (I know that Dropbox does the same thing, to indicate the sync status of the file)….

Good luck with the approval process!

Oct 29 2015 | 5:10 pm

For those of you who get your apps approved, please post to this thread so I can keep the list of Max apps on the store updated!

Jul 06 2016 | 11:10 am

Hi Lasseron,

In your step 4…

4. Change "Bundle identifier" value from "com.CYCLING74.component" to "com.MYAPP.component" in Info.plist files inside:


These items don’t actually contain the "Bundle identifier" code at all, so there’s nothing to change.

However when I submit to Apple I get…

ERROR ITMS-90276: "Missing Bundle Identifier. The application bundle contains a tool or framework […/Contents/Resources/C74/jsextensions/msp/jsbuffer.mxo] that is missing the bundle identifier in its Info.plist file."

Does this mean that I have to manually insert the "Bundle identifier" into all of the above files? (After I removed resources I don’t need of course, like Jitter etc.

On that topic, what components did you remove from the App that you didn’t need? My app plays back wave files, that’s it, so I doubt it uses Jitter, or ReWire, but what else should I be looking to remove to trim down my app?



Jul 07 2016 | 9:07 pm

I’m down to just 2 different errors in the Application Uploader.

ERROR ITMS-90334: "Bundle identifier mismatch. The executable at MyAPP in has been signed with identifier ‘max~’ which does not match the bundle identifier ‘bundle.identifier.MyAPP’."

I have:

1) Edited the Info.plist inside and changed its CFBundleIdentifier to bundle.identifier.MyAPP and its CFBundleExecutable to MyApp

2) Changed the name of the executable in to be MyApp

but I’m still getting the same error.

Does any one know what this issue is here?



Jul 08 2016 | 7:00 pm

Your two posts above are related. Although I don’t know the fix for getting the max~.mxo to work, the good news is that you can likely just eliminate it! If your app just plays back .wav files, you can probably remove almost *all* of the C74/extensions subfolders and their contents, with the exception of C74/extensions/max/sqlite.mxo .

If you break something by removing stuff, it’s easy to fix – just replace the file/folder you removed…

Jul 10 2016 | 2:21 pm


Thanks for all the assistance, I really couldn’t have done it without this forum,

Jul 10 2016 | 5:21 pm

Congrats! That’s super fast Apple turnaround (for once!)…

Also please post your app on this thread – I can no longer edit the original post to update the list, but at least that way all the Max apps up on the store are in one place…

Jul 10 2016 | 7:46 pm

Thanks Dan. It was less than 24 hours from submission to ‘Ready for Sale’ status and it being available for download from the App Store. And I uploaded it on a Saturday.

Sep 11 2016 | 7:07 pm

After having successfully uploaded my app to the App Store, I decided to release a new version. However, when code-signing the entitlements, in the exact same way that I did in the past, I now get the error:

/ bundle format is ambiguous (could be app or framework)
In subcomponent: /

I think this has something to do with an OSX update, but I can’t be certain.

Has anyone else encountered this error?

The command I’m executing is
codesign -f -s MYDeveloperID –entitlements "/MYAPP.entitlements" "/" –deep

I’m running OSX 10.11.6 and Max 7.2.4 (could it be a Max issue?)


Sep 11 2016 | 10:35 pm

Hi Riotchild,

I recently updated my apps in the App Store, and with Max 7.2.4 I had the same problem. Reverting to 7.2.3 seems to do the trick.


Sep 17 2016 | 6:12 am

Hi guys,
I am trying to submit an update to the Mac App Store and encounter the following problem:
I store the paths for the audio files used when a user saves a preset. Apple now doesn’t let you read those files just by having a path to them! So no file gets loaded.

If the app isn’t sandboxed, it works fine, or if I use the entitlement:
with value "/", that asks for read-only permission to the whole of user’s folder.

The think is that the Apple review team, doesn’t like giving you unrestricted (even if read-only), so my update got rejected only for that.

I searched and found that the "proper" way of doing this (having persistent access to files & folders) is by using the entitlement more here – Security-Scoped Bookmarks and Persistent Resource Access.
The methodology is:
– Set the entitlement.
– Get the path of the file through an open dialog panel, and create a security-scoped bookmark
– Resolve the security-scoped bookmark.
Do this when your app later (for example, after app relaunch) needs access to a resource you bookmarked in step 2. The result of this step is a security-scoped URL.
– Explicitly indicate that you want to use the file-system resource whose URL you obtained in step 3.
Do this immediately after obtaining the security-scoped URL (or, when you later want to regain access to the resource after having relinquished your access to it).
– When done using the resource, explicitly indicate that you want to stop using it. Do this as soon as you know that you no longer need access to the resource (typically, after you close it). After you relinquish access to a file-system resource, to use that resource again you must return to step 4 (to again indicate you want to use the resource).
– If your app is relaunched, you must return to step 3 (to resolve the security-scoped bookmark).

So, does anyone has any info about "Security-Scoped Bookmarks", is there any workaround, or is this the end of max apps with stored presets?

The only workaround I see for now, is using the entitlement to freely read the "Music folder, but this forces the user to use audio files located only in the "Music" folder.

Sorry guys for the long post, any info would be much appreciated.


Sep 17 2016 | 12:00 pm

Hi Nikolas,

I haven’t run into that problem myself, but I understand the problem you’re describing. Ugh, that’s a real pain. I’m not sure how one would even create a bookmark from within Max?

Sep 18 2016 | 2:02 am

Well, ideally there would be a quick Max7.2.6 update that handles it! But I really don’t think its fair to ask or expect something like that.
I will maybe try to build an external that create and manages the bookmarks, but haven’t really got any idea on how that will go… so, yeah!
I’ll keep the thread updated for anyone who is interested.

– N

Sep 18 2016 | 5:21 am

That would be really awesome if you’re successful – yes please keep this thread posted. And yes, I doubt Cycling will go there…

Oct 14 2016 | 1:57 pm

This is still an issue in Max 7.3 for those experiencing problems….

"After having successfully uploaded my app to the App Store, I decided to release a new version. However, when code-signing the entitlements, in the exact same way that I did in the past, I now get the error:

/ bundle format is ambiguous (could be app or framework)
In subcomponent: /

I think this has something to do with an OSX update, but I can’t be certain.

Has anyone else encountered this error?

The command I’m executing is
codesign -f -s MYDeveloperID –entitlements "/MYAPP.entitlements" "/" –deep

I’m running OSX 10.11.6 and Max 7.2.4 (could it be a Max issue?)"

Oct 29 2016 | 12:14 am

Hi guys,
My app update gets rejected at the App Store at the review stage, because it "crashes on quit". Anybody has any similar problem?
I submitted just a simple update, and don’t experience any crashes in my Macbook when testing it.

I am still on Max 7.2.5, could this be a OS Sierra & Max 7.2.5 issue?
I attached the crash log if anyone would take a look.

@riotchild if you still have this problem, with Max 7.2.5 the app reaches review but I do have the problem mentioned above.

– N

Oct 29 2016 | 1:26 am

I checked on the console what happens when closing the app.
When the app in NOT codesigned, it looks ok – NO crash reports.
But, when I sign the application, run and then quit it is throws an "Assertion Failure". I attached the console’s log regarding the assertion if anyone makes sense of it.

Thank you guys in advance.


  1. console_output.txt
Oct 30 2016 | 3:30 pm

Hi Nikolas,

I reverted to Max 7.2.3 which fixed my issue.

Oct 31 2016 | 7:11 am

Thanks for these reports. We’re looking into it.

Viewing 126 posts - 151 through 276 (of 276 total)

Forums > Dev