[SDK43][iOS] Production app is rendered twice, breaking AsyncStorage, RNFirebase, ...

[Yonom]

Summary

We are experiencing a series of strange issues after upgrading to SDK 43.

They all seem to stem from the fact that the app is mounted twice on launch in production builds, causing all hooks and everything to be run twice.

These issues are severe enough to make our app unusable around 90% of the time (some issues happen consistently, while others come and go). Moreover, the issues stem from race conditions that are super hard to debug, reproduce or work around.

Managed or bare workflow? If you have ios/ or android/ directories in your project, the answer is bare!

bare

What platform(s) does this occur on?

iOS

SDK Version (managed workflow only)

43.0.0

Environment

❯ expo diagnostics                    

  Expo CLI 4.12.11 environment info:
    System:
      OS: macOS 11.6
      Shell: 5.8 - /bin/zsh
    Binaries:
      Node: 16.13.0 - /usr/local/Cellar/node@16/16.13.0/bin/node
      Yarn: 1.22.17 - /usr/local/bin/yarn
      npm: 8.1.0 - /usr/local/Cellar/node@16/16.13.0/bin/npm
      Watchman: 2021.10.18.00 - /usr/local/bin/watchman
    Managers:
      CocoaPods: 1.11.2 - /usr/local/bin/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 21.0.1, iOS 15.0, macOS 12.0, tvOS 15.0, watchOS 8.0
      Android SDK:
        API Levels: 23, 24, 28, 29, 30
        Build Tools: 28.0.3, 29.0.2, 30.0.2, 30.0.3, 31.0.0, 31.0.0, 31.0.0, 31.0.0, 31.0.0
        System Images: android-29 | Google APIs Intel x86 Atom, android-29 | Google Play Intel x86 Atom, android-30 | Google APIs Intel x86 Atom, android-30 | Google Play Intel x86 Atom
    IDEs:
      Android Studio: 2020.3 AI-203.7717.56.2031.7784292
      Xcode: 13.1/13A1030d - /usr/bin/xcodebuild
    npmPackages:
      expo: ^43.0.0 => 43.0.1 
      react: 17.0.1 => 17.0.1 
      react-dom: 17.0.1 => 17.0.1 
      react-native: 0.64.2 => 0.64.2 
      react-native-web: 0.17.1 => 0.17.1 
    npmGlobalPackages:
      expo-cli: 4.12.11
    Expo Workflow: bare

Reproducible demo or steps to reproduce from a blank project

• Open Flipper Logs (I used DeviceLogs@0.117.0) or something else to see the release app log output

Test 1 (baseline, expected behavior)

• Create a new SDK 42 project
  • expo init -y,
  • edit package.json to downgrade expo to ~42.0.0
  • yarn install
  • expo doctor, fix all mismatches
• expo run:ios --configuration Release
• Open the app in simulator and check logs in flipper

✅ Output looks alright.

Test 2 (upgrade to SDK 43, this is where the issues begin)

• expo upgrade
• rm -r ./ios
• expo run:ios --configuration Release
• Open the app in simulator and check logs in flipper

🤔 There are two instances of the application being started. There are warnings regarding Unbalanced calls start/end for tag X.

Test 3 (add app_open useEffect hook)

• Open App.js and apply the following diff

  
  -import React from 'react';
  +import React, { useEffect } from 'react';
  import { StyleSheet, Text, View } from 'react-native';
  
  export default function App() {

• useEffect(() => {

• // log something only once

• console.log('app_open');

• return () => console.log('app_close');

• }, []);

• expo run:ios --configuration Release

• Open the app in simulator and check logs in flipper

:x: Our useEffect is run twice, app_open is logged twice. (Expectation: app_open is logged only once)

:x: The first useEffect is not cleaned up before the second one is run; there is no app_close event logged.

Test 4 (react-native-firebase)

(this is an example of a module that breaks because of these changes)

• Setup a firebase project and setup firestore, create an empty document in path test/doc and make sure everyone has access to the document.
• Add @react-native-firebase/app and setup the corresponding config plugin + Google-Info.plist
• Add @ract-native-firebase/firestore
• Open App.js and apply the following diff

-import React from 'react';
+import React, { useEffect, useState } from 'react';
 import { StyleSheet, Text, View } from 'react-native';
+import firebaseFirestore from '@react-native-firebase/firestore';
+
+const firestore = firebaseFirestore();

 export default function App() {
+  const [success, setSuccess] = useState(false);
+  useEffect(() => {
+    console.log('subscribed');
+    firestore.doc(`test/doc`).onSnapshot(() => {
+      console.log('got snapshot');
+      setSuccess(true);
+    });
+  }, []);
+
   return (
     <View style={styles.container}>
-      <Text>Open up App.js to start working on your app!</Text>
+      {success 
+        ? <Text>Got snapshot</Text>
+        : <Text>Waiting for snapshot</Text>
+      }

• expo run:ios --configuration Release
• Open the app in simulator and check logs in flipper

❌ Sometimes, when a race condition happens, the first invisible app instance gets the snapshot and the second app is stuck in "Waiting for snapshot" state. Other times, the order is reversed and the second app gets the snapshot, resulting in the expected behavior. (This is somewhat tricky to reproduce, the timings seem to be different based on the device model, app size, jsRuntime, ...)

👎 Bad case:

👍 Good case:

Other libraries that have issues

We are experiencing weird race conditions from

• @react-native-async-storage/async-storage (await AsyncStorage.getItem(key); sometimes never resolving on first app launch),
• mixpanel-react-native (internal SQLite table errors) and probably more to be discovered.

Another interesting log we get is EXUpdates: Could not emit noUpdateAvailable event. Did you set the bridge property on the controller singleton?

[RodolfoGS]

Test this PR, maybe is related https://github.com/expo/expo/pull/15019 I fixed an issue with notifications on iOS with that. I created a patch here: https://github.com/expo/expo/issues/14078#issuecomment-959742553

[Kudo]

please try to upgrade expo-updates@0.10.12 with #15019 change and see if it fix the issue for you. thanks for reporting this issue to us.

[Yonom]

@Kudo Yes, I can confirm that hooks are no longer executed twice. Thanks for the fix 👍

[Kudo]

i'm glad to hear that. thank you, @Yonom!