Best iOS and mobile development skills for AI agents

Apple platform work punishes a model's memory harder than almost any other stack. Version numbers moved sideways — Apple shipped iOS 26 at WWDC 2025, jumping straight from 18 and skipping 19 through 25 — so an agent reasoning from training data will confidently tell you a real OS version does not exist. Xcode 27 replaced the Simulator app with Device Hub. @Observable retired ObservableObject boilerplate. BuildConfig stopped generating by default in Android Gradle Plugin 8.0. None of this is guessable. Meanwhile the mechanical part goes wrong quietly: an agent that cannot boot a simulator, read an accessibility tree, or tell a stale Derived Data folder from a genuine compile error will spend an hour rewriting perfectly good Swift.

Here is the thing that surprised me: the Apple-platform skills worth installing barely talk about Swift at all. They talk about the loop — boot, build, install, launch, look, log — and about the specific places that loop lies to you. One tells your agent that taps on inline links inside a SwiftUI Text report success and do nothing, because the accessibility tree never exposes them as separate elements. That is the kind of thing no amount of general knowledge supplies, and it is the difference between an agent that says "tested, works" and one that is right.

Top picks

Simulator control: conorluddy's script suite, not a command cheat sheet

ios-simulator-skill ships 29 scripts and one strong opinion: navigate by accessibility tree, never by pixels. The body puts a price on the alternative — a screenshot costs roughly 1,600 to 6,300 tokens depending on size, the structured element list costs 10 to 50 — and the workflow follows from that. sim_health_check.sh verifies Xcode, simctl and Python before anything else; screen_mapper.py lists what is on screen; navigator.py --find-text "Login" --tap acts on meaning rather than coordinates, so it survives a layout change. Past the basics it gets unusually deep: hang_watcher.py runs a detached recorder, clusters os_log hang events, and will diff two sessions against each other for regressions; privacy_manager.py grants and revokes app permissions; status_bar.py freezes the clock at 9:41 for clean screenshots. Nearly every operational limit is an environment variable, documented in a table — boot waits default to 300 seconds, an xcodebuild test invocation is killed at 2700.

The obvious rival is simulator-utils, a well-organised command reference covering xcrun simctl device and app operations, xcodebuild invocations, a build-terminate-install-launch-screenshot workflow, sips image handling and a troubleshooting section. Its sharpest single insight is one most agents need — always pipe a screenshot through sips --resampleHeightWidthMax 1800, because iPhone 17 simulator captures exceed 2000px and the Claude API rejects images over that in multi-image requests. What it has no notion of is finding an element. Everything it does happens by name, path or bundle id; nothing reads the screen. That is the whole gap. Caveat on conorluddy's: this is a skill that ships executables, so you are installing a scripts/ directory and a Python 3 dependency, not a page of prose. Read what you are running.

Build failures: route them through Axiom before touching the code

axiom-build is a router, and its central claim is a discipline rather than a technique: 90% of mysterious iOS issues are environment, not code, so check the environment first. It fans a failure out to the right specialist — SPM resolution conflicts to a package-graph agent, "app builds but runs old code" to a build-fixer that checks zombie xcodebuild processes, Derived Data, SPM cache and simulator state before it reads a line of Swift, slow compiles to a build-optimizer aimed at type-checking bottlenecks and expensive build phase scripts. Crash triage, TestFlight symbolication and LLDB each get their own route, with a one-line reason why: crash reports tell you what crashed, LLDB tells you why.

Its companion axiom-tools is where the maintenance shows. It carries a table of rationalizations the agent is told to treat as stop signs — "I remember how to do this from last time" is answered with "iOS changes constantly", and "this iOS version doesn't exist" is answered with the actual iOS 26 numbering history. It documents Device Hub in Xcode 27 and points at the CLI equivalents, including the unified devicectl device capture path for screenshots and screen recording from Xcode 26.6 onward. Two caveats. The tone is shouty — a block of capitalised must-use language that will not suit every setup. And the routing is only partly self-contained: the environment, build-performance, dependency and LLDB routes all point at files shipped inside the skill's own package, but crash triage and App Store Connect send you to axiom-shipping, MetricKit and hang diagnostics to axiom-performance, and the privacy scanner to axiom-security. Install those or those particular routes go nowhere. The body is candid, too, that build, test, simulator and symbolication work needs Bash and stays Claude Code-only.

The smoke test: ce-test-xcode knows where automation lies to you

