Stack IA para Desarrollo Móvil — iOS + Android

What's in this pack

This is the stack a mobile engineer reaches for when AI actually has to ship to App Store and Play — not the listicle of every IDE on Earth. Every pick covers one rung of the same ladder: pick the framework you'll write in, give the agent enough context to scaffold real UI in that framework, give it the build tools to compile and boot a simulator, prove the screen works on a real device through an E2E driver, and ship the signed artifact to the stores without doing the upload dance yourself.

The pack is deliberately framework-plural — Swift for native iOS, Kotlin for native Android, Expo + React Native for the JavaScript shop, Flutter + Dart for the single-codebase shop. The five layers (framework, AI UI, build, test, ship) are the same regardless of which you pick; the tooling under each layer is what changes. Treat the framework picks as a menu — install the one (or two) you'll actually code in, then the four pipeline layers that wrap around it.

Install in this order (framework → AI UI → build → test → ship)

1. Pick your framework first (assets 4–7). The rest of the pipeline depends on the choice. Flutter (#1070) if you want one codebase and Google-grade rendering. Expo (#1002) if your team already lives in TypeScript and you need OTA updates. Swift (#1071) and Kotlin (#1072) if you're building a native-first app where every platform-specific affordance matters. Most teams install two — one cross-platform plus one native — so they can drop down when the cross-platform abstraction leaks.
2. Mobile App Developer agent (#4377) — the orchestrator. Cross-platform agent that reads your project structure, decides whether the change is iOS, Android, or both, and delegates to the specialist agents. Daily driver; everything below routes through it.
3. iOS Developer agent (#4376) — Swift / SwiftUI / UIKit specialist. Use for native iOS screens, Core Data schemas, AVFoundation pipelines, and anywhere SwiftUI's modifiers go six layers deep. The agent understands @StateObject, @Observable, navigation stacks, and the Info.plist privacy keys you forgot.
4. Flutter Expert agent (#4522) — Flutter 3+ specialist. For widget trees, state management (Riverpod / Bloc / Provider — pick one and stick), platform channels to native APIs, and the pubspec.yaml dance. Pair with the Flutter framework (#1070) install above.
5. XcodeBuildMCP (#3065) — build & simulator tools for the agent. Without this, the agent writes Swift code and can't compile it; with this, the agent can call xcodebuild, list simulators, boot one, install the .app, and read back logs. The missing link between an agent that writes iOS code and one that ships it.
6. Maestro (#2950) — E2E test that the agent can write. Declarative YAML (tapOn, assertVisible, swipe) runs on iOS simulator, Android emulator, and physical devices over USB. Replaces the Appium / Detox / Espresso debate with one tool that the agent can author flows for in 30 seconds.
7. Fastlane (#3074) — the ship layer. Automates code signing, TestFlight uploads, App Store Connect metadata, Play Store releases, screenshot generation. The agent writes the Fastfile, you run fastlane beta, and the next build is in TestFlight without you opening Xcode Organizer.

How they fit together (ASCII pipeline)

   product idea / Figma
        │
        ▼
  ┌──────────────────────────────────┐
  │ Mobile App Developer Agent       │
  │ (#4377) — repo-aware orchestrator│
  └──────┬───────────────────────────┘
         │ routes by platform
         ├──────────────┬──────────────┐
         ▼              ▼              ▼
  ┌────────────┐ ┌─────────────┐ ┌──────────────┐
  │ iOS Dev    │ │ Flutter     │ │ Expo / RN    │
  │ Agent      │ │ Expert      │ │ (#1002)      │
  │ (#4376)    │ │ (#4522)     │ │ + JS / TS    │
  │ + Swift    │ │ + Flutter   │ │              │
  │ (#1071)    │ │ (#1070)     │ │              │
  └─────┬──────┘ └──────┬──────┘ └──────┬───────┘
        │               │               │
        ▼               ▼               ▼
  ┌────────────┐ ┌─────────────┐ ┌──────────────┐
  │ Kotlin     │ │ XcodeBuild  │ │ Metro / EAS  │
  │ (#1072)    │ │ MCP (#3065) │ │ build        │
  │ for Android│ │ build + sim │ │              │
  └─────┬──────┘ └──────┬──────┘ └──────┬───────┘
        └───────────────┼───────────────┘
                        ▼
              ┌──────────────────┐
              │ Maestro E2E      │
              │ (#2950)          │
              │ iOS + Android    │
              └────────┬─────────┘
                       │
                       ▼
              ┌──────────────────┐
              │ Fastlane (#3074) │
              │ certs · TestFlight│
              │ App Store · Play │
              └────────┬─────────┘
                       │
                       ▼
               App Store / Play

The critical join is Mobile App Developer Agent + XcodeBuildMCP + Maestro: the agent writes Swift or Dart, XcodeBuildMCP compiles it and boots a simulator, Maestro proves the screen actually responds to taps. Without XcodeBuildMCP, the agent ships code that compiles in its head; without Maestro, you find out at TestFlight that the login button doesn't fire on Android 12 small screens.

Tradeoffs (the honest part)

• Cross-platform vs native. Flutter and Expo are 70% of the way to native feel; the last 30% (haptics, custom keyboards, share extensions, platform-specific privacy prompts, Live Activities, App Clips, Wear OS tiles) is where the abstraction leaks. Pick cross-platform when you ship one product to both stores fast; pick native when one platform's deep integrations are the product. Real teams ship Flutter for the main app and native modules for the 5% that needs it.
• Expo vs bare React Native. Expo gives you OTA updates, EAS Build, prebuilt native modules, and a faster local loop. Bare React Native gives you full Xcode / Gradle access and any third-party SDK. Default to Expo, eject only when you hit a wall — most teams never need to.
• Maestro vs Appium vs Detox. Maestro is in this pack because the agent can author flows in YAML in seconds. Appium is more mature and supports any framework but the WebDriver dance is painful. Detox is fast for React Native specifically. For agent-driven testing, Maestro wins on author cost.
• XcodeBuildMCP vs running xcodebuild yourself. You can call xcodebuild from a terminal; the MCP wraps it so the agent can call it without you copy-pasting. The value is agent autonomy, not faster builds.
• AI-generated UI quality. First-draft SwiftUI from an agent often has the right shape but wrong navigation patterns (NavigationStack vs NavigationView, sheet vs fullScreenCover, the right keyboard avoidance). Always run the screen in the simulator before merge; reviewers will catch what the agent missed.
• Apple Review risk. Apple's reviewers reject for 4.2 ("minimum functionality") faster than they did two years ago. An AI-scaffolded MVP that's a thin wrapper around an API will fail review. Ship a feature, not a chat UI on top of a model.
• Fastlane vs Xcode Cloud vs EAS. Fastlane runs anywhere (your laptop, GitHub Actions, Bitrise) and stays portable. Xcode Cloud is convenient but iOS-only and locks you in. EAS is convenient for Expo specifically. Fastlane is the lingua franca.

Common pitfalls

• Apple Review 4.2 rejection. "Your app does not provide enough functionality" — the most common rejection for AI-scaffolded MVPs. Wrappers around ChatGPT, single-screen utilities, and "AI photo edit" clones get rejected on first submit. Ship a real feature with offline state, settings, an account flow, and at least three meaningful screens before submitting.
• Android fragmentation. Build looks great on a Pixel 8 emulator, ships, then breaks on a Samsung mid-range with a 3:2 aspect ratio and a non-standard density. Test on at least three real form factors (small phone, large phone, tablet) — Maestro on a device farm is the cheapest way.
• Missing privacy permission strings. iOS rejects builds (Apple 5.1.1) if you access camera / mic / location / photos and the Info.plist NSCameraUsageDescription etc. is missing or generic. The agent forgets these constantly; add a pre-submit checklist that greps for every privacy key.
• IAP sandbox testing skipped. App Store Connect rejects (3.1.1) if your subscription / IAP flow wasn't tested with a sandbox tester account. The sandbox is its own world (separate Apple ID, different receipts, slower) and easy to skip when iterating. Build a Maestro flow that drives the IAP purchase end-to-end on a sandbox account before every release.
• Pushing a non-signed build to TestFlight. Fastlane handles certs and provisioning profiles if you let it (match for shared keys). Doing it manually leads to the 11:59 PM cert-expiry panic. Set match up on day one, store the keys in a private repo, never look back.
• Letting the agent generate platform-specific code into shared files. Expo / Flutter shared code with Platform.OS === 'ios' branches everywhere is a maintenance tax. Push platform-specific logic into *.ios.tsx / *.android.tsx files (Expo) or platform channels (Flutter) so the shared layer stays clean.
• Skipping Maestro because "the simulator looks fine". The most common AI-mobile regression is a tap target that's 40pt on iOS (fine for fingers) but the agent sized 20pt (fine for clicks); accessibility scan catches it once, your hands catch it never. Maestro tapOn with explicit coordinates surfaces this in 30 seconds.
• Treating MCP servers as optional plumbing. Without XcodeBuildMCP, the agent has to ask you to run xcodebuild and paste output. Wire the MCPs first (an afternoon), then the rest of the pack pays off every day.