MacOS Marzipan | Hacker News Reader

MacOS Marzipan

benjaminmayo.co.uk

233 pointsadrian_mrd141 comments

Some people have been clamouring for a way to run iOS apps on an Mac for a long time, and now here it is.

When Marzipan was first announced, Apple was very careful to temper people's expectations. Marzipan is not about some grand new cross-platform development framework. It's not about merging Mac and iOS. It's about allowing iOS developers to port certain iOS apps to the Mac with as little friction as possible.

And in that sense it's a complete success. Many 3rd-party apps can already run inside of Marzipan with little or no code changes. That's a huge win.

There are some very obvious downsides. Most iOS apps are a poor fit on the desktop and won't conform to the expected Mac desktop expectations. I suppose Apple could have gone the Windows 8 route and put these iOS apps in a completely separate environment, but we all know how that turned out on Windows. At least these apps attempt to mesh with the regular desktop environment.

Another downside is that it's a hack. These are pure iOS apps running inside of an iOS simulator designed to look like a Mac app. These apps have no access to the world outside of iOS.

If you're looking to make a great modern Mac app, Marzipan isn't for you. If you're looking for an easier way to share UI code between your AppKit and UIKit apps, Marzipan has nothing for you. If you have a relatively simple iOS app that you think might be useful on a Mac, Marzipan is exactly what you've been waiting for.

If you want a peek into what a grand new cross-platform development framework might be, take a look at the JetEngine.framework embedded in the Mac App Store app. It appears to be a separate UI framework that is neither AppKit nor UIKit, but can run on top of either. However, it's full of App Store-specific UI components and I would expect that it was developed only for internal use at Apple.

App Store is an awful app experience, just like iTunes, because they both feel like they're just rendering XML that comes down from a server instead of being a real UI implementation. Everything's slow and laggy under the best of internet connectivity circumstances, and once you leave the beaten path it's just excruciating.

Parent specifically talks about the new App Store and it's new engine.

