6 ms·

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

by untog 9y ago

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.

jasonkostempski 9y ago
I feel like the Ubuntu phone might have succeeded had they not focused on trying to do it this too. So sad.
- untog 9y ago
  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.
  - criddell 9y ago
    Are you talking about everything being an Electron app?
    - untog 9y ago
      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.
    - jimmies 9y ago
      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.
      - throwaway2048 9y ago
        20? try 200
    - mr_toad 9y ago
      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.
      - criddell 9y ago
        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.
abakker 9y ago
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.
- mikestew 9y ago
  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.
  - abakker 9y ago
    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.
  - Corrado 9y ago
    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.
CodeWriter23 9y ago
> 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
- frik 9y ago
  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)
  - saagarjha 9y ago
    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.
    - frik 9y ago
      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.
      - saagarjha 9y ago
xocyabencl 9y ago
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.
- DaiPlusPlus 9y ago
  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.
  - paulryanrogers 9y ago
    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.
    - kartickv 9y ago
      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.
      - untog 9y ago
        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.
        kartickv 9y ago
chrisbrandow 9y ago
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.
cm2187 9y ago
Looking forward the combination of webassembly (as a full virtual machine) and adaptive web apps, for a single app across every device and OS...
- lawnchair_larry 9y ago
  Would users want this? That seems like a huge step back for performance.
  - cm2187 9y ago
    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.
tinus_hn 9y ago
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.

by untog 9y ago

jasonkostempski 9y ago

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

untog 9y ago
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.
- criddell 9y ago
  Are you talking about everything being an Electron app?
  - untog 9y ago
    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.
  - jimmies 9y ago
    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.
    - throwaway2048 9y ago
      20? try 200
  - mr_toad 9y ago
    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.
    - criddell 9y ago
      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.

abakker 9y ago

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.

mikestew 9y ago
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.
- abakker 9y ago
  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.
- Corrado 9y ago
  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.

CodeWriter23 9y ago

> 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

frik 9y ago
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)
- saagarjha 9y ago
  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.
  - frik 9y ago
    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.
    - saagarjha 9y ago

xocyabencl 9y ago

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.

DaiPlusPlus 9y ago
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.
- paulryanrogers 9y ago
  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.
  - kartickv 9y ago
    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.
    - untog 9y ago
      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.
      - kartickv 9y ago

chrisbrandow 9y ago

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.

cm2187 9y ago

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

lawnchair_larry 9y ago
Would users want this? That seems like a huge step back for performance.
- cm2187 9y ago
  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.

tinus_hn 9y ago

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.