Friday, January 17, 2020 [Tweets] [Favorites]

App Movement Monitoring

Daniel Jalkut:

Essentially, when a Mac app is launched, the location of that app on disk is saved, and used repeatedly whenever an internal component needs to located. The dynamic nature of resource loading in Mac apps means that these components are not typically loaded until they are need. For example, if you never show the Preferences window in a typical Mac app, the resources that define that window will never be loaded.

If, on the other hand, you decide to show the Preferences window, but you’ve moved the app since it was launched, things have a tendency to go haywire. The app will go searching for its Preferences resources in the location on disk where they used to be, and it won’t find anything.

Why doesn’t Cocoa use file reference URLs to delay resolving the path until it’s actually needed, like it does for the document architecture? Or at least try to prevent users from moving apps that are open?

Paul Kafasis:

To avoid these issues, the Finder already works to avoid multiple types of changes to running applications. For instance, if you try to delete an application that’s open, the Finder stops you[…] As well, if you attempt to rename an open application, the Finder will warn against it[…] However, while any Unix geek can tell you that a rename is really just a move by another name, the Finder does nothing to stop you from actually moving the app.

Paul Kafasis:

I discussed this issue with Daniel and Brent, and provided them with the code we’d been using to watch for this issue. This actually led us to make several changes and tweaks, and a simplified implementation of this “Application Moved” watcher can be found below[…]

RSAppMovementMonitor:

RSAppMovementMonitor handles the nuanced details of monitoring for the movement, prompting the user, and relaunching the app[…]

This is more complicated than it seems, due to quarantine, translocation, sandboxing, and need to preload any localized strings before the app is moved.

The latter was surprising to me, but I recently ran into a similar issue when updating my apps to en.lproj instead of English.lproj.

Previously:

Comments

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment