Building native iOS and Android mobile apps with Opus 5.5

Published October 27, 2026

For as long as I can remember, I’ve had more ideas for software than engineering time to build them. Working with Claude Opus 5.5 on native iOS and Android apps for Independent Vet changed my sense of what can be accomplished in a very short amount of time.

In just a couple of weeks, with roughly US$5,000 in API credits, a month of the Claude Max and ChatGPT Pro plans, and an existing website and dataset to build on, I had two feature-rich and feature-equivalent native apps that feel genuinely useful in my own testing. They let pet parents find independent veterinary practices, save a shortlist, and keep their pets’ records and medications together. Since release, account login, household sharing, practice management, job listings and much more have been added. Both apps are now available on the App Store and Google Play, and I’m excited to introduce them to the thousands of visitors the websites get each day.

Download the apps:

I’ve been using mobile apps since the Nokia Communicator and a jailbroken first-generation iPhone. In a previous startup, we created a prototype app around Apple’s ResearchKit when it was first released, but I’ve never taken an app end-to-end before. I feel like I have a good sense of what makes an app good and a reasonable intuition for how they should work. But I’m by no means a mobile app developer.

I had some API credits remaining and wanted to see how far I could get. What surprised me was how quickly the experiment became a pair of working apps that I could test, refine and prepare for submission.

Why build the apps?

Independent Vet helps pet parents find locally owned veterinary practices, and Private Equity Vet helps pet parents identify corporately owned practices. The websites were already well established, with tens of thousands of people visiting each day. The dataset, refined over three years, was now quite robust. In a mobile app, I wanted to make that same information accessible and useful on the move and in an emergency.

A saved hotlist of practices was one example of where an app could add value over a website. If you need a vet quickly, having the practices you’ve already identified close at hand is useful. I also wanted pet parents to have their own place for pet records and medications, separate from whichever practice they happened to use. The apps include document scanning with OCR to help turn information from documents into structured data.

I also wanted to build these apps native - call me a purist but I get rather annoyed with apps that feel like they’re loading webpages between clicks.

I had also read about Shopify moving from React Native back to Swift and Kotlin. Its explanation resonated: coding agents had changed the economics of maintaining separate apps for each platform. I wanted to explore that frontier for myself.

From design to working apps

I began in Claude Design with a fairly light brief. We worked through my MVP list of features, look and feel, tabs and navigation. The existing website gave us a design language and content display to draw on, and Claude Design produced wireframes for both platforms.

I then brought those wireframes into Claude CLI, alongside the website codebase. Having the existing map, data and implementation available gave Claude a substantial foundation to build upon.

Claude recommended getting iOS under way first, with Android following a few steps behind in parallel. That became the working pattern, with product decisions carrying across as the two apps developed.

Most of the heavy lifting of mobile development was done using Claude Opus 5.5 at extra-high effort. I used GPT-6 Astra at high effort to review and merge pull requests and implement API changes based on shared contracts between agents documented and iterated upon in PRs.

Claude split the first release work into eight milestones, starting with the core features and gradually building out from there. iOS stayed one milestone ahead of Android, and we’d check in after each milestone to briefly test what had been built and answer questions that came up. It turned sprints that would have taken weeks into work measured in minutes and hours.

The build ran almost continuously over four days, with plenty of back and forth. I answered questions, made high-level architecture decisions and tried the apps as they took shape.

Making the product decisions

There were many product decisions to be made along the way, some architectural and some more philosophical. Surprisingly, Claude and Codex had great intuition and advice along the way, baking in encryption and privacy from the outset.

One particularly interesting decision was whether to show corporate-owned practices alongside independent ones. I decided to keep the map focused on independent practices by default, with corporate practices available through the filters.

Independent Vet exists to help people find locally owned practices, but in an emergency, with limited local options, someone may need to see every practice nearby. I also felt that people would be less willing to switch between apps than between browser tabs. The app needed to be useful enough that they could stay in it.

Connecting everything and getting into testing

Building the apps was only part of the work. Getting the services connected and the builds into testing involved a lot of setup across Clerk, my authentication platform, Cloudflare, Google Cloud Platform, Google Play Console and Apple’s App Store Connect. It was by no means a straightforward process.

