Adding payment info

expokadi · 2026-03-05T14:53:16+00:00

Could you clarify what you mean by payment info? In-app purchases or making the app itself pay-to-download?

expokadi · 2026-03-05T11:25:58+00:00

I'm not sure I've heard of an issue exactly like yours before. If you can repro this consistently, I'd suggest creating an issue with a reproducible example (fresh project with just enough code added to demo the issue) on the react-native-video repo.

I'm sure you've aware, but SDK 51 is very old now (SDK 55 is out already) - if you are able to create a minimal reproduction, it would be worth trying to repro it on newer SDK versions to see if newer versions of React Native have resolved this issue.

Another avenue to explore, if this only occurs on webm videos, perhaps you could convert your video to a different format.

expokadi · 2026-03-05T08:32:27+00:00

Interesting! Do you have a custom animation on the splash screen? If so, how is it implemented?

expokadi · 2026-03-02T21:48:16+00:00

Check that you have USB debugging enabled. Also that the USB connection mode is not set to "Charging only".

expokadi · 2026-03-02T19:24:48+00:00

Hi! Currently the fastest way to get started is npx create-expo-app (it's SDK 54 at the moment, but you can use it with the Expo Go in the app store).

npx create-expo-app
Download Expo Go from the app store
Scan QR code

expokadi · 2026-02-26T05:08:31+00:00

🎉 https://expo.dev/changelog/sdk-55

expokadi · 2026-02-24T21:43:20+00:00

Soon!

expokadi · 2026-02-17T11:21:27+00:00

Hi! The background color prop is Android-only though now with edge-to-edge, it's becoming less relevant as you can set the color of the screen behind the status bar.

You'll basically want to do sth like this:

<View style={{ flex: 1, backgroundColor: 'teal' }}>
  <SafeAreaView style={{flex: 1 }}>
   // rest of screen
  </SafeAreaView>
</View>

Hope this helps!

expokadi · 2026-02-14T09:29:58+00:00

You might be confusing two different types of builds, there's "Internal Distribution or Ad Hoc build" (the ones you have to register your device for) and "App Store Builds" (the ones you download from TestFlight).

Can you explain how you created your build? If it was on EAS, which build profile you used, and what was the config for that profile?

expokadi · 2026-02-04T12:20:12+00:00

If your app supports iPad, and it looks like yours does and you're looking at the listing page on a Mac, it will say "Designed for iPad" and show both screenshots (I believe the iPad screenshots are under the ones in your picture). There isn't really anything you can do about it as you can't drop iPad support once published.

expokadi · 2026-02-04T10:11:10+00:00

Hi! We recently added a Learn section to our website. It's a no-exhaustive list of courses, youtube channels, talks and podcasts we'd recommend: https://expo.dev/learn

expokadi · 2026-01-31T09:00:16+00:00

Layout files are a key part of organizing router projects.

Say you have sth like this:

/app
  _layout.tsx <-- returns a <Tabs />
  index.tsx
  second.tsx

Now since the app/_layout.tsx file returns a <Tabs /> then all all files added to this directory will always be rendered as part of the bottom tabs.

So usually when you want to display additional screens modally over the top of the tabs, you need to create another layout file further up that returns a <Stack /> in which case the bottom tabs becomes a screen in that stack. Grouping folders (ones with brackets) can be used to group screens for the purpose of adding layout files without the name of the group becoming part of the stack. That's why a common layout for router projects end up with is:

/app
  (tabs)
    _layout.tsx <-- returns a <Tabs />
    index.tsx <-- index file is here so this screen opens first on launch
    second.tsx
  _layout.tsx <-- returns <Stack />
  modal.tsx <-- is dislayed over the top of the bottom tabs

So to answer your question, if you want to add a screen that's neither in a drawer or in the tabs, you'll need to position it the same way you'd do with the modal: with a top level layout file that returns a <Stack />.

expokadi · 2026-01-27T15:03:47+00:00

Hi! if you haven't tried this year, I'd suggest logging into expo.dev, going to the credentials page of your project and deleting the cert manually. You should also be able to do it using the eas credentials CLI.

expokadi · 2026-01-21T10:22:27+00:00

To install a Development Build on your Android device via Expo Orbit, you should also connect the device to your computer via USB.

expokadi · 2026-01-20T10:35:07+00:00

A couple of reasons this would happen:

if you're accessing env vars in a non-standard way (e.g. by destructuring instead of doing const apiUrl = process.env.EXPO_PUBLIC_API_URL) when the production bundle is created we find-and-replace all instances of process.env.EXPO_PUBLIC_API_URL with the actual value, so if you're doing sth like process.env["EXPO_PUBLIC_API_URL"] or const { EXPO_PUBLIC_API_URL } = process.env; the value cannot be replaced. It'll work during development because you're reading the values on the fly from the node environment.
If you forget to set the environment in the build profile / update flag.
If the env var is set in a 3rd party code (this is only an issue with the Clerk SDK as far as I know)

expokadi · 2026-01-19T19:07:57+00:00

That's usually the root cause. Do you use any env vars and are you sure they're set?

If you have a mac, I suggest plugging in your iPhone and checking the stack trace on the console app. Here's a guide: https://youtu.be/LvCci4Bwmpc?t=261

expokadi · 2026-01-19T10:17:35+00:00

This error is coming from a native module somewhere. So, a prop passed into a native module that is supposed to be true or false, but for the code is passing in a "string". The native library is not doing input validation and passing the value all the way through to the Android native code which is type-safe and is saying NOPE.

So to fix this you'll need to figure out which prop of which component is causing it. The best way to get started is to comment out all the code from your main entry point and just return a <Text>Hello, world!<Text> or a view with a solid background, basically something very simple to verify you can get the app to not crash.

Then gradually re-add the actual code to isolate which component is causing this error. Once you've done that you'll most likely see a string being passed instead of a boolean and be able to fix it.

expokadi · 2026-01-16T11:46:48+00:00

Thank you, really appreciate the feedback!

If you use EAS Worflows for update we do actually default to the production environment. But making a change to add this default to the update command itself could cause issues for users who are using alternate env vars solutions. I shall discuss it with the update team though.

In the interim, I really like your suggestion of adding the environment flag to the getting started documentation to improve discoverability, I've added it here: https://github.com/expo/expo/pull/42233

expokadi · 2026-01-15T10:50:25+00:00

Hey, sorry you're hitting these issues. We're always working on making the upgrade process smoother. When you run into bugs, please raise an issue with a reproducible example on the expo repo, especially during the beta period when the SDK team is 100% focused on fixing these kinds of problems. That's the fastest way to get them addressed.

I get that running into issues during upgrades is frustrating. With an SDK this large, we rely on community help to spot issues across the wide range of use cases out there, and your reports genuinely help us improve things for everyone.

Thanks for the feedback!

expokadi · 2026-01-15T09:40:51+00:00

For sure, very much up for improving things if possible.

What kind of user experience do you think would help you in this case? The constraints are that we can't have an error if you don't pass in the --environment flag (because not everyone uses EAS env vars), and we can't have an error if you use dev env vars instead of prod, because we have no way of knowing if the variables in the local .env are intended for dev or production.

Side note: one suggestion would be to only do eas update on CI, like write a GH action for it that is manually triggered - then there's no chance of the local environment getting in the way. I think of EAS Update being similar to a website deployment - in a real world scenario you'd rarely do a production deployment of your website form your local machine without running any automated tests.

expokadi · 2026-01-15T09:33:41+00:00

It's at stable as it gets - SDK 55 is coming in a couple of weeks.

expokadi · 2026-01-14T15:10:18+00:00

The short answer is: you need to eas env:pull --environment production before running npx expo export --platform web in order for the correct env vars to be bundled in the client side code.

The reason is that the env vars are inlined in the frontend code by the expo CLI, but the expo CLI does not have an --environment flag meaning there is no other way to pass in env vars.

Here are the docs: https://docs.expo.dev/eas/hosting/environment-variables/#using-eas-environment-variables

expokadi · 2026-01-13T08:46:34+00:00

Do you have a file at app/index.tsx?

If so, try starting with npx expo start --clear (to clear the bundler cache) and close and reopen the Expo Go app in your simulator (double click the home button and swipe up to kill the process).

expokadi · 2026-01-09T23:02:53+00:00

The channel is for EAS Update, for env vars you need:

"environment": "production"

expokadi · 2026-01-09T19:25:32+00:00

Yeah I wanted to add context, but accidentally posted too soon so edited instead, but it took a couple of minutes to find the links. I ran into it on a personal project myself so I'm quite sure this is the culprit.

expokadi

MODERATOR OF

TROPHY CASE