More Ups Than Downs

Rumor has it Apple is cooking up a new framework that helps unify the development of macOS and iOS apps. At least, that’s the part of the rumor that makes the most sense, anyway.^[1]

Code-named, Marzipan, this new framework would help developers who make either iOS apps or Mac apps to make both using the same basic toolset. Obvious differences between the platforms would necessitate some variation, of course (clicks vs taps, and all that), but the underlying APIs for creating either would be largely the same. And thus, perhaps you could even create (and sell) a single app binary that is capable of running on either platform, if you choose.

Rather than a straight port of iOS’s UIKit to the Mac, as some have requested from Apple for years, Marzipan would more likely be a new framework that replaces both AppKit and UIKit in favor of something more modern and clean.

However they go about it, the million-dollar question is: Would this be a good thing?

Let me start with the short version: Yes. Of course this would be a good thing. There are downsides, to be sure. But to me, the good outweighs the bad here.

Let me start with the downsides.

This will lead to a lot of crappy iOS ports on the Mac

No doubt about it. Thousands of previously iOS-only apps will end up on the Mac barely altered with bad UI on day one. Count on it. Remember how many terrible watchOS apps debuted minutes after watchOS was made available? Apps that had no place on the Watch, that tried to do way too much on the Watch, that didn’t understand the utility of the Watch, and so on? That will absolutely happen on the Mac, too. It will still take time and effort to make a good Mac app, and many developers will not bother. They will try to make a quick buck.

But who cares? The last time I checked, there is already a ton of crap available on the Mac. A few thousand more bad apps will be a blip on the radar.

Here’s the thing: People who care about good software will find the good stuff. People who care to make good software will make the good stuff. There aren’t many people in either group. And there never will be.

Developers who care about making great software keep wanting the majority of people to give a shit. They don’t. Find your little niche and set your business model accordingly.

This will lead to a repeat of iPhone and iPad Universal apps

When Apple made universal storyboards available on iOS, the promise was it would now be easier to make apps that run great on both iPad and iPhone. Looking at the disparity between the number of iPhone apps and iPad apps available, Apple decided getting more apps on iPad was a priority.

The result was a ton of new apps that now run natively on iPad but are little more than “blown up” iPhone apps. They don’t use the extra power and screen real-estate available on iPad in any fundamental way.

There are some apps, however, built with universal storyboards that take full advantage of iPad. The problem here isn’t the tool, but rather the people using the tool. The same will be true for Marzipan apps.

In the hands of lesser developers, any tool will be used to create crap. That’s no reason for the rest of us to keep using clunky tools.

This will negatively impact some businesses

Some developers make iOS and Mac versions of the same app and sell them separately for a one-time upfront price. If Apple makes a “universal” buy once-run-on-any-Apple-device binary possible, the customer expectation is likely to shift, and people will simply expect to have to pay only once.^[2]

I don’t have a lot to say to these folks, except you are correct. If you currently sell a paid-up-front app on iOS and Mac, there will be some customer expectation and pressure to make your app universal. And more than likely that will be coupled with the expectation of lower prices, too. There’s not a whole lot you can do about this, except:

• Don’t go universal: Fantastical has pulled this off for years on iOS, refusing to make the app a single purchase on iPad and iPhone. They get complaints, I’m sure. But they aren’t exactly going out of business over it. And given there are a lot of iOS users who don’t use the Mac, there may be at least a slightly stronger argument for not having to pay extra for a Mac app they will never use. I suspect more developers will go the non-universal route this time around. And given this is not a simple matter of screen size, as it was on the iPad, a port of an iOS app to the Mac, even using Marzipan, is going to take quite a bit of time. It will be a while, in other words, before the pressure from other developers gets extreme to start selling your existing app as universal. So you have time.
• Get out of the paid-up-front business. Apps like Ulysses have shifted to a subscription model for a reason. They see the future coming. Yes, I know subscriptions aren’t for every app. But two years ago, a word processor would have been on most people’s list of can’t possibly go subscription apps.^[3]

Undoubtedly, businesses will fold after Marzipan. And that’s a shame. But many of those businesses are likely going to fail, anyway. Others will adapt. The world has largely moved on from paid-up-front software. We’re long past the point where Apple (or anyone else, for that matter) is going to hold back on anything because it might hurt paid-up-front app makers. Sugar-coating that would be cruel to those who have been and continue to be affected. Better to be honest than spread false hope.

Eventually, UIKit and AppKit will end up like Carbon

