It wasn't. And it wasn't just one bug...it was a string of them, each one quietly teaching me something I didn't know I didn't know.

The Bug That Wasn't a Bug

The first real wall was a photo picker. A user taps "choose from library," picks a photo, and… nothing. No error, no crash; just silence. I waited four minutes before giving up and backing out, which triggered an alert saying I'd "cancelled." I hadn't cancelled anything. I'd waited.

That single distinction ( cancelled vs. hung) turned out to matter a lot. My first instinct was to assume it was a permissions issue, since that's the obvious web-dev-brain answer: something's being denied, check the permissions. Wrong guess. The real cause was allowsEditing: true a native crop screen that, in Expo Go specifically, doesn't reliably hand control back to the JavaScript side after you confirm. The picker wasn't broken. It was just waiting, forever, for a handoff that was never going to come.

The fix was almost anticlimactic once I found it: drop the crop step, add a hard 20-second timeout so it fails loudly instead of hanging silently. But finding that fix meant learning something that isn't obvious if you've only ever worked on the web , native mobile has separate "activities" and screens that hand control back and forth, and if that handoff breaks, nothing tells you. There's no console error for "a native screen forgot to return."

The Bug That Gaslit Me

The second one was worse, because it lied convincingly. A UI issue would appear, then disappear on its own, then come back a session later with no pattern I could find. I'd fix something, it would look fixed, then two days later the exact same broken state would show up again like I'd never touched it.

The actual cause had nothing to do with my code. I had a pile of old dev server processes running simultaneously in the background , metro bundlers from previous sessions that never actually shut down. Each one was quietly serving a different, stale version of my app. Depending on which port my device happened to connect to, I'd get a different snapshot of my own code, days apart, with no warning that this was even possible.

This one taught me something web development never really forces you to learn: that "it looks fixed" and "I understand why it's fixed" are not the same claim, and treating them as the same one will waste hours of your life.

Why This Was Harder With AI in the Loop, Not Easier

Here's the part that actually surprised me. I expected AI to make debugging faster, and it did ... for writing fixes. But it didn't shortcut the understanding. If anything, it raised the bar, because I could get a plausible-sounding fix in seconds, and plausible isn't the same as correct.

With the picker bug, my first prompt to Claude Code was based on my wrong assumption — permissions. It gave me a reasonable-sounding permissions fix. It would have "worked" in the sense of not crashing, while leaving the actual hang untouched. The only reason I caught it was refusing to accept a fix I couldn't fully explain back to myself. Same with the stale-server issue , the first few explanations sounded complete, but none of them actually accounted for why the bug would vanish and reappear days later. I kept pushing until the explanation actually closed every loop, not just the visible one.

What I Actually Learned (Beyond the Fixes)

• Native mobile has handoffs between screens/processes that web development doesn't really have an equivalent of, and when those handoffs silently fail, there's no clean error to point you at it

• "Cancelled" and "hung" look identical from the outside but mean completely different things, and confusing them sends you debugging the wrong problem entirely

• Long-running dev processes on mobile can quietly multiply and serve stale code without any obvious signal, always check what's actually still running before trusting what you're looking at

• An AI-generated fix that runs without error isn't the same as a fix you understand and the gap between those two only shows up later, usually at the worst time

The Actual Lesson

None of this was really about mobile development, or even about AI. It was about the fact that "it works" is a much lower bar than "I know why it works" and the second one is the only one that actually protects you later. Web development let me get away with the first bar more than I realized. Mobile, with an AI moving fast enough to outpace my understanding if I let it, didn't let me get away with it at all.

Looking back, I learned a lot more from this project than I expected. I learned that mobile development has its own rules, that some problems take more than just another fix, and that sometimes the hardest part is figuring out what is actually going wrong. I also learned to slow down, question things, and not assume that because something worked on the web, it would work the same way here.

It was frustrating at times, but every strange bug, wrong turn, and late realization taught me something I didn’t know before. And honestly, that’s probably what I’ll remember most from building this app.