Skip to content

Releases: microsoft/react-native-code-push

v1.7.2-beta

10 Feb 00:04
Compare
Choose a tag to compare

This is a bug fix release which addresses some key user-reported issues. It is now available on NPM and can be updated immediately by running npm i --save react-native-code-push@latest.

Bug Fixes (General)

  1. We saw a few cases where apps were inadvertently calling the sync method multiple times concurrently (e.g. they called sync in componentDidMount as well as an AppState change handler), which had the potential to put the app in a weird state. Now, when sync is called, and a previous sync call is still in progress (e.g. an update is downloading), it will resolve the promise with a new sync status of SYNC_IN_PROGRESS. That way, we can safeguard the runtime from getting into a bad state, while still providing the app with an indication of why each sync call completed.

Bug Fixes (iOS)

  1. If a developer's desktop clock wasn't synchronized with their testing device (i.e. it was significantly ahead of it), it would be possible to hit an issue where your app downloads a CodePush update, but after restart, continues to use the JS bundle that was shipped with the binary. This was because the [CodePush bundleURL] logic saw that the binary bundle was newer than the CodePush update, and therefore, gave it precedence. We no longer rely on this time-based heuristic for detecting whether to use the binary or CodePush update on app start, and therefore, this issue would no longer be possible in the rare cases that we saw it.

