2

I have an interesting issue with submitting an update for my iOS app. I have 2 API versions: production and staging. The TestFlight builds use the staging server, and the App Store builds use production via this check:

if ([[NSBundle mainBundle] pathForResource:@"embedded" ofType:@"mobileprovision"]) {
    // TestFlight, use staging API
} else {
    // App Store, use production API
}

This works great. We get to test the next version of the app with the next version of the API, while keeping the released version working with the production API.

The problem is that when we submit the app to Apple for review, their reviewers now have the new code that needs the new API, but the above check points them to the production API. This caused a crash and thus we got rejected.

I know that we should do proper API versioning so we could have the old and new API running in production at the same time, but sadly we're not at that stage yet. We mistakenly figured that the Apple reviewers would take the first code path (using the staging server), and we would manually release the app after it got approved and time that with deploying the new API to production and thus everything would work out just fine.

So, finally the question. Is there any way in code to detect if the app is run by Apple's reviewers, have it use the staging server? Or are we screwed and need to get the new API into production (and thus breaking the app that's currently in the App Store)?

Kevin Renskers
  • 5,156
  • 4
  • 47
  • 95
  • 1
    Not an answer to your question but... You seem to be saying that you can't have the old and new APIs running at the same time on your production server. When you release the new app and switch in the new APIs won't this break your app for everyone that hasn't upgraded? If this is what you are planning then it sounds like really bad user experience. Perhaps I'm missing something. – mttrb Dec 20 '14 at 11:56
  • You are correct. However, at that time there *is* an upgrade path for our users, and we really don't have a lot of users yet so it was a calculated bad experience (that we will warn them about). Something that we can get away with while we're still small and until we have proper API versioning. – Kevin Renskers Dec 20 '14 at 12:15
  • You did this all wrong. You need your new app to request a new production API so it can coexist with the old production API. This way you don't mess with users that don't upgrade after the new version of the app comes out. Also, you can point the new production URL to your test server while the app is in review. Once you get the email that the app is processing for the app store, you can quickly switch the new production URL to the production server. This way the reviewers hit the test servers using the production URL and new/upgraded users hit the production server. – rmaddy Dec 20 '14 at 15:51
  • I know. Like I said in my question: "I know that we should do proper API versioning so we could have the old and new API running in production at the same time, but sadly we're not at that stage yet." – Kevin Renskers Dec 20 '14 at 16:12

1 Answers1

3

I don't believe that you will find a reliable way of detecting the reviewer activity.

Is it possible to add a new "API" on your server specifically for your new app where it can post its version and get an answer back as to whether it is released or not (and therefore which server it should talk to subsequently)?

Once the app is approved then you can change the answer from this new API. You could even store a "production" answer in NSUserDefaults so that the app no longer checks each time once it "knows" it is in production - presumably you would never revert to staging.

Paulw11
  • 108,386
  • 14
  • 159
  • 186
  • I think that could indeed be a pretty good solution until we have proper API versioning. I'll run it by the API guys and see what they think. Thanks! – Kevin Renskers Dec 20 '14 at 12:17