A single USB port is not enough
Really, on a tablet you should be praising it for having a full size USB port at all. The fact it's USB3, doubly so.
Microsoft’s first take on Surface RT was a disaster, culminating in a $900m stock write-down in July. Curious then that the company has now produced the Surface 2 with a similar design, and also running Windows RT, the locked-down ARM build on which you cannot install desktop applications – only new-style apps from the Windows …
Really, on a tablet you should be praising it for having a full size USB port at all. The fact it's USB3, doubly so.
Irregardless of Windows 8 or RT, the limited time I had with the Surface 1 made me agree that it is indeed a supremely well built slab. All this talk about the usefulness of Office for enterprise users seems a bit near sighted though, as Office RT will not run the macro heavy Excel worksheets that most companies seem compelled to use. Add 3G option and it would be even more useful (maybe that's reserved for Nokia's version only?)
There's no such word. Use "Regardless" or "Irrespective".
It actually does exist, or at least according to the OED it does, it's just that it is considered as a nonstandard word.
It is a word. It doesn't get a wiggly underline by Chrome or nuffink so it must be.
I should know, I just made it up. (It means the feeling that one experiences when one discovers that the toilet roll has been mounted incorrectly).
(vexabibulus ... means the feeling that one experiences when one discovers that the toilet roll has been mounted incorrectly)
....or that the perforations don't line up... (Yes - I know how to fix that).
It should go in the dictionary with reciprivesexclusional (a number defined as having any value other than that of itself e.g. the number of guests at a restaurant - will be any number other than the number on the booking) an luposlipoculinophobia - the fear of being chased around a kitchen table by timber-wolves whilst wearing socks and a newly-waxed floor.
shouldn't the meaning be "annoyance at not being able to find the book you're after"?
Thank you so much for naming my condition. This won't stop me annoying guests and hosts as I rearrange their intimate bathroom setups, but now I can excuse it as a (perhaps medically?) recognised feature.
The app eco-system is still lacking, but I agree the Surface hardware design is nice. I got a first gen Surface RT at a good deal and it's a OK tablet, I prefer my Asus Transformer or iPad2 over Windows RT. Microsoft would be smart to let people develop for the RT's "desktop" instead of just the Metro interface. Also opening up so alternate browsers could be installed would be nice too.
That really is the issue - the x86 Surface Pro makes some sense for business users and others with portable windows needs, you can run most software on it.
But Windows RT has some really annoying limitations beyond what MS give you, and that is what they don't give you. In particular, that mere mortals can't produce desktop-style apps, but MS have that right for IE11 & Office.
Furthermore, you have to *pay* MS to sell your software via the app store, no direct sale/downloads like you can for x86 Windows.
So really, if you want a slick fondleslab look to the IPad (or cheaper & often nastier Android ones) or pony up for the x86 Surface and get proper Windows support.
How much did Microsoft pay you or indeed The Register to write that?
Your overall view essentially says "buy it because it's well made".
Well, I'd rather not buy it because...
- There's no apps
- It's too expensive
- I'd rather have a laptop for proper work
- I'd rather have an iPad or Android tablet for messing with
- It's destined to fail
Thanks but no thanks.
I think you will find "The Register" is not a monolithic Borg, but an outlet for a number of journalists with a varying range of personal opinions.
"How much did Microsoft pay you or indeed The Register to write that?"
If you read The Register you'll know I don't speak nice about anyone unless it's true...but Tim isn't For Sale. I'll not say I agree with the man in all his works, but he's honorable and believes what he writes.
Besides, if you're a fan of Microsoft's paint-by-numbers OS (and Tim is) then the Surface 2 is a wonderful little machine. Had a chance to give one a quick poke and it looks to be nearly as well crafted as my Asus Transformer!
So really then, it's a question of "do you want Windows 8 or Windows RT with that?" If you don't, well, there's lots of other options. If you do...Microsoft seem to be offering a good machine.
Nothing paid-for about that.
>How much did Microsoft pay you or indeed The Register to write that?
Twit. The only two objective points you raised, the range of available apps and the price, are clearly stated in the article, an article that one must read because there is no final 'score' at the end for people to skip to. People will read it, and have a better idea of whether or not the device will suit their own individual usage model.
Anyway, Reg readers don't need me to point out that they can see if all the WinRT apps they want are available... just poke around here:
Reg readers are numerate, too, so they can also make sense of whatever digits follow the £ sign unaided.
How much did Apple or Google pay you to write that comment?
Seriously ? Now, in all honesty, trying to be humble, there are more surface 1's on the tip than in customer's hands. This guy writes that the surface 2 sucks in every aspect, except that it runs faster than surface 1, has office and is well built.
Nobody wants a tablet for work, though you could get a high-end android tablet and put linux on it ... that would beat any windows box (even i7), productivity-wise, but that is not the point.
No, the point is, nobody likes windows 8 ui, nobody thinks Microsoft is cool, nobody cares to write apps for surface, nobody wants surface because there are no apps.
Bottom-line, MS desperately tries the reality distortion tactic and without coolness, is doomed to fail.
Surface 2 will fail just as miserably as surface 1 failed.
So the question, which I consider very legitimate, is: where did el reg find a twit to write such an article ... come on, nobody is that dumb ... so maybe there is cash to be had - I personally experienced MS trying to buy ppl, so I would not be surprised.
Grow up ? No, get your head out of the sand !
To be fair "runs fast, is well built and has Microsoft Office" fulfills most requirements that I have to deploy a field unit to my staff and most of my customers. All that's missing is:
1) Genuine "all day" batter life. (12 hours of RDP or 16 hours of Web).
2) A price point that is closer to $500 than $1000
Right now, if I am going to drop $1200+ on something it will be a Lenovo X230. Why? Because - while expensive - it can be equipped with an additional battery and an expanded internal one to meet the battery life requirements without giving up on the others.
So surface is close. If only they'd make the damned thing into a netbook form factor and replace Windows 8 with Windows 7...
Man, I'd love a notebook that well designed.
A Pro microsoft piece.
Quick, someone's done a DNS hijack on theregister.co.uk.
Even I couldn't polish those MS turds.
Appropriate moniker idiot. You are a stain on humanity. Take your stupid shit elsewhere
>Even I couldn't polish those MS turds.
Not even you? Gasp, not even Wang, when normally he's so adroit at buffing shit...
Your article reminds me that what I want is a ChromeOSTablet with usable cover keyboard.
What I possibly want is a Nexus 10 that can become a second screen to a Chromebook, or maybe an iPadBetter that can become a second screen to a MacBook.
And 15 hours of battery life.
The only Android tablet I know of that can function as a second monitor to a laptop is this new Wacom thing, when it also acts as a digitiser for the laptop.
There may be others I don't know of.
"What I possibly want is a Nexus 10 that can become a second screen to a Chromebook, or maybe an iPadBetter that can become a second screen to a MacBook."
Well, at least the second screen bit is covered: https://itunes.apple.com/us/app/iscreen/id379944104?mt=8
With the app store its going to be one of those ongoing things, its not going to have the market share of Android or mindshare of iOS to pull the devs in and seeing as most Win8 machines run Pro a lot of companies will just see no need to make an app as it runs a host of full fledged non-gimped web browsers.
Microsoft needs to take the bull by the horns and start competing with those services that aren't supporting Win8. They really need to consolidate their software ala Google+. If they build on the SkyDrive platform giving additional storage specifically for video and photos then extending the sharing settings to give a range from private, to friends and family to public and you've already got the base of a Instagram and YouTube competitor without having to launch a brand new platform. Integrate that into the existing People's Hub on Win8/WP8 and turn that into a standalone app that's available on iOS and Android to get that user base.
Microsoft needs to stop pandering to devs that aren't interested and adopt a f*#k 'em attitude instead.
Right, as if MS doesn't already do that enough.
Definitely what won't work, what they need is an "innovative" integrated "open" solution. :)
For example, rather than cloud file storage being tacked on as an Operating System afterthought and botched in the same ghastly, quasi-usable way as "libraries" in earlier full Windows OSes, actually properly integrated. The important thing, is it must be fully, 100%, utterly open, not MS's traditional half baked, only available fully internally with agendas to "support" MS technologies that 95% of users really don't want or need.
Consider an OS that could just open a DropBox file and save it back seamlessly, with no external interfaces, no further messing, just a user-facing persistent storage area that is seemlessly available across their devices. Now consider that other Cloud storage providers could supply their own "cloud file system drivers" and compete on the same platform, providing the same services. No separation, no segration into "MS" vs "non-MS", just competing at this level on performance, quality of service and cost. With this arrangement organisations that don't want to throw their own, privelidged data into the hands of others would be able to manage it on their own servers or private cloud and users would still get the overlaying applications and interface the same as before, just the end storage repository would be different.
However this pipe-dream would never happen at MS, as they only seem interested in doing something other than proving an Operating System, are only really interested in foisting their own marketing plan driven "solutions" on unwilling users and switch them all to a more expensive subscription plan and make it hard for them to switch solution providers.
"A f*#k 'em attitude" is pretty standard for most developers, as this forum thread would seem to obviate.
Not a stab at MicroSoft, but, I never would have thought that I would see the day when there is not enough programs, or apps, for Windows, and Apple has more than anyone can probably count.
Trust me - you still haven't seen that day, and you likely never will. There are at least hundreds of millions (if not billions) of programs that run on Windows.
What you are running into here is the Windows RT limitation. Bit of a different story. This is why the Surface Pro 2 is so intriguing. Seemingly, you could install nearly any program.
You could install a lot of applications on the Surface Pro 2...but why would you? The mouse is a third-class input method, the OS feels like dyslexic finger painting and the battery is still shit.
Put the money into getting your apps ported to open standards and run 'em as web apps on the many available platforms that don't suck*. Windows 7, ChromeOS, Android, iOS, Bada or Tizen...just to name a few!
*Bonus points; by making your apps browse-based, they still work in OSes that suck, like Windows 8 and Windows RT.
Browser based apps. Great in theory, but the fact even after all these years, widgets as (seemingly) innocuous as comment text editors on so many websites are so frequently whole heaps of fail, says something quite fundamental about the medium and why, comparatively speaking, native apps are doing so well.
No, actually, it says lots about how many shitty coders there are out there. I can name you hundreds of fantastically coded browser-based apps. I can also point you at millions of terribly coded native apps.
You seem willing to over look this massive quantity of awful native apps while using a comparatively similar quantity of awful browser apps as a cudgel. All you're doing is demonstrating your own bias and inability to make side-by-side comparisons in an objective manner.
Shitty developers are everywhere.
Browsers have a lot of limitations that would be perfectly good targets. Limitations that native apps (normally) don't have. (Though those are disappearing.) "There are bad apps for them" isn't one of them.
Browsers do, however, have one massive advantage over native apps: a single set of universal standards to code to. It was what Java was supposed to be, be never was. Sure, there are some differences and some accommodation for browser quirks required, but far less than Java...and way less than recompiling your native app with proprietary APIs.
Standards-based browser-apps are inclusive; they are open to almost everyone on all devices, all platforms. Native apps are exclusive: they target only that which the developer feels is important.
A browser based app is the developer saying "I am here to meet your needs; I will work to help your business grow by adapting my application to how you work." Native apps are the developer saying "I know better than you; if you want to use my software you'll do things exactly how I say, in the environment I say you'll do them in."
Of course, all of it - browser or native - relies on your developers not being terrible. But the fundementals of the medium are solid. Have been for some time.
and IOS and OSX
"No, actually, it says lots about how many shitty coders there are out there."
Problem is Trevor your explanation doesn't get to the heart of the problem. You can hardly put Facebook web app coders in the bad coder group, so there is a more profound issue you haven't addressed. Zuckerberg now openly refers to the Facebook web app strategy as a failure and they continue to beef up their native app support. Facebook would, of course, have had some of the best web-app coders available so why do you think they failed?
Web apps can work, but a successful implementation remains far more difficult than it should be. Currently its just about only Google that is managing it but even then there is a preference for native apps on mobile devices.
Users are used to the "native app" style of presentation; I.E. that it has it's own dedicated window, does not appear to be in a browser, etc. This is psychology and sophistry not technological requirement.
The difference between this and a true "native app", however, is that this development is still a standards-compliant development that is portable between systems. In fact, it typically calls the native system renderer and expects it "just work" with the relevant standards.
Psychologically, users are trained to think of "native apps" as "real apps". So you have to present them as such. Realistically, however, you code them using open standards and you use internetworked APIs to communicate information. The days of truly native apps that are coded to be platform specific are coming to a close.
Native app wrapper for a web app, that was precisely the strategy Facebook adopted and have moved steadily away from. Sure, as I understand it, they have adopted CSS such that it can be used to give layout directives that style *native* UI elements but in the main those elements are *not* laid out by an HTML rendering engine.
Well, if so, that's one example amongst literally thousands of others who choose standards-compliant means to reaching multiple platforms over native apps. Facebook has the resources to write multiple apps for multiple platforms and maintain umpteen separate code bases. Most don't.
Of course, if one is a True Believer in native apps (like you seem to be) then "multiple separate code bases" isn't a problem. You just tell your users to use whatever you dictate and believe that they'll meekly comply.
Frankly, I don't put developers on such a pedestal. They're disposable. They comply with my demands as a customer or they fuck the hell off. It isn't my job to alter my business model, OS selection or device selection to meet the desires of some jumped-up code monkey. It's the code monkey's job to write what I want for the platform I want if they want to get paid.
If you're Facebook you can do that with native apps (apparently) and fuck the inefficiencies of the process. Very - very - few others can afford that.
But...wait...what's this? Can it be?!?
Facebook's primary offering is a web application using standards after all! They merely have peripheral applications that may (or may not, depending on your view) provide a subjectively "better" experience on different form factors that are coded natively.
Even the enormous behemoth that you rip up as your example of native appness still seems to believe that providing it's wares primarily through a cross-platform, standards-compliant application delivery mechanism is critical to their business. Whodathunkit?
I'm not necessarily a true believer in native apps. My job has involved integrating HTML based OS's across a range of embedded devices (STB's) for the TV industry (NCI (aka Liberate), Microsoft WebTV). For years HTML has failed to provide an adequate user experience. Things are clearly a lot better now, but it still always lags native app performance. I'm being a little disingenuous because I have actually built up a nuanced opinion of precisely what the problem is and it relates, in part, to human psychology:
Although web apps have got to performance that 2 years ago would have been considered good, the state-of-the-art is always moving on and we human beings are amazingly sensitive to "touchy feely" aspects of the interface which, in terms of a feature list, appear inconsequential, but in terms of our feelings about apps, are far more important than tech-heads generally give them credit for. This in large part is why the iPhone had such an impact on the industry. It didn't excel on features, but on touchy-feely implementation that appeals to human nature. Web apps are in a perpetual state of getting closer in performance to the state of the art but, due to additional overhead, never actually catch-up (their rate of approach is ever reducing) and users are amazingly sensitive to touchy-feely differences. Look at the fact iOS has now integrated a highly responsive physics engine for moving standard (non game) UI elements around. The state of the art has moved on and web apps will take time to catch up.
Many tech heads get annoyed by this. Surely it's what something can be used to do rather than what it feels like as you do it that is important? Perhaps. But that doesn't change how users respond.
Another part though is plain simple quality issues. QA remains an issue across browsers with n-state configuration conditions and continual updates. The size of the additional QA overhead is getting on for being a multiplication of any small differences between each platform and there are always small, seemingly innocuous differences that impact negatively on user experience. So the problem appears to us like it should be small, but is in fact larger than we want it to be. This represents a sizeable drag on development.
Yet another part relates to state management and re-initialisation, which has a high overhead. Ask how do you manage inter-session state within different loadable web apps so the state remains instantly available (again this relates to user touchy-feely expectations of instant restart and instant responsiveness). The framework overhead is heavy and still, for a host of subtle reasons some of which are platform specific and much to do with differences in the run-time environment running interpreted code - overarching inter-app frameworks remain too fragile to be run for long without problems. This area is a PITA. Nothing beats a statically linked compiled library for responsiveness and restoration of prior state.
This last problem isn't an absolute, it is possible for it to be solved. Google for example seem to be doing a good job. But it hasn't been adequately solved on a broad enough basis as yet.
There are other factors as well, but I think these are the most significant impacting user adoption.
If you honestly think that the fundamental capabilities of the platform to deliver a smooth and fast experience aren't there for standards-based platforms then you haven't been paying attention for some time.
I will agree with you 100% if you are trying to limit yourself to the top-end applications requiring breaking performance. But I will disagree vehemently about the other 99.99999% of applications. Even on a moderns smartphone. For the overwhelming majority of apps, web-based is more than fast enough and has been for some time.
The fact that existing web developers don't know how to use the functionality enabling acceleration is more a function of shitty developers than "the fundamental capabilities of the platform."
AS to you "but it's *hard* to code for the differences in multiple browsers" whinge; Bullshit. I flat out don't buy it. It's far harder to recode native apps for every platform. The only way that native apps are easier than standards-based apps is if you are telling a goodly chunk of the user population to eat shit because you're lazy and you get to dictate which native platform they use. That's not actually solving the problem, that's just the developer being a dickwad.
And then you finish off by saying "well, except Google seem to have solved all of this." Which sort of makes your entire rant about "the fundamental capabilities of the platform" a steaming sack of horseshit, doesn't it?
Standards-based development in browsers is a fine platform for 99.9%+ of non-video-game applications out there. (There it's probably only about 80% ready.) Everything else has nothing to do with the fundamental capabilities of the platform and everything to do with whiny, arrogant developers who feel that the end user should bent to suit them instead of providing applications that suit the end user.
I have zero sympathy for any developer who just wants to be able to use the objective-C skills they've honed for years. They're the ones selling a product. I'll not buy it unless it's what I want.
Yes there is considerable rationale in the notion of write once run anywhere. Yes in theory it should prevail. But getting "sweary" about it isn't going to change the reality. The same arguments have been made for years, so I think the most interesting thing is why the utopia has not come to pass.
It's easy to simply write off the majority of developers with a coarse dismissive, but your assertion doesn't really stand up to scrutiny (so for example your comment about the developers of comment editors is just fatuous armchair speculation - Check the code on most editor widgets, which are open source, and you will find most are actually pretty good. The engineers who delivered TinyMCE for example, are expert, but have over the years encountered a long a tortuous list of cross browser compatibility issues and significant problems challenges have plagued the project through no fault of the engineers).
Indeed all the mainstream apps you would expect, on your argument, to be highly suitable candidates for web-apps are not (this after all is an article referring to the surface and iPad):
Twitter - native.
Facebook - native.
BBC iPlayer - native.
Google Maps - used to be browser frame based, but not now native code. Moreover you can visit the web version in a browser and see the very marked difference.
Google Mail - native.
BBC Weather app - native.
Indeed on that last one, a pretty simple app, hardly demanding high performance. Yet here is a (very typical) paragraph on its' development from the BBC website:
"Native or hybrid HTML5?
We wanted to provide the best user experience we could for mobile devices. Based on our research, 80% of respondents said a simple uncluttered forecast was most important and this focused our design approach, which my colleague Stephen will discuss in more detail soon.
Through prototyping and user feedback sessions we clarified our designs and also investigated the use of HTML5 hybrid apps along with a purely native app. Deciding our approach was not easy as both have advantages.
However, based on feedback, speed and simplicity were highlighted as particularly important on the move and to present forecast data quickly we chose to develop native code. We could take full advantage of location and data management whilst interactions, transitions and animations were far easier to implement."
This isn't just one isolated case. Its pretty much the same conclusion reached by every important web based company out there. Now if you are going to respond please do so nicely.
You are arguing a point I never made and trying to change the discussion past your original assertion, which it the point I was arguing to begin with.
You asserted that the fundamental platform of standards-based browser-delivered apps is inadequate. I said it is not.
You then went on a tangent about how "so many developers are producing native apps for mobile devices."
I said "but standards-based apps are still being developed that are just as good as those native apps and continue to be supported."
I am not talking about why developers choose to be egocentric assholes that place their needs above those of their customers. I merely said that standards-based development was possible, is the superior choice for the end users and that companies should avoid lock-in by moving their applications to said standards-based platforms.
It is possible to do. It is being done even by the very same companies you hold up as producing native mobile clients and ultimately helps companies escape lockin.
Your arguments have fucking nothing to do with "the fundamental suitability of the platform".
There are many reasons that people choose one design choice over another that have nothing to do with the platform capability. As I stated before, it's a lot more about the psychology of the matter than anything else. (And the lock-in political power games played by the platform owners specifically designed to prevent companies from building cross platform apps.)
Your arguments made a claim and backed it up with bloody nothing that was related to it.
Oh, and as for "be nice when I talk to you," here's a giggle: no.
You have no more right to dictate my behavior in a forum than you do dictating my purchasing decisions to suit your personal agenda. My irritating and flagranty douchily trolly behavior is purposeful and chosen specifically to illustrate my point. I'm the consumer. I get to do what I want. You're the vendor. Do what I say or I go elsewhere. I have no reason to listen to you; on the forum, as a vendor or anywhere else. You do not compel or have a reason to expect my obedience. If you want my compliance you fucking earn it.
In fact, I have a better idea: why don't you stop wasting time on internet forums and go put some effort into actually developing things that are good for your customers and meet their needs without imposing externalities upon them. (In this case, in the form of locking them into closed platforms where the costs constantly ratchet upwards.)
I'm exactly as nice as the situation warrants. Address your actual assertion - rather than arguing past it with irrelevant dogma - and we'll be fine. If you want to argue the politics of platform selection, then start a new thread. Your assertion was about the fundamental capability. That's to do with tech, and you've provided zero evidence that the technology behind standards-based application development is lacking.
companies like native apps because you can make them do plenty of things under the bonnet that you cannot inside a browser. Native apps can happily ask users to sign away their privacy rights and raid your contacts, habits, location etc. They also have habits of waking your devices when they feel like it. At least a browser app is controllable.
Take a point with a facebook app. Try that will all the notification bits turned off then try uninstalling it and using the browser version. At least with the android version my battery life SHOT up (at least 25% over a typical day).
There is no single universal standard by which to code apps in the true sense of the word "universal". But it is fair to say that web apps are usable on a wider range of devices than pretty much any other means. That very issue comes with a huge range of limitations and workarounds in the development process, which adds cost. Of course if your primary goal in developing that app is reaching the widest possible audience, then developing within those limitations may be the lesser of all evils. Its still an exclusive process, and web apps are not a panacea.
Indeed you focus on *your* desires. However, it is rarely so simple unless you are only ever responsible for purchasing a limited selection of apps for your own use. Most often than not in my experience, each and every company has its own set of requirements, that are often only served by a very limited selection of app development providers, so your available choices are limited, sometimes to a single provider.
User preferences can often play an exaggerated and disproportionate part of the selection process. As the gentleman made in one of his posts, responsiveness is a highly regarded factor. Maybe not for you personally, but again, in my experience, lag is unacceptable to most users unless it is a very niche app and they have no choice. Web apps, including native apps that rely on a web or 'internet' based backends often have a noticeable lag involved, simply due to factors that are outside the control of developers and users. I specifically single out the internet, as most of us have very little control or choice over our transit across the public internet as opposed to a corporate LAN where we can often, though not always, have a direct impact upon performance. Native interfaces to web apps are yet another compromise solution, and done well can provide native interface speed, and ameliorate the effects of the public internet on response times on a users experience. But then again, we move away from the nearest to universal platform.
Quote "AS to you "but it's *hard* to code for the differences in multiple browsers" whinge; Bullshit. I flat out don't buy it. It's far harder to recode native apps for every platform." May be true, but displays I believe a misplaced belief that an app needs to be available on every platform. Most don't, doing so just adds an unnecessary cost. You also underline the point that there is NO truly universal way of coding an app to reach the largest number of devices without incurring a certain amount of overhead and dealing with a number of limitations. You may want to consider that cost, man hours available and other factors decide whether it is needed for an app to be web based such as the ever moving goalposts of the development platform/language/library/paradigm which seems to shift faster online than off.
And you can never get around the fact that internet access is required for a web app to work at all (though not for apps delivered into a web browser that may operate on local data rather than remote and have some method of local persistance). You may be happy in your cosy suburbanite office with both fiber and wireless internet, and this may come as a shock, but not every app deployment has internet access. Larger corporates have departments that may "request" internet access and be denied for reasons including security and simple politics (one such springs to mind, an oil company, where the client department was denied internet access mainly due to the application in question coming embedded within the industrial machinery rather than being supplied by them which in their eyes meant they wanted nothing to do with it - end result being the department simply getting their own internet connection without any support from their IT department). Or the widely roving auditor, who travels to corners of the globe that have no internet at all, shocking as that may be to some.
So I guess what I am trying to convey, in a terribly long winded fashion for which I apologise, is, there is no one size fits all development route. If your only criteria is it must be a web app, you are doing yourself and your company/clients/whatever a disservice with a myopic view of requirements and with no consideration to factors such as cost.
"I get to do what I want. You're the vendor. Do what I say or I go elsewhere." is a short sighted, arrogant and needlessly combative viewpoint. I guess it works if you only buy generic apps and have no relationship with the developer other than parting with some cash. If that is the case, why the vitriol directed at developers?
Then you assert that native apps lock users in to an upwardly spiralling cost of ownership. What? Really? Maybe in your own experience this has happened to you. Pure conjecture here, but that may be due to a lack of groundwork on your part than any effort of the developer. The same thing could happen no matter the delivery means.
I think you already made the point, a bad developer is a bad developer. Well, an app is an app, and a platform is a platform. and a bad purchasing decision....
Hey, I got through that without once calling you a dick! :-)
Biting the hand that feeds IT © 1998–2017