Last June, Apple promised to take the wraps off new technology at WWDC19 that allows iOS developers to create macOS apps from their iOS apps. The developer community has dubbed it “Marzipan”.
The idea is appealing. Flip a switch in Xcode and get a macOS app from your iOS app source code. New market. Small additional investment.
In the run-up to WWDC, there has been lots of speculation, on Twitter and elsewhere, about what this means for the Mac we know and love. Some of the more thoughtful posts include:
As the developer of both Storyist for macOS and Storyist for iOS, I’m well aware of the challenges of developing for each platform. Here’s what I’ll be watching for.
How is Selection Handled?
It’s tempting to look at Marzipan through the lens of responsive web design and mobile first, with the Mac being just another “breakpoint.” iOS already has the concept of size classes (UIUserInterfaceSizeClass), and a larger screen would just be another enum value—for example, UIUserInterfaceClassLarge.
Unfortunately, there are several interaction differences too—the biggest one being the selection model—that need to be addressed if cross-compiled iOS apps are to feel at home on macOS.
Consider this: On macOS, you click to select and double-click to edit. Finder is an excellent example of this model. On iOS, however, you tap to navigate, and selection is most often accomplished by tapping a button to enter a selection mode. See the Files app, for example. Modal operation is tolerated on iOS, but less so on macOS.
How will Marzipan deal with these differences?
Are Files Finally First-Class Citizens?
When iOS was first introduced, Apple took great pains to hide the fact that there was a file system under the hood. The average user, so the thinking went, was confused by the idea of files and file systems, so care should be taken to avoid these concepts in the user interface—even though computers have embraced these concepts since the early days of personal computing.
This was clearly a mistake, which Apple rectified in iOS 11 with the introduction of the Files app. The Files app and the underlying open-in-place functionality improved things considerably for users of productivity apps.
But on macOS, files are first-class citizens. Most non-trivial workflows involve multiple apps and count on the ability to quickly and productively move between them.
Will the Files app and UIDocumentBrowserViewController receive substantial updates in iOS 13 and be up to the task?
What Changes Does iOS 13 Bring to TextKit?
UIKit started as a reimplementation of the fundamental interface concepts found in AppKit—views, controls, the responder chain, and the like—but with a focus on a touch interaction model.
The new platform offered Apple the chance to revisit design decisions (layer backing, the coordinate system), take the best and leave the rest safely in the past. This philosophy was, by necessity, cautious, and many of the concepts that did not immediately apply were left for later.
This was the right approach, but we’ve now arrived at “later,” and there are some things that need to be added to TextKit to make it suitable for productivity apps.
NSTextView is one of the richest controls in AppKit. Its counterpart on iOS is UITextView and is missing some key features.
Multiple page support—NSLayoutManager (initially developed for macOS and ported to iOS) provides a mechanism for laying out text in multiple containers (pages). However, UITextView becomes read-only when attached to layout managers with multiple containers. Part of this is undoubtedly due to the additional complexity of selecting across containers, and is something that Apple could easily choose to remedy.
Tables support—NSTextView supports tables. UITextView does not.
Bullet support—NSTextView (via NSParagraphStyle) on macOS supports bullets. On UITextView does not.
Delegate methods—NSTextViewDelegate provides a much richer set of access points than UITextViewDelegate. For example, with NSTextViewDelegate you have access to and can modify the selection as it is happening. With UITextViewDelegate, you cannot.
TextKit on macOS is more powerful in other ways too. Temporary attributes, heading levels in paragraph styles … the list goes on.
Storyist is a text-centric app. What changes will Marzipan bring to TextKit?
Last year, Apple shipped four “test” apps in macOS Mojave that were originally iOS apps and use a precursor to Marzipan to run on macOS—News, Stocks, Home, and Voice Memos. Not the most exciting apps. Certainly not productivity apps.
I expect that this year, we’ll see a more examples, perhaps with Safari leading the way. The most significant indicator for me will be if Apple rolls out a Marzipan version of Pages, Keynote, or Numbers. That would get my attention.
WWDC is just a few days away. Hopefully, we’ll be blown away.