« The Road

Them »

In yesterday's earnings call Apple said that the 14% increase in iPhone revenue growth was mainly driven by sales of the iPhone X. According to Apple, the iPhone X was the most popular iPhone every week of this past quarter.

This is notable because various media outlets have been writing articles about how badly the iPhone X is selling and that production has been scaled way back.

Through it all, Apple said nothing.

I was in LA a couple of weeks back and some analysts pointed to the negative articles and Apple's lack of response as proof.

It wasn't.

Sometimes Apple leaks things to set expectations but usually it's in the other direction. Usually their leaks are to temper expectations.

Suppose someone publishes a rumor that Apple's new iPhone 9 + opens up into a self-driving scooter and it flies.

Inside Apple they're bummed that the scooter plans got out but they're also worried. They tried to make the scooter fly but they just couldn't get it to work.

What do they do?

If they do nothing then when the phone releases in September the headline reads, "Apple misses mark with phone that can't even fly".

So they call someone. In the old days it was probably Walt Mossberg, now it's probably John Gruber, and say, "look, you can report that a source inside Apple told you that this scooter thing is real and will require some sort of subscription but Apple is not going to release a phone that flies this year."

This tempers the reaction On the one hand, now everyone expects the self-driving scooter and knows that there will be some sort of monthly fee. The demo will still be cool. Apple fans will line up to buy one. Apple-hating reporters will explain why no one will ever buy it.

Anyway. What does this have to do with Marzipan?

When you read a report based on first and second hand inside sources, you need to ask why those sources talked to a reporter. What is it they want to accomplish?

That's not a criticism of the reporter running the story, but people told their story for a reason.

And so there was the Marzipan story back in December about how Apple is merging the UIs for iOS and macOS.

Earlier this week Gruber ran a story with some follow-up details.

What does John tell us?

THE NAME: He says the name is not currently "Marzipan" and he has hashed the name that he knows so we can later verify that he knew the name. The name isn't important.

WHAT IS IT?: John says it's a declarative control API. He guesses that it abstracts the API differences between UIKit and AppKit. He provides a lot of wiggle room here but says "perhaps the logic is simply that if they're going to create a cross-platform UI framework, the basis for that framework should be a declarative user interface."

I don't know anything but a lot of that doesn't sound right to me.

The following is my guess.

I love Swift.

So much of what makes Swift great is it is a fresh start that builds on what we know from so many other languages. Swift is still evolving - we still don't have the new ownership model or a great asynch solution - but they're coming.

One of the biggest pain points for those of us coding in Swift is interacting with Objective-C.

I'm not saying there's anything wrong with Obj-C. I'm saying that Swift and Obj-C are fundamentally different in their approaches to many things (in particular nil).

UIKit and AppKit are built in Objective-C and are class based hierarchies. We're used to inheriting from classes that inherit from NSObject or UIViewController. We put up with implicitly unwrapped optionals because of the way Storyboards and Nibs are loaded.

Now that Swift is stabilizing, one of our greatest needs is for a Swift friendly UI framework.

The fact that it is declarative or cross-platform is less of an issue, but...

As long as they are rethinking the UI framework, they can certainly consider whether we need NSColor and UIColor or whether a single Color class will do. Are NSButtons and UIButtons really different or can we just have a Button. That doesn't mean that we are headed towards a single UI from the consumers point of view and it doesn't mean that developers are writing a single UI that works on multiple platforms. It just means that perhaps our building blocks are the same.

This audit is most important in UIKit and AppKit but other frameworks benefit from this second look as well.

CoreData is built around NSManagedObjects and is written for Objective-C style coding. A more Swift friendly data abstraction would be welcome.

There are so many frameworks that could benefit from being reconsidered in the world of Swift and multi-core processing.

Couple this with the (no-doubt correctly) rumored move to ARM chips on the Mac and the time is right to revisit these pieces.

While I'm dreaming, I imagine a world in which Apple gives us the tools to build these new apps or even reconsiders what it means to build apps.

Back to Marzipan. Back to UIKit and AppKit and a new UIFramework. In my dreams, Chris Parker and Ali Ozer each choose five engineers and work out the details of this new world.

Yes, I understand why this can't happen, but it's my dream.

It's the same dream that gives me a phone that turns into a flying scooter.

Gruber's final paragraph is WHEN.

This is why his sources were willing to talk to him. They want to make sure people don't come to next month's WWDC expecting to see this new framework. Gruber says that you should "set your expectations accordingly for this year's WWDC."

Apple doesn't want people coming away from the conference complaining that the new OS doesn't fly.