Re: Makes sense
>Trying to shoehorn a complex app written for a large desktop monitor onto a small touch screen
Agree. I'll chip in from the point of view of browser apps.
Now, I know some (most?) of you frown on CSS. That's fine, if you are looking down at excessive finagling of form over function (I mostly write command line programs, so don't point the finger too much in that regard).
But, in MVC terms, CSS is also really, really, good at separating view/presentation/formatting concerns from the core model/controller layer. Recently, the responsive/mobile-first frameworks (Bootstrap being one of them) have been promising, and mostly delivering, screen-resolution independence. In theory, you could display the same website on a 480 or 1920 screen. There are a bunch of built-in functions that resize and re-flow the page at different resolutions.
But... in reality you (the coder) need to take into account the device:
- If you have large content widgets, they may not fit at all or be desirable at low-res. That's why you have breakpoints available for hiding widgets. If you are on low res and need to display something big, maybe that's another page. Or a modal. It's not just shrinkage.
- a desktop browser typically won't have touch gestures like pinch/spread. It will have right-mouse click (even though it's not often used in html/js). A mobile typically won't have "hover" sensitivity. So, if you were writing a complex app, you'd have to be aware of what's available.
- pixel count <> device size either. A 1920 5" screen is not the same as 17".
I don't meant to imply that browsers, html and js are the answer for desktop/native development.
But, optimized as they are for precisely the run everywhere mode, they show us that you still need the developer to be aware of what complex GUI interaction modes are available and the nature of the device it is run on.
The feature gap between devices isn't as bad on the web, because folks have limited expectations of what a browser app will do and how to interact with it. That's not going to be true of a serious and complex native app.
Pretending an app "doesn't have to know" will likely drive to lowest common denominator type of approach. While I haven't used Unity myself, I have had the misfortune of using Windows 8. Another example of less than stellar results would be Java Swing which manages never to quite take on the full capability (and look & feel) of its host platform.
For simpler programs, a possible solution for cross-device portability is to code a core app, w.o. GUI, and "skin it" with a presentation layer. But I don't think that layer really needs to be embedded in the window manager of the device, especially if the app needs to be aware of/and react to the device type anyway.
Rome wasn't built in a day and this is likely another step on a long journey. Best wishes to the Unity devs, I think everyone learned a lot from it - MS could have, but decided not to pay attention and went Win8. If someone really really likes Unity, I figure that's the beauty of open source, they can pick it up and run with it.
And, respect to Shuttleworth for taking what must have been a really hard decision.