Documentation on dependencies between apps and data files

help, anyone?

I have an app that was sharing the same package ID as its demo

What do you mean by “package ID” in this context?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The CFBundleIdentifier

Is your app sandboxed?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Not for the moment

Both the demo and the app use a distinct data folder in /Library/Application Support. That's what gets sometimes messed up when we delete one or the other.

But it does use a Hardened runtime

So:

• You have two apps, A and B, that use the same bundle ID.

• Each stores its data in a separate directory underneath /Library/Application Support, so /Library/Application Support/A, and /Library/Application Support/B.

• The user has both apps installed.

• The user deletes B.

• You expect that to delete /Library/Application Support/B.

• But it’s also deleting /Library/Application Support/A.

Is that right?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Yes, or some subfolders of /Library/Application Support/A. It's not very clear, but I see some subfolders disappear.

That's why knowing the exact rules Apple applies to apps and their data folders would be very helpful.

Thanks for confirming.

That's why knowing the exact rules Apple applies to apps and their data folders would be very helpful.

So, yeah, that’s super easy to explain: macOS does not delete the directories associated with an app when you delete the app.

First, let’s consider a sandboxed app. In this case macOS knows the relationship between the app and its container but we choose not to delete the container when you delete the app. That’s because macOS allows apps to be stored outside the Applications folder, so we can’t be sure whether the app you’re deleting is the only copy of that app. Consider this sequence:

1. The user is running out of disk space on their boot volume.

2. So they copy a big app from Applications to some other volume.

3. Then they temporarily unmount the other volume.

4. And finally they delete the copy from Applications.

If we deleted the app’s container at step 4, that’d be bad.

Second, in the non-sandboxed case, your app can create directories in a wide variety of locations, including /Library/Application Support, and macOS isn’t able to track that relationship. It’s just not possible for it to clean up in that case [1].

In conclusion, I’m not sure what’s deleting this stuff but I’m quite sure it’s not macOS deleting it in response to your app being deleted.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Well, on the most recent systems we have a providence mechanism, which might make it theoretically possible for us to do that in the future, but that’s unlikely to fly for the same reason we don’t clean up after a sandboxed app.

Ok, so you are positive that when you delete a non-sandboxed app, MacOS does not delete/update any of its folders/files in Application Support?

In that case, the problem must come from Packages (the installer software). Because I can reproduce the error at wish. If I install the software A, with its data in /Library/Application Support/A, and then install the demo B:

a) Applications only contains B (deleted A)

b) only the new/updated files in /Library/Application Support/A remain, all others are deleted (so if no file updated, the whole folder is removed)

c) a new /Library/Application Support/B folder is added

So what could happen is that Packages keeps a list of the files/folders it has added for a specific bundle ID. When a new installer with that bundle ID is executed, it will delete the previous files/folders and install the new ones. What do you think?

I'll try with using unique bundle IDs for both software and installer, see how that works.

Ok, I think I found the reason. It seems this happens when the Packages installer uses the same identifier as another one. In that case, it seems to remove all files/folders previously installed before copying the new ones.

It does that using the receipts that get created when the installer runs. You can view these receipts using the following command:

pkgutil --files <package id>

Knowing this, I feel more confident to create new installers for updating current apps.

Thanks a lot for taking the time to assist me.