Does user data survive when a macOS app replaces an iOS app on Mac?

We have an iOS app that's available on Apple silicon Macs via "iPhone and iPad Apps on Mac." We're planning to add a native macOS build under the same bundle ID.

Releasing the macOS build replaces the iOS app on the Mac App Store, and existing users are updated to it. What we can't find documented is what happens to their local data container at that moment.

1. Is the container preserved, and can the macOS app reach it?

An iOS app on Apple silicon keeps its data under ~/Library/Containers/. A native sandboxed Mac app expects ~/Library/Containers/<bundle-id>/Data/. Containers are also associated with the creating app's code signature, though both our builds would be re-signed by the App Store under the same team. So we can't tell whether the new app would inherit the old container or get a fresh one.

  • Does the replacement preserve the container, or remove it?
  • If preserved, does the macOS app — same bundle ID, same Team ID — get access to it? Is this a supported path?

2. Can this be tested before release?

We filed FB21861189 about TestFlight refusing the in-place upgrade — "To install the macOS version of this app on your Mac, first uninstall the iOS app." The response was this is expected in TestFlight.

The forced uninstall destroys the container, so TestFlight only ever shows the clean-install case. The path we need to test is the one we can't reach.

Is there a supported way to test the App Store replacement before general release?

3. If data doesn't carry over, what's the recommended bridge?

If so, we'll need to add a migration path to the iOS app before the Mac build ships.

We're aware of App Groups and have read App Groups: macOS vs iOS: Working Towards Harmony. What this post doesn't cover is whether an app group is an appropriate bridge for this scenario. If not, what would you recommend instead?

  1. Is the container preserved, and can the macOS app reach it?

To be perfectly honest, I don't know. Our documentation on exactly what/where/how containers behave has always been somewhat sparse, and the implementation crosses enough components that it's hard to be sure of exactly what will happen/work.

  1. Can this be tested before release?

I haven't tried this, but what I would try is something like this:

  1. Install one of the versions (macOS or iOS).

  2. Copy the app bundle "somewhere else", zip up[1] that copy, and delete both your copy and the app bundle inside /Applications/.

  3. Install the other.

  4. Uncompress the archive you made in #2, change the name (<app name> 2!.app) to prevent a name collision, then copy it back into /Applications/.

...and that should give you both app versions running on the same machine, which should let you see who is getting which container.

[1] The goal here is to preserve a copy of the app for “later” while also removing that app from the systems “view”, so the system doesn’t think it’s installed anymore. There are lots of ways to do that, but zipping the file is the easiest to explain.

We're aware of App Groups and have read App Groups: macOS vs iOS: Working Towards Harmony. What this post doesn't cover is whether an app group is an appropriate bridge for this scenario.

Yes, this is very reasonable use of App Groups. I'm not aware of it having been used for this EXACT case, but it's certainly been used to migrate data between apps when one app was replacing another.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Does user data survive when a macOS app replaces an iOS app on Mac?
 
 
Q