1

I tried Code Push with react-native for the first time and I have a below question.

Let's say I have published an app with version 1.2.0 on AppStore and I push a code-push version for that specific target (1.2.0).

Now, the update popup is shown to those users but I don't want to show popup to new installers so I republish the app on AppStore and migrate it to 1.2.1.

So my question is, what about the users who installed 1.2.0 and got code pushed version later? They have code for 1.2.1 but their actual version is 1.2.0. So how can we keep the AppStore version in sync with code push one?

In general, how do we approach code push safely, covering such cases?

Thanks

Nishan Bende
  • 41
  • 1
  • 8
  • Can't you update the version in your app to 1.2.1 before the code-push and then release the proper 1.2.1 through appstore afterwards? I haven't tried including a change to version-number in a code-push, but I would assume that it could work. Otherwise when 1.2.1 is released, users on 1.2.0 (code-push version) should automatically update, since a new version is available. – BaconPancakes Aug 30 '19 at 07:52
  • okay, so you mean that I should update already installed apps via code push and also generate a new app store deployment, right? – Nishan Bende Aug 30 '19 at 08:14
  • Is there any approach we should follow with code push and standard deployments? – Nishan Bende Aug 30 '19 at 08:15
  • Just thinking out loud! How about checking if the app is first launched, then skip the popup and directly update the codepush bundle? that way you don't have to release a new version to appstore again. – Hannan Shaik Jan 22 '20 at 01:55

2 Answers2

1

You have to change it manually. Code push doesn't change native files or in play store desc.

Rishav Kumar
  • 4,979
  • 1
  • 17
  • 32
0

Bit late with the answer, but sharing my 2 cents for anybody who is wondering -

In our production environment, we use the 4th digit to identify the codepush releases (and display this value in the settings page of our app). The appstore/playstore releases (as required) are in X.X.X format, but the app UI displays X.X.X.X .

When we are codepushing the update, we increment the 4th digit (it's stored in appconfig.js) , and after next store release we reset it back to 1. As the codepush releases can be targeting specific appstore/playstore release (using the -t option of CLI) , with this approach we can codepush latest update to recent store version and also a patch to previous version at the same time. Example:

Initial store version 1.0.0 => app settings page shows 1.0.0.1

  • Codepush #1 , target 1.0.0 => 1.0.0.2
  • Codepush #2 , target 1.0.0 => 1.0.0.3

Store release 1.0.1 => 1.0.1.1

  • Codepush #3 , target 1.0.1 => 1.0.1.2
  • Patch Codepush #4 , target 1.0.0 => 1.0.0.4

(apply patch to previous version to clients which didn't update yet to 1.0.1)

If for any reason we can't patch anymore previous versions (i.e. requirement of a new native module from latest version), we have a built in mechanism in the app to force everybody to update to latest store version (triggered remotely from server side) , in which case they will all get the latest codepush and we don't need to worry about backward compatibility.

Dharman
  • 30,962
  • 25
  • 85
  • 135
mike_t
  • 2,484
  • 2
  • 21
  • 39
  • Thank you for your answer @mike_t. I'm a bit late, but since you seem to know what you're talking about: do you know how can we push codepush update when our versionName is 2.xx.x ? seems like codepush only accepts format x.x.x for target version, but it's impossible for us to change our app store version.. – Gigalink Apr 14 '23 at 12:07
  • 1
    @Gigalink 2.xx.x (i.e. 2.10.1) is a valid semVer, i don't see a reason why it shouldn't work.. Double check if your binary has a correct version (build.gradle for android, or in xcode for ios) and compare it with latest update u pushed. check the output of `code-push deployment history ` and check if it's matching your version (check for typos, or any wildcards in past that might be promoting older code pushes) – mike_t Apr 16 '23 at 07:40
  • I unfortunately keep getting the error "Error: Invalid binary version(s) for a release." when trying to push a 2.xx.x version. weirdly enough, it does work with 2.x.x format, whereas such format is nowhere used (not in build.gradle etc) when you say "compare with latest update you pushed", what do you mean? I never push an update through codepush, I was testing if it worked to implement it. I followed their doc. and it all worked until that deployment step. I appreciate your help :) – Gigalink Apr 18 '23 at 10:17
  • What exactly is the version you are trying to push? Does it match `versionName` from your build.gradle? 2.xx.x mask is a valid semver format (as long as the xx int the minor is a valid integer) – mike_t Apr 19 '23 at 04:23
  • the version is 2.03.1, and it matches EXACTLY the version shown in build.gradle. That's exactly why i'm so confused – Gigalink Apr 19 '23 at 13:56
  • 03 is not a valid integer, so it's not a valid SemVer - in this case i'm afraid the only solution is to do a new store release and fix the versioning from that point on (i.e. 2.3.2 will be your next version) . `A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.` - source - https://semver.org/#spec-item-2 – mike_t Apr 20 '23 at 04:37
  • 1
    Unfortunately 2.3.2 would not work for many reasons on my case, however I will simply updtae to 2.10.0 instead, thank you so much once again that makes sense!! – Gigalink Apr 21 '23 at 10:20