Hozier – Take Me to Church link

Directed by David LaChapelle.

Beyond UXKit

Yesterday, Apple seeded the beta version of 10.10.3 to developers. It contained the long-awaited Photos app, an overdue successor to iPhoto. It also contained, however, a much more unexpected surprise. When poking around the app’s internals, Jonathan Willing came across a new internal framework, he wrote:

The new Photos for Mac is based on a new private framework in 10.10.3, UXKit. It is essentially a replica of UIKit, based on top of AppKit.

It includes favorites such as UXView, UXNavigationController, UXControl, UXCollectionView, UXTableView, UXLabel, UXImageView, and much more.

Since UIKit was built with years of experience of AppKit being in production, many consider its APIs superior to AppKit’s. Bringing those interfaces over to OS X would make it easier to switch between the two platforms and even allow for cross platform code where the interaction patterns permit it.

This got a lot of people pretty excited.

Now, we don’t know if UXKit is more than just a convenient shim built by the Photos team and if it will ever become a public framework, but even if it will, it won’t be enough.

UXKit is not a leap forwards, it is at best a sidewards step over the platform gap. The whole paradigm of stateful UI components being whipped into shape on the main thread is broken beyond repair.

- (void)userDidLogIn:(NSNotification *)notification {
    [self updateAllTheViews]; // You better be on the main thread.

It’s 2015 and you can’t even layout an off-screen view when you’re not on the main thread. We need something better.

React and beyond

Facebook recently announced React Native, the iOS and Android extension to their existing React JavaScript framework for building data-driven UIs in the browser. A lot of people reacted (ha) like this:

Ewww, JavaScript.

– Too many people

I’m floored that the same community that complains that 40-year old language features like generics needlessly complicate their precious Objective-Blub would get their collective nose all up in the air about JavaScript this way.
As Josh Abernathy put it, JavaScript is an implementation detail.

A couple years back, the same smugness of platform superiority hung around when Facebook ditched their HTML5 based app (rightfully) for a native implementation. Little did we know that there would be a lot to learn from the DOM-slingers.

See, I don’t know or care if React Native will be what we all write our apps in two years down the road, but this is not about HTML, it’s not about CSS and it sure as hell ain’t about JavaScript.

It’s about expressing your application’s user interface as a function of this signature:

public func updateUI(state: State) -> RootView

A pure function like that doesn’t need to care what thread it layouts your views on. Imagine being able to layout all your table-view cells in parallel. (Facebook’s AsyncDisplayKit demonstrates some of the performance gains that can be made by offloading UI calculations to the background.)

An inert representation of your entire view hierarchy is also much easier to persist than an a tree of UIViews. When was the last time you implemented -[UXView initWithCoder:]? Imagine iOS simply restoring the last view hierarchy on app start.

Similarly, such a serialization format could be written directly. I’m not the world’s biggest fan of JavaScript, but I’d prefer merging a JSX file over a nib file any day of the week.

If it is completely encapsulated, hot-swapping your layout code suddenly becomes feasible. Every modern browser ships developer tools that beat Interface Inspector and Reveal single-handedly. Imagine being able to attach Interface Builder to your running app, restructuring it on the fly while all data is being preserved.

And that’s only the beginning. Even impressive touch interactions can be described in only a few lines of declarative constraints.

Only Apple can do this

There’s been a lot of talk in the previous months about the perceived decline in Apple’s software quality. While I don’t doubt that a lot of excellent work is being done inside Apple, from the outside it’s still a black space-gray box.
I just hope that somewhere inside that box, a true successor to UIKit is being built, something that will take us to the iPhone 12S and beyond.

We can’t reap the full benefits of Swift’s powerful language features if we’re being constrained by UIViewController in its current form. We won’t easily maintain a smooth 60 fps if even basic layouting is shackled to the main thread. We need to pop our filter bubbles and steal the best ideas from Android, the Web and 1973.

I’m no longer fully sure that the future of iOS UI engineering will come out of Cupertino, but I’d love to be proven wrong in June.

We need a Safari View Controller link

Bryan Irace:

It’d be wonderful if Apple provided a “Safari view controller” that developers could present directly from within their applications. This controller would run out of process and work almost exactly like MFMailComposeViewController and MFMessageComposeViewController already do for composing emails and text messages respectively. The app would provide the controller with a URL (and optionally, a tint color), but otherwise what the user does in it would remain secure and isolated from any third-party code, yet fully integrated with Safari.app and Safari controllers presented by other applications.

This can’t happen soon enough.

Serial Soundtrack link

The soundtrack to the podcast sensation by Mark Phillips:

Smooth asynchronous user interfaces for iOS apps — AsyncDisplayKit link

Facebook open-sourced their AsyncDisplayKit:

AsyncDisplayKit is an iOS framework that keeps even the most complex user interfaces smooth and responsive. It was originally built to make Facebook’s Paper possible, and goes hand-in-hand withpop’s physics-based animations — but it’s just as powerful with UIKit Dynamics and conventional app designs.

They’ve mentioned this multiple times before in their tech talks on Paper, I’m glad it’s finally out.

Anita Sarkeesian at XOXO Festival 2014 link

How to host speakers who also happen to be parents of young children link

My former boss Caroline gives some great advice on how to accomodate parents as speakers:

A tiny human shouldn’t get in the way of a great talk though. And it turns out that a lot of great speakers also become parents. As a conference organizer, what can you do to help make your event more accommodating for a speaker with a baby (and thus get a kick-ass presentation)?