Jeppesen ForeFlight: taking mobile to new heights in aviation

Air travel is still one of the safest forms of transport there is. But there’s a lot that goes on behind the scenes to keep it that way. Chief among them is giving pilots access to precise, up-to-the-second information so they can make the right call at the right moment.

Few companies understand that better than Jeppesen ForeFlight.

The company combined forces last year, bringing Jeppesen’s 90-year legacy of aeronautical data together with ForeFlight’s cutting-edge technology to redefine the aviation experience and give pilots the critical insights they need to fly safely and efficiently. 

We sat down with Nathan Hillyer, head of the company's mobile platform, to learn how Bitrise frees his team from infrastructure upkeep so they can focus on setting the standard for air safety and reliability. And why "uneventful" is the word they love hearing most from customers. 

About Jeppesen ForeFlight

Nathan, let's start with what your role is at Jeppesen ForeFlight.

[Nathan Hillyer] I'm the Director of Engineering for our mobile platform, leading what's known as our Electronic Flight Bag (EFB) platform. Essentially it's a series of mobile apps that give pilots the information they need before and during a flight, including crucial things like real-time weather updates, navigation maps and other flight-related details.

While pilots are the ultimate end users of our apps, our focus day to day is on the engineers building and shipping to those pilots. Our goal and what motivates us is to enable those engineers to work efficiently so they can deliver the best aviation experience for pilots.

How has the transition to becoming an independent company changed your focus?

[Nathan] Previously, our guiding mission was to create software that made flight planning easier. Today, as Jeppesen ForeFlight, that mission is much broader.

Our work starts much further back in the process with something as simple as calling a small airport somewhere in the world to confirm the length of a runway. That data is then fed into our systems, and published in our apps, aviation charts and other products.

Now,our goal is to combine Jeppesen's legacy of precise aeronautical data with ForeFlight's digital-first aviation technology to build the software that powers every flight, every mission, and every operational decision across the aviation industry.

What impact has that change had on your mobile strategy?

[Nathan] Bringing the two companies together has definitely expanded our scope in mobile. We now have multiple major workstreams. Originally it was just ForeFlight and Flight Deck Pro, our regulated airline EFB product. Now we've also added Aviator.

On top of the apps themselves, we also have the shared libraries and infrastructure that power them, which will rely on Bitrise too.

A big part of our focus over the last six months has been figuring out how all these different areas of the company fit together so we can support them as the EFB platform.

Your mission is to deliver the most unified, intuitive aviation experience possible. How important is mobile in making that a reality?

[Nathan] Mobile is really the product that cuts across our entire portfolio. Whether pilots or crew members are using an iPad or iPhone in the cockpit, our app is the primary interface they have with our service.

In many organisations, mobile is the companion to the web product. For us, it's the other way around. That means we need to ensure that every release we ship to the App Store is reliable, consistent and tested thoroughly.

I'd say our approach is closer to firmware development than standard mobile app development because of how critical our service can be. When one of our apps fails, it doesn't just result in an annoyed or frustrated user, it could have serious consequences. That's why release discipline is so important for us. CI is a big part of that, in helping to ensure our app is built in a consistent and safe way.

Jeppesen ForeFlight's journey with Bitrise

What challenges were you facing before moving to Bitrise? 

[Nathan] Back then we were still operating as ForeFlight, and I'd just become Director of the platform organisation. I spoke with our DevOps engineers to understand the biggest challenges they were facing. They were swamped with machine maintenance, and every new Xcode release meant dropping everything to get our infrastructure working again.

One of the team recommended Bitrise after using it at a previous company, so not long after stepping into the role, I started looking at whether it would be a good fit for us.

What CI/CD setup were you using before Bitrise, and where was it falling short? 

[Nathan] Before Bitrise, we'd been using TeamCity, a JetBrains product. We were self-hosting our own build agents instead of having hosted infrastructure. Essentially we had a closet in our office repurposed as a Mac Mini data center. I’d say our challenges back then were really twofold.

