Phone-Number Login in a Mobile App: Seven Things That Break in the Real World

Our sign-in screen shows the country code already selected, so the number field expects ten digits. Apple's reviewer read our review notes, saw the number written with the country code in front of it, and typed all twelve digits. The field silently kept the first ten, so the code was sent to a different number, and the screen then reported an invalid code. Apple rejected the app for that, and the attached screenshot, which showed the masked number the code had been sent to, is the only reason we understood it.

Two fixes, and you need both. Never truncate silently: a field that cannot hold what was typed should say so, or accept and normalise it. And write test credentials exactly as the field expects them, in the format it displays.

The user taps send, switches to their messages to read the code, and comes back. In our apps, coming back sent them to the first screen and discarded the half-entered code. The cause was routing: the router had stored the in-flight request as extra data on the route, and when the app resumed, a state change rebuilt the router from the saved route information, where that data had been silently dropped to nothing. With no request to show, the screen bounced to login.

The fix is to hold the in-flight request in a holder that lives for the life of the process, and read it from there when the route data is missing. Also do not emit lock or permission changes into the router while nobody is signed in; refreshing the router during the login window only churns it. The holder is cleared on success, on going back and on sign-out, because it holds a phone number.

Testers reported entering the right code, seeing verification failed, and then being taken into the app anyway. The sign-in had succeeded, the session was live, and the app then looked up whether this was a new or returning user. That lookup failed on a momentary network error and threw, and the whole call reported a generic failure, while the valid session carried on navigating.

Once the credential step succeeds, the user is signed in. Every later read is only a routing hint. Put each one in its own best-effort block that defaults to a safe route and returns success. A failure after the credential check must never be reported as a failure of the credential.

When the follow-up lookup does fail, the default matters. Defaulting to new user sends a returning customer to the profile-setup form, which will not bounce them off and can overwrite their existing name and handle. Defaulting to returning user sends a genuinely new user to the home screen, where the router's own check sees there is no profile and forwards them to setup. One default is self-correcting; the other strands people. Always choose the self-correcting one.

App Review is done by people who are not in your country and who cannot receive a text on your numbers. An app with only SMS sign-in is simply unreviewable unless you provide a way in. The standard answer is a test identity on your authentication service: a fixed number with a fixed code, where no message is ever sent and the code always works. Say in the review notes that no SMS is sent and that the code is fixed.

Apple files a failed sign-in under Guideline 2.1, app completeness, and it is one of the most common reasons first submissions are rejected. We cover the full set of store rejections in what shipping two apps to both stores taught us.

Our test identity worked at first submission. By the next release it had a lapsed confirmation date on the authentication service, and the reviewer could not get in. Nobody had signed in with it since the previous review, so nobody knew. It was the second rejection of the same app for a demo-credential reason, which is the real lesson: the demo path is part of the product and rots like anything else.

Sign in with the test identity yourself, on a phone, using the exact text in the review notes, on the day you submit. It takes two minutes, and it is the cheapest item on any release checklist.

All of our apps share one login, one-time-code and profile-setup package. That is why the failures above hit every app at once, and also why each fix reached every app at once: the resume fix, the false-failure fix and the no-silent-truncation fix were made once, in the package, and flowed into each app's next release. If you are building more than one app, a shared sign-in package is not over-engineering; it is the difference between fixing a bug once and fixing it five times.

Before you commission phone-number login, ask five questions. What happens if the user leaves the app and returns mid-code? What does the user see if the code is right but the next lookup fails? How will App Review get in? Who checks the test identity on submission day? And can the same sign-in code be shared across your apps? If the answers are vague, the first rejection will answer them for you. Our mobile app development service treats sign-in and the store launch as named pieces of work, and what a mobile app costs in 2026 shows where they sit in a budget.