Oh, it’s not hard. The source code is pretty short and easy to follow. It’s just a question of making the effort.
I already have a solution, using a separate helper app written in AppleScript, but it turns out that what LetsMove does is safer - Apple apparently has already implemented a fix to make the way LetsMove work in the latest 10.12 beta that didn’t work work in the first beta. So I rather rely on something that mimicks that exactly instead of rolling my own, which may more likely got broken by Apple at a whim.
[code] dim myapp as FolderItem = app.ExecutableFile.parent.Parent.Parent
dim destination as FolderItem = SpecialFolder.Applications
The app is signed, and it moves very nicely to Applications. This would not fly with a sandboxed app, though. If the app was to reside on a read-only DMG, I believe it would be necessary to simply copy it.
Downloaded it through Safari within macOS, opened it right in the spring menu from Downloads in the dock, and guess what ? It actually copied itself into Applications. It runs very nicely from Applications.
Should be noted that it took only about five seconds to open from the download. And only 3-4 when in the Applications folder (I tend to count the bounces).
Okay, Michel, you’re right. I was wrong because I incorrectly assumed that Xojo’s Move command would only move - but it does apparently revert to Copy if the Move fails. Because that’s the issue - A translocated app can’t move itself because the temp folder in which is resides it read-only.
In a way, though, your solution is not complete, because you leave the original version in the Downloads folder, which should not happen - it should be cleared. But again, that you cannot do with your approach because you are not able to find your original app because you cannot get the original path from where it was launched. So, if I’d download to a different folder or if it would get renamed when extracting, you’d not be able to find that original when the app runs translocated. That’s the basis of this thread - to implement a solution that does this right.
Michel, which path do you think you get when you call App.ExecutableFile when your app runs for the first time, right after unzipping, e.g. from the /Users/you/Downloads folder? You do realize it’s not /Users/you/Downloads/Your.app, right?
It’s taken me a few hours, but I’ve got now a working Xojo version of what “LetsMove” (https://github.com/potionfactory/LetsMove) does, along with handling the cases where the Apps folder is not writable and an Admin login is required. It also manages to remove the source app from the Download folder, even on 10.12 Sierra.
The only thing it doesn’t do is to specially handle apps started from a dmg volume, i.e. it does not unmount and trash the dmg after the successful move. Meaning that this code is mainly made for apps delivered as .zip files, solving issues we’ll encounter on Sierra due to apps runnning translocated when started from the Downloads folder.