SyncEngine init crashes in Swift runtime while de-duping synchronized tables

[iSapozhnik]

Description

Our macOS app crashes at runtime while initializing SQLiteData.SyncEngine.

The project builds successfully, but the app crashes during SyncEngine.init, before startup completes. Cleaning DerivedData and doing a clean build does not change the behavior. I would greatly appreciate any suggestions!

The crash appears to occur in SyncEngine.swift while de-duping synchronized tables:

let allTables = OrderedSet((tables + privateTables).map(HashableSynchronizedTable.init))
  .map(\.type)

The app does not reach the log immediately after SyncEngine initialization.

Possibly relevant Tuist package product typing:

let packageSettings = PackageSettings(
  productTypes: [
    "SQLiteData": .staticFramework,
  ]
)

Dependency:

.package(url: "https://github.com/pointfreeco/sqlite-data", from: "1.6.3")

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• I have determined whether this bug is also reproducible in a vanilla GRDB project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

SyncEngine initializes successfully for the configured synchronized tables, and app startup continues.

Actual behavior

The macOS app crashes during SyncEngine.init.

Xcode reports:

Thread 1: EXC_BAD_ACCESS (code=1, address=0x0)

Tables passed to SyncEngine:

try SyncEngine(
  for: database,
  tables: RewriteMode.self, RewriteModeSeedDeletion.self, Snippet.self,
  privateTables: RewriteHistoryEntry.self,
  containerIdentifier: containerIdentifier,
  startImmediately: startImmediately,
  logger: logger
)

Table shape:

• RewriteMode: @Table("rewriteModes"), primary key String
• RewriteModeSeedDeletion: @Table("rewriteModeSeedDeletions"), primary key String
• Snippet: @Table("snippets"), primary key String
• RewriteHistoryEntry: @Table, primary key UUID

Stack:

Thread 0 Crashed:
swift::TargetMetadata<swift::InProcess>::getTypeContextDescriptor() const
swift::SubstGenericParametersFromMetadata::SubstGenericParametersFromMetadata(...)
swift_getAssociatedTypeWitnessSlowImpl(...)
Collection.map<A, B>(_:)
SyncEngine.init(container:defaultZone:defaultSyncEngines:userDatabase:logger:delegate:tables:privateTables:)
SyncEngine.__allocating_init(container:defaultZone:defaultSyncEngines:userDatabase:logger:delegate:tables:privateTables:)
SyncEngine.__allocating_init<each A, B>(for:tables:privateTables:containerIdentifier:defaultZone:startImmediately:delegate:logger:)
CloudKitSyncService.init(database:containerIdentifier:startImmediately:)
PersistenceBootstrap.makePersistenceClients()
AppServices.makeLive()
ReforgeApp.init()
static App.main()

Reproducing project

I do not yet have a standalone reproducing project. The current reproduction is in a Tuist-generated macOS app project using the SyncEngine initialization shown above.

SQLiteData version information

1.6.3

Sharing version information

2.8.0

GRDB version information

7.10.0

Destination operating system

macOS 26.5.1

Xcode version information

Xcode 26.4.1

Swift Compiler version information

swift-driver version: 1.148.6 Apple Swift version 6.3.1 (swiftlang-6.3.1.1.2 clang-2100.0.123.102)
Target: arm64-apple-macosx26.0

[mbrandonw]

Hi @iSapozhnik, there isn't much we can do without seeing a reproduction of the problem. Can you please distill the problem into a minimal project without using Tuist and share that? Also tell us what version of SQLiteData does it not crash and what version does it crash.

Until then I am going to convert this to a discussion. Feel free to continue the conversation over there.

[iSapozhnik]

Hey @mbrandonw!
Unfortunately I can not reproduce this issues in a vanilla Xcode project without Tuist. Xcode/SPM (not sure exactly) must be doing some extra work when it comes to linking. Also answering your question it crashes on all version. so far I tried 1.6.1 and 1.6.3.
However, I distilled the problem into a small Tuist repro project.

The crash happens on macOS when SyncEngine is initialized and the package linkage is:

"ReproHistory": .framework
"ReproSnippets": .framework
"SQLiteData": .staticFramework

Both ReproHistory and ReproSnippets define small @Table models and depend on SQLiteData.
At runtime the app logs duplicate Swift/ObjC class warnings, for example IssueReporting.FailureObserver being implemented in multiple generated frameworks (not sure is this is relevant). Then it crashes while initializing SyncEngine with:

Thread 1: EXC_BAD_ACCESS (code=1, address=0x0)

I tried one workaround: make the local table packages static too:

"ReproHistory": .staticFramework
"ReproSnippets": .staticFramework
"SQLiteData": .staticFramework

That removes the duplicate runtime warnings and avoids the macOS SyncEngine crash in the repro.

However, in my real app I also tried another workaround earlier: making SQLiteData dynamic. That avoided the macOS SyncEngine crash, but it caused the iOS TestFlight build to crash instead, in an ordered query path:

RewriteHistoryClient.fetchHistory()
SQLiteData Select.order(by:)
SQLiteData Where.order(by:)
SQLiteData static Table.order(by:)

So I are stuck between:

• SQLiteData static: macOS crashes during SyncEngine initialization.
• SQLiteData dynamic: iOS TestFlight crashes during Table.order.

Here is the repo: https://github.com/iSapozhnik/sqlite-data-syncengine-crash-repro
Thanks in advance for taking a look.

[iSapozhnik]

Quick update: I found the issue.

This was a Tuist linkage configuration problem, not a SQLiteData problem.

The crashing configuration was effectively mixing dynamic local/framework targets with SQLiteData and some of its transitive dependencies linked statically. That produced duplicate Swift runtime metadata and led to the macOS SyncEngine crash.

What fixed it was making the SQLiteData/StructuredQueries stack link consistently as dynamic frameworks in Tuist:

"SQLiteData": .framework,
"StructuredQueries": .framework,
"StructuredQueriesCore": .framework,
"StructuredQueriesSQLite": .framework,
"StructuredQueriesSQLiteCore": .framework,
"IssueReporting": .framework,
"IssueReportingPackageSupport": .framework,
"OrderedCollections": .framework,
"InternalCollectionsUtilities": .framework,

With that configuration:

• macOS no longer crashes during SyncEngine initialization
• iOS/TestFlight also works
• the earlier TestFlight crash happened because I had only made SQLiteData dynamic, while some transitive dependencies were still static

The downside of this approach is that if you decide to introduce another dependency to the library, I would need to keep an eye on that and update the twist file by explicitly adding the new dependency as .framework. Maybe you have some better ideas?

So this can be closed/converted however you prefer. Thanks for pushing me toward a minimal repro.

[mbrandonw]

Nice, thanks for the update and glad you figured it out!