Appstore Review For Breaking Change

I'm working on a platform that includes 2 native iOS apps, and Android App, and a Web App.


I am getting the finishing touches on a LARGE internal change. (Database tables, API routes, etc)


I have been testing on a public facing beta server and I am happy with the performance. I have not pushed the server code to production.


I am ready to submit for app review, but here's the snag: If I push the web code prior to the review, all of the apps currently in the wild will begin to break. On the otherhand, if I submit the apps for review, they won't work because they'll be pointing at production before it is ready....so I will likely fail review because of how deep these changes were.


So with this catch 22, what is the correct way to get breaking changes through the Appstore Review?

Replies

This same topic was discussed about three months ago on this forum. One issue that will arise is, once approved, how do you handle users who have not yet updated their app at the same time you handle those who have?


One approach is to build two separate databases, one for the old and one for the new. Problem solved. But that may not be possible.


Alternatively - The updated app needs to check some website and determine if it is still in review or if it has been approved. If it is in review it accesses one database using suitable methods. If it has been approved it accesses a different database using different methods. Once approved, make changes to the database and trigger that website to redirect the app. But consider how the old app will respond to the changes to the database. A better way of doing this is to use that website redirect to make as few changes as possible - and be sure to tell App Review what you are doing and why.


And again.... once approved, how do you handle users who have not yet updated their app at the same time you handle those who have?

Post not yet marked as solved Up vote reply of PBK Down vote reply of PBK