iOS driver build fails on Xcode 26.4: missing MaestroDriverLib/Info.plist

[12mv2]

Summary

Maestro 2.4.0 fails to build the iOS driver when targeting a physical iPhone on Xcode 26.4. The xcodebuild step for MaestroDriverLib (framework target inside the bundled maestro-driver-ios project) can't find its own Info.plist input file. Signing, team ID, and provisioning profile resolution all succeed — the failure is deeper in the build phase.

Environment

• Maestro: 2.4.0 (latest — installed 2026-04-23 via official shell installer)
• Xcode: Xcode 26.4 (Build version 17E192)
• macOS: Darwin 25.2.0 / Apple Silicon (arm64)
• Target device: iPhone 17 Pro, iOS 26.3.1, USB-connected
• Apple Developer team: paid team, valid provisioning profile installed

Reproduction

Run against a physical iPhone with a valid signing team configured in Xcode:

maestro --udid <device-udid> test --apple-team-id <TEAM_ID> path/to/flow.yaml

Expected: Maestro builds + installs iOS driver, runs the flow.
Actual: Driver build fails during xcodebuild phase.

Error

ProcessInfoPlistFile
  /<…>/Build/Products/Debug-iphoneos/MaestroDriverLib.framework/Info.plist
  /var/folders/…/T/maestro-xcodebuild-output<…>/MaestroDriverLib/Info.plist
  (in target 'MaestroDriverLib' from project 'maestro-driver-ios')
    cd /var/folders/…/T/maestro-xcodebuild-output<…>
    builtin-infoPlistUtility /var/folders/…/T/maestro-xcodebuild-output<…>/MaestroDriverLib/Info.plist
      -producttype com.apple.product-type.framework
      -expandbuildsettings -format binary -platform iphoneos
      -requiredArchitecture arm64
      -o /<…>/Build/Products/Debug-iphoneos/MaestroDriverLib.framework/Info.plist

error: Build input file cannot be found:
  '/var/folders/…/T/maestro-xcodebuild-output<…>/MaestroDriverLib/Info.plist'.
  Did you forget to declare this file as an output of a script phase or custom build rule which produces it?
  (in target 'MaestroDriverLib' from project 'maestro-driver-ios')

** TEST BUILD FAILED **

Diagnosis (best guess)

The MaestroDriverLib target expects Info.plist at a temp path generated by an earlier build phase. On Xcode 26.4 something in the framework build pipeline no longer generates that file at the expected location, and the ProcessInfoPlistFile step reads from a path that doesn't exist.

The bundled maestro-driver-ios/project.pbxproj likely needs either:

• An explicit INFOPLIST_FILE pointing at a source-committed plist, or
• A script-phase output declaration that Info.plist is a generated output

Similar issues from other projects on Xcode 26.x point to the framework Info.plist handling changing around product-packaging. Same root usually surfaces as "Build input file cannot be found" on auto-generated plists.

Signing works fine

The signing half of the pipeline completes cleanly with --apple-team-id:

Entitlements:
{
  "application-identifier" = "<TEAM>.dev.mobile.maestro-driver-ios";
  "com.apple.developer.team-identifier" = <TEAM>;
  "get-task-allow" = 1;
}

Provisioning profile resolution and codesign-identity-override both work. It's only the framework's Info.plist generation that breaks.

Workarounds I tried

• --reinstall-driver flag — same error (rebuild from scratch, same failure)
• Pre-xcodebuild clean on the Maestro driver derivedData — same error
• Verifying Xcode 26.4 is stable for non-Maestro device builds — yes, the project's own Run Fun app signs + installs to device fine via xcodebuild

So the issue is specific to the bundled maestro-driver-ios Xcode project's framework target config, not to the system's signing/Xcode setup.

Request

• Confirm Xcode 26.4 compatibility status for Maestro 2.4.0
• If there's a workaround (env var, branch of maestro-driver-ios, version pin), please document
• Fix target: possibly Maestro 2.4.1 or 2.5.0 if the bundled driver project needs an update

Impact

