@bravemobile/react-native-code-push 9.0.0-beta.6 → 9.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CodePush.js +13 -10
- package/CodePush.podspec +1 -1
- package/README.md +265 -369
- package/package.json +1 -1
- package/docs/setup-android.md +0 -482
- package/docs/setup-ios.md +0 -280
package/README.md
CHANGED
|
@@ -1,492 +1,388 @@
|
|
|
1
|
-
|
|
1
|
+
# @bravemobile/react-native-code-push
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
**Seamless transition from AppCenter to a fully self-hosted CodePush.**
|
|
4
4
|
|
|
5
|
-
```bash
|
|
6
|
-
npm install @bravemobile/react-native-code-push
|
|
7
|
-
```
|
|
8
5
|
|
|
9
|
-
|
|
10
|
-
You can still use CodePush, but become independent of AppCenter's cloud infrastructure.
|
|
6
|
+
This package was created to continue using React Native CodePush without AppCenter.
|
|
11
7
|
|
|
12
|
-
|
|
8
|
+
It allows self-hosting of CodePush deployments while retaining essential operational features.
|
|
13
9
|
|
|
14
|
-
Specify the host and path using the `bundleHost` option.
|
|
15
10
|
|
|
16
|
-
Upload the code-push bundle file to your server. The file name should be exactly same as the file on AppCenter.
|
|
17
11
|
|
|
18
|
-
```javascript
|
|
19
|
-
const codePushOptions = {
|
|
20
|
-
bundlehost: 'https://cdn.yours.com/codepush/bundle/',
|
|
21
|
-
};
|
|
22
12
|
|
|
23
|
-
|
|
24
|
-
|
|
13
|
+
> [!NOTE]
|
|
14
|
+
> New architecture will be supported later.
|
|
25
15
|
|
|
26
|
-
### Customize the update check behavior
|
|
27
16
|
|
|
28
|
-
Specify a function to perform the update check using the `updateChecker` option.
|
|
29
17
|
|
|
30
|
-
|
|
18
|
+
## 🚗 Migration Guide
|
|
31
19
|
|
|
20
|
+
If you have been using `react-native-code-push`, replace the NPM package first.
|
|
32
21
|
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
// It's up to you to decide what to do.
|
|
37
|
-
// However, you need to have a good understanding of Code Push's interface to configure your response.
|
|
38
|
-
const { data: response } = await axios.get('https://your.api.com/update_check', {
|
|
39
|
-
params: { app_version: updateCheckRequest.app_version }
|
|
40
|
-
});
|
|
41
|
-
return response;
|
|
42
|
-
},
|
|
43
|
-
};
|
|
44
|
-
|
|
45
|
-
export default codePush(codePushOptions)(MyApp);
|
|
22
|
+
```bash
|
|
23
|
+
npm remove react-native-code-push
|
|
24
|
+
npm install @bravemobile/react-native-code-push
|
|
46
25
|
```
|
|
47
26
|
|
|
27
|
+
Then, follow the installation guide starting from **'4. "CodePush-ify" your app'**.
|
|
48
28
|
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
[](http://microsoft.github.io/code-push/)
|
|
54
|
-
|
|
55
|
-
#### [Sign up With App Center](https://appcenter.ms/signup?utm_source=CodePush&utm_medium=Azure) to use CodePush
|
|
29
|
+
The following changes are optional but recommended for cleaning up the old configuration:
|
|
30
|
+
- Since the deployment key is no longer needed due to the retirement of AppCenter, it is recommended to remove it from your `Info.plist`, `strings.xml`, or JavaScript code.
|
|
31
|
+
- Thanks to Auto Linking, you can remove the `react-native-code-push` module settings from `settings.gradle`.
|
|
56
32
|
|
|
57
|
-
# React Native Module for CodePush
|
|
58
33
|
|
|
59
|
-
|
|
34
|
+
## ⚙️ Installation
|
|
60
35
|
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
<!-- React Native Catalog -->
|
|
66
|
-
|
|
67
|
-
* [How does it work?](#how-does-it-work)
|
|
68
|
-
* [Supported React Native Platforms](#supported-react-native-platforms)
|
|
69
|
-
* [Supported Components](#supported-components)
|
|
70
|
-
* [Getting Started](#getting-started)
|
|
71
|
-
* [iOS Setup](docs/setup-ios.md)
|
|
72
|
-
* [Android Setup](docs/setup-android.md)
|
|
73
|
-
* [Plugin Usage](#plugin-usage)
|
|
74
|
-
* [Store Guideline Compliance](#store-guideline-compliance)
|
|
75
|
-
* [Releasing Updates](#releasing-updates)
|
|
76
|
-
* [Multi-Deployment Testing](#multi-deployment-testing)
|
|
77
|
-
* [Android](docs/multi-deployment-testing-android.md)
|
|
78
|
-
* [iOS](docs/multi-deployment-testing-ios.md)
|
|
79
|
-
* [Dynamic Deployment Assignment](#dynamic-deployment-assignment)
|
|
80
|
-
* [API Reference](#api-reference)
|
|
81
|
-
* [JavaScript API](docs/api-js.md)
|
|
82
|
-
* [Objective-C API Reference (iOS)](docs/api-ios.md)
|
|
83
|
-
* [Java API Reference (Android)](docs/api-android.md)
|
|
84
|
-
* [Debugging / Troubleshooting](#debugging--troubleshooting)
|
|
85
|
-
* [Example Apps / Starters](#example-apps--starters)
|
|
86
|
-
* [Continuous Integration / Delivery](#continuous-integration--delivery)
|
|
87
|
-
* [TypeScript Consumption](#typescript-consumption)
|
|
88
|
-
|
|
89
|
-
<!-- React Native Catalog -->
|
|
90
|
-
|
|
91
|
-
## How does it work?
|
|
92
|
-
|
|
93
|
-
A React Native app is composed of JavaScript files and any accompanying [images](https://reactnative.dev/docs/image), which are bundled together by the [metro bundler](https://github.com/facebook/metro) and distributed as part of a platform-specific binary (i.e. an `.ipa` or `.apk` file). Once the app is released, updating either the JavaScript code (e.g. making bug fixes, adding new features) or image assets, requires you to recompile and redistribute the entire binary, which of course, includes any review time associated with the store(s) you are publishing to.
|
|
94
|
-
|
|
95
|
-
The CodePush plugin helps get product improvements in front of your end users instantly, by keeping your JavaScript and images synchronized with updates you release to the CodePush server. This way, your app gets the benefits of an offline mobile experience, as well as the "web-like" agility of side-loading updates as soon as they are available. It's a win-win!
|
|
96
|
-
|
|
97
|
-
In order to ensure that your end users always have a functioning version of your app, the CodePush plugin maintains a copy of the previous update, so that in the event that you accidentally push an update which includes a crash, it can automatically roll back. This way, you can rest assured that your newfound release agility won't result in users becoming blocked before you have a chance to [roll back](https://docs.microsoft.com/en-us/appcenter/distribution/codepush/cli#rolling-back-updates) on the server. It's a win-win-win!
|
|
98
|
-
|
|
99
|
-
*Note: Any product changes which touch native code (e.g. modifying your `AppDelegate.m`/`MainActivity.java` file, adding a new plugin) cannot be distributed via CodePush, and therefore, must be updated via the appropriate store(s).*
|
|
100
|
-
|
|
101
|
-
## Supported React Native platforms
|
|
36
|
+
### 1. Install NPM Package
|
|
37
|
+
```bash
|
|
38
|
+
npm install @bravemobile/react-native-code-push
|
|
39
|
+
```
|
|
102
40
|
|
|
103
|
-
|
|
104
|
-
- Android (4.1+) on TLS 1.2 compatible devices
|
|
41
|
+
### 2. iOS Setup
|
|
105
42
|
|
|
106
|
-
|
|
43
|
+
#### (1) Install CocoaPods Dependencies
|
|
107
44
|
|
|
108
|
-
|
|
109
|
-
|-------------------------|-------------------------------------------------------|
|
|
110
|
-
| <0.14 | **Unsupported** |
|
|
111
|
-
| v0.14 | v1.3 *(introduced Android support)* |
|
|
112
|
-
| v0.15-v0.18 | v1.4-v1.6 *(introduced iOS asset support)* |
|
|
113
|
-
| v0.19-v0.28 | v1.7-v1.17 *(introduced Android asset support)* |
|
|
114
|
-
| v0.29-v0.30 | v1.13-v1.17 *(RN refactored native hosting code)* |
|
|
115
|
-
| v0.31-v0.33 | v1.14.6-v1.17 *(RN refactored native hosting code)* |
|
|
116
|
-
| v0.34-v0.35 | v1.15-v1.17 *(RN refactored native hosting code)* |
|
|
117
|
-
| v0.36-v0.39 | v1.16-v1.17 *(RN refactored resume handler)* |
|
|
118
|
-
| v0.40-v0.42 | v1.17 *(RN refactored iOS header files)* |
|
|
119
|
-
| v0.43-v0.44 | v2.0+ *(RN refactored uimanager dependencies)* |
|
|
120
|
-
| v0.45 | v3.0+ *(RN refactored instance manager code)* |
|
|
121
|
-
| v0.46 | v4.0+ *(RN refactored js bundle loader code)* |
|
|
122
|
-
| v0.46-v0.53 | v5.1+ *(RN removed unused registration of JS modules)*|
|
|
123
|
-
| v0.54-v0.55 | v5.3+ *(Android Gradle Plugin 3.x integration)* |
|
|
124
|
-
| v0.56-v0.58 | v5.4+ *(RN upgraded versions for Android tools)* |
|
|
125
|
-
| v0.59 | v5.6+ *(RN refactored js bundle loader code)* |
|
|
126
|
-
| v0.60-v0.61 | v6.0+ *(RN migrated to Autolinking)* |
|
|
127
|
-
| v0.62-v0.64 | v6.2+ *(RN removed LiveReload)* |
|
|
128
|
-
| v0.65-v0.70 | v7.0+ *(RN updated iPhone-target-version)* |
|
|
129
|
-
| v0.71 | v8.0+ *(RN moved to react-native-gradle-plugin)* |
|
|
45
|
+
Run `cd ios && pod install && cd ..`
|
|
130
46
|
|
|
131
|
-
|
|
47
|
+
(`npx pod-install`, `bundle exec pod install --project-directory=./ios`, ..)
|
|
132
48
|
|
|
133
|
-
We work hard to respond to new RN releases, but they do occasionally break us. We will update this chart with each RN release, so that users can check to see what our "official" support is.
|
|
134
49
|
|
|
135
|
-
|
|
50
|
+
#### (2) Edit `AppDelegate` Code
|
|
136
51
|
|
|
137
|
-
|
|
52
|
+
**If you have `AppDelegate.swift` (>= RN 0.77)**
|
|
138
53
|
|
|
139
|
-
| Component | Prop(s) |
|
|
140
|
-
|-------------------------------------------------|------------------------------------------|
|
|
141
|
-
| `Image` | `source` |
|
|
142
|
-
| `MapView.Marker` <br />*(Requires [react-native-maps](https://github.com/lelandrichardson/react-native-maps) `>=O.3.2`)* | `image` |
|
|
143
|
-
| `ProgressViewIOS` | `progressImage`, `trackImage` |
|
|
144
|
-
| `TabBarIOS.Item` | `icon`, `selectedIcon` |
|
|
145
|
-
| `ToolbarAndroid` <br />*(React Native 0.21.0+)* | `actions[].icon`, `logo`, `overflowIcon` |
|
|
146
|
-
| `Video` | `source` |
|
|
147
54
|
|
|
148
|
-
|
|
55
|
+
<details><summary>If your project doesn't have bridging header, please create a file.</summary>
|
|
56
|
+
<p>
|
|
149
57
|
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
58
|
+
1. Open your project with Xcode (e.g. CodePushDemoApp.xcworkspace)
|
|
59
|
+
2. File → New → File from Template
|
|
60
|
+
3. Select 'Objective-C File' and click 'Next' and write any name as you like.
|
|
61
|
+
4. Then Xcode will ask you to create a bridging header file. Click 'Create'.
|
|
62
|
+
5. Delete the file created in step 3.
|
|
154
63
|
|
|
155
|
-
|
|
64
|
+
</p>
|
|
65
|
+
</details>
|
|
156
66
|
|
|
157
|
-
*Note: CodePush only works with Video components when using `require` in the source prop. For example:*
|
|
158
67
|
|
|
159
|
-
|
|
160
|
-
|
|
68
|
+
Add the following line to the bridging header file. (e.g. `CodePushDemoApp-Bridging-Header.h`)
|
|
69
|
+
```diff
|
|
70
|
+
+ #import <CodePush/CodePush.h>
|
|
161
71
|
```
|
|
162
72
|
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
73
|
+
Then, edit `AppDelegate.swift` like below.
|
|
74
|
+
|
|
75
|
+
```diff
|
|
76
|
+
@main
|
|
77
|
+
class AppDelegate: RCTAppDelegate {
|
|
78
|
+
override func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {
|
|
79
|
+
|
|
80
|
+
// ...
|
|
81
|
+
|
|
82
|
+
override func bundleURL() -> URL? {
|
|
83
|
+
#if DEBUG
|
|
84
|
+
RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
|
|
85
|
+
#else
|
|
86
|
+
- Bundle.main.url(forResource: "main", withExtension: "jsbundle")
|
|
87
|
+
+ CodePush.bundleURL()
|
|
88
|
+
#endif
|
|
89
|
+
}
|
|
90
|
+
}
|
|
169
91
|
```
|
|
170
92
|
|
|
171
|
-
As with all other React Native plugins, the integration experience is different for iOS and Android, so perform the following setup steps depending on which platform(s) you are targeting. Note, if you are targeting both platforms it is recommended to create separate CodePush applications for each platform.
|
|
172
93
|
|
|
173
|
-
|
|
94
|
+
**Or if you have `AppDelegate.mm`**
|
|
95
|
+
|
|
96
|
+
```diff
|
|
97
|
+
+ #import <CodePush/CodePush.h>
|
|
98
|
+
|
|
99
|
+
// ...
|
|
100
|
+
|
|
101
|
+
- (NSURL *)bundleURL
|
|
102
|
+
{
|
|
103
|
+
#if DEBUG
|
|
104
|
+
return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index"];
|
|
105
|
+
#else
|
|
106
|
+
- return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];
|
|
107
|
+
+ return [CodePush bundleURL];
|
|
108
|
+
#endif
|
|
109
|
+
}
|
|
110
|
+
|
|
111
|
+
@end
|
|
174
112
|
|
|
175
|
-
|
|
113
|
+
```
|
|
176
114
|
|
|
177
|
-
Then continue with installing the native module
|
|
178
|
-
* [iOS Setup](docs/setup-ios.md)
|
|
179
|
-
* [Android Setup](docs/setup-android.md)
|
|
180
115
|
|
|
116
|
+
### 3. Android Setup
|
|
181
117
|
|
|
182
|
-
|
|
118
|
+
#### (1) Edit `android/app/build.gradle`
|
|
183
119
|
|
|
184
|
-
|
|
120
|
+
Add the following line to the end of the file.
|
|
121
|
+
```diff
|
|
122
|
+
// ...
|
|
123
|
+
+ apply from: "../../node_modules/@bravemobile/react-native-code-push/android/codepush.gradle"
|
|
124
|
+
```
|
|
185
125
|
|
|
186
|
-
|
|
126
|
+
#### (2) Edit `MainApplication` Code
|
|
187
127
|
|
|
188
|
-
|
|
128
|
+
**If you have `MainApplication.kt` (>= RN 0.73)**
|
|
189
129
|
|
|
190
|
-
|
|
130
|
+
```diff
|
|
131
|
+
+ import com.microsoft.codepush.react.CodePush
|
|
191
132
|
|
|
192
|
-
|
|
133
|
+
class MainApplication : Application(), ReactApplication {
|
|
134
|
+
override val reactNativeHost: ReactNativeHost =
|
|
135
|
+
object : DefaultReactNativeHost(this) {
|
|
193
136
|
|
|
194
|
-
|
|
137
|
+
// ...
|
|
195
138
|
|
|
196
|
-
|
|
197
|
-
|
|
139
|
+
+ override fun getJSBundleFile(): String = CodePush.getJSBundleFile()
|
|
140
|
+
}
|
|
141
|
+
// ...
|
|
142
|
+
}
|
|
143
|
+
```
|
|
198
144
|
|
|
199
|
-
|
|
200
|
-
}
|
|
145
|
+
**Or if you have `MainApplication.java`**
|
|
201
146
|
|
|
202
|
-
|
|
203
|
-
|
|
147
|
+
```diff
|
|
148
|
+
// ...
|
|
149
|
+
+ import com.microsoft.codepush.react.CodePush
|
|
204
150
|
|
|
205
|
-
|
|
151
|
+
public class MainApplication extends Application implements ReactApplication {
|
|
206
152
|
|
|
207
|
-
|
|
208
|
-
|
|
153
|
+
private final ReactNativeHost mReactNativeHost =
|
|
154
|
+
new DefaultReactNativeHost(this) {
|
|
209
155
|
|
|
210
|
-
|
|
211
|
-
|
|
156
|
+
// ...
|
|
157
|
+
|
|
158
|
+
+ @Override
|
|
159
|
+
+ override fun getJSBundleFile(): String {
|
|
160
|
+
+ return CodePush.getJSBundleFile()
|
|
161
|
+
+ }
|
|
162
|
+
};
|
|
163
|
+
// ...
|
|
164
|
+
}
|
|
165
|
+
```
|
|
212
166
|
|
|
213
|
-
|
|
214
|
-
```
|
|
167
|
+
### 4. "CodePush-ify" Your App
|
|
215
168
|
|
|
216
|
-
|
|
169
|
+
The root component of your app should be wrapped with a higher-order component.
|
|
217
170
|
|
|
218
|
-
|
|
171
|
+
You should also pass configuration options, including the implementation of the `releaseHistoryFetcher` function.
|
|
172
|
+
This function is used to find the latest CodePush update within the `ReleaseHistoryInterface` data.
|
|
219
173
|
|
|
220
|
-
|
|
174
|
+
To enable this, you need to create a release history using the CLI tool and upload it to the remote.
|
|
175
|
+
(The following steps explain more about the CLI.)
|
|
221
176
|
|
|
222
|
-
|
|
223
|
-
import codePush from "react-native-code-push";
|
|
177
|
+
At runtime, the library fetches this information to keep the app up to date.
|
|
224
178
|
|
|
225
|
-
|
|
226
|
-
|
|
227
|
-
|
|
228
|
-
|
|
179
|
+
```typescript
|
|
180
|
+
import CodePush, {
|
|
181
|
+
ReleaseHistoryInterface,
|
|
182
|
+
UpdateCheckRequest,
|
|
183
|
+
} from "@bravemobile/react-native-code-push";
|
|
229
184
|
|
|
230
|
-
|
|
185
|
+
// ... MyApp Component
|
|
231
186
|
|
|
232
|
-
|
|
233
|
-
|
|
187
|
+
async function releaseHistoryFetcher(
|
|
188
|
+
updateRequest: UpdateCheckRequest,
|
|
189
|
+
): Promise<ReleaseHistoryInterface> {
|
|
234
190
|
|
|
235
|
-
|
|
236
|
-
|
|
191
|
+
// Fetch release history for current binary app version.
|
|
192
|
+
// You can implement how to fetch the release history freely. (Refer to the example app if you need a guide)
|
|
237
193
|
|
|
238
|
-
|
|
239
|
-
|
|
194
|
+
const {data: releaseHistory} = await axios.get<ReleaseHistoryInterface>(
|
|
195
|
+
`https://your.cdn.com/histories/${platform}/${identifier}/${updateRequest.app_version}.json`,
|
|
196
|
+
);
|
|
197
|
+
return releaseHistory;
|
|
198
|
+
}
|
|
240
199
|
|
|
241
|
-
|
|
200
|
+
export default CodePush({
|
|
201
|
+
checkFrequency: CodePush.CheckFrequency.MANUAL, // or something else
|
|
202
|
+
releaseHistoryFetcher: releaseHistoryFetcher,
|
|
203
|
+
})(MyApp);
|
|
242
204
|
|
|
243
|
-
|
|
205
|
+
```
|
|
244
206
|
|
|
245
|
-
|
|
207
|
+
> [!NOTE]
|
|
208
|
+
> The URL for fetching the release history should point to the resource location generated by the CLI tool.
|
|
246
209
|
|
|
247
|
-
```javascript
|
|
248
|
-
let codePushOptions = { checkFrequency: codePush.CheckFrequency.ON_APP_RESUME };
|
|
249
210
|
|
|
250
|
-
|
|
251
|
-
}
|
|
211
|
+
### 5. Configure the CLI Tool
|
|
252
212
|
|
|
253
|
-
|
|
254
|
-
|
|
213
|
+
> [!TIP]
|
|
214
|
+
> For a more detailed and practical example, refer to the `CodePushDemoApp` in `example` directory. ([link](https://github.com/Soomgo-Mobile/react-native-code-push/tree/master/Examples/CodePushDemoApp))
|
|
255
215
|
|
|
256
|
-
|
|
216
|
+
**(1) Create a `code-push.config.ts` file in the root directory of your project.**
|
|
257
217
|
|
|
258
|
-
|
|
259
|
-
|
|
218
|
+
Then, implement three functions to upload the bundle file and create/update the release history.
|
|
219
|
+
The CLI tool uses these functions to release CodePush updates and manage releases.
|
|
220
|
+
(These functions are not used at runtime by the library.)
|
|
260
221
|
|
|
261
|
-
|
|
262
|
-
}
|
|
222
|
+
You can copy and paste the following code and modify it as needed.
|
|
263
223
|
|
|
264
|
-
|
|
265
|
-
|
|
224
|
+
```typescript
|
|
225
|
+
import {
|
|
226
|
+
CliConfigInterface,
|
|
227
|
+
ReleaseHistoryInterface,
|
|
228
|
+
} from "@bravemobile/react-native-code-push";
|
|
266
229
|
|
|
267
|
-
|
|
230
|
+
const Config: CliConfigInterface = {
|
|
231
|
+
bundleUploader: async (
|
|
232
|
+
source: string,
|
|
233
|
+
platform: "ios" | "android",
|
|
234
|
+
identifier,
|
|
235
|
+
): Promise<{downloadUrl: string}> => {
|
|
236
|
+
// ...
|
|
237
|
+
},
|
|
268
238
|
|
|
269
|
-
|
|
270
|
-
|
|
239
|
+
getReleaseHistory: async (
|
|
240
|
+
targetBinaryVersion: string,
|
|
241
|
+
platform: "ios" | "android",
|
|
242
|
+
identifier,
|
|
243
|
+
): Promise<ReleaseHistoryInterface> => {
|
|
244
|
+
// ...
|
|
245
|
+
},
|
|
271
246
|
|
|
272
|
-
|
|
273
|
-
|
|
274
|
-
|
|
275
|
-
|
|
276
|
-
|
|
277
|
-
|
|
278
|
-
|
|
247
|
+
setReleaseHistory: async (
|
|
248
|
+
targetBinaryVersion: string,
|
|
249
|
+
jsonFilePath: string,
|
|
250
|
+
releaseInfo: ReleaseHistoryInterface,
|
|
251
|
+
platform: "ios" | "android",
|
|
252
|
+
identifier,
|
|
253
|
+
): Promise<void> => {
|
|
254
|
+
// ...
|
|
255
|
+
},
|
|
256
|
+
};
|
|
279
257
|
|
|
280
|
-
|
|
281
|
-
return (
|
|
282
|
-
<View>
|
|
283
|
-
<TouchableOpacity onPress={this.onButtonPress}>
|
|
284
|
-
<Text>Check for updates</Text>
|
|
285
|
-
</TouchableOpacity>
|
|
286
|
-
</View>
|
|
287
|
-
)
|
|
288
|
-
}
|
|
289
|
-
}
|
|
258
|
+
module.exports = Config;
|
|
290
259
|
|
|
291
|
-
MyApp = codePush(codePushOptions)(MyApp);
|
|
292
260
|
```
|
|
293
261
|
|
|
294
|
-
|
|
262
|
+
**`bundleUploader`**
|
|
263
|
+
- Implements a function to upload the bundle file.
|
|
264
|
+
- The `downloadUrl` returned by this function is recorded in `ReleaseHistoryInterface` data
|
|
265
|
+
and is used by the library runtime to download the bundle file from this URL.
|
|
266
|
+
- Used in the following cases:
|
|
267
|
+
- Creating a new CodePush update with the `release` command.
|
|
295
268
|
|
|
296
|
-
*NOTE: If you are using [Redux](http://redux.js.org) and [Redux Saga](https://redux-saga.js.org/), you can alternatively use the [react-native-code-push-saga](http://github.com/lostintangent/react-native-code-push-saga) module, which allows you to customize when `sync` is called in a perhaps simpler/more idiomatic way.*
|
|
297
269
|
|
|
298
|
-
|
|
270
|
+
**`getReleaseHistory`**
|
|
271
|
+
- Retrieves the release history of a specific binary app by fetching a JSON file or calling an API.
|
|
272
|
+
- Used in the following cases:
|
|
273
|
+
- Printing the release history with the `show-history` command.
|
|
274
|
+
- Loading existing release history during the `release` command.
|
|
275
|
+
- Fetching release history to modify information in the `update-history` command.
|
|
299
276
|
|
|
300
|
-
|
|
277
|
+
(Similar to the `releaseHistoryFetcher` function in the library runtime options.)
|
|
301
278
|
|
|
302
|
-
#### Google play
|
|
303
279
|
|
|
304
|
-
|
|
305
|
-
|
|
280
|
+
**`setReleaseHistory`**
|
|
281
|
+
- Uploads a JSON file located at `jsonFilePath` or calls an API using `releaseInfo` metadata.
|
|
282
|
+
- If using a JSON file, **modifying the existing file should be allowed.**
|
|
283
|
+
(Overwriting the file is recommended.)
|
|
284
|
+
- Used in the following cases:
|
|
285
|
+
- Creating a new release record for a new binary build with the `create-history` command.
|
|
286
|
+
- Appending a new record to an existing release history with the `release` command.
|
|
287
|
+
- Modifying an existing release history with the `update-history` command.
|
|
306
288
|
|
|
307
|
-
That fully allow CodePush as it updates just JS bundles and can't update native code part.
|
|
308
289
|
|
|
309
|
-
|
|
290
|
+
**(2) For `code-push.config.ts` (TypeScript) to work properly, you may need to update your `tsconfig.json`.**
|
|
310
291
|
|
|
311
|
-
|
|
292
|
+
```diff
|
|
293
|
+
{
|
|
294
|
+
"extends": "@react-native/typescript-config/tsconfig.json",
|
|
295
|
+
// ...
|
|
296
|
+
+ "ts-node": {
|
|
297
|
+
+ "compilerOptions": {
|
|
298
|
+
+ "module": "CommonJS",
|
|
299
|
+
+ "types": ["node"]
|
|
300
|
+
+ }
|
|
301
|
+
+ }
|
|
302
|
+
}
|
|
312
303
|
|
|
313
|
-
|
|
304
|
+
```
|
|
314
305
|
|
|
315
|
-
CodePush allows you to follow these rules in full compliance so long as the update you push does not significantly deviate your product from its original App Store approved intent.
|
|
316
306
|
|
|
317
|
-
|
|
307
|
+
## 🚀 CLI Tool Usage
|
|
318
308
|
|
|
319
|
-
>
|
|
309
|
+
> [!TIP]
|
|
310
|
+
> You can use `--help` command to see the available commands and options.
|
|
320
311
|
|
|
321
|
-
|
|
312
|
+
(interactive mode not supported yet)
|
|
322
313
|
|
|
323
|
-
|
|
314
|
+
### Commands
|
|
324
315
|
|
|
325
|
-
Once your app is configured and distributed to your users, and you have made some JS or asset changes, it's time to release them. The recommended way to release them is using the `release-react` command in the App Center CLI, which will bundle your JavaScript files, asset files, and release the update to the CodePush server.
|
|
326
316
|
|
|
327
|
-
|
|
317
|
+
#### `create-history`
|
|
328
318
|
|
|
329
|
-
|
|
319
|
+
Create a new release history for a specific binary app version.
|
|
320
|
+
- Use this command whenever you release a new binary app to the app store.
|
|
321
|
+
This ensures that the library runtime recognizes the binary app as the latest version and determines that no CodePush update is available for it.
|
|
330
322
|
|
|
331
|
-
|
|
332
|
-
|
|
323
|
+
**Example:**
|
|
324
|
+
- Create a new release history for the binary app version `1.0.0`.
|
|
333
325
|
|
|
334
|
-
appcenter codepush release-react -a <ownerName>/MyApp-iOS
|
|
335
|
-
appcenter codepush release-react -a <ownerName>/MyApp-Android
|
|
336
326
|
```
|
|
337
|
-
|
|
338
|
-
The `release-react` command enables such a simple workflow because it provides many sensible defaults (like generating a release bundle, assuming your app's entry file on iOS is either `index.ios.js` or `index.js`). However, all of these defaults can be customized to allow incremental flexibility as necessary, which makes it a good fit for most scenarios.
|
|
339
|
-
|
|
340
|
-
```shell
|
|
341
|
-
# Release a mandatory update with a changelog
|
|
342
|
-
appcenter codepush release-react -a <ownerName>/MyApp-iOS -m --description "Modified the header color"
|
|
343
|
-
|
|
344
|
-
# Release an update for an app that uses a non-standard entry file name, and also capture
|
|
345
|
-
# the sourcemap file generated by react-native bundle
|
|
346
|
-
appcenter codepush release-react -a <ownerName>/MyApp-iOS --entry-file MyApp.js --sourcemap-output ../maps/MyApp.map
|
|
347
|
-
|
|
348
|
-
# Release a dev Android build to just 1/4 of your end users
|
|
349
|
-
appcenter codepush release-react -a <ownerName>/MyApp-Android --rollout 25 --development true
|
|
350
|
-
|
|
351
|
-
# Release an update that targets users running any 1.1.* binary, as opposed to
|
|
352
|
-
# limiting the update to exact version name in the build.gradle file
|
|
353
|
-
appcenter codepush release-react -a <ownerName>/MyApp-Android --target-binary-version "~1.1.0"
|
|
354
|
-
|
|
327
|
+
npx code-push create-history --binary-version 1.0.0 --platform ios --identifier staging
|
|
355
328
|
```
|
|
356
329
|
|
|
357
|
-
|
|
358
|
-
|
|
359
|
-
For more details about how the `release-react` command works, as well as the various parameters it exposes, refer to the [CLI docs](https://github.com/microsoft/code-push/tree/v3.0.1/cli#releasing-updates-react-native). Additionally, if you would prefer to handle running the `react-native bundle` command yourself, and therefore, want an even more flexible solution than `release-react`, refer to the [`release` command](https://github.com/microsoft/code-push/tree/v3.0.1/cli#releasing-updates-general) for more details.
|
|
360
|
-
|
|
361
|
-
If you run into any issues, or have any questions/comments/feedback, you can ping us within the [#code-push](https://discord.gg/0ZcbPKXt5bWxFdFu) channel on Reactiflux, [e-mail us](mailto:codepushfeed@microsoft.com) and/or check out the [troubleshooting](#debugging--troubleshooting) details below.
|
|
362
|
-
|
|
363
|
-
*NOTE: CodePush updates should be tested in modes other than Debug mode. In Debug mode, React Native app always downloads JS bundle generated by packager, so JS bundle downloaded by CodePush does not apply.*
|
|
364
|
-
|
|
365
|
-
### Multi-Deployment Testing
|
|
366
|
-
|
|
367
|
-
In our [getting started](#getting-started) docs, we illustrated how to configure the CodePush plugin using a specific deployment key. However, in order to effectively test your releases, it is critical that you leverage the `Staging` and `Production` deployments that are auto-generated when you first created your CodePush app (or any custom deployments you may have created). This way, you never release an update to your end users that you haven't been able to validate yourself.
|
|
368
|
-
|
|
369
|
-
*NOTE: Our client-side rollback feature can help unblock users after installing a release that resulted in a crash, and server-side rollbacks (i.e. `appcenter codepush rollback`) allow you to prevent additional users from installing a bad release once it's been identified. However, it's obviously better if you can prevent an erroneous update from being broadly released in the first place.*
|
|
330
|
+
#### `show-history`
|
|
370
331
|
|
|
371
|
-
|
|
332
|
+
Display the release history for a specific binary app version.
|
|
372
333
|
|
|
373
|
-
1. Release a CodePush update to your `Staging` deployment using the `appcenter codepush release-react` command (or `appcenter codepush release` if you need more control)
|
|
374
334
|
|
|
375
|
-
|
|
335
|
+
**Example:**
|
|
336
|
+
- Show the release history for the binary app version `1.0.0`.
|
|
376
337
|
|
|
377
|
-
3. Promote the tested release from `Staging` to `Production` using the `appcenter codepush promote` command
|
|
378
|
-
|
|
379
|
-
4. Run your production/release build of your app, sync the update from the server and verify it works as expected
|
|
380
|
-
|
|
381
|
-
*NOTE: If you want to take a more cautious approach, you can even choose to perform a "staged rollout" as part of #3, which allows you to mitigate additional potential risk with the update (like did your testing in #2 touch all possible devices/conditions?) by only making the production update available to a percentage of your users (for example `appcenter codepush promote -a <ownerName>/<appName> -s Staging -d Production -r 20`). Then, after waiting for a reasonable amount of time to see if any crash reports or customer feedback comes in, you can expand it to your entire audience by running `appcenter codepush patch -a <ownerName>/<appName> Production -r 100`.*
|
|
382
|
-
|
|
383
|
-
You'll notice that the above steps refer to a "staging build" and "production build" of your app. If your build process already generates distinct binaries per "environment", then you don't need to read any further, since swapping out CodePush deployment keys is just like handling environment-specific config for any other service your app uses (like Facebook). However, if you're looking for examples (**including demo projects**) on how to setup your build process to accommodate this, then refer to the following sections, depending on the platform(s) your app is targeting:
|
|
384
|
-
|
|
385
|
-
* [Android](docs/multi-deployment-testing-android.md)
|
|
386
|
-
* [iOS](docs/multi-deployment-testing-ios.md)
|
|
387
|
-
|
|
388
|
-
|
|
389
|
-
### Dynamic Deployment Assignment
|
|
390
|
-
|
|
391
|
-
The above section illustrated how you can leverage multiple CodePush deployments in order to effectively test your updates before broadly releasing them to your end users. However, since that workflow statically embeds the deployment assignment into the actual binary, a staging or production build will only ever sync updates from that deployment. In many cases, this is sufficient, since you only want your team, customers, stakeholders, etc. to sync with your pre-production releases, and therefore, only they need a build that knows how to sync with staging. However, if you want to be able to perform A/B tests, or provide early access of your app to certain users, it can prove very useful to be able to dynamically place specific users (or audiences) into specific deployments at runtime.
|
|
392
|
-
|
|
393
|
-
In order to achieve this kind of workflow, all you need to do is specify the deployment key you want the current user to syncronize with when calling the `codePush` method. When specified, this key will override the "default" one that was provided in your app's `Info.plist` (iOS) or `MainActivity.java` (Android) files. This allows you to produce a build for staging or production, that is also capable of being dynamically "redirected" as needed.
|
|
394
|
-
|
|
395
|
-
```javascript
|
|
396
|
-
// Imagine that "userProfile" is a prop that this component received
|
|
397
|
-
// which includes the deployment key that the current user should use.
|
|
398
|
-
codePush.sync({ deploymentKey: userProfile.CODEPUSH_KEY });
|
|
399
338
|
```
|
|
400
|
-
|
|
401
|
-
With that change in place, now it's just a matter of choosing how your app determines the right deployment key for the current user. In practice, there are typically two solutions for this:
|
|
402
|
-
|
|
403
|
-
1. Expose a user-visible mechanism for changing deployments at any time. For example, your settings page could have a toggle for enabling "beta" access. This model works well if you're not concerned with the privacy of your pre-production updates, and you have power users that may want to opt-in to earlier (and potentially buggy) updates at their own will (kind of like Chrome channels). However, this solution puts the decision in the hands of your users, which doesn't help you perform A/B tests transparently.
|
|
404
|
-
|
|
405
|
-
2. Annotate the server-side profile of your users with an additional piece of metadata that indicates the deployment they should sync with. By default, your app could just use the binary-embedded key, but after a user has authenticated, your server can choose to "redirect" them to a different deployment, which allows you to incrementally place certain users or groups in different deployments as needed. You could even choose to store the server-response in local storage so that it becomes the new default. How you store the key alongside your user's profiles is entirely up to your authentication solution (for example Auth0, Firebase, custom DB + REST API), but is generally pretty trivial to do.
|
|
406
|
-
|
|
407
|
-
*NOTE: If needed, you could also implement a hybrid solution that allowed your end-users to toggle between different deployments, while also allowing your server to override that decision. This way, you have a hierarchy of "deployment resolution" that ensures your app has the ability to update itself out-of-the-box, your end users can feel rewarded by getting early access to bits, but you also have the ability to run A/B tests on your users as needed.*
|
|
408
|
-
|
|
409
|
-
Since we recommend using the `Staging` deployment for pre-release testing of your updates (as explained in the previous section), it doesn't neccessarily make sense to use it for performing A/B tests on your users, as opposed to allowing early-access (as explained in option #1 above). Therefore, we recommend making full use of custom app deployments, so that you can segment your users however makes sense for your needs. For example, you could create long-term or even one-off deployments, release a variant of your app to it, and then place certain users into it in order to see how they engage.
|
|
410
|
-
|
|
411
|
-
```javascript
|
|
412
|
-
// #1) Create your new deployment to hold releases of a specific app variant
|
|
413
|
-
appcenter codepush deployment add -a <ownerName>/<appName> test-variant-one
|
|
414
|
-
|
|
415
|
-
// #2) Target any new releases at that custom deployment
|
|
416
|
-
appcenter codepush release-react -a <ownerName>/<appName> -d test-variant-one
|
|
339
|
+
npx code-push show-history --binary-version 1.0.0 --platform ios --identifier staging
|
|
417
340
|
```
|
|
418
341
|
|
|
419
|
-
|
|
420
|
-
|
|
421
|
-
---
|
|
422
|
-
|
|
423
|
-
## API Reference
|
|
424
|
-
|
|
425
|
-
* [JavaScript API](docs/api-js.md)
|
|
426
|
-
* [Objective-C API Reference (iOS)](docs/api-ios.md)
|
|
427
|
-
* [Java API Reference (Android)](docs/api-android.md)
|
|
428
|
-
|
|
429
|
-
### Example Apps / Starters
|
|
430
|
-
|
|
431
|
-
The React Native community has graciously created some awesome open source apps that can serve as examples for developers that are getting started. The following is a list of OSS React Native apps that are also using CodePush, and can therefore be used to see how others are using the service:
|
|
432
|
-
|
|
433
|
-
* [F8 App](https://github.com/fbsamples/f8app) - The official conference app for [F8 2016](https://www.fbf8.com/).
|
|
434
|
-
* [Feline for Product Hunt](https://github.com/arjunkomath/Feline-for-Product-Hunt) - An Android client for Product Hunt.
|
|
435
|
-
* [GeoEncoding](https://github.com/LynxITDigital/GeoEncoding) - An app by [Lynx IT Digital](https://digital.lynxit.com.au) which demonstrates how to use numerous React Native components and modules.
|
|
436
|
-
* [Math Facts](https://github.com/Khan/math-facts) - An app by Khan Academy to help memorize math facts more easily.
|
|
437
|
-
|
|
438
|
-
Additionally, if you're looking to get started with React Native + CodePush, and are looking for an awesome starter kit, you should check out the following:
|
|
439
|
-
|
|
440
|
-
* [Pepperoni](http://getpepperoni.com/)
|
|
342
|
+
#### `release`
|
|
441
343
|
|
|
442
|
-
|
|
344
|
+
Release a CodePush update for a specific binary app version.
|
|
345
|
+
- This command creates a CodePush bundle file, uploads it, and updates the release history with the new release information.
|
|
443
346
|
|
|
444
|
-
|
|
347
|
+
**Example:**
|
|
348
|
+
- Release a CodePush update `1.0.1` targeting the binary app version `1.0.0`.
|
|
445
349
|
|
|
446
|
-
|
|
447
|
-
|
|
448
|
-
|
|
449
|
-
|
|
450
|
-
|
|
451
|
-
|
|
452
|
-
|
|
453
|
-
|
|
454
|
-
Note that by default, React Native logs are disabled on iOS in release builds, so if you want to view them in a release build, you need to make the following changes to your `AppDelegate.m` file:
|
|
455
|
-
|
|
456
|
-
1. Add an `#import <React/RCTLog.h>` statement. For RN < v0.40 use: `#import "RCTLog.h"`
|
|
457
|
-
|
|
458
|
-
2. Add the following statement to the top of your `application:didFinishLaunchingWithOptions` method:
|
|
350
|
+
```
|
|
351
|
+
npx code-push release --target-binary-version 1.0.0 --app-version 1.0.1 \
|
|
352
|
+
--platform ios --identifier staging --entry-file index.js \
|
|
353
|
+
--mandatory true
|
|
354
|
+
```
|
|
355
|
+
- `--target-binary-version`: The version of the binary app that the CodePush update is targeting.
|
|
356
|
+
- `--app-version`: The version of the CodePush update itself.
|
|
459
357
|
|
|
460
|
-
|
|
461
|
-
|
|
462
|
-
```
|
|
358
|
+
> [!IMPORTANT]
|
|
359
|
+
> `--app-version` should be greater than `--target-binary-version` (SemVer comparison).
|
|
463
360
|
|
|
464
|
-
Now you'll be able to see CodePush logs in either debug or release mode, on both iOS or Android. If examining the logs don't provide an indication of the issue, please refer to the following common issues for additional resolution ideas:
|
|
465
361
|
|
|
466
|
-
|
|
467
|
-
|-----------------|-------------------|
|
|
468
|
-
| Compilation Error | Double-check that your version of React Native is [compatible](#supported-react-native-platforms) with the CodePush version you are using. |
|
|
469
|
-
| Network timeout / hang when calling `sync` or `checkForUpdate` in the iOS Simulator | Try resetting the simulator by selecting the `Simulator -> Reset Content and Settings..` menu item, and then re-running your app. |
|
|
470
|
-
| Server responds with a `404` when calling `sync` or `checkForUpdate` | Double-check that the deployment key you added to your `Info.plist` (iOS), `build.gradle` (Android) or that you're passing to `sync`/`checkForUpdate`, is in fact correct. You can run `appcenter codepush deployment list <ownerName>/<appName> --displayKeys` to view the correct keys for your app deployments. |
|
|
471
|
-
| Update not being discovered | Double-check that the version of your running app (like `1.0.0`) matches the version you specified when releasing the update to CodePush. Additionally, make sure that you are releasing to the same deployment that your app is configured to sync with. |
|
|
472
|
-
| Update not being displayed after restart | If you're not calling `sync` on app start (like within `componentDidMount` of your root component), then you need to explicitly call `notifyApplicationReady` on app start, otherwise, the plugin will think your update failed and roll it back. |
|
|
473
|
-
| I've released an update for iOS but my Android app also shows an update and it breaks it | Be sure you have different deployment keys for each platform in order to receive updates correctly |
|
|
474
|
-
| I've released new update but changes are not reflected | Be sure that you are running app in modes other than Debug. In Debug mode, React Native app always downloads JS bundle generated by packager, so JS bundle downloaded by CodePush does not apply.
|
|
475
|
-
| No JS bundle is being found when running your app against the iOS simulator | By default, React Native doesn't generate your JS bundle when running against the simulator. Therefore, if you're using `[CodePush bundleURL]`, and targetting the iOS simulator, you may be getting a `nil` result. This issue will be fixed in RN 0.22.0, but only for release builds. You can unblock this scenario right now by making [this change](https://github.com/facebook/react-native/commit/9ae3714f4bebdd2bcab4d7fdbf23acebdc5ed2ba) locally.
|
|
362
|
+
#### `update-history`
|
|
476
363
|
|
|
477
|
-
|
|
364
|
+
Update the release history for a specific CodePush update.
|
|
365
|
+
- Use the `--enable` option to disable a specific release for rollback. (or enable it)
|
|
366
|
+
- Use the `--mandatory` option to make the update as mandatory or optional.
|
|
478
367
|
|
|
479
|
-
|
|
368
|
+
**Example:**
|
|
369
|
+
- Rollback the CodePush update `1.0.1` (targeting the binary app version `1.0.0`).
|
|
480
370
|
|
|
481
|
-
|
|
482
|
-
|
|
371
|
+
```
|
|
372
|
+
npx code-push update-history --target-binary-version 1.0.0 --app-version 1.0.1 \
|
|
373
|
+
--platform ios --identifier staging \
|
|
374
|
+
--enable false
|
|
375
|
+
```
|
|
483
376
|
|
|
484
|
-
|
|
377
|
+
#### `bundle`
|
|
485
378
|
|
|
486
|
-
|
|
379
|
+
Create a CodePush bundle file.
|
|
487
380
|
|
|
488
|
-
|
|
381
|
+
**Example:**
|
|
382
|
+
```
|
|
383
|
+
npx code-push bundle --platform android --entry-file index.js
|
|
384
|
+
```
|
|
489
385
|
|
|
490
|
-
|
|
386
|
+
By default, the bundle file is created in the `/build/bundleOutput` directory.
|
|
491
387
|
|
|
492
|
-
|
|
388
|
+
(The file name represents a hash value of the bundle content.)
|