I've been seeing a lot of opinions on this topic and decided to articulate some of my own after having spent a month primarily using an iPad for nearly everything. I've closely monitored the few cases where I've needed to use my MacBook Pro and effectively made a list of things iOS should implement for feature parity with macOS.

(Check out the project over here.)

After having been a consumer of the Core Animation (originally LayerKit) framework for about a decade now, I began to wonder how it was designed and implemented under the hood. Not simply the surface details such as "it's rendered out of process" or "it handles the animation interpolation for you" or whatnot, but more specifically, HOW all of its beautiful bells and whistles translate into nitty gritty graphics ideas and associated draw calls. I figured the best way was to try to build it myself from scratch!

Like I said in the previous "episode", recently, I've wanted to get around to adding "hot key" support for Parrot, and realized I didn't like any of the existing solutions:

1. Use MASShortcut or ShortcutRecorder which are tried and proven to work in ObjC-land.
2. Use a new but not proven Swift hotkey recorder (there's a few out there).
3. Roll my own (probably somehow using dangerous private SPI) and not test it at all!

Obviously I went with option #3.

And here we are now, onto part two of the thrilling saga in which you witness me breaking AppKit and WindowServer and inviting the wrath and fury of the engineers that work on said components. I hope you brought your popcorn.

Okay, well, maybe not better, but at least, not under imminent threat of deprecation - and even that is questionable, because we'll be using [Private SPI] (I mean, would you really be here reading this if it didn't? At least I've marked it all so you can cut it out for MAS apps.)

Recently, I've wanted to get around to adding "hot key" support for Parrot, and realized I didn't like any of the existing solutions:

1. Use MASShortcut or ShortcutRecorder which are tried and proven to work in ObjC-land.
2. Use a new but not proven Swift hotkey recorder (there's a few out there).
3. Roll my own using dangerous private SPI and not test it at all!

Obviously I went with option #3.

Most developers know of Core Animation through its few key classes, such as CALayer and CAAnimation, and their subclasses. Very few need to venture past this realm to take advantage of this powerful framework. What's not very clear to most is how many faces the framework takes on; there are three: CoreAnimation, CoreAnimationCF, and the internal C++ CoreAnimation underpinnings.

CALayer has internal/private support for two pretty cool things: archives and states. We'll talk about states first, as they're the more complex part of the exercise.

In the macOS 10.13.4 beta, I spotted a new CALayer class called CAPortalLayer being used in AppKit, and apparently also in UIKit. After looking into it a bit more, it turns out it does exactly what CAPluginLayer did for CGSWindow/NSWindow but for CALayers!

There's a lot of cool CoreAnimation goodies hiding around in the private headers, but there are three private CALayer classes that really caught my eye: CAProxyLayer, CALayerHost, CABackdropLayer, and CAPluginLayer. CALayerHost is similar in design to CARemoteLayerClient/Server, so I'll be writing about both of these classes in a later post. I experimented with CAProxyLayer a little bit, as it's used for visual effects (think NS/UIVisualEffectView) and either I didn't know the right constants or wasn't using it correctly, but I couldn't get it to work reliably without nuking windowserver. I'll talk about the remaining two, using code samples.

Around two years ago I began looking into ViewBridge.framework and a bunch of related frameworks as a side-project, mostly for fun. Realizing I had figured out most of it but just hadn’t put it together, I assembled a quick demo project that worked almost instantly with ViewBridge. All I had to do was create an XPC service, add a few Info.plist keys, grab the headers (I cleaned a few up) and I was on the road.

Similar to iOS, macOS recently gained Picture-In-Picture mode for videos; so far, only Safari seems to support it out of the box. The question remains: why isn’t it a public API? That’s a question we’ll never have an answer for, but as it turns out, PIP.framework does exist in the PrivateFrameworks realm, and a quick job of reverse engineering shows exactly how it works.

Recently I’ve been doing a lot of reverse engineering in the PrivateFrameworks department, simply out of curiosity. One thing that really always bothered me was how to insert a view hierarchy across processes — and I was interested in seeing how Apple had done it. A few frameworks of note: ViewBridge.framework, PlugInKit.framework, LaunchServices.framework, and finally, libextension.dylib. The last one is a bit weird because it’s actually a high level Objective-C framework that’s tied into AppKit — but for some reason has been relegated to /usr/lib (but is now located in Foundation.framework in macOS Sierra). All of the frameworks above use a common transmission medium: the NSXPCConnection API, which internally wraps the libxpc.dylib library, found in /usr/lib/system.