[TIMOB-27338] iOS: Invalid iOS simulator error is shown when doing concurrent builds with iOS 13
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2019-10-24T13:26:08.000+0000 |
Affected Version/s | Release 8.0.3, Release 8.1.0 |
Fix Version/s | Release 8.2.1, Release 8.3.0 |
Components | CLI, iOS |
Labels | n/a |
Reporter | Samir Mohammed |
Assignee | Chris Barber |
Created | 2019-08-15T10:09:00.000+0000 |
Updated | 2019-10-24T19:43:16.000+0000 |
Description
When running concurrent iOS builds on simulators the following error is seen in Studio:
Run the project in APPC studio or through the CLI (e.g.
[ERROR] : Invalid "--device-id" value "8B89634B-0E8B-4286-8839-7CEE6A035700"
The cli also shows this error:
[ERROR] Invalid iOS simulator "8B89634B-0E8B-4286-8839-7CEE6A035700"
*Test Steps*
note: I can only reproduce this when using xcode beta 5 after updating from xcode beta 4. It's reproducible in ti as well as appc so moving to TIMOB
I was able to reproduce with 12.4 sims as well. It looks like if you have Xcode 11 command line tools selected and you try to run a concurrent 12.4 sim you get the above error. If you have command line tools selected for Xcode 10 and you try to run a concurrent 13.0 sim you get that error as well.
From some looking I think this is purely down to the response we're getting from
simctl list --json
not including a booted simulator that is using a runtime from another xcode (so xcode 10 simctl and iOS 13, xcode 11 simctl and iOS 12.4). Seeing as how that is how we source the simulator listing I'm not sure how we can fix this without changing how we source the simulator to run simctl from _every_ xcode available and the collate the results. I tested this and it appears to fix detection, but then cause issues further down the line when we try to boot the sim. [~cbarber] any thoughts on whether doing that is the right thing to do?I added support for Xcode 11 sims in several ioslib releases recently, the last one is 1.7.11 which [isn't](https://github.com/appcelerator/titanium_mobile/blob/master/package.json#L72) currently used on master.
[~hknoechel], i think 1.7.11 was just a fix for the team id stuff right? That shouldn't have an impact on sim detection. I think once xcode 11 is released this will be a non-issue except for the rare circumstance someone is switching between xcode versions during development, although I totally expect it to arise while people are testing xcode 11/iOS 13/SDK 8.2.0
[~eharris] Beta 6 is out. Perhaps it's been fixed?
Still occurs on beta 6
[~eharris] so the theory is that when XCode 11 is released, we shouldn't see this issue? Should I move the fixVersion to 8.2.1 for now as a placeholder, and we'll check again after XCode 11/ iOS 13 release?
[~amukherjee], yes that's the theory. But mainly because when xcode 11 is GA'd people wont be running xcode 10/xcode 11 side by side.
Keeping it in resolved state until the final release of Xcode 11.
The method of detecting the iOS simulators differs between the CLI and Studio. Appc/Titanium CLI uses ioslib@1.x in the SDK. Studio calls the daemon which uses ioslib@2.x. ioslib@1.x will detect the iOS simulators by calling
simctl list --json
. ioslib@2.x will detect the iOS simulators by walking the simulator devices directory. It is entirely possible that an iOS simulator device directory exists yet for some reasonsimctl
doesn't list it. I've seen this happen depending on the selected Xcode version. Furthermore, I discovered bugs in ioslib@1.7 while fixing TIMOB-27360 where simulator availability checks were not being done infindSimulators()
, a function that is only called at the beginning of the build to determine the simulator to launch. My hunch is to completely nuke all of your simulators and recreate them. The easiest way to do this is install ioslib@2 or ioslib@3, then runnode bin/ioslib reset-sims
. Otherwise you can try my old reset-sims script which may work: https://gist.github.com/cb1kenobi/19dc4c547864a96bfa9027aae5631e67.I've fixed a bunch of bugs in ioslib@1.7 and the SDK that seem to fix all simulator related issues. ioslib 1_7_X PR: https://github.com/appcelerator/ioslib/pull/98 Ti SDK master PR: https://github.com/appcelerator/titanium_mobile/pull/11228 To test, build an app for the iOS Simulator, then rerun the build without closing the simulators. Additional testing: * iOS SDK 12.2 (Xcode 10) + iOS Simulator 12.2 (Xcode 10) * iOS SDK 12.2 (Xcode 10) + iOS Simulator 13.0 (Xcode 11) * iOS SDK 12.2 (Xcode 10) + auto selected 12.2 iOS Simulator * iOS SDK 13.0 (Xcode 11) + iOS Simulator 12.2 (Xcode 10) * iOS SDK 13.0 (Xcode 11) + iOS Simulator 13.0 (Xcode 11) * iOS SDK 13.0 (Xcode 10) + auto selected 13.0 iOS Simulator * Same as above but with a watch app (both explicit watch sim UDID and auto selected) Note: selected Xcode shouldn't matter
Ti SDK master PR: https://github.com/appcelerator/titanium_mobile/pull/11228 Ti SDK 8_2_X PR: https://github.com/appcelerator/titanium_mobile/pull/11235
FR Passed. Concurrent builds on iOS simulator work fine. Waiting on Jenkins build to pass.
PR's Merged
Verified on build 8.2.1.v20191009074714. Ticket closed.
Turns out the Ti SDK PR was bugged. Ti SDK master PR: https://github.com/appcelerator/titanium_mobile/pull/11281 Ti SDK 8_2_X PR: https://github.com/appcelerator/titanium_mobile/pull/11282
FR Passed.
Master PR Merged.
merged to 8_2_X
Closing ticket, fix verified in SDK version
8.2.1.v20191023131524
and SDK version8.3.0.v20191023125529
Test and other information can be found at: Ti SDK master PR: https://github.com/appcelerator/titanium_mobile/pull/11281 Ti SDK 8_2_X PR: https://github.com/appcelerator/titanium_mobile/pull/11282Found another ioslib issue surrounding the Xcode version semver lookup that was causing Xcode 10 to short circuit Xcode 11's lookup. ioslib PR: https://github.com/appcelerator/ioslib/pull/105.
Ti SDK master PR: https://github.com/appcelerator/titanium_mobile/pull/11296 Ti SDK 8_2_X PR: https://github.com/appcelerator/titanium_mobile/pull/11297