But the truth is we wanted to build a native iOS app. It was less about optimizing the workflow and more about the excitement of trying something new. I had never built a native iOS app before, and part of the motivation was simply curiosity and the challenge.
We also wanted to test the limits of Claude Code. That part honestly surprised us. We never had to roll back once. Every issue we ran into we were able to solve remotely through vibecoding. The entire development cycle happened over SSH from a phone, and it held up better than I expected.
Another important reason was offline usage. We generated the audio files asynchronously using ElevenLabs TTS and bundled them into the app so everything worked fully offline. We did not want to depend on a server connection while traveling. Especially in Japan, where you are constantly moving through stations, underground areas, or rural zones, reliability matters.
So yes, a PWA would have been technically cleaner. But this project was driven more by exploration and constraints than by optimizing for the perfect setup. And in that sense, going native was part of the fun.
Now I am working on another app, a multiplayer party game to play with friends, and for that I am exploring a PWA approach using Firebase. And honestly, for this kind of project it works really well.
The development flow is much smoother. Instant updates, no App Store review cycle, easy real time features with Firebase, and the ability to test quickly with friends just by sharing a link. For a social, fast iteration type of product, it makes a lot of sense.
If it gains traction and people actually use it consistently, then I would consider migrating it to native iOS and Android later. Starting as a PWA feels like the right balance between speed, flexibility, and validating the idea before committing to the overhead of native apps.