One Codebase, Every Screen: A Curious Look at Cross-Platform Development with Ionic + Capacitor
Ode Narendra Reddy (AI/ML Engineer Mirai Labs)
There’s a small, almost philosophical question hiding inside every mobile project kickoff: do we really need to build this twice? Once in Swift for the iPhone crowd, once in Kotlin for everyone else, and maybe a third time in plain JavaScript for the browser? A few years ago the honest answer was usually “yes, sadly.” Today, it’s a lot more interesting than that — and it’s the question that pulled me into this week’s deep dive.
What “cross-platform” actually buys you
Cross-platform frameworks let a team write the app once and ship it to iOS, Android, and the web from a shared codebase, instead of maintaining parallel native projects. It’s less a single trick and more a spectrum: some tools compile down to fully native UI, others wrap a web app inside a thin native shell. By some industry estimates, roughly 40% of apps in app stores today are cross-platform in some form, built with tools like React Native, Flutter, Ionic, or Cordova. That’s not a niche pattern anymore — it’s close to half the industry quietly agreeing that writing everything three times is a waste of good engineering time.
Where things get genuinely curious is how each tool closes that gap. That’s where our stack — Ionic paired with Capacitor — comes in.
Ionic and Capacitor: who does what
It helps to untangle two words that get used almost interchangeably but aren’t the same thing:
- Ionic Framework — a UI component library (buttons, tabs, modals, the works) built with web technology, styled to feel native on whichever platform it lands on.
- Capacitor — the native runtime underneath it. It’s what actually takes your HTML/CSS/JS project and wraps it into a real iOS project, a real Android project, and optionally a Progressive Web App, while exposing native device features (camera, GPS, filesystem, biometrics) through a plugin bridge.
You can use Capacitor without Ionic’s UI kit at all — plenty of teams pair it with plain React, Vue, or Angular. But together, they form a fairly elegant loop: design the interface once, let Capacitor carry it everywhere.
Get Ode Narendra Reddy’s stories in your inbox
Join Medium for free to get updates from this writer.
Here’s roughly how a build travels from your editor to someone’s phone:
The interesting part isn’t the boxes — it’s the middle one. Capacitor isn’t just repackaging a website. Under the hood, it runs as a native runtime that acts as the communication layer between your web app and the underlying operating system, exposing native plugin APIs directly into the WebView. Your JavaScript can call Camera.getPhoto() and genuinely trigger the iPhone’s camera, not a browser file picker pretending to be one.
A small taste of what that looks like in practice
# add Capacitor to an existing web project
npm install @capacitor/core @capacitor/cli
npx cap init "MyApp" com.mirailabs.myapp
npx cap add ios
npx cap add android
npx cap syncimport { Camera, CameraResultType } from '@capacitor/camera';
async function takePhoto() {
const photo = await Camera.getPhoto({
resultType: CameraResultType.Uri,
quality: 90,
});
return photo.webPath;
}Four lines, and you’ve got a camera call that behaves natively on both iOS and Android, with the same TypeScript running in the browser fallback too.
The honest trade-offs
No framework gets to skip this section, and pretending otherwise would be the least curious thing I could do here.
Independent comparisons generally rank raw performance as Flutter first, React Native close behind, and Capacitor a noticeable step further back — a gap that tends to show up mainly in interaction-heavy, visually complex screens rather than in typical CRUD-style business apps. For a form-and-list-driven internal tool or an MVP that needs to reach three platforms by Friday, that gap rarely matters. For a game or a highly animated consumer app, it might.
The other quiet trade-off: your app is, structurally, a website in a native shell. That’s a feature when you want one team, one skill set, and one deployable artifact — and a limitation the moment you need pixel-perfect native transitions or platform-specific gestures that the web simply doesn’t expose.
Why this is worth caring
What made this topic fun to dig into wasn’t the “which framework wins” debate — that answer is always “it depends,” and anyone who tells you otherwise is selling something. It was noticing why teams keep circling back to the web-technology approach: hiring is easier (any web developer can contribute), the plugin ecosystem is genuinely npm-flavored, and a single Angular/React/Vue app quietly becomes three products without three teams. For a fast-moving codebase, that’s less a shortcut and more a design decision with real weight behind it.
A couple of things worth watching next
- Capacitor’s plugin ecosystem — smaller than React Native’s or Flutter’s today, but growing, and writing a custom native plugin when one doesn’t exist yet is refreshingly documented.
- PWA support as a genuine third target, not an afterthought — the same build can run in a browser tab with minimal extra work.
- The migration path from Cordova, for teams still living in that older world.
🎥 For a short video walkthrough alongside this post, Ionic’s official YouTube channel has a few good explainer videos on Capacitor fundamentals worth linking or embedding here.
