I think this problem is twofold:

1. The app should not be terminating every time the user backgrounds. The splash screen could display from a simple background / foreground action, but only if they go through a deep link. It seems like these splash screen complaints are happening without a deep link flow. We fixed background crashes around the table of contents in 7.2.1, so that may help here. A couple of other things I can think of is that we should modernize our Core Data stack initializer, and update our AppDelegate to use SceneDelegate. Those would be blind fixes, as I have no proof that that's the issue here.
2. Long loading times - there are several sequences that occur on launch, but the few I can think that take a while are the core data library migration and restoring the navigation stack. Having multiple Explore feed cards turned on should only affect the Explore feed loading screen and should not cause the splash screen to display for a long period of time.

I am creating a 7.2.2 Testflight-only build, which is the 7.2.1 release with several additional logging calls added throughout the launch sequence. I will release it only to users who agree to help us debug this, and will send them instructions for exporting their log back to me. Hopefully the log will indicate exactly where the slowdown and/or background crashes are occurring, and we can get a little closer to resolving this.

Update

I have looked at two shared user libraries. The primary problem of slow launch times for both is a huge Explore feed. The Explore feed assumes our database cleanup task is regularly run in the background as a part of the BackgroundTasks Apple framework, but it is not. This task cleans out any unreferenced article data older than 30 days. This causes the number of database items to grow larger and larger, all of which get fetched into the Explore feed upon launch.

Immediate fix
A quick, low-risk fix is to limit the number of items that the Explore feed fetches from the database to the same 30-day limit.

Medium-term fix
We could manually run the database housekeeper cleanup task. We could do this as a part of a one-time migration upon first launch of the next release, and/or when users tap "Clear cache" in the app settings.

Long-term fix
We need to understand why the app is crashing in the background, because fixing should allow the background cleanup task to run again. This WWDC video has a good rundown of reasons. I think our first thing to is to audit our usage of UIApplication's beginBackgroundTask and endBackgroundTask calls, and make sure every begin call has an associated end call, and we aren't letting any of them run for too long (the video mentioned 30 seconds as the limit). This may mean not wrapping any network calls up in a background task.

We should also generally audit our memory usage. The WWDC video also provides benchmarks for background memory usage and foreground memory usage. Check for leaks, listen for memory warning notifications, and clean out caches upon backgrounding. It's possible that the large memory footprint in the Explore feed fetch from this bug causes it crash in the background, which causes the database cleanup task to fail, which causes the Explore feed continue getting larger, repeat. It may be a self-fulfilling cycle.

Another interesting note from user is that they still have a huge Explore feed even after reinstalling the app. I came across a recent thread that seems to indicate an Apple bug where the app container remains even after users uninstall the app - https://developer.apple.com/forums/thread/720458.

To help track down background task crashing reasons, I pushed another 7.2.2 build out that attempts to log those reasons reported from MetricKit. Again this will only go to users that agree to troubleshoot this. I'll report back if there's any findings there.

One last thing that I noticed is an article migration loop for a user. I have tracked it here - T335134. I don't think it causes noticeable performance issues, but we should still fix it.

To help track down background task crashing reasons, I pushed another 7.2.2 build out that attempts to log those reasons reported from MetricKit. Again this will only go to users that agree to troubleshoot this. I'll report back if there's any findings there.

Update - here are results from a MetricKit log over the weekend:

https://phabricator.wikimedia.org/T335077#8801346