To be clear though, you can actually have SQLite dbs (treated as regular files) in the app group container. You just can't open them there. I copy to and from as a syncing mechanism between share extension and main app. Works great.
None of the mitigations worked for me, & I tried everything over a couple of years. When I finally admitted defeat, I implemented this solution in short order, & I haven't thought about it since. There are tradeoffs, but the extension really doesn't need access to gigabtyes of cached emails.(4/4)
Also, I've always used multiple small compartmentalized dbs where others might use tables. This allows for a smallish subset of synced dbs. Copy to shared dir is done in background with backup, vacuum, checkpoint, journal-mode-delete, & then,for good measure, removal of any -wal or -shm files.(3/4)
A full sync from main based on mod times is done periodically (once per day). Individual dbs are copied after relevant updates. I can't recall why I don't sync on app suspend, but I suspect I ran into same issue. (2/4)
Well. Since you asked, I'll expound. There are 2 subdirs under group container. Each writes to its own and reads from the other. Syncing back from the extension is minimal. I made changes to architecture so that most of that data is synced using a mechanism specific to an email app. (1/4)
Call WidgetCenter.shared.reloadAllTimelines and pray the OS will actually reload them haha
The widget timeline providers asynchronously load the JSON file with NSFileCoordinator to generate the timeline snapshots.
Thank you so much for the write up and sharing your learnings, Ryan 👏
Do you have any hunch/intuition as to whether this might also negatively affect CoreData databases in app group containers?