跪拜 Guibai
← All articles
Android · iOS · AI Programming

An Android Dev Forced to Write iOS with AI Maps What Works and What Breaks

By Coffeeee ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

The piece is a reality check for any team betting that AI can turn a single-platform developer into a cross-platform replacement. It catalogs exactly where LLMs reduce friction and where they create catastrophic blind spots, especially around signing, review, and legacy code that no model can reason about.

Summary

A senior Android developer with zero iOS experience was handed an old, mixed-language iOS project and told to use AI instead of hiring. The result is a practical field manual of AI-assisted cross-platform survival tactics and a blunt list of things AI still cannot touch.

The workflow leans heavily on structured code translation, concept mapping between Android and iOS APIs, and an AI-maintained knowledge base that acts as a second brain. Concrete prompt templates cover translating network modules, debugging crash logs, generating tests, reviewing code for memory and thread safety, and designing progressive architecture migrations from MVC to MVVM.

Just as important is the list of hard limits: Xcode certificate and provisioning profile hell, App Store review politics, Instruments-based performance tuning, and the existential danger of AI silently deleting legacy "do-not-touch" code that only the original author understood. The post ends with a warning that AI-assisted multi-platform development is possible but requires buffer time and lowered expectations; without those, the only sensible move is to walk.

Takeaways
— Code translation from Android to iOS works only when the prompt includes project-specific context: networking library, JSON parser, and minimum iOS version.
— AI-generated code must include line-by-line comments and rationale; a developer new to the platform cannot evaluate bare code.
— A concept-mapping table (Activity→UIViewController, Room→CoreData, etc.) lets an Android dev ask AI to explain iOS code in familiar terms.
— An AI-maintained knowledge base should auto-organize pitfall logs, generate cross-references, flag deprecated APIs, and fill missing chapters.
— Crash log triage succeeds by pasting the stack trace and asking for a plain-language explanation, an Android equivalent, and a fix.
— AI can generate unit tests and review code for memory leaks, thread safety, and Swift best practices, but a human must judge the output.
— Progressive architecture migration plans (MVC to MVVM) can be designed by AI when the two platforms use different patterns.
— Xcode certificate management, provisioning profiles, Build Settings debugging, and Archive/Export flows remain entirely manual.
— App Store rejection appeals, gray-area guideline interpretations, and expedited review requests require human judgment and social skill.
— Instruments-based performance tuning and memory-leak hunting still demand hands-on tool proficiency.
— AI will silently delete legacy code that looks wrong but must never be touched; on an unfamiliar platform, the developer won't notice until production breaks.
Conclusions

The core risk is not that AI writes bad code but that it deletes code whose correctness depends on unwritten organizational memory. On a familiar platform, a developer catches this; on a new one, the deletion is invisible until users scream.

Prompt engineering for cross-platform work is really context engineering: the model needs the project's dependency list, target version, and architectural conventions, not just the source snippet.

The knowledge base strategy treats AI as a librarian, not an author, which sidesteps hallucination by making the model curate and index human-verified notes rather than generate authoritative reference material.

App Store review is framed as a fundamentally social process where AI-generated language is a liability, not an asset, a useful counterpoint to automation maximalism.

Concepts & terms
Concept Mapping (Android→iOS)
A technique where an Android developer provides AI with a table of equivalent platform concepts (e.g., Activity→UIViewController, Room→CoreData) so the model can explain unfamiliar iOS code using familiar Android analogies.
AI-Maintained Knowledge Base
A structured, version-controlled set of markdown files that an LLM periodically updates by deduplicating pitfall logs, generating cross-references, flagging deprecated APIs, and filling gaps based on recent development issues.
Progressive Architecture Migration
An AI-designed plan to incrementally move an iOS codebase from one architectural pattern (e.g., MVC) to another (e.g., MVVM) without a full rewrite, often needed when the two platforms use different patterns and direct code translation is impractical.
From the discussion

The conversation quickly pivots from the article's AI-assisted development theme to a shared grievance about expanding job scopes. The initial suggestion to tackle HarmonyOS next is met with a preference for it over iOS, purely due to language unfamiliarity. A consensus forms around the normalization of multi-platform responsibilities on a single salary, capped by a concrete example of a boss demanding a full native rewrite from Flutter to match an iOS codebase.

— Developers are being asked to cover more platforms than their core expertise, with HarmonyOS mentioned as the next frontier.
— Unfamiliarity with a platform's language (Objective-C/Swift) makes iOS a less desirable assignment than HarmonyOS for some.
— One salary covering multiple distinct engineering roles has become an accepted, if resented, industry norm.
— A management request to port an entire iOS project to native Android, abandoning an existing Flutter codebase, represents an extreme case of scope creep.
Featured comments
bqliang

Gross. The boss not only wants me to write native iOS… but also wants me to translate the iOS project into a native Android project (currently the Android side is written in Flutter) [awkward]

See top comments, translated →
Source: juejin.cn ↗ Google Translate ↗ Backup ↗