Treat the callback as a chain of handoffs
A user completes sign-in in a browser, but the app opens to a blank screen or remains signed out. The provider may have authenticated the user successfully while a later handoff failed.
Trace the whole route: the provider accepts the redirect, the browser reaches it, the operating system selects the destination, the application handles the incoming URL and the authentication library establishes the intended session. Navigation then moves to the correct screen.
Record a callback contract for each flow, including OAuth login, email confirmation and password reset. Identify which app build, host, path and authentication response each flow expects. A single generic success page may not satisfy all three workflows.
Choose links that the installed app can handle
A custom URL scheme can route a link to an installed app. HTTPS links can use iOS Universal Links or Android App Links with an association between the website and the application.
Expo's linking overview distinguishes these mechanisms and recommends development builds for testing. Opening the app is only part of the work; the application still needs routing logic for the incoming destination.
Use an explicit scheme where a stable custom callback is required. Avoid treating an Expo Go development URL as the callback contract for a store build. Native configuration and installed application identity affect which links can open that build.
Match provider settings to runtime behavior
Configure the callback in every layer that checks it. Depending on the authentication design, that may include the identity provider, an authentication broker and the app's own routing configuration.
Expo's authentication guide explains redirect construction and development-build requirements. Supabase's native deep-link guide covers redirects used for OAuth and email-based authentication flows.
Separate development, staging and production values deliberately. A correct development callback does not prove that a production email points to the production host. Review the generated link itself and the configuration of the deployed service sending it, rather than only checking a source-code default.
Verify the domain associations for HTTPS links
For iOS, inspect the associated domain entitlement and the website's apple-app-site-association configuration for the intended application and paths. Expo's Universal Links guide documents the setup and its testing considerations.
For Android, verify the intent filter, assetlinks.json association and signing-certificate fingerprints for the installed build. The Android App Links guide explains why the correct package and signing identity matter.
Test links from realistic entry points such as an email or message on the device. Browser address-bar navigation and an app-to-app tap can behave differently. Account for association caching and use the platform's documented verification process when diagnosing an outdated configuration.
Handle the authentication result before protected navigation
Use the authentication library's supported callback handling and code-exchange process. With an authorization-code flow, the callback must complete the expected exchange before the app treats the user as authenticated.
Coordinate routing with session initialization. A cold-start callback may arrive while the app is still loading stored state; a warm-start callback may arrive while an existing screen is visible. Handle both without processing the same result twice or redirecting before the session is ready.
Validate incoming destinations against your expected schemes, hosts and paths. Honor the authentication library's state, nonce and PKCE handling where applicable. Do not log raw tokens, authorization codes or complete sensitive callback URLs while trying to debug navigation.
Build a callback test matrix
Test fresh installation, cold start, warm start, signed-out and signed-in states, canceled login, expired email link and password-reset completion. Include the development build and the intended distribution build on a physical device.
For each test, verify the final account, session and screen, not merely that the app opened. In an illustrative email-confirmation flow, success means the intended user reaches the appropriate next step with the expected authentication state.
Give failures a useful description: redirect rejected, website reached instead of app, wrong route, session exchange failed or navigation happened too early. These categories direct investigation to the correct handoff and keep a working provider login from masking an incomplete app flow.
Test the build that reaches users.
Linking configuration belongs alongside the other checks before distributing a mobile release.