Support for ios17

[kali]

Ping @simlay here... I'd like to get your opinion on this. It can be improved a bit (not starting the tunnel and devserver at each run maybe), but it feels super fragile to me at this stage.

Also, from the look of it, you're in a position to test on some variety of devices (I just could just try my iphone12/ios17). And I don't know if the new tunnel workflow will work with older devices or if it is a brand new thing. If it only works with ios17, we need to preserve the old workflow and use the detected ios version to enable the right one.

What do you think ?

[simlay]

Nicely done. After updating my version of pymobiledevice3, this worked well for iOS 17 on my iPhone 15. xcrun devicectl (such as list devices) doesn't work with anything less than iOS 17 which makes this more annoying. That's why I added the version to the IosDevice struct and kept using ios-deploy -c to detect devices. The UUID from ios-deploy works with xcrun devicectl (unclear about pymobiledevice3).

Couple notes:

• Before the sudo password is prompted, maybe say why and what commands will be ran.
• When the app is running and I ctrl-c, it looks like the lldb command remains running even if the app on the device is closed. I just see it in ps: 96252 ttys003 0:05.09 /Applications/Xcode.app/Contents/Developer/usr/bin/lldb -s /var/folders/dq/kjbf14qn4zx3qw_3gtpvmjr40000gn/T/dinghy-lldb.Mtjyy0elxkDg/run.lldb Not sure if there's a great way to deal with that. Just something to keep in mind.

[kali]

Thanks for checking.

• Ok, I will re-instantiate the ios-deploy stuff beside the new workflow.
• Agreed on the sudo prompt message.
• I'm not happy with all the processes I have to spawn and do not really join correctly in case of errors. And I suspect leaving them in the background participates to at least one of the failure mode after a dozen of runs or so. I'll try to make it better.

[kali]

@simlay I improved the workflow, including its ergonomics quite a bit with specific attention to the "locked device" failure mode. This will reduce the need for ctrl-c and help with the lost lldb processes.

I tried to put the ios-deploy stuff back in place... it looks so simple compared to the new workflow, such a pain. Again, I'm not in a position to test it. Given you're already familiar with the code, it would help a lot if you can try it and patch whatever I broke so we can release this promptly.

[kali]

Thanks for reviewing despite the annoying formatting fixes.

How much do we want untethered ? We could maybe have it working partially with devicectl, but without capture of course. It may come "free" with a bump of pymobiledevice3 later. We — sonos — don't care that much about untethered. Do you ?

[simlay]

How much do we want untethered ? We could maybe have it working partially with devicectl, but without capture of course. It may come "free" with a bump of pymobiledevice3 later. We — sonos — don't care that much about untethered. Do you ?

Yeah... I notice that untethered stuff is less reliable using just the xcrun devicectl tooling. Thanks for the work!

[kali]

ok. I'm gonna merge this as is then. I think the best way to get wifi would actually be to contribute to pymobiledevice, assuming it can be made to work. I am very reluctant to introduce workflows where we can not get stdout and the return value as running test and bench is historically the core feature of dinghy...