This blocks all physical-device automation on Xcode 26.4 (the current Xcode release). Simulator path still works (we're using it today).

Happy to test fixes against this environment.

---

Generated during iOS test-harness build-out (2026-04-24). Full build log available on request.

[linear]

MAE-456

[Fishbowler]

Thanks for the report.

If you got past this point you'd quickly see that physical iPhones won't work for almost all flows anyway - lots of things still rely on simctl and the like. It's something we're working on, and we expect to have physical iOS support later this year.

[12mv2]

Quick follow-up after digging through the docs and adjacent issues — I see physical iOS device support isn't currently an officially supported feature (UIKit docs state "Executing tests on physical iOS devices is not supported yet"), so this report is more "here's a repro for when device support is on the roadmap" than a regression. Happy to leave it open as future reference; close at your discretion.

If there's a tracked issue or rough timeline for official device support I can subscribe to instead, that'd be useful — couldn't find one in mobile-dev-inc/Maestro. Thanks.

[gbossirus]

Pinning the root cause and a one-line fix for this issue, in case it helps prioritize a packaging-only patch even while broader physical-iPhone support is on the longer roadmap.

Root cause

maestro-cli/build.gradle.kts line 25-32 in cli-2.5.1 bundles the iOS driver source into the JAR with this include list:

from("../maestro-ios-xctest-runner") {
    into("driver/ios")
    include(
        "maestro-driver-ios/**",
        "maestro-driver-iosUITests/**",
        "maestro-driver-ios.xcodeproj/**",
    )
}

The list omits MaestroDriverLib/**, even though the xcodeproj has a MaestroDriverLib framework target with:

GENERATE_INFOPLIST_FILE = YES;
INFOPLIST_FILE = MaestroDriverLib/Info.plist;

…and references MaestroDriverLib/Sources/MaestroDriverLib/*.swift. So when DriverBuilder.kt extracts driver/ios from the JAR into $TMPDIR/maestro-xcodebuild-output…/, the MaestroDriverLib/ directory is missing entirely. xcodebuild fails immediately on the absent Info.plist. That is the exact path reported in the original ticket.

Fix

from("../maestro-ios-xctest-runner") {
    into("driver/ios")
    include(
        "maestro-driver-ios/**",
        "maestro-driver-iosUITests/**",
        "maestro-driver-iosTests/**",
        "MaestroDriverLib/**",
        "maestro-driver-ios.xcodeproj/**",
    )
}

(maestro-driver-iosTests/** is also missing today; including it for completeness, since project.pbxproj references its Info.plist from the test target.)

Verification

Patched my local maestro-cli-2.5.1.jar by adding driver/ios/MaestroDriverLib/ and driver/ios/maestro-driver-iosTests/ from the matching tag with jar uf. After clearing ~/.maestro/maestro-iphoneos-driver-build, the next maestro --udid <udid> test --apple-team-id <TEAM> run drove the build through to:

✅ Drivers successfully set up for destination platform=iOS,id=…

…then installed the runner via xcodebuild test-without-building and ran a smoke flow against a physical iPhone 17 Pro Max (iOS 26.3.1, Xcode 26.2). assertVisible passed against the target app, screenshot in hand.

Two follow-on caveats once the JAR is fixed (separate from this packaging bug, but worth flagging for anyone trying physical iOS today):

1. The XCTest runner binds to TEST_RUNNER_PORT=7001 on the device, but Maestro doesn't set up a tunnel to it — running iproxy 7001:7001 -u <udid> (libimobiledevice) before maestro test is needed to reach the runner from the host.
2. LocalIOSDevice.launch() routes through DeviceControlIOSDevice.launch(), which is TODO("Not yet implemented") (source). Routing to xcTestDevice.launch() instead — which already has an end-to-end XCUIApplication-based implementation via the runner — makes launchApp work on physical iPhones with no further changes. One-line patch in LocalIOSDevice.kt:107.

Happy to open PRs for both — the gradle one is fully self-contained and doesn't broaden physical-device commitment, just makes the existing path build.

Environment: Maestro 2.5.1, Xcode 26.2 (17C52), macOS 26.3.1 (Apple Silicon), iPhone 17 Pro Max iOS 26.3.1.

[redwards72git]

Adding a third independent reproduction + a runtime-crash data point one .x version above @gbossirus's stack, in case it helps sequence the fix.

Confirmation of root cause + the JAR-patch fix

Hit this on Xcode 26.3 (17C529) / macOS 26.4 / iPhone 15 / iOS 26.4.2 / Maestro 2.5.1 under the same conditions @12mv2 originally reported. appleTeamId was correctly set in ~/.maestro/config.yaml; the auto-rebuild failed with the same Build input file cannot be found: '/var/folders/.../MaestroDriverLib/Info.plist' trace. @gbossirus's root-cause analysis is correct — the gradle include list omits MaestroDriverLib/** so DriverBuilder.kt extracts an incomplete driver/ios tree.

Two independent recovery paths both work on the cache-restoration layer:

1. JAR patch (@gbossirus's route). Verified equivalent locally — jar uf maestro-cli-2.5.1.jar driver/ios/MaestroDriverLib driver/ios/maestro-driver-iosTests after staging the missing sources, then rm -rf ~/.maestro/maestro-iphoneos-driver-build and re-running. Maestro's auto-rebuild completes through to install.

2. Run the bundled maestro-ios-xctest-runner/build-maestro-ios-runner.sh directly. It accepts DEVELOPMENT_TEAM as a proper env var and writes the same artefacts the CLI would extract — sidesteps the broken auto-rebuild without touching the JAR. Equivalent end-state to (1).

Both paths produce a ~/.maestro/maestro-iphoneos-driver-build/ that lets Maestro install + connect to the runner.

New finding — runtime crash on Xcode 26.3 + iOS 26.4.2 specifically

Same cache restoration that runs end-to-end for @gbossirus on Xcode 26.2 / iOS 26.3.1 / iPhone 17 Pro Max consistently crashes for me on Xcode 26.3 / iOS 26.4.2 / iPhone 15 during screenshotBasedTap:

• Driver installs + connects fine; first orchestrator commands (runFlow, assertVisible for stable testIDs) execute successfully
• The first command that requires the runner to take a screenshot fails with java.net.SocketException: Connection reset from okhttp3.internal.http1.Http1ExchangeCodec.readResponseHeaders against http://127.0.0.1:7001/
• Background xcodebuild test-without-building exits with ** TEST EXECUTE FAILED ** after ~60–90s with a devicectl_diagnostics.zip archive
• xcrun devicectl device info processes shows the runner gone post-crash

USE_XCODE_TEST_RUNNER=1 with the runner pre-launched manually surfaces the same crash — so it's the runner runtime, not Maestro's install path.

Reproducible in three back-to-back attempts after pkill xcodebuild && pkill maestro && xcrun devicectl device install app for both .app bundles. Repro stack:

java.net.SocketException: Connection reset
  at sun.nio.ch.SocketChannelImpl.throwConnectionReset(...)
  at ios.xctest.XCTestIOSDevice.tap(XCTestIOSDevice.kt:46)
  at ios.LocalIOSDevice.tap(LocalIOSDevice.kt:58)
  at maestro.drivers.IOSDriver.tap$lambda$14$lambda$13(IOSDriver.kt:136)
  ...
  at maestro.Maestro.screenshotBasedTap_ogj28Uc$lambda$31$lambda$29(Maestro.kt:367)

Versions in scope:

• @gbossirus: Xcode 26.2 (17C52) / iOS 26.3.1 / iPhone 17 Pro Max → works end-to-end after JAR patch
• This report: Xcode 26.3 (17C529) / iOS 26.4.2 / iPhone 15 → crashes during screenshotBasedTap

Either Xcode 26.3 regressed the runner's XCUITest screenshot path, iOS 26.4.2 changed something XCUITest-side, the iPhone 15 specifically has an interaction the iPhone 17 doesn't, or some combination. Separate layer from the packaging bug — happy to file as a distinct issue once anyone with a 26.3 + 26.4 stack can independently repro.

What this means for the fix priority

The packaging fix (gradle include list) is fully scoped + tested. Shipping it as a 2.5.1.x patch or bundling it into the 2.5.2 release would unblock most physical-iPhone users today. The Xcode 26.3 + iOS 26.4.2 runtime crash is a separate downstream layer that doesn't block the gradle fix from landing.

Happy to provide additional diagnostics (full maestro.log, full xcodebuild stderr, devicectl_diagnostics.zip contents) if useful for the runtime-crash thread.

[Fishbowler]

@gbossirus and @redwards72git - seen the comments above about there not being any real physical iOS device support right now? If you got the driver built, lots of operations would still fail, since most of Maestro relies on simctl.

[LeoGCode]

Another data point + a pointer to the fix.

Still reproduces on the latest toolchain: Maestro 2.6.0, Xcode 26.5 (17F42), macOS 26.4, iPhone 12 Pro / iOS 26.4.2. Same MaestroDriverLib build failure described here — and after removing the dangling INFOPLIST_FILE, the build then fails on the missing framework sources (MaestroDriverLib/Sources/MaestroDriverLib/MaestroDriverLib.swift, AXFrame.swift, ElementType.swift, PermissionValue.swift, Helpers/PermissionButtonFinder.swift) — only Models/AXElement.swift ships, so it's the jar-packaging exclusion @gbossirus pinned, not just the plist.

This is fixed in #3100 (fix: enable iOS real device support via devicectl and iproxy), which adds MaestroDriverLib/** to the jar packaging in build.gradle.kts — plus the two things you hit after the build (which is why physical devices "didn't work anyway"): it implements the stubbed DeviceControlIOSDevice.launch via xcrun devicectl, and auto-starts iproxy to forward the XCTest server port over USB.

Re: the "most operations rely on simctl and would fail" concern above — I can confirm that with #3100's three fixes applied, a full real-device flow works end-to-end: launch app → viewHierarchy → coordinate tap → screenshot, none of which go through simctl (they run over the XCTest HTTP server). Details and a newer-Xcode caveat in #3100 (comment).

So this issue is effectively resolved by #3100 — might be worth linking them.