Why Your Capacitor Apps Can't Use EAS Build (And the Debug APK Shortcut That Works)

You've got a mobile app that runs fine in the browser. You've got a CI pipeline. You've heard EAS Build is the modern way to ship mobile builds. So you wire it up, hit run, and… nothing. Or worse, a confusing error about Expo config that has nothing to do with your project.

If that sounds familiar, you're probably hitting a tooling mismatch that trips up a lot of builders. Let me save you the afternoon.

EAS Build only knows Expo

EAS Build is Expo's build service. It's designed for Expo projects. When you point it at a project, it expects the Expo config, the Expo runtime, and the Expo assumptions about how a mobile app is structured.

Capacitor apps are not Expo apps. They're web apps wrapped in a native shell. The build pipeline is your own — typically a web build step, then a native Android or iOS project that gets compiled by the platform toolchain.

So when someone tries to build a Capacitor app with EAS, it fails. Not because the app is broken. Because EAS was never built to handle that project shape.

This came up recently with three apps — abcd, quickmarks, and loop-gallery. All three are Capacitor apps, not Expo. EAS couldn't build them. That's not a bug you can fix with a config tweak. It's a fundamental incompatibility.

The real blocker is usually signing

Here's the thing: most people don't actually need EAS Build. They need a working APK on a device so they can test, demo, or ship to a small group of users.

The reason they reach for EAS in the first place is that native Android builds feel heavy. You need a keystore. You need signing configs. You need to remember which alias and password go with which project. For a solo builder or a small team, that's a lot of ceremony before you've even seen your app run on a phone.

So the tooling mismatch isn't just "EAS doesn't support Capacitor." It's "I went looking for a shortcut and found a dead end."

The shortcut: ship a debug APK

The practical fix is to skip EAS entirely and ship a debug APK as a sideload.

A debug APK is exactly what it sounds like. It's the Android build variant that's meant for development and testing. It's signed with a debug key that Android tooling generates for you. No keystore setup. No signing config. No release pipeline.

You build it, you get a file, you install it on a device. Done.

For Capacitor projects, this is usually wrapped in a single script. In the case of these three apps, the command is:

npm run mobile:apk

That runs the web build, syncs it into the native Android project, and produces a debug APK. You can hand that file to a tester, drop it in a shared drive, or sideload it yourself.

When this is the right call

Debug APKs are perfect when:

  • You're testing on real devices and don't care about store distribution yet.
  • You're demoing to a client or a small group.
  • You want to validate the native shell before investing in release signing.
  • You're blocked on EAS (or any other tool) and just need to keep shipping.

They are not the right call when you're publishing to the Play Store. For that, you'll eventually need a release build with a proper keystore. But that's a later problem. Don't let it block you today.

The takeaway

If your app is built with Capacitor, EAS Build is not your tool. Don't spend hours trying to bend it into shape. Reach for the native build path your project already has, and use a debug APK to get something installable in front of real users.

npm run mobile:apk is not glamorous. But it ships. And shipping beats fighting your tooling every time.