Hacker News Reader

Comment by untog | Hacker News Reader

Well, I hope they can learn from Microsoft's total failure to do this.

To be honest, I don't see a persuasive argument. In order for this to be worth the extra development time the company needs to have a big marketshare on both platforms - MS failed because they had zero footprint on mobile, and I think Apple will fail because they have a relatively small footprint on desktop. As a third party developer, is it really worth your time to make a native macOS app when the web is already very capable? In some cases I'm sure it will, but in the vast majority of cases you're going to need to make a web version anyway (for the huge number of Windows desktops out there), so a native macOS app just wouldn't be worth it.

View on HN

Unifying the ui itself is less important than unifying the frameworks to build the ui.

Assuming that the effort is focused on making frameworks that simplify macOS development for folks trained as iOS developers, then this will have a large impact on native Mac development.

Microsoft failed because they had few developers for either the desktop or mobile version of the framework. The countless Windows apps did not become buildable on mobile. If Apple makes it easy to add OSX support to existing iOS apps, they will have a lot of success.

That, and the fact the new XAML UX framework can only be used by AppX apps that run in the sandbox. “Normal”, otherwise unconstrained Win32 programs can’t use it.

This decrease in capability seems to be a weakness with Mac App Store as well, that and the ramp up from 0% to 30% of purchase price.

As a user I personally prefer more powerful software and a more financially motivated developer; even when it makes buying more bespoke.

What are some alternatives to Mac App Store that give the developer the same services, like handling payment, including subscriptions, downloads, some DRM to prevent casual copying and updates, for less than 30%?

Last I checked, I had to assemble the above from disparate services, investigating each, integrating them, and paying for each, which doesn't seem like a productive use of my time or money.

That's not an answerable question in any universal way. 30% of what?

Assembling from disparate sources will have more of an upfront cost but cost less per purchase. So it depends entirely on your sales volume.

30% of the sale price, obviously.

Regarding your second point, interesting, seems like MAS is good to get started until the app reaches a certain volume.

The "buy once update forever" business model of the Mac App Store is the real financial burden, not the ~30% tariff. Dev houses need some residual income, esp in the relatively small Mac market.

My guess is this could be driving the divide between semantic and vanity versions. If a developer has a big new update that's fully backward compatible they'll still be tempted to bump the major version of it means they can justify selling it separately. (Assuming stores allow names with a numeric bump.)

Counter argument: there are many app store apps that I would use on my laptop if I could - Unit converters, resistor code calculators, etc. I use them on mobile, and I google those things, but I would probably buy certain iOS apps to only use them on desktop if they were available.

Man, you could almost see that in the old OS X Dashboard. In fact, the early Apple iOS apps looked like they took cues directly from some in-house dashboard apps. I thought for sure that one of these days one would be able to put iOS apps on the Dashboard. Dashboard’s gone, but this still might work out in some fashion.

The Dashboard isn't gone! You can still enable it in Mission control and can decide whether it is a separate space or an overlay. I still depend on it for about 10 different international clocks all the time. I too hope to see iOS apps there one day.

I love the Dashboard and even updated an app that displays weather radar for my city. The idea of the Dashboard being an iOS app workspace makes perfect sense and I can't see how I missed the connection before.

The naive approach to allowing people to develop applications that work both on mobile and on the desktop always fails because in the end the user gets a bad experience on the desktop, on mobile or on both. There is no UI that works on both mobile and the desktop.

Apple could unify UIKit and AppKit so you could more easily share parts of widgets and the backend code, but you'd still have to design the general user interface separately.

> MS failed because they had zero footprint on mobile, and I think Apple will fail because they have a relatively small footprint on desktop.

Two possilities here:

They dust off NextStep’s YellowBook support (Cocoa for Windows) and update it to support UIKit.

-or-

What if the parameters of Marzipan is not a compatibility API, but an effort to package the iOS Simulator and your x86 simulator builds transparently for the end user. Then port the iOS Simulator to Windows.

Halo Effect 2.0

To your "YellowBook" point, yes, looks like possibility.

And several Apple software like Safari 5 for Windows and iTunes already ship with macOS UI libraries ported to Windows. So in near future iOS apps may run on macOS and Windows - quasi true universal apps (not the UWP-crap)

You had been flagged for whatever reason…not sure why.

> several Apple software like Safari 5 for Windows and iTunes already ship with macOS UI libraries ported to Windows.

Actually, the situation is kind of the opposite: Safari and iTunes eschew the use of macOS's UI libraries. Safari, in particular, is actually just WebKit (which has no "UI") wrapped up in a Windows-style chrome to appear native. iTunes itself, even on macOS, is some sort of weird C++ hybrid abstracted API that's not Cocoa (which is why it looks so "off" on macOS). This, along with a version of Foundation/CoreFoundation, allows it to work on both platforms–though not very well, I'll admit.

Yes true. What I meant:

Safari 5.1 (Win32 version, discontinued) comes with several MacOSX user mode libraries ported to Win32 DLLs.

Older iTunes and QuickTime (like 5 years ago) came with MaxOSX libraries ported to Windows too - at least from what I recall.

Someone keeps flagging you…

I feel like the Ubuntu phone might have succeeded had they not focused on trying to do it this too. So sad.

It feels like a "X is the year of the Linux desktop!" comment to make, but I'm more and more convinced that the web is will be a very viable mobile app platform soon. Progressive Web App APIs are solving a lot of the homescreen/notification/other native functionalities, and performance is always getting better.

One day there might be an opportunity for a web-focused phone OS (what Firefox OS was trying to be, essentially), but... not quite yet.

Are you talking about everything being an Electron app?

Well, I'm talking about mobile, so the Electron model isn't quite applicable. But sort of, yes. Except without the overhead of each app bundling it's own entire browser runtime.

Progressive web apps actually run in the browser (any modern browser), whereas Electron runs its own copy of Chromium and Node.js, which is why you see the bloat.

It's all about trade-offs though, right?

Compared to a native app web apps are bloated, slow, have foreign UIs, and are power hungry. On a desktop machine, it probably doesn't matter, but for anything battery powered it does. I'll choose a native app any day of the week over a web app.

When I see the word Electron, I just don't install the "app." I am convinced that the 3MB winamp does just a good of a job being a media player as the stupid "electron" "app" that takes 20x as much RAM.

20? try 200

Looking forward the combination of webassembly (as a full virtual machine) and adaptive web apps, for a single app across every device and OS...

Would users want this? That seems like a huge step back for performance.

Why would it? Webassembly is meant to be close to native code performance. An HTML UI has no reason to be significantly slower than a native UI.

Reply on news.ycombinator.com