I Built My Mobile App in 48 Hours. The Important Part Took 20 Years.

I have spent an absurd number of hours over the last two decades complaining about mobile development.

It is slow. Xcode breaks. Certificates expire. Simulators stop working. And no matter how many apps you have shipped, you can still lose half a day because you cannot find the damn button in some Apple or Google console.

So I am still processing what happened last week.

I took Hold My Juice, my fairly complex Next.js app, and ported it to React Native. It has uploads, voice recording, chat, calendar syncing, authentication, and much more.

I assumed this would take a few weeks. My modest goal was: get iOS working first, Android can come later.

About 48 hours later, both platforms were fully built and compiled on a device.

My first reaction was: holy shit.

My second was: I would have shot myself in the foot about fourteen different ways if I hadn't already spent twenty years learning how mobile development goes wrong.

That second part is the interesting one.

We have been trying to make mobile development disappear forever

First, mobile web was going to save us. Build once. Ship instantly. One developer owns the experience across devices. Facebook bet hard on this; in 2012 Zuckerberg called betting too heavily on HTML5 one of the company's biggest mistakes and said it had cost them two years.

So the industry swung toward native. Hire iOS engineers. Hire Android engineers. Let each platform do what it does best.

This worked. It also meant one product feature might get implemented three times, by people with completely different skill sets, on completely different release cycles.

I lived this at Quizlet. Even when mobile development was going well, web could move at a speed mobile just couldn't. We could build something in the morning and get it in front of users that afternoon. On mobile, you built it, compiled it, tested it, submitted it, waited, released it, then discovered half your users hadn't updated.

Then came React Native. I still remember engineers coming back from the first React Conf in 2015 completely electrified. Previous cross-platform attempts mostly felt like putting a website inside an app and hoping nobody noticed. This let you write JavaScript while rendering actual native components.

It really did change mobile development. It just didn't make mobile development go away.

The complexity always leaks out somewhere

Greenfield React Native could be great. Brownfield React Native, where you were introducing it into an existing native app, got hairy fast.

At Quizlet we spent a lot of time on those boundaries. What lives in native? What lives in React Native? How do you introduce a new framework without accidentally creating a third application architecture inside the two applications you already have?

None of that complexity disappeared. Abstraction just moved it somewhere else.

And even if you solved all of that, mobile still had one unavoidable problem. You can't control the code running on someone's phone.

On web, I can ship something, realize I broke it, fix it, and five minutes later everyone has the fix. On mobile, someone may still be running a version from three months ago. Now your backend needs to work with software from three months ago.

That is a very different engineering constraint and one that does not play well with iterative product development.

Every generation of mobile tooling reduced some of the labor. None of it removed the need to understand where the platform boundaries were.

Then AI changed the equation

AI is the first thing I've used that made the implementation cost of that translation feel almost trivial. Moving software between platforms got shockingly cheap, at least when the underlying system is designed for it.

Historically, starting on web came with a giant asterisk. No matter how fast you're going, someday someone is going to have to rebuild this for mobile. That future rewrite influenced decisions you made today. Maybe we should start with React Native. Maybe we should make the desktop experience worse so we can share more code. Maybe we should build mobile before we need mobile, because later will be expensive.

I got to skip all of that. Web is an incredible surface for learning: you can make something in the morning and find out it was a terrible idea by lunch. So I built on web in a responsive layout until I knew what the product actually was. Then I moved it to native, and apparently that move now takes a weekend.

So I don't think AI means every startup should build mobile first. It means you can plan for native without building native before you need it.

We didn't need native to answer the questions we actually had. Plenty of products do: if the camera, location, offline behavior, or some other native capability is the product, this calculus is different. Hold My Juice wasn't that. Native became valuable when people started returning on their own, not while we were still figuring out what they wanted.

The weekend only worked because I had already made three decisions Claude could not make on my behalf.

The code wasn't the hard part

Don't force one UI to serve all platforms

The first decision was that I was going to have two apps. A Next.js web app. A React Native mobile app.

There is a very strong temptation when you hear "cross-platform" to optimize for maximum code reuse. But at the end of the day, each platform is different and should be treated as such. What I want on a 27-inch monitor is not a stretched-out version of what I want in my hand. I wasn't going to compromise either product to make the other one's architecture cleaner.

That immediately creates another problem. Drift. Two apps slowly becoming two different products.

Don't duplicate behavior just because you're duplicating UI

I was lucky here because Hold My Juice already worked across more than one surface. Parents could add todos and interact with the product over SMS, so I had already been forced to keep business logic out of the web UI and in the backend or shared modules.

That meant adding mobile was much easier. Claude wasn't rebuilding Hold My Juice. It was adding another interface to a system that was already designed to support more than one.

Web, SMS, and now mobile could all be true to their platforms’ capabilities without losing consistency of experience.

Treat released clients as permanent dependencies

The third decision was the thing a web developer could easily forget. Once I shipped the mobile app, I no longer controlled which version people were using.

On web, I can usually change an API response and ship the client that consumes it at the same time. On mobile, someone opens a two-month-old build tomorrow and congratulations, I just broke the app.

So I added guards. Changes to the backend run compatibility tests against the assumptions released mobile clients depend on. Changes to shared behavior get checked against both apps. And parity is tracked separately: if a feature lands on web and never shows up on iOS and Android, my checks flag it.

None of this is sexy. It is also exactly the kind of thing I knew to worry about because I have been burned by mobile development before.

That is what I mean by experience mattering. Not "I know the right React Native syntax." Claude can produce the syntax faster than I can. Experience is knowing which completely reasonable shortcut becomes a six-month problem.

Code has become cheap. Judgement is not.

Claude was remarkably good at this. It inspected the codebase, figured out libraries, ran the app, debugged things. Work that would once have required me to methodically type, translate, Google, and debug just happened.

But I still had to know what I wanted it to do. Which things should be shared. Which shouldn't. What was going to break later.

AI compressed the implementation. It did not compress the judgment.

If anything, judgment matters more when implementation becomes this cheap, because now you can make a bad architectural decision at extraordinary speed.

There may be another consequence too.

For twenty years, the cross-platform dream has revolved around one question: how do we avoid building this three times?

AI may change the answer. Not by eliminating the duplication, but by reducing its cost enough that code reuse stops being the overriding architectural goal. Build the right thing for web. Build the right thing for mobile. Share what genuinely should be shared, and let AI absorb the translation in between.

Claude wrote my React Native app in about 48 hours. Learning how I wanted it built took decades.

For the record

None of this solved the Google Play Console. Google told me I could not verify my phone number until I had verified my organization. I had already verified my organization. Claude investigated. Claude spelunked. Claude clicked through on the browser. Eventually Claude gave up and drafted a support ticket.

Some parts of mobile development are apparently AI-proof.