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?