Claude and Codex were incredibly helpful here. They explained what needed to be configured and guided me through the work across those services. I handled account setup, DNS configuration, secrets and webhooks as needed. The development setup also used MCP integrations with Cloudflare and Clerk, giving Claude Code a way to work with those services.

The back and forth mattered just as much here as it did in the app design. I still had to work through the accounts and consoles, but I had help understanding what needed to happen and how the pieces fitted together. That support carried through to Google Play Console and App Store Connect, getting the apps set up and out into testing, and eventually submitted for review.

The apps didn’t come fully baked

I spent a lot of time testing on both an iPhone and an Android phone, and found plenty of bugs. In one case, tapping something in the Android app sent it into a loop that prevented me from exiting. There were also interface improvements and design changes that became apparent as I used the apps.

The apps definitely did not arrive fully baked. But they were good enough to test and improve incrementally, and Claude was very good at debugging, suggesting fixes and implementing them. It didn’t feel like whack-a-mole. Each round of testing and fixing moved things forward.

That was a big part of the experience for me: I could use the product, identify what was wrong or awkward, and work to improve it. Claude also has some great intuition on how to fix or improve things given direction. My time went into testing, decisions and feedback, with a fast turnaround on the implementation.

Map

My Vets

Pets

Profile

The initial bottleneck

A lot has been written about the app stores being inundated in the era of vibe coding and the consensus is that review times have definitely slipped.

For personal developer accounts created after November 13, 2023, Google Play requires a closed test with at least 12 testers opted in continuously for at least 14 days before you can apply for production access. That’s the ability to submit the app for public release, so completing the testing period is another step toward publication rather than an automatic launch.

Apple required me to submit a build for review before releasing it on the App Store. For the first submission, I waited 11 days at which point I requested an expedited review and it was approved the next day.

The wait did give me the opportunity to keep chipping away at the roadmap and ship several nice-to-have features into the test builds. By the time Google approved production access, I was already on version 1.3.0, build 40. Once Apple approved the first version, subsequent approvals seem to happen same-day.

The first release is just the start

Getting to that initial release and onboarding real-world users is just the start of any software journey. The real magic comes from quickly iterating based on user feedback and your own intuition while also trying to drive user growth.

With AI, it’s now possible to iterate on the product much faster than user feedback can arrive, especially for emerging products. That makes intuition and founder-product fit more important than ever in deciding what to build next.

My takeaways

1. Just build it. Your agency, creativity, product taste and willingness to put in the time go a remarkably long way. You still need some understanding of the fundamentals and a budget for the tools, but the cost feels like pocket change compared with the development budget I would once have imagined. The decision to get started is increasingly in your own hands.

2. The expectations for an MVP have shifted. This experience has raised my own bar for a minimum viable product. In just a couple of weeks, I could get to native apps with useful features, a considered interface and something substantial to test. There were still plenty of bugs to fix, but I could spend more time refining how the product worked and felt, even at this early stage.

3. If you build it, they will not necessarily come. Despite steering thousands of people to the app download page and seeing hundreds of installs over the last week, it has not felt like opening the floodgates. My attention is now turning to how to increase the conversion rate, better onboard users and delight them in those first interactions. Time will tell!

4. Using multiple frontier models builds confidence. Having GPT-6 Astra review website pull requests and offer occasional input gave me another perspective alongside Claude’s work. I like being able to ask a second model to question an approach or review a change. That adds confidence, while hands-on testing remains essential.

5. Subscription plans can go much further than API credits. A subscription got me out of a bind toward the end of the build, after my API credits had expired. Based on the usage reported by /cost, my US$100 Max subscription seemed to deliver over US$3,000 in equivalent API usage. That was a striking difference for this project, and something I’d factor into how I fund future work.

6. Invest in a workhorse machine and a good screen setup. My setup was a MacBook M5 Max with dual 4K monitors, plus an always-on Mac Mini at home occasionally running tasks in the background. There is still a lot happening on your own desk: development tools, builds, simulators, service consoles and the apps you’re testing. A capable machine and enough screen space to comfortably follow the work make it easier to stay involved, spot problems and keep moving.

Both apps are now available on the App Store and Google Play, and I have plenty to learn from how pet parents actually use them. For now, I’m excited to have taken an idea this far, and even more excited to get it into people’s hands.