Support SQLCipher using package traits by marcprux · Pull Request #1708 · groue/GRDB.swift

marcprux · 2025-01-26T17:58:50Z

This is a less ambitious alternative to #1701 that enables adding a SQLCipher source dependency to the Package.swift based on the GRDBCIPHER environment variable. Tests can be run with the dependency with a command like:

GRDBCIPHER="https://github.com/skiptools/swift-sqlcipher.git#1.2.1" swift test

Running it without the environment variable will leave things exactly as they are. The majority of changes in this PR are simply re-ordering the import header checks for GRDBCIPHER and SWIFT_PACKAGE, since we would need the former to take precedence of the latter.

An advantage of doing it this way is that it facilitates creating a GRDB-SQLCipher fork that can follow the releases of the upstream. The only change in such a fork would be to hardwire the GRDBCIPHER setting in Package.swift to some SQLCipher source repository (either mine, or one that you maintain). When a client package wants to switch between GRDB and GRDB-SQLCipher, they would just need to swap their dependency URL. (this is no longer needed when using package traits; see comment below)

This PR also adds in support building and testing against Android, mostly by stubbing out the unit tests that can't compile due to missing NSFileCoordinator, Combine, and the like. Android tests can be run with skip:

GRDBCIPHER="https://github.com/skiptools/swift-sqlcipher.git#1.2.1" skip android test

Most of the tests pass, but there are a few that need to be investigated. I'll look into them next.

Closes #1701

marcprux · 2025-01-27T13:28:05Z

Addendum: out of curiosity, I ran some comparisons between the built-in SQLite and the SQLCipher build with the following script (and adding a GRDB_PERFORMANCE_TESTS check to enable GRDBPerformanceTests in Package.swift).

The results over a dozen runs are a fairly consistent slowdown of around 10% when using SQLCipher. It'd be interesting to tweak the SQLite build flags in swift-sqlcipher to see what might increase/decrease the performance.

echo "With GRDBCIPHER"; rm -r .build; GRDB_PERFORMANCE_TESTS=1 GRDBCIPHER="https://github.com/skiptools/swift-sqlcipher.git#1.2.1" swift test --filter GRDBPerformanceTests 2>&1 | grep --after-context=2 "Test Suite 'GRDBPackageTests.xctest' passed"
echo "Without GRDBCIPHER"; rm -r .build; GRDB_PERFORMANCE_TESTS=1 swift test --filter GRDBPerformanceTests 2>&1 | grep --after-context=2 "Test Suite 'GRDBPackageTests.xctest' passed"

With GRDBCIPHER
Test Suite 'GRDBPackageTests.xctest' passed at 2025-01-26 22:33:13.477.
	 Executed 23 tests, with 0 failures (0 unexpected) in 353.144 (353.146) seconds
Test Suite 'Selected tests' passed at 2025-01-26 22:33:13.477.
Without GRDBCIPHER
Test Suite 'GRDBPackageTests.xctest' passed at 2025-01-26 22:38:59.398.
	 Executed 23 tests, with 0 failures (0 unexpected) in 314.684 (314.686) seconds

Update: this was simply because I wasn't building in release mode. See comment below, where the SQLCipher build is actually 10% faster.

Joannis · 2025-01-30T09:32:19Z

@marcprux the Android NDK doesn't seem to bundle sqlite3.h, whereas GRDB and your PR do rely on that being available. How are you providing that right now when building and testing GRDB?

marcprux · 2025-01-30T13:59:08Z

@marcprux the Android NDK doesn't seem to bundle sqlite3.h, whereas GRDB and your PR do rely on that being available. How are you providing that right now when building and testing GRDB?

It is included with the SQLCipher source module: https://github.com/skiptools/swift-sqlcipher/tree/main/Sources/SQLCipher/sqlite

groue

Hello @marcprux,

I like that very much. This pull request is a great gift 🎁! I'll shortly play with the new targets.

I made a first review and preliminary comments. I hope we agree on the broad outlines!

GRDB/Dump/Database+Dump.swift

