Summary

  • Sign in with Apple assigns identities within a developer team’s scope. The buyer must connect its new identifiers to existing customer records using transfer identifiers.
  • The migration period lasts 60 days after the app transfer is completed. Apple’s documented recovery after that period requires returning the app to the original team and transferring it again.

There is an awkward post-acquisition email waiting for an app buyer who misses a particular deadline: could you take the app back, prepare its users for migration, and send it over again? The seller may already have spent the money and reassigned the engineers. The login system would still like everyone’s attention.

Apple’s technical note TN3159 sets out that recovery route. If Team A transferred an app to Team B more than 60 days ago, B should transfer it back. A prepares the user data and transfer identifiers, transfers the app again, and B completes the identifier exchanges. The round trip reactivates the migration facilities.

An acquisition can therefore be complete in the deal room while its customer handover needs another journey through the seller’s account. That is a useful distinction to discover before paying for the customers.

The stars cross easily

Apple offers valuable continuity at the storefront. Its App Store Connect transfer guide says an eligible app can remain available for download during transfer, retain its ratings, reviews and Bundle ID, and continue delivering updates to users. The buyer can acquire a reputation without asking the market to award all those stars again.

Sign in with Apple draws its boundary around the developer team. Its user identifiers are team-scoped. This protects privacy by preventing separate developers from simply receiving one universal number with which to correlate a person’s activities.

An app sale has to cross that boundary deliberately. The buyer needs to connect the identifier issued within its team to the correct existing customer record. That record may hold the account’s history and treatment within the service. Possessing the database is one part of the handover; making the new login find the right entry is another.

Apple’s instructions for the transferring team provide a controlled bridge. The sender generates a transfer identifier for each user, targeted to the receiving team. The exported data excludes the old team-scoped identifiers and private email relay addresses. The recipient exchanges the transfer identifier for its own team-scoped identifier and a private email address where applicable.

The design allows a customer relationship to move while keeping the identity boundary intact. Somebody still has to carry out the movement. An acquisition announcement cannot identify a returning customer on the new owner’s behalf.

One clock, two teams

The migration window runs from the completed app transfer. The sender can prepare transfer identifiers beforehand or generate them up to 60 days after acceptance. The recipient must also exchange them within 60 days of acceptance. A late delivery does not start another full period for the receiving team.

That shared clock gives the order of work a commercial consequence. Preparation, delivery, exchange and association with existing records are successive tasks. The seller’s “sent” can arrive well before the buyer’s “working”, or uncomfortably close to the deadline. Moving the first task later squeezes the time available to finish the rest.

The receiving-team guide describes how login information during the transfer period can help correlate users. Relying entirely on their return visits, however, hands the integration schedule to people who never agreed to it.

Some customers open an app every morning. Others need it a few times a year. Apple supports server-side batch migration, so teams can process users who have not signed in again. The quiet customer can be included in the handover without being summoned back to rescue an acquisition timetable.

This matters to the denominator in an integration report. Success among recent visitors can look excellent while accounts belonging to absent customers remain unfinished. A customer does not stop being part of the purchased business merely by declining to log in during the buyer’s preferred month.

After payment, cooperation gets interesting

Once the period is missed, the documented return-and-retransfer procedure brings both organisations back into the work. App Store Connect requires the respective Account Holders to initiate and accept transfers. The buyer does not control every necessary action from inside its own company.

Before closing, the seller has a strong reason to make people available. Afterwards, its next product may be more interesting. The recovery process asks that organisation to prepare data and perform another transfer sequence for a business it has already sold. An overlooked handover becomes a fresh claim on somebody else’s time.

The migration logs, unmatched accounts and actual recovery hours from a particular acquisition are missing here; those would put a price on its rework. The structure is already visible. Owning the app does not give the buyer unilateral control over completing every part of the old users’ identity migration.

A useful closing arrangement can cover preparation, completed mappings, dormant-user coverage and practical help if recovery is needed. These are deliverable actions. A promise to answer emails is a much softer asset.

The storefront will happily display the inherited stars. It cannot use them to recognise an old customer at the new owner’s door.