Also, the App Store is a client for remote data (what's on the store). What should one expect to see when there's no connectivity? A local cache of all app data? That could be feasible, but also not very useful (you still can't buy or download) and might be misleading (e.g. an update might have been added or taken down etc).

>What should one expect to see when there's no connectivity?

It's not that there's no connectivity. Whatever they're using for metadata is extremely slow. As though all requests need to go to California or something.

> A local cache of all app data?

Yes. This is how Linux package managers all work; metadata is cached locally so search (and dependency analysis - not needed in AppStore) performs well.

It's worth noting that most linux package managers are CLI and their GUI tools suck. It's hard to make a good GUI and App Store is no outlier in that regard. Unfortunate that there's no CLI alternative.

Not from Apple, but there's mas: https://github.com/mas-cli/mas

The new app store in Mojave seems fast and snappy. I agree about the previous version though.

I think the old App Store literally was just a WebView, since you could see overscroll shadows. Now it seems to be much closer to 'real UI' dynamically rendered by the remote data.

Not sure about the App Store but when you get into the preferences -> icloud -> manage you can right click on that window and "inspect element" and safari debugging window will pop up :)

It definitely was, rubber banding had the exact same bugs and performance issues than Safari had (which have since been fixed).

Ugh, its that bad on iOS. I never wish for people to have to go through the process of changing their App Store country. It's a painful, buggy process with a horrible UX.

The purpose of making the process difficult is deliberate, to dissuade users from doing so.

I think it's less a calculated act of hostile design and more of a Hanlon's Razor moment; a manager says "It's working so it's good enough. We won't work on that because it's not a priority right now." I don't think the companies have enough time and energy to purposefully implement dark patterns.

Why would you do that?

Maybe put some pages explaining when you would need this functionality, that you have to be living in this country, etc. Or you could also limit the amount of times a user does it for maximum once in a month or less. And so on.

There's a lot of good alternatives, having bad UX should never be one of them.

Otherwise your users are just going to solve it their way, like in my case, where I had to create another account and backup all my stuff from the old account simply because I moved from my country.

The reason I suggested it as a possibility is that I see UX these patterns in other Apple products.

For example, the iOS Camera app hides away options for the frame rate and resolution of video under several menus. This option is much more accessible in actual cameras. In Apple's case, it's put out of easy reach to prevent the user from obsessing over which resolution to capture a moment, and to provide a uniform appearance to all captured content.

Options are hidden away to reinforce a set-it-and-forget mentality.

I've never fully understood why the App Store has continued to have such a poor user experience.

Because that's literally the case. Check the network traffic with Surge or Charles. I'm not sure if the iOS 12 store has native parts to it (because it's pretty responsive), but there's always a significant XML blob downloaded.

The App Store app isn't particularly great, either. There are many UI paradigms it ends up breaking, and of course, it still goes for that sidebar/main window layout that all the Marzipan apps use.

I much prefer the new MAS than the old one, which was a poor WebView hackfest. That one feels more native than the brand new News/Stocks/Voice Memos apps, as described in the article: search box roundrects are correct, search focus and clear behaviours are consistent, titlebars are displaying content title, not app name.

There are a number of buttons that do follow iOS style though. Also, "Redeem" and "View information" open up views that were previously unavailable except through iTunes, and you can see a mishmash of styles there too.

The two things that infuriate me though are the font size of the sidebar, and the laughably placed "Done" button on the top right when you're viewing a story.

Apples been trying to push the sidebar thing for a few years now on general Mac apps. It started as an evolution of the Finder sidebar and was named “source lists” for a short while and now it’s just called Sidebar in the default View too menu for new apps. Every time I go to use Notes on Mac I get confused by the two sidebars. Hopefully they calm down on their sidebar mania a bit soon. The web is a great proving ground for hierarchical organization of widgets and information, and I hope Apple can be humble and take notes from conventions that are popping up and sticking around about how to do “multiple sidebars” a little smarter.

>Every time I go to use Notes on Mac I get confused by the two sidebars.

You mean the actual sidebar (with the top level note folders) and the notes list? That has been the norm in 99% of note apps (and similar 'bucket' apps) for ages, across platforms...

Any particular sites/webapps you like as examples of hierarchical design? I am a tech lead and struggle to come up with anything better than Material Design's nav drawers with sub-items, or equivalent.

Not the OP, but one thing that springs to mind when talking UIs and web/native is the use of breadcrumbs online. For example, if seeing a list of all other notes in the same folder isn't a key use case, an alternative could be to hide that list but make it visible when activating the list's parent. This reduces the noise so the individual note can be focussed on.

Having said that, I suspect the use cases of notes are quite varied, so a one-size-fits-all approach might not be straightforward.

>and of course, it still goes for that sidebar/main window layout that all the Marzipan apps use.

So?

It's not a particularly inspired design; for whatever reason it just seems really out-of-place to me. I know there are some apps that utilize the sidebar/main window thing, but they all feel like native Cocoa apps while these have different spacing, search fields, etc.

It's more about the UI than the specific layout; no-one ever complains about Finder's 'uninspired' sidebar/main content layout. The inconsistencies which make the App Store feel alien on the Mac are what gets me. Also, I don't know if it's just me, but the App Store seems almost entirely keyboard-unaccessible.

When Apple rewrote iPhoto as the Photos application a few years ago, they used a private framework called UXKit that also implements UIKit on the Mac.

They've been working on this for a while.

http://www.idownloadblog.com/2015/02/05/photos-mac-uxkit/

It doesn't implement UIKit; it provides a shim on top of AppKit that makes the API look similar to UIKit.

Apple always had UIKit working on the Mac, the iOS device emulator runs it.

>These apps have no access to the world outside of iOS.

Well, they can save files (like Apple's own audio notes app), connect to the network, and so on. So what access do they lack? They're not on the same direct kernel? That's probably for the better.

One article mentioned that dragging something to the desktop causes the app to block/freeze for several seconds. Having access is not enough on its own - it also has to be reasonably performant and not too glitchy.

The Photos app has the same kind of behaviour when dragging photos. You'd be hard pressed to select a bunch of photos/videos and drag&drop them anywhere but on a folder (typically the desktop). Even then, copying them seems to trigger an "export" process (sometimes you see a progress bar or something with that label to that effect, I can't recall right now) that takes ages. Alternatively, you can "Reveal in Finder" and copy/drag/whatever the photos/videos from there and it's instantaneous.

Even though it still triggers an export, this behavior has gotten a lot better in Mojave. Whereas previously one could only really drop images on Finder windows (Desktop counts as well) it now works in many different applications. Not quite everywhere, but at least it works most of the time and I don't just not even try it.

> They're not on the same direct kernel?

They are on the same kernel. As far as I'm aware, they're in the same namespace as well, so this isn't just a simulator, either.

>These are pure iOS apps running inside of an iOS simulator designed to look like a Mac app. These apps have no access to the world outside of iOS.

If you mean the current 4 iOS app running on 10.14, then i agree. If you mean project Marzipan in general and what it means to developers, well we just don't know yet. Its going to be the next WWDC at the earliest before we hear any new information on the topic and its overall goals/capabilities are yet to be fully defined.

It’s a bit sad; Apple is setting the standard here and it stinks. That’s how we ended up with having to accept Electron apps.

Do you have any more info on Jetengine.framework ?

This is all the references I could find to it in the OS X header dump:

https://github.com/w0lfschild/macOS_headers/blob/master/macO...

Electron started as a similar “simulator”, and look at it now.

This thing will be massively popular once mature. Whether that’s a good thing for MacOS in the long run, I don’t know.

To me it looks like a time saver with mediocre results. Easy and fast, but not great.

For those of us that aren't keeping track: "Marzipan is the code name for the technology that will allow iOS developers, with just a handful of modifications, to port the iOS versions of their apps over to the Mac." [0]

At least it's better than Electron, I guess. It seems ridiculous that Apple wouldn't put up the resources to implement these apps properly on macOS. But I guess getting a bad version of an app is better than nothing at all.

I hate the whole mobile-first trend, since it usually means fucking over desktop users. Remember multi-window apps? Now everyone seems set on forcing everything to be done from a single window.

[0] https://arstechnica.com/features/2018/09/macos-10-14-mojave-...

At least it's better than Electron, I guess. It seems ridiculous that Apple wouldn't put up the resources to implement these apps properly on macOS

The entire purpose of porting these apps to the Mac was to dog food Marzipan. If they had made “proper Mac apps” that would have defeated the purpose.

I suppose what the GP meant is that Apple, even if using Marzipan, was in power to do the job properly, from menubar to titlebar to modals and set a standard for developers to follow, instead of going the lazy route and have what appears to be mere containers of an iOS experience with only slight touches of macOS. It really does make me think of Electron, with foreign conventions held within a window and tentacles reaching out to some APIs like menubar and notifications.

They basically said at WWDC that Marzipan is still a work in progress. They haven’t even promised a date when it would be released. Isn’t it better to release early and often and get feedback? It’s basically a “technology preview”. It would be much worse if they thought they were releasing a fully baked framework in a year, tied down the APIs and be stuck with something that got negative feedback.

It’s strange that a forum that usually supports “development in the open” is now criticizing Apple for doing just that.

IMO that's a poor excuse; that's just tantamount to shipping your org chart. You ship the best product for your customers, and if the technology you've pre-selected as a vehicle actively precludes you from doing so, STOP, and re-consider what you're up to. Focus on the user, not management needs, not artificial technology limitations. Otherwise, you won't have users.

In the long term, it's better if Marzipan gets real-world usage from some less-critical apps than Apple shipping a half-baked SDK to developers next year with a great, native Home app.

It was never about the apps. It’s about getting feedback from customers and developers and iterating. Google has been shipping “beta” software for years.

It’s not like any of the apps they chose are core parts of the OS.

Apple is not Google.

>At least it's better than Electron, I guess. It seems ridiculous that Apple wouldn't put up the resources to implement these apps properly on macOS.

It's not about putting resources for their own apps or not. It's about enabling this route to macOS for iOS developers. They're just eating their own dogfood.

>Remember multi-window apps? Now everyone seems set on forcing everything to be done from a single window.

That's what most people want anyway. Not to have to manage 5 panels and sub-windows for each app on top of managing their apps.

Microsoft did the same, Adobe, etc.

> At least it's better than Electron, I guess. It seems ridiculous that Apple wouldn't put up the resources to implement these apps properly on macOS.

I'm confused. The resources already exist, it's called "implementing applications on macOS".

Marzipan is for iOS devs who want their existing application quickly running on macOS without actually porting it, either because there's some demand and they don't want to do macOS development or as a prelude to a proper port/cross-platform implementation.

Apple can't magick the void into the not-void, an iOS application works on different principles than a macOS one.

> At least it's better than Electron, I guess. It seems ridiculous that Apple wouldn't put up the resources to implement these apps properly on macOS

From people with experience in both, UIKit is better designed than AppKit. Apple sees this and I think it's pretty clear their intent is for UIKit to supersede AppKit on macOS. One day.

Apple unfortunately shipped what is effectively the alpha version to the public.

I did macOS development with AppKit from 2003-ish through 2012, then iOS with UIKit since. It's not that one's better than the other, UIKit is just newer. It wasn't clean-roomed, it was heavily inspired by the best parts of AppKit. Since then, many of the best parts of those changes have been fed back, yet again, into AppKit (view-based table views, view controllers, layer-backed views, CoreAnimation, etc).

They're built to serve different audiences, just like iOS and macOS they support. macOS and AppKit are designed around multiple windows, side-by-side, with very specific mouse and keyboard navigation conventions. iOS and UIKit are designed around single windows with nested navigation stacks, view controllers and gesture-based navigation. One tool for each job. It's not about replacement.

As always, you can use any API to implement any piece of software. It behooves you to focus on your user and pick the one that lets you provide the best experience. They're the same programming languages and just different accents on the framework. You'll figure it out if you care.

Speaking only for myself, I have no problem with windows/screens or mouse/taps being different. The parts that baffle me are those which have nothing to do with the different interaction models, and are simply different for no apparent reason.

NSColor/UIColor are different, and it's not like one color class is better for windowed versus non-windowed colors. NSBezierPath/UIBezierPath perform the same task yet often the same methods have different names.

I've wasted a bunch of time making extensions so that one OS's classes would look like the other (annoying but not difficult). The fact that every developer has to do this is just silly. Apple's own WWDC video on iWork essentially says "Because we wanted it to be cross-platform, we avoided drawing the standard way, and draw all content using CALayers instead".

If Apple did nothing else but make the parts that work identically be named identically, that would be Marzipan enough for me.

I agree the color and path classes being different is pretty frustrating. I think the argument that can be made is that the UI should be different enough between iOS and macOS that the incentive to share code at the UI level is limited. Sharing the model and business logic is, after all, seamless. There was a big push in the early days to true the lower-level APIs up. I also understand why they could justify to themselves a code-level compatibility barrier to make people think twice about sharing UI elements in a sub-optimal way. I'm pretty tepid on it, tbh.

> From people with experience in both, UIKit is better designed than AppKit.

Debatable. AppKit might have a bunch of legacy cruft, but it also has some truly beautiful things like bindings, or how certain interface controls work. It's a much more mature framework.

Bindings (and KVO/KVC that support them) are magic-oriented programming that make me sad. One has to assume they very specifically didn't make the cut when iOS and UIKit were designed :P

Interesting, i found bindings only useful for the most basic of UI and not really worth the effort.

> Apple unfortunately shipped what is effectively the alpha version to the public.

Apple hasn't shipped any library to the public.

I didn't make that claim.

There are 4 apps available for macOS that are entirely written with UIKit, with the exception of the bridge required to interact with macOS. They shipped those apps to the public, and they feel like incomplete apps.

> From people with experience in both, UIKit is better designed than AppKit.

Can you expand on this? I haven't done iOS development, so I'd be interested in what ways people consider UIKit superior. Although it wouldn't surprise me, since it came much later than AppKit and they had hindsight when designing it.

The topic of making UIKit available to developers on the Mac comes up from time to time.

People seem to go back and forth on it, as in this post from a couple of years ago.

>The thing is, UIKit "just works" (most of the time at least). AppKit has so much historical garbage that it's become a pain to work with for modern macOS apps. It's still really hard to make simple things like customizing system controls and Core Animation doesn't work as well on it as it does on UIKit.

https://medium.com/@guilhermerambo/why-uikit-for-macos-is-im...

I'd have to disagree with him here; he's unnecessarily biased against AppKit since he's more used to how UIKit is supposed to work.

Is anyone else concerned that the influx of cheap, low-quality iOS apps ported to Mac via Marzipan is going to effectively poison the well for existing Mac apps? Software prices have already been pushed to rock bottom on mobile but things are more sustainable on Mac, for now anyway...

Nah. Mac users who pay for software are a different demographic than their iOS counterparts in my experience. Such Mac users are usually professionals who pay a little extra for the reliability and quality and attention to detail that Mac apps have been know for for a while now.

Fair point. However, we already have an influx of cheap, low-quality web apps ported to Mac via Electron.

I think in this case Marzipan is a better solution, as it will allow willing developers to port native iOS apps to the Mac without much effort.

It won't help with webapp juggernauts like Slack or Skype, but it's definitely a step in the right direction.

I actually wouldn't mind having the iOS Skype app running on my Mac. It has a nice dark mode.

So would the old Skype desktop app, had they kept it around and linked it against a recent SDK. But no, they threw it out, replaced it with some sort of Electron mess, and now have to pay the price of not having proper dark mode support.

If Apple doesn't offer a better solution, Electron's performance will eventually catch up to "good enough" for all sorts of purposes and then nerds will really be crying as those Electron apps take off in popularity.

Slack is only the beginning, and Apple sees what's happening, perhaps a little bit too late.

The long term trend for software prices is towards zero, I'm not sure this will have much influence on that.

Why would it be toward zero? The authors of the software still have to eat.

"in the direction of"

I think there is an economic theory that the price of products tends towards their marginal cost which in the case of software is near zero.

As a final user I'm very happy software prices are plummeting, thanks.

Generally this also means the quality of software declines as well.

Are you? Wouldn't you prefer that software vendors can support themselves selling the software, and thus be able to update it?

> You get the standard rainbow close/minimise/full-screen widgets and they work fine. Window resizing using mouse drags — not so much. The performance is just poor.

It’s ironic that this is an issue again. Poor window resizing performance was probably the #1 complaint in Mac OS X 10.0 back in 2001 — resizing exposed the sometimes very slow rendering behind the beautiful new Aqua façade. Apple spent a few years tweaking resize performance, even adding AppKit APIs so apps can adjust their rendering when in live resize.

Doing layout updates in a rapid mouse tracking loop is hard. The iOS window resizing system was designed primarily around screen size classes which change on events (e.g. portrait to landscape), so there’s lots of fudge room to hide rendering updates while the entire screen is being animated. The desktop doesn’t have that luxury.

I welcome Marzipan.

It’s not perfect at the moment, but lately I feel like when I’m in macOS I’m running a browser and awkwardly trying to switch between tabs without Cmd + Tab. It’s not fun.

Over the last year I’ve been using an iPad with a hardware keyboard for productivity apps and it’s great. There’s apps for everything, even G-Suite, that I can Cmd + Tab through without any problems.

I really hope that the rough edges get worked out and Marizipan works; otherwise macOS will become even more stale.

The real abomination in Mojave is the Screenshot annotation tool. Good luck figuring out how to add and arrow with some text.

—

Edit: Changed Alt Tab to Cmd Tab

> awkwardly trying to switch between tabs without Alt + Tab.

Ctrl+Tab? (is it Cmd+Tab on the Mac?) Shortcuts like that are a big part of how I use the browser.

Yeah oops. Edited original message.

It's ctrl + tab in Chrome. You can also use option + command and the left/right arrows to flick between tabs.

There’s a different shortcut for switching between tabs in a single application. I don’t know if I customized mine but it’s something like cmd+Ctrl+arrow. Cmd+tilde switches between an application’s Windows.

I believe the default one is ⇧⌘[ or ⇧⌘].

on mac I use Cmd + Shift + [ or ]

You can also use option + command and the left/right arrows

This doesn't work for me. Are you sure this is a standard shortcut?

Seems like it works in Chrome. Not at all standard afaik.

Works for me in Firefox too.

I feel the same way about Windows 10 Store apps. They don't have the performance issues mentioned in the article but they otherwise feel alien to the rest of the OS. Even web applications feel more integrated.

ChromeOS's support for Android apps almost feels similarly alien, except that everything in ChromeOS is already a webapp so it's not too jarring.

As I've learned so often to do with Apple experiments, I'm going to ignore this one and it's probably going to get better or go away, I seriously doubt it'll stay objectively bad like this.

Apple does this from time to time. Remember when iCal looked liked, to quote a Gizmodo writeup, "a lone cattleman's notebook" missing only "animated beaded tassels"? Or when Game Center on iOS looked like "an evening of backgammon at the nursing home" that "smelled like plastic bottle whiskey"? [1] Because they absolutely did.

Let's see where this thing goes. Seeing them remedy their many flagrant mistakes over the years has given me, oddly, hope.

[1] https://gizmodo.com/5849940/ugh-god-why-apple-is-making-ever...

>Remember when iCal looked liked, to quote a Gizmodo writeup, "a lone cattleman's notebook"

And that was bad because? Enough things look like "a pretentious hipster notebook" already!

I don't think they were denigrating farm workers nor pushing the hipster aesthetic. It was a problem with not following Apple's own guidelines and making something that clashed so much with the rest of the system.

Yes it's not about what they made it look like - and to be clear, my understand was the intent was to replicate the rich leather feel of Steve's private jet. It's that they insistent on making it look like something at all, and that clashed with the entire aesthetic. Stuck out like a sore thumb.

Why was this changed to a less descriptive title? Seems more "clickbaity" now.

Not to mention that it should be "Marzipan on macOS" or similar; "MacOS Marzipan" just plain doesn't make sense. This makes it should like a version of macOS.

That's what I thought it was initially. I kind of forgot that Marzipan was included in Mojave and thought that this was some details about the _next_ incarnation of macOS.

> In this case, I suspect the Marzipan system houses apps in a window with a titlebar, and it automatically populates the window with the display name of the bundle.

It creates a window for each app, and the titlebar is set to the app name pulled from Launch Services.

I still think this is less about running iOS apps on Mac and more about pushing Mac developers to build their pro-tier apps as something that runs on Macs and iPads.

Mac has no shortage of apps. But the iPad Pro has a shortage of the sort of apps people use Macs for.

This sounds equally applicable to pgAdmin 4, or indeed any Electron app on a Linux desktop.

If I can run my baby monitor app from my laptop instead of my phone (with any degree of usability), I will consider Marzipan to be a huge win.

They should give you a native macOS storyboard that works with your iOS code. iPad apps used to have separate storyboards too, I think that lead to a lot of rethought applications instead of just stretched up. Working with different size classes in one storyboard becomes a nightmare quickly with a lot of differences.

If there is going to be an Apple Arm laptop, it would likely run an iOS derivative and would need both keyboard and mouse awareness.

Would Marzipan make it easier to go in the other direction, e.g. run iOS apps in tiled windows on an iOS laptop, alongside "CLI/terminal" windows?

> If there is going to be an Apple Arm laptop, it would likely run an iOS derivative

Why do you think this?

An Apple Arm laptop would compete with Chromebook & Surface Go, both of which are "locked down" and optimized for Arm, similar to iPads.

  - iOS is Apple's primary revenue focus
  - iOS is already optimized for Arm
  - iOS itself was derived from MacOS
  - iOS new derivative can support KB/mouse
  - Arm + macOS = no 3rd-party apps compiled for Arm
  - Arm + iOS = million existing apps
  - Arm + iOS does not conflict with expensive MacBook Pros

> iOS is Apple's primary revenue focus

> iOS is already optimized for Arm

> iOS itself was derived from MacOS

All true…

> iOS new derivative can support KB/mouse

iOS can support the keyboard currently, but not very well. And it can't support the mouse at all.

> Arm + macOS = no 3rd-party apps compiled for Arm

That's what an emulation layer is for.

> Arm + iOS = million existing apps

That's a nice bonus.

> Arm + iOS does not conflict with expensive MacBook Pros

Apple is no stranger to cannibalizing itself.

So, overall, I'm still not sold that they won't just make a ARM MacBook that runs macOS, rather than iOS.

Somehow I feel like it would be easier to evolve from the iPad pro with its keyboard to a more laptop-like experience than do the "Universal app" stuff again like they did when they switched from PPC to Intel.

And no, I don't think emulating x86 apps on ARM will work well. Both from a technical point of view and legal point of view (Intel patents).

Apple controls MacOS and iOS. They can make iOS support kb & mouse, even if initially focused on Apple apps like Terminal, Mail & office.

Windows on Arm is forced to use an emulation layer because the majority of Windows apps are x86. The majority of Apple apps are already on Arm.

Cannibalization is done to a smaller market in order to reach a larger market. Which market is larger for Apple?

Apple can do both: low-cost 2018 Arm iOS laptop and premium 2019 Arm MacOS Macbook (when Marzipan is ready to bring iOS apps to x86).

just one thing to remember: you can easily (as in, it's just an app you download from the windows store) unlock the surface go and run windows 10 pro on it.

i have one, and i'm doing it -- i can run docker and windows subsystem for linux without a hitch (and honestly, it's not a bad dev experience imho).

Why would they do this, instead of continue with the iPad Pro?

iPad Pro would continue. This would reuse many of the same components and address the "Macbook Air" market which prompted x86 Ultrabook designs. Apple would regain a design crown and compete with cloud-focused Chromebooks for students. The lack of "pro x86" apps on iOS would have less impact on students. It would reduce brand confusion with x86 Macbook Pros, while Apple continues to improve Arm cpu performance.

An iPad Pro 12 with external keyboard is poorly integrated and unnecessarily clunky, even though it's the least bad option today for "iOS laptop".

iPad Pro is rumored to be getting a USB-C connector, which could enable docking with desktop monitor & keyboard.

I wonder if people complaining about Marzipan are the same praising React Native...

It has a lot of potential but the apps included with Mojave feel way too iOS-like and out of place in macOS. Hopefully it gets better integration before they open this up to developers.

I suspect MacOS will slowly begin to look more like iOS. These apps might be the beginning of the trend.

I hope they don't ruin the dev experience. I love my Macbook Pro.

I feel like it's similar to the skeumorphism of the past coming back with a revenge.

Any one experienced the News app not syncing between Mojave and iOS 12?

It did that for me for a while, but eventually it came around to syncing.

> I debated calling this post ‘Home, News, Stocks and Voice Memos for Mac’ because it’s not really a comment on the Marzipan project initiative.

I would've been a lot less disappointed with the article if it had the alternate title.

Here's the thing: most users don't really care. The evidence is in the author's own disapproval of the slack app - about it just being a wrapper around a website disguised as an app. Guess what, slack desktop has a LOT of traction, and paying customers!

If an app is sufficiently good on Marzipan, then the users will steer it towards becoming better if they care.

> If an app is sufficiently good on Marzipan, then the users will steer it towards becoming better if they care.

I have never once seen anyone been able to convince Slack that their desktop app needs to be improved.

>Here's the thing: most users don't really care.

It was that attitude at Microsoft that opened the door for Apple to revive its fortunes.

What do you mean? Apple didn't really take a substantial market share from Microsoft. Apple was successful in a market that Microsoft chose to not compete in until it was too late.

>What do you mean?

I mean exactly what I said, Microsoft was complacent and it allowed Apple to cream off the most valuable segment of the market. Microsoft may still have the largest market share (in Desktop) but it was Apple that became the first Trillion dollar company.

Yes, but Apple didn't take away anything from Microsoft, so where's the connection? Their "users don't care" attitude on software worked out. Pretty much nobody in business is switching over to Mac OS (or iOS) and Numbers. Both companies are barely even competing in the same markets.

What do you think all the Mac users were using before they switched to the Mac. Apple had a huge switching campaign over many years. They might not be competing much now but MS didn't want to give up that segment. That's before we get on to what the iPhone did to Windows mobile.

I wonder what’s exactly preventing them from implementing UIKit on macOS, that necessitates running the app in a simulated iOS environment...

The biggest pain point on macOS is the crappy AppKit framework which has so many awful quirks due to legacy reasons (e.g. layer-backed vs non-layer-backed views, no standard collectionview, etc.).

My understanding was that they did implement UIKit on macOS, but that there are still limiting factors that force them to wrap them up in a VM (which will most likely change until next year).

There is no VM. Even the iOS simulator for iOS development is not a VM. When you run your code in the simulator, it’s compiled for x86 and linked against an x86 version of the iOS framework.

I know, I‘m a iOS dev. Some Marzipan apps reportedly are wrapped in a VM now. Haven’t checked myself.

> layer-backed vs non-layer-backed views

Most views are layer-backed by default these days. The newer APIs tend to "force" this decision on you by doing things like making your entire view hierarchy implicitly layer-backed in many cases to encourage layer-backing.

> no standard collectionview

NSCollectionView?

Yeah, I’ve heard that NSCollectionView got revamped in El Capitan or something, haven’t really checked it since then.

There is no simulated iOS environment here.

One thing i don't understand is, since most apps have a web version why would anyone prefer run a ios version on the desktop. I don't understand why apple would invest time in making this possible.

Instead of down voting, be useful and show your arguments. I really don't understand why.

Writing was on the wall as soon as mobile overtook laptops/desktops as Apple's cash cow, but it is still disappointing. Dumbed down, lowest common denominator UI will eat the Apple ecosystem.

After so many years of Apple fans telling everyone that any cross platform technology demonstrated absolute laziness on the part of developers that resulted in unacceptable un-native feel, how fitting it is that now Apple, the largest company on Earth, and home to the makers of AppKit no less, can no longer be burdened to take the time to write real Mac apps anymore.

I know that people will say that this is Apple working hard to make the Mac viable again, but especially when considered in the context of the poor Mac hardware in the past two years, I think it’s clear that’s not the case.

Not mentioned in this article is that these apps look weird because they’re using 1.3x scaling from iOS too. Apple barely takes the time to differentiate iOS on the iPad, or even the XS Max. Owning either of these two devices constantly feels like there would be obvious places to make the experience feel better than just a big iPhone. Do we really think Apple is going to work that hard on making iOS software feel good in the Mac?

Remember, when the iPad first came out, everyone said “oh it’s new, I’m sure they’ll really make the software different soon”. It took 7 years to get multi-tasking in there. And this was the star product for a while. iOS still doesn’t really feel like iPad is it’s home.

> Apple … can no longer be burdened to take the time to write real Mac apps anymore

I have no doubt that Apple could have written these from scratch and they'd be fantastic. They're just testing out the new Marzipan platform so that they can work out the kinks in it before launching it next year.

I agree. I'm usually the first to jump on lazy design or the near complete sacrifice of form and function just to release a few hours earlier to save more of daddy's precious investment capital ... but these are clearly just toys. It's a demo of the underlying tech.

I think the better argument is that giving such tech to 3rd part devs will encourage them to be lazy.

I am 100% certain these apps will not be fantastic in 1 year. Or 2, or 3.

Let’s look at another cross-platform app that Apple has had years to perfect, iTunes: terrible since they’ve had to make it work on Mac and Windows. Apple Music being the latest proof point that they cannot make a nice experience. The track record isn’t good.

But honestly, what’s the latest fantastic new Mac app you’ve used? I can’t think of any. The days of something like Keynote being released are behind us.

> I am 100% certain these apps will not be fantastic in 1 year. Or 2, or 3.

That's about how long it took Photos to become pretty decent. I'm sure people will eventually come around to designing for both platforms, but it will take a while for them to do so.

> But honestly, what’s the latest fantastic new Mac app you’ve used?

Well, there are a couple of third-party apps…

Indeed. This is just Apple's usual tactic of eating their own dog food, the same way that Finder used to be a Carbon app just to demonstrate that Carbon was viable at a time when classic Mac OS developers were hesitant to move to Mac OS X, this despite having Finder written in Cocoa to start with means we wouldn't have needed to wait for Apple to port to Cocoa much later.

Reply on news.ycombinator.com