Using CocoaPods, SQLCipher 4.0, Swift 4. Database created and encrypted(with SQLCipher 4) by DB Browser for SQLite.
SQLCipher 4 works well with database without encryption, but it fails to open an encrypted database. It shows error message: Error setting key: not an error, Error retrieiving cipher_version: no more rows available
The above operations always work well with SQLCipher 3 in other Apps.
When App running on iOS 10 simulator, App crashes with this error message: dyld: Symbol not found: _sqlite3_key Expected in: /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 10.0.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libsqlite3.dylib
This is the culprit. If you look at their pod spec, they are linking sqlite3.
If both SQLCipher and a standard version of SQLite are linked, this can lead to undefined behavior.
Our recommendation would be to remove any other pods that depend on SQLite.
Alternatively, there is some guidance in these posts on how to ensure SQLCipher is preferred when linking:
Note: This is considered unsupported
Specifically in your scenario, since you’re using cocoa pods with use_frameworks you’ll want to put this as the first item in your target’s Build Settings > Other Linker Flags: -framework SQLCipher as recommended in the second post. We’d also recommend following the guidance in that second post related to ensuring that SQLCipher is properly linked at runtime.
@mmoore awesome solution! I can’t believe this subtle problem has costed hours to locate.
My problem was very similar, by using Google library (again) at cocoapod. It secretly induced a sqlite library dependency which cause mislink at runtime. These kind of runtime linking issue is again very subtle and extremely hard to be troubleshooted. Especially when the problem is not noticed right away.
While @sjlombardo has written a comprehensive article about this issue. Although it is rare to meet, I suggest it should be put at FAQ or common mistake section to avoid fellows from suffering if they are so lucky to meet this problem.