As I said, there’s one aspect of macOS Mojave that we really do have to talk about.
Macs and iOS devices have been getting closer and closer to each other in terms of functionality, and now Apple is bridging that gap with an announcement that the company will be making it easier to port iOS applications over to macOS at its WWDC.
Apple has already been testing its new frameworks, with the recently revealed News, Stocks, Voice Memos, and Home apps that Apple introduced with Mojave all actually being ported versions of the iOS apps. According to Apple, the cross-platform porting is made possible by integrating elements of iOS’s UIKit frameworks directly into macOS, alongside the existing AppKit framework used on desktop.
The point during the keynote where Apple announced this was odd – they put up a slide with the question if Apple will ever merge iOS and macOS, followed by a slide that simply said “no”. However, they then followed by saying that a large part of all the mac OS Mojave features they just announced were actually ports from iOS, which really takes the wind out of that seemingly definitely “no”. We’re not merging iOS and macOS, but by the way all the new apps you just saw are iOS apps!
In any event, this is the Marzipan project Mark Gurman scooped late last year, and it will present a massive sea change for Mac and iOS developers alike. With how popular iOS is compared to macOS, all your favourite macOS applications will eventually be iOS applications ported over to run on macOS. It simply makes very little economic sense to have two separate applications fully optimized for each of the two platforms; it’s much easier to develop an iOS application that oh-by-the-way also runs on macOS.
So no, iOS and macOS aren’t merging in the sense that they’re going to be the same operating system, but once most macOS applications are just ported iOS applications, can you really argue that the distinction between the two platforms really matters?
Hi,
Since the 1970s, the design of the C programming language and its standard libraries has allowed software written in C to be ported from anywhere to anywhere. Can you really argue that the distinction between ancient MS-DOS and modern Linux really matters?
– Brendan
There’s a big difference between code portability and properly matching a platform’s UI conventions.
Any Apple user who has used a low-effort “all relevant platforms” port primarily targeted at Windows or Linux can tell you that.
(To continue your analogy, COMMAND.COM and shells like bash have very different keyboard shortcuts, the platform conventions for command-line switches are different, etc.)
Edited 2018-06-04 22:38 UTC
> (To continue your analogy, COMMAND.COM and shells like bash have very different keyboard shortcuts, the platform conventions for command-line switches are different, etc.)
Oddly enough that one’s not Microsoft’s fault. They wanted DOS to be much more unixy, but IBM insisted on the CP/M-inherited conventions like \ for pathsep and / for switches instead of the sane / and -.
That’s like saying humans are as closely related to chimps as we are to fish. Just because they all have something in common doesn’t mean they’re equally related/different.
While C code can indeed be ported to any platform with a suitable compiler, and iOS and MacOS both use the Cocoa libraries based on Objective-C, a crudely ported iOS app would look out of place on a Mac; they have different menu systems for starters and Mac users expect to see tooltips when they roll the mouse over things, which you don’t get on an iOS app. I used Qt to build an app that runs on Windows, Linux and Mac and to get it looking like a proper Mac app rather than a crudely ported X11 app, it takes a bit of effort and a few workarounds. The same must be true of Cocoa apps; just because the libraries are the same doesn’t mean you can port an app from one platform to another and expect it to look and feel at home on the second platform.
Of course there’s a distinction that matters. iOS support using a library level shim leaves macOS unchanged.
Comparing this to a full merge of iOS and macOS is like claiming that Linux with Wine is just Windows.
I’m glad macOS stays as-is technically, it’s a great OS for developers.
The REALLY big news here is https://developer.apple.com/macos/whats-new/
Basically they’re making it impossible to do portable CL code >.<
Edited 2018-06-04 22:38 UTC
What about having a virtual environment like WoW64 or the Windows Subsystem for Linux? I remember Apple had their Carbon APIs providing a compatibility layer on macOS when OS X was released.
I wonder why they did not do that and instead they are relying on third party developers to port their apps.
Edited 2018-06-05 00:07 UTC
Because they would have to add an processor-emulation in this case. The iOS Devices are ARM based. The would probably have to add GPU emulation as well.
Edited 2018-06-06 11:40 UTC
The powerful Mac apps people use and buy today will continue to be Mac apps. The lower quality, mass produced, non-native apps you fear are here already: they are called web apps. This announcement finally targets them properly.
Making a subset of UIKit available on macOS finally taps into the vast number of iOS developers out there eager to bring their skills to the Mac. This should give native apps and native app developers a fighting chance against the armies of web apps masquerading as Mac apps using Electron and similar wrapper technologies. I can only see this as a positive change.
iOS has much more in common with macOS, in terms of performance, resource use, behaviours and conventions, than the web. From a developer perspective, iOS and macOS are siblings. The technologies and skill sets are similar. This makes much more sense than web apps on the desktop.
When app developers are faced with the question of whether they should address the Mac, hopefully the answer no longer has to be “We can’t afford to make a Mac app. The audience is too small. They can use our web site. If we need an app, let our web team wrap our web site.” Hopefully now the answer can be “Wait a minute, we already have a nice iOS app, let’s make a target for macOS!”
Edited 2018-06-05 05:19 UTC
Eugh.
If it doesn’t run in the terminal or the browser it can stay the fuck away from the desktop.
“Native apps” are just non-portable rubbish.
Your desktop. I prefer native apps on mine, thank you very much. Also, terminal apps are native apps, did you think otherwise?
I placed “native” in quotation marks for a reason.
It’s a loosely defined term. Is a GTK app written in Python native? It requires an interpreter. If it is, how is that different to an electron app, which is compiled code with a small runtime instruction set?
Lots of the tools I run in the CLI are python GUIs. I don’t see how that’s more “native” than a JS GUI that runs in the browser. They’re both interpreters.
By my standards, it’s a question of end-user experience.
A C++ GUI using Qt Quick would be as un-native as a JS GUI using React Native, while a GTK+ or QWidget GUI would meet certain minimum standards for native-ness whether you’re using Python, Perl, JavaScript, C, or C++ (Yes, GTK+ bindings exist for all of those and more.) and, beyond that, it’s a question of how well you follow the platform conventions.
Firefox counts as native despite the UI being XUL-based because they make a sufficient effort to fit in.
At the same time, programs like Emacs, Vim, JDownloader, and KeePass only count as borderline native because of various mistakes. (eg. Emacs, Vim, and KeePass’s UI behaviours are glitchy at times and JDownloader’s UI feels heavy.)
It took a fair bit of work to find a Clearlooks theme for Ttk and get it to work with git-gui, but I consider that “native enough” because all of the other equivalent tools that are “more native” had worse workflows.
Edited 2018-06-06 00:33 UTC
Except all those libraries are not provided by the system, thus are not native to the system.
That depends on who you ask. I run a KDE desktop, so Qt is “native to the system” because it’s the foundation my desktop is built on.
That aside, I’m talking about native UX, not native code. (eg. “How native does it feel to an end user?”, not “How native does it feel to the CPU?”.)
As GTK+ drifts further and further away from my ability to make it “feel native” on a KDE desktop. (It’s the same thing as “Android is not Linux”. Playing around with definitions doesn’t win the argument just because the person on the other side isn’t using the terminology you’d prefer to refer to the concepts they assign significance to.)
Edited 2018-06-06 16:46 UTC
Ugh. I somehow edited that As GTK+ … sentence into incompleteness, didn’t notice until it was too late, and now I don’t even remember what point I was going for.
Edited 2018-06-06 18:49 UTC
Native is compiled code to a native binary using system provided frameworks. Everything else are just abstraction layers.
What a strange view. The terminal is pre-desktop. The browser is its own eco-system. Native apps ARE the desktop. And there is nothing more native on macOS than Cocoa/AppKit/UIKit.
I would argue «portable» apps are «rubbish». I want apps optimized for the desktop, thank you. I have no need for «portable».
Too much effort is made in making software portable. That portability comes with a price that not everyone wants to pay, and certainly not all software has to be portable.
A Mac is a piece of expensive but beautifully and “carefully” designed technology. That applies to software too. If I wanted portable apps, I would be using a cheaper generic PC with Linux.
Instead I want something better. A better experience comes from software designed to fit with the desktop ecosystem where it runs. If it’s generic and portable, you’ll get a generic experience. You might as well sell your expensive hardware and buy a much cheaper one and then run that application in Ubuntu, or perhaps buy a ChromeOS laptop and run only web applications.
Maybe I don’t know enough people but I don’t know anyone who has ever said `I wish this ios app was available on macos`. What amazing ios apps are there that macos users are going to line up for?
I can’t say about Apple stuff, but I would find handy if a few Android apps would run on my Linux desktop. Not a really big deal, just handy.
I do not think it has to do with “amazing” iOS apps getting lined up to be purchased, but a simple way to reach more potential customers since not every Mac user has an iOS device. For us Angry Birds users on Macs it will be nice to get all the updates (levels) iOS users get.
Additionally, when Apple releases a Mac, with an A-series processor running macOS, there will already be a slew of applications available. Those needing an Intel processor will get a Mac with an Intel processor while still being able to use ported iOS apps, and those not needing an Intel processor will get a Mac with an A-series processor which will run ported iOS apps.
In the Human Computer Interaction field, this is currently the focus to save time and money: Develop software for the small screen first, and then add things for bigger screens, then adapt it to another interface.
That last one is the issue I believe Thom was referring to and, indeed, as someone who has been using the apps from Windows 8 / 10 trying to do this, it’s the hardest thing to really accomplish, since if an application is more popular or profitable on mobile, the desktop will quickly be made into an afterthought, and perhaps viceversa (I haven’t seen a mobile app get ported masterfully as a universal application to the desktop, so there’s that).
I am personally more worried about Apple neglecting the desktop accessibility aspects of apps and usability, since thankfully their screens are not touchscreen.
I hope they prove me wrong though, since I do love my desktops and laptops to not have touchscreens.
“can you really argue that the distinction between the two platforms really matters?”
it does matter, because it’s not vice versa.
they’ll just let ios devs quickly add mac versions for (some) of their apps, but that won’t mean that complex and professional mac apps will find a way to ios so easily.
“can you really argue that the distinction between the two platforms really matters?”
You’re pushing this agenda very strongly at the moment, but this is really stretching it. Matters to who, exactly?
To developers? Lazy developers make lazy ports – that’s as old as time. XCode gives them that option on iOS, Mac and even Apple TV already. Mostly they stick with iOS because that’s where the money is. Good developers will use the new compatibility framework but spend time on a meaningful distinction between touch-based and non-touch-based interfaces.
To users? This is surely where the meat of the argument is, and there would still be a learning curve, a culture shock even, for a user moving from one to the other for the first time.
The Mac GUI is fundamentally the same WIMP-based desktop-metaphor GUI that is was 34 years ago. The iPad/iPhone is the same touch-based system that it was 11 years ago. Placed side-by-side the two systems are clearly and obviously different and the differences only become more pronounced when you start using them.
Is an operating system merely the sum of the applications that run on it?
Adobe Photoshop will look and feel the same whether you’re running it on Windows or Mac. Does that mean the distinction between those platforms doesn’t matter any more? What about Apache/MySQL/PHP with MacPorts/Brew? These applications don’t even need to make the leap from touch-based to non-touch-based – they’re basically the same wherever you run them.
The difference of course is that this is an official Apple framework, rather than some 3rd party compatibility layer, but that’s irrelevant for most users. They see a tablet with touch; or they see a laptop with a keyboard, a trackpad, a screen with a ‘desktop’, windows, icons, pull-down menus and a pointer.
I think it matters to you that you’ve made predictions and you want to be able to say “effectively, this proves I was right”. That might seem a little harsh but if not, then I repeat, “really matters to who?”.
There will still be cross platform desktop apps. And let’s be frank, some of professional apps can’t be done on mobile.
With that in mind, I think ported iOS apps will be both great success and great failure. Success because there will be many such, and it will be lesser effort for some iOS developer to make desktop version. Failure because there will always be some of those awesome, detailed, and powerful apps on MacOS to make comparison and feel the limitations.
I’m not sure this is good news. The Mac world will be flooded with dumbed-down freebee and pay-to-play tablet apps that will displace full-functionality desktop apps, even if they be better than the appalling tablet-like applets that come with W10. The race to the bottom we saw in the iOS app market will all but wipe out serious applications. Good for simple games, though, I guess.
I am not sure, what the author is trying to tell me – is he trying to tell me, that porting applications is the wrong way in doing things?
At least i am missing an opinion of what the author considers to be the better way besides complaining.
Edited 2018-06-06 11:32 UTC