## Summary
Accessing the NSStatusBar in an extension causes a crash; this avoids calling it in extensions. We also should not be touching the status bar in an extension either way.
## Any other notes
Didn't show up during the betas, nor does it show up in Sentry. I'm guessing it's crashing so early in the MacBridge code that it doesn't have an opportunity to deal with crash logs.
Crashes look like:
```
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
Assertion failed: (CGAtomicGet(&is_initialized)), function CGSConnectionByID, file /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/SkyLight/SkyLight-570.7/SkyLight/Services/Connection/CGSConnection.mm, line 133.
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff20504462 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff20532610 pthread_kill + 263
2 libsystem_c.dylib 0x00007fff20485720 abort + 120
3 libsystem_c.dylib 0x00007fff204849d6 __assert_rtn + 314
4 com.apple.SkyLight 0x00007fff24dad771 CGSConnectionByID + 423
5 com.apple.SkyLight 0x00007fff24f9f58a SLSRegisterConnectionNotifyProc + 31
6 com.apple.AppKit 0x00007fff236a476c +[NSCGSStatusItem addNavigationChangedNotificationHandler:] + 121
7 com.apple.AppKit 0x00007fff230fe170 -[NSStatusBar init] + 202
8 com.apple.Foundation 0x00007fff2136104c _NSFaultInObject + 27
9 io.robbie.HomeAssistant.dev.MacBridge 0x0000000107090389 MacBridgeStatusItem.init() + 105 (MacBridgeStatusItem.swift:4)
10 io.robbie.HomeAssistant.dev.MacBridge 0x0000000107090973 @objc MacBridgeStatusItem.init() + 19
11 io.robbie.HomeAssistant.dev.MacBridge 0x000000010709031b MacBridgeStatusItem.__allocating_init() + 27
12 io.robbie.HomeAssistant.dev.MacBridge 0x000000010709a295 MacBridgeImpl.init() + 213 (MacBridgeImpl.swift:12)
13 io.robbie.HomeAssistant.dev.MacBridge 0x000000010709a383 @objc MacBridgeImpl.init() + 19
14 io.robbie.HomeAssistant.dev.Shared 0x00000001037be6d9 closure #1 in variable initialization expression of Environment.macBridge + 2073 (Environment.swift:141)
15 io.robbie.HomeAssistant.dev.Shared 0x00000001037b9ad6 Environment.init() + 2150 (Environment.swift:132)
```
Adds new fastlane lanes:
- `fastlane lint` which checks the linters
- `fastlane autocorrect` which applies the linters which can autocorrect (Rubocop, SwiftFormat)
Adds a build step to the Codegen abstract target which runs SwiftFormat in lint mode, pointing out what it's going to change when run.
Applies SwiftFormat to nearly all code -- exempts a few externally-sourced files and generated code.
Fixes#1270.
Sends a webhook update with the active status as 'off' when the app is terminating. This doesn't work if, of course, the app crashes or is force quit.
In a normal Mac app, to do something when Termination is about to happen, you tell the system to hold on a sec, you do the thing, and then you tell the system you're done. Easy, right?
Well, we're a Catalyst app, so no: it definitely is not that easy. Why should we have access to an `NSApplicationDelegate` instance to do this exchange?
After quite a bit of investigation, I'm reasonably sure that `NSUIApplicationDelegate` does termination like so: if there are any existing `UIApplication` background tasks, delay termination, wait for them to complete, then complete termination.
The trick then becomes trying to get a background task started before termination starts. However, there's a problem here: the `UIApplication.willTerminateNotification` will only fire when it's about to respond to the "terminate later" with "GO!" This means we need to get in there sooner. However, there's nothing else that we can access publicly that happens sooner. In fact, there isn't even a private notification that fires for this case that we could piggyback off of, not that that's likely to be stable going forward.
One path that seemed hopeful was the `UIApplication.willResignActiveNotification` which does fire at the right time. However, it also fires when Hiding the app, so we can't use it as a "termination is gonna happen" indicator since we don't want to set active status to 'off' incorrectly.
In the end, the easiest route I could get working is to swizzle the app delegate and when we're asked whether we should do a normal termination and use this to kick off the background task. Our teed-up background task for the webhook update, live-signaled by the active status changing, both prevents the termination and does the update.
In my testing this works for every mechanism of clean termination I could think of: Quit menu item, "Quit" from Activity Monitor, system shutdown.
