You cannot just put the SQLite database in an iCloud container because it can be damaged. (As SQLite DB changes, temporary files are created and renamed, so if the synchronization process starts to copy these files, you will get a damaged database.)
If you do not want to switch to Core Data, you can do what Core Data does: store your database in the folder of your document and store the transaction log in the iCould container. Each time you change the database, you add these changes to the log file so that you can play them back and make equivalent changes on other devices.
This becomes quite complicated: in addition to the correct log logic and response, you will want to combine redundant changes and periodically collapse the log into a full copy of the database.
You may have an easier time developing a solution if you can use the knowledge of your application (basic data should solve the problem in the general case). For example, you can save invoices as separate files in a cloud container (text, property list, XML, JSON, etc.), recording them as database changes and importing them only if the system reports that they have been created or modified.
In general, your choice is to either switch to Core Data or write your own synchronization solution. Which one best depends on the features of your application.
benzado
source share