Check if app is ad-hoc|dev|app-store build at run time

Question 1

While I would agree with Abhi Beckert that runtime is the wrong time to be doing this (use preprocessor directives and build settings!), I wanted to clarify some of the details and speculations in the previous answer/comments and shine some light on things you could do. Bear with me, this is going to be a longer answer...

There are a bunch of pieces of data that could go under the generic umbrella of 'Build Information'. A non-exhaustive list of such things would include: Build Configuration, Code Signing Identity, Build Time, Build Date, Marketing Version Number, SCM Revision Number, SCM Branch Name, Provisioning Profile Team Identity, Provisioning Profile Expiration, CI Build Number...the list goes on and on.

Assuming for the moment your question was narrowly focused on gaining information as to the type of iOS certificate and Provisioning Profile used for the build, then I will have to go with a very firm 'No' as the answer to the question: Is there a way to check [build information using an existing API method] at runtime? As a brief aside: Collectively these two data points are called the "Code Signing Identity" in Xcode 4.6.x Build Settings or "CODE_SIGN_IDENTITY" for you command-line build setting enthusiasts.

As of the time this question was asked, there is no singular public iOS API that you can call to get information about the code signature type for the currently running app. The likely reasons behind this are numerous, but here are a few examples:

Developers are permitted to construct their own build schemes and build configurations. This means that we can have one scheme and one build configuration, or one scheme and dozens of build configurations, or even thousands of each. Naturally each scheme can be assigned a different build configuration, and those configurations can each be assigned a different code signing identity. As you might guess, it doesn't take much customization by a developer or team for this to quickly get chaotic.
Code signing identities only require that a non-expired Provisioning Profile issued for the current app identifier, contains a copy of the public key for the certificate used to sign the binary. For those working on a team, you might have a single Provisioning Profile containing all the certificates of the developers on the team, or you might make individual Provisioning Profiles for each developer on the team containing only their certificates. This is yet another point of variation in how developers can elect to build their app.
Developers may share a single certificate (tsk tsk) or be issued their own certificates...yep, you guessed it, even more variation.

This hypothetical one-stop API would then need to have access at runtime to all of your build configuration data, certificates, and provisioning profiles to be able to untwist the 'effective' settings applied at compile time and reduce all of that data down to a finite string...simply for a developer diagnostics view...not an impossible feat by any stretch of the imagination, but such a potentially computationally intense operation for negligible developer benefit would definitely rank low on just about anybody's priority list. It would get kicked even further down the priority list given that other options (like compile-time flags!) are more reliable, cheaper to setup, and simpler to maintain in the long run.

Now, as to the semi-lurking question of "Could I do it at runtime?" I would emphatically say 'Yes you can.'

As you know, device builds are the only kinds of builds that require code signing. Part of the process creates a file in the main bundle called 'embedded.mobileprovision'. This is a file owned by your app's sandbox and thus is something you absolutely have the ability to open programmatically:

[[NSBundle mainBundle] pathForResource:@"embedded.mobileprovision" ofType:nil]

.mobileprovision files are PCKS#7 encoded and contain both binary and text data. The info you seek is that of the text-based plist embedded within the PCKS#7 data. First, using OS X let's take a look at this text data out of one of your device builds:

Right click on your build for device .app bundle and select 'Show Package Contents'
Copy the embedded.mobileprovision file someplace easily accessible.
Open that file with your preferred text editor.

You notice right away that there's a lot of binary data but you can make out parts of the text data. Scrolling to the right, you'll see plist-styled xml, only it isn't so easy to read in this view. We can use an OS X command line tool to look at this data in a more organized manner:

Open Terminal and 'cd' to the folder containing your copy of the embedded.mobileprovision.
Run: security cms -D -i embedded.mobileprovision

This will display the plist xml to the terminal window for your perusal in a nicely tabbed format. If you repeat this process for an Ad-Hoc build, Dev build, and an App Store build you'll start to notice the keys in this text that are indicative of the respective types of builds. For builds signed with an 'iPhone Developer: ...' certificate (or 'Dev' builds as you listed in the original post), look for:

<key>get-task-allow</key>
<true/>

The 'get-task-allow' key is what is used to instruct iOS if the app will allow a debugger to attach to it. In the case of an 'iPhone Developer' signed binary this makes sense - You would typically need to be able to debug on the device when pushing code from Xcode to your device for testing purposes.

The difference between 'Ad-Hoc' and 'App Store' require some additional checks. This same 'get-task-allow' key will be set to false for both of these kinds of distributions:

<key>get-task-allow</key>
<false/>

However, 'Ad-Hoc' builds have a defined set of 'ProvisionedDevices'not present in 'App Store' builds:

<key>ProvisionedDevices</key>
<array>
    <string>abcdef01234567890abcdef01234567890abacde</string>
    <string>1abcdef01234567890abcdef01234567890abacd</string>
    <string>2abcdef01234567890abcdef01234567890abacd</string>
</array>

So what does this mean in practical terms for the runtime checking question? Yes you can do it, by opening up the embedded.mobileprovision file out of the main bundle, and parsing data out of it to make an informed decision, but that is something you'd be entirely responsible for implementing yourself. You'll need to add logic to handle cases where that file is missing (ex. Simulator builds) and to either parse the PCKS#7 data or reliably extract the ASCII content of the file upon which your code can run a series of string searches. As is likely evident, this will require non-trivial effort for a somewhat brittle solution that can otherwise be easily accommodated by build settings and pre-processor macros at as Abhi Beckert outlined in the previous answer.

What about the risk of App Store rejection? Is this 'illegal' or 'subversive'?

Presuming that you use all public API when reading and parsing the contents of the embedded.mobileprovision file, this is perfectly allowable by the current terms of the App Store. Anything in your app's sandbox is fair game including embedded.mobileprovision if it happens to be present. I still strongly caution against going down this road, echoing Abhi Beckert's comments. It is a considerable amount of effort for less than 1% of use cases and there are far easier solutions out there! Furthermore, developer diagnostic views shouldn't be in App Store release builds, however the decision to include extraneous code is entirely in your hands.

I hope this clears up any lingering questions, but if not, please toss in a comment and we can see what we can do.

Question 2

This is probably what you're looking for. Abhi has a good, thorough explanation and this gist has the actual code:

https://github.com/blindsightcorp/BSMobileProvision

Question 3

Runtime is the wrong time to do this.

Your app may get rejected from the store if you try doing it. Or it might be approved, and then you do an urgent bugfix release and that one might get rejected.

As @rmaddy suggested in a comment, you should do it at compile time.

Edit your project settings to define this constant: CONFIGURATION_$(CONFIGURATION), then do this in your code:

#if defined (CONFIGURATION_Debug) || defined (CONFIGURATION_Adhoc)
  NSLog( @"Warning message");
#endif

Source/more details: http://ios-dev.gravitini.com/2009/02/identifying-current-xcode-configuration.html

You can wrap a runtime function around it if you want. Perhaps:

void debugLog(NSString *str)
{
    #if defined (CONFIGURATION_Debug)
      NSLog(@"%@", str);
    #endif
}