4

I have an app that sends logs to Keen IO for logging and analysis purposes. The code that sends logs to Keen IO is guarded by preprocessor macros, and hence it never sends any logs when I’m running it on the simulator or my own phone while development.

What I generally follow is this — After the app is (almost) done, I release an ad-hoc version and give it to some testers who use it for a few days and test it. However, since it is also a “release” version, the app sends analysis data. This data usually pollutes my other data that was supposed to come from my real users!

I want to programmatically know inside the app if it is an ad-hoc release version or AppStore release version, so I can handle those two conditions. Is there a way to do this?

The only way I can think of is have another preprocessor macro AD_HOC that tells that its a test version. But it can happen that I forget to remove the macro while submitting to the AppStore. Its not gonna help if that happens.

Rahul Jiresal
  • 1,006
  • 13
  • 24

1 Answers1

2

I use such a macro for a very similar reason. I build the adhoc version using the release building setting and the app store version using the distribution build setting. In that way I avoid forgetting to set the #define to the right value.

onnoweb
  • 3,038
  • 22
  • 29
  • 1
    How do you add a “distribution” build setting? I can see only two options under preprocessor macros - ‘Debug' and ‘Release' – Rahul Jiresal Jan 20 '14 at 21:19
  • Never mind, found it. http://stackoverflow.com/questions/19842746/adding-a-build-configuration-in-xcode – Rahul Jiresal Jan 20 '14 at 21:29
  • 1
    I have another question — How do you tell Xcode to use “Release” configuration for Ad-hoc and “Distribution” configuration for AppStore release? – Rahul Jiresal Jan 20 '14 at 21:34
  • I use separate targets and schemes. – onnoweb Jan 20 '14 at 21:41
  • If you’re using separate targets, why do you need another build setting? You can use the “release” build setting on the other target to set the #define. – Rahul Jiresal Jan 20 '14 at 21:45
  • Yes, that works too. I ended up using targets because the app is distributed both through the app store and as an in-house enterprise app. – onnoweb Jan 20 '14 at 21:47
  • So, I guess having two targets is the only option? Since, having two build configurations does not work because you cannot tell Xcode which one to use during what operation (debug, ad-hoc and App Store)? – Rahul Jiresal Jan 20 '14 at 21:50
  • I ended up having two schemes and two build configurations. Two targets failed because it change the bundleID. The second scheme pointed to the “AppStore” build configuration for archiving. Thanks a lot. This simplifies a lot for me. :) – Rahul Jiresal Jan 20 '14 at 22:30