ce-test-xcode is the one to hand an agent when you want "build it, run it, click through it, tell me what broke". It refuses to start until XcodeBuildMCP answers a list_simulators call, then walks discover project, list schemes, boot, build, install, launch, start log capture, screenshot each screen, read the logs for crashes and failed network requests, and finish with a results table per screen. Two details lift it above every other test-the-app skill on this topic. First, the SwiftUI Text trap: simulated taps on inline AttributedString links report success and do nothing, because inline links are not separate elements in the accessibility tree — the skill tells the agent to stop, ask the human to tap, or fall back to xcrun simctl openurl. Second, it enumerates the flows automation genuinely cannot do — Sign in with Apple, push notifications, sandbox purchases, camera and location permissions — and blocks on a real question to the user instead of hallucinating a pass.

If you would rather not run an MCP server, xcodebuildmcp-cli is the same tooling as an executable, and its instruction is smart: discover commands from xcodebuildmcp tools and --help rather than from a memorised tool list that goes stale, prefer the combined build-and-run, and do not chain build into build-and-run. The caveat on ce-test-xcode is that it sets disable-model-invocation: true — your agent will never reach for it unsolicited, you have to call it.

Swift style: pick the one that argues, not the one that teaches

swift-expert is built as opposed pairs — the right pattern next to the wrong one, with the reason. @Observable instead of ObservableObject plus @Published; an actor instead of a class guarding a cache with NSLock; a protocol with an associated type instead of a base class whose one method is a fatalError stub waiting to be overridden. The part that matters operationally is the validation checkpoints: build after implementing, then run swift build -warnings-as-errors specifically to surface actor isolation and Sendable warnings, then run the async tests. That turns style guidance into something an agent can fail.

There is a second swift-expert, published by personamanagmentlayer, and the bodies are not close. That one is a Swift language tour — optionals, guard, closures, enums with raw values, map/filter/reduce — material any competent model already has. It does one thing better: its frontmatter scopes Bash to swift: and xcodebuild: invocations, which is a real containment win. If that matters more to you than the guidance does, take it knowingly.

Android: MiniMax's guide is the one that unblocks a build

android-native-dev opens by classifying the project — empty directory, has a Gradle wrapper, Android Studio project without one, half-finished — and refuses to write business logic until ./gradlew assembleDebug passes. That ordering alone prevents the most common Android agent failure. It then front-loads the traps that break builds for reasons no error message explains: BuildConfig is not generated by default from Android Gradle Plugin 8.0 and must be switched on in buildFeatures; resource and variable names that collide with Android reserved words (background, icon, view, id) cause conflicts and need prefixes. There is an error-keyword lookup table — Duplicate class sends you to ./gradlew dependencies, AAPT: error to your XML — and a Material Design 3 section with the numbers designers actually check: 48 by 48dp minimum touch targets, an 8dp spacing grid, component heights, animation durations by category.

A second android-native-dev, from lioensky, covers similar ground under the identical name but carries a NOASSERTION license, which is a redistribution question you inherit. If you want an ambient style guide rather than a setup guide, android-kotlin lays out a Hilt/Compose/Room layering with MockK testing, but note its frontmatter: it is marked not user-invocable and path-scoped to Kotlin and Gradle files, so it is designed to hover over edits, not to run a task.

Cross-platform: argent drives iOS, Android and Electron with one vocabulary

Software Mansion's argent-device-interact gives your agent a single tool surface across an iOS simulator, an Android emulator and any Chromium runtime exposing a DevTools endpoint, dispatching on the shape of the device id — a UUID means iOS, an adb serial means Android. Coordinates are normalized to 0.0 through 1.0 everywhere, and the standing instruction is to call describe before tapping rather than navigate from a screenshot. It is also honest about its edges: TV targets are focus-driven rather than touch-driven, and the skill tells the agent to stop and switch rather than swipe at an Apple TV. Its one hidden dependency is worth knowing up front — the tapping guidance defers to a tapping_rule that lives in your project's own argent.md file, so the skill assumes a repo convention it does not ship.

