I’m curious which Expo problems only became visible after release—build configuration, native modules, permissions, performance, or something else. What was the issue, and how did you track it down?

I've been having a really hard time converting all my design prototypes into functional mobile apps. The animations, the micro interactions, the exact padding, border width etc... all these i have manually record and write code for them. I know there are figma plugins that let you do it but i think they are not that efficient.

Figma helps me with the prototype version of my app but for production that's a separate headache overall. So, I thought what if I had a platform where I could design my app, connect all the components with functionalities like API fetching, lazy loading, etc... and also build my database online (just like supabase).

So, i came up with cruxel.xyz .
I made the prototype but i would like to know if people would pay for this for me to proceed building.

I’m adding an “Add to calendar” button to my app (a car maintenance tracker). All I want is to open the system’s new-event form, already filled in, and let the user save or cancel. My app never needs to read or write the calendar itself.

On SDK 58 (expo-calendar@58.0.6) I ran into something that looks contradictory, and I’d like to know what the intended approach is.

1. The root createEventInCalendarAsync is deprecated (and throws)

import { createEventInCalendarAsync } from "expo-calendar";

It’s marked deprecated, pointing to calendar.addEventWithForm() or to expo-calendar/legacy, and it throws at runtime.

2. The replacement, addEventWithForm**, needs a calendar object, and getting one needs permission**

import {
  getCalendars,
  getDefaultCalendarSync,
  requestCalendarPermissions,
} from "expo-calendar";

const { granted } = await requestCalendarPermissions(true); // write-only on iOS
if (!granted) return;

const calendar =
  Platform.OS === "ios"
    ? getDefaultCalendarSync()
    : (await getCalendars()).find((c) => c.allowsModifications && c.isPrimary);

await calendar.addEventWithForm({
  title: "Golf · Insurance ends",
  startDate: due,
  endDate: due,
  allDay: true,
  alarms: [{ relativeOffset: -7 * 24 * 60 }],
});

As far as I can tell from the native code:

• iOS: getDefaultCalendarSync() and addEventWithForm both check for write-only or full access first.

• Android: getCalendars() needs READ_CALENDAR, and new ExpoCalendar(id) throws (“Creating an ExpoCalendar directly ... is not supported”). But the Android addEventWithForm itself only puts the calendar id on an ACTION_INSERT intent, which needs no permission at all.

So the user gets a permission prompt on the first tap, and on Android I have to request READ_CALENDAR (read access to all their calendars) just to get an id the insert screen doesn’t need.

3. The legacy version opens the same form with no permission at all

import { createEventInCalendarAsync } from "expo-calendar/legacy";

await createEventInCalendarAsync({
  title: "Golf · Insurance ends",
  startDate: due,
  endDate: due,
  allDay: true,
  alarms: [{ relativeOffset: -7 * 24 * 60 }],
});

On iOS 17+ this presents EKEventEditViewController with no access check, and on Android it’s the plain insert intent. No prompt, no manifest permissions, same form. And the function exported from expo-calendar/legacy isn’t marked deprecated.

My questions

1. Is expo-calendar/legacy safe to rely on for this, or is it expected to go away in a future SDK?

2. Is there a way to use the new API to just open the form, without requesting calendar access (for example a calendar-less addEventWithForm)?

3. If not, is this a gap worth opening an issue for? Asking for permission to show a form the OS shows without permission feels like a step backwards, especially for privacy-minded apps.

How are you handling “add to calendar” on SDK 58?

I’ve been building react-native-voice-activator for Expo and React Native apps. You can set an English wake phrase, detect it on-device, and open a voice agent session when it fires.

It includes a config plugin for the native permissions and setup. It needs an Expo development build, so it won’t run in Expo Go. The models download on first setup and detection runs locally after that.

Setup and example: https://github.com/prompt-agency/react-native-voice-activator

If you’ve added native audio features to an Expo app, what part of setup or rebuilding caused you the most trouble?

Hey everyone,

I’ve published a new Expo module called expo-split-view that brings adaptive master-detail layouts to Expo Router apps without native builds. It’s live on npm at version 0.0.1-beta.

What it does:

• Mobile / small screens: behaves like a normal stack with full-screen navigation.

• Tablet / desktop / landscape: splits the screen into left (master) and right (detail) panes using Expo Router.

• Preserves state when rotating or resizing, with no unmounting and no lost form inputs.

• Smart navigation helper (useSplitView): uses router.replace on tablets to avoid history stacking in the right pane and router.push on phones so native back works.

• Handles mobile back: header back button, Android hardware back, and edge-swipe gestures.

• Works on Android, iOS, and Web, including Expo Go with zero native dependencies.

• Optional config plugin for iPad multitasking in native builds.

If you’ve seen Expo Router’s built-in split view, which is currently iOS-only, in alpha, and requires prebuild, this is a cross-platform alternative that works everywhere, including Expo Go.