It stands to reason that after Marzipan gets released into the wild, both UIKit and AppKit will be on “borrowed time.” Just as Cocoa replaced Carbon, eventually Apple will very likely want all apps to be written using Marzipan.

This is not such a huge deal for small utility apps. But consider an app like Photoshop. Or BBEdit. Those are massive codebases. For any company that’s had a Mac app since the early days of OS X, Marzipan is going to mean a lot of work rewriting bits that are currently working just fine. And that sucks.

Even larger iOS apps, like Procreate or Ulysses, would not be a small conversion job.

Now, very likely, there would be a generous grace period, just as there was with Carbon, where AppKit and UIKit apps could continue to run and be updated. Marzipan will very likely be optional for at least a while. (I’m thinking right up until the entire Mac hardware line goes ARM.) And in the case of macOS, I’m sure AppKit apps would continue to run for a long time, even past the point where Apple stops accepting them in the Mac App Store.

But eventually, Apple will start dropping hints at WWDC: “We believe Marzipan (or whatever the official name will be) is the way to create the best user experiences moving forward.” At which time you’ll know you have a couple of years to get your legacy code converted.

There’s no way around this being a pain in the ass for some developers. In fact, if there’s one group of people who have the biggest reason to gripe about Marzipan, it’s the folks with the largest legacy codebases. But technology marches on. It would be hard to argue that Apple should have allowed Carbon to go on this long.

Another thing to consider: The retirement of Carbon led to new opportunities for a lot of developers. Legacy companies spent years rewriting their Carbon-based apps, which gave small indies the opportunity to start fresh in Cocoa, move faster, and create legitimate competition. ^[4]

With any luck, Apple will make the translation over to Marzipan as painless as possible. Who knows? Apple isn’t as powerless in this transaction as it was in the Carbon days. So they could tell us to go pound sand, if they wanted to. But I suspect they will want to make this transition smooth.

So that’s the bad news. What do we get in return?

At least a few good iOS devs who have never tried macOS development will likely give it a try, and vice versa

Gus Mueller wrote a piece last week about Marzipan, suggesting that no miracle framework can be a panacea for all the problems associated with porting iOS apps to the Mac. He’s absolutely right. The hardest part of making a Mac app, or any software, for that matter, is never the framework. Anyone can learn to write code that executes. The challenge, as Mueller puts it, is caring enough to do it well.

No framework can make developers care more about making great things.

But speaking as someone who does care, I sure wouldn’t mind if Apple made my life a little easier.

Imagine you’re pushing a rock twice your size up a hill. It’s snowing, and you have no shoes or coat on. Someone is on the other side of the rock pushing in the opposite direction.

If I offered you a pair of shoes, you’re telling me you wouldn’t take them?

There’s no doubt in my mind there are good iOS devs out there who have never ventured over to the Mac because it looks like it would be just a bit more effort than it’s worth. It’s not that they can’t do it because AppKit is some incredibly hard thing that only a rocket scientist can figure out. (I’ve made AppKit apps, so trust me, it’s not rocket science.) But it is yet another thing to learn. In addition to having to sweat the details about the platform, user experience, etc., you also have to learn the differences between an NSButton and a UIButton, NSColor and UIColor, and on and on. I remember when I was going through it, I never once said “This is too hard!” It was more like “Why the heck is this so different?”

Also, there are many cases where the simplest of things take more effort in AppKit than on iOS. And even when something isn’t more effort, just finding answers to basic questions was a chore, because it’s harder to get answers from a web search about AppKit.^[5]

A unified API would obliterate these small frustrations. When I want to add a button to a view, I’d add it the same way on macOS as I do on iOS. When I want to specify a color, I’d use the same syntax for both.

If we apply the infamous “aliens landing on Earth” hypothetical to the development of iOS and macOS apps, of course the aliens would think it’s ridiculous this isn’t already the way things work.

And the benefits really could go in both directions. Some macOS devs may just find that once they learn this new framework, suddenly their great Mac apps are just a little bit easier to port over to the iPad.^[6]

Regardless of how much junk gets made by others, in the hands of those who care, better tools are still a good thing.

If you care about making great apps, then Marzipan should at least make you excited about a slightly easier path to platforms you haven’t yet explored, or a simplification between the two versions of your apps you already maintain.

A lower barrier to entry for new devs

Marzipan will not only make it easier for an existing iOS dev to move to macOS, and vice versa. It will also be easier for new developers to get started in Apple’s ecosystem. If we’re not talking about UIKit ported to AppKit, but rather a completely new set of APIs, that would mean years of knowledge about how those current frameworks get used would be baked into the new framework. Apple’s engineers are pretty good at this stuff.^[7] I’m guessing they know all the pain points for new developers coming to the platform, and they’ll seek to decrease that pain.

