Why I Built My App with Flutter Instead of Swift

If you had asked me a year ago what technology I would use to build my own product, Flutter probably would not have been my answer. I've spent most of my career building native iOS applications. Swift has been my primary language for years, UIKit shaped the way I think about mobile architecture, and most of my professional experience has been centered around building for Apple's ecosystem. Naturally, when I started working on Anotter, I assumed I would continue down that same path.

Instead, I chose Flutter — not because I suddenly believed it was better than native development, and not because I wanted to reinvent myself as a Flutter developer. If someone approached me tomorrow looking for an experienced iOS engineer, I would still introduce myself exactly that way.

So why choose a technology that sits outside my primary area of expertise?

Looking back, the answer is surprisingly simple: I stopped optimizing for the engineer I was, and started optimizing for the product I wanted to build.

Native Was Never the Problem

This is not one of those "Flutter vs Swift" articles. I have no interest in arguing that one framework has finally defeated another, or that everyone should abandon native development. Those comparisons rarely produce practical insight.

I still believe native development is the right choice for many products. Years of experience have taught me the value of working directly with platform APIs, taking advantage of mature tooling, and building experiences that feel deeply integrated with the operating system. That background is still one of the strongest parts of my engineering work, and I expect it to stay that way.

If Anotter had been an iOS-only application, I probably would have built it in Swift without thinking twice. But Anotter was never meant to be an iOS application. It was meant to be a product. That distinction ended up changing almost everything.

The Real Constraint Was Duplication

Building your own product is very different from working inside an established company. There is no Android team across the hallway, no separate roadmap for platform parity. Every feature, bug fix, design iteration, release, and future maintenance task comes back to the same person.

That forced me to ask a different question. Instead of asking which technology I enjoyed using most, I started asking which technology would let me validate the product with the least duplicated effort. Choosing native development would have meant maintaining two separate codebases from day one — every feature implemented twice, every bug investigated twice, every design change applied twice. For a larger organization, that cost is often acceptable. For a solo founder trying to learn whether anyone actually needs what they are building, it becomes very hard to justify.

Flutter allowed me to focus on building the product instead of keeping two implementations synchronized. It was not about reducing quality. It was about reducing the kind of effort that does not move the product forward.

Previous Experience Gave Me Confidence

This was not a leap of faith. Before starting Anotter, I had already worked on a production Flutter application — one with authentication, backend integrations, and the kinds of engineering challenges that exist regardless of framework. That experience removed the uncertainty. I had already seen that Flutter was capable of supporting a real product at a meaningful level of complexity.

It was not perfect. Neither is Swift. Neither is any framework I have ever worked with seriously. But that project convinced me that Flutter was no longer something I was curious about. It was a tool I could realistically reach for when the project called for it.

AI Changed the Cost of Learning

If I had started this project five years ago, I am honestly not sure I would have made the same decision. One of the bigger reasons for that is AI-assisted development.

Tools like Cursor significantly reduced the cost of navigating an unfamiliar ecosystem. Frameworks evolve, APIs change without warning, and communities accumulate patterns that take time to absorb. What used to require hours of documentation reading, blog posts, and Stack Overflow threads can now be resolved in minutes. That does not mean the thinking disappears — it means less time is spent on the search before the thinking can begin.

To be clear about what AI did not do: it did not decide how authentication should work, did not design the data model, did not define the product vision, and did not make architectural trade-offs. Those decisions were still mine. What changed was the speed at which I could become productive without needing to become an expert first.

What the Framework Did Not Change

The biggest surprise was discovering how little changing the framework actually changed the nature of the problems I had to solve.

Authentication still required careful planning. Data modeling still mattered. Security had to be considered from the beginning, not added later. Offline behavior involved trade-offs. Releases required coordination. The product evolved as I learned more from potential users.

Cross-platform development also turned out to be a more honest phrase than platform-ignorant development. There were platform-specific surprises along the way — some rooted in iOS behavior I already understood well, others in learning how Flutter approaches things differently on each platform. None of them were unsolvable. But they were a reminder that sharing a codebase and ignoring the underlying platforms are not the same thing.

In the end, the difficult parts of software engineering stayed exactly where they had always been. Changing the framework did not remove those problems. It changed the tools I used to solve them — and that is a much smaller shift than most cross-platform debates suggest.

Final Thoughts

Choosing Flutter did not change how I think about software engineering. If anything, it reinforced something I have gradually learned throughout my career: technology choices should serve the product, not the other way around.

Swift is still my preferred language for native iOS work. That has not changed. What changed was recognizing that this project had a different set of constraints than most of the software I had built before. For Anotter — a product that needed to reach both platforms, validate quickly, and be maintained by one person — a single codebase made more sense than optimizing for my own familiarity with Apple's ecosystem.

In hindsight, I did not choose Flutter because it was the best framework. I chose it because it was the framework that best fit the problem I was trying to solve.

The specific engineering decisions that followed — what worked, what did not, and why — are worth exploring in more detail. But that is a different story.

If you are curious about the product that came out of these decisions, Anotter is a property record system for independent landlords. You can join the waitlist at anotter.app.