iOS toolchain broken with libimobiledevice 1.2.0 + Xcode 8

[yjbanov]

Steps to Reproduce

Upgrade to Xcode 8. Observe this issue: libimobiledevice/libimobiledevice#356.

Workaround is available in comment libimobiledevice/libimobiledevice#356 (comment) and I verified that it works.

/cc @chinmaygarde @tvolkert @cbracken

[dragostis]

This might get fixed in the next beta of Xcode?

[yjbanov]

I tried it on Xcode 8 final

[cbracken]

Running with with Xcode 8.0, latest ios-deploy (1.9.0), libimobiledevice (1.2.0) from brew, Xcode command-line tools installed via sudo xcode-select --install against an iPhone 6S+ on iOS 10 worked for me.

If you can repro and dump version info for each of those, that'd help track this down.

[cbracken]

TL;DR + workaround

An updated release of libimobiledevice on brew gets us rolling again. In the meantime a quick workaround is to install from head with homebrew:

brew uninstall libimobiledevice
brew install --HEAD libimobiledevice

Let's catch up with/send PRs to the libimobiledevice authors/brew maintainer to see if we can get a new release rolled out.

Details

What works: I'm able to build, install and run with the above setup on both the simulator and a real device.

What's broken: so far, just that listing physical device name (e.g. in flutter doctor) fails. There may be other issues.

The issue occurs in _getDeviceName() in lib/src/ios/devices.dart. That method invokes ideviceinfo which fails with ERROR: Could not connect to lockdownd, error code -17.

Running dtruss to trace syscalls suggests that this is the same issue as reported in the thread you cite: we're failing due to permissions on /var/db/lockdown/bunch_of_hex.plist. /var/db/lockdown is permissioned 700 with user, group _usbmuxd.

As I say, the fixes are already landed upstream, looks like it's just a matter of getting a release rolled out on homebrew.

[cbracken]

Separate from the libimobiledevice issue is the fact that Xcode now wants a team specified in the project in order to build and deploy to a physical device (as usual, no issue running on the simulator). Manually setting this in the Xcode project resolves the issue but we should see if there's an automated solution here.

[eseidelGoogle]

Is there something we can do in flutter doctor to detect this and help users? FYI @danrubel

[cbracken]

In terms of flutter doctor checks, as of this afternoon, we're down to just one remaining issue for Xcode 8, which is libimobiledevice version.

Until a new version is released upstream we need users to install from head. Unfortunately the libimobiledevice tools don't include a --version option, which would be the simplest way to check compatibility.

We could potentially check if the user installed it via homebrew and check that the version there is > 1.2.0 or 1.2.0 at head. brew info libimobiledevice has the info. This doesn't help for those using MacPorts or hand-built versions, but it might catch a significant portion.

[cbracken]

A quick check for flutter doctor could be to run idevicename and check for exit code 0. This exits non-zero for the same reasons as other libidevice tools at older versions.

Will add this check.