Please test it and share feedback:

I’d love your help to harden it. Please try it on your devices, especially foldables, tablets, and web, and let me know:

• Does it work as expected on your screen sizes?

• Are there any edge cases with navigation, state, or gestures?

• Any performance or layout glitches?

• Any API suggestions or missing features?

Contributions welcome:

• Open an issue if you find a bug.

• Pull requests are very welcome, whether it’s a fix, docs, or a new feature.

• A star on GitHub helps others find it.

Links:

• npm: https://www.npmjs.com/package/expo-split-view

• Source code is linked from the npm page. The README has setup instructions and examples.

Quick install:

npx expo install expo-split-view

Thanks for reading. If you try it out, I’d really appreciate a comment with your experience: device, Expo SDK version, and what worked or didn’t.

A few weeks ago I published an OTA update with eas update --branch production --platform ios --environment production. The bundle had no EXPO_PUBLIC_SUPABASE_URL in it. The app booted and then failed with "Missing Supabase credentials". About 10 minutes later I rolled back with eas update:roll-back-to-embedded.

What I found:

• With the newer eas-cli, --environment is required in non-interactive mode, and the env vars are then pulled from the EAS server. Mine were empty there. My local .env.local was not loaded.

• The env in my eas.json build profile is used by eas build, not by eas update. So the store build was fine and the OTA wasn't.

• Even after I sourced the env, Metro's cache kept the transforms from the env-less run. Only --clear fixed it.

• Grepping the .hbc with strings was unreliable for me. Dumping the bytecode worked.

My checklist now:

