Bundling app with our own SQLite

Any “can we do X” question always has two aspects:

• Is it technically possible?
• What about the business side of this?

On the business side, there’s an Apple part and a non-Apple part. I presume that you’re concerned about App Review. I don’t work for App Review and thus can’t offer definitive advice about their policies. I suggest you review the App Review Guidelines.

The non-Apple part is the standard open source licence stuff, and I definitely can’t comment on that.

As to whether it’s technically possible, it’s generally fine to do this. SQLite is just an open source library written in standard C targeting Posix-layer APIs. You can generally add code like that to an iOS project without any problems.

There are, however, some potential caveats:

• Apple’s SQLite implementation has some Apple-specific tweaks. These are not well documented, so it’s hard to say exactly whether this will be a problem for you or not.
• You may run into problems if you try to combine code that uses Apple’s SQLite with code that uses your SQLite. A good way to avoid any confusion is to static link your SQLite with its client code.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

If possible, I would recommend sticking with the system-provided version of SQLite. There are platform-specific enhancements that are not available in the open-source version of SQLite.

For extensions like spellcheck1, you can build and statically link the extension. (See https://www.sqlite.org/loadext.html Section 6. Statically Linking A Run-Time Loadable Extension)

• Add the spellcheck.c file to your Xcode project and add it to your target.
• In Target Membership, click the edit button and add -DSQLITE_CORE in Compiler Flags.
• After opening your database (sqlite3_open_v*), call the initializer and pass NULL for the db routines). Something like sqlite3_spellfix_init(db, &err, NULL);

Can we bundle our app with our own version of SQLite with extensions that we want.

Yes, and you should do that. The version that Apple includes depends on the iOS version (see https://github.com/yapstudios/YapDatabase/wiki/SQLite-version-(bundled-with-OS) for a table). If you use the Apple version, there's a danger that your app will break after an iOS update, or will not function on an older iOS version that you are still trying to support but don't test on as well as you should. I was caught out by the latter issue because the sqlite in iOS 14 doesn't support "on conflict" without a column list.

Hey hey, three different responses with three different opinions.

It seems like this is gonna be a classic ‘it depends’ situation, that is, there are engineering trade-offs to be made and it’s really up to you as to which approach is best for your specific use case.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

But whatever you decide, make a point to save that response from "Framework Engineer". I had no idea it was possible to do either of those two things.