4 ms·

Your assumptions hold for OS X and iOS even though they are not the same OS and never claimed to be. > Won't it just be easier, as a developer, to create a sin

Your assumptions hold for OS X and iOS even though they are not the same OS and never claimed to be. > Won't it just be easier, as a developer, to create a singular platform with two XAML (one for small screens, one for large screens) that share the same codebase? In theory yes, in practice changing the UI isn't the only problem. The problem is that a phone is much more limited, both in hardware and in what it is allowed to do. Just as a simple example, on the desktop you can have storage that's shared between apps (at least for now), hence if you want your app's settings to be synchronized with Dropbox, you only need to detect Dropbox's folder and save your stuff in it, whereas on a mobile, you need to integrate with Dropbox's API. Plus on the desktop you usually have a lot of storage space, like my 5 year old desktop has 1 TB of storage, whereas my phones only have 32 GB and 64 GB respectively and these are high-end phones. So clearly storage is a bottleneck on mobile phone, but not on desktops. Another simple example: battery life. Mobile developers have to worry about battery life, the big and forever bottleneck of mobile devices, whereas desktop developers have never been concerned about it. For example I avoided to install Skype on my Android for two years because it was sucking my battery dry in only 2-3 hours. And now mobile Skype is so aggressive in cutting down on background chat that I cannot rely on it to deliver chat messages on time. And you want to hear the worst part? Moore's law doesn't apply well to batteries, so unless major breakthroughs happen, this will only get worse ;-) And if universal apps on the desktop are as limited as their phone counterparts, that would turn out quite ironic for Microsoft to have turned your powerful desktop into a dumb phone just to have the same experience everywhere. Of course, them and others will try and turn this around as being for the senile grandmas everywhere that are unable to use their laptops, but many of us will have known the truth about that one.

pavlov 10y ago
For a lot of people, "desktop" really means laptop these days. Laptops are much closer to mobile than the traditional desktop PC you describe. Limited storage and battery life are important considerations on a MacBook just as on an iPad. Also the Mac desktop software environment is more like iOS these days, if you want to go through the Apple-sanctioned route of using the Mac App Store. For example direct folder access is not possible, so the Mac desktop app in your example would have to use the Dropbox API too.
- bad_user 10y ago
  > Limited storage and battery life are important considerations on a MacBook just as on an iPad. No, I don't believe that's true. Laptops are bigger, so they can afford bigger batteries. My Macbook Pro's battery holds without problems for 4 to 6 hours of intense work, which is not something I can say about my phone and I'm talking about working on and compiling Scala code and few things are more intensive than that. Also, most of the time, laptops are used while sitting on desks for actual work. Oh, I know, you might pull your laptop at your coffeeshop to write an email or write comments on HN, or you might need it for work during a flight, which is cool, but overall laptops do get used pretty near an electrical outlet. But the biggest difference is one of expectations. Phones are still communication devices which we rely on. If my laptop's battery goes out during a flight, I don't care because I do not need my laptop to make phone calls or to orient myself using maps or to call a cab or to open my travel documents or whatever. Whereas I do really need my phone. So the Scala compiler running on my laptop doesn't need to be battery efficient. But my phone needs to last for 12 hours while traveling, otherwise I'm fucked. > Mac desktop software environment is more like iOS these days, if you want to go through the Apple-sanctioned route of using the Mac App Store ... the Mac desktop app in your example would have to use the Dropbox API too Oh, I don't know about that and the reason is the Mac App Store is a wasteland and I can't think of a single app I installed from it. Also, the Mac App Store isn't the "Apple sanctioned" way and they know it's a wasteland too, it's not like they are blind. No, the Apple sanctioned way is to sign your app. Signing apps needs an Apple developer account, which is fairly costly for open-source devs, but at least I can see the benefit to it. And as long as your app is signed, OS X gives you no problem in letting it be installed.
