Error on first run after iOS simulator is updated

[freakboy3742]

The first time you attempt to run an app in the iOS simulator after installing or updating the iOS simulator, the simulator fails to start at the point when it tries to identify the available simulators.

To Reproduce
Steps to reproduce the behavior:

1. On a completely clean macOS install, install Xcode
2. Generate a new Briefcase project
3. run briefcase run iOS
4. Briefcase fails with the error: "Unable to parse output of xcrun simctl":

briefcase.2022_07_06-11_12_50.run.log

The error will also occur when Xcode undergoes a major version update, and the simulator is updated.

Expected behavior

Briefcase should present a list of available simulator images on first run.

Environment:

• Operating System: macOS (any)
• Python version: any
• Software versions:
  • Briefcase: 0.3.8

Additional context

The problem appears to be caused by stray content in the output being parsed. From the log above:

>>> Running Command:                                                                                                                                    subprocess.py:434
>>>     xcrun simctl list -j                                                                                                                            subprocess.py:435
>>> Command Output:                                                                                                                                     subprocess.py:453
>>>     Install Started                                                                                                                                 subprocess.py:455
>>>     1%.........20.........40.........60.........80.........Install Succeeded                                                                        subprocess.py:455
>>>     {                                                                                                                                               subprocess.py:455
>>>       "devicetypes" : [                                                                                                                             subprocess.py:455
>>>         {                                                                                                                                           subprocess.py:455
>>>           "productFamily" : "iPhone",                                                                                                               subprocess.py:455
>>>           "bundlePath" :                                                                                                                            subprocess.py:455
...

Briefcase currently takes the literal output of the command, and attempts to parse it as JSON. The stray content in the first two lines ("Install started, 1%... ") isn't valid JSON, so the parse fails.

When you run a second time, the stray content isn't present; the entire command output is parseable JSON.

[freakboy3742]

@rmartin16 Your logging work has paid off big time - this is the bug I've been trying to track for over a year, and I've finally been able to catch it!

[mhsmith]

Confirmed that this is still an issue with the current version of Xcode.

[mhsmith]

@freakboy3742: I've renamed the tag "first-timers-only" to "good-first-issue" to avoid potentially losing contributions from second-time contributors.

Also, what's the purpose of "up-for-grabs"? It's currently on 67 out of 80 open issues, so it isn't conveying much information. It might be better to mark those issues which are not up for grabs by assigning them to someone.

[freakboy3742]

@mhsmith No disagreement that "first-timers-only" isn't a great name, and that our tags could definitely do with some rationalisation. However, it's not just a matter of changing the name in the Github GUI; at the very least:

• The labels definition in .github needs to be updated
• Documentation references (e.g., this one on the first time contributors's guide need to be updated
• For consistency, the same tag needs to be updated on other repos.

I've reverted this name change for now so we can have a more complete conversation about our desired end state for issue tagging across the project.

[ashleyplusplus]

checking this out at pycon `24

[freakboy3742]

The approach taken in PR #1828 has a reasonable starting point for a fix for this issue.