From iOS to Android in a Weekend: How I Used Claude Code to Build a Complete App Without Writing a Single Line of Code

I've been shipping software for over two decades. I've seen plenty of "no-code" promises come and go. So when I tell you that I took an existing iOS application, pointed an AI at it, and had a fully functional Android app, complete with notifications, offline support, local database, and accessibility features, in about eight hours over a weekend, I understand if you're skeptical.

I was too. Until I did it.

If you read my recent post about building PourCraft Coffee, a brand new iOS app, in 32 minutes, you saw what Claude Code can do with a greenfield project. This time, I wanted to push it further: take an existing, production iOS app and port it to an entirely different platform. Same AI, bigger challenge.

The Starting Point: Travel Times Milwaukee

Travel Times Milwaukee is an iOS app I built that displays real-time Milwaukee freeway travel times from the Wisconsin Department of Transportation API. It's a focused, well-scoped utility app, not a toy project. The iOS version features:

• Real-time route data with color-coded delay status
• Favorites with reordering and swipe gestures
• Scheduled notifications for your commute
• Offline support with graceful degradation
• Search with debounced filtering
• A "What's New" dialog for version updates

It's the kind of app that exercises a broad surface area of a mobile platform: networking, local persistence, background work, push notifications, accessibility, and thoughtful UI/UX. Porting it to Android the traditional way would mean weeks of work, learning (or re-learning) Android-specific idioms, setting up the Gradle build, wiring up Hilt dependency injection, configuring Room for local storage, writing Jetpack Compose UI, and handling all the platform quirks that come with Android development.

I decided to see if Claude Code with Opus 4.6 could do it instead.

The Approach: Show, Don't Tell

My approach was deliberate. I didn't just say "build me an Android app." I gave Claude structured context:

1. The iOS source code. I pointed Claude at my Swift codebase so it could understand the data models, API contracts, business logic, and feature set.

2. Four screenshots of the running iOS app. These showed the routes list, favorites screen, route detail view, and notification scheduling UI. Claude used these to understand the visual design intent.

3. My coding standards document. This is a comprehensive set of guidelines I use across all my projects, covering everything from function length limits (30 lines max) to naming conventions, DRY principles, error handling patterns, and architectural preferences.

4. A CLAUDE.md project file. This gave Claude the Android-specific architectural context as the project evolved: build commands, data flow diagrams, tech stack decisions, and the patterns I wanted it to follow.

That was it. I provided the what and the standards. Claude figured out the how.

What Claude Built

The numbers tell part of the story: 43 Kotlin files, ~5,300 lines of code, organized into a clean MVVM + Clean Architecture structure. But the architecture doesn't capture how right the decisions were. Claude didn't just transliterate Swift to Kotlin. It built an idiomatic Android application.

Hilt for dependency injection with proper module separation and a HiltWorkerFactory for WorkManager integration, including the non-obvious step of disabling the default WorkManager initializer in the manifest.

Room database with versioned migrations. When I asked Claude to add notification schedules in a later iteration, it created a proper v2 schema with AutoMigration(1→2) rather than nuking the database.

Kotlin Flows and coroutines throughout, including the connectivity observer, the repository's caching layer, and the debounced search.

Material 3 with dynamic theming, swipe-to-dismiss gestures, and custom TalkBack accessibility actions on route cards. It didn't just make the app work; it made it accessible.

Proper Android permission handling: runtime permission requests for notifications on API 33+, exact alarm scheduling on API 31+, and a boot receiver to reschedule alarms after device restart.

The app targets SDK 35 (Android 15) with a minimum SDK of 26 (Android 8.0), covering approximately 95% of active devices. Claude set up the Gradle build with a signing configuration that loads from local.properties for local development, with an environment variable fallback for CI/CD.

The Process: Guiding, Not Coding

I want to be honest about what "I didn't write a single line of code" actually means, because it's not the same as not working. I was actively guiding the process the entire time.

The first iteration got the core structure and most features in place. From there, it was a series of focused conversations:

• "The swipe behavior on the favorites screen should snap back after adding a favorite, not dismiss the row."
• "The notification scheduling needs to support per-day-of-week configuration."
• "Add an offline banner that appears when connectivity is lost."
• "The search should be debounced — users shouldn't hit the API on every keystroke."

Each of these was a natural-language conversation. I described the behavior I wanted, and Claude translated that into the correct implementation. When something wasn't right, I described what was wrong, and Claude fixed it, usually identifying the root cause faster than I would have navigating an unfamiliar codebase myself.

The total time was about eight hours spread over a weekend. The part that still surprises me: I spent more time wrestling with Android Studio's IDE quirks and setting up my Google Play developer account than I did on the actual application code.

What Made It Work

The quality of Claude's output was directly proportional to the quality of my input. A few things separated this from a mediocre result.

A clear reference implementation. Having the iOS codebase as a reference gave Claude an unambiguous spec. There was no guessing about features, edge cases, or UI flows. Every behavior was defined by working code.

Explicit coding standards. My coding-standards.md document isn't just style preferences. It covers architectural patterns, error handling strategies, and quality guardrails. Giving Claude these standards upfront meant I rarely had to send code back for quality issues.

Behavioral descriptions over implementation details. I described what I wanted the app to do, not how to code it. "The favorites screen should let users reorder favorites using up/down controls in edit mode" is a better prompt than "implement a RecyclerView with drag handles." Letting Claude choose the implementation gave it room to pick the most idiomatic approach.

Iterative refinement. I didn't try to specify everything upfront. I let Claude build the foundation, then refined through focused follow-up conversations. This mirrors how real software development works: build, review, iterate.

The code quality reflected all of this. Functions were focused and small. The architecture was layered properly. Error handling was thoughtful, with exponential backoff on API retries, graceful offline fallbacks, and proper null safety. The visual fidelity was high too. From four screenshots, Claude reproduced the design while keeping a native Android look and feel. The app doesn't look like an iOS port; it looks like it belongs on Android.

What This Means for Developers

I've seen too many "AI will replace developers" hot takes, and that's not what happened here. What happened was that an experienced developer with clear requirements, strong coding standards, and good judgment used AI to dramatically compress the implementation timeline.

The skills that mattered were:

• Knowing what to build: understanding the requirements deeply
• Knowing what good looks like: having standards and being able to evaluate output
• Knowing how to guide: giving clear, behavioral direction when things needed adjustment
• Knowing when something's wrong: reviewing the generated code with a critical eye

These are all engineering skills. The AI didn't replace the engineer; it amplified the engineer.

If you're a developer who has been thinking about porting an app to another platform, or building something you've been putting off because the implementation time felt too daunting, the barrier just got a lot lower. The time from idea to working application is now measured in hours, not weeks.

Current Status

The Android version of Travel Times Milwaukee is currently under review for the Google Play Store. The app has feature parity with the iOS version: all priority items are implemented, the build is clean, and all tests pass.

From a single iOS codebase, four screenshots, and a set of coding standards, Claude Code with Opus 4.6 produced a production-ready Android application in a weekend.

That's not a demo. That's not a prototype. That's a real app, heading to a real app store, built by a developer who guided an AI instead of writing code manually.

The future of software development isn't about AI replacing developers. It's about developers who know how to work with AI building things that used to be impossible on a weekend timeline.