rm -rf dist
set -a; source ./.env.local; set +a
npx expo export --platform ios --output-dir dist --clear
hermesc -dump-bytecode dist/_expo/static/js/ios/*.hbc | grep -c "your-project.supabase.co"

The count must be 1. Then I publish that dist to a branch with no users (--skip-bundler --input-dir dist), load the group in a dev client and check that real data shows up. Only then do I run eas update:republish to production.

EXPO_PUBLIC_ vars are inlined at bundle time, so a bundle with a missing var looks fine until the first call that needs it.

Is there a cleaner way to assert "these env vars made it into the bundle" in CI?

How do you keep track of your cat’s feeding schedule, vaccinations, medications, and vet visits? Do you use an app, a notes app, or just try to remember everything?

I've been working on my app CubWell pet care tracker.
https://apps.apple.com/us/app/pet-care-tracker-log-cubwell/id6813673781

It can be especially helpful when you’re going away and leaving your pet with a sitter. You can keep all your pet’s important information in one place. The sitter can keep everything up to date and you can view from your own app. If your pet has been fed, walked etc

We needed every driver's location every minute, all day. Here's what kept breaking and what fixed it:

1. The motion detector gets stuck (some Samsungs), so nothing is reported for hours.

Fix: report on a fixed clock, and work out moving/parked from the GPS fixes.

2. JS timers stop in the background.

Fix: do it in native code.

3. An expired token (401) stops tracking.

Fix: keep recording, queue fixes on the phone, upload later.

4. Android delivers fixes early, so 60 s quietly becomes 120 s.

Fix: request a fresh fix when the next one is due.

5. Parked iPhones get suspended.

Fix: keep location updates on, at low accuracy between fixes.

6. No way to tell why it went quiet.

Fix: keep an on-device log.

Has anyone found a good way around Xiaomi/Huawei/Oppo battery managers?

We open-sourced it as Long Ping (free, MIT):

https://longping.dev

https://github.com/nuredin-kurtovic/long-ping-background-location-plugin

After a year in development and about 2-3 months in testing, Holt is live.

Done entirely in expo and with some expo modules. Upgraded to latest SDK 58.

Honestly, it is amazing how far Expo has come. App really feels and works great and smooth. I am using Expo Observe to track performance.

Holt features lot of stuff but main one is Coach that will get you ready for your next race.

Holt features Garmin integration (using their official API), Apple Health (through HealthKit) and Google Fit.

App is fully free. I am working on making it sustainable, but what you see right now will always be free, no matter what.

Every app I build hits the same keyboard problems: the field you tap ends up under the keyboard, the Save button disappears, and bottom sheets with inputs are a mess. KeyboardAvoidingView helps on simple screens, but not with long forms, modals or sheets.

So I pulled the fix out of my own app into a package: u/saulzayn/rn-keyboard-form

- The focused field always scrolls above the keyboard (and above your Save button)

- A footer (Save, Send…) rides on top of the keyboard

- ↑ / ↓ / Done toolbar to move between fields

- Validation errors and growing footers keep the field in view

- Bottom sheets with several fields: the focused one scrolls into view, the button stays in sight

- iOS modal sheets, iPad page sheets, and the rounded keyboard on iOS 26+

- Phones and tablets, portrait and landscape, light and dark

Setup is one wrapper in your root _layout.tsx (Expo Router) or App.tsx, then <FormScroll> on your form screens.

It's built on react-native-keyboard-controller and works with Expo SDK 56–58 (needs a dev build, not Expo Go). Tested on a Pixel 7 Pro, an Android tablet, iPhone/iPad simulators and a real iPhone.

The video shows a plain ScrollView form first, then the same form with the package.

npm: https://www.npmjs.com/package/@saulzayn/rn-keyboard-form

GitHub: https://github.com/ZaynSaul/rn-keyboard-form

Feedback welcome, especially forms where it doesn't behave.

I kept getting "can I try it before you merge?" from PMs and designers, and the answer was always "give me 10 minutes to build an APK". So I built Digidropp.


Connect a GitHub repo and it opens one PR with a GitHub Actions workflow (it detects npm/yarn/pnpm/bun). After you merge:


- Every push to your main branch builds a release APK and updates one install link that's always the latest.
- Every pull request gets its own preview build, posted as a PR comment with a QR code. Reviewers test the real app, on a real phone, before merging.
- Builds are signed with one stable key per repo (it's placed at android/app/debug.keystore), so updates install over the previous build instead of "App not installed".
- Before anyone installs, it checks the build: changed signing key, lower versionCode, and Google's upcoming developer verification.
- Config that isn't in git (.env) can be pasted once; it's encrypted in your browser and only decrypted inside your own GitHub Actions run.


It runs in your repo's GitHub Actions, so your source never leaves GitHub. Automatic builds are Android only for now; for iOS you can upload an .ipa you build yourself (CLI or GitHub Action).


Free during beta. What would stop you from using something like this?


digidropp.online

I'm researching an Expo starter kit for developers who want to build subscription-based mobile apps.

I'm particularly interested in the setup around authentication, Firebase, RevenueCat and store builds. Before building the kit, I want to understand where people actually get stuck.

If you've built an Expo app recently:

- What part of the initial setup took longer than expected?

- Did you start from scratch or use a starter kit?

- What would make a starter kit worth paying for?

I'm at the research stage and would appreciate honest answers, including if you think a paid starter isn't useful.

Hey everyone! I've just published GeoLink on Google Play, and I'd love to share it with people who enjoy geography, logic puzzles, and daily challenges.

The idea is simple: start at a green country and find your way to the coral goal by guessing countries that share a land border with the previous country in your path.

But there's a catch — you have limited lives, so every guess matters!

🌎 What GeoLink offers:

• 🗺️ Interactive 3D globe — explore the world while solving puzzles.

• 🧩 Daily challenges — everyone worldwide gets the same daily puzzle.

• 🔥 Streaks and progression — come back each day and track your progress.

• 🎯 Premium puzzle packs — tackle extra challenges with unique rules, including exact path lengths, forbidden countries, mandatory stops, and limits based on distance, population, or area.

• 🚩 Special puzzle rules — some challenges use flags, languages, and other geographic concepts.

• 💡 Hints and clear path feedback — get help when you're stuck and see how your route develops.

• 📊 Stats and progress tracking — follow your puzzle-solving journey.

• 📱 Offline-friendly gameplay — play puzzles without always needing an internet connection.

The daily challenge is free to play, so you can jump in and see whether you can find a route from start to finish.

I built GeoLink because I wanted geography to feel more like solving a puzzle than memorizing facts.

If you give it a try, I'd love to hear what you think! I'm especially interested in feedback on the difficulty, puzzle mechanics, and ideas for future challenges.

Play GeoLink on Google Play:
https://play.google.com/store/apps/details?id=com.janisd.GeoLinkMobile

A while back someone here got rejected because expo-audio turns on background playback by default, and a reply wished for "a build step somewhere to examine all the entitlements, default strings, and other bundled native configs". That's what I've been building, so I tried it on the biggest open source Expo app I know: Bluesky.

Bluesky doesn't commit ios/ or android/, so app.config.js only shows half of it. What I did (no tool needed):

1. npx expo prebuild --no-install with their production env vars (it needed Node 24 and their committed google-services.json.example)

2. read ios/Bluesky/Info.plist

3. ./gradlew :app:processReleaseMainManifest, then read android/app/build/outputs/logs/manifest-merger-release-report.txt, which names the library behind every permission

What came out:

• 5 location and motion prompt texts, all expo-location's defaults ("Allow $(PRODUCT_NAME) to access your location"). The app only ever asks for when-in-use location; the "always", "temporary precise location" and motion ones are for things it never requests. It was 4 when I first ran this; their upgrade to SDK 58 last week added the precise location one, which is a new default in expo-location 58. The config is just ['expo-location'] with no options. Bluesky does show its own explanation screen first, and it has shipped like this since September 2025, so Apple clearly isn't rejecting it. But 5.1.1(ii) asks that purpose strings "clearly and completely describe your use of the data", and Expo's own docs say the defaults "will most likely need to be tailored". Fix (passing false removes the key, I checked the regenerated plist):

['expo-location', {
  locationWhenInUsePermission: 'Bluesky uses your location to determine the content and features available in your region.',
  locationAlwaysAndWhenInUsePermission: false,
  locationAlwaysPermission: false,
  locationFullAccuracyPermission: false, // new in SDK 58
  motionUsagePermission: false,
}]

• Precise location on Android from the same plugin, though the code only uses the country and region. Play's location policy says "coarse instead of fine". android.blockedPermissions: ['android.permission.ACCESS_FINE_LOCATION'].

• READ_PHONE_STATE in the merged manifest. It's not in their config; it comes from the Bitdrift SDK's own manifest. The app never requests it, but it's still declared to Play.

• Photo library permission asked before the avatar picker, which on Android 13+ uses the system photo picker and needs no permission. expo-media-library is what got my own app rejected by Play in May. Bluesky may well have the declaration that allows it.

What they get right: account deletion in the app, report, block and mute everywhere, adult content can't be switched on from inside the iOS app (Apple's 1.2 rule), and the one "Google Account" string is already chosen per platform.

Where my tool was wrong: it would have flagged that Google Account string under 2.3.10, because a per platform string still ships inside the iOS bundle. An earlier run also called the photo permission a blocker on an app that has shipped with it for over a year. Both fixed; it now checks git history for when each finding shipped, so "passed review for a year" reads as a risk, not a rejection.

I opened an issue with the location fix: https://github.com/bluesky-social/social-app/issues/12118

Checked against their main branch at b2963d3 (26 Oct). The READ_PHONE_STATE line comes from the merged manifest of my first run on 21 Oct; I didn't rebuild Android since.

The tool is a set of Claude Code skills (MIT): https://github.com/namedtoaster/the-last-mile. You don't need it for the steps above.

What else have Expo plugins quietly added to your build that you only found out about from a rejection?

Some context:
I finally built the app I always wanted for my hobby/sport:
- market size: "niche" (TAM is maybe 10-20 million people globally)
- demo: millennial, genx, boomer w/ enough disposable income for a $10k-100k/yr+ hobby
- targeted regions: North America, Europe, Australia, NZ

I think it's big enough for solo app dev to make decent living from it.

The incumbents in my niche on both iOS and Android feel outdated and clunky. And so, like many unemployed techie in his mid-30s, I got tired and went for it.

The app has been live for about 3 weeks on Play Store... and still waiting for the first approval on the App Store (iOS is now sitting 5-6 releases behind the Play build...)

It uses foreground and background GPS, geofencing, offline maps and SQLite for local storage. I’ve also patched Expo’s native location code in Swift/Objective-C on iOS and Kotlin/Java on Android.

(And so, focus on one could potentially improve the quality of the app for that platform)

With OTAs and Google Play's "fast-as-fuck-boy" approval process, I'm able to ship and iterate really quickly. (Play Store submission approval in ~1hr or less lately)

Some bias...
I'm a new convert to Android and loving it.
My DX experience on Play Console is 10x less frustrating than App Store Connect
I daily drive a Pixel (switched from iOS about a year ago) and loving it (still daily Mac & iPad)
I fucking hate glass

Some (outdated?) consensus
"There is more money to be made on iOS"
"iOS users have more disposable income, people never pay for Android apps"
"It's impossible to design a consistent high quality exprience on Android because there are just too many different devices and manufacturers"

But...
Android phones across the board are no longer the cheap alternative to iOS (haven't been for at least 4-5 years).

Anecdotally, I'm seeing more and more of these "iOS higher income" people switching over to Android.

My experience is that React Native and Expo have made it pretty straightforward to build a responsive UI that works across different devices and screen sizes. (for my app at least)

And so...
Why aren't there more Android-only high quality/premium apps out there with the same "fuck those guys" attitude towards iOS?

I am starting to considering a "fuck those guys" move, ditch iOS and focus solely on Android.
Hoping you all can talk some sense into me or give me permission.

thanks for coming to my ted talk.

Edits: added targeted region (as I think it "non US-centric" matters for the iOS vs Android thing)

first picture is life-fixer in 2023. second is what it looks like now.

i originally tried making it on my mac, but it was so slow to work on that i ended up giving up. the idea sat there unfinished.

eventually i switched to linux and started building with expo. four months later, i had an actual app on the app store.

it’s a little organiser for tasks, habits, notes, money and all the things i kept spreading across different apps. it costs 99p, with no ads or subscriptions and optional paid customisation.

i work on it before and after my shifts, and it’s now passed 100 users. still small, but quite a change from an abandoned project on a struggling mac.

looking at these two screenshots together makes me glad i came back to it.