macOS 10.12 slow app start (when no longer quarantined and after reboots)

Not sure why the other thread on 10.12 was started here, but to keep the context, I’ll add mine here, too.
Since the first thread already got pretty long with several issues, I like to make this one particularly about the slow app launch times of Xojo-made apps.

Here’s what I observed:

When watching the launched Xojo app in Activity Monitor, I noticed that they’re using only very little CPU time the entire loading time, such as below 2%. Other apps made with Xcode use much more CPU.

So I wonder if something prevents the app from getting the full CPU time at launch. Maybe Xcode’s app runtime lib does set some flag early on that regulates this, and Xojo’s code is currently missing that.

Any ideas?

Oh, it’s getting much weirder:

When I launch my app (iClip) as built with 2014r3.3, then it takes a long time to launch. But when I build it with 2016r1.1, it launches fast. Can others confirm this?

Also, the slow launch seems to place the app into a weird temp directory - as my app updates the Login Items using AppleScript, it then uses a weird long path like this one

However, when I run iClip made with 2016, the path is the correct path.

So, it seems that OSX doesn’t like something about the older apps, putting them into some kind of temporary location while launching them, and that’s causing the slowdown.

But the good news is: 2016r1 helps. Let’s hope it stays that way :slight_smile:

Didn’t I read somewhere that unsigned apps appear to be started in a temp path? That was supposed to be a security measure. But I’d assume that both your versions are signed, correct?

Ah, good point!

So, I revoke my statement about 2016 fixing this!

Instead, it’s like this:

When I build the app on Mac #1 (running 10.10.5), and sign it there, and then copy a zipped version of the app to Mac #2 (running 10.12), then the app launches quickly, without going thru a validation check (that’s always been like that) and without using a tmp path.

But as soon as I upload the same zip to a web server and then download it from there using Safari, then the app will get quarantined, and at every launch (not just the first), it’ll launch slowly and in a tmp dir.

Damn.

Okay, Peter Maurer of ManyTricks pointed me to this:

App Translocation

That explains what’s going on.

However, the article then explains that moving the app would fix this behavior. However, it does not for me. Can others confirm this, or find that moving the unzipped app away from the Downloads folder makes the app launch fast again?

That’s what i was saying in the other thread. :slight_smile:

I think it has something to do with the Xojo framework is being verified each time you launch an Xojo compiled app.

What currently bothers me most is that, despite the findings of others, moving the unzipped app does not stop the Translocation from happening at launch.

Also, I’d expect that Apple provides a new Info.plist key to tell the OS that this app does not need this protection because it’s not loading anything from outside the app. We sure need such a flag.

Would it be possible to check if the parent folder of the app was read-only and alert the user they need to move the app to /Applications then?

[quote=272459:@Thomas Tempelmann]Okay, Peter Maurer of ManyTricks pointed me to this:
App Translocation [/quote]

I think this is another issue. In those cases the App just doesn’t start at all. What I have seen (and others) is Xojo apps are launching, but very slowly.
I tried moving it to another folder (as mentioned in the article) but it still launch slowly.

This article: http://lapcatsoftware.com/articles/app-translocation.html speaks if a signed DMG. Never heard of this. Didn’t know you can codesign a DMG too. Odd…

EDIT: I don’t think they mean DMG with ‘disk image’. :slight_smile:

Christoph, see https://eclecticlight.co/2016/06/16/macos-sierra-will-break-many-installers-and-updaters/ - that talks about signed DMGs:

Tim, moving the app supposedly helps, so you asking the user to move the app would be the right way. However, so far, even after moving the unzipped app, the app still seems to get translocated at launch.

The only way I could get this working (i.e. fast launch) was by removing the quarantine flag from the app, using sudo xattr -r -d com.apple.quarantine path/to/app

Jeff from Lap Cat Software has written two more follow-ups on the topics, find them all here: http://lapcatsoftware.com/articles/

I am sure Sam Rowlands will have a look at this new requirement.

Maybe the start of a workaround would be to check upon launch if the app is in /Applications, and if not display a MsgBox requesting to move it there and quit.

Well I read the move must be done in Finder, so I was thinking a modified version of that dialog you see in some newer apps that offers to move the app automatically. My question was more related to the procedure of checking if the parent is read only. Is that a thing you think we could pull of in Xojo reasonably? Is this the best way to check to see if we’ve been translocated?

All of this is horrible enough but still this doesn’t explain why only Xojo apps are so slow to start.

What are “flat-file packages” as mentioned in https://eclecticlight.co/2016/06/16/macos-sierra-will-break-many-installers-and-updaters/? Why wouldn’t bundle-style installer work for Sierra? These only load internal resources and not external ones.

It doesn’t matter if the app is in the Application Folder or not. It always launches slow.
Again, I would to say it only happens with Xojo compiled apps (and code signed with Appwrapper).

Installing any other app (read: compiled with Xcode) works fine and launched within < 1 sec.

Also noteworthy : downloading an Xojo compiled (signed with Appwrapper) takes an awful long time to ‘verify’ the first time.
Never seen that with Xcode compiled (and probable codesigned with Xcode).

Yes, thats what I wanted to say all the time. Maybe it is wrongly codesigned with Appwrapper? Maybe it is because the Xojo framework is triggering this issue?

Manually using the signing tools instead of using AppWrapper makes no difference, either. So it’s not AppWrapper’s fault.

This is an interesting phrase from the second article: “It was clear from the session that Apple is concerned not just with Wardle’s dylib hijacking but also with any resources loaded external to the app bundle”

This is eventually the same as the Xojo framework, not? If this is the case, we are in trouble.