macOS Sequoia makes it more difficult to open non-notarized apps

Targets macOS
1

With macOS Sequoia, apps without notarization can no longer be opened by right-clicking on the app icon.

This is a fundamental necessity.
I would like to point out here, although often discussed, that you pay 399 dollars a year for the desktop version and it is not possible to create a ‘ready-made app’ without restrictions.
The situation is not really solved with ‘App Wrapper’ either.
For me, the responsibility clearly lies with Xojo.

2 Likes
2

What are you expecting Xojo to do here?

3

I expect Xojo to provide a way to notarize macOS apps. Either through a function via software or a guide that shows step by step how to notarize the apps.

1 Like
4

https://documentation.xojo.com/topics/application_deployment/apple_requirements/signing_your_mac_application.html#topics-application-deployment-apple-requirements-signing-your-mac-application-code-signing-your-app

5

Why not?

1 Like
6

You can do that yourself.
Here is an example project: GitHub: jo-tools/xojo2dmg.

2 Likes
7

Neither VSCode, Eclipse, CLion, NetBeans, IntelliJ, PyCharm, QT Creator, not even the discontinued Visual Studio for Mac offer a ui for notarization. With most development environments, free and paid, you must notarize yourself via CLI. Xcode is the only major IDE I know of that has a GUI for notarization, and even that one is somewhat convoluted imho.

Fwiw, app wrapper has solved notarization completely for me. If you use its provided script in your build step you don’t even have to think about it. You just build, and you end up with a ready-to-distribute file in just a few minutes.

I guess my point is that Xojo is in-line with industry standards here. While I absolutely detest Apple’s mandatory signing+notarization and think it should not exist, that’s a different issue altogether. This is a distribution issue and not a compilation/language one, so it’s arguably outside of Xojo’s purview, in the same way that Xojo should not be responsible for creating a .dmg or .pkg or Windows .msi for you.

While I have no doubt the Xojo engineers could put together a UI for Apple’s notarization (the process is relatively simple when you read up on it), development resources are better allocated to the core language and its features and not to Sherlocking a $50 third-party app by a member of their own community.

4 Likes
8

Apps are notarised by Apple, not Xojo or anyone else… The process involves sending the app to Apple, who check it and then list it in their database as clean (or not, if it isn’t). Then, the first time an app runs on a Mac, the OS asks Apple about the app, who tell teh OS whether it has been notarised or not.

AppWrapper makes the notarisation process quite easy. It’s meaningless to suggest that Xojo should be doing it.

2 Likes
9

Thank you for your answers.
Thanks for the reference to xojo2dmg.
Unfortunately, I can’t find all the answers correctly.
If you make an iOS app in Xojo it is also possible. Why shouldn’t it be possible with a macOS app?
I have been programming with XOJO (Realbasic) since 1998 and with Xcode since 2010.
The comparison with development environments from the Windows area is silly.
Is the future of AppWrapper secure?

1 Like
10

Could be because all iOS apps have to go via the App Store, which includes notarisation as a step in the process… macOS apps don’t. Either way, it’s Apple doing the notarisation.

1 Like
11

Here’s the gist of the process. Make sure your app is signed and zip up your app bundle. Run the following terminal command (requires xcode to be installed):

xcrun altool --notarize-app --primary-bundle-id "com.yourcompany.yourapp" --username "your-apple-id" --password "app-specific-password" --file /path/to/YourApp.zip

It will reply with a UUID that you should save for later. Apple will take some time to scan the file for viruses and process the notarization. You can check the status of your notarization request by running:

xcrun altool --notarization-info "RequestUUID" --username "your-apple-id" --password "app-specific-password"

Once it’s successful, you staple the notarization ticket to your app with:

xcrun stapler staple /path/to/YourApp.app

Then it is ready for distribution. If you want to verify it, run:

spctl -a -vv /path/to/YourApp.app

It should say “accepted” if everything is correct.

Fairly trivial to do manually but if you push a lot of apps or updates it can get tedious, which is why App Wrapper comes in so handy.

12

It should be pointed out that notarization requires you to codesign your apps with the hardened runtime option set. When you sign, you’ll need to add this flag.

--options=runtime

1 Like
13

That’s deprecated. Use notarytool instead. It’s even easier with that.

See e.g. Use notarytool instead of altool by jo-tools · Pull Request #12 · jo-tools/xojo2dmg · GitHub

1 Like
14

Especially since Apple’s rules change “often”.

1 Like
15

Thanks for the tips.
Does anyone have any experience with notarytool or are there any examples?

16

Go to your Apple ID online and create an “app specific password” and name it something like Apple Notarization so you don’t forget what it’s for.

Once you have a codesigned package, notarization is pretty easy

xcrun notarytool notarize --apple-id <your Apple ID> --password <notarize password> --team-id <your Apple team id> --wait <path to item to notarize>

This method will return a Notary ID and a status

If it fails, you can get a log of everything it found like this:

xcrun notarytool log --apple-id <your Apple ID> --password <notarize password> --team-id <your Apple team id> <notary id>

If it succeeds, you need to staple the response

xcrun stapler staple <path to item being notarized>

That’s the basics of it. Now, most likely on your first attempt, you’re going to get errors about signing. As I mentioned above, make sure you use the --options=runtime and also the --timestamp flags when you sign your app.

17

I have a suspicion that they’re also going to finally retire the --deep option of the codesign command. Call me paranoid, but this type of hardening was done in iOS right when --deep was disallowed there too. That will mean that if you are manually signing your apps, you will need to do the inner parts first and then sign the outer part. Apple has been talking about the correct structure since they deprecated --deep so you’ll probably need to do this for Xojo apps. Everything in these folders should be signed individually, followed by the app itself.

App/Contents/MacOS/
App/Contents/Frameworks/ 
App/Contents/Plugins/
App/Contents/Helpers/
App

There are some rules about where executable code can be located and you can read more of that by typing man codesign in a terminal window.

18

This greatly reminds about how a secured APFS boot volume is signed.

19

Many thanks for the tips. Then I can start my first attempts.

20

Lots of mixed opinions and some deprecated code.

Xojo should maintain an official “how to” with several guides like:

  1. Easy steps to produce a macOS self published app.
    1.1 Introduction
    1.2 Steps
    1.3 Troubleshooting
    1.3.1 Usual troubles
    1.3.2 Notarizing notes
    1.3.3 Codesigning notes

  2. Easy steps to produce and publish a macOS app in the App Store
    2.1 Introduction
    2.2 Steps
    2.3 Troubleshooting
    2.3.1 Usual troubles
    2.3.2 Notarizing notes
    2.3.3 Codesigning notes

etc.

I don’t know the best format, but the current “omission” is a trouble.

Other IDEs have it in some format, not the best one, but much better than letting the users to fight to discover by themselves like:

image
image1215×775 44.3 KB

Some even have some “Wizard tool” to help.

3 Likes