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

i'd check build information in debugging screen. there way check @ runtime?

i realize set compiler flags builds or similar, if there existing method leverage i'd take advantage of that.

while agree abhi beckert runtime wrong time doing (use preprocessor directives , build settings!), wanted clarify of details , speculations in previous answer/comments , shine light on things could do. bear me, going longer answer...

there bunch of pieces of data go under generic umbrella of 'build information'. non-exhaustive list of such things 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 , on.

assuming moment question narrowly focused on gaining information type of ios certificate , provisioning profile used build, have go firm 'no' answer question: is there way check [build information using existing api method] @ runtime? brief aside: collectively these 2 data points called "code signing identity" in xcode 4.6.x build settings or "code_sign_identity" command-line build setting enthusiasts.

as of time question asked, there no singular public ios api can call information code signature type running app. reasons behind numerous, here few examples:

1. developers permitted construct own build schemes , build configurations. means can have 1 scheme , 1 build configuration, or 1 scheme , dozens of build configurations, or thousands of each. naturally each scheme can assigned different build configuration, , configurations can each assigned different code signing identity. might guess, doesn't take customization developer or team chaotic.
2. code signing identities require non-expired provisioning profile issued current app identifier, contains copy of public key certificate used sign binary. working on team, might have single provisioning profile containing certificates of developers on team, or might make individual provisioning profiles each developer on team containing certificates. yet point of variation in how developers can elect build app.
3. developers may share single certificate (tsk tsk) or issued own certificates...yep, guessed it, more variation.

this hypothetical one-stop api need have access @ runtime of build configuration data, certificates, , provisioning profiles able untwist 'effective' settings applied @ compile time , reduce of data down finite string...simply developer diagnostics view...not impossible feat stretch of imagination, such potentially computationally intense operation negligible developer benefit rank low on anybody's priority list. kicked further down priority list given other options (like compile-time flags!) more reliable, cheaper setup, , simpler maintain in long run.

now, semi-lurking question of "could @ runtime?" emphatically 'yes can.'

as know, device builds kinds of builds require code signing. part of process creates file in main bundle called 'embedded.mobileprovision'. file owned app's sandbox , absolutely have ability open programmatically:

[[nsbundle mainbundle] pathforresource:@"embedded.mobileprovision" oftype:nil] 

.mobileprovision files pcks#7 encoded , contain both binary , text data. info seek of text-based plist embedded within pcks#7 data. first, using os x let's take @ text data out of 1 of device builds:

1. right click on build device .app bundle , select 'show package contents'
2. copy embedded.mobileprovision file someplace accessible.
3. open file preferred text editor.

you notice right away there's lot of binary data can make out parts of text data. scrolling right, you'll see plist-styled xml, isn't easy read in view. can use os x command line tool @ data in more organized manner:

1. open terminal , 'cd' folder containing copy of embedded.mobileprovision.
2. run: security cms -d -i embedded.mobileprovision

this display plist xml terminal window perusal in nicely tabbed format. if repeat process ad-hoc build, dev build, , app store build you'll start notice keys in text indicative of respective types of builds. builds signed 'iphone developer: ...' certificate (or 'dev' builds listed in original post), for:

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

the 'get-task-allow' key used instruct ios if app allow debugger attach it. in case of 'iphone developer' signed binary makes sense - typically need able debug on device when pushing code xcode device testing purposes.

the difference between 'ad-hoc' , 'app store' require additional checks. same 'get-task-allow' key set false both of these kinds of distributions:

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

however, 'ad-hoc' builds have 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 mean in practical terms runtime checking question? yes can it, opening embedded.mobileprovision file out of main bundle, , parsing data out of make informed decision, you'd entirely responsible implementing yourself. you'll need add logic handle cases file missing (ex. simulator builds) , either parse pcks#7 data or reliably extract ascii content of file upon code can run series of string searches. evident, require non-trivial effort brittle solution can otherwise accommodated build settings , pre-processor macros @ abhi beckert outlined in previous answer.

what risk of app store rejection? 'illegal' or 'subversive'?

presuming use public api when reading , parsing contents of embedded.mobileprovision file, allowable current terms of app store. in app's sandbox fair game including embedded.mobileprovision if happens present. still caution against going down road, echoing abhi beckert's comments. considerable amount of effort less 1% of use cases , there far easier solutions out there! furthermore, developer diagnostic views shouldn't in app store release builds, decision include extraneous code entirely in hands.

i hope clears lingering questions, if not, please toss in comment , can see can do.