Ian Ynda-Hummel

I'm not sure it's the `constrain` overloads. I've tried reducing it to only the array call with no meaningful difference in compile time.

For what it's worth, anecdotally this seems to be a lot faster for me nowadays.

Nothing. Swift compiler changes seem to have improved the type inference, which is what I think was slowing it down.

Again, this is somewhat anecdotal. I haven't done any thorough timing tests.

Yes. It's possible I've just adjusted to my capricious robot overlords. I'll do some more thorough timing when I get a chance.

Hm. My main concern here would be not passing review. I just tested it and in an app extension it _does_ respond to `sharedApplication`, returns an application object, and then...

Did a bit more testing and it seems like the interactive frame changes don't work from a share extension, so there's definitely something weird with those windows.

I expect today extensions are hosted differently than share extensions are. Share extensions are hosted by an application's process, so there would be different dynamics. Just not including the library...

This still triggers the `UIApplication` getter. It's `let` so it's not lazy loaded. Even if you make it lazy loaded, though, the `startWith` combined with the nil coalescing means that...

I'm worried about both, but accessing it is probably worse.