Expo app works in Expo Go but crashes on TestFlight (iOS build) after navigating to Login screen

Hi everyone,
I’m facing an issue with an Expo app published via Replit that works perfectly in Expo Go, but fails when built and distributed through TestFlight.

:white_check_mark: What works

  • App runs normally in Expo Go

  • App installs correctly via TestFlight

  • Initial welcome/onboarding screen loads fine

:cross_mark: What fails

  • When navigating from WelcomeLogin screen, the app crashes and shows a generic error screen:

    “Something went wrong. Please reload the app to continue.”

(Attached screenshot)

After that, the app becomes unusable.

Is this your own login/auth screen, or did you use Replit auth?

own authentication

I’ve never had to debug a native iOS app, so 'fraid this is a tricky one.

As always, I’d start by getting the Replit agent to help. Explain the situation and see what it comes up with. It may well offer to add in some debugging and logging. A very long re-publish process to test it, but sadly this is the world of native apps.

Let us know how you get on, as I fear this is a situation a lot of people will reach as they start experimenting with native apps.

The error was due to the Google login option; I probably didn’t configure it correctly. I’ve temporarily disabled it to continue testing the app in the future when I feel more secure and can reactivate this option.

I was going to say, probably a Google issue. It’s a bit tricky for mobile. My advice would be to launch with simpler auth, get it into the app store, then revise as you have time.

Seeing a lot of builders get stuck trying to add everything at once. I think this is a problem for all apps, but even more so for iOS. And not to sound like ChatGPT, but heres why…

Submit barebones first. Get approved with the minimum viable feature set, then add features through updates.

Apple reviewers have quotas to meet every day and spend only a few minutes on each one. When you submit an update, they’re checking the delta (what changed), not re-reviewing your entire app from scratch. Your core architecture is already validated, so updates fly through.

So instead of submitting your full-featured app and giving them 15 things to reject you on, you submit something simple, establish trust in their system, then iterate. Each update only puts the new feature under the microscope. Way less surface area for rejection.

2 Likes

I agree with Eric. And, with mobile or web apps, I would always suggest people start with something simpler. The classic MVP (minimum viable product):

  • in a first cut version, nobody needs social logins. Just add email-only user auth.

  • just create 1 or 2 features that blow people away - and just work, beautifully. Rather than 16 features that are all lost in the noise of each other - and are full of bugs.

1 Like

Jack Nicholson yes gif

1 Like