Apple made a big shock this year when WWDC announced that developers could transfer their iOS applications to their Mac sometime in the course of next year – and that Apple had already started the process through the iOS versions of the Home to bring, Stocks, News and Voice Memo apps for macOS 10.14 Mojave.

The project – reportedly the codename Marzipan – is still in its infancy and Apple is not even planning to offer it to developers until 2019. And there's already a lot of confusion and indignation about what Apple is doing here: whether it's will see the death of the traditional Mac app as we know it, exactly how these new types of apps will work, whether they'll feel like traditional "native" Mac apps, and whether or not it's fair to call them ports of these apps. So here is what is actually going on.

To understand what Apple is doing, we must first understand Why we have this discussion even in the first place. Apple wants to make it easier for mobile developers to get something like their mobile apps on the Mac.

Why? Firstly, it is clear that many more developers are currently creating iOS apps than Mac apps. The ecosystem of the Mac app is not necessary in problems but compared to what happened on the iPhone in recent years, it certainly feels a bit stale. It would certainly help to make it easier to transfer iOS apps to the Mac.

As Apple developer Guilherme Rambo wrote in one piece a couple of years ago, some developers are currently forced to choose between developing and supporting an iOS app or a Mac app – and in a world where there are many more iOS users, the Mac often lacks great software.

And getting small, mobile first-apps on the desktop turns out to be incredibly useful. If you've used Android on a Chromebook, it's really great to have a lightweight app for lightweight tasks like scrolling on Instagram or firing a task list. Windows has tried to do something similar with its frameworks (limited, but increasing success), and Android apps on ChromeOS are out of beta, although they still need to add things to support windows.

The trick in all of this is how you get those mobile apps (or whatever word you really want to use) from mobile to desktop. And Apple's solution is in many ways the most interesting view of this problem that we have seen so far.

Let's start with the difference between Mac and iOS apps. At first glance, they look pretty similar: they use the same basic codals, such as Objective-C or Apple's own Swift, and many of the underlying APIs are the same.

So what is the difference? It seems obvious that it comes down to this, but it is the user interface. Mac apps work with a keyboard and a mouse, while iOS apps work with a touch screen. Simply transferring iPhone apps to the Mac in a way that is similar to Google's first beta & # 39; s of Android on ChromeOS is not the experience that Apple wants. Anyway

Apple's solution is to give developers the tools they need to make iOS apps a more Mac-like user interface.

So far, many Mac applications were based on a software framework called AppKit, which provides all the elements of the user interface that make a Mac app what it is: all windows, menus, buttons, scrollers, and text fields along with all high-level software-side things that your computer needs to actually display applications. AppKit dates back to the 80s and comes from the original NeXTSTEP application set. (For a more detailed history, here is a good place to start.)

When Apple developed iOS, it created an entirely new software framework for displaying applications called UIKit, which was designed for the smaller screens and more limited touch controls that iOS devices offer. But that means that a huge piece of [iOS 9016] how iOS apps appear on devices (up to the way colors are displayed, as John Gruber notes here) uses different basic code boxes from Mac apps. Add to that complexity is that AppKit is designed for mouse and keyboard input, while UIKit is designed for touch.

With Marzipan, Apple wants to bring the UIKit framework to Macs, which means developers can – in theory – offer a version of their applications that will run on Macs without having to rewrite them all over for the AppKit user interface. (In addition, by adding UIKit to macOS as a native framework, the ported apps will work natively, rather than in a simulator or emulator). Note that Apple is adding [U1990] UIKit, not to replace the traditional AppKit. Both will live side by side. Here, look at a map!

There is already priority for this type of transfer in Apple's own ecosystem – iPad apps and TVOS apps for the Apple TV already work on a comparable basis. They are built into UIKit and share the same code as an iPhone version. But developers can more easily transfer them from one platform to another and each platform still has its own interface with its own considerations, design and controls. Just as you do not expect an iPad application to simply be a giant iPhone app, or an Apple TV app to work as an iPad app with a remote control, Marzipan applications transferred to the Mac – also in theory – would own version have user interfaces and designs and layouts that are best suited for the desktop.

That is the theory anyway. But in practice, after trying a few new Apple apps on macOS Mojave, these apps look a lot like iPad apps. Of course you can not tap on it, but there is something about the layout and controls that look very similar to the iPad. You can change the size of the windows (as opposed to Android apps in ChromeOS), but re-drawing the contents of the window is sometimes a bit slow. There is simply no classic Mac feeling for these apps.

There is no app where that is clearer than the Home app, for controlling all smart home devices that you have. It looks a lot like a straight gate – with huge gigantic buttons for everything that looks like you'd have to tap on it. But you can not tap it because Apple fundamentally believes that touchscreens on laptops are a bad idea. As we do almost every year now, we asked Apple why that was the case, and the answer has not really changed: Apple believes that touchscreens on laptops are uncomfortable in use and most user research shows that even customers with touchscreens that barely use.