Our first challenge was with the TeamCity platform itself. As far as we could tell, mobile seemed to be more of an afterthought for them. We were constantly troubleshooting issues around changes not appearing in CI in a timely fashion, and we just couldn't figure out why. We worked with their support team, but they couldn't solve it either. The mobile focus and expertise just wasn't there, and that was a real problem for us.

The second challenge was the raw infrastructure and the amount of electricity and maintenance needed to keep a bunch of build servers running in our office. We build software for pilots, we don't want to be a data centre.

We were also thinking ahead to where we wanted to be in a few years' time, which is basically where we are now, about two years after moving to Bitrise. By the end of this year we'll have about 50 build agents in Bitrise. There are just physical limits to the space we had in our office, and had we not moved to Bitrise, we'd be running into those limits now. There's no way we could have supported that scale ourselves.

What were your top priorities when evaluating a new mobile CI/CD solution, and how has Bitrise measured up?

[Nathan] I was looking for a solution that would let me define and set direction for more creative work. For example, where we could improve the product and support our developers, rather than just keeping machines running.

As well as Bitrise, we also looked at a solution called Cirrus. It was a lot cheaper for the number of agents we needed, but we had some concerns about the team behind it. I think they were only a two-person company, and we were a bit skeptical about how they could offer such low prices. We knew Bitrise had established a good reputation and had a lot of experience in the space, and one of our engineers, Danny, had used it at a previous company and was happy to recommend it. So even though Bitrise was at a slightly higher price point compared to Cirrus, we knew it was the best choice. Thankfully we trusted our instinct as Cirrus was later acquired by OpenAI and has recently shut down without much notice leaving customers scrambling to find another solution.

I'd say the final thing that swayed us in favour of Bitrise was the fact that Arpad Kun, VP of Engineering, happens to be a pilot and ForeFlight user, so we knew he'd understand the importance of what we were trying to deliver. We've been partners from the get-go, and a lot of the feedback we provide eventually finds its way into the Bitrise product, so we've been really pleased with how the partnership has developed.

What's been the biggest change for your developers since moving to Bitrise?

[Nathan] It's allowed our team to think at a much higher level. Instead of being focused on keeping the lights on day to day, we can think ahead into the future and come up with creative solutions that increase the productivity of our team. Whether that's improving our build distribution system or enabling more automated testing, it's just about having the time to think on a different level.

Before Bitrise hosted our infrastructure, our focus was always on how to keep the lights on by the end of the week. As well as keeping our build agents up to date and making sure they were consistent. Now with Bitrise, that's all gone away. It takes care of that critical but time-consuming work, which has really unlocked the creativity and potential of our DevOps engineers.

Now we can spend our time talking to engineers, understanding their pain points, and actually building solutions to address them. I've got two engineers, Jake and Danny, and they're both much happier now. Instead of focusing on basic maintenance, they're solving more complex problems that are specific to our domain, and that's a much better use of their time.

Moving from Bitrise CI to Build Hub

You recently moved to Build Hub, can you share what prompted that change?

[Nathan] As we scaled, there was a drive to standardize on GitHub Actions across the company, so it made sense for us to make that move too. However, the challenge we faced was how to run our Mac builds. It was clear that GitHub-hosted Mac runners weren't sufficient for our use case. They didn’t work consistently and cost was also an issue.

So when Bitrise Build Hub became available, we wanted to get on it as soon as possible. We restructured our contract last year to switch over, and we've been very happy with it ever since.

As more teams across the business adopt GitHub Actions, having that Mac infrastructure already in place has been a huge advantage. Teams can migrate without relying on more expensive GitHub-hosted runners or having to self-host and maintain their own infrastructure.

How was the migration from Bitrise CI over to Build Hub?

[Nathan] It was pretty seamless. We'd already gone through a TeamCity to Bitrise migration, so moving to Build Hub was pretty straightforward. It took a few weeks to move everything over and port our jobs to GitHub Actions, but we didn't see any service disruption or performance degradation during the migration or after it. In fact, there was minimal change, which was exactly what we wanted.