GrumpyYoungMan 10y ago
>The problem is that a phone is much more limited, both in hardware and in what it is allowed to do. The full version of MS Office is capable of running quite well on those inexpensive Atom tablets with only 2 GB of RAM. That's about as much hardware capability as the average smartphone has already and peripherals can be handled by a docking station. Granted, apps will need to show different UIs and adjust power consumption depending on whether they're in mobile or desktop mode but convergence is really just about here.
dragontamer 10y ago
But why _force_ it with different APIs? Is it impossible to imagine a set of applications (ie: generic Bank of America banking app: take pictures of checks and send them in sorta thing) where the UWP model doesn't help? If you need a 2nd application for your task, then write two different UWP applications. If you don't, then write one application with two XAMLs. If you want a very cheap program, write one application with a "responsive" XAML that works on all systems. By unifying the code base, you have the flexibility to do whatever code you need. Different code paths if the applications are grossly different, or the same code path if you need to save some money.

pavlov 10y ago

For a lot of people, "desktop" really means laptop these days. Laptops are much closer to mobile than the traditional desktop PC you describe. Limited storage and battery life are important considerations on a MacBook just as on an iPad. Also the Mac desktop software environment is more like iOS these days, if you want to go through the Apple-sanctioned route of using the Mac App Store. For example direct folder access is not possible, so the Mac desktop app in your example would have to use the Dropbox API too.

bad_user 10y ago
> Limited storage and battery life are important considerations on a MacBook just as on an iPad. No, I don't believe that's true. Laptops are bigger, so they can afford bigger batteries. My Macbook Pro's battery holds without problems for 4 to 6 hours of intense work, which is not something I can say about my phone and I'm talking about working on and compiling Scala code and few things are more intensive than that. Also, most of the time, laptops are used while sitting on desks for actual work. Oh, I know, you might pull your laptop at your coffeeshop to write an email or write comments on HN, or you might need it for work during a flight, which is cool, but overall laptops do get used pretty near an electrical outlet. But the biggest difference is one of expectations. Phones are still communication devices which we rely on. If my laptop's battery goes out during a flight, I don't care because I do not need my laptop to make phone calls or to orient myself using maps or to call a cab or to open my travel documents or whatever. Whereas I do really need my phone. So the Scala compiler running on my laptop doesn't need to be battery efficient. But my phone needs to last for 12 hours while traveling, otherwise I'm fucked. > Mac desktop software environment is more like iOS these days, if you want to go through the Apple-sanctioned route of using the Mac App Store ... the Mac desktop app in your example would have to use the Dropbox API too Oh, I don't know about that and the reason is the Mac App Store is a wasteland and I can't think of a single app I installed from it. Also, the Mac App Store isn't the "Apple sanctioned" way and they know it's a wasteland too, it's not like they are blind. No, the Apple sanctioned way is to sign your app. Signing apps needs an Apple developer account, which is fairly costly for open-source devs, but at least I can see the benefit to it. And as long as your app is signed, OS X gives you no problem in letting it be installed.

GrumpyYoungMan 10y ago

>The problem is that a phone is much more limited, both in hardware and in what it is allowed to do. The full version of MS Office is capable of running quite well on those inexpensive Atom tablets with only 2 GB of RAM. That's about as much hardware capability as the average smartphone has already and peripherals can be handled by a docking station. Granted, apps will need to show different UIs and adjust power consumption depending on whether they're in mobile or desktop mode but convergence is really just about here.

dragontamer 10y ago

But why _force_ it with different APIs? Is it impossible to imagine a set of applications (ie: generic Bank of America banking app: take pictures of checks and send them in sorta thing) where the UWP model doesn't help? If you need a 2nd application for your task, then write two different UWP applications. If you don't, then write one application with two XAMLs. If you want a very cheap program, write one application with a "responsive" XAML that works on all systems. By unifying the code base, you have the flexibility to do whatever code you need. Different code paths if the applications are grossly different, or the same code path if you need to save some money.