Releases: microsoft/react-native-code-push
v1.10.6-beta
This release primarily includes performance improvements to the update download process (for both iOS and Android), and also fixes a critical user-reported bug on iOS. It is now available on NPM and can be installed via npm i --save react-native-code-push
.
Performance Improvements
- The download progress events that are triggered when calling either
sync
orRemotePackage.download
are no longer dispatched to the JS thread unless the app actually specified adownloadProgressCallback
. Additionally, even if an app subscribed to download progress events, we now throttle them along with the device's vsync, so that the CodePush plugin doesn't overwhelm the JS thread with more events than it can actually render, and ensures that we impose a small impact as little an impact on the app's frame rate as possible.
Bug Fixes (iOS)
- CodePush updates are now explicitly excluded from iTunes and/or iCloud backups, which ensures that they don't impact the end users storage capacity, and also prevents any App Store rejections based on their storage guidelines.
v1.10.5-beta
This is just a quick bug fix release that addresses a regression with the client-side rollback feature on Android devices.
v1.10.4-beta
This is just a quick bug fix release that addresses an issue that could occur when an update is downloaded while the app is in the foreground, but finished installing after it has been put into the background.
v1.10.3-beta
This is just a quick bug fix release that also improves upon the existing getCurrentPackage
method. It is now available on NPM and can be updated immediately by running npm i --save react-native-code-push@latest
.
New Features
-
Metadata about the currently running update can now be reliably retrieved The existing
getCurrentPackage
method allowed programmatically retrieving the metadata for CodePush updates (e.g. what is its label? is it mandatory?), but unfortunately, it would always return the "latest" locally available update, which could either be the running update or a pending update. Therefore, there wasn't a reliable way to get the metadata for the update that is currently running, that disregarded any pending updates To address this, we are deprecating thegetCurrentPackage
method and replacing it with a newgetUpdateMetadata
method that allows explicitly specifying whether you want the metadata for the running, pending or latest (using the same behavior asgetCurrentPackage
) update. Check out the docs for more details.import codePush, { UpdateState } from "react-native-code-push"; // Reliably get the running update metadata // Both of these calls are equivalent codePush.getUpdateMetadata(); codePush.getUpdateMetadata(UpdateState.RUNNING); // Check if there is a pending update, and if so, get its metadata codePush.getUpdateMetadata(UpdateState.PENDING); // Provides the same behavior as the existing getCurrentPackage method. // The return object still contains the isPending property to determine // if the latest update is pending or not. codePush.getUpdateMetadata(UpdateState.LATEST);
-
The
notifyApplicationReady
method has been aliased asnotifyAppReady
to be more consistent with the use of "App" instead of "Application" in most React Native APIs (e.g.AppRegistry
,AppState
). To prevent a breaking change,notifyApplicationReady
isn't removed, but our docs will prescribe the new alias moving forward.
Bug Fixes (iOS)
- We resolved a bug where CodePush updates on disk weren't correctly being cleared after bumping the app version when using React Native packager as opposed to specifying
[CodePush bundleURL]
as your JS bundle location.
v1.10.2-beta
This is just a quick bug fix release that addresses a few commonly 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
- Fixed an issue with programmatic restarts (e.g. calling
CodePush.restartApp
, specifying anyInstallMode
value other thanON_NEXT_RESTART
when callingsync
) on pre-KitKat Android devices. - Removed the pre-release version tag from our podspec (
-beta
), which was causing issues for apps being submitted to iTunes Connect. We could have just documented this workaround, but it seemed like a better solution for our users to just remove it on our end, since our NPM packages and GitHub releases already include the-beta
semantics.
v1.10.1-beta
This release primarily improves some of the fundamentals of CodePush for Android and deepens our integration with RNPM (we hope to do more more in the future!). It is now available on NPM and can be updated immediately by running npm i --save react-native-code-push@latest
.
New Features (Android)
-
App restarts are now much smoother for the end user Previously, when an app was restarted in order to apply a CodePush update, we would stop and re-start the
Activity
that represented the current React Native app. While this method worked, it had the effect of being a fairly obtrusive user experience. This release improves the restart by doing a reload of the React Native bridge, which is able to re-use the existingActivity
and simply results in a quick "flash" when reloading the new JS bundle file. This experience mirrors what we already have on iOS and should be a lot nicer for your users. -
RNPM-based installs now generate the CodePush package code correctly When you run
rpm link react-native-code-push
, it will update yourMainActivity
class with the right constructor call to theCodePush
class (instead of generatingnew CodePush()
which isn't a valid signature), which further simplifies the installation experience. -
RNPM-based installs now prompt you for your CodePush deployment key If you're using RNPM >=1.6.0 (we recommend it!), when you run
rpm link react-native-code-push
, you will be prompted for your Android deployment key, which will be used to auto-populate yourMainActivity
file. You can choose to ignore this for now and specify it later using our configuration instructions. We hope to add support for iOS as soon as RNPM allows automating the creation ofInfo.plist
entries.
v1.10.0-beta
This release primarily introduces a simplified public Java API, that is also more compatible with RNPM, and should make integrating CodePush into React Native Android apps a little easier. It is now available on NPM and can be updated immediately by running npm i --save react-native-code-push@latest
.
New Features (Android)
- RNPM-based installation is now fully supported and documented We had to make a few breaking changes to our Java API to achieve this (see below for details), but we believe it will be worth it in the long run, since RNPM will greatly simplify adding CodePush to new projects and/or re-installing it in existing projects after performing a React Native upgrade. View the updated Android install docs for more details.
- The
CodePush.getBundleUrl
Java method now includes an overloaded version that takes no parameters, and assumes your JS bundle name isindex.android.bundle
. This is what most people name it, so this is just a simple codification of an already ubiquitous convention. More details
Breaking Changes (Android)
- The
CodePush
class itself is now aReactPackage
, and therefore, you can construct an instance of it, and directly add it to the list of packages in yourMainActivity.getPackages
method. Because of this, theCodePush.getReactPackage
method has been removed from theCodePush
class since it is no longer needed. View the updated Android install docs for more details about how this class is expected to be used now. - The
CodePush.getBundleUrl
method is now static, which allows you to easily call it from within yourMainActivity.getJSBundleFile
method, without needing to maintain a local member variable for theCodePush
class instance. View the updated Android install docs for more details about how this method is expected to be used now.
v1.9.0-beta
This release introduces a couple of highly-requested features, as well as some key bug fixes. It is now available on NPM and can be updated immediately by running npm i --save react-native-code-push@latest
.
New Features
-
Added client-side support for the new release rollout feature in the CLI This version of the React Native SDK is required in order to begin taking advantage of this new capability, so make sure to upgrade your apps before attempting to release updates with a rollout percentage. More details
code-push release-react MyApp ios --rollout 25%
-
Added support for throttling resume-based installs We've seen a lot of developers want to use the resume-based install strategy, in order to get their updates in front of their end users sooner. However, forcing a restart on the next resume might be too obtrusive if the user switched away from the app for only a few seconds (e.g. to respond to a text). In order to help get updates in front of users sooner, while still respecting their workflow, the
sync
method now accepts a new option calledminimumBackgroundDuration
that specifies the number of seconds that the app needs to have been in the background before forcing the install. More details// If the app was in the background for 10 minutes, we assume that it is "safe" to restart to install the update codePush.sync({ installMode: codePush.InstallMode.ON_NEXT_RESUME, minimumBackgroundDuration: 10 * 60 });
Bug Fixes (General)
- When an update is downloaded from the CodePush server, the plugin now looks for the JS bundle file using the exact same file name that was specified as being contained in the binary (via either
[CodePush bundleURL]
orCodePush.getBundleURL
), as opposed to looking for the first file with a.jsbundle
,.bundle
or.js
extension. This makes the update E2E more reliable, and prevents issues for apps that use local<WebView>
hosted content.
Bug Fixes (iOS)
- The contents of the app binary are now successfully hashed for apps that aren't using React Native assets
- A custom error message is displayed when using
[CodePush bundleURL]
in yourAppDelegate.m
file, and deploying a debug build to the iOS Simulator. React Native doesn't generate a JS bundle in the binary in this circumstance, and it has confused many CodePush users. To help alleviate the confusion, we now explain the issue as well as a few possible workarounds.
Bug Fixes (Android)
- Cleaned up a bunch of lint warnings that didn't impact behavior, but may have been noisy for devs integrating CodePush into a native Android app
- Fixed an interop bug for apps that are using CodePush along with the Fabric SDK
v1.8.0-beta
This release introduces a handful of highly requested features and some key bug fixes. It is now available on NPM and can be updated immediately by running npm i --save react-native-code-push@latest
.
New Features
- The
sync
method now accepts a new option calledmandatoryInstallMode
, which allows you to individually customize the install mode that is used for optional and mandatory updates. This new property defaults toInstallMode.IMMEDIATE
(which is what we've found most devs want), but can be changed by passing a different value when callingsync
(e.g.codePush.sync({ mandatoryInstallMode: codePush.InstallMode.ON_NEXT_RESUME })
). - The contents of the binary are now hashed and sent to the CodePush server so that we can detect whether an available update is equivalent to what the end-user is already running. This helps prevent the unnecessary first-run update issue, and we now encourage developers to release their binary contents to CodePush to help solve this scenario, as well as enable diff updates for the initial CodePush update after a fresh binary install/update.
- When we download a diff update from the server, and merge its contents together with the previous update (or binary contents), we now validate the contents of the entire update on the client-side to ensure integrity.
Bug Fixes
- We removed our use of
Promise.prototype.done
for compatibility with allPromise
implementations, since we were seeing instances where folks were overriding the default React Native polyfill - We fixed our podspec to support CodePush being built as a framework in Swift apps using CocoaPods.
- We removed the requirement for apps to include a patch component in their version (e.g.
2.0
as opposed to2.0.0
), so you can now release updates for apps, without needing to change your versioning policies - Added some better diagnostic logging in certain scenarios (e.g. when the native module wasn't properily configured).
Breaking Changes (General)
- With the addition of the new
mandatoryInstallMode
option forsync
(described above), by default, mandatory updates will now be installed immediately. From our experience, this is what most developers were already doing or wanted to do, but just keep this change in mind, since it's possible that it would impact your existing update experience once you upgrade the plugin.
Breaking Changes (iOS)
v1.7.3-beta
This is a bug fix release which addresses a user-reported iOS issue and also introduces a small breaking change for apps using getCurrentPackage
. It is now available on NPM and can be updated immediately by running npm i --save react-native-code-push@latest
.
Bug Fixes (iOS)
- When the
Promise
returned bygetCurrentPackage
was rejected (rare but possible), the native-side wasn't properly returning from the method, and therefore, it would attempt to resolve thePromise
as well, which would result in a "Callback with id [ID] not found" error.
Breaking Changes
- The
getCurrentPackage
method now returnsnull
when the currently running JS bundle is coming from the binary and not from a CodePush update. This is the behavior that most people expected, but in case you're usinggetCurrentPackage
and not currently checking for anull
object as the resolved value of itsPromise
, you need to make sure to update that. Note that this isn't a server change, and therefore, existing production apps are unaffected. This breaking change only affects apps that upgrade to 1.7.3+ and continue callinggetCurrentPackage
without checking fornull
.