Monday, May 13, 2019

What to Expect from Marzipan

Craig Hockenberry (tweet, Hacker News):

It will be exciting for a lot of developers, including yours truly, to press that button. But it’s also important to temper this enthusiasm with reality: that build setting is just the first step on a long and complicated road. Good interaction doesn’t come for free.

As you saw above, the Mac has seen a lot of tool and framework transitions. But this is the first transition which involves a large group of developers who don’t have any experience on the platform they’re targeting. A Mac developer moving from CodeWarrior and C++ to Project Builder and Objective-C didn’t have to learn anything new about conventions: they were still on a Mac. That can’t be said about iOS developers who are starting to use Marzipan.


Many of the thoughts in this essay got their start while developing a tvOS app: I found that having a common user interface toolkit wasn’t much help. It’s nice to have familiar UIKit items like UIImage, UIColor, and UIButton, but in the end I found that little code was shared between platforms. Some views could be ported directly between platforms, but anything involving a controller was out of the question.


Keeping two wildly different groups of customers happy with a single app won’t be an easy task, but it’s one that you’re going to be taking on with Marzipan.


It’s my opinion that Universal apps were the worst thing to ever happen for the iPad ecosystem. There’s no way for a developer to recoup the costs for new interactions and the extra work needed for more sophisticated apps. Apple makes it easier for a customer up front by offering a single download, but at the same time they make things worse because a Universal version of the user’s favorite app isn’t financially viable.

Brent Simmons:

As a Mac developer, you should do what other Mac developers do: understand and respect the platform and get help from Mac users, power users, and fellow Mac developers.

I’ve always found that Mac users are rooting for our success. They want us to make great apps — and they reward us for it. It’s a smaller, more intimate community, and warmer than iOS world. But you can also blow it by not trying, by not respecting the Mac and Mac users.

Craig Hockenberry:

Here’s a thread of some thoughts that didn’t make it into the post (it was already too long!)

Martin Pilkington:

I often feel that AppKit is under-appreciated by those who don’t have a lot of experience with it, and especially with switching back and forth between Mac and iOS development. To help try and fix that, I am going to go through some of the features in AppKit that don’t exist in UIKit. In this post I’ll cover the many controls of AppKit, and in a future post I’ll go into some of the less user-facing features.

Dimitri Bouniol:

I feel like neither AppKit nor UIKit, nor a “declarative framework” that sits on top of either, depending on the platform, is really the right answer.

AppKit is amazing in that it allows an app’s UI to easily match system conventions, but needs easy customizability badly.

Similarly, UIKit offers a huge amount of flexibility to customize system components, and make new controls, but lacks the depth that AppKit has in terms of great defaults for a newly developed app.

I feel like the ideal on both platforms would really be to have a cleaned up version of AppKit that offers the visual customizability of UIKit, but starts with an excellent set of defaults that any app should expect to have.


3 Comments RSS · Twitter

The fundamental fear and issue is customizability. I think Bouniol gets at that. AppKit is harder to customize. The tradition in iOS has always been radical individuality and customizability. I remember when an old DVD app called Disco on OSX got developers in an uproar because it violated UI conventions so much and added unnecessary animations. This ushered in an era that lasted about 5 years of customization in apps that thankfully finally fell by the wayside. There always was, from day 1, with OSX less convention adherence. Cocoa and Carbon apps frequently performed subtly differently - particularly in preference windows. You had brushed metal windows and "regular" windows. In a certain way the contemporay Mac - at least since Lion - is far more consistent than OSX used to be.

What I think many - particularly so-called greybeards - fear is that the whole inconsistent style of iOS apps comes to the Mac. It'll be like the worst of what happened to Windows in the Win8 era with so many different appearances. It's almost worse on macOS since you'll have multiple windows clashing. Since on iOS you typically are only running one app at a time (even with iPad multitasking) it's just less of an issue. Maybe this is just an issue of visual aesthetics, but I'd lay good odds that this rather than the frameworks is the concern of many.

i'm really worried about the path forward for my large AppKit app, if any...

Leave a Comment