On Christmas morning, someone opens your app on a brand-new phone

Rosa's new phone

Rosa is a composite, but you know her. She runs a small dog-walking business and books most of her week through one scheduling app. On Christmas morning, which this year is a Friday, she unwraps a new phone. By lunchtime she's moved everything across from the old one, the way the setup screens suggest. Photos, messages, apps. It feels like it worked.

On Saturday morning she opens the scheduling app to confirm Monday's walks. Let's follow what happens next, because every step is a decision someone on your team made, or didn't.

Step one: is she still signed in?

The app opens to the login screen.

That might be fine. Some apps should ask again on a new device. The question is whether anyone chose it. On iPhone, an app can store its sign-in token in the Keychain with a setting that keeps it on that device. Apple's documentation is plain about it: items with that attribute do not migrate to a new device. That's a sensible choice for something sensitive. It just means a new phone always starts signed out, and your team should know that's the behavior.

On Android, what moves depends on backup rules each app sets. Again, the result can be right. It should be on purpose.

The same goes for face or fingerprint unlock inside your app. That's tied to the device too, so she'll need to turn it on again. If the app quietly falls back to a password she no longer knows, the friendly shortcut just became a locked door.

So Rosa needs to sign in. She doesn't remember her password, because the old phone remembered it for her. She taps "forgot password." The email goes to an address she stopped checking two years ago. We wrote a whole note about the password reset that went to spam. This is its holiday cousin.

Step two: the code is on the other phone

She finds the email. She resets the password. Now the app asks for a two-step code.

If the code comes by text, she's probably fine, because her number moved with her. If it comes from an authenticator app, it may be on the old phone, which she's already wiped and handed to her nephew. If your app's own login uses a one-time code sent to "this device," it's gone.

This is the step where people get stuck and call. And it's Saturday of a holiday weekend, so the call goes to voicemail.

What helps: a recovery path that doesn't depend on the old device. Backup codes shown once at setup and again in settings. A verified email and a verified phone, so there's always a second door. A support process that can confirm identity on a holiday without a three-day wait. Our note on keeping more than one way in makes the same case for social sign-in.

Step three: what came across, and what didn't

She's in. Monday's walks are there, because they live on your server. But the draft note she'd started for a new client, the one with gate codes and the dog's medication schedule, isn't. It was saved on the old phone and never synced.

Nothing told her it was missing, either. There was no "you have one unsent draft on another device" note, because the server never knew it existed. That silence is worse than the loss.

Her settings are back to defaults. Reminders are off. Her preferred map app isn't selected.

And she's not getting notifications. Push notifications are tied to a device token, and the new phone needs to register its own. Most apps handle this when the app opens, but it's worth checking, because "I stopped getting reminders" after a phone change is the kind of thing nobody reports until something is missed.

The rule we'd use: anything a customer would be upset to lose belongs on your server, not only on the phone. Drafts, settings, preferences. Keep sensitive secrets on the device if that's safer, and let them be re-created. The new phone is not the moment to find out your sign-in only worked on the old one.

Step four: the old phone in the nephew's pocket

Rosa's old phone is still signed in. She cleared it, she thinks. Maybe she did. Maybe she just signed out of her main account and left the apps.

Can she see, in your app, which devices are signed in to her account? Can she sign one out? Does your app remember the old device as "trusted" for two-step checks?

A short device list in account settings, with "sign out" next to each, is cheap to build and solves a whole category of worry. It's also what your support team needs when someone calls to say "I gave my old phone away."

While you're there, check that your app still behaves if someone signs in on the new phone with an older version still installed elsewhere. We've written about old versions still running, and phone changes are one of the ways they hang around.

Put this into practice before December

Run Rosa's morning yourself. Take a test account with real-looking data, set it up on one phone, move to another phone using the normal transfer or restore flow, and write down what you see at each step. Do it on iPhone and on Android.

For each piece of data, decide on purpose: should this follow the customer to a new phone, or should it start fresh? Write it down so the next developer doesn't have to rediscover it.

Write the support reply now, while it's calm. A short, kind message for "I got a new phone and can't get in" that explains the recovery steps in order, and says what happens if none of them work. Put it where whoever answers on the holiday weekend can find it. If an assistant answers your support inbox, give it the same steps, word for word.

Fix the recovery path first. If the only way back in depends on the old phone, that's the one to change before the holidays.

Add a device list with sign-out if you don't have one. Check that push notifications re-register on first launch.

If you'd like help testing your app's move to a new phone, or fixing what you find, that's mobile application work we do. Talk to us.

Related work: PatientIQ.