WHY WE CHOSE EXPO APPLICATION SERVICES (EAS): A JOURNEY TOWARD SIMPLICITY

There’s a moment in every engineering team’s life when someone squints at the CI/CD dashboard, sighs deeply, and says, “There has to be a better way.”

For us at Essent, that moment arrived when we received a security report listing a gazillion vulnerabilities in our macOS runners. Add to that the ever-growing headache of managing certificates, provisioning profiles, and complex build pipelines, and we knew it was time to explore alternatives.

Around the same time, Expo had finally matured and stabilised enough for serious production use. We decided to give it a shot—not because it was new and shiny, but because it promised to solve real problems and simplify our life as mobile developers.
And that’s how our journey toward Expo Application Services truly began.

Where we started: A solid but heavy setup

Before Expo entered the picture, our mobile ecosystem was built on:

• A React Native CLI project
• Native iOS and Android modules for bridges and extensions like widgets
• Fastlane for managing builds, signing, and store submission
• macOS runners powering our pipelines
• Certificates and authentication stored in gitlab repository and managed through Fastlane
• GitLab pipelines handling everything from:
  - Creating builds
  - Uploading to TestFlight
  - Promoting to alpha testers
  - Preparing releases for production
  - Auto-submitting for Apple & Google reviews

It worked.
It had character.
It had battle scars.
But it was also becoming… a bit of a diva.

The issues & vulnerabilities that piled up

1. Certificate & credential management
   Fastlane did a great job wrangling certificates — but the process was fragile, and a single outdated or corrupted certificate could derail the entire release pipeline. (At one point, we considered giving the certificates their own employee onboarding.)
2. Custom pipelines = custom pain
   We wrote and maintained our own CI/CD pipelines, which meant:
   - More code to maintain
   - More knowledge locked inside specific developers’ heads
   - More opportunities for mysteries like: “Why does this script exist? Did anyone write this? Was it generated by AI in 2018?”
3. macOS runners
   Managing macOS infrastructure felt like maintaining a slightly temperamental pet:
   Needs constant updates
   Breaks unpredictably
   Eats developer time
   And on top of that: security vulnerabilities we had to constantly patch.
4. High costs & overhead
   Time is money, and maintaining custom infrastructure consumed both.
5. Knowledge silos
   Only a few developers truly understood how everything worked end-to-end — creating bottlenecks and risk.

What we really wanted

After enough battles with certificates, runners, and pipeline headaches, we agreed on a shared vision:
A simple, managed, controlled solution with minimal maintenance overhead.
We didn’t want to reinvent the wheel anymore.
We just wanted a wheel that stayed round.

Enter Expo Application Services (EAS)

For the uninitiated, Expo Application Services is a cloud-based platform that handles:

• Building iOS & Android apps
• Managing credentials
• Submitting to app stores
• Supporting Over-the-Air (OTA) updates
• Simplifying project configuration
• Providing consistent workflows across teams

Imagine all the complexity of managing mobile builds — but with the knobs, levers, and hidden traps handled by a platform instead of your DevOps team.

Why we chose EAS: The big wins

1. A cleaner project setup
   Expo simplified our React Native configuration and helped remove unnecessary custom scripts.
2. Secure, managed credentials
   Expo takes over the responsibility of generating and storing certificates. No more “who touched the provisioning profile” investigations.
3. Build for multiple platforms at once
   With a single command, we can build iOS and Android in parallel.
4. Faster iteration & feedback
   Developers get builds faster, reducing wait time and improving productivity.
5. Easier distribution
   TestFlight and Google Play publishing became smoother — and less dramatic.
6. Over-the-Air (OTA) updates
   One of our favourite perks. Minor fixes don’t need full store releases anymore — they can be deployed instantly.

How EAS solved our business problems

• Decommissioned macOS runners
  Goodbye vulnerabilities, manual updates, and hardware maintenance.
  You’ve served us well, dear runners, but it's time to rest.
• Comparable costs, lower headaches
  EAS pricing is roughly the same as our previous infrastructure — but with far less work for developers.
• Less pipeline maintenance
  No more complex custom Fastlane scripts or runner management.
• Better, faster app distribution
  The organisation benefits from faster turnaround times and more stable build processes.

Proposing Expo to Essent’s Tech Radar

At Essent, adopting a new technology isn’t something we do on a whim.
We follow a structured governance model to ensure every decision is deliberate, well-evaluated, and aligned with our long-term strategy.

Two groups guide this process:

• Tech Radar — the framework we use to evaluate, trial, adopt, or phase out technologies.
• Tech Crew — the team responsible for reviewing, challenging, and approving proposals

Once we gathered enough evidence that Expo might be the right direction for us, we started formalising the journey.

Here’s how Expo moved through the process:


0. Created an ADR for Mobile App Developers
Before anything else, we documented our context, reasoning, and initial decision direction in an Architecture Decision Record (ADR).
This ensured all mobile developers were aligned, informed, and involved from day one.
The ADR laid out:
• our current challenges
• why Expo was being explored
• expected benefits
• initial risks and unknowns
This set the stage for a structured evaluation.


1. Submitted a trial proposal
With the ADR as our foundation, we submitted a formal trial request.
We outlined:
• our existing issues (certificates, runners, vulnerabilities, pipeline complexity)
• how Expo could potentially address them
• what we aimed to validate in the trial phase

2. Built a Proof of Concept (POC)
A practical, working example with expo managed project. Clear, functional, and most importantly: it validated our assumptions.

3. Created a detailed adoption proposal
Once the POC proved promising, we produced a comprehensive proposal covering risks, benefits, cost estimates, and architecture impact.

4. Presented to Tech Crew
Once we submitted the proposal we were invited to the next tech crew meeting.
We showcased our findings to the Tech Crew with slides, metrics, honest trade-offs, migration roadmap and a fair amount of enthusiasm.
The discussion was collaborative and critical—exactly how it should be.

5. Pricing & budget review
Together with our engineering manager, we evaluated:
• pricing of Expo’s paid tiers
• comparison with maintaining macOS runners
• long-term operational costs
• expected developer efficiency gains
The numbers aligned.

6. Approvals & contract signing
Once everything aligned—from technical proof to financial viability—Expo was approved and formally integrated into our technology ecosystem.

The result?
Green light.
Cue the migration…