argent-create-flow is the reason to take the suite seriously. It records reusable YAML flows where every step is executed live as you add it, so a flow cannot be saved before it is proven, and a recorded coordinate tap is upgraded to a portable selector tap whenever the element has stable text. The distinction it draws is genuinely useful: an e2e flow begins with a launch and owns its start state, so it is the only kind meaningful as a CI entry; a fragment runs against whatever is on screen and declares its entry-state contract. Directives cover await, assert, snapshot diffing against a baseline, and conditional blocks, and every one hard-stops the run on failure. It is fussy in one place worth knowing: you pass an absolute project_root to the recorder once, it is rejected if the path is not absolute, and it is then reused for the rest of the session. The caveat is structural: all of this is documentation for an MCP server, so without that server installed the skills describe tools your agent does not have. And argent-ios-simulator-setup, the on-ramp, is two numbered steps and a note about what a UDID looks like — budget for reading the tool docs yourself.

A skill's name is only its topic

Skills are community-published and names are not namespaced, so the same name routinely wraps completely different documents. ios-development is the clearest case. The rshankras version is a router into modules for HIG review, accessibility audits, navigation patterns, and running the app on a simulator or a physical device — and it argues with itself about what it is allowed to do. The frontmatter grants only Read, Glob, Grep and WebFetch, which reads as advisory. The body then describes a run-simulator module explicitly marked operational rather than guidance, and a run-device module that builds and code-signs with xcodebuild -allowProvisioningUpdates, installs via devicectl, and screenshots hardware through libimobiledevice. Whichever half your harness honours, know which one you were counting on. It also carries last_verified and review_by dates plus a target OS version, which is the strongest maintenance signal on this topic.

The travisjneuman version under the identical name is a long reference sheet: an ObservableObject-to-@Observable migration table, Swift 6 typed throws, visionOS ImmersiveSpace and watchOS complications, HIG metrics down to the 44 by 44pt touch target. And the CoWork-OS version is neither — it is a routing manifest with positive and negative trigger examples, whose actual instructions live in a JSON file it names but does not include, reporting only that the runtime prompt is 893 characters long. Useful inside its own harness. Empty on its own.

The same pattern hits kotlin-multiplatform. The travisjneuman one is a general KMP reference — source set layout, expect/actual, Ktor, SQLDelight. The vitorpamplona one is an abstraction decision tree written for the Amethyst codebase, with a "should this be shared?" flowchart whose worked examples are that project's own crypto and JSON types. Both are good. Installing the second one puts one specific app's architecture rules in your agent's head.

The check is always the same: open the body and look at the publisher. The name tells you the topic; only the body tells you what your agent will actually be told to do.

What to check before you install

Does it target your app, or the tool's own repo? The sharpest trap on this topic wears a familiar name. Alongside the app-facing CLI skill, the XcodeBuildMCP project publishes contributor guardrails under near-identical names — xcodebuildmcp-test-boundary-review tells the agent to inspect src/**/__tests__/**, treat snapshot updates as contract changes, and run npm test and npm run typecheck. That is excellent advice for someone submitting a pull request to XcodeBuildMCP and pure noise inside your iOS app. Same publisher, same prefix, entirely different audience.

Does it encode someone else's architecture? ios-xcode is a well-organised set of 19 rules across 6 categories covering SwiftData containers, Swift Testing, Instruments and TestFlight — but every rule assumes a specific modular MVVM-C contract where feature modules may import only two named modules and the app target owns the dependency container. Adopt that architecture and the skill is excellent. Do not, and you have installed an argument.

Will it fire when you expect? Frontmatter decides this more than the description does. disable-model-invocation means the agent will never choose the skill; user-invocable: false with path globs means the opposite, an always-on style guide over matching files. Check which you are getting before you wonder why nothing happened.

Can you actually use it? A NOASSERTION license or no license at all is common here, including on some of the longest and most detailed Swift persistence writeups available. Depth you can read is not always depth you can redistribute, and that distinction matters the moment the skill lands in a work repo.

What you end up with

The failure mode this topic invites is an agent that writes plausible Swift against a version of Apple's platforms that no longer exists, then declares the result tested because a simulated tap returned success. The fix is not a better Swift reference. It is a build-and-run loop the agent can actually execute, plus something that knows where that loop misleads.

Install conorluddy's simulator scripts for semantic navigation and hang capture, route build failures through Axiom before anyone edits code, and use ce-test-xcode for the click-through pass that stops and asks a human at Sign in with Apple instead of guessing. Add Jeffallan's swift-expert if you want the style guidance to come with a command that can fail it. On Android, MiniMax's guide gets a Gradle build green before anything else happens; on React Native and Electron, argent's recorded flows turn a proven interaction into something replayable in CI. Check the license and the publisher before each one lands, because on this topic a familiar name has told you almost nothing.