Apple could announce universal iOS/macOS apps as soon as WWDC 2018

iMac Pro
iMac Pro (Image credit: iMore)

Because watchOS and tvOS are both based on iOS, apps for those platforms can share code, be packaged as universal apps, and be sold in bundles. Not so macOS, which uses AppKit instead of UIKit, the Mac App Store instead of the iOS App Store (and it's offshoots for TV and Watch), and generally has to be planned for and executed separately. But just because that's the way it is doesn't mean that's the way it's always going to be.

Mark Gurman, writing for Bloomberg:

Starting as early as next year, software developers will be able to design a single application that works with a touchscreen or mouse and trackpad depending on whether it's running on the iPhone and iPad operating system or on Mac hardware, according to people familiar with the matter.Apple currently plans to begin rolling out the change as part of next fall's major iOS and macOS updates, said the people, who requested anonymity to discuss an internal matter. The secret project, codenamed "Marzipan," is one of the tentpole additions for next year's Apple software road map. Theoretically, the plan could be announced as early as the summer at the company's annual developers conference if the late 2018 release plan remains on track. Apple's plans are still fluid, the people said, so the implementation could change or the project could still be canceled.

It remains to be seen if, when, and how Apple would roll out universal iOS/macOS binaries. (How, not what, is always the truly interesting part — UIKit for Mac, anyone?)

What's clear is that the company has been doing things along these lines, internally, for years. The iWork apps for Mac were burned down and then built back up using the engine from iWork for iOS. Photos for Mac was bridged from Photos for iOS. More recently, Apple has been merging the teams and work on the core technologies behind their apps while maintaining the separate user, context-appropriate, user experiences.

In other words, this is nothing new. It's the next progression down a long road that, like with tvOS and watchOS, will let Apple and hopefully developers work wider and more efficiently.

For Microsoft, shifting to universal apps was a way to shed legacy baggage and encourage support for post-PC devices. For Google, bringing Android apps to Chrome let them tap into native functionality and performance.

For Apple, it lets the massive iOS platform help pull the Mac platform forward. So, for example, we don't have to live years without bubble effects on macOS. (Tragic, right?)

We've survived Java. We've survived Adobe Air. We'll survive the JavaScript Electron apps that are trying to solve for easy deployment these days.

Universal iOS/Mac apps wouldn't be about surviving. It would be about thriving. At least if Apple is responsible enough to enable new and better pricing options for developers — including per-platform tiers and bundles.

WWDC 2018 kicks off this June. Happy holidays.

Rene Ritchie

Rene Ritchie is one of the most respected Apple analysts in the business, reaching a combined audience of over 40 million readers a month. His YouTube channel, Vector, has over 90 thousand subscribers and 14 million views and his podcasts, including Debug, have been downloaded over 20 million times. He also regularly co-hosts MacBreak Weekly for the TWiT network and co-hosted CES Live! and Talk Mobile. Based in Montreal, Rene is a former director of product marketing, web developer, and graphic designer. He's authored several books and appeared on numerous television and radio segments to discuss Apple and the technology industry. When not working, he likes to cook, grapple, and spend time with his friends and family.

  • This may or may not be universal apps. It is very likely though that they will announce UXKit. UXKit is the framework that has made porting of some iOS apps to macOS easier, and likely would make mac apps easier to develop in the future. It is basically UIKit for both the mac and iOS (i.e. UIKit -> UXKit; AppKit is deprecated). I believe photos for macOS uses UXKit.
  • "I believe photos for macOS uses UXKit." Yes, it does.
  • Android on Chrome and WIndows mobile/Metro apps on Windows haven't exactly set the world on fire, despite touch screens on laptops. Fundamentally different use cases for mobile and desktop, And app developers still have to port apps across platforms (e.g. iOS to Java/Android) as well as to desktop. As a software developer, I'd settle for an iPad that doubles as a screen for a 2-in-1 MacBook/Pro laptop. I don't need iOS apps on a Mac desktop, and most people (other than gamers and developers) need only a good tablet with bluetooth keyboard for home-use and content consumption.
  • Why do so many commenters here at iMore and elsewhere fear that iOS apps will come to the Mac?This is nothing like this. Besides, with iPads and iPhones getting more powerful, apps may come up to par with their Mac counterparts. Think of it as MS Excel on iOS having the same functionality as its Mac counterpart. The interface will remain different.
    This initiative should make it easier for developers to create apps that do the same thing but with different interface on MacOS and iOS.
    Not that different than the current generation of Universal iOS apps but with different interface. One for iPhone and another for iPad.
  • I have to agree MG537. I doubt that this rumoured change is anything more (at least initially) than just unifying the libraries. AppKit is sort of old and there are many more idiosycracies to it than UIKit. I understand that when Apple ported the iOS like Photos to macOS, that they created UXKit (used internally) which is basically UIKit. So instead of something like UILabel and NSLabel - you have just one label etc. The rumoured fat binaries Universal binaries (if it is true) could just be the forshadowing of an ARM Macbook. Now that does not mean that iOS apps could not be made to work easily on a macOS environment (adding mouse support), and it is much more difficult to go the other way (resizing, reorganizing all the screens to be touch friendly (i.e. not micro sized) which might eventually lead to a laptop/tablet hybrid -- but where it falls flat is expecting the pro market to have to use touch on screens that are typically more than an arm length away. Personally. I hate touch on the desktop, and depending on how I am using a laptop I don't want people touching my screen... but there are cases where it would be nice. I just don't see that coming next WWDC... but it would position Apple in the future if they figured a way that was not as kludgy as the existing solutions are.
  • "The rumoured fat binaries Universal binaries (if it is true) could just be the forshadowing of an ARM Macbook." Not necessarily. There's no need for Macs to transition to ARM processors wholesale for this to happen. On the flip side, one can make the case the iPad Pro is Apple's take on an ARM Macbook.
  • A shared code base for engines and some UI elements means: 1. It will be more efficient to make apps for iOS with macOS features, thus better iOS apps (esp. iPad). 2. It will be easier to make macOS apps based on iOS apps (more macOS apps in the Mac App Store ghost town). So, for #1 it would be easier to make a full feature version of Pixelmator, and for #2 it would be easier to create an Instapaper app for Mac. For unique cases like VLC Player, which have a non-store macOS app and an iOS app, this would make it easier to have an Mac App Store version. For apps like iA Writer, which are in both stores, it means a unified core with lower development cost and easier beta testing. Developers can still do what they want, but Apple will highlight apps that do use the new framework in the App Stores. Still, devs will have efficiency and marketing reasons to use a common code base.