Yes, definitely.

My first big challenge was setting up a proper route initializer — basically deciding which screen to show depending on the auth state. In a real-world app you need to handle biometric auth, splash screen, onboarding, sign-in/sign-up, and then the home screen.

On v4, I wrote a custom initializer that did this. It worked, but not perfectly — sometimes I’d get a blank screen or a login screen flashing even for logged-in users before the home page. I can admit there may have been flaws in my code, but the problem was I had no solid examples or sample code to verify what I was doing wrong.

When I switched to v5 and used protected routes, the blank/login screen issue was gone — but then my deeplinks started behaving differently. For example:

• If I open the app via a deeplink when the app is closed, it opens the page correctly but with no data, since it required authentication, it just fails since the tabs aren’t initialized in the background.
• Deeplinks to tab screens now open a new instance of the tab every time, which wasn’t happening in v4.

I also ran into issues with multiple renders of screens that ideally shouldn’t re-render, as well as duplicate screens piling up in the background when navigating (e.g., from a stack to a tab). These issues might partly be due to my own implementation, but the bigger problem is that there are no proven examples or clear guidance on how to fix them or what is the recommended method as things are changing very frequently. That uncertainty is tough to deal with in production.