Problems/Limitations when app is Notarised for macOS10.14

[ChristopheDV]

I have started a new thread because it seems when you notarise your apps for macOS10.14, it can break some things. Oh boy …

These are the two things I noticed - more may follow.

- Creating a declare is more piccy. For example you can not use libobjc.a.dylib anymore.You need to use Cocoa instead.

- The below code will not work anymore. It’s code to reveal a file in the Finder.

dim a as AppleEvent = New AppleEvent("misc", "slct", "com.apple.finder") a.FolderItemParam("----") = f If a.send then a = New AppleEvent("misc", "actv", "com.apple.finder") If a.send then //success Else //activate failed End if Else //select failed End if

Maybe it needs an entitlement like in a Sandboxed app? Will do some test later.
BTW this script does work when I do not notarise the app. So it has nothing todo with the new way of Mojave dealing with permissions.

- AppleScripts do not work at all (I use AppleScriptMBS).
The AppleScripts I tried do refer to Finder. So maybe there is a new entitlement needed to use the Finder ?

[Jean-Yves_Pochez]

the user must accept your app to run applescripts. like the location before 10.14

[Greg_O_Lone]

@410851:@Christoph De Vocht

Creating a declare is more piccy. For example you can not use libobjc.a.dylib anymore.You need to use Cocoa instead.

It would be even better if you specified the actual framework that you are using. If the function you are making exists in more than one place, the Library is used to call the right one.

[Sam_Rowlands]

In the capabilities pane of App Wrapper, the first option at the top has the ability to attach entitlements without Sandboxing your application. Give that a try.

[ChristopheDV]

@410852:@Jean-Yves Pochez

the user must accept your app to run applescripts. like the location before 10.14

As I wrote, it has nothing todo with ‘permissions’. I know the user has to approve this in Mojave. It works fine when not using –option runtime when code signing.

[ChristopheDV]

@410872:@Sam Rowlands

In the capabilities pane of App Wrapper, the first option at the top has the ability to attach entitlements without Sandboxing your application. Give that a try.

Yes, I know that. But as far as I know, it is not possible to use AppWrapper for Notarizing. (the –option runtime is not available).

[Beatrix_Willius]

A replacement of the AppleScript for the Finder was mentioned a couple of times. Search for NSWorkspaceMBS.

[ChristopheDV]

@410863:@Greg O'Lone

It would be even better if you specified the actual framework that you are using. If the function you are making exists in more than one place, the Library is used to call the right one.

Yes, this is correct. But it doesn’t seems to work that way when your app is Notarized.
For example:

Declare Function obj_allocateClassPair Lib “libobjc.a.dylib” (superclass as Ptr, name as Cstring, extraBytes as Integer) As ptr

This works fine. Even when you codesign your app.
But when you codesign with –option runtime (needed for notarising) it does not work and throws an error:

An exception of class
FunctionNotFoundException was not
handled. The application must shut down.

Replacing it with the below code, it works fine.

Declare Function obj_allocateClassPair Lib “Cocoa” (superclass as Ptr, name as Cstring, extraBytes as Integer) As ptr

[ChristopheDV]

@410893:@Beatrix Willius

A replacement of the AppleScript for the Finder was mentioned a couple of times. Search for NSWorkspaceMBS.

Yes, that’s true. Still, it is important to know it does not work anymore when your app has been notarised. That’s what this thread is all about: LIMITATIONS WHEN YOUR APP IS NOTARISED.

And for what’s worth: It is not possible with NSWorkSpace to show a file in the Finder. That’s what the above AppleEvent code does.

[Sam_Rowlands]

@410895:@Christoph De Vocht

And for what’s worth: It is not possible with NSWorkSpace to show a file in the Finder. That’s what the above AppleEvent code does.

This is the function, I use it (but not with Notorized apps) activateFileViewerSelectingURLs: | Apple Developer Documentation

Here an excerpt from the documentation on the “–option runtime” flag (which requires macOS 10.13.6 or Mojave).

On macOS versions >= 10.14.0, opts signed processes into a hardened runtime environment which includes runtime code signing enforcement, library validation, hard, kill, and debugging restrictions. These restrictions can be selectively relaxed via entitlements. Note: macOS versions older than 10.14.0 ignore the presence of this flag in the code signature.

So any declares MUST now access the framework (not dylibs directly) that Apple declares is the most appropriate.
Sadly it now means that macOS 10.13.6 or newer must be used to deploy apps, and as I’m halfway through a project there isn’t a hope in hell that I’ll update my production machine to High Sierra or Mojave (until at least 10.14.3 or even 10.14.6), see how it goes. So looks like I’ll be using a second machine to deploy apps.

[Beatrix_Willius]

And for what’s worth: It is not possible with NSWorkSpace to show a file in the Finder. That’s what the above AppleEvent code does.

Sure is this possible:

NSWorkspaceMBS.selectFile(file)

[ChristopheDV]

[quote=410900:@Beatrix Willius]Sure is this possible:

NSWorkspaceMBS.selectFile(file)

Mea Culpa.

Still, I need Applescript - which I currently cannot get to work with Notarising.

[Beatrix_Willius]

I think that Apple doesn’t want us to script the Finder anymore. Have you tried with an AppleScript for another app like Mail?

[Antonio_Rinaldi]

@410910:@Beatrix Willius

I think that Apple doesn’t want us to script the Finder anymore. Have you tried with an AppleScript for another app like Mail?

No, it’s extended to all the AppleScript. There is an example in the WWDC presentation that shows that trying to control Mail will show an alert to the user.

[ChristopheDV]

@410911:@Antonio Rinaldi

No, it’s extended to all the AppleScript. There is an example in the WWDC presentation that shows that trying to control Mail will show an alert to the user.

No, thats another thing. Mojave does indeed ask for permission when you use for example the Finder with Applescript. We all are aware of this now.

The above issue is that it just doesnt work at all when the app is notarized. It is possible we need to use an entitlement for this but I have no clue which.

[ChristopheDV]

@410910:@Beatrix Willius

I think that Apple doesn’t want us to script the Finder anymore. Have you tried with an AppleScript for another app like Mail?

Yes, for example removing a file with Applescript does not work when the app is notarized.

[Antonio_Rinaldi]

I see.
Probably we have to test with different hardened runtime entitlements

[Sam_Rowlands]

The writing has been on the wall for Apple Script for a long time; after all iOS doesn’t have it, so why should the macOS?

My advice is to find API to replace what you need (if possible), so what do you script the finder to do.

• Show a file in the Finder, is covered with NSWorkspace API.
• Removing a file, see one of my xDevMag articles where I write up how to delete files in the macOS, with the option to move them to the trash, so the user can recover them. I forget which edition.

[ChristopheDV]

[quote=410917:@Sam Rowlands]

• Removing a file, see one of my xDevMag articles where I write up how to delete files in the macOS, with the option to move them to the trash, so the user can recover them. I forget which edition.[/quote]

As far as I know it is only possible to remove a file with the Finder AND keep the ‘Put Back’ feature enabled/working.
I have yet to find a different solution for this.

[Greg_O_Lone]

@410917:@Sam Rowlands

The writing has been on the wall for Apple Script for a long time; after all iOS doesn’t have it, so why should the macOS?

I’d agree with that except for the fact that Apple keeps adding things to the language. For instance, they added one for switching Dark Mode on and off in Mojave.