Attempting to notarise - Xcode Archive of App is generic


Following on from this thread, I am trying to take the plunge into a properly signed and notarised OSX App.

I’ve been working through the stages here. I haven’t yet shelled out the necessary £80 for a developer ID, (as its a lot of cash for me and) as I wanted to first check that I could get as far as the notarisation checking process.

Turns out, I’m having problems (surprise surprise!). I’ve got as far as Archiving the app that I have. So I open my OF project, go to Product/Archive and the process runs successfully. BUT it then opens the Xcode Organiser with the archive only identified as an ‘other’ type, i.e. a generic Xcode archive, not an app archive.

As a result I can’t get any further with notarisation. I’ve done a load of reading up on the issue which seems common enough but can’t solve it.

Are there OF related things to get right here too? Has anyone else worked through this?

In hope, and a bit of despair…

Ok, so I don’t have this issue when I archive using the ‘emptyExample’ project.

Presumably this means that there is something in my project (library, or addOn???) that is causing the archiver to produce a generic archive rather than an macOS App archive? Yikes…

I’ll keep guessing away, but can anyone advise?


One thing to note is to make sure you have set your configuration to AppStore ( click edit scheme in the drop down that allows you to switch between Debug and Release. This is an OF supplied configuration that bundles the App up in the right way and removes 32bit code from libfmodex.

However, more generally I am not sure if it is worth going through these steps without a Developer ID.

You would need to sign the app ( in your Build Settings ) with Developer ID Application before it is archived and I think you need a Developer account to do that.

thanks Theo, I’ve done that now.

I’ve also rebuilt the entire project from scratch and since doing that it now is archiving as a macOS app. It might have been that the old version had legacy settings from OF v10, and these are now cleaned out, maybe?

So now I get as far as the Distribute App/Developer ID/Upload Send to Apple notary service option. But here’s the next block; when I hit send, it tells me that Hardened runtime is not enabled:

Thing is, I’m sure I do have this enabled:

Any suggestions here?

And yes, I understand the point about needing to sign pre-archive, I just wanted to scout out possible deal-breakers before I spend the £££… Might this now be causing the above? Hmmm

Edit: ah hah yeah, from this it seems like the hardened runtime is shown as an additional code signing flag. So maybe I can’t get any further without raiding my piggybank. Well played, Apple.

I should mention OF 0.11.0 has some fixes for the AppStore configuration.

In terms of the hardened runtime:

I think you need to add it here too.
Its very subtle, but there is a + in the bottom left corner of this page which you can use to add capabilities.

yup, I got that bit, I’m assuming none of the exceptions need to be activated for now too.

I’ve got past the ‘Hardened Runtime is not enabled’ warning by including sign to run locally in the signing options; but it won’t let me upload the app archive to be notarised unless I have an active Development Team. So it is time to buy. I’ll report back…

Update: well, I’m in. Couple of things to note - the Developer ID isn’t activated instantly, I had to wait about 20 minutes from paying out, until it said that I had permission to raise certificates and use them to access the notarising services:

So that was mildly worrying, thinking I’d messed up and paid for nothing or something. But now I’ve got this far:

As yet, 15 minutes and counting at uploading a 20mb file. Sigh…

Aaaaand success! After what seemed like quite a long upload, and one internet connection crash, it came back with ‘your notarisation was successful’. So, I think I’ve done it. Not a bad end to the year I guess.

Thanks Theo


1 Like

Eurgh. Can’t believe I’m back here - seems I spoke too soon. So, here’s a weird thing.

Today I tweaked two lines in the code to fix a minor bug, and then hit archive. No dice, the following error came up:

fatal error: lipo: -remove i386 specified but fat file: /Users/smcelhinney/Library/Developer/Xcode/DerivedData/isovist_2-3-bpiquhetdppytveyikexqwiimybb/Build/Intermediates.noindex/ArchiveIntermediates/isovist_2-3/InstallationBuildProductsLocation/Applications// does not contain that architecture

Which left me wondering what to do. Having no real smart ideas, I stubbornly hit archive again. Literally didn’t do anything else. And that time, it worked.

What is going on here?


That is in the Run Script setting of the AppStore config.
It is removing the 32bit architecture from the fmodex.dylib it copied into the app bundle.

It might be that fmodex.dylib doesn’t get copied over every time you archive, so then its calling the function on a dylib that doesn’t need the function called.

We could probably pipe the error so that it doesn’t break a build as it shouldn’t be a fatal error.

If it happens again you can do a clean then build and it should work fine again.

ok, thanks, it is good to understand a little better what is going on there.

I’ve been wondering, might it be triggered by my stone age interwebs connection failing? I’ve noticed there seems to be some correlation.

oh no. back here again, just one month later

I’ve done some updates to my code, and trying to re-archive. Every time I now get the fmodex.dylib error:

fatal error: lipo: -remove i386 specified but fat file: /Users/smcelhinney/Library/Developer/Xcode/DerivedData/isovist_2-3-dsvcezruodqdgeenfpgfwbtkgcgs/Build/Intermediates.noindex/ArchiveIntermediates/isovist_2-3/InstallationBuildProductsLocation/Applications// does not contain that architecture

trying to clean and hit archive again now no longer resolves the problem. Can someone help?


If I remove the following from the build scripts:

# Strip 32bit from fmod dylib
lipo -remove i386 "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Contents/Frameworks/libfmodex.dylib" -o "${TARGET_BUILD_DIR}/${PRODUCT_NAME}.app/Contents/Frameworks/libfmodex.dylib" 

then a different fail occurs, as follows:

Stripping invalid archs '/Users/smcelhinney/Library/Developer/Xcode/DerivedData/isovist_2-3-dsvcezruodqdgeenfpgfwbtkgcgs/Build/Intermediates.noindex/ArchiveIntermediates/isovist_2-3/InstallationBuildProductsLocation/Applications//'
Signing '/Users/smcelhinney/Library/Developer/Xcode/DerivedData/isovist_2-3-dsvcezruodqdgeenfpgfwbtkgcgs/Build/Intermediates.noindex/ArchiveIntermediates/isovist_2-3/InstallationBuildProductsLocation/Applications//'
/Users/smcelhinney/Library/Developer/Xcode/DerivedData/isovist_2-3-dsvcezruodqdgeenfpgfwbtkgcgs/Build/Intermediates.noindex/ArchiveIntermediates/isovist_2-3/InstallationBuildProductsLocation/Applications// replacing existing signature
/Users/smcelhinney/Library/Developer/Xcode/DerivedData/isovist_2-3-dsvcezruodqdgeenfpgfwbtkgcgs/Build/Intermediates.noindex/ArchiveIntermediates/isovist_2-3/InstallationBuildProductsLocation/Applications// errSecInternalComponent
Failed to sign '/Users/smcelhinney/Library/Developer/Xcode/DerivedData/isovist_2-3-dsvcezruodqdgeenfpgfwbtkgcgs/Build/Intermediates.noindex/ArchiveIntermediates/isovist_2-3/InstallationBuildProductsLocation/Applications//'.
Command /bin/sh failed with exit code 1

this is teeth grindingly frustrating :sob:

Can anyone help me out here? I’m totally stuck, can’t find any way forward. Even my old version of the project won’t archive and calls the same error, which suggests it is an Xcode update related issue? I’m on v11.3.1…


Edit !-Solution-!
Oh boy. This one is a corker. I found the solution here, explainer follows…

The key point - a week ago my work machine forced a change of my user login password. It does so every few months, and this is never smooth; it always causes some form of issue in the keychain. Normally screws all of my logins for a couple of weeks.

What I didn’t realise is that when I was hitting archive, Xcode was trying to access the developer certificate accounts, entering the wrong password, and (I think), silently failing. Cue an error that seems a simple straightforward signing issue, right? d’oh.

So, to solve;

  • go to keychain,
  • lock all keychains,
  • clean and re-hit archive.

Yup, really that simple - I spent two hours getting nowhere and that’s the solution. This time round, Xcode asks for the user password about five times (tedious) but eventually gets over its multi-personality identity issues and we are through to the organiser screen. Success, right? (well, maybe… I’m waiting for the package to upload to the App Store now. Sigh).

I never ever thought I’d say this, but it has become one helluva lot quicker and easier releasing apps via Windoze and VS than via OSX now. Such a shame.

Hope this rescues someone else/saves them time in the future.

just a note the lipo issue is fixed here in the patch-release branch.

Brill, thanks!

Another quick note, I mentioned above that I seem to sometimes get these errors called when my internet connection stalls; I’m pretty sure this is the same as the silent password fail (i.e. XCode tries to access my Apple account, can’t, and so calls a superficially different error)

Just in case anyone else is reading through this, it is something worth checking!