App Transfer Impact on Universal Linking/AASA

Thanks so much for the post.

For users who already have the app installed, Universal Links will continue to function normally immediately after the transfer in App Store Connect.

When a user installed the app originally, iOS downloaded your AASA file and verified it against the app's entitlements. Because the binary on their device has not changed, the operating system still expects the old Team ID. As long as you do not remove the old Team ID from your AASA file, Universal Links will remain unbroken for these users.

While the app transfer happens immediately in App Store Connect, the actual Team ID associated with the app binary does not change until the new owner submits an app update.

Once the recipient account compiles and submits a new version of the app, that new binary will be signed with the New Team ID. For Universal Links to work on this new version (for both fresh installs and users updating the app), your AASA file must include the new appID.

Because the AASA appIDs (or appID depending on your formatting) property accepts an array, you can list multiple App IDs for the same routing rules. You should update your AASA file on your server before the new owner releases their first app update.

When you transfer the app, make sure the AASA file contains the correct AppID is you still using the same server and url.

Albert
  Worldwide Developer Relations.

Hi Albert,

Thank you for the details! The details and transition steps are clear.

I wanted to confirm one additional scenario to make sure I understand the transition behavior correctly.

During that interim period where the app transfer has completed in App Store Connect, but the recipient account has not yet released a new app version signed with the new Team ID.

• If a brand new user downloads and installs the app from the App Store for the first time, will Universal Links continue functioning normally as long as the AASA file still includes the original Team ID and appID?
• Is it correct to assume that the App Store would still be distributing the existing binary signed with the original Team ID until a new version is submitted by the recipient account?

Thank you.

Thanks for your new post. I thought I have covered those scenarios on my previous post, I guess I missed something. I would recommend you to look at the documentation and see how AASA files works and how you register the different appIDs do that will give you the knowledge that the most important is to have multiple AppID into the AASA file so you can have 2 apps that will use a unique AASA file.

Because the App Store is still distributing that original binary, any brand new user downloading the app for the first time is installing an app signed with the original Team ID. When iOS installs the app and fetches the Apple App Site Association (AASA) file from your server, it will be looking for a match with the original.

As long as your AASA file still includes the original and new App ID, Universal Links will continue to function completely normally for these new users during the interim period.

This exact behavior is why it is highly recommended to host an AASA file that contains both the original and the new before the new owner releases an update.

Keeping both entries ensures no one experiences broken Universal Links during the transition. But I would also recommend you to go ahead and create a test app that works with the AASA file so you can experience, debug and see the registrations on your swcutil file.

Albert
  Worldwide Developer Relations.