[iOS] sqlite3 build errors with expo-updates

[martinezguillaume]

Minimal reproducible example

https://github.com/martinezguillaume/expo-sqlite3-bug

What platform(s) does this occur on?

iOS

Where did you reproduce the issue?

in a development build

Summary

Hello 👋
When building iOS with expo-updates and an other Pod that is using an other lib of SQLite3. It produces an error when building.

❌  (ios/Pods/Headers/Public/sqlite3/sqlite3.h:7345:9)

  7343 |   /* The methods above are in versions 1 through 3 of the sqlite_module object.
  7344 |   ** Those below are for version 4 and greater. */
> 7345 |   int (*xIntegrity)(sqlite3_vtab *pVTab, const char *zSchema,
       |         ^ 'sqlite3_module::xIntegrity' from module 'sqlite3.sqlite3' is not present in definition of 'struct sqlite3_module' provided earlier
  7346 |                     const char *zTabName, int mFlags, char **pzErr);
  7347 | };
  7348 |


❌  (/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator17.5.sdk/usr/include/sqlite3ext.h:36:8)

  34 | ** libraries!
  35 | */
> 36 | struct sqlite3_api_routines {
     |        ^ type 'struct sqlite3_api_routines' has incompatible definitions in different translation units
  37 |   void * (*aggregate_context)(sqlite3_context*,int nBytes);
  38 |   int  (*aggregate_count)(sqlite3_context*);
  39 |   int  (*bind_blob)(sqlite3_stmt*,int,const void*,int n,void(*)(void*));

after investigation, it seems that expo-updates has a built-in sqlite3 and is importing it. But in my case, the AmazonChimeSDK uses directly the iOS built-in SQLite3 and is importing it causing a SQLite3 mismatch version.
I only find this issue that was a little bit related, but nothing more...
I hope that someone will be able to help me, I'll continue to work on it

Steps to reproduce :

• Clone https://github.com/martinezguillaume/expo-sqlite3-bug
• Run npm run ios

Environment

expo-env-info 1.2.0 environment info:
System:
OS: macOS 14.5
Shell: 5.9 - /bin/zsh
Binaries:
Node: 20.12.2 - ~/.nvm/versions/node/v20.12.2/bin/node
Yarn: 1.22.17 - /opt/homebrew/bin/yarn
npm: 10.5.0 - ~/.nvm/versions/node/v20.12.2/bin/npm
Watchman: 2024.07.15.00 - /opt/homebrew/bin/watchman
Managers:
CocoaPods: 1.15.2 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 23.5, iOS 17.5, macOS 14.5, tvOS 17.5, visionOS 1.2, watchOS 10.5
IDEs:
Android Studio: 2023.2 AI-232.10227.8.2321.11479570
Xcode: 15.4/15F31d - /usr/bin/xcodebuild
npmPackages:
expo: ~51.0.21 => 51.0.21
expo-router: ~3.5.18 => 3.5.18
react: 18.2.0 => 18.2.0
react-dom: 18.2.0 => 18.2.0
react-native: 0.74.3 => 0.74.3
react-native-web: ~0.19.10 => 0.19.12
npmGlobalPackages:
eas-cli: 10.2.1
Expo Workflow: bare

Expo Doctor Diagnostics

✔ Check Expo config for common issues
✔ Check package.json for common issues
✔ Check dependencies for packages that should not be installed directly
✔ Check npm/ yarn versions
✔ Check for issues with metro config
✔ Check for common project setup issues
✔ Check Expo config (app.json/ app.config.js) schema
✔ Check native tooling versions
✔ Check for legacy global CLI installed locally
✔ Check that packages match versions required by installed Expo SDK
✔ Check that native modules do not use incompatible support packages
✔ Check that native modules use compatible support package versions for installed Expo SDK

Didn't find any issues with the project!

[martinezguillaume]

Little update
From my understanding there are, for the moment, no straight forward solution to this problem.
I found 3 possibilities :

• Fork the pod that is using the builtin sqlite and make it use the sql from the pod, like that (for me, forking a pod dependency was a real pain, I didn't even succeed to link it properly in my ios project)
• Work on the pod that is using the builtin sqlite and propose a solution like SQLite.swift (thanks simolus3). So, to add a standalone subspec that use sqlite3 from the pod and not from the builtin system (like this)
• Patch the pod that is using the sqlite3 from the pod (here expo-updates), and make it use a sqlite version that is aligned with the sqlite system version.
  You can find the sqlite system version inside /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator17.5.sdk/usr/include/sqlite3.h you will have something like this

#define SQLITE_VERSION        "3.43.2"
#define SQLITE_VERSION_NUMBER 3043002
#define SQLITE_SOURCE_ID      "2023-10-10 13:08:14 1b37c146ee9ebb7acd0160c0ab1fd11017a419fa8a3187386ed8cb32b709aapl"

For me, I'm using the last solution to patch expo-updates, my patch look like this
expo-updates+0.25.20.patch

diff --git a/node_modules/expo-updates/ios/EXUpdates.podspec b/node_modules/expo-updates/ios/EXUpdates.podspec
index 92aacaa..407d744 100644
--- a/node_modules/expo-updates/ios/EXUpdates.podspec
+++ b/node_modules/expo-updates/ios/EXUpdates.podspec
@@ -28,7 +28,7 @@ Pod::Spec.new do |s|
   s.dependency 'EXManifests'
   s.dependency 'EASClient'
   s.dependency 'ReachabilitySwift'
-  s.dependency 'sqlite3', '~> 3.45.3+1'
+  s.dependency 'sqlite3', '3.43.1'
 
   unless defined?(install_modules_dependencies)
     # `install_modules_dependencies` is defined from react_native_pods.rb.

It can be dangerous because you'll miss features of the newest sqlite version but in this case and from my understanding, only expo-sqlite are using it, and since I'll not use it'll be fine

Sorry for all this infos, but I wanted to documente everything because this is a complex subject and I'm very surprised that it is not a common issue. Sometimes, I'm thinking that maybe I'm missing something....

[Kudo]

thanks for sharing this investigation. that's a known issue where on ios all source code is built together by default. all sqlite symbols should be aligned. we use the newer sqlite in expo-updates because of expo-sqlite.
i have some idea and would resolve the issue in sdk 52.

[expo-bot]

Thank you for filing this issue!
This comment acknowledges we believe this may be a bug and there’s enough information to investigate it.
However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

[mirague]

@martinezguillaume Thanks for providing your workaround, this helped us continue building on EAS when we ran into this exact same issue with expo-updates

[Kudo]

the issue should be resolved from sdk 52 from the effort of #30824 and #30826. i'm going to close this issue. let me know if it is still a problem on sdk 52.