0

my company is very new to IOS app development, but we are now in the process of releasing a first app (developed through Xamarin).

This app connects to our API for the totality of the features (we develop an ERP web application to be used by companies and the app can be installed on the company's employee personal iphones).

Our backend application, apart from our own servers fro SAAS distribution, is also installed on premise on several customers and this means that we must coordinate our backend API update process with our IOS app release.

When we developed our android app we released the app updates through an FTP (Play Store was only used to install the app the first time) so the coordination process was fairly simple:

  • at startup time the app asks the api what is the current api version
  • then it connects to an FTP to check what is the latest app update compatible with that api version
  • if there is a new update available it downloads it and installs it

Is there a way (a viable way, not some hacky one) we can replicate this behaviour with IOS apps?

If there isn't I guess the option is only to publish the app through the app store (so there will always be only one version of the app for everyone) and make sure that the new versions of the app works with the old versions of the API. And the contrary too, while waiting for the app review time the API can be updated, so it must offer a certain degree of backwards compatibility.

Thank you

frankieta
  • 962
  • 1
  • 9
  • 31
  • 1
    You can not. Every app update/upload needs to go through Apple review. If you in some way download code that will be executed inside the App, your app will get rejected and removed from Appstore. The only solution is that you implement some method for your iOS Client to know what API endpoint to connect to, but you do this on the server side. Send your APP version headers to your server on the API requests, and act accordingly, connecting the client to the old API while the update is in progress. Also remember, even if you update your App on Appstore, that doesnt mean users will update it too. –  Aug 31 '17 at 11:45
  • Thank you @Sneak. We will have to work on our api in order for it to be backwards compatible; some hints are provided in this question: https://stackoverflow.com/questions/10716035/best-practices-for-api-backwards-compatibility – frankieta Aug 31 '17 at 13:26
  • 1
    Yes, depending on your setup and API structure etc. you can do in different ways, but I don't see any problems on backward compatibility, it is a minor issue, unless you have dramatic changes. Backward compatibility should always be taken into consideration anyways, since the client is not guaranteed to update the app. One thing that can be harder, is when you do structure updates in the DB etc, and you need to sync that with the old clients and the LIVE DB, you should have that in mind and atleast plan a strategy for that before your release. GL –  Aug 31 '17 at 15:24
  • @Sneak, please can you elaborate a little bit more on this concept, maybe with an example? Thank you for your patience – frankieta Aug 31 '17 at 16:37
  • 1
    Well, in short, let's say you have clients connected to your API V.1 , and you want to do some major update on your backend that holds user data (your DB), you can either 1: (easy option) Have a short system downtime while you redirect the clients to the new DB that is a replica with the old data + new structure, or 2: (hard option) , do this without downtime, this is nothing I can elaborate further here, it takes a team and is all depending on your backend structure etc. So, the point is, its not only software updates, but also user-data that could be backward compatible –  Aug 31 '17 at 16:55
  • 1
    The point is, you need to keep the DB/Backend updates in sync with connected/incoming data from the clients, unless you have downtime. –  Aug 31 '17 at 16:57
  • 1
    Thank you, it's more clear now :) – frankieta Aug 31 '17 at 17:12

0 Answers0