Here it is! What's New in UIKit in iOS 26. This was a pretty mammoth undertaking, and it shows – a whopping 64 minute read! I'll be keeping this article up to date over the beta cycle. Possibly littered with errors. Shout at me if I've made any stupid mistakes. Link below 👇

After almost 3 hours in review, Duet’s iOS 27 update is ready to go* *Unfortunately, this is not including the added iPadOS support because…I’ve gotta make screenshots 🫠

Oh, the joys of dealing with ASC infrastructure on a dodgy hotel Wi-Fi network... 🫠

Duet's iOS 27 update isn't _really_ ready but it's also going to have to be... 9K lines of code, 347 commits, and 250 files changed. Still got a bunch of bugs to iron out before I'm happy with it, but they can come in 1.6.1 patch.

Shoutout to @_inside for tracking down the implementation of the iPhone Duo’s fold effect in record time. SBContinuousFoldEffectViewController “just” appears to be using a CAMeshTransform on backdrop layer, with a variable blur filter, and some carefully placed gradient layers. Beautifully simple.

@SebJVidal knows more than anyone about UIKit internals, mostly through the most straightforward kind of reverse engineering: runtime reflection using Objective-C selectors. Most of Apple’s frameworks are Obj-C based. Thank John Scuelly, Steve Jobs, and NeXT for that. This makes frameworks like UIKit more-or-less transparent, for those with eyes to see. Dynamically picking selector strings at runtime is the linchpin of private API work. In your Swift code, you never lost access to the Objective-C runtime: just call NSClassFromString, NSSelectorFromString, and all their friends to initialise underscored classes and “private” APIs. The _UINavigationBarPalette (Seb's favourite API) is one of these underscored views: it lets you attach arbitrary views onto a navigation bar, but without losing the useful a11y, size transitions, and automatic layout that makes most custom UI so Temu-esque. Apple uses this a ton internally for apps like Calendar, Fitness, Photos, and Messages but jealously guards it from mortals. Read “Forbidden iOS” here 👹 blog.jacobstechtavern.com/p/…

This update is HUGE. I don't mean important, although it is pretty important depending on how well the iPhone Duo sells... But there are *839* additions to the UIKit headers compared to the last 27.0 beta. Compared to the 955 additions we saw comparing 27.0 beta 1 with 26.4.

Or better yet… 🗑️

The Xcode 27.2 beta is here and, subsequently, as is the iOS 27.2 SDK. Despite no device or simulator support, this update is chock-full of new UIKit API for supporting the iPhone Duo. Someone should write about all of this...

[AVPlayerLayer playerLayerWithPlayer:]

Also (and I’m guessing here as AFK) I believe UIKit uses these SwiftUI glass effects under the hood to render the UINavigationBar and UIToolbar animations? Both bars use _UICoreHostingViews to render the glass platters, which house representable _UIButtonBarButtons – what a name!

Lot of speculation and misinformation floating around about SwiftUI today! I've done some reverse engineering of all relevant frameworks (including private frameworks), and I've made some interesting discoveries about SwiftUI that disprove a lot of the noise. More soon.

Small (almost unnoticeable) detail, the pitch button’s label animates in 3D thanks to some CoreAnimation trickery. The label itself comprises of two UILabels, rotated using a CATransform3D. When the map becomes pitched, one label’s transform3D gets reset to its identity transform, the other is rotated and translated on the Z axis, resulting in this rotating cube effect.

By this logic, the fluid interactions on the iOS Home Screen aren’t native either (they run on a display link). Core Animation is great at what it does. But there’s a reason many of the best interactions in the OS tick their animations in-process rather than handing them off to Core Animation, even when built with UIKit. How do you think UINavigationController drives its interruptible transitions? Or the morphing glass controls in the navigation bar? These are advanced techniques, sure. But oversimplifying this stuff does a disservice to people trying to build great apps. “Technically dropped zero frames” and “feels fluid and alive” are not the same.

If SwiftUI isn’t native because it bypasses the CoreAnimation render server and animates views client-side by directly manipulating the platform view’s properties… …does that make UIKit/AppKit not native if you manipulate these properties, or animate using a UIUpdateLink? 🫠

Fun fact: the creator of CoreAnimation is one of the creators of SwiftUI! The decision to run animations in the app process rather than the render server (as CoreAnimation does) was one of the earliest and most fundamental decisions we made when designing SwiftUI. Some of the most distinctive experiences of using an iPhone, like UIScrollView rubber banding and SpringBoard app switching are only possible as client-side animations. But these experiences aren’t easy to build with UIKit! This is because if you want a UI to be fully interactive and interruptible by the user while it’s animating, it has to be running in the same process as the event handling. In fact, in iOS 18 we added new APIs to AppKit and UIKit to adopt the SwiftUI client-side animation model. There are a lot of valid critiques of SwiftUI. The fact that SwiftUI doesn’t use CoreAnimation for its animations is not one of them.

🚨 I rebuilt imessage/discord, but only for app founders introducing ChatMRR – the verified revenue community where you can only join groups based on your MRR → connect @Superwall or RevenueCat → join chats w/ revenue minimums → unlock new chats as your revenue grows → daily leaderboards & awards limited spots → mrr.chat

Genuine question: do we feel Xcode 27 is significantly more stable than 26? Apple made a song and dance out of this during the keynote but I'm still getting the dreaded "Xcode quit unexpectedly" reasonably often...