How to Use Claude Agent in Xcode 27 and Verify Its Code on Real iPhones

Option 1: Kane CLI, Plain-English Checks From the Terminal

Kane CLI is TestMu AI's testing agent for the terminal. It works in conjunction with Claude Code, Codex, Cursor, and Gemini CLI. You specify the outcome you're looking for, and Kane CLI will run that against your build on a real iPhone in the TestMu AI cloud.

It returns a pass/fail exit code and an evidence file. There's a separate inspection step (not the model that's driving the steps) which makes the pass/fail decision against your acceptance criteria. Once saved, the test will simply re-run the same steps on every run.

npm install -g @testmuai/kane-cli
kane-cli login

# List real iPhones available on iOS 17
kane-cli devices list --target ios --remote --os-version 17

# Verify Claude Agent's change on a real iPhone
kane-cli run "Add the first item to the cart, open the Cart tab and confirm it shows 1 item" \
  --target ios --device-name "iPhone.*" --os-version 17 \
  --app ./build/MyApp.ipa --agent --timeout 600

With no terminal attached, or with --agent, the device list prints one JSON line per device. At the time of writing, iOS 17 returns 15 real devices, iPads included:

{"name":"iPad 10.2 (2019)","brand":"Apple","os_versions":["17"]}
{"name":"iPad Air 13 (2024)","brand":"Apple","os_versions":["17"]}
{"name":"iPad Pro 11 (2024)","brand":"Apple","os_versions":["17","26"]}
{"name":"iPad Pro 12.9 (2021)","brand":"Apple","os_versions":["17"]}
{"name":"iPad Pro 12.9 (2022)","brand":"Apple","os_versions":["16","17"]}
{"name":"iPad Pro 13 (2024)","brand":"Apple","os_versions":["17","26","27"]}
{"name":"iPhone 12 Mini","brand":"Apple","os_versions":["14","15","16","17"]}
{"name":"iPhone 13","brand":"Apple","os_versions":["15","16","17","18","26","27"]}
{"name":"iPhone 13 Pro","brand":"Apple","os_versions":["15","17","26"]}
{"name":"iPhone 13 Pro Max","brand":"Apple","os_versions":["15","17","27"]}
{"name":"iPhone 14","brand":"Apple","os_versions":["16","17","18","26"]}
{"name":"iPhone 15","brand":"Apple","os_versions":["17","26"]}
{"name":"iPhone 15 Pro","brand":"Apple","os_versions":["17","18","26","27"]}
{"name":"iPhone 15 Pro Max","brand":"Apple","os_versions":["17","26"]}
{"name":"iPhone SE (2020)","brand":"Apple","os_versions":["14","17"]}
{"total":15,"platform":"ios","kind":"real-device"}

What to know first (Kane CLI 0.9+ docs, checked Nov 9, 2026):

• Exit codes are 0 = pass, 1 = fail, 2 = setup or auth error, and 3 = timeout or cancel. That way, the CI and coding agents can gate on them.
• --agent prints out structured NDJSON that Claude can read and act upon. --timeout is in seconds.
• Real device runs require an .ipa (not a simulator .zip), you install the app fresh for every run, and you need KaneAI Max or a Real Device Plus Automation Cloud plan. Plans, parallel limits, and heal rules are all in the Kane CLI on real iOS and Android devices.

Run it from inside Xcode: add kane-cli to Xcode > Settings > Intelligence > Permissions > Allowed Commands. Then just tell the Claude Agent to run your check with --agent after each task. If the agent comes back with "command not found," then allow the full path that kane-cli prints out in Terminal.

From Claude Code: install the Kane plugin via the Claude Plugin Marketplace (add LambdaTest/kane-claude-plugin and then claude plugin install kane-qe@lambdatest). The full workflow is detailed in the 'How to use Claude Code for testing with Kane CLI' guide. (TestMu AI was formerly LambdaTest, so some of the plugin and API names will still be lambdatest.)

Try it on your next Claude Agent task.

