With the forthcoming Featured article widget (a result of iOS engineering week), we're dipping our toes into an alternate retrieval model for widget data. Currently, the WidgetKit refresh cycle relies on the main app and its Core Data store for the featured feed network fetch and data model population.

Core Data (specifically SQL backed instances) is notoriously bad news in shared app group usage, and continues to cause crashes in our (old and new) Widget extensions. This has lead to some involved Core Data mutual exclusion code that unfortunately still doesn't completely resolve our crashes.

With the new iOS 14+ Featured article widget, we're testing a different approach (which we'll apply to the existing widgets if it performs well in practice): the widget extension itself will now have a little network stack of its own to directly fetch featured content. It also has a shared WidgetCache that can be used to transit data (like the user's primary language, or cached feed results) between the app itself and the extensions via a shared App Group.

This allows us to remove the extension's direct shared Core Data usage (and along with that, resolves all our outstanding Core Data related widget crashes), as well as provides a path to more autonomous widgets (with their own independent user selectable language, for example).

It does come at a cost though, in that there’s some minor duplication of data models and network fetch, but I believe these costs are worth the path to resolving our biggest outstanding crashes while supporting our ideal future of more independently user configurable home screen widgets. A stretch goal I was unable to finish during my time working on this was to have content fetched in the main app cache itself to be used in the widget, but this is straightforward enough to implement as a future improvement.

The key point from my investigation of all this during engineering week is that I believe we have a viable model and strategy for less crash prone, more independent widgets.