Logically, this makes sense. Desktop apps can be constrained with window sizing, and there are a lot of missed opportunities for native desktop apps. A reason most iOS apps don’t make their way to the Mac is that developers don’t see any reason to make an AppKit app after writing a UIKit app; doubling your efforts for minimal gain is just not smart.We also think this is a clever way to introduce iOS developers to the Mac platform. Whatever the case, these are early days, and the initial results are pretty impressive. We hope this tooling makes it easy for third-party app developers to create special desktop apps, starting next year.
The Marzipan rumors were true – or at least a variation of them. At WWDC 2018, Apple previewed its project for iOS/macOS cross-platform apps, and it’s a doozy. Late last year, news broke that Apple was working on a method to merge the iOS and macOS platforms. At this year’s WWDC, however, Apple platforms chief Craig Federighi stated emphatically that the two platforms aren't merging. Lauding the values and advantages of macOS, Federighi quickly transitioned into why there was so much speculation about a potential merge. First, Apple is fixing the Mac App Store to be more like its iOS counterpart. It will look and act much like the mobile version for iOS, but it’s a macOS app. The new Mac App Store is joined by four revamped native apps: News, Stocks, Voice Memos, and Home. They were all written in Swift, and are early examples of ‘Marzipan’ in action. Apple’s two platforms have unique frameworks: macOS has AppKit, and iOS has UIKit. As Federighi noted, the two share similar functionality and features. To bridge the gap between mobile and desktop, Apple is essentially creating an API that will help developers port their iOS apps to the Mac. The dual-framework method will use UIKit for heavy lifting, but AppKit to keep things desktop-friendly. AppKit will handle things like mouse clicks, menu bar and sidebar opacity, and window resizing. If UIKit is the window to an app, AppKit is its desktop frame. Apple didn’t say as much, but its four revamped native apps show that it feels iPad apps are best suited for the desktop. News, for example, uses the same side-bar for the Mac as its iPad version. Each adopts the iPad user interface (which is, at times, a blown-up iPhone app). Currently, Apple is testing its AppKit/UIKit project internally. It plans to have it ready for full release to developers next year. This coincides with another important change: the move away from 32-bit apps. Apple has started encouraging developers to update their legacy 32-bit codebases, and says the new version of macOS – Mojave – will be the last to support 32-bit apps at all (with High Sierra, Apple offered support with no degradation). By WWDC 2019, it will be making a big push to have developers update their apps. The company may also know developers won’t rush to update, which is why we have this double-framework, cross-platform tooling. It’s also a bit of side eye at Electron; rather than allow developers to create shells for progressive web apps, Apple is working to make native available to all its customers. But we don’t see a method for this being profitable yet. It’s too early to discuss how developers will be able to sell their kinda-sorta-Mac-apps, or if they can at all. It’s very possible Apple will push developers to pursue a subscription model and forgo charging users twice for the same app. Another reason this new system exists is duplication of work. Federighi admitted it’s not advantageous to write an AppKit app on top of writing a UIKit app. We’d agree. In May, I wrote the following: