App rejected because of code inside #if DEBUG conditions

My app was rejected twice. The first time I left code calling into private APIs (namely LSApplicationWorkspace) in a production build, so this rejection seems legitimate. However, the second time the app was rejected, all uses of private APIs were inside #if DEBUG conditions.

I believe code inside #if DEBUGs does not make it into the build, given that the DEBUG flag isn’t specified for the configuration.

Taking into consideration the fact it took nearly three weeks—during which my app was “in review,” without any updates or requests from the reviewers—and two inquiries into the status (including an expedited review request) to have the new build reviewed, I’m not even sure it was actually reviewed—the experience was so frustrating I wouldn’t be surprised if the build got rejected “just because.”

So, I’ve got a few questions:

  • Am I correct in that #if DEBUGged code cannot end up in a production build (i.e. a build whose configuration doesn’t include the DEBUG flag)?
  • Is it possible the App Store review team had access to more symbols than actually exist in the build?
  • How could my app get rejected because of code that’s not in the build?
  • Is it worth spending time on engaging in a conversation with the review team to figure out what’s going on?
Up vote post of XMaster Down vote post of XMaster
721 views
Posted by
XMaster
Reply
Add a Comment

Replies

Do you test your production build configuration?

(If you don't test your production build configuration - why don't you test your production build configuration ???!!!)

Anyway, put something inside the #if DEBUG that will cause it to not compile (example: !"£$%^&*), and try to build for production.

Is it worth spending time on engaging in a conversation with the review team to figure out what’s going on?

It's probably more productive to talk to Developer Technical Support.

Edited to add: I've just googled what LSApplicationWorkspace might be used for, and I think you need to be very cautious going forward. It seems that it can perhaps be used to enumerate all the apps on the device! That's a nasty bit of user privacy violation, and has no doubt raised a "red flag" against you and the app. Why on earth was it there in the first place?

Posted by
endecotp
Post not yet marked as solved Up vote reply of endecotp Down vote reply of endecotp

  • Sure, I tested the production config, and the conditional compilation with #if DEBUG behaved just as expected. Nevertheless, analyzing the archived app with strings did produce LSApplicationWorkspace among other strings.

    I suspect this may have to do with Strip Debug Symbols During Copy (COPY_PHASE_STRIP) and/or Generate Debug Symbols (GCC_GENERATE_DEBUGGING_SYMBOLS) build settings which default to NO and YES, respectively, for all configurations. Haven’t tested it yet, though.

    —
    XMaster

  • You’re right in that LSApplicationWorkspace is a pretty powerful class. Among other things, it can launch apps by bundle IDs, which I initially wanted to use for opening Settings’s main screen (the UIApplication.openSettingsURLString constant points to an app’s settings, which wan’t quite suitable for my goal).

    —
    XMaster
Add a Comment