Unknown Mortal Orchestra - Can't Keep Checking My Phone link

Ownership and +1s

Yesterday, hell froze over.

Many people have written about the change in Apple’s external engineering culture. With the announcement of Swift at WWDC 2014, Apple seemed to have relaxed its notoriously tight-lipped communications: Chris Lattner is candidly answering questions in the developer forums, there’s a Swift development blog and I’ve even had a radar resolved! While matters are definitely changing for the better, a company of Apple’s size has insane inertia and good things take time.

So it comes to little surprise that, when ResearchKit was announced as an Open Source project, many members of the community were skeptical. But where the “old” Apple would have handed a zip archive to registered Apple Developers and called it a day, the new Apple now has a GitHub account.

A GitHub account. Apple.

I don’t think anybody would have imagined this two years ago (cue the never happened under Steve) but there’s even more: the ResearchKit team have expressed interest in adding a podspec for official CocoaPods support.

I’m glad they understand that in order for ResearchKit to succeed, they need to get it as many developers’ hands as possible and CocoaPods has done a lot to lower the barrier to entry for using third party dependencies.

However, if Apple can step up their Open Source game, we can too.

The Pull Request to add the aforementioned podspec file quickly filled with 👍s. While I understand that those emoji were well intended and only meant to express support to the cause–hey, it beats duping a radar–the thread got very noisy very quickly. As someone who maintains some Open Source repos myself, it pained me to see that the ResearchKit team’s first foray into the public iOS community was met with such clutter.

Again, I’m sure that those 👍s had only the community’s best interests in mind, but I think there is a certain sense of entitlement in our part of the Open Source world when it comes to support for some random iOS version, the dependency manager of the day or fixes for arbitrary crashes in your app, which may or may not be related to the project in question.

Let me tell you, nobody likes to maintain iOS 7 support in their spare time.

Bumping or 👍ing that issue for the twentieth time is probably not going to do anybody much good. The thread becomes harder to follow for everybody and the maintainers get more email at best and a sense of guilt at worst.

Open Source projects rarely come with a Service Level Agreement. There are many reasons to pursue Open Source just as there are many other interesting things in life. Look at the list of contributors to your favorite OSS project and imagine what would happen if they all pulled a __why, as they have every right to.

If you decide to incorporate someones project into your app, especially if you write said app as part of your day job, you have to be willing to support that project when the poop emoji hits the fan. That can mean using your own time and engineering resources or financially supporting said contributors. I don’t think many people would balk at the opportunity to get paid for working on something they started out of their own curiosity.

But maybe money is tight and you don’t have the knowledge necessary to support every project. That’s cool. If you don’t think you have the skills to fix a problem yourself, try regardless. A Pull Request will always get you further than an Issue. Even if it breaks the build, it shows that you value the maintainers’ time highly enough to match it with some of your own. It’s also a great opportunity to familiarize yourself with a code base and learn a thing or two.

Update: Thanks to Ayaka and Orta for their Pull Requests on this post 💛.

I’m In Love (Poolside Remix) link

Mantle 2.0 link

After a long wait, Mantle 2.0 is finally here. I got the opportunity to write most of the additions and learned a lot from Justin’s insightful code reviews.

For those that upgrade, it brings rock-solid error handling and makes it easier to extend adapters to handle reoccurring transformations. Check out the whole Changelog for the nitty-gritty. I’ve been using it in production for a while, and it being so solid was probably the main reason why the milestone was stalled at 95% completion for so long.

Sadly, I don’t think we’ll ever see a Mantle 3.0., now that Swift shows us a clear way forward in terms of value types and immutability that is not really compatible with Mantle. It’s fundamentally an Objective-C project.

That being said, you should definitely have a look at my buddy FelixPistachio framework, it shares many of Mantle’s ideals and is easy to mix with specific serialization formats, like Argo for JSON.

I hope you find Mantle useful and if you use it production, I’d be happy to hear from you.

Few.swift link

Josh Abernathy just open-sourced his take on ReactNative, Few.swift:

Few.swift lets us express UIs as stateless, composable, immutable-ish values of their state. When their state changes, Few.swift calls a function to render the UI for that state, and then intelligently applies any changes.

To put it another way, the state is the necessary complexity of the app. The view is a mapping from state to its representation.

This is super cool because the only thing that’s mutating is the state. Few.swift is in charge of making an in-place changes to the UI when the state changes.

Exciting times.

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.