Expect to see the Swift 1.0 of Marzipan this summer, not the Swift 5 we all want.

So I've been giving Marzipan a lot of thought as of late, especially during the lead-up to Apple's once-rumored gaming service. As an iOS developer I'm very excited to be able to port Slopes over to the Mac (replaying their days skiing on virtual 3D mountains on a 27" screen will be a great experience).

But I'm trying to stay realistic in what I expect this year at WWDC. It's easy to let my excitement for new tech make me get ahead of myself, and as I plan my roadmap for Slopes into the fall I'm trying to figure out if I need to support Marzipan this year.

That means taking a step back and looking at the puzzle pieces we have that help me look forward to a potential, realistic, roadmap:

• Marzipan is a multi-year effort, culminating in universal platform-agnostic binaries in 2021, according to the Bloomberg report. Craig Federighi also called this a multi-year project on stage, right in the introduction of Marzipan during the keynote, so this is no surprise.
• In that same Bloomberg report, we get Marzipan support for iPad apps this year (which, keep in mind, is a fraction of the size of the iPhone app catalog). In 2020 we'll get support for iPhone apps.
• While not confirmed, I'd place decent money on Marzipan being a big part of the Apple Arcade tech stack. Apple Arcade is slated to release this fall, so are iOS 13 and macOS 10.15, just when Apple promised devs would be able to play with Marzipan.

I think we can paint a pretty good picture of what to expect from those pieces. As a developer, I'm excited and certainly hope that we get more than I'm proposing here, but I'm trying to temper my expectations so I don't go rioting in the streets Eagles-win-the-Super-Bowl style when the announcements at WWDC 2019 aren't everything I hoped and dreamed it to be.

San Jose wouldn't invite Apple back next year if we did that.

So first off, before we look forward, let's understand the task at hand. What is the scope of work Apple faced starting with the WWDC announcement in 2018?