The best part was that everything was integrated into a single application. Our developers were pretty happy that they didn't need to log on to a different service to look at build logs anymore; everything was right there in the GitHub interface. And of course, no downtime was a huge plus.

Which Build Hub features have had the biggest day-to-day impact?

[Nathan] Ephemeral runners are probably the biggest one. Having every job start from a clean state, without worrying about leftover state or flaky builds, is a huge benefit.

It also lets our developers write and iterate on their own workflows without fear of breaking our core CI/CD. That's been a big help towards our goal of democratising CI, as it gives our teams the ability to build purpose-built workflows independently. We needed a model that let developers work without stepping on each other's toes, and ephemeral runners are a key part of achieving that. This capability is especially crucial now as we scale to a 4,000+ person organisation with a two-person mobile DevOps team.

Having Xcode images ready to go in around 24 hours of a new release is excellent too. It probably saves us a week of engineering time on a regular basis because we don't have to update every agent by hand. We can switch to a new Xcode version within 24 hours of release instead of reimaging every machine.

The larger runners have been great as well. We used to manage a mix of M1, M2, and M4 Mac minis, but Bitrise regularly upgrades the hardware, so we can simply reprovision our agent pools instead of deprecating and replacing hardware ourselves.

You also tested GitHub-hosted runners at one point. How did that go?

[Nathan] We're an evidence-driven team, so it's part of our culture to continuously test any obvious alternatives. We were parallelising parts of our codebase to run smaller sets of tests on different agents, and one of the things we wanted to evaluate was GitHub-hosted runners alongside our core CI/CD on Build Hub.

The prototype worked fine, so we merged it into production. Then it was a completely different story. We started seeing random failures, some network instability and memory pressure. Within about a week, we reverted back to Bitrise entirely and realised that GitHub-hosted runners, at our scale and with our codebase, just aren't practical.

I have to say, that was not a fun week, and not one I'd like to repeat.

Overall, what's the biggest impact you've seen from moving to Bitrise?

[Nathan] From an operational perspective, one of the biggest benefits is that we were able to avoid hiring another engineer. We had a backlog of projects to deliver, but the team was so busy with Xcode updates and infrastructure maintenance that we never had the capacity to get to them. Moving to Bitrise freed the team up to deliver those projects ourselves. Not only did we save the cost of another engineer, but we also enabled the team to focus on the more innovative work they enjoy doing.

We've also seen measurable improvements in build times. We adopted the Bitrise Build Cache feature, and by our measurements it's saving around 20 to 30 hours of build time every month. We're also modularising our codebase so we can parallelise builds across the CPU, saving even more time. Our build telemetry estimated the cost of local build drag at roughly six figures a year in engineering time, so CI infrastructure was the first place we tackled it.

Before Bitrise, testing a new Xcode beta in CI could take us a month or two, because getting it onto a self-hosted Mac agent was always a lower priority. Now we just update the Xcode version in the configuration and start testing immediately, so we can catch compiler and compatibility issues much earlier.

We've also structured our contract so we can add capacity throughout the year. Even as AI tools increase code volume, we haven't had any major queuing issues for months, aside from one incident back in the spring. Infrastructure-related failures have more or less disappeared as a category. A red build now usually means the code is wrong, which is exactly what a red build is supposed to mean.

Last but not least, our team's identity has really changed. We used to be infrastructure maintainers. Now we're platform engineers who can focus our time on build configuration, developer experience, and reducing build times.

Looking back, what outcome are you personally most proud of since moving to Bitrise?

[Nathan] The outcome I care about most is trust. It’s hard to measure but it shows up in developers believing in the pipeline, and knowing that if they see a failure, it's taken seriously and addressed fast. We measure that qualitatively through periodic developer experience surveys, and we've seen real improvement in the level of trust our team has in our infrastructure.

In the old setup, when I was a developer myself, if you noticed a failure your first thought was always, "well, what went wrong in CI this time." Now it's, "what did I do wrong and what do I need to do to fix it." That's one of the biggest shifts we've achieved.

