Add a command to check whether a device has enabled developer mode. D… #563
Conversation
…eveloper mode was introduced in iOS 16. When checking devices on older versions the command will print an unsupported error. Retry of ios-control#556 that guards the developer mode check by a preprocessor define so that it is not build by default. Developer mode requires a MobileDevice method introduced with Xcode 14 so including it by default will break builds where Xcode 14 is unavailable.
src/ios-deploy/ios-deploy.m
Outdated
| @@ -91,6 +91,9 @@ | |||
| mach_error_t AMDeviceLookupApplications(AMDeviceRef device, CFDictionaryRef options, CFDictionaryRef *result); | |||
| int AMDeviceGetInterfaceType(AMDeviceRef device); | |||
| AMDeviceRef AMDeviceCopyPairedCompanion(AMDeviceRef device); | |||
| #if defined(XCODE_14_OR_NEWER_AVAILABLE) | |||
There was a problem hiding this comment.
What happens if you compile this on Xcode14 and then run it against Xcode12? Wouldn't AMDeviceCopyDeveloperModeStatus not exist?
There was a problem hiding this comment.
It would still work because there is a single MobileDevice.framework that gets updated along with each Xcode release. As long as the user installed Xcode 14 at one point and installed the developer tools, this feature will work.
There was a problem hiding this comment.
What about centrally compiled versions? e.g. I believe Flutter and Cordova compile the ios-deploy binary on their server and then distribute that binary.
There was a problem hiding this comment.
I'm not sure, I don't have a machine that hasn't had Xcode 14 installed but I think that would result in a crash when the program attempts to use the invalid symbol. I don't know of a good way around that so for that reason this feature is disabled by default and requires building with "-DXCODE_14_OR_NEWER_AVAILABLE=1" to enable. Then any tools that invoke ios-deploy would need to perform their own checks that Xcode 14 is available before attempting to use this feature.
There was a problem hiding this comment.
For compiling it would be best to switch to a tbd file, so we don't have to gate on the version of Xcode used to compile, but requiring Xcode14 to compile is also an option.
For run-time checking I'd just put these calls not in the main path. If it fails we should try to tell them they need Xcode14 installed, but it's fine if it fails.
There was a problem hiding this comment.
I'm not sure what "switching to a tbd file" means. ios-deploy won't compile if Xcode 14 has not been installed to the system because the MobileDevice framework that is dynamically linked won't have the symbol defined (the reason why I rolled back the previous commit). A tbd would fail the same way.
For runtime, I guess we could dlopen and dlsym to check if the symbols exists before we attempt to call it but simply noting the requirement in the usage + README.md seems sufficient to me
There was a problem hiding this comment.
From our discussion offline, it seemed we had a misunderstanding over when the define would be defined, and by extension when the feature would be enabled. I've renamed XCODE_14_OR_NEWER_AVAILABLE to IOS_DEPLOY_FEATURE_DEVELOPER_MODE so it is clear that this define must be manually provided in order to enable the developer mode option. This feature is opt-in because it requires Xcode 14 on the machine that builds ios-deploy AND on the machine that runs it.
XCODE_14_OR_NEWER_AVAILABLE sounds like a define guard provided by Apple so I changed it to IOS_DEPLOY_FEATURE_DEVELOPER_MODE to make clear that this define needs to be provided manually.
…eveloper mode was introduced in iOS 16. When checking devices on older versions the command will print an unsupported error.
Retry of #556 that guards the developer mode check by a preprocessor define so that it is not build by default. Developer mode requires a MobileDevice method introduced with Xcode 14 so including it by default will break builds where Xcode 14 is unavailable.