I don’t think so - the dylib hijacking and Translocator is all meant to prevent file access OUTSIDE of the app’s bundle, but relative to it. The article explains the reasoning behind that: Everything inside the app bundle is verified using the signature, but things outside are not. The Xojo frameworks are inside, so that’s not something Apple has to worry about.
App Wrapper can use Apple codesign. You may want to try that option (click on the gear right of your certificate name).
Michel, see my comment above.
Unless … maybe we’re all doing the codesigning wrong, not signing everything, and that’s what 10.12’s Gatekeeper trips over? I remember discussions in the past about using the various signing options right or wrong. E.g, I am currently signing every dylib file individually first, then sign the entire app in the end, all cmds using “codesign -f -s …”. I’ve seen examples that do this differently, I believe. Maybe there’s an option we’re forgetting.
OK, then we are off to zero again. Why are Xojo compiled apps slow on launching? And why are Xojo compiled apps very slow in verifying the first time you launch them after downloaded with Safari?
In Appwrapper you can enable ‘Use same identifier for all components’. This makes sure everything is codesigned again (including all Xojo dylibs).
That’s incorrect. If a Xojo app is not quarantined, it launches fast. I explained that already.
I guess the verification process happens also in the Translocated app. And it should be clear by now that the Translocation is the part that’s slowing everything down.
Yes, but why does it only happen with Xojo apps?
I noticed something else which isn’t on OSX10.11 or earlier:
There is a process called logd that consumes a LOT of CPU cycles every time you launch an app. It is remarkable when launching a X-code compiled app, it has a short high CPU usages. Launching a Xojo app it peaks for a pretty long time (up 60% CPU on my MBPr i7).
Sometimes you also see a spinlog process. If this shows, there is always a .spin log to be found. That too only happens with Xojo apps.
BTW googling for logd or spinlog does not reveal anything. Those seems to be two new macOS processes.
That’s the new log daemin. The release notes have an enitire page on that. Not related to this issue, I am sure
OK, thanks. But it does consumes a LOT of CPU resources (and sometimes for a very long time - up to 30 seconds bogging a i7). 
Some more info (I know … . I know … )
It seems the logd process has a HUGE impact on loading Xojo apps. And when I say huge I mean H U G E.
I even found a way to launch Xojo apps < 1 secs as it should. How? … well just wait until the logd is finished. If it does not consumes any CPU, and then start a Xojo app, it launches about immediately.
Now the problem is … the logd process is using CPU load at random so it seems. Sometimes it peaks and eats up 70% and more, it stops doing that and then after some seconds … it starts again using CPU load.
Even waiting for 30 minutes doing nothing, it keeps peaking, dropping, peaking, …
Every time it hits the CPU, Xojo apps (yes,only Xojo apps) launch very slow. If the peak is gone and you launch a Xojo app, it is launched < 1 secs.
Still odd that non Xojo apps always launch < 1 sec, even if the logd is peaking like hell.
Noteworthy: the spinlog process also pops up at random times. If this happens, a .spin log is made. Looking at those logs it is not related to any Xojo app I tried in macOS.
@Michel:
You say you do not see this slow launching. Can you take a peek at the Activity Monitor and see if logd also has heavy CPU load?
It would be very useful to log a bug report in Feedback with mention of the most important discoveries, for xojo to have a look. This quarantine thing is intriguing in particular.
With some luck, they will have this covered when Sierra becomes fully public.
True. And is worrying too. Hopefully this is a beta issue only. Otherwise, we are in for some heavy complains of our users.
[quote=272525:@Christoph De Vocht]@Michel:
You say you do not see this slow launching. Can you take a peek at the Activity Monitor and see if logd also has heavy CPU load?[/quote]
Next time I boot Sierra which I have not yet installed on my work machine, I shall verify that.
Yesterday I stated in t’other thread that moving the application to the Applications folder helps, not on the first launch there, but on subsequent launches. Today when I tried (I haven’t moved it since yesterday so it’s still in the Applications folder), the first launch took 10+ second, while the second, third and fourth took less than a second.
I will update my bug report on Apple, because this certainly goes against their documentation.
Also want to point out that Apple have already responded and are investigating; I have to give them credit where it’s due.
In can confirm what I was writing above: If you monitor the logd process and wait until it does not hog the CPU, start any Xojo App and it launches <1 sec. If it peaks, any Xojo app takes a long time to launch.
In other word, I can now reliable reproduce the issue.
Definitely something to watch in future macOS betas.
Nice. In which way? Did you contact them directly, or are you at WWDC?
Oh - through the bug report you sent, apparently. Could you please put the bug report up here for everyone to follow? Open Radar
I contacted them via bugreporter.apple.com, I wish I could have got a ticket to WWDC. I would have given some of the engineers a piece of my mind, and probably been thrown out… Ha.
That Open Radar thing isn’t connected to the Apple Radar system, so it doesn’t get updated when Apple update the bug report right.
Not directly related to this thread, but this is it for machines without an SSD : Sierra is unusable on a regular hard drive. It reaches for the drive for most everything. Worse than Windows with insufficient memory !