Over the last few years, cross-platform development has become the default recommendation for almost every startup.

Write once, ship everywhere.

For many products, that makes perfect sense. Social apps, marketplaces, productivity tools, and internal business software benefit enormously from sharing code across platforms.

But while building a privacy-focused vault for iPhone, I made the opposite decision: I built a native iOS app.

The final binary is around 3 MB. Many cross-platform alternatives in the same category are fifty or even a hundred megabytes larger. That difference isn't automatically good or bad—it simply reflects different priorities. But for software whose entire purpose is storing passwords, documents, and authentication codes, I found myself valuing simplicity over portability.

Every framework brings dependencies. Every dependency brings maintenance obligations. And every additional layer introduces more complexity to understand, audit, and maintain.

Native code isn't magically secure—bugs exist everywhere—but reducing complexity still feels like a worthwhile engineering goal, especially for software designed to protect sensitive information.

Building natively also meant taking advantage of the platform directly: Face ID without abstraction layers, native document scanning, tight integration with the Files app, platform security APIs exactly as Apple designed them, smaller binaries, lower memory overhead, and fewer third-party libraries to maintain.

The tradeoff, naturally, is reach. A cross-platform application can support iOS, Android, desktop, and the web from a shared codebase; a native iPhone application cannot. That is a significant cost.

But I started wondering whether security-sensitive software should optimize for different things than ordinary applications.

Maybe the question isn't, “How many platforms can we support with one codebase?”

Maybe it's, “How much complexity are we willing to introduce in exchange for that convenience?”

For my particular project, the answer ended up being: not very much.

I would rather maintain separate native implementations than introduce additional layers between users and the underlying operating system security mechanisms. That preference won't be universal, and I completely understand why many teams make the opposite choice.

Still, I suspect we sometimes treat cross-platform development as an unquestioned default rather than a tradeoff that deserves deliberate consideration—especially when building products whose primary value proposition is privacy, security, or trust.

My own conclusion, at least for privacy software, is that native, small, local, and self-contained systems are often worth the additional effort.

I'm curious how others think about this. Should security-focused software optimize for fewer dependencies and deeper platform integration, even if it means supporting fewer platforms? Or is the maintenance burden of multiple native implementations ultimately the bigger risk?