The problem, as you might expect, is the app review process.
In order to get Apple to review an app update, it has to be pointing at my production server. In order for that to work, I must update the build on my production server. But of course I don’t want to do that until the app update is available in the Apple Store.
Now this isn’t a problem if I’ve only made changes that can be deployed via hot code push … but changes that can be deployed via hot code push don’t need a new app wrapper anyway. I’m concerned about things like new node modules, or an updated meteor version.
Surely I’m not the only person to have this problem, but the most pertinent forum thread I found was this one (Push new update IOS app store).
Hot code push blocks when the Cordova versions are not equal. So it will not update when they are not equal. So for example a Meteor update from 1.3 to 1.4 may block (and will need an iOS update). Where and update from 1.3.1 to 1.3.2 might not need that so it will hot push.
But of course I don’t want to do that until the app update is available in the Apple Store.
Not always.
The main issue there is when you change logic on the server which is really incompatible, like removing methods, with the existing clients out there. If you add or improve methods (like adding security checks) you can just publish that to your production server.
In general you track your regression bugs with your testing suite. It becomes hard when you for example add a new parameter to a method. Then you have incompatible code where the old client will not supply that parameter.
What we do then: We don’t mix that release with Cordova changes as well. So when we update something related to Cordova we do an immediate update to Apple so we can freely update the business logic afterwards.
Ah, okay. So if I understand correctly, you separate anything that introduces a breaking (Cordova version or Cordova plugin) change into its own update. Say you upgraded from meteor 1.3 to 1.4 and made absolutely no other changes. You would then:
build a new wrapper for the app store.
update your production server with the new version.
submit the new wrapper to Apple for approval.
wait.
once apple approves the new wrapper, deploy it to the store.
users download the updated version and everything is copacetic.
But what happens to your app users during step 4? Can you expect the client running meteor 1.3 to get along nicely with the server running meteor 1.4?
We check the changelog and have both versions running on our dev machines. So we get quite some experience with the versions before we send them to the App Store. We also run an acceptance version for each app so we will catch those errors with manual testing. So we test that also with TestFlight before we send it for approval.
We don’t do automated testing from real iOS devices yet, we do that by manual testing. That’s something we may want to do in the future. But we catch about every issue just upfront by that manual testing so no real worries there yet. Because you only have to test the Cordova pieces, the rest stays stable.
Thanks so much for describing your process. The idea of separating wrapper-breaking changes into a separate update is a helpful one. But I’m not sure it solves all my problems. It still seems it’s highly likely that I might end up with an ugly incompatibility between cordova versions that meteor doesn’t provide a good way to work around.
Any idea how I could get a confirmation from MDG folks about how App Store deployments are /intended/ to work?
For us it did not occur, and it prevents the client from updating so that is quite hard to happen. What should be in sync is the older client version of your software with the newer version running on the server.
@martijnwalraven is the expert on Cordova so I hope he will add in his view on this matter!
I don’t have much to add, @lucfranken has done a really good job explaining the issues and I’m sure he has much more experience using Cordova and Meteor in production than I have.
As mentioned, hot code push is fairly conservative, so Cordova or plugin updates by themselves shouldn’t lead to incompatibilities (existing devices will still be running the old code). You do want to be careful with making changes to your server however, such as changing subscriptions or methods. In general, only make changes that are backwards compatible (at least until all clients have updated, if there is such a thing). Meteor updates shouldn’t lead to incompatibilities, but always check the changelog and test your old app version against a new server deployment before updating your production server.