But do not get away from this thought that the end result will be a lot of apps that look just like iPad apps on the Mac. These few apps that Apple has released are only the first steps and marzipan is at least a year away from the availability for developers – Apple says it's a long-term project & # 39; is. In the course of the next year, we expect Apple to develop the frameworks and APIs to make these apps feel a bit more native to the Mac. And as pointed out by Steve Troughton-Smith, rummaging the rudimentary Marzipan support in the developer of the Mojave developer, Apple suggests that Apple is already starting: adding interface elements, such as the classic Mac app sidebar to UIKit, which enables developers to apps can make them feel more at home on macOS.

Moreover, we have already seen an unused (so-called) potential in these apps. When I started diving the Mac menu bar for these apps, all the classic Mac files and the Edit and View menu options were there. There were a few keyboard shortcuts on the keyboard, but not as many as you would expect. But it would be fairly easy to add more.

At the moment, Marsepein is still in its early stages and only Apple has access to it (unless you're very good at searching Apple's filesystems). The four apps that Apple has ported still look a lot like iOS apps that run on a Mac, which may not be the best start as an example for developers who want to follow the example if the goal is to get good, native Mac experiences.

As Tapbots developer Paul Haddid commented on Twitter: "UIKit on Mac feels more like running an iOS app in a customizable simulator than a next-gen Mac app," and the early Troughton-Smith experiments seem to agree, noting that the size of UIKit windows is currently quite slow.

As Apple's senior vice president of software engineering Craig Federighi remarked in an interview with Wired Apple is already planning to help developers in their process. Once the tools are available to developers next year, they can indicate in Xcode that they want to create a variant of their app that will run on macOS, which will automatically replace the way that some parts of the app work together. (For example, long press on iOS changes to a right mouse click with two fingers on a Mac).

In theory, can developers make the bare effort and create a version-based version of an iPhone app with Marzipan? Certainly, and there will probably be some attempts to do that. But that is missing the point of what this should offer. The goal here is not to replace native Mac applications with iOS versions – the idea is that developers can create custom Mac versions of applications that would otherwise never have made it to macOS, and expand what developers can offer on the Mac without the extra lift of writing a new, separate app from scratch.

For the same reason, ported iOS apps do not necessarily indicate that Apple is creating an iMac on the touch screen or MacBook Pro in the same way that TVOS with UIKit iOS apps ported by you does not mean that Apple is working an iPad without a touchscreen that works only via a TV remote control. Ideally these are in some form Mac apps with the same mouse and keyboard focus as every Mac app entails. (Again, this does not mean that Apple does not do that, predicting what Apple will or will not do on a given day is difficult.)

That said, the ported apps will also not be a 1: 1 recreation of an AppKit app: UIKit apps are still UIKit apps, which means – at least now, based on how Apple & # 39; s own apps look like – there is always something becomes a hereditary DNA, such as this extreme iOS interface of the Apple home app. But that does not mean that Apple will not adjust this in the coming year, or that we will achieve a kind of middle way. And there will probably still be room for traditional Mac apps for developers who choose to support them.

But there is another part where UIKit apps can serve for macOS – replacing the webapp style of Electron applications that have emerged in recent years such as Slack and Simplenote with native UIKit-based ports of the iOS counterparts. A lot of the most popular apps on the Mac are currently Electron apps and that could be a threat to the Mac. If everyone beckons to use only custom web apps, what should keep them from switching to a Chromebook or (heaven forbidden) Windows? Not so much!

And developer David Barnard claims that UIKit based apps for desktops can more easily offer these convenient, app-based experiences of our phones on computers, especially for services with better apps than websites (such as banks or weather apps). Even more, the Marsepean apps could probably offer better experience than Electron apps. Look no further than Slack, which is a RAM hogging goliath on the Mac, but works sweetly and smoothly on the iPad.

Much of this will depend on what makes Apple available to developers – at the moment there is no word about when these tools will start rolling to third parties to work on "next year", let alone a consumer release. And there are still a lot of questions, such as whether UIKit ported apps will be offered as universal software such as how iOS, iPad, watchOS and TVOS apps are currently bundled, or whether developers have both UIKit and AppKit versions of their apps in the Mac App Store.

But if developers can take advantage of the potential that Apple seems to offer here – and again, that's a big, theoretical "ALS" – it could mean a new wave of new native apps for the Mac changing how we deal with our computers, just as apps have changed the mobile landscape forever.

Oh, and two final bits of completely unjust speculation, just for fun.

First, one of the hits on the iPad Pro is that there are not enough "Pro" apps at the level of what is available on the Mac. But the iPad Pro has such a powerful processor and there are now so many features built into the iOS operating system, that problem seems more like a failure of the imagination than a failure of the operating system to support them. If developers get the habit of creating powerful apps for the Mac with these new tools, they might just continue and make them available on the iPad.

Secondly: iOS apps run on ARM processors, Macs run on Intel processors. As far as we know, it is not really difficult to get Marzipan apps on those Intel chips. If you ever think about creating an ARM-based Mac, you might want some apps that you know would do well!