Wordpress-ios: Launch timeout on iPhone 6 Plus

[koke]

We've had some reports of the app crashing right after launch, and inspecting the user's crash reports it looks like it's timing out and being killed:

Exception Type:  EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d
Termination Description: SPRINGBOARD, scene-create watchdog transgression: org.wordpress exhausted CPU time allowance of 4.31 seconds |  | Elapsed total CPU time (seconds): 23.710 (user 23.710, system 0.000), 100% CPU | Elapsed application CPU time (seconds): 5.314, 22% CPU | 

The stack traces are all different but somewhere inside the launch sequence.

[gemmagarner]

Reported in 1030062-zen (iPhone 6s, iOS 10.2).

[gemmagarner]

Reported in 1040635-zen (iPhone 7, iOS 11.2)

[gemmagarner]

1040782-zen (iPhone 6, iOS 11.1)

[koke]

Tagging for groundskeeper rotation. I know it's hard to work on this since we can't reproduce consistently, but let's try something:

• Investigate if we can get metrics of the amount of timeouts on launch (I'm not sure Fabric's crash count is including this).
• Profile the startup sequence and make sure only what is essential is blocking the app launch.
• If there are no clear solutions, let's document what's happening on launch and why it can't be deferred.

[brucea8c]

I checked in with the user in 1040635-zen and she reported that the problem is no longer happening.

[designsimply]

Because the original issue was filed over a year ago with no new reports for ~1y and at least one report saying the problem is no longer happening, I'm asking that a Groundskeeper please investigate following @koke's notes and report what you find. Please close the issue if it is no longer actionable based on the findings.

[jklausa]

We're gonna have some quick wins here with the Swift runtime libraries being integrated into system soon — reducing the number of binary images we need to load.

I profiled the method and it looks like most of the work is essential — we _could_ refactor some things, like moving the initialisation of UI/Core Data to _after_ willFinishLaunching but that seems rather fragile. I'll write up my findings in more details.

[jklausa]

So, here's a slightly-edited brain-dump from my notes when investigating it:

1) We get a fairly large performance hit on launch from loading a bunch of frameworks. This is fairly well docummented issue. Since CocoaPods 1.5.0, we can integrate our Swift dependencies as _static libraries_, instead of framework binaries (altough... Zendesk might mess that up...) — we should take a look at looking if that benefits us. Upcoming Hack Week seems like a neat opportunity ;)

2) We do a lot of work in application: willFinishLaunchingWithOptions callback in AppDelegate, most notably running Core Data migrations. It _makes sense_ to do them there, but it's problematic on older devices with big databases and/or a lot of migrations to run.

I profiled the app launch startup and there wasn't anything egregious there that should be delegated later — and most of them are very unlikely to have pathological worst-case performance characeristics that would push us over 30s of walltime watchdog timeout — apart from the migrations.

It's way beyond the scope of single groundskeeping rotation (and my comfortableness with messing with such critical section of the app), but I believe upcoming Hack Week could also be a good opportunity to try delaying the migrations _after_ didFinishLaunching has returned. It's not a easy or small project, but I believe it would alleviate those crashes.

[astralbodies]

I've long wanted to make the app launch asynchronous to when Core Data is ready/available. Think of it like in some apps launch with a "wait screen" while the DB is migrated to a new version. When the db is ready and migrated then the UI is brought up. This would require some architectural changes potentially but not an insurmountable task. Lots of testing ... LOTS of testing.

[jklausa]

Yeah — that's the gist of my idea too, basically just keep showing the splash-screen while the migrations run in the "background". I tried doing a 3-h spike to see how much work it would be, and it seemed... _plausible, but tight_ to maybe do it during a hack week.

[designsimply]

Moving this out of Groundskeeping and into [Type] Tech Debt and will circle back to review it again at a later date since it didn't get picked up during Hack Week Apr 2019. Thank you so much @jklausa for your work looking into this crash!

[designsimply]

Circling back and noting that a similar-ish sounding issue was recently closed as unable to reproduce at https://github.com/wordpress-mobile/WordPress-iOS/issues/12941.

Closing for now because the issue is old and we investigated it more than once without being able to reproduce the problem in our own testing. Feel free to reopen if it can be reproduced again.