More new blood in the ecosystem means more innovation, more creativity, more inclusiveness. It probably also means more terrible apps, but like I said before, the cream that rises to the top will be worth it. As much as the old-timers love their little niche community of app celebrities, the future of the platform depends on all of us getting replaced eventually. Personally, I welcome the possibility of an influx of bright new talent, particularly to the Mac.

Less code is a good thing

While we’re on the subject of making things easier, Marzipan also promises more shared code between iOS and Mac versions of apps. We’ve been able for a long time to share some elements of our apps, models, classes, etc. in the same project file with different targets. With Marzipan, we could end up sharing even more code between platforms. Not all of it, of course. But a lot more of it.

Fewer repeated classes equals less code, which equals easier testing, which equals less room for human error, which equals more-reliable apps.

It also means less duplication of effort. Which is easier to sell to middle managers on a budget.

A unified framework that’s still native

I was a middle manager once. Every year, my boss would bring me into his office and hand me a budget that was invariably 15% smaller than last year’s and tell me to make it work, no matter what I had to do. Same output. Lower cost. That meant giving part-timers fewer hours, not extending contracts, and in some cases, eliminating positions altogether.^[8]

That was always my last resort, though. More often than not, I’d look at ways to spend less money on the services we delivered. There are always inefficiencies in any business, and if you put enough pressure on people, they will find them, even if it ends up hurting the product.

Enter our old friend, Write-Once, Run-Anywhere. We had a brief period of bliss with Apple’s push for native iPhone apps back in 2008. But the Dark Lord’s lieutenant has returned, and although he is not yet regained his full strength, his minions are gathering in Mordor.

Slack. Skype. Banking apps—chances are, you are already seeing more cross-platform Electron apps on your Mac and non-native apps on your phone as well. This is a trend. It will continue.

Marzipan probably won’t save us from this nightmare. But if even one of these JavaScript-infused beasts turns out to be an iOS-to-Mac native port on my Mac instead, it will be worth it.

As a consultant, I like the idea of being able to pitch an even slightly less expensive Mac add-on to an existing iOS contract. “Oh, you were going to build a Mac version in Electron? Well, we can make a much richer native experience reusing a lot of our efforts on iOS…” It’s still a tough sell, but it is just a bit easier.

The Mac is less likely to get left out of new API goodies

If Apple only has to maintain one framework for adding new features to iOS and macOS, it’s less likely to leave the Mac out of new APIs. That means no longer waiting a year or more to get the same interesting cool new features we see on iOS.

And given Apple’s tendency to eat its own dog food, I can see this having a very positive effect on the App Store as well. Imagine the App Store app being built using Marzipan, sharing its code between macOS and iOS. Now features like gifting, app previews, review prompting, and other things that have been missing on the Mac App Store for years would actually take effort to exclude from the Mac.^[9]

Simplifying to one framework could also improve the speed at which Apple keeps up with its documentation and sample code. Wouldn’t that be a wonderful thing?

The Mac market is far too small compared to iOS to be a top priority for Apple. At least with Marzipan, macOS can maybe tag along with its more popular baby brother on new features.

More options is almost always better than fewer options

People who have been reading me for a long time know that generally I’m a fan of having more options. It’s always better when Apple gives us something than when it takes something away.

Right now, even if I wanted to, I couldn’t sell an iOS app that also runs on the Mac in one simple transaction. At least not easily. Marzipan looks to make that very easy. Even if I never end up selling an app that way, I like having the option. I also like the idea of one button my customers press to download my app on all their devices, Macs included.

Developers are fond of criticizing Apple for all the things we can’t do. They tend to forget that Apple often gives us new things we can do. Sure, there are other things we’d rather they let us do. But I’ll take what I can get.

Conclusion

All of this, of course, is merely speculation on a rumor. But it’s a rumor that makes a whole lot of sense to me. I would not be surprised to hear something official about this from Apple come June in San Jose. I would not be terribly surprised if it came a year or two later. I would be surprised, however, if it never comes to pass.

When you look at all four of Apple’s operating systems (iOS, tvOS, watchOS, and macOS) one of them is clearly not like the others. And that’s inefficient from Apple’s perspective. The benefits to Apple of a unified framework are just too numerous and obvious. So if I had a stake in the macOS or iOS ecosystems (and I do have one in both) I’d be doing some serious planning in the new year, so I can be prepared to reap the benefits, rather than wasting time fearing the negatives.