Newly installed app with latest build is being required to download (and install) latest code-push build

[faceyspacey]

For some time my code has been:

codePush.sync({
      installMode: codePush.InstallMode.ON_NEXT_RESUME,
      mandatoryInstallMode: codePush.InstallMode.IMMEDIATE,

But I almost never pushed with mandatory mode. I'm not even sure I have, but I might have a while ago. Now, every time I build the production version of the app in Xcode, it restarts after getting the latest code. But it already has the latest code. So I'm not sure why it's doing this, or even how it detects if it has the latest code (a hash of the bundle??).

My hunch is that I must have pushed a build with a mandatory flag a while back, and now on every fresh xcode build it thinks it needs to get that, even though it has the latest code. When I do code-push deployment ls It says Mandatory: NO. I thought for a second perhaps the mandatory flag was inherited somehow from a previous push.

Honestly, I have no idea what's going on. I've temporarily set mandatoryInstallMode to ON_NEXT_RESUME, but I'd like to get to the bottom of why code-push thinks my app doesn't have the latest code when obviously it does.

[richardhuaaa]

Hi @faceyspacey, I think what you might be looking for is the deployment history command, which will show you whether or not you have a mandatory release in your history. If you do, then you are right that the latest release will 'inherit' the mandatory attribute. If this is indeed the cause and you'd like to change it, you can patch the release to no longer be mandatory.

Does this help?

[faceyspacey]

that's amazing. thanks so much. Great work with the code push stuff by the way. really good stuff.

[faceyspacey]

@Silhouettes I have 2 quick questions for you:

1. what about new releases on the app store that already has the latest version--is there a way to mark the version it has so it doesn't install a mandatory version it already has, which, for me at least, causes a hiccup in my app as it installs it? Also note: the targetBinaryVersion parameter doesn't apply in this case as the app store update is only so new users have the latest javascript code the first time they open the app and no new binary code has changed. I don't want these users having their app restarted because of an inherited mandatory release (or even if the latest release is mandatory) since they already have it.

2. what if you want to add/remove the mandatory setting on an older release? The patch command only seems to let you patch the latest release. It doesn't have documented a targetRelease parameter like the rollback command. The use case would be the following:

I want to release a non-mandatory major release and possibly have additional small releases after it, and then at a later point mark that older major release mandatory; the reason I would do this is to avoid the app hiccups on install for the largest # of users.

Maybe there is something I don't know, but the mandatory release is a very bad last resort in my case as for users who have yet to signup we continue to show an intro animation at the beginning. If you're returning to the app after a mandatory release has been made, it gets about a second through the intro animation and then the app restarts and it plays again. It's jarring and not the smooth user experience we're aiming for. I imagine if you don't have an intro animation it's not as bad, but my guess is that it's an unavoidable consequence everyone will have with a mandatory release, even if just for a split second (more like 1 or 2 seconds though). So that's why the above capability to later mark an old release as mandatory is a nice solution--it lets you limit the percentage of you're users that will experience that glitch. In addition, being able to unflag an older release as mandatory would let you fix any mistakes where an older release than the latest one shouldn't have been made mandatory, as was the case with me in the initial issue here.

[richardhuaaa]

Hey @faceyspacey, in answer to your questions:

1. We have some hashing logic to ensure that if the version of the script code running in the binary is identical to the CodePush update that would be applied, the SDK will report the app as already up-to-date. Is this not the case for you (i.e. are you sure there isn't a tiny difference between the uploaded CodePush update and the version you're shipping to the store?)
2. You can indeed modify older releases, you just need to use the --label <releaseLabel> flag :)
3. For your issue with your intro animation being interrupted, I'd recommend using the disallowRestart() and allowRestart() methods to delay the restart until after the animation. If you also have an issue with the animation being played through twice, maybe you could save some state locally to ensure that it is not played the second time.

I'm not sure if the discoverability of these features is a problem - let me know if you have any ideas to improve it :)

[faceyspacey]

Hey @Silhouettes thanks so much. I wasn't sure whether --label just let you change the label or whether it was a selector. I also think your dis/allowRestart() methods should be sufficient. Regarding #1, I'm not sure--i thought I had pushed the update--but I'll keep a look out and report back if I find any issues. Again, thanks so much!