Apple Rumored to Combine iPhone, iPad, and Mac Apps to Create One User Experience
Mark Gurman (Hacker News, MacRumors):
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.
Developers currently must design two different apps -- one for iOS, the operating system of Apple’s mobile devices, and one for macOS, the system that runs Macs. That’s a lot more work. What’s more, Apple customers have long complained that some Mac apps get short shrift. For example, while the iPhone and iPad Twitter app is regularly updated with the social network’s latest features, the Mac version hasn’t been refreshed recently and is widely considered substandard. With a single app for all machines, Mac, iPad and iPhone users will get new features and updates at the same time.
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.
This has long seemed like an obvious thing for Apple to do, but I’m not sure it’s good for the Mac platform. The upside is that we’ll get lots of ports of iOS apps where previously there was no Mac app or only a poor quality Web-based one. The downside is that I don’t want to be using lowest common denominator iOS ports. I like using a Mac because of the apps that really take advantage of what the desktop has to offer. I’m continually annoyed by the apps that essentially put an iOS-style interface in a window and don’t support standard Mac conventions or features. I also worry that bifurcating the platform with UXKit and AppKit apps will inevitably mean that Apple will focus less on enhancing AppKit, while at the same time doubling the surface area for bugs. Having two classes of Mac apps would not be good, but AppKit going the way of Carbon would be even worse.
macOS 10.14 Toasterfridge
To quote from my piece, with a unified app platform between iOS and macOS, iPad apps would have a migration path to the desktop, and legacy desktop apps to iPad — both platforms could evolve & grow as one, and not one at the expense of the other.
Opening the macOS floodgates to iOS developers is going to be a huge shot in the arm (unintentional pun); it could make a big difference to Apple’s inability to give macOS the development attention iOS gets. We know they need this! Photos on the Mac is a UIKit port using UXKit!
If there’s any truth to this, it’s going to make a lot of Mac developers pretty mad (and depends a lot on implementation details), but I’m definitely in favor of it and pretty excited for the potential.
Whoa. Looks like “native Mac apps” that are thin wrappers around websites will be dying soon if we can just run the iOS version native on our Macs. Huge ramifications for this.
Developers say, “Yay, now we get Mac for free!” But the reality is customers are saying the exact same thing.
Update (2017-12-20): Michael Love:
Also, the release of this story compels Apple to either a) unequivocally deny it or b) work like hell to get it ready for next summer; who’s going to invest any more time in a Mac app with this waiting in the wings?
Heck, it even makes me a bit reluctant to buy macOS software with it unclear whether that will be abandoned + replaced by iOS ports under this new regime.
Today, Apple invented UWP apps. Psyched!
There seems to be a big cultural divide between iOS developers who came from the Mac and iOS developers who didn’t. Many in the latter group are ok with destroying the Mac, and that’s very frustrating to me.
I do worry that in the transition to ‘universal’ apps we’ll loose functionality that currently exists on the Mac side. The infamous example of Apple’s own Keynote app, where the Mac app lost a bunch of functionality to harmonise it with the iOS version, seems like a warning shot.
The irony is that Mac sales are as high as ever, despite lagging hardware updates. People like the Mac and are buying Macs. It’s not in any sense an endangered or dying platform. It’s wildly successful.
The Mac App Store is suffering, yes. The best Mac apps have left the store, or were never in the store in the first place. That’s a problem with the store, not a problem with the Mac.
I fear radical degradation of macOS’ usability. But maybe also a chance to kill f***ing Electron apps.
Update (2017-12-22): Gus Mueller:
There’s an easy solution for updating the Mac version of Twitter to have the same features as its iOS peers. Twitter has to care enough to update it. That’s it. It’s not as if there needs to be massive engineering efforts put behind it. It’s not as if the road hasn’t already been explored and the server APIs already exposed (which they must have done for the iOS version). They just need to put some effort and care to it. Tweetie for the Mac, which Twitter for the Mac is based on, was built from the ground up by a single person. All Twitter had to to was maintain it. And Twitter, Inc. couldn’t be bothered.
And we see the same behavior from other vendors happening on the iPad where a shared framework already exists (Instagram being the prime example).
What if this is all about getting iPhone-only apps to run at iPad (and, by the way, Mac) screen sizes?
The technology to create Universal apps has been around for many years now, yet there’s still a surprising lack of adoption.
You can literally flip a switch and make it “work”.
It’s a lot of work to make your app design & layout work on a wide variety of screen sizes. Adding macOS to this situation isn’t going to make less work.
I speak with a bit of experience here: we built a macOS app with a UIKit framework developed by @BigZaphod.
Even with familiar classes and frameworks, it wasn’t easy to make a macOS app from an iOS source base.
Our second attempt, which used separate UI presentation layers for macOS and iOS, but with and a common data model, was actually simpler to implement and resulted in a better app.
I could imagine a system that might work somewhat like the Carbon/Cocoa integration that Apple provided in the early OS X days, where you could do things like embed a Carbon view in a Cocoa view, mix Carbon and Cocoa windows in the same app, and so forth. There would still be some work to do for iOS devs to make their apps work well on the Mac, but I think this might be a good middle ground similar to Carbon, where 80% of the work is already done for you, and you’d just need to handle the extra hooks in order to have your iOS components behave inside a Mac environment.
What if it’s not a layer on top of AppKit and UIKit, but a layer underneath?
Classes like NSImage and UIImage could be refactored to have a common ancestor, maybe just named Image. When you create an Image you get the platform specific version under the hood, but you can ignore that and work with Image’s shared cross platform functions. When you need something only currently available on the Mac, like image representations, you just downcast your image to an NSImage, and you have all your AppKit functionality back.
[The] Bloomberg article completely downplays the prerequisites, on the desktop side, of an unified OS.
Even though this makes sense, I have [a] strong feeling it will result in the dumbing down of the macOS user experience to a degree where it will be untenable to use for serious purposes.
It may look like this is the downfall of the Mac as a platform, but in reality, this may be a life raft into the modern era. It’ll take years to discover which is true, but if it means a Mac ecosystem with more options when it comes to good apps, that’s a win.
So, Apple keeps stressing the user interface differences between Mac OS and iOS hardware, and the next step could be ‘universal’ apps!? You can see this is a bad idea from miles away. The last thing Mac OS needs are dumbed-down iOS-ported apps.
Microsoft’s UWP will be hitting the three-year mark in late 2018, right around when Apple’s first attempt at app unification may debut.
[…]
These tools combined make Windows 10 an OS that can live anywhere, on any device, with any screen size, running any processor. With UWP, the apps can run on all those devices with only minor changes. […] Apple has some of this with shared components between iOS and macOS, but its app story is very far behind. Apple has not – to our knowledge – taken any steps to unify its UI across macOS and iOS.
See also: Under the Radar, Matt Birchler, Ben Lovejoy, Dave Verwer.
Update (2017-12-23): John Gruber (tweet):
“One user experience” is neither possible nor desirable. The truth is that this effort by Apple is almost certainly not about cross-platform applications but instead cross-platform frameworks for developers. It’s developer news, not user news.
[…]
There is a lot of work involved getting an iPhone app to work well on an iPad. That’s why you still see iPhone-only apps. Even with good new cross-platform Mac/iOS frameworks, there would be way more work involved to bring an iPhone app to Mac than there is to bring to iPad.
[…]
Caring is ultimately what makes true Mac apps Mac apps. Caring about the details, caring about the Mac way of doing things. No amount of shared frameworks between MacOS and iOS can make iOS developers care about doing things properly on the Mac.
[…]
My concern with this whole situation is that even if this is all true — if Apple is indeed working on creating cross-platform UIKit-like frameworks for iOS and MacOS, and that the existence of such frameworks would spur more developers and companies to create Mac apps — it wouldn’t to the creation of good Mac apps.
Even Apple, much to my concern, has fallen short in this regard. Photos for Mac is one of the worst Mac apps I use. […] It’s as though Photos for Mac was created by iOS developers who saw a Mac one time and said, “Sure, we can do that.”
I take the details of the Marzipan story with a grain of salt, considering that Gurman also told us that Swift would be ABI stable for version 2.
Update (2017-12-28): See also: Accidental Tech Podcast on some of the problems with Photos, which is probably the best of Apple’s ported iOS apps.
UWP is not a "write once, deploy everywhere" model, though in some ways it can be used as such. Nor is it only about phones, which apparently are on the sideline now for Microsoft. UWP is about building a next-generation app platform that can quickly adapt to new hardware paradigms, whether it is Windows Mixed Reality, traditional PCs, tablets, mobile devices, or your living room.
No doubt about it. Thousands of previously iOS-only apps will end up on the Mac barely altered with bad UI on day one. […] 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.
[…]
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.
[…]
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.
[…]
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.
[…]
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.
See also: Accidental Tech Podcast.
Update (2018-01-01): Todd Ditchendorf:
Languages: same (Swift/ObjC)
IDE: same (Xcode)
Standard lib: same (Foundation)
User Interface lib: extremely similar (UIKit vs AppKit)It’s not clear to me that a write-once-run-anywhere toolkit across iOS (touch) & Mac (WIMP) more unified than this is actually desirable.
