1 | # Developing expo-updates
|
2 |
|
3 | This document provides some tips and configuration settings that can help when developing expo-updates locally.
|
4 |
|
5 | ## Environment
|
6 |
|
7 | While it's possible to develop expo-updates in the context of Expo Go, it's usually easier to use a bare app. If you run `expo init` and choose either of the bare templates, they will have come with the latest version of expo-updates installed and pre-configured.
|
8 |
|
9 | There are a few ways to hook up your local copy of expo-updates to your test app. If you're not importing anything from expo-updates in your JS, you may be able to use `yarn link`, which is the most straightforward solution.
|
10 |
|
11 | Unfortunately, Metro doesn't support symlinks (at the time of this writing) so if you do need to use the Updates JS module methods in your app, `yarn link` will not suffice. A couple of suggestions are:
|
12 | - in package.json, replace the expo-updates dependency with: `"expo-updates": "file:/path/to/expo/expo/packages/expo-updates"`. You'll need to run `yarn --force` each time you make changes to your expo-updates source to make yarn copy them into node_modules.
|
13 | - if you don't want to wait for yarn to run each time, you can just manually copy expo-updates into node_modules each time you make a change.
|
14 |
|
15 | Feel free to add other options here!
|
16 |
|
17 | ## Configuration
|
18 |
|
19 | Configuration for iOS should be done in Expo.plist. On Android, most options can be configured in AndroidManifest.xml.
|
20 |
|
21 | - Make sure that the URL (`EXUpdatesURL`, `expo.modules.updates.EXPO_UPDATE_URL`) is properly set.
|
22 | - Make sure that one of either the SDK version (`EXUpdatesSDKVersion`, `expo.modules.updates.EXPO_SDK_VERSION`) or runtime version (`EXUpdatesRuntimeVersion`, `expo.modules.updates.EXPO_RUNTIME_VERSION`) is also properly set.
|
23 |
|
24 | ### Ignore Embedded Update
|
25 |
|
26 | If you are using expo-updates to test a server you're developing, you may want to tell expo-updates to ignore the embedded update. Otherwise, each time you make a new build, it will create a new bundle with a new creation time and will refuse to load any updates published previously.
|
27 |
|
28 | You can do tell expo-updates to ignore the embedded bundle and force a remote update by setting `EXUpdatesHasEmbeddedUpdate` and `expo.modules.updates.HAS_EMBEDDED_UPDATE` to false.
|
29 |
|
30 | ### New Manifest Format
|
31 |
|
32 | To test the new EAS update manifest format, set `EXUpdatesUsesLegacyManifest` and `expo.modules.updates.EXPO_LEGACY_MANIFEST` to false.
|
33 |
|
34 | ### Additional Headers
|
35 |
|
36 | If you want any additional headers to be sent in manifest requests, you can add these to a map under the key `EXUpdatesRequestHeaders` on iOS, or `requestHeaders` on Android (currently, this can't be configured in AndroidManifest.xml and you need to use the `UpdatesController.initialize(Context context, Map<String, Object> configuration)` method in MainApplication.java).
|
37 |
|
38 | ## Making a Build
|
39 |
|
40 | By default, expo-updates is only enabled in release builds for bare apps, and debug builds load from the local Metro server instead.
|
41 |
|
42 | To make a release build in Xcode, choose the following menu options: Xcode → Product → Scheme → Edit Scheme → Change "Debug" to "Release" in the Run configuration; then press "Run" in the main Xcode window.
|
43 |
|
44 | To make a release build of your Android app, run `react-native run-android --variant Release` from your project root.
|
45 |
|
46 | ### Enable expo-updates in Debug Mode
|
47 |
|
48 | Sometimes you may want to enable expo-updates in a debug build -- for example, if you want to step through the code with breakpoints.
|
49 |
|
50 | To do this, first follow the directions above to [Ignore Embedded Update](#ignore-embedded-update).
|
51 |
|
52 | In Xcode's Bundle React Native code and images Build Phase, add the line `export FORCE_BUNDLING=true` to the top, and in android/app/build.gradle, add `bundleInDebug: true` to `project.ext.react`.
|
53 |
|
54 | Then, in AppDelegate.m, find both instances of `#ifdef DEBUG` and delete or comment out the following lines:
|
55 | ```objective-c
|
56 | // #ifdef DEBUG
|
57 | // ... <- delete or comment out these lines
|
58 | // #else
|
59 | ... other stuff
|
60 | // #endif <- and this one
|
61 | ```
|
62 |
|
63 | Similarly, in MainApplication.java, find the instances of `BuildConfig.DEBUG` and delete or comment out all paths where `BuildConfig.DEBUG` evaluates to `true`, like so:
|
64 | ```java
|
65 | public boolean getUseDeveloperSupport() {
|
66 | // return BuildConfig.DEBUG;
|
67 | return false;
|
68 | }
|
69 |
|
70 | // if (BuildConfig.DEBUG) {
|
71 | // return something; <- delete or comment out these lines
|
72 | // } else {
|
73 | return somethingElse;
|
74 | // } <- and this one
|
75 |
|
76 | ...
|
77 |
|
78 | // if (!BuildConfig.DEBUG) { <- and this one
|
79 | UpdatesController.initialize(this);
|
80 | // } <- and this one
|
81 | ```
|
82 |
|
83 | Now you can make a debug build of your app which behaves as if it were a release build (but without an embedded update).
|
84 |
|
85 | ## Troubleshooting
|
86 |
|
87 | If expo-updates is not loading an update you expect it to, check that:
|
88 | - the creation time of the update you're trying to load is newer than the embedded bundle, or you've configured expo-updates to [ignore the embedded bundle](#ignore-embedded-update).
|
89 | - the SDK or runtime version configured in Expo.plist or AndroidManifest.xml matches the one in the manifest you're trying to load.
|
90 |
|
91 | TODO: add more common scenarios here as they come up.
|