Built and shipped an iOS app from my phone while traveling Japan
7 comments
How much of the final app would have been different if you'd built it the traditional way at your desk in Spain? My guess is 40% of the features you shipped only existed because you were IN Japan using it. Context shapes product more than we admit.
The UI part was a bit challenging because we did not have immediate feedback. Every change required deploying a new build to TestFlight and waiting around 15 minutes before we could actually test it. That delay made fine tuning layouts and small interface details slower than it would have been sitting at a desk with instant previews.
That said, testing the phrases in real situations was invaluable. We could try them in restaurants, shops, or train stations, and even ask locals how something should be said more naturally. That real world loop shaped the app much more than instant UI feedback would have.
The app probably contains some translation imperfections, and we are fully aware of that. It was built by us and for us. The goal was not linguistic perfection but usefulness. And for our own trip, it genuinely worked and made things easier.
That said, testing the phrases in real situations was invaluable. We could try them in restaurants, shops, or train stations, and even ask locals how something should be said more naturally. That real world loop shaped the app much more than instant UI feedback would have.
The app probably contains some translation imperfections, and we are fully aware of that. It was built by us and for us. The goal was not linguistic perfection but usefulness. And for our own trip, it genuinely worked and made things easier.
Interesting workflow.
What prevented you from creating a PWA using pure HTML, CSS and WebAudio for text to speech? Would have given you instant feedback, hot reload, no deployment - maybe an idea for your next trip.
What prevented you from creating a PWA using pure HTML, CSS and WebAudio for text to speech? Would have given you instant feedback, hot reload, no deployment - maybe an idea for your next trip.
You are absolutely right. A PWA would probably have given us a much lighter workflow. Instant feedback, hot reload, no deployment cycle, no TestFlight delay. From a purely practical perspective, it would have been more efficient.
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.
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.
Pangram says it's 100% AI generated.
I'm absolutely right?
How did you keep it secure doing all this from a phone - SSH keys, Apple account, 2FA, all that?
She hates when I bring my laptop on trips. I love building things. This was our compromise.
I had been wanting to experiment with building an iOS app using Claude Code. I had never built for iOS before, and the idea of exploring it through AI-assisted development felt like a new frontier for me. But bringing a laptop to Japan again would not go unnoticed, and not in a good way.
So I made a plan.
Before leaving Spain, I configured my Mac so it would never sleep. I set up a VPN so I could SSH into it securely from my phone. I installed Zellij to maintain persistent terminal sessions in case the connection dropped. I also prepared a deployment pipeline to TestFlight, so I could trigger builds remotely and test them about 15 minutes later from the other side of the world, asynchronously.
This was our second time visiting Japan, and we have always wanted to learn more of the language. So we decided to build something we would actually use: a lightweight phrase app with useful tourist sentences and built-in text to speech. Things like ordering in restaurants, asking how much something costs, or navigating train stations.
The funny part is how it evolved.
While I was driving between cities, my wife would sit in the passenger seat dictating changes and features into Terminus on my iPhone, connected via SSH to my Mac back home. We used voice input to modify prompts, refine UI text, and generate new features. It became a shared game.
Development happened in short bursts, in parking lots, at rest stops, during train rides. We would ship a build, test it in real restaurants or shops, notice friction, and tweak it again that same evening from a ryokan or small hotel room.
The feedback loop was almost absurdly tight. We would use it in the real world, find awkward phrasing, improve it, redeploy, and test again the next day.
We never opened Xcode locally. We never touched the Mac physically during the trip. Everything happened remotely from a phone across continents.
What started as a workaround to avoid bringing a laptop turned into one of the most fun and lightweight building experiences I have ever had. It did not feel like working on vacation. It felt like co-creating something useful for the trip itself.
By the end of the journey, the app was not just a prototype. It was stable, usable, and something we genuinely relied on.
More than the app itself, the experiment was the interesting part: remote vibecoding, persistent sessions, AI-assisted iteration, and building in real-world feedback loops instead of simulated ones.
It made me rethink what a development environment even means.
Happy to answer questions about the setup, tooling, workflow, or what broke along the way.