What's the single most important thing for the developers you support, and ultimately for the pilots and crew members using your products?

[Nathan] Confidence, without a doubt. Developers need confidence that the code they're writing will work, and that it's been built and tested reliably on more than just their own machine.

Our developers need confidence that the code they're writing will work, and that it's been built and tested reliably on more than just their own machine. Ultimately, that's what our end customers, pilots and crew members, care about too. Everyone loves cool new features and a great UI, but what we hear people asking for most is reliability. Whether it's ForeFlight, Flight Deck Pro, or Aviator, they want the assurance that everything will work when they need it and Bitrise gives us the ability to deliver exactly that.

AI and the future of mobile at Jeppesen ForeFlight

With AI accelerating code creation, how is that showing up in your CI and testing?

[Nathan] It's definitely leading to more pressure, as it shifts the bottleneck. I think a lot of organisations are experiencing this real-time shift from code generation to code validation.

It's allowing us to generate a much higher volume of code, but that doesn't necessarily translate into a higher volume of shipped outcomes. The bottleneck is now reviewing that extra volume of code and making sure it meets our quality and safety standards.

A big focus for our team is developing automated quality gates to remove, or at least reduce, the validation bottleneck now that code generation can happen so much faster.

On testing specifically, we have some experimental work aimed at more holistic, system-level testing with personas. Essentially we are modelling different types of users inside our ecosystem and using automated tests to simulate them. That's still running on a couple of small agents we maintain ourselves, using the XCUITest framework, and we'll move it to Bitrise agents once it matures. Our main automated testing target already runs on Bitrise, that's about 18,000 tests across the whole test pyramid, from unit to integration tests. It's our primary blocking job; it has to be green for anyone to merge. We're hoping to build more of a user-focused testing job, rather than a purely technical one, to address these AI-driven bottlenecks.

How do you see the role of mobile evolving at Jeppesen ForeFlight as the business continues to scale?

[Nathan] Mobile will continue to be a top priority. Right now, we're focused on the same challenges as many mobile teams: preparing for iOS 26, continuing to optimize our build time through modularization, parallelising our build graph, and binary caching, as well as expanding automated UI testing to replace more of our manual testing.

It’s funny as we talk a lot internally about making things as boring as possible. That might sound like an unusual goal, but to us it's a positive thing. We want everything to be predictable. If our app experience is uneventful, we’re doing our job well.

Bitrise is a big part of that. Larger runners, ephemeral capacity for our UI test fleet, and Xcode images that are ready almost as soon as Apple releases them help keep everything consistent, reliable, and, most importantly, uneventful.

What are you most excited about for the future?

[Nathan] I think it's the shift we've made since I joined the platform team about two and a half years ago. With Bitrise, we've gone from maintaining systems to designing feedback loops and working on more novel problems, instead of the things the industry has already solved, like hosting Mac minis.

Now we're able to focus on things like build-time telemetry to make builds faster, automated test gates, and how we adapt to the AI-driven changes happening across the industry. One of the biggest challenges is making sure we maintain the same level of test coverage as code volume increases. We're experimenting with concepts like persona-based testing, creating different types of users in our ecosystem and using AI-driven automated tests to simulate how they behave.

Essentially, we're now building the operating system for how our mobile engineering organization works. When I started, we mostly kept machines alive. Now Bitrise takes care of that, so we can focus on the future. 

Finally, how would you sum up your partnership with Bitrise today?

[Nathan] The Bitrise team feels like an extension of our team. If we have an issue with our build agents or orchestration, we can hop into Slack, start brainstorming, and get feedback right away.

When new capabilities like the remote development environment come out, it feels like another team in our company has built something cool, rather than a vendor shipping a new feature. And as we are involved so early we can see our feedback shaping the product in real time.

It genuinely feels like we're one team, with Bitrise providing the core infrastructure and CI/CD arm we need to deliver the best service possible to customers. That's the biggest thing for me.

Learn more about Jeppesen Foreflight's results with Bitrise: Read the case study