Skip to content

fix(ios): apply launch permissions on simulators - #169

Open
s4lmon wants to merge 1 commit into
devicelab-dev:mainfrom
s4lmon:fix/ios-launch-permissions
Open

s4lmon wants to merge 1 commit into
devicelab-dev:mainfrom
s4lmon:fix/ios-launch-permissions

Conversation

@s4lmon

@s4lmon s4lmon commented Sep 12, 2026

Copy link
Copy Markdown
Contributor

Apply launchApp permissions after clearing simulator app state, with all: allow by default and specific overrides honoured (related: #147).

Validated with regression tests, the driver race suite and iOS picker/negative checks; full checks remain blocked by existing lint/cancellation failures and a browser startup timeout.

@omnarayan

Copy link
Copy Markdown
Contributor

Thanks @s4lmon, this is the right direction. The native iOS driver is the only one
that never touches permissions on launch today, so the same flow shows a system
dialog here and none on WDA or Android. Closing that gap is worth doing, and the
ordering fix in handleSetPermissions (apply all before the specific overrides)
catches a latent bug in the existing code that map iteration could trigger at random.

Two things before I merge, both about matching what the WDA driver already does in
pkg/driver/wda/commands.go (launchApp, around line 929), since that path has been
running on simulators for a long time and users expect the two drivers to behave alike:

  1. Do not abort the launch on a simctl privacy failure. WDA ignores errors from
    applyIOSPermission and carries on. With this PR one unsupported service name, or
    a simctl quirk on a particular Xcode, stops every flow at its first step. Log a
    warning with the simctl output and continue with the launch.

  2. Reset before granting. WDA resets every known service first, then applies the
    requested values. This PR only grants, so on a launchApp without clearState a
    permission the flow does not mention keeps whatever state the previous run left it
    in, and a deny from an earlier flow leaks into the next one.

One smaller point: WDA expands all into its explicit list of seven services rather
than passing all to simctl. I do not know of a case where grant all behaves
differently, but if you have a simulator handy, a quick run of a flow with
clearState: true and no permissions: on the native driver, checking that no
dialog appears, would settle it. I will do the same on my side before release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants