I was temporarily using Android and wanted the water-temperature app I already had on iOS. Instead of treating that as a reason to postpone the problem, I gave Claude Code a direct porting request and went out to do other things.
The instruction was to analyze the iOS version, create an equivalent Android application in a separate folder, leave the iOS folder unchanged and read-only, then build and launch the result in an emulator. The original application was the specification as well as the source material.
When I returned about an hour later, the Android app was running in the emulator. My first impression was that it worked, including widgets and a version for Android watches. That was a striking amount of visible progress from one request.
The result was an implementation to inspect. Store publication was still ahead. Seeing the app in an emulator and distributing a dependable mobile application are different milestones, with useful work between them.
Preserve the behavior, translate the platform
"Make it identical" is a practical shorthand, but a port cannot simply reproduce every implementation detail. iOS and Android have different lifecycle rules, permission flows and background-execution models. Widgets and watch applications also have their own conventions.
The useful thing to preserve is the user's task. AquaDegrees should obtain the intended location, show the corresponding water temperature and remain understandable when data is unavailable. The route through the platform APIs can change while those promises remain the same.
Using the existing application as input helps because many decisions are already represented somewhere. Labels, units, screen states and data-handling paths give the agent more to work from than a fresh description of the idea. It can compare concrete behavior rather than invent a product from a short prompt.
The read-only boundary around the iOS folder was deliberate. I wanted the agent to learn from one application while creating another, without quietly adapting the reference to make the task easier. A port is much easier to evaluate when the thing being ported remains stable.
The useful comparison is a sequence of actions
A screenshot comparison can reveal layout differences, but it is not enough. I would walk through the same tasks on both versions: first launch, permission granted, permission declined, a successful fetch and a failed one. Then return after the application has been in the background.
For widgets and watch components, the comparison should include the passage of time. A value can appear correctly when the main app is open and become stale elsewhere. Platform-specific scheduling makes this a particularly important part of the port.
There are also small translation decisions that affect how native an application feels. A back action should follow the destination platform's expectations. A system permission sheet cannot be replaced by a visual imitation. Text needs to remain readable at different sizes and device dimensions.
None of this takes away from the surprise of returning to a running application. It explains why that result is valuable. The agent moved the work far enough that I could start comparing and correcting an implementation instead of assembling the first project structure.
AquaDegrees on iOS had become a useful, concrete description of what the Android version should do. The porting experiment showed how much an agent can infer from an existing product when the boundary is clear. My next responsibility was to turn the impressive first hour into an application I could confidently hand to someone else.