Note: Install the Kane CLI, claim the free credits on the Kane CLI page, and run your very first plain English check on your local iOS simulator today. Add on KaneAI Max or a Real Device plan when you're ready to gate merges on real iPhones. Start free with Kane CLI.

Option 2: XCUITest Suites on the Real Device Cloud

If you already have XCUITest suites, then just keep those as your release gate and run XCUITest on real iPhones. Have Claude Agent write the UI tests as well, but have a human review the assertions. A test is only of any value if someone other than the agent has decided what "correct" is.

Here's a small XCUITest that covers something that Previews never get to: a system permission alert on a fresh install.

import XCTest

final class CheckoutFlowUITests: XCTestCase {

    override func setUpWithError() throws {
        continueAfterFailure = false
    }

    func testAddFirstItemToCart() throws {
        let app = XCUIApplication()
        app.launch()

        // A fresh install shows the location prompt. It's SpringBoard's prompt not ours.
        let springboard = XCUIApplication(bundleIdentifier: "com.apple.springboard")
        let allow = springboard.buttons["Allow While Using App"]
        if allow.waitForExistence(timeout: 5) {
            allow.tap()
        }

        let addButton = app.buttons["product.addToCart.0"]
        XCTAssertTrue(addButton.waitForExistence(timeout: 10))
        addButton.tap()

        app.tabBars.buttons["Cart"].tap()

        let count = app.staticTexts["cart.itemCount"]
        XCTAssertTrue(count.waitForExistence(timeout: 5))
        XCTAssertEqual(count.label, "1 item")
    }
}

The product.addToCart.0 and cart.itemCount identifiers are the ones we'd use in our views, assuming we'd set .accessibilityIdentifier(...) on them. Having Claude Agent add in some stable identifiers is a good first thing to do.

To run the suite on real devices, you build for testing with signing set to your group. Then you wrap the app, and the test runner .app bundles up in a Payload folder and zip each one as an .ipa:

xcodebuild build-for-testing -scheme MyApp \
  -destination 'generic/platform=iOS' -derivedDataPath build/dd

cd build/dd/Build/Products/Debug-iphoneos
mkdir Payload && cp -R MyApp.app Payload/ && zip -qr ../../../../MyApp.ipa Payload && rm -rf Payload
mkdir Payload && cp -R MyAppUITests-Runner.app Payload/ && zip -qr ../../../../MyAppUITests-Runner.ipa Payload && rm -rf Payload
cd -

Then upload both and start a build through the TestMu AI XCUITest API, as documented in XCUITest on TestMu AI:

# Upload the app and the test suite (each returns an lt://APP... id)
curl -u "$LT_USERNAME:$LT_ACCESS_KEY" -X POST \
  "https://manual-api.lambdatest.com/app/uploadFramework" \
  -F "appFile=@MyApp.ipa" -F "type=xcuit-ios"

curl -u "$LT_USERNAME:$LT_ACCESS_KEY" -X POST \
  "https://manual-api.lambdatest.com/app/uploadFramework" \
  -F "appFile=@MyAppUITests-Runner.ipa" -F "type=xcuit-ios"

# Start a build on real iPhones (devices in the list run in parallel)
curl -X POST "https://mobile-api.lambdatest.com/framework/v1/xcui/build" \
  -H "Authorization: Basic $(printf '%s' "$LT_USERNAME:$LT_ACCESS_KEY" | base64)" \
  -H "Content-Type: application/json" \
  -d '{
    "app": "lt://APP_ID",
    "testSuite": "lt://TEST_SUITE_ID",
    "device": ["<iPhone model>-<iOS version>", "<iPhone model>-<iOS version>"],
    "video": true,
    "devicelog": true,
    "build": "claude-agent-pr-142"
  }'

Pick devices from the Real Device Cloud list in the format "model-iOS version". The Real Device Cloud supports XCUITest along with network throttling, Face ID and Touch ID, camera image injection, SIM-based OTP, Apple Pay and VoiceOver checks, video and device logs for every session. For any suites that have to finish in a PR window, run them on HyperExecute (which is up to 70% faster than a traditional grid).