Bug Fixes (Android)

  1. We removed the superfluous NDK config from our build.grade file (we don't have any C++ code!), which was causing compilation errors for apps that use both the NDK and CodePush.

v1.7.1-beta

03 Feb 20:33
Compare
Choose a tag to compare

This is simply a bug fixing release that adds better logging for diagnostic purposes and re-enables install telemetry to be reported while debugging.

v1.7.0-beta

03 Feb 00:56
Compare
Choose a tag to compare

This release introduces the long-awaited support for updating assets on Android! This feature depends on React Native v0.19.0, so you'll need to update to that version of the platform in order to consume this CodePush release. We think it's extremely worth it though! (e.g. you get new debugging support for unhandled promises). This update is now available in NPM and can be installed immediately!

New Features (Android)

  1. Deploy updates to your assets on Android via CodePush. This works exactly like it does for iOS: instead of simply uploading your JS bundle to CodePush, you upload a directory containing your bundle and assets, and everything works great. The server supports differential updates, so your end-users will only get the files that changed between releases (i.e. they won't have to download all of your assets every time you release an update). Check out the CLI docs for the release command for more details.

New Features (iOS)

  1. We added a new method to the CodePush class called setDeploymentKey which allows you to dynamically set your deployment key in Objective-C, as opposed to specifying it in the Info.plist file.

Breaking Changes

  1. This release depends on React Native 0.19.0, so if you choose to upgrade CodePush, then you need to also upgrade your React Native dependency.
  2. The newly added install metrics feature now only reports data to the server in release builds. Therefore, if you are testing your app and want to see this data populated in the CLI, you'll need to generate a release build first. This change was made to reduce noise from the metrics that are generated during debugging.

v1.6.0-beta

23 Jan 01:00
Compare
Choose a tag to compare

This release primarily introduces the necessary client-side telemetry to support the new install metrics of the CLI. You can view the details of this feature here. This version is now available in NPM and can be installed immediately!

New Features

  1. Update installations and rollbacks are now reported to the CodePush server in order to enable the CLI to display these metrics. You can find details about this feature here.

Bug Fixes

  1. The Android platform implementation no longer requires your app's Activity to inherit from FragmentActivity in order to display an update dialog prompt. This was necessary for enabling React Native 0.18.0, since it now makes use of a base class (ReactActivity) which doesn't itself inherit from FragmentActivity.

v1.5.3-beta

09 Jan 21:11
Compare
Choose a tag to compare

This release is primarily meant to address an iOS compilation error that was introduced by React Native 0.18.0-RC (see details below), but it also includes a few other fixes and a minor feature enhancement. It is now available on NPM and can be upgraded to immediately.

Bug Fixes (iOS)

  1. In order to perform a programmatic app restart after an update has been installed, the CodePush plugin needs to update the RCTBridge.bundleURL property to point at the latest JS bundle file on disk. React Native 0.18.0 made this property readonly (in it's interface), and therefore, cause a compilation error with our plugin, since we could no longer set it. At runtime, this property is still readwrite, so we simply use KVC to set the property, instead of relying on the "dot syntax" that the compiler didn't like. In the future, we'll use the more appropriate solution of importing the new RCTBridge+Private.h header file, but for now, we wanted to maintain backwards combat so that this release didn't force all of our users to upgrade to React Native 0.18.0-RC.

Bug Fixes (General)

  1. Update assets (e.g. the JS bundle and images) weren't being removed from disk after being automatically rolled back due to a crash. This wouldn't have impacted the user experience, and unless you released a significant amount of CodePush updates that included a crash (please don't do this!), this wouldn't result in much disk space being used either. That said, we don't want to consume any more of the end users storage capacity than is absolutely necessary, so this was an important fix for cleanliness sake.
  2. Internal CodePush state (e.g. the list of updates that have previously failed) wasn't being properly cleared when a new binary was installed. It would be pretty rare for this behavior to have caused any issues, but it's more deterministic for us to treat each new binary installation as a "clean slate" since we can't make many assumptions about the new "environment" (e.g. which CodePush updates will work within it).

Feature Enhancements

  1. The restartApp method now includes an optional parameter that lets you specify whether you want to always restarts the app, or only if there is a pending update. This makes it simpler to implement a "forced restart" solution at some well-known point within your app (after installing a non-immediate update), without having to check LocalPackage.isPending before calling restartApp.

v1.5.2-beta

21 Dec 00:31
Compare
Choose a tag to compare

This release fixes a bug with the rollback protection feature that would occur in some circumstances on iOS when deploying React Native assets.

v1.5.1-beta

19 Dec 15:55
Compare
Choose a tag to compare

This is largely a bug-fix release to address a regression, but it also introduces a small feature request. It can be immediately acquired from NPM and includes the following improvements:

New Features (iOS and Android)

  1. The LocalPackage object returned by calling getCurrentPackage now includes an isPending property which indicates whether or not the most recently installed update has actually been applied yet via a restart.

Bug fixes (iOS and Android)

  1. We fixed a regression that caused immediately-applied updates to automatically rollback in certain situations.

v1.5.0-beta

12 Dec 21:19
Compare
Choose a tag to compare

This is largely a bug fix release for the Android platform, that also introduces a breaking change for both iOS and Android (hence the minor version bump). Because of this breaking change, you need to uninstall your app from the emulator/devices your testing against before upgrading. It can be immediately acquired from NPM, and includes the following improvements:

Breaking Changes (iOS and Android)

  1. The rollbackTimeout parameter of both the sync and LocalPackage.install methods have been removed. We received a lot of feedback regarding this parameter being pretty confusing, and it also required devs to opt-in to receiving client-side rollback protection. We believe that this behavior is extremely important for doing production deployments, and therefore, in order to be more prescriptive, calling sync and LocalPackage.install will now automatically enable rollback protection, and it cannot be disabled (why would you want to do that anyways?)

    If you are calling sync on app start (e.g. the componentDidMount method of your root component), then you don't need to do anything else. Your updates will be made available to users, but if you accidentally release something bad, you can rest assured that your users will be automatically rolled back. However, if you are calling sync somewhere else (e.g. button click, within a periodic timer), you MUST call notifyApplicationReady after your app has successfully started (e.g. in your root component's componentDidMount event), which lets the CodePush runtime know that the update is valid and won't automatically roll the end-user back to the previous version.


    We've found that the vast majority of users are calling sync in componentDidMount, and therefore, this change automatically makes your deployments more reliable, without doing any work!

Bug Fixes (Android)

  1. When dev support is enabled, the React Native runtime attempts to load the JS bundle from a locally available cache. This can create a confusing workflow when using CodePush, since it's possible to install an update, restart the app, and not see the changes applied. This occurs because the app might still be using the older cached file, and CodePush is effectively not being consulted. The CodePush plugin now deletes the React Native cache whenever an update is installed. This will have the effect of loading the JS bundle from the packager (if running), or the bundle file downloaded from CodePush.
  2. There were some instances where an installed update wouldn't be correctly applied when running your app in an emulator. This has now been addressed, and updates should work great across all emulators and devices.

v1.4.2-beta

09 Dec 07:24
Compare
Choose a tag to compare

This is a bug fix release that addresses the following issues and can be immediately acquired via NPM:

  1. When an error occurs during a call to sync (e.g. missing deployment key in Info.plist file), that error message is now logged to the console (e.g. adb logcat, Chrome, Xcode console). Previously, we would only log "Unknown error", which wasn't particularly useful. If an app was calling done on the Promise returned by sync, any errors would have resulted in a red box, so this issue only really impacted scenarios where the error was being completely swallowed and the console didn't provide any indication of the cause.
  2. We were previously writing the update contents (e.g. JS bundle, images) to the app's Documents folder, whereas the iOS guidelines recommend using the Library\Application Support directory for content that shouldn't be end-user visible. Because of this change, you should uninstall your app from any devices or simulators in order to clean out the Documents folder. The plugin automatically cleans out old updates when installing a new one, but with this fix, it won't attempt to clean out the Documents folder anymore. This won't impact any user experience, however, it's just for cleanliness sake.
  3. The iOS plugin was erroneously giving priority to the JS bundle contained in the binary in some instances. If you're installing an update but still seeing an older version of your app after restarting, it it likely this bug, and you should update your NPM dependency to this release.

v1.4.1-beta

07 Dec 18:39
Compare
Choose a tag to compare

This is a bug fix release which addresses the following two issues:

  1. The sync method wasn't calling notifyApplicationReady as was intended. This has been addressed, and therefore, when you are calling sync on app start, and specifying a rollbackTimeout, you don't have to manually call notifyApplicationReady, since
  2. The bug reported (and fixed!) via #94. Thanks @oney for being such a consistently amazing contributor!