Expo developer for EAS Build and OTA updates
I work with Expo every day: moving builds off a single laptop, shipping fixes over the air, catching up on skipped SDK versions and moving navigation to Expo Router, without restarting the project.
- Expo SDK
- EAS Build
- Expo Router
- TypeScript
- OTA updates
Built for teams with an Expo app in production
The usual case is an app that started in Expo and now asks questions the managed workflow does not answer on its own: a build that only runs on one machine, an SDK jump postponed for two releases, a store submission with no repeatable process. If the question is less about Expo and more about the app underneath, the React Native developer page is the better fit: taking over an existing app, bridging to native code, performance.
Where Expo projects get stuck
The app itself works. What breaks is the path from a change to the device of a user, and it is usually one of these six.
The build lives on one machine
Releases come out of a local Xcode and Android Studio setup. When that machine dies or that person leaves, shipping stops with it.
The SDK upgrade keeps waiting
Every skipped Expo SDK version makes the next jump bigger, because dependencies, build tooling and native modules all have to move at once.
A typo needs a store review
A one line copy fix waits for review even though no native code changed. That is exactly what over the air updates are for.
Navigation grew by accident
Screens live in two routing systems side by side, deep links land on the wrong screen, and nobody can say which route belongs where.
One native library is missing
The single feature the managed workflow does not cover blocks the whole release. Config plugins and prebuild are the way around it.
Credentials are scattered
Certificates, provisioning profiles and the keystore sit in personal folders. The first handover turns a release into a search party.
What I do on an Expo codebase
Book one piece or all of it. Most projects start with the build pipeline, because everything else gets easier once a release is reproducible.
EAS Build
Builds run in the cloud instead of on a laptop. Credentials are stored in one place and anyone on the team can cut a release.
EAS Submit
Finished builds go to App Store Connect and the Play Console automatically, including a lane for TestFlight and internal testing.
Over the air updates
Changes to JavaScript and assets reach installed apps without a store review. Separate channels for staging and production, with a way back to the last good build.
Expo Router
File based navigation with typed routes, deep links and shared layouts. Also available as a migration from React Navigation.
SDK upgrades
Moving to the current Expo SDK version together with its dependencies, in reviewable steps and with a test pass on both platforms.
Config plugins and prebuild
Native settings and libraries get described in code instead of clicked in Xcode, so every prebuild produces the same result.
From first look to a repeatable release
After handover you either carry on in house or keep me on app maintenance, monthly instead of project by project.
Read the project
I go through the repository, app.json, eas.json and the last build, then write down what is actually holding up shipping today.
Agree on the order
Build pipeline, SDK jump or navigation: one of them goes first. Each step gets a scope so none of them turns into open ended work.
Ship in small steps
Work lands through pull requests and every step ends in a build, so you have an installable version after each one.
Hand it back
Pipeline, update channels and credentials are documented and live in your accounts. No knowledge stays with me.
Tell me where the app is stuck right now
One paragraph is enough: which Expo SDK version you are on, how the app gets built and what failed last. You get an assessment of what to fix first instead of a sales call.
Questions about Expo work
Yes, that is a well bounded job. First I check how many versions sit in between and which native modules are affected, then I tell you whether this is closer to a day or closer to two weeks before you commit.
Anything in JavaScript and in your assets can go straight to installed apps through EAS Update. New native code, meaning a new SDK or a new native library, still needs a store build. So the two are kept apart: small fixes over the air, bigger jumps through the stores.
No. Config plugins and prebuild keep the native configuration generated and still customisable. Only when that stops being enough do the ios and android folders get committed for good. I take that step when a feature really requires it, because coming back is expensive.
Yes. Next to React Native and Expo I work with Kotlin and Jetpack Compose for native Android. That helps when a problem sits below the JavaScript layer and somebody has to read the native build.
With read access to the repository and one build I run myself end to end. Only then do I say what I would change. An estimate without looking at the project would be guesswork.
I work from Germany in Central European Time and handle projects in English and German. Written communication is the default, calls when a decision needs one.
Let's build something great together.
Have a project in mind? I'd love to hear about it. Send me a message and I'll get back to you as soon as possible.
