App Packaging: bundle format unrecognized, invalid, or unsuitable

I am trying to package a Filemaker 18 Runtime app.

A week ago, I managed to get 90% of the way towards doing as much, using MS Copilot as a guide.

Unfortunately, due to my confusion over the landing stage files, I decided to start the process from scratch.

This time, I fell at the first stage:

Code Signing my .app Bundle.

The Terminal command:

codesign --deep --force --verify --verbose \ --sign "Developer ID Application: ME (V********)" \ "/Users/Me/Documents/Apps/MyApp/Runtime/MyApp/My App.app"

Returned the error:

/Users/Me/Documents/Apps/MyApp/Runtime/MyApp/My App.app: bundle format unrecognized, invalid, or unsuitable In subcomponent: /Users/Me/Documents/Apps/MyApp/Runtime/MyApp/My App.app/Contents/Frameworks/FMWrapper.framework

No matter how many separate elements within the bundle I sign, I encounter the same error message.

A few days ago, the identical command worked first time.

I would be obliged for any help you can provide.

Thanks.

Answered by DTS Engineer in 864776022

I recommend that you seek help from your third-party vendor here. It seems likely that they’ll have a well-trodden path that you can follow for this.

If you decide to debug this yourself, I have some general hints. To start, dont use --deep when signing code. For an explanation as to why not, see --deep Considered Harmful.

Rather, sign each code item separately, from the inside out. Creating distribution-signed code for macOS explains that process in detail.

I think that’ll reveal that there’s an issue with FMWrapper.framework. If so, that’s good, because gives you something to focus on.

One of the most common causes of weird problems signing frameworks is that folks copy the framework without preserving symlinks. You should check that’s not the case here.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I recommend that you seek help from your third-party vendor here. It seems likely that they’ll have a well-trodden path that you can follow for this.

If you decide to debug this yourself, I have some general hints. To start, dont use --deep when signing code. For an explanation as to why not, see --deep Considered Harmful.

Rather, sign each code item separately, from the inside out. Creating distribution-signed code for macOS explains that process in detail.

I think that’ll reveal that there’s an issue with FMWrapper.framework. If so, that’s good, because gives you something to focus on.

One of the most common causes of weird problems signing frameworks is that folks copy the framework without preserving symlinks. You should check that’s not the case here.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Accepted Answer

Quinn,

Thank you very much for the prompt and detailed reply.

Do you happen to know if the problem might be caused by a plugin that is no longer being used but may still be referenced within my app?

I ask because the only difference between the first version of my app (that sailed through to the launch file stage) and the one that fell at the first hurdle is that I added a plugin to the latter; then removed it.

I tried removing all plugins from my runtime, and signing it again, but it made no difference.

Thanks again.

Do you happen to know if the problem might be caused by a plugin … ?

That seems unlikely, but I don’t know enough about this third-party tooling [1] to offer definitive answers.

Were you able to identify the code items within MyApp.app? How are they placed within MyApp.app?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] While FileMaker is built by Claris which is owned by Apple, DTS treats them as third-party developers.

App Packaging: bundle format unrecognized, invalid, or unsuitable
 
 
Q