Marzipan isn't just "get UIKit working on the Mac." Getting UIKit working is certainly the most visual / noticeable aspect of this effort, but that's only the coat of paint. But even "just a coat of paint", that alone is a huge effort. There are a ton of AppKit concepts that just don't exist in UIKit that will have to be exposed somehow. And it isn't just a matter of getting iOS apps to be able to use AppKit concepts (that's step 1), getting iOS apps to feel somewhat-sorta-kinda at home on a Mac is going to be a lot of work too (step 2), and a lot of tradeoffs will have to be made.

That list in the screenshot right there is a mountain of work to be done. Through people spelunking the existing Marzipan code in Mojave, like Steve Troughton-Smith, we can see Apple has been working on getting the beginnings in place: things like exposing the menu bar, contextual menus, and more. How much of that remains private APIs, vs. goes public this year, will remain a mystery until WWDC 2019.

To that end, I've considered last year's release of Home.app, Stocks.app, etc. to be the alpha builds of this kind of UIKit port. I've long argued that I don't think these apps represent the end-game of what Marzipan apps will feel like. As Craig said they're just at Phase 1; and after all it took until Phase 3 for the Avengers to truly assemble.

A completed AppKit → UIKit bridge is a tremendous amount of work, but getting our apps to feel native isn't the beginning, no no no, that's step 2. The real can of worms opens before we even get to worry about if our apps look at home on the Mac: it begins in just worrying about getting them to run. That means every framework we use on iOS has to be there on the Mac, in some form. That slide above from the State of the Union — about what they need to do for AppKit — is just a drop in the overall Marzipan bucket. Some of the other frameworks exist on both platforms already (CoreLocation, SceneKit, CoreML, etc), but have subtle or even major differences that will need to be unified. Some frameworks, like HealthKit, don't exist at all on the mac (at least that one has an isHealthDataAvailable flag we can check so they can just fake-it-till-you-make-it and give us a .h file and one working method in their .m that returns false for the check).

But regardless, in the end that is a lot of code and frameworks to either port or unify before they consider Marzipan done. Marzipan isn't just about bridging AppKit and UIKit, even though that's where most of the discussion has resided.

To make matters even more fun, beyond what we as developers can see via these public APIs they have to get working, during the Platform State of the Union Kristen said they are going to unify the underpinnings of iOS and macOS "which in some cases have drifted apart over time." That's no small task I'm sure, and it'll have ripple effects. Last time Apple rewrote a single underpinning that went really well didn't it (mDNSResponder / discoveryd anyone)? They have to pull these changes off bug-free across who-knows-how-many subsystems. Given the ripple-up effect an effort like this will have, I'd wager Apple is focused on tackling this low-level part first before anything else above.

That surface area of the three major items above is huge, and certainly with many areas of high risk. They can't do all of the above in one year, even if it was all-hands-on-deck. And it can't be all-hands-on-deck: don't forget that while this is going on Apple needs to ship multiple major tentpole features for iOS, macOS, and watchOS for consumers this year (do you want to be the one to tell Viticci his iPad power user features are on hold?).

OK so with that all in place (*magical hand-waving*) our apps can compile and look decent on the Mac (*snicker* Home.app). Let's talk distribution.

Based on the Bloomberg report, Apple is eventually planning for universal binaries that will execute on both Mac and iOS, but for 2019 that isn't in the cards. Until 2021 our apps will have to be "converted" to Mac apps, and "developers will still need to submit separate versions of the app to Apple’s iOS and Mac App Stores." So that means a Marzipan build target, which likely gets uploaded to App Store Connect as a Mac app the same way a Mac app does today, with a separate SKU from the iOS app and all. Easy enough, right?

Lets unpack how App Store Connect ("ASC", because I'm lazy) works today — specifically purchases — as a lot of us will care about that. Right now you can't share receipts between a Mac and an iOS app using the built-in system frameworks (StoreKit). This won't be an issue for paid up-front apps (worst case you make a bundle containing apps for both platforms so they get access to both for one price) or 100% free apps. But for in-app purchases (or those subscriptions Apple loves right now), things get a lot messier.

Not only are the app SKUs / receipts different for each platform, the IAPs have their own SKUs within each app SKU. There is no concept of a subscription shared between two apps. You've got to roll your own solution if you want to offer IAPs that work on both platforms. But rolling-your-own doesn't fit the story of a unified App Store and easy porting, so Apple will have to address receipt sharing across platforms for universal binaries by 2021. With a single SKU that'll be a lot easier to solve than today's multiple SKU setup.

We developers are going to want more than that this fall, though. We will we want receipts to work across our (temporary, but necessary until 2021) multiple SKUs. But notice this is only needed for the short term until we have the concept of a unified iOS/Mac SKUs on ASC. Lets say Apple throws us a bone, though. How do they make receipt sharing happen for now? Is it automatic if you use the same bundle ID? (oh fun fact you can't have the same bundle ID in ASC for binaries on two platforms today.) If not that, then some manual link we make in ASC between the SKUs? Does the system, however it works, then automatically analyze the downloaded Mac binary on-device to see if it is a Marzipan app and #ifdef the normal MAS "get the receipt" logic and have it return a copy of the iOS counterpart's receipt instead? Once they ship universal binaries, does Apple have a clean migration plan to merge to the "proper" way of doing things with a new single SKU? How do we migrate customers using the now-legacy dual-SKU setup of our Mac Marzipan app when we convert to said universal app in 2021, or support them if they don't migrate?

My code-smell sure is tingling at all these short-term workarounds. Sure, these short-term problems can be solved, but is the effort (and potential long-term maitenence on both ours and Apple's side) worth it in Apple's eyes? They need receipt sharing in place for universal binaries and the idea of One True App Store, but do we need it in the next two years before that?

They can certainly avoid many headaches if they punt. And if they don't address receipt sharing, we can avoid a lot of headaches by not rushing out of the gate. This is the same separate iPad and iPhone apps → Universal app migration all over again, except we know its coming this time.

(I wouldn't be suspried if News+ / TV+ uses some of this receipt-sharing, but that could easily be Apple-only hacks not ready for consumption, just like Marzipan itself was in Mojave.)

Craig made it very clear that he thinks some types of apps are great candidates for Marzipan. It sounds like the goal isn't to get every app on iOS on the Mac (thank goodness), and that leads me to think be they're willing to accept tradeoffs as this is a multi-year rollout. As time goes on, more and more apps will fall under that some types of apps, but maybe for now that doesn't include apps with IAPs.

Apple also isn't stupid. They're well aware that iPad apps are a small subset of the total iOS App Store. They know that the real flood of demand for Marzipan will come in 2020 when they open it up to iPhone apps. I'll be very curious how they balance the above issues with ASC with the demand for iPhone apps, but without universal binaries.

Regardless, the people who ship this year will be the trailblazers, and given the monumental scope of work that is Marzipan, Apple won't be able to, or feel obligated to, remove all the thorns from the path this year.

So with all those TODOs littered throughout their code, I think that third item in the opening of this post, Apple Arcade, gives us a good way to figure out where Marzipan is landing in 2019.

Apple is courting game studios with Apple Arcade, and you better believe the messaging to them isn't "just use Unity and then you can target both our platforms!" with Marzipan just on the horizon. Platforms like Unity let you ship thin wrappers around your game, allowing you to run on multiple platforms, but Apple would love to be their own full-stack answer here. Ship a SceneKit game written as a UIKit app, wrap it for the Mac with a second Marzipan build target, and you're up and running on the Mac. Add the same stuff you'd need to do in Unity: keyboard / mouse support, perhaps some better textures for the Mac, etc. — and you're done. With Apple touting many of these games as exclusives, I'm sure they'd love to see Unity out of the picture for Apple Arcade (as would developers due to Unity's additional revenue).

To me games seem like they'll be the low-hanging-fruit of a v1.0 Marzipan rollout as they'll require the least framework surface area to support. Their AppKit support needs will be minimal too: keyboard/mouse support, a menu bar item or two, and boom(ish) you've got a native-feeling Mac game. Metal / SceneKit / SpriteKit already exists on both platforms, they've just gotta get it working well for Marzipan (I'd venture most of Apple's work there is Metal-related, which likely falls under that first-year "underpinnings" work from above). With games you don't need 98% of AppKit, you don't need HealthKit, MapKit, MessageUI, CoreLocation, CoreMotion, AddressBook, TextKit, ARKit, SiriKit, document pickers, and heck without in-app purchases in Apple Arcade they can probably get away without StoreKit (Apple can throw the Apple Arcade games into a bundle behind the scenes and Apple Arcade gets you all apps in said bundle).

Why am I focusing on Apple Arcade? Jokes of AirPower aside, it is publicly announced, with a release date. Apple is committed to landing it in the Fall along side the OS updates. Anything that doesn't directly enable this goal is a bonus at this point - so Apple Arcade is the benchmark for priority. If things have to get cut, it'll be things that don't directly enable Apple Arcade. That's their MVP for this year.

That all said, I think their broad focus for Marzipan 2019 is games, not just AA. All the above holds true for third parties, too, Apple Arcade is just the MVP they've been dogfooding internally in prep for a September public release. What's backing up my theory about a focus on games? Games are their biggest bang for the buck and easiest sell for a v1.0. Howso? Games is the largest category in the App Store just shy of 25% of the total apps (w/ the next one behind it, business, at 10%). On top of their popularity, Apple doesn't have to worry about convincing game developers to adapt a bunch of crazy UIKit voodoo over to Marzipan-compatable UIs: games operate inside of a nice little Unity / SceneKit / OpenGL windowed sandbox. It'll be an easy sell to game developers in that regard; a lot less work then porting Slopes, that's for sure. Games will make for some great "look what 2 engineers were able to do in one week!", "look at how much better it runs on the Mac!", "🤘 Metal" demos at WWDC. Lastly, and perhaps most importantly, these easy-to-port games will help boost the size of the Mac App Store catalog a ton, right away in the first year.

(Yes some games might require additional frameworks. Some games won't translate well from touch to keyboard / mouse. But remember we're talking year one in a multi-year strategy here. Low-hanging fruit.)

Edit: "Thread" on Twitter also points out that Craig dropped Fortnight as a possible great candidate for Marzipan to the press last year after WWDC.

"Apple believes that many games will easily be able to make the leap; Federighi specifically mentioned Fortnite as a candidate for porting."

Now don't worry, I'm not proposing they'll make the WWDC 2019 Marzipan story all about games, not at all. I expect we'll see at least one more of Apple's UIKit apps ported via Marzipan. They need a way to demo the now-official APIs used for that UIKit to AppKit bridge (providing the APIs from that slide with Kristen above). But a lot of frameworks will be missing, and AppKit support will be very bare-bones in this v1.0. As such this demo will be an app that has a relativly small framework surface-area, so Apple can bite off just enough for them to chew and have a good demo / story this year.

They hit relatively easy apps last year, so they'll have to step it up just a bit this year to a more visible app that feels like less of a trivial port (sorry, Voice Memos). One where they can tout the savings of replacing an AppKit app with a UIKit app (vs. last year's all-new-on-Mac apps). A well-known app, but not a key app like Address Book / Contacts / Photos / Mail, and certainly not apps with larger framework surfaces areas like iMessage. Marzipan isn't battle-tested for those yet. You've gotta save the biggest and the best for last, and we have two more years until we're at the Marzipan finish-line, ready to celebrate with a bang.

Maps seems like a good candidate for 2019. Brings in two new frameworks to be Marzipan-blessed (MapKit and CoreLocation), is a non-obscure app, but also safe to mess with a bit.

(Oh man how I wish this year's demo would be a Marzipan Music.app. Replacing iTunes with that can't come soon enough.)

For a long time we developers would criticize Apple for working in secret for years on some major new API or tech, just to drop it on us once it was finalized with no room for feedback. What we're seeing is a new Apple, one that is releasing major technologies early enough to gather real-world feedback. They aren't doing it all the time, but Marzipan is the second major tech (after Swift) in recent years that they're doing it for.

They gave us Swift when it was ready enough to start using it, but long (long) before it was "done." It wasn't until maybe 2 years after its initial relase that it was really ready for use (I use the term "ready" loosly, but Swift 3 was at least the last big code migration pain and things have settled down a lot.) After Swift 3 we stopped inheriting technical debt just by using Swift, and instead just had to deal with tooling PITAs. But as a result of releasing it early, we trailblazers that have been using Swift since 1.0 have had tons of time to provide real-world feedback and help shape the language long before things were locked in by ABI stability (I'm looking at you, string API).

And Swift is, without a doubt, much better off than it would be if Apple had waited to give it to us until it was "done" (with an Xcode refactor tool and all).

Marzipan is the same. From the Bloomberg report, and from Craig and Kristen's own mouths, this is an ambitious multi-year project to get it to where they want it to be. We're seeing it, and even going to be able to use it, well before it is Classic-Apple "done." I fully expect this year's release to be similar to Swift 1.0: enough to start working with and maybe even ship some stuff with, useful to some but by far not all of us, and those using it will encounter tons of rough edges and tons of things subject to change.

So where does that leave me and Slopes? I'm always willing to have my mind changed by what they announce WWDC, but for now I've taken Marzipan off my roadmap for 2019. I don't have a business case to be a trailblazer here.

(But you better believe I'll still be spinning up a Marzipan build target and playing around.)

Edit: Changed the lead so people wouldn't get distracted by the trees in the forest.