App does not start anymore on macOS Sequoia (due to sandbox restrictions?)

[Alexander Halser 32]

I have a Delphi FMX app that runs fine on anything from macOS Big Sure to Sonoma. Just on the latest Sequoia release, it doesn't start. It seems, that this has to do with new sandbox restrictions. Any ideas what to change in the entitlements to make it run on Sequoia? The app is signed and notarized, compiled with Delphi 11.3.

 

This is the crash log I get on Sequoia (from a different mac, not my development machine):

2024-11-07 08:43:02.786318 <Notice>: Last log repeated 1 times
2024-11-07 08:43:02.785852 (gui/501/application.SnipSVG.16305011.16305018) <Notice>: internal event: WILL_SPAWN, code = 0
2024-11-07 08:43:02.785996 (gui/501/application.SnipSVG.16305011.16305018) <Notice>: service state: spawn scheduled
2024-11-07 08:43:02.785999 (gui/501/application.SnipSVG.16305011.16305018) <Notice>: service state: spawning
2024-11-07 08:43:02.786053 <Notice>: Coalition Cache Hit: app<application.SnipSVG.16305011.16305018(501)> [985]
2024-11-07 08:43:02.786105 (gui/501/application.SnipSVG.16305011.16305018) <Notice>: launching: launch job demand
2024-11-07 08:43:02.787814 (gui/501/application.SnipSVG.16305011.16305018 [1131]) <Notice>: xpcproxy spawned with pid 1131
2024-11-07 08:43:02.787872 (gui/501/application.SnipSVG.16305011.16305018 [1131]) <Notice>: internal event: SPAWNED, code = 0
2024-11-07 08:43:02.787875 (gui/501/application.SnipSVG.16305011.16305018 [1131]) <Notice>: service state: xpcproxy
2024-11-07 08:43:02.787956 (gui/501/application.SnipSVG.16305011.16305018 [1131]) <Notice>: internal event: SOURCE_ATTACH, code = 0
2024-11-07 08:43:02.813870 (gui/501/application.SnipSVG.16305011.16305018 [1131]) <Notice>: service state: running
2024-11-07 08:43:02.813881 (gui/501/application.SnipSVG.16305011.16305018 [1131]) <Notice>: internal event: INIT, code = 0
2024-11-07 08:43:02.813884 (gui/501/application.SnipSVG.16305011.16305018 [1131]) <Notice>: job state = running
2024-11-07 08:43:02.814097 (gui/501/application.SnipSVG.16305011.16305018 [1131]) <Notice>: Successfully spawned SnipSVG[1131] because launch job demand
2024-11-07 08:43:02.845832 (pid/1131 [SnipSVG]) <Notice>: uncorking exec source upfront
2024-11-07 08:43:02.845882 (pid/1131 [SnipSVG]) <Notice>: created
2024-11-07 08:43:03.355264 (pid/1131 [SnipSVG]) <Notice>: shutting down
2024-11-07 08:43:03.355286 (pid/1131 [SnipSVG]) <Notice>: cleaning up
2024-11-07 08:43:03.355364 (gui/501/application.SnipSVG.16305011.16305018 [1131]) <Notice>: exited due to exit(217), ran for 567ms
2024-11-07 08:43:03.355370 (gui/501/application.SnipSVG.16305011.16305018 [1131]) <Notice>: service state: exited
2024-11-07 08:43:03.355381 (gui/501/application.SnipSVG.16305011.16305018 [1131]) <Notice>: internal event: EXITED, code = 0
2024-11-07 08:43:03.355386 (gui/501/application.SnipSVG.16305011.16305018 [1131]) <Notice>: job state = exited
...

 

My entitlements list:

 

[salvadordf 40]

Perhaps it needs to be signed. Read this article.

[Alexander Halser 32]

Signed and notarized, as explained above. Shouldn't that be sufficient?

[Dave Nottage 624]

14 minutes ago, Alexander Halser said:

Signed and notarized, as explained above. Shouldn't that be sufficient?

Yes, it should be. My Mosco app is a signed and notarized app, and has these entitlements:

 

It starts OK for me on macOS 15.1, but is built with Delphi 12.2. Not sure whether that might be relevant?

Edited November 7, 2024 by Dave Nottage

[Alexander Halser 32]

Problem solved. It wasn't the permissions, but a native NSToolbar control. This toolbar contained two NSToolbarSidebarTrackingSeparator items, which were used to create a vertical separator bar on the toolbar. While this had worked before, it's illegal for macOS 15. Only one of this item type is permitted.