Thing i can see being a blocker currently for us

[wcastand]

For now, expo-router doesn't support .ios / .android and we use it for 2 reasons.

• expo-plugin for apple-pay and google-pay to only import in the right platform (should be able to deal with this in the export of the plugin)
• having a Toast above all else needs different logic in ios(FullWindowOverlay) and android(View in absolute) so not sure how we could handle that in the case of expo-router without custom extensions.

The second one is more specific to our case, which is When you leave the app for more than 30 seconds, we need to block the user with a biometric Auth (fingerprint / faceID / local pin). which means i need a screen going above all else, without loosing current history (people coming back should not comeback to the home everytime they have to re-auth)

so the Auth use case doesn't work in our case since we need to redirect when coming from background on a biometric auth blocking all other screens when you're connected but not when you're not connected.

[leggomuhgreggo]

expo-plugin for apple-pay and google-pay to only import in the right platform

I'd say this is one of the few really valid reasons to use platform extensions. Way to easy for people to confuse "platform" and "form factor" -- so it's best to only use when there's really some underlying platform API that requires the customization

Anyway you can totally do this with expo-router, just can't be in the app directory. If you throw it in "components" or something then you should be fine to import it as if it were a single file like: import { Pay } from "../components/Pay

|- app
|- components
|    |- Pay.ios.tsx
|    |- Pay.android.tsx
|    |- Pay.tsx <-------- always have one without an extension 

Here's the relevant bit from the latest docs:

excerpt

Metro bundler's platform-specific extensions (for example, .ios.js or .native.ts) are not supported in the app directory. This ensures that routes are universal across platforms for deep linking. However, you can create platform-specific files outside the app directory and use them from within the app directory.

Auth use case doesn't work in our case...i need a screen going above all else, without loosing current history (people coming back should not comeback to the home everytime they have to re-auth)

Plenty of ways to handle auth. The docs just provide one example. You can customize it so that you're persisting a redirect target, perhaps as a query param like: /login?redirect=return-route or just in local/async storage or somethin. Then when login succeeds you check for if it exists and redirect back if so.

[marklawlor]

Our philosophy for the app directory is for it to be synonymous with URLs. Platform extensions don't fit within this philosophy and don't work well with planned future features. For this reason, the best solution is to have one route that exports a multi-platform component as demonstrated by #220 (comment)

[wcastand]

wow that was a ticket from long ago, i forgot about it ahah.

so for the platform extension i realized later that i could still use them outside of app folder which like you said, fix the problem.

for the auth i ended up taking the biometric screen out of the navigation because it was causing issues to navigate when the app was re-opening or coming from deeplink etc.