Tests/GRDBTests/DatabaseQueueTests.swift

Tests/GRDBTests/FTS5TableBuilderTests.swift

Tests/GRDBTests/FailureTestCase.swift

Tests/GRDBTests/JSONColumnTests.swift

Tests/GRDBTests/JSONExpressionsTests.swift

Tests/GRDBTests/MutablePersistableRecordTests.swift

Tests/GRDBTests/PersistableRecordTests.swift

Tests/GRDBTests/ValueObservationRecorderTests.swift

groue · 2025-02-01T10:50:09Z

The results over a dozen runs are a fairly consistent slowdown of around 10% when using SQLCipher. It'd be interesting to tweak the SQLite build flags in swift-sqlcipher to see what might increase/decrease the performance.

Isn't it just the cipher? (EDIT: I'm wrong because performance tests don't run on encrypted databases, see comment below.)

SQLCipher can also be extremely slow when it opens a connection. Some people have reported up to 0.5 seconds (😱). To the point I had to ship #1350.

groue · 2025-02-01T12:57:58Z

I ran the same performance tests, but this time in release configuration:

echo "With GRDBCIPHER"; rm -rf .build; GRDB_PERFORMANCE_TESTS=1 GRDBCIPHER="https://github.com/skiptools/swift-sqlcipher.git#1.2.1" swift test --configuration release --filter GRDBPerformanceTests 2>&1 | grep --after-context=2 "Test Suite 'GRDBPackageTests.xctest' passed"
echo "Without GRDBCIPHER"; rm -rf .build; GRDB_PERFORMANCE_TESTS=1 swift test --configuration release --filter GRDBPerformanceTests 2>&1 | grep --after-context=2 "Test Suite 'GRDBPackageTests.xctest' passed"

With GRDBCIPHER
Test Suite 'GRDBPackageTests.xctest' passed at 2025-02-01 13:53:37.700.
	 Executed 23 tests, with 0 failures (0 unexpected) in 72.258 (72.260) seconds
Test Suite 'Selected tests' passed at 2025-02-01 13:53:37.700.
Without GRDBCIPHER
Test Suite 'GRDBPackageTests.xctest' passed at 2025-02-01 13:57:26.264.
	 Executed 23 tests, with 0 failures (0 unexpected) in 80.139 (80.141) seconds
Test Suite 'Selected tests' passed at 2025-02-01 13:57:26.264.

This time, SQLCipher tests are faster.

marcprux · 2025-02-01T18:38:50Z

SQLCipher can also be extremely slow when it opens a connection

Agreed, but the performance hit should only occur when encryption is actually enabled on the database, which shouldn't affect any of the perf tests.

This time, SQLCipher tests are faster.

Of course! Foolish of me to not do that. Otherwise, it is comparing the debug build of the sqlcipher/sqlite source build against the release build of the vendored sqlite.

