Opening Simulator app fails often with error The executable is missing

[fluiddot]

Description

I experienced often failures on different workflows that open and use the Simulator app for running mobile end-to-end tests, so far the failure ratio is 70-50%.

The command used for opening the Simulator app is:

open -Fn /Applications/Xcode_13.0.app/Contents/Developer/Applications/Simulator.app

And the error message:

The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10827 "kLSNoExecutableErr: The executable is missing" UserInfo={_LSLine=3844, _LSFunction=_LSOpenStuffCallLocal}

In the beginning, I wasn't sure if this issue might be produced by other steps in the workflow, so for this reason, I created an empty repository with a basic workflow to confirm that the issue could be reproduced by only opening the Simulator app. In the following PR you can check the workflow fluiddot/test-virtual-environment-macos-11#1 and the failure.

As a side note, I'd like to highlight that I only encountered this error when using the macOS 11 image, on previous macOS images opening the Simulator app work without issues.

Virtual environments affected

• Ubuntu 18.04
• Ubuntu 20.04
• macOS 10.15
• macOS 11
• Windows Server 2016
• Windows Server 2019
• Windows Server 2022

Image version and build link

• Image version: 20211114.1
• Build link: https://github.com/fluiddot/test-virtual-environment-macos-11/runs/4267476811

Is it regression?

Not sure.

Expected behavior

Opening the Simulator app shouldn't produce errors.

Actual behavior

Around 50-70% of runs that open the Simulator app produce an error and makes the workflow fail.

Repro steps

1. Create a workflow with the following code.

name: Test Simulator app

on:
    pull_request:

jobs:
    test:
        runs-on: macos-11
        strategy:
            matrix:
                xcode: ['13.0']

        steps:
            - name: Open Simulator app
              run: open -Fn /Applications/Xcode_${{ matrix.xcode }}.app/Contents/Developer/Applications/Simulator.app

2. Trigger several runs until producing a failure (usually it happens around the 2nd-5th run).
3. Observe the The executable is missing error related to the step that opens the Simulator app.

[dibir-magomedsaygitov]

Hello @fluiddot. Thank you for your report. We will take a look.

[fluiddot]

Hello @fluiddot. Thank you for your report. We will take a look.

Thank you @dibir-magomedsaygitov for the heads up 🙇 .

As a side note, I'd like to note that I also tried with the following Xcode versions and also experienced this issue:

• 12.5.1
• 13.1

[dsame]

The problem seems to relate to renaming Xcode installations to the version specific folders.

The possible workarounds are:

1. retry

        steps:
            - name: Open Simulator app
              run: |
                while ! open -Fn /Applications/Xcode_${{ matrix.xcode }}.app/Contents/Developer/Applications/Simulator.app; do
                  echo "Retry"
                done
                echo "Success"

2. force update Launch Database

        steps:
            - name: Open Simulator app
              run: |
                /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f /Applications/Xcode_${{ matrix.xcode }}.app/Contents/Developer/Applications/Simulator.app
                open -Fn /Applications/Xcode_${{ matrix.xcode }}.app/Contents/Developer/Applications/Simulator.app

Reference documentation: https://eclecticlight.co/2017/08/11/launch-services-database-problems-correcting-and-rebuilding/

@fluiddot if you want to use Simulator.app for testing purposes there's more common approach with xcrun simctl.

[fluiddot]

@fluiddot if you want to use Simulator.app for testing purposes there's more common approach with xcrun simctl.

Good point, actually I initially considered this option but the open -Fn /Applications/Xcode_${{ matrix.xcode }}.app/Contents/Developer/Applications/Simulator.app command is being executed by the testing tools (Appium specifically) used in the mobile end-to-end tests, not in the workflow, so I wanted to avoid introducing potential tweaks there.

I'm going to try option 2 in the original workflows where I identified the issue. Thank you very much @dsame for taking a look and providing such helpful workarounds 🙇 .

[fluiddot]

@dsame using option 2 worked like charm in the workflows, thank you so much for investigating and providing the workarounds 🙇 .

[miketimofeev]

@fluiddot we are thinking of implementing lsregister call during the image generation so the workaround won't be needed. We will let you know once it's done.

[fluiddot]

@fluiddot we are thinking of implementing lsregister call during the image generation so the workaround won't be needed. We will let you know once it's done.

@miketimofeev awesome, thank you for letting me know 🙇 , I'll be looking forward to the workaround 👍 .

[DavidKnight-Bluescape]

Just a note that we are launching with xcrun simctl and hitting the same issue intermittently. Thanks for the workaround - we'll give #2 a shot until there is a fix.

[shilovmaksim]

Hi @fluiddot, @DavidKnight-Bluescape .
Approach with lsregister call during the image generation merged into main. The update will be available after next week's deployment.

[shilovmaksim]

Hi @fluiddot. Images with lsregister call during the image generation were deployed last week. The change should be available already.

[fluiddot]

Hi @fluiddot. Images with lsregister call during the image generation were deployed last week. The change should be available already.

@shilovmaksim Thank you very much for letting me know about the update.

[DavidKnight-Bluescape]

Thank you!