I have a global strategic problem which resembles a philosophic issue (well, sort of ;-)).

I have an app interacting via REST/JSON with a django webserver. The web [front|back]end is rapidly and gradually evolving, but, in case of severe changes, we introduced an in-app mechanism to manage API breakages (a popup is presented to the user, inviting him/her to install the updated app from the store).

What I never thought about before is how to manage the review process, considering that, if I upgrade the backend just for the purpose of the review process:

  • old applications won't be able to speak the new API language;
  • they will be presented with the upgrade message without being actually able to find it on the store;
  • people will see the upgraded frontend before being able to interact with their own app with it.

The only thing that came to my mind is to let the existing users suffer from this change until the moment in which they will be able to download the new version.

How would you handle this empasse?

1 Answer 1


Just in case any other person should look for a solution to a similar problem: made through Apple's reviewing process through the setup of a /2.0 subdomain for the backend.

Every old user is still pointing to the old url and, whenever the switch is ready, we will make the old uri point to the new backend (so that we will have two simultaneous groups of URIs address the same backend).

All the old applications will still point to the old URI and get the "Invite to upgrade" message. When upgraded, all the applications will point to the /2.0 subdomain.

From a web browser people will still be able to use the old URL and get served by the new backend.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .