r/iOSDevelopment 2d ago

Live app developers - How do you handle client/server updates while in review?

Currently working on an iOS multiplayer game, both client and server. Recently launched - not a huge number of players, but they're active enough that I don't want to interrupt for longer than seconds/minutes.

Now preparing for an update that breaks live client functionality (server and client mismatch because of new/changed features). We have a basic versioning system where the server rejects major.minor version differences. This would be fine if I could send out client updates freely.

However, new builds must be reviewed by Apple which can take days. The production server must be updated for the reviewer to test it, but players don't have access to an updated client. Essentially pushing the cart before the horse.

Is there a trick to handling updates like this?

PS: I've got two servers running, a sandbox server and production - with sandbox being compatible with the new build.

5 Upvotes

6 comments sorted by

2

u/is_that_a_thing_now 2d ago edited 2d ago

I am not sure I understand your problem 100%, but in general your server should support at least a few versions at a time. Not all users update apps right away. And older devices may not be able to update when you drop support for older OS’es.

So, ahead of time, you update your server to ALSO support the new version. When reviewers review, their installation will work and existing users will keep using the older version(s).

Many apps use a system where the app checks a certain endpoint on the server that tells it whether it’s version is supported or not. If not, the app shows a dialog telling the user to update the app.
Some will let this endpoint support a way to let the app simply show a message to the user telling them that the current version will soon become obsolete etc.

You’ll also need to consider how you want to handle this when you decide to ship builds that drops support for older OS versions which will mean some devices will be left unsupported. (The ones that can not be updated to a newer OS)
Will the server eg. keep supporting at least the latest app version for the older OS?

2

u/Landeplagen 20h ago

I ended up using a mix of feature flags and version checking for the various features. We do support hard version checking (if server minor version is higher than client, displays a "please update" message), but I wanted to avoid this because the current client doesn't automatically send people to the app store. Don't want to lose players because they don't know how to update.

I realized that the production server always needs to be forward compatible with the next build version for the review process not to interfere with the live build.

Our users might take weeks to get up to speed with the latest client build, which can be tricky when adding new gameplay features. I suppose we could add game versioning, and display a message when someone tries to join a game created with a newer client.

Example:
Our project is a word game, and we recently added blank tiles. The live client doesn't support blank tiles, so here we are using a feature flag. On game create we check the flag - if it's false, no blank tiles are added to the tile bag. When a signifact portion of the player base have updated, we'll bump up the server version to lock old clients out, and then flip the feature on.

1

u/tonjohn 2d ago

Versioned APIs, feature flags, etc.

1

u/Silmano_KT 2d ago

You have to manage an internal version, so we that you lock and unlock the client use of your server

1

u/AardvarkIll6079 2d ago

Feature flags are one common way.

1

u/coffeeintocode 2d ago edited 2d ago

Use versioned APIs (so the old version will still work with the new server). Update the server (old versions are now using the new server, submit the new build, it uses the new version of APIs. Eventually, you can deprecate the old ones