[scan] fix: Properly select device if Xcode destination is provided - #29814

Could you help me understand this avenue vs the device and devices parameters scan offers? The comment on destination states - "Only use if you're a pro" so a bit funny that it doesn't tell me exactly why someone would do this.

So to see destination have to rip off a device from that parameter from that seems like some extra features. Is there something I'm missing why its not part of the device parameter?

Apologies if these are dumb questions - honestly not used scan yet.

Could you help me understand this avenue vs the device and devices parameters scan offers? The comment on destination states - "Only use if you're a pro" so a bit funny that it doesn't tell me exactly why someone would do this.

So to see destination have to rip off a device from that parameter from that seems like some extra features. Is there something I'm missing why its not part of the device parameter?

Apologies if these are dumb questions - honestly not used scan yet.

No problem @iBotPeaches, I'm happy to provide more details, and thanks for taking a look into the PR.

If you check the above CI log you could see that in the affected PR I was providing only the destination parameter to the lane hoping that it already has all the necessary device and OS info. Also, even the original fastlane sources contain the below comment:

    # No need to show below warnings message(s) for xcode13+, because
    # Apple recommended to have destination in all xcodebuild commands
    # otherwise, Apple will generate warnings in console logs
    # see: https://github.com/fastlane/fastlane/issues/19579

So, seeing that fastlane selects absolutely different simulator device and OS version was completely unexpected to me. In such case the mismatch was a major problem since it's important to select a correct device and platform to run integrations tests on. Now I have updated my code to use device explicitly to workaround the issue, although I still think it is a bug, and that it makes sense to fix it for other people.

If there are any major concerns about merging the PR itself then we could at least update the documentation to explain that fastlane deliberately ignores parameters provided in destination while scanning for devices.