Skip to content

Latest commit

 

History

History
9 lines (9 loc) · 2.75 KB

ExpoNotes.md

File metadata and controls

9 lines (9 loc) · 2.75 KB
Raw

Dear team - Learned lessons regarding Expo:

  • While Apple and Android use the app.json “buildNumber” / “versionCode” values to know when a new build submitted to the store is newer than the old build, updating this number otherwise is apparently bad. Over the air (OTA) updates to iOS will not work if the update’s “buildNumber” (for Apple) has changed from whatever the is being sold by the store.
  • OTA Updates allow you to update both your javascript/js dependencies, and assets. BUT… even if you include a new asset for the splash screen, you cannot change the splash screen image’s name, at least. I’m still determining if you can change the image at all or if they hash it to know when an image with the same name but different content has been submitted. Right now our new splash screen is not available in production because of this issue. The update to the splash screen briefly broke production.
  • Symptoms of these breaking changes in the app.json file after publishing to production is when launch the app store version of the app, it opens and closes.
  • More info here: https://docs.expo.io/workflow/publishing/#some-native-configuration-cant-be-updated-by
  • Using expo build:ios or expo build:android inherently does a expo publish which is confusing if you are trying to create a new APK or IPA file for submission to the app stores - the release I was building was incompatible with the current app store versions. But because of the OTA update magic, when I did expo build:ios the resulting and invisible expo publish that that caused immediately updated the production build for the iOS app to a won’t-work-in-current-production app bundle.
  • It is tempting to then use the command line switch expo build:ios --no-publish as this would seem to be a sensible way to avoid the issue… yet then strangely in Testflight, the app never appeared to be updated…
  • So I realized that the way it works is that when you expo build:ios or expo build:android it does that expo publish first so that the IPA or APK file will have a bundle to point to on the expo servers. I had thought the build process was wrapping up a snapshot of the code into the IPA or APK file independent of any published releases, but the IPA or APK actually has to refer to a published release or it won’t work.
  • A lot of the issues here stem from the fact that the current app store apps were built using Expo’s default release channel. I got around this last night in my build by using a new production release channel. expo build:ios --release-channel production2020.1 - and if a future IPA or APK needed to be built and submitted that included content that would break then-current production releases, one could use a new release channel such as expo build:ios --release-channel production2020.2