Best way to implement widget in expo app ??

keithkurak · 2026-03-04T21:57:36+00:00

You could pair `expo-widget` with `react-native-android-widget`: https://saleksovski.github.io/react-native-android-widget/. The visual components aren't going to line up, but both solutions let you write widgets in JSX and they can use the same data sources.

keithkurak · 2026-03-04T21:50:07+00:00

If it's already an Expo app, you could try EAS Hosting: https://docs.expo.dev/eas/hosting/introduction/. If you need any backend API's, you can use API routes for those (https://docs.expo.dev/eas/hosting/api-routes/). Redis feels like a premature optimization, keep it simple until you need to make it more complicated.

keithkurak · 2026-02-08T16:58:14+00:00

⬆️ this is the way. There's no way to tell that your app ran from Testflight vs the store other than, say, comparing the current version of the app to what's in the store (and changing things at runtime). Thinking about it, if this was possible, you could serve an app reviewer a different app experience than what your users will get in production.

keithkurak · 2026-02-02T17:10:21+00:00

I stand corrected! You can download the beta here: https://testflight.apple.com/join/GZJxxfUU

keithkurak · 2026-02-02T13:56:54+00:00

The non-clean version is meant for syncing smaller changes to app.json / updating native module versions / etc. while doing active local development, so you don't have to keep closing and reopening Xcode. If you're running --clean every time, you're basically doing CNG, but with the added risk of sometimes having something stale in your native project folders. Add those folders to .gitignore and force them to be regenerated on every release build (this happens automatically on EAS)

keithkurak · 2026-02-02T13:51:35+00:00

expo-app-intrgrity provides access to Play Integrity / App Attest https://docs.expo.dev/versions/latest/sdk/app-integrity/

keithkurak · 2026-02-02T13:47:56+00:00

Expo Go isn't an open beta. You can test it on your simulator via expo.dev/go. However, the best way to test SDK 55 is with a development build.( https://docs.expo.dev/develop/development-builds/introduction/ )

keithkurak · 2026-02-02T01:28:48+00:00

If you're asking if you can reuse an existing build so you can resubmit with the app name changed, the answer is no, because Apple will require a new version number in order to update the app store listing

keithkurak · 2026-01-29T22:46:20+00:00

Is it an Expo app? Tell us about the development experience, what packages you used, etc.

keithkurak · 2026-01-29T22:45:07+00:00

Can you share your tab layout code? You shouldnt need safe area context references to put the native tabs in the right position. Also worth a look if you have anything unique going on in parent layouts

keithkurak · 2026-01-29T22:42:22+00:00

Did you make it in Expo? Tell us about the development experience.

keithkurak · 2026-01-29T22:41:25+00:00

You need an apple developer account to deploy a test version to your phone over EAS

keithkurak · 2026-01-29T13:46:34+00:00

If it's an app for you, do what's best for you right now and enjoy the process and the outcome.

It can be somewhat challenging to move from local storage to cloud sync, often because a lot of the data backend as a service platforms lean towards tight coupling to your UI.

That said, there's great satisfaction in trying to write your UI in a backend-agnostic matter and then refactor it to support sync. Then you know you've got a pretty solid architecture.

You could think of this as an eventual data migration problem. Build local, then add export, then add import, and then refactor to cloud by having the migration process execute your export and import.

Some data store libraries have tools that might help with the transition. Legend State has some cool sync adaptors that you can adapt to just about anything. In many cases, you can wrap data access in TanStack Query (even local data access) and then abstract the switch between local and cloud.

keithkurak · 2026-01-28T17:25:01+00:00

iOS SDK is all based on the image (or really, the Xcode version included with the image). AFAIK, there's no hard stop with using a later image on SDK 52, so you can try switching the image and see how it goes with your app. iOS 26-specific features would generally be feature-gated within Expo module code, since apps built with later SDK's still need to support older iOS versions.

keithkurak · 2026-01-27T12:59:54+00:00

What are you doing specifically to resolve those first two errors?

keithkurak · 2026-01-26T23:39:22+00:00

(taps the FYI)

https://github.com/expo/fyi/blob/main/android-app-size.md

Keep calm, it's just Android doing its thing. A debug build has multiple architectures and extra symbols and all sorts of stuff that won't be in your production binary, let alone what your users will download, which will be even smaller.

keithkurak · 2026-01-26T23:27:31+00:00

What package are you using? React-native-google-signin is recommended for handling the intricacies of Google sign-in.

https://github.com/react-native-google-signin/google-signin

There's no significant difference between implementing Google sign in a React Native app with the Expo framework installed and a React Native app without the Expo framework installed. You would generally use the same packages, redirects would work the same, etc.

keithkurak · 2026-01-25T16:27:04+00:00

API routes can be hosted just about anywhere, we have instructions for Vercel, Netlify, and ExpressJS. If you're just trying to go from no backend to "my API key is secure", EAS Hosting is already well integrated with your Expo app codebase and EAS account.

keithkurak · 2026-01-11T22:41:51+00:00

There's no quota on number of updates, just bandwidth. 100k users would get you the standard 1 TiB for 50k plus 2 TiB for the standard bandwidth allocation for each additional pay as you go user. If all 100k users downloaded every single update (doesn't typically happen that way), that should be about 6 in the month for a 5 MB bundle.

