Is there a way to determine programmatically if the currently running app was built and signed for development only or whether it was built for distribution? And can one determine if was build for app store or ad hoc distribution?
Is it e.g. possibly to access the code signature and get the information from there? Or are there certain files present in one of variants that don't exist in the other ones? Is part of the bundle info? Or can it be derived from the executable file?
Any hints are appreciated.
It seems that the embedded.mobileprovision file is in ASN.1 format.
Release your app on TestFlight Navigate to the TestFlight tab of your app's application details page on App Store Connect. Select Internal Testing in the sidebar. Select the build to publish to testers, then click Save. Add the email addresses of any internal testers.
From My Apps, select the app you want to distribute privately. This will show you the app's page on App Store Connect. In the sidebar to the left, click on Pricing and Availability. Navigate to App Distribution Methods and select Private — Available as a custom app on Apple Business Manager or Apple School Manager.
The easiest way to check is to look at embedded.mobileprovision
([[NSBundle mainBundle] pathForResource:@"embedded.mobileprovision" ofType:nil]
):
openssl asn1parse -inform der
), but a bad hack is to just look for <plist
and </plist>
.<key>get-task-allow</key><true/>
The other thing you can check is the entitlements embedded in the executable (otool -l
lists it as LC_CODE_SIGNATURE
). Parsing this is even more tedious (you need to parse the Mach-O header and load commands, and for "universal" binaries which are now the default, you'll need to check the currently-loaded architecture or all architectures).
<key>get-task-allow</key><true/>
<key>get-task-allow</key><false/>
I don't think the entitlements distinguish between Ad Hoc and App Store builds.
Apart from those and the certificate it's signed with, there's no difference between Development/Ad Hoc/App Store apps (there are a few other things in the entitlements/provisioning profile, but nothing more reliable that I can think of).
Neither of these are that difficult to circumvent. For the first method, the app could just "swizzle" -[NSBundle pathForResource:ofType:]
. The second method is a bit more difficult depending on what API you use to read the file.
openssl asn1parse -inform DEM -in *Mobile_Provision_File* -strparse 54
is the easiest way to access the data that I've found.
EDIT:
security cms -D -i *Mobile_Provision_File*
is actually easier. The openssl command leaves some garbage in the output.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With