Reading Between The Lines On Marzipan

John Gruber today posted some reliably sourced rumors about Apple’s cross platform efforts. Most notably, he’s placing any changes in 2019, and not at WWDC 2018, and casting doubt that what Apple is doing is UIKit on the Mac. (And if you follow me on Twitter, you’re likely aware that I feel that UIKit on Mac would be a bad move.)

  • “XKit” not assured. I read iMore’s article first and got quite excited about the prospect of an “XKit” framework, a unified framework that would replace UIKit (but I think was reading the original, pre-Gruber update article.) It’s worth noting that Gruber’s rumor says nothing about a new UI framework, only a new UI API and declarative toolkit, which is very open ended. API could mean anything between a new class (a la NSNib), or a full set of new frameworks. Later in his post, Gruber speculates that this new API and declarative tool could abstract UIKit and AppKit, or be part of a new UI framework, which is fairly non committal. The Gruber post also does not imply there are dramatic UI changes being made to macOS or iOS to support this new API, but I could see a declarative toolkit opening previously untapped creative avenues. Certainly Apple will want to dogfood such an API on a few applications, which could mean a few new crossover applications, possibly in both directions.
  • Declarative control API. Apple wouldn’t be the first to have one, and declarative UIs are typically written in a markup language, meaning it wouldn’t necessarily be in Swift (or Obj-C). Android has Layout XML, and Microsoft has XAML. I think Apple’s Xib format is also very similar, but I don’t know of any developers writing Xib by hand, and I think the format is too cumbersome to write by hand. Xib also does nothing to abstract the platform differences.
  • Auto Layout. A declarative control API also sounds a little bit like Auto Layout, although Auto Layout is missing is a way to declare controls themselves and not just the relationships between controls. It’s possible whatever Apple is working on is being built on Auto Layout. (Did you know that Auto Layout already has a declarative UI language? It’s uhhhhh…. interesting.)

Other things to watch for:

  • Tooling. A declarative control API, especially using a markup language like XML, opens up a lot of tooling possibilities. Apple could extend Interface Builder to create these declarative APIs, but I would love them to return to more powerful standalone UI tools. When Microsoft unveiled XAML, they also unveiled a tool called Sparkle, which eventually became Microsoft Expression. The demo video is 13 years old now and is a little dated in a few ways, but I think is still worth a look. Even if Apple doesn’t come in with a high end tool, it would make it easier for a third party developer to come in and fill the void.
  • Dynamic Swift. There is room for this new technology to be all Swift based, but generally I’d still guess like other platforms this is still a better fit for a markup language. The Swift team has been hinting at more dynamic features, and I wouldn’t count on this getting us closer towards being able to deal with our declarative UIs using static style programatic development. I think this will still look like loading the declarative API from an archive format at runtime. It’s speculation. But Swift feels like way too heavy of an option for writing declarative API.

All in all we don’t know much about Marzipan, or whatever it is called now. But my hunch is it’s a tool to help us deal with UIKit and AppKit, and not a tool to replace it. Although changes to keep us from having to deal with NSView vs UIView would still be welcome.

Leave a Reply

Your email address will not be published. Required fields are marked *