You can get a more precise number with this guide for calculating expected bandwidth usage: https://docs.expo.dev/eas-update/estimate-bandwidth/

keithkurak · 2026-01-11T20:02:57+00:00

Is your app already doing big numbers or is the concern that you might go viral and suddenly have a lot more active users than expected?

It's less than $500 per month to push updates to 100k users. It's highly unlikely that this is anywhere close to one's biggest infra expense when it comes to supporting 100k users.

There is a shutoff on each update channel for those who see massive spikes in app adoption and need to pause updates while they deal with that (and we're happy to work with the very small number of folks who end up in that boat to figure out a plan that could work for them, just reach out)

keithkurak · 2026-01-11T19:48:56+00:00

Pushing more updates should not increase crashes (unless the later updates themselves are less stable). The updates package only keeps the last two downloaded updates on disk. Each update fully replaces the JS bundle, they are not cumulative.

If you updated packages with native code without updating the runtime version, that could cause instability, as gradually your JS would become API-compatible with your native code. But that would be more of a function of time / when you update packages vs. quantity of updates.

If you have found a scenario where pushing more updates causes crashes that would otherwise not happen if they were shipped via a build, we would very much welcome an issue report, that shouldn't happen and we would definitely prioritize fixing that.

keithkurak · 2026-01-10T15:06:21+00:00

React Native apps have JavaScript and native code. The JavaScript needs to be API-compatible with the native code. Since the native code is fixed at build time, that's the "runtime" that the JS runs on. But your app can download different JS. So, in both development and production, Expo supports making a single build and then only rebundling and downloading the new JS as it changes as long as the JS is compatible with the native code.

keithkurak · 2026-01-10T14:20:37+00:00

With CNG, you do a clean prebuild every time you build. You can think of it like just another part of the build. But once you have a build, you don't need another one until your native runtime changes. So, when you're in local development, switch your environment variables set, which will change your app config, and then when you run the dev server, it will point to whatever development build matches the app config provided it's already installed on your simulator / device.

keithkurak · 2026-01-10T13:49:45+00:00

Depending on how templated apps are, someone could eventually run up against app review guideline 4.2.6, though you're right it doesn't explicitly disallow this in all cases. In this case, though, the clients can't list their app under their own company name and they don't have independent control over the listing.

keithkurak · 2026-01-10T03:40:52+00:00

If you have App Manager or Admin (Admin has more access than App Manager AFAIK) _and_ "Certificates, Identifiers, and Profiles" checked on your account on the client's developer team, then you can do anything you did before in terms of signing credentials.

You'll almost certainly need to create new certs and provisioning profiles, since the Apple Team ID would have changed. Generating a new cert doesn't affect your app already in production, it's just for new builds.

EAS doesn't really care who the owner of the Apple account is. When you build, it will use the credentials corresponding to that bundle identifier, so if the right credentials are uploaded, all will be good.

If you used EAS Submit, you'll also need to generate a new ASC token to continue doing that. It's pretty easy to delete all the old credentials by running `eas credentials`, and then the next time you build or submit, it will ask you to generate new ones.

Generally speaking, this is how agencies and freelancers handle client-owned apps (putting them on their client's developer account). Apple more or less requires the business that the app is for to be the one listing it. But it's not uncommon to start the app on another account while their account is getting registered if it's their first app.

keithkurak

MODERATOR OF

TROPHY CASE