It is heartening to see that superior performance can be squeezed out of a source build. I wonder how much more might be managed with strategic performance-related flags (e.g., sbooth/CSQLite#59 (comment)).

…ersionNumber

…abilites on non-Dawin platforms missing XCTIssue

… rather than disabiling them altogether

marcprux · 2025-02-06T21:38:56Z

Apologies for the long delay in addressing the feedback (I was traveling).

I believe I've handled each of the requested changes. Let me know if I can do anything else to help get this PR over the finish line – it has grown quite large, so I'm nervous that rebasing is going to be difficult if it starts to become stale.

Joannis · 2025-02-07T07:29:29Z

We've been using this branch successfully.

marcprux · 2025-02-12T14:23:34Z

I'll follow up on the list of needs at https://mastodon.social/@groue@hachyderm.io/113990450491505387 here, just to keep it in the PR record.

Provides built-in SQLCipher support that works for 80+% of people.

This should work out of the box for anyone that just changes:

    dependencies: [
        .package(url: "https://github.com/groue/GRDB.swift.git", from: "7.0.0"),
    ]

to the (theoretical) locally-maintained fork:

    dependencies: [
        .package(url: "https://github.com/groue/GRDB-SQLCipher.swift.git", from: "7.0.0"),
    ]

No extra dependency (we must control the SQLCipher compilation options).

You are welcome to relocate https://github.com/skiptools/swift-sqlcipher.git into the groue/ org and use that – then you would have control over releases and flags.

No binaries (they rot).

swift-sqlcipher.git is a pure source build. There are no binaries.

A clear documentation that tells users what to do to get GRDB+SQLCipher with SPM, written for people who are not build experts.

This isn't part of this PR, but it would only be a couple of lines in the README.

Testable in GitHub CI.

This is part of the PR. The new SPMSQLCipher job just does:

GRDBCIPHER="https://github.com/skiptools/swift-sqlcipher.git#1.2.1" swift test

Runs the full GRDB test suite with unencrypted databases, AND with encrypted databases (we already do that for SQLCipher with CocoaPods).

The tests do run against SQLCipher, but against an unencrypted database. I didn't see how this is being done with SQLCipher for CocoaPods, but I suppose we could just do the same setup here (perhaps just based on checking the GRDBCIPHER environment variable)

Requires minimum efforts for debugging (one can debug tests from Xcode).

This shouldn't be an issue. Just activate (i.e., un-comment) the GRDBCIPHER line in the Package.swift and run the test cases in Xcode.

Requires minimum efforts for maintenance (i.e. bumping SQLCipher version and adjusting compile options when needed)

For the SQLCipher dependency, you just need to make a new amalgamated sqlite.c from sqlcipher, commit it, and then tag a release. This is done with the script: https://github.com/skiptools/swift-sqlcipher/blob/main/scripts/build_sqlcipher.sh

An example of this sort of update commit is the bump to sqlite 3.46.1 and sqlcipher 4.6.1: skiptools/swift-sqlcipher@5ea2f8b

For GRDB itself, my proposal is that you maintain a fork of GRDB.swift.git at https://github.com/groue/GRDB-SQLCipher.swift.git. The fork is pristine, with the one exception that the GRDBCIPHER line in the Package.swift is un-commented. Whenever you make a release of GRDB.swift.git, you just update the GRDB-SQLCipher.swift.git fork and sync the tags.

~~It is a little bit of overhead, but it could be added as another step in any scripts you might already be using to maintain releases.~~

A technique thats enables SQLCipher support in companion packages as well (GRDBQuery, GRDBSnapshotTesting, RxGRDB).

~~This is certainly a shortcoming of this method. I unfortunately don't see any solution other than to also have a GRDBQuery-SQLCipher that depends on the GRDB-SQLCipher.swift.git fork.~~

This last point is indeed painful. However, I think this PR gets us a lot, with minimal intrusion on the existing GRDB structure. A more "correct" solution would be along the lines of #1701, which requires a large refactoring and had performance implications, and so was rejected.

~~We can have a working GRDB-SQLCipher implementation (plus Android support!) today with this PR, while still continuing to design a more ideal future implementation.~~

Update: the fork is no longer necessary when using package traits (see comment below)

groue · 2025-02-24T10:12:09Z

I'm sorry I did not answer yet. I had to cope with the problems created with Xcode 16.3 beta. I'll get back to you soon.

Alex293 · 2025-03-12T17:16:07Z

This PR saved me today while integrating a closed source framework which links SQLCipher while we were already extensively using grdb.

marcprux · 2025-04-23T00:16:31Z

I've updated this PR to use the new package traits in Swift 6.1, which seem designed for a scenario exactly like this. Now, rather than having to create and maintain a custom GRDB-SQLCipher fork that enables GRDBCIPHER, a consumer of this package can simply enable the GRDBCIPHER trait when adding a dependency on GRDB:

    dependencies: [
        .package(url: "https://github.com/groue/GRDB.swift", from: "7.5.0", traits: ["GRDBCIPHER"])
    ]

Adding the trait to the dependency will activate the GRDBCIPHER conditionals as well as adding a conditional dependency on the swift-sqlcipher repository, whereas leaving the trait empty (the default) will result in GRDB continuing to use the vendored SQLite3.

For the purpose of testing and CI, the "GRDBCIPHER" environment variable is still checked, but only to see whether to enable the trait by default in the Package.swift, so you can run:

# test with SQLCipher
GRDBCIPHER=1 swift test 
# test with SQLite3
GRDBCIPHER=0 swift test

The performance test environment can also still be used, which demonstrates that the custom SQLCipher build continues to be ~10% faster than the vendored SQLite3, at least on my machine:

# SQLCipher performance tests
GRDBCIPHER=1 GRDB_PERFORMANCE_TESTS=1 swift test -c release --filter GRDBPerformanceTests 
# Executed 23 tests, with 0 failures (0 unexpected) in 73.005 (73.009) seconds

# SQLite3 performance tests
GRDBCIPHER=0 GRDB_PERFORMANCE_TESTS=1 swift test -c release --filter GRDBPerformanceTests 
# Executed 23 tests, with 0 failures (0 unexpected) in 81.398 (81.401) seconds

The only drawback is that since traits are simple booleans, you can no longer specify a custom repository with the "GRDBCIPHER" environment variable, so you need to depend on a specific repository. But an advantage is that the swift-sqlcipher.git repository could now publish its own traits that will control various SQLite build flags, which means that consumers of the package could potentially have fine-grained control over the SQLite build itself.

marcprux · 2025-04-28T14:48:28Z

@groue Hoping you can take another look at this PR with the new Package traits dependency. I think it really improves on the original idea.

marcprux · 2025-09-17T01:01:35Z

Why did you pick https://github.com/skiptools/swift-sqlcipher? What are the other options?

I picked it simply because that is a package that I had already put together to work on Android. Any buildable SQLCipher amalgamation would work, and as I've mentioned before, you could simply pull it into the GRDB package as a C module in order to eliminate the need for an external dependency (which I think would be the ideal solution). I would be happy to expand this PR to provide that option, but it would introduce the potential maintenance burden of keeping up with subsequent SQLCipher releases, which I sense you aren't interested in.

If there's a bias due to your focus on Android, would you please make it explicit, and describe the consequences of this choice for other platforms?

You would be correct in thinking that the two issues (SQLCipher support and Android support) are orthogonal. They just happen to both be solvable through this PR.

My ultimate goal is to bring this support to all platforms, including Android. GRDB currently doesn't work at all on Android due to there not being any linkable sqlite library on the platform (unlike Linux), so a source build is currently the only solution for that platform (irrespective of whether the source build is sqlcipher or just a stock sqlite package like https://github.com/sbooth/CSQLite or https://github.com/swiftlang/swift-toolchain-sqlite).

As to your other concerns, I feel like they can all be mitigated by simply stating that this support is experimental and optional (just like the current Linux support). Nothing this PR does changes how GRDB functions on Apple platforms by default. It is only when opting-into the SQLCipher trait that the new build behavior would be activated.

I'm happy to continue iterating on the PR or provide alternate suggestions/solutions, but I also understand if you would prefer GRDB to stick to narrow path of supporting only the vendored-SQLite on Apple platforms.

groue · 2025-09-17T05:20:37Z

All right, @marcprux, we are converging. I agree that we can just flag SQLCipher support as experimental. I'll have a closer look at the PR.

groue · 2025-09-17T13:38:46Z

(EDIT: in response to a comment that was deleted by its author)

I'm not sure the meaning of "experimental" was correctly understood. Expressions such as "huge deal" and "intolerable" can only be supported by actual contributions.

Il n’y a pas d’amour, il n’y a que des preuves d’amour (the proof is in the pudding).

EDIT: Given the complete lack of mention of GRDB in the SQLiteData README, I would advise commenters to choose their arguments with more tact and discernement than some of their favorite developers.

mbrandonw · 2025-09-18T21:25:57Z

EDIT: Given the complete lack of mention of GRDB in the SQLiteData README, I would advise commenters to choose their arguments with more tact and discernement than some of their favorite developers.

This was an honest mistake on our part and we saw your comment on Hacker News and immediately corrected it. We took for granted the obviousness of GRDB’s presence in the library in the name alone, and so forgot to update the readme with the 1.0 release. We are very sorry for that.

groue · 2025-09-28T08:15:56Z

Tests/GRDBTests/DatabaseAggregateTests.swift

                XCTFail("Expected DatabaseError")
            } catch let error as DatabaseError {
                XCTAssertEqual(error.resultCode, .SQLITE_ERROR)
+                #if canImport(ObjectiveC) // non-Darwin platforms bridge NSError differently and do not set the message the same


This PR merges two concerns here: SQLCipher and Android.

NSError is available on non-Darwin platforms, so people can use it. I'd be curious to know if this test can be restored. When a custom SQL function raises an error, it is important that the host application can catch a message that preserves as much as possible from the original error.

What's the specific issue here? This test does pass on Linux, as the DatabaseError is used here directly. I don't need the compiler directive here. Is this different on Android?

groue · 2025-09-28T08:17:27Z

Tests/GRDBTests/DatabaseErrorTests.swift


    func testNSErrorBridging() throws {
+        #if !canImport(ObjectiveC)
+        throw XCTSkip("NSError bridging works differently on non-Darwin platforms")


Same question as above

Again, I'm having a similar issue on Linux. The DatabaseError in this test is thrown correctly but casting to an NSError in the catch clause fails. I guess this is either a bug in Swift on non-Darwin platforms or not supported. Why would we need NSError in this case instead of the Swift Error protocol? To preserve the error information in DatabaseError?

groue · 2025-09-28T08:18:43Z

Tests/GRDBTests/DatabaseMigratorTests.swift

    func testEmptyMigratorPublisher() throws {
        func test(writer: some DatabaseWriter) throws {
            let migrator = DatabaseMigrator()
+            #if !canImport(Combine)


I'd move this check at the beginning of the test method (as all similar checks below).

groue · 2025-09-28T08:22:44Z

Tests/GRDBTests/DatabasePoolConcurrencyTests.swift

            // > because DISPATCH_QUEUE_OVERCOMMIT is not a public API. I don't
            // > know of a way to get a reference to the overcommit queue using
            // > only public APIs.
+            #if !canImport(Darwin)


Should be moved at the beginning of the test function

groue · 2025-09-28T08:31:13Z

Tests/GRDBTests/FailureTestCase.swift

 /// A XCTestCase subclass that can test its own failures.
 class FailureTestCase: XCTestCase {
    private struct Failure: Hashable {
+        #if canImport(Darwin)


Instead of turning regular methods into throwing methods, as below, in order to be able to throw XCTSkip, I'd rather remove the whole FailureTestCase from non-Darwin platforms (or Android only, if this limitation is specific to Android). I hope Swift Testing makes it possible to run tests that catch test failures.

groue · 2025-09-28T08:39:24Z

Tests/GRDBTests/FoundationNSDecimalNumberTests.swift

-
+    func testNSDecimalNumberPreservesIntegerValues() throws {
+        #if !canImport(ObjectiveC)
+        throw XCTSkip("NSDecimalNumber unavailable")


NSDecimalNumber is part of the GRDB support for decimals.

I find mentions of NSDecimalNumber in https://github.com/swiftlang/swift-corelibs-foundation and https://github.com/swiftlang/swift-foundation.

Is this lack of NSDecimalNumber temporary, or Android specific? Shouldn't we use #if os(android) instead of #if !canImport(ObjectiveC)?

Finally, shouldn't we disable the whole test class, since it is named FoundationNSDecimalNumberTests?

I'm having a similar issue on Linux as mentioned here The issue is not the availability of NSDecimalNumber but a problem with two constructors which are used in converting int64 and double values from a DatabaseValue to an NSNumber. I have solved it similarly by ignoring these tests on Linux and Windows platforms. Not sure why these constructors are giving problems. Maybe they are not available? In any case it needs more research!

groue · 2025-09-28T08:39:56Z

Tests/GRDBTests/FoundationNSNumberTests.swift

-    func testNSNumberDatabaseValueToSwiftType() {
+    func testNSNumberDatabaseValueToSwiftType() throws {
+        #if !canImport(ObjectiveC)
+        throw XCTSkip("NSNumber unavailable")


Same question as above about NSDecimalNumber.

groue · 2025-09-28T08:41:27Z

Tests/GRDBTests/FoundationNSURLTests.swift


    func testNSURLDatabaseRoundTrip() throws {
+        #if !canImport(ObjectiveC)
+        throw XCTSkip("NSURL unavailable")


NSURL is less useful than NSNumber/NSDecimalNumber, so here I'll just recommend that the whole test class is disabled on platforms that do not support NSURL. Or to throw XCTSkip from setUp() so that we can see this test case in the test log.

(I admit I don't quite understand why we can keep on compiling this test, and yet do not compile the NSURL support for GRDB)

groue · 2025-09-28T08:42:00Z

Tests/GRDBTests/FoundationNSUUIDTests.swift

+
    private func assertRoundTrip(_ uuid: UUID) throws {
+        #if !canImport(ObjectiveC)
+        throw XCTSkip("NSUUID unavailable")


Same request as in FoundationNSURLTests above.

groue · 2025-09-28T08:43:28Z

Tests/GRDBTests/FoundationURLTests.swift

        XCTAssertNil(URL.fromDatabaseValue(databaseValue_Int64))
        XCTAssertNil(URL.fromDatabaseValue(databaseValue_Double))
-        XCTAssertEqual(URL.fromDatabaseValue(databaseValue_Blob)!.absoluteString, "bar")
+        XCTAssertEqual(URL.fromDatabaseValue(databaseValue_Blob)?.absoluteString, "bar")


It looks like a change that is not strictly necessary.

groue · 2025-09-28T08:44:41Z

Tests/GRDBTests/ValueObservationTests.swift

    }
-
+
+    #if canImport(Darwin) // @MainActor test cases don't compile non-Darwin platforms: "call to main actor-isolated instance method 'test_mainActor_observation()' in a synchronous nonisolated(unsafe) context"


This needs a link to at least one bug report in the Swift repository.

groue · 2025-09-28T08:50:25Z

Package.swift

@@ -1,4 +1,4 @@
-// swift-tools-version:6.0
+// swift-tools-version:6.1


Not required in this pull request, but some cleanup is needed:

git grep -i 'version.*\b6\.0'

git grep 'compiler('

README.md

GRDB.swift.podspec

groue · 2025-09-28T08:56:55Z

Package.swift

        .library(name: "GRDB-dynamic", type: .dynamic, targets: ["GRDB"]),
    ],
+    traits: [
+        .trait(name: "GRDBCIPHER", description: "Use the SQLCipher library rather than the vendored SQLite"),


After reading the naming concerns expressed in #1816, and the CamelCase trait names used in the proposal SE-0450, I suggest using the name SkipSQLCipher or SkipToolsSQLCipher, and a description that mentions the repository URL https://github.com/skiptools/swift-sqlcipher

I assume, @sjlombardo, that the names I suggested are acceptable for Zetetic.

We're about to have multiple SQLCipher versions: the one in this pull request, the one from #1816, and the CocoaPods one (even if it's high time I completely removed it).

To simplify the compiler flags dance, I start working on replacing most uses of #if GRDBCIPHER with #if SQLITE_HAS_CODEC. That last flag ought to be set by all GRDB+SQLCipher flavors. See #1819

cc @R4N

@groue That sounds good to us. We were initially re-using the GRDBCIPHER flag, but using SQLITE_HAS_CODEC should work better for supporting both flavors. We'll switch over to that.

@groue thanks, the suggested names look good to us, things will be very clear with the prefixing.

groue · 2025-10-18T12:24:26Z

@marcprux, I found a pretty important blocker while validating the pull request for the official SQLCipher trait: #1827 (comment). This PR will suffer from the same problem.

Basically, the fact that Xcode lacks support for traits is likely to block all progress. Maybe this can be fixed, but this is beyond my skills.

orj · 2025-10-21T03:34:48Z

⚠️ 🚨 @groue @marcprux how is this at all safe to do?

I'm working on a project where we're encountering dyld binding issues with SQLite & GRDB due to a 3rd party vendor linking a version of SQLCipher into their dynamic framework on iOS.

This vendor has linked an old version of SQLite/SQLCipher into their framework. This breaks GRDB because dyld seems to randomly select which versions of _sqlite3_* C calls to call from inside GRDB.

I see from the .swiftinterface files in the DuckDuckGo fork of GRDB that GRDB inlines calls to sqlite3_* APIs in some areas. This would mean that depending on how dyld binds SQLite to frameworks (including Apple frameworks) you might end up with random incompatibilities and duplicate global state.

The way this is manifesting in our app (if we link this vendors framework) is SQL syntax errors for syntax that is very old and very correct.

The only way I can think of this working correctly is if SQLite/SQLCipher is linked into into GRDB statically as a hidden dependency (which means no inline code or exposing of sqlite symbols private import SQLite). I believe it might also require that the SQLite/SQLCipher C library is linked/compiled into GRDB with -fvisibility=hidden option to clang.

Though this may not be possible with Swift given this old unresolved bug: swiftlang/swift#43633

mackoj · 2025-10-22T09:36:53Z

@marcprux, I found a pretty important blocker while validating the pull request for the official SQLCipher trait: #1827 (comment). This PR will suffer from the same problem.

Basically, the fact that Xcode lacks support for traits is likely to block all progress. Maybe this can be fixed, but this is beyond my skills.

Hello @groue, I haven’t read all the messages, so maybe someone has already suggested this, but there’s a pretty straightforward way to work around this limitation: you can import a local package into the project to enable the trait.

This is the approach we use in our project using one local package as a proxy that depends on the package where we need the traits and enabling them there. This way, we have access to it. So, I don’t think the lack of trait support in Xcode should block this. People who need Linux/Android support can work around the Xcode limitation, and those who don’t need it won’t even be affected which I think applies to most users.

I’ve also shared an example project that demonstrates this approach. testTrait.zip

groue · 2025-10-22T09:58:53Z

Thank you for your hint, @mackoj :-) The use case that is currently broken is the plain Xcode app that has a plain dependency on GRDB (via the Xcode UI), without any wrapper package. That's what most apps that use GRDB today do. The technique of the wrapper package is not a satisfying solution for those apps, because it would be a painful breaking change. Now, I hope that the use case that is currently broken can be restored while keeping the ability to use SQLCipher through SPM. That's the current discussion in #1827.

groue · 2026-02-01T14:39:22Z

This pull request is obsolete, so I'm closing it. Thank you nevertheless @marcprux, your support is very precious! 🙏

The Android situation should be in better shape since I merged the Linux compatibility changes of #1825 into the development branch. #1825 is still open, but it is now re-focused on the CI.

The SQLCipher situation is also in better shape: #1845 should be merged shortly.

From now on, future progress on the SQLCipher or Android topics should happen independently, in dedicated pull requests.

marcprux added 2 commits January 26, 2025 12:40

Rework import order for SQLCipher; add test conditionals for Android

b26c42c

Add SPMSQLCipher workflow action

c4b0279

marcprux mentioned this pull request Jan 26, 2025

Add SQLInterface for dynamic replacement of SQLite implementations #1701

Closed

6 tasks

Add optional performance testing to Package.swift

81b647f

groue reviewed Feb 1, 2025

View reviewed changes

marcprux added 4 commits February 6, 2025 12:33

Rebase and fix conflicts

cf29c95

Remove import of SQLCipher due to availability of Database.sqliteLibV…

65db92f

…ersionNumber

Re-enable ValueObservationTests and FailureTestCase with degraded cap…

15e3089

…abilites on non-Dawin platforms missing XCTIssue

Update tests to throw XCTSkip when required frameworks are unvailable…

289f9fd

… rather than disabiling them altogether

Remove some more unnecessary conditional imports

8b974af

Merge branch 'groue:master' into sqlcipher

463f5df

marcprux mentioned this pull request Mar 5, 2025

Wow, is this a future replacement for SkipSQL? skiptools/swift-sqlcipher#1

Closed

gr-markin mentioned this pull request Apr 1, 2025

add os(Android) compiler conditions #1754

Closed

6 tasks

marcprux and others added 2 commits April 22, 2025 18:57

Merge branch 'groue:master' into sqlcipher

c49ed6d

Update to use package traits to control whether SQLCipher is used

91092ba

marcprux changed the title ~~Rework import order for SQLCipher; add test conditionals for Android~~ Support SQLCipher using package traits Apr 23, 2025

Merge branch 'groue:master' into sqlcipher

a9f9e63

sjlombardo mentioned this pull request Sep 22, 2025

Proposal for Official SQLCipher.swift Pull Request #1816

Closed

groue reviewed Sep 28, 2025

View reviewed changes

groue mentioned this pull request Sep 28, 2025

Accept multiple SQLCipher libraries #1819

Merged

This was referenced Oct 3, 2025

Fixes for the Linux version of GRDB #1824

Closed

Updated Fixes for the Linux version of GRDB #1825

Open

groue mentioned this pull request Oct 4, 2025

Simplify the compiler checks for the availability of SQLite snapshots #1826

Merged

groue mentioned this pull request Oct 14, 2025

SQLCipher (Official) Swift Package Manager Integration #1827

Closed

6 tasks

Merge branch 'groue:master' into sqlcipher

66ad994

groue closed this Feb 1, 2026

		}


		#if canImport(Darwin) // @MainActor test cases don't compile non-Darwin platforms: "call to main actor-isolated instance method 'test_mainActor_observation()' in a synchronous nonisolated(unsafe) context"

		@@ -1,4 +1,4 @@
		// swift-tools-version:6.0
		// swift-tools-version:6.1

Uh oh!

Conversation

marcprux commented Jan 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marcprux commented Jan 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Joannis commented Jan 30, 2025

Uh oh!

marcprux commented Jan 30, 2025

Uh oh!

groue left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

groue commented Feb 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

groue commented Feb 1, 2025

Uh oh!

marcprux commented Feb 1, 2025

Uh oh!

marcprux commented Feb 6, 2025

Uh oh!

Joannis commented Feb 7, 2025

Uh oh!

marcprux commented Feb 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

groue commented Feb 24, 2025

Uh oh!

Alex293 commented Mar 12, 2025

Uh oh!

marcprux commented Apr 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marcprux commented Apr 28, 2025

Uh oh!

marcprux commented Sep 17, 2025

Uh oh!

groue commented Sep 17, 2025

Uh oh!

groue commented Sep 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mbrandonw commented Sep 18, 2025

Uh oh!

groue Sep 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

groue Sep 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

groue Sep 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marcprux commented Jan 26, 2025 •

edited

Loading

marcprux commented Jan 27, 2025 •

edited

Loading

groue commented Feb 1, 2025 •

edited

Loading

marcprux commented Feb 12, 2025 •

edited

Loading

marcprux commented Apr 23, 2025 •

edited

Loading

groue commented Sep 17, 2025 •

edited

Loading

groue Sep 28, 2025 •

edited

Loading

groue Sep 28, 2025 •

edited

Loading

groue Sep 28, 2025 •

edited

Loading

groue Sep 28, 2025 •

edited

Loading

groue Sep 28, 2025 •

edited

Loading

groue Sep 28, 2025 •

edited

Loading

groue Sep 28, 2025 •

edited

Loading

groue commented Oct 18, 2025 •

edited

Loading

orj commented Oct 21, 2025 •

edited

Loading

mackoj commented Oct 22, 2025 •

edited

Loading

groue commented Oct 22, 2025 •

edited

Loading