I imagine that it's mostly in the background via libraries. E.g.:
- Access system-level SQLite databases via system APIs using the OS-linked SQLite. For example, you want to access the system config settings, so you use the iOS/Android API for doing so.
- Access your app's SQLite libraries using (e.g.) SQLCipher. For example, you want to store your app's preferences in a SQLite db, so long as SQLCipher manages to use a single SQLite library internally, then you're golden.
An example of running into issues could be:
- Using an ORM to access your App's SQLite db to read/write changes locally.
- Using a separate library to sync your App's SQLite db to desktop/"the cloud"/whatever.
Those two libraries could be using separate SQLite libraries, and be accessing the same SQLite db file. Oops!
It could be possible to resolve said issue so long as you make sure that only one library is accessing the SQLite database at a time. Basically your own in-app DB locking mechanism. Yay!
- Access system-level SQLite databases via system APIs using the OS-linked SQLite. For example, you want to access the system config settings, so you use the iOS/Android API for doing so.
- Access your app's SQLite libraries using (e.g.) SQLCipher. For example, you want to store your app's preferences in a SQLite db, so long as SQLCipher manages to use a single SQLite library internally, then you're golden.
An example of running into issues could be:
- Using an ORM to access your App's SQLite db to read/write changes locally.
- Using a separate library to sync your App's SQLite db to desktop/"the cloud"/whatever.
Those two libraries could be using separate SQLite libraries, and be accessing the same SQLite db file. Oops!
It could be possible to resolve said issue so long as you make sure that only one library is accessing the SQLite database at a time. Basically your own in-app DB locking mechanism. Yay!