QUOTE: But as a strategy, you get the Web app out first since it is a universal client, then you roll out "native" apps (including desktops if you feel the need) as time and budget and resources permit. It may not be ideal... but it sure beats building one "native" client and hoping you picked the right one.
That works sometimes, but not always. Each situation needs to be evaluated on its own terms. For instance, an application that will be especially atrocious through a browser may actually impose such a drag on user uptake that you won't capture any user base to speak of at all with the web version of the application, and as a result your business model may not survive long enough to get around to building the "native" implementation(s). Meanwhile, an application that gains popularity rapidly on one platform can easily fund porting to other platforms. Even in corporate business climates, where there may be money to blow on sustaining the project despite lackluster business performance throughout the web application deployment, the decision makers might cut the project based on a failure of the concept itself even though it's not the concept that failed, but the specific implementation.
In short, it is often the case that a better application is far more important than a more widely usable application, at least at first. This is not always the case, which is why it pays to make an evaluation of your specific case and come to an informed decision on how to proceed.
QUOTE: BlackBerry isn't dead by any means, and they could enjoy a resurgence as well.
The business decisions at RIM all point to death. For instance, RIM is retreating to the "high ground" -- that is, to serving enterprise and high-end customers, ignoring the more numerous (but more frugal) lower-tier market. Unfortunately, that's an almost invariably losing strategy in technological markets where the basic product or service being offered is not by nature confined to that "high ground", because such niches are typically overtaken by whoever controls the far more diverse and distributed segments of the market, over time. In circumstances like that, the "high ground" is where you go to die, because company executives can achieve short-term success in the numbers, get big bonuses, then leave for greener pastures before the guillotine blade falls on the company.
QUOTE: So for folks who need to get their stuff on as many devices as possible (and that's an awful lot of devs), the best and maybe only strategy that fits their time and resource limitations is Web, regardless of what's "better" or "right".
There's probably at least half a dozen development toolsets that (to varying degrees of capability) offer the ability to build an application once and deploy across multiple platforms, typically including the major mobile platforms and, often enough, "desktop" systems as well. Their deployment packaging mechanisms provide much more responsive "native" applications than the creeping slowness of web applications on those platforms, with richer UIs that feel more integrated with the platform and are better designed for use on each supported device. One of the big problems with web applications in the browser, after all, is the fact that the interface generally sucks horribly in comparison with "native" applications.
In fact, I only go to the browser on my smartphone when I absolutely must (e.g. when what I want is actually a website), because the browser (any browser) is an awful interface for a captive interface application (as opposed to a basic knowledge source -- using the browser to just offer interconnected content). I guess the upshot is that "native" applications are for "doing things", and the browser is more for "reading things". Using the browser for "doing things" just results in a miserable experience, and that's regardless of hardware platform (but exacerbated by a small touchscreen interface).
QUOTE: Using Web on a freebie Android phone is probably quite painful.
I think hardware is the big problem here, and not the OS. I don't use a "freebie Android phone"; the only real problem with mine, in terms of what we've been discussing, is that it's old (and that the state of the art of smartphone OSes is still pretty damned primitive, anyway).
QUOTE: Also, speaking of "native", with Windows 8 clearly going to replace WP7 on the next version of Windows Phone, I am curious if they will bring the C++ compatibility to it that they have in Windows 8. I am also curious if the C++ on Windows 8 runs under the .NET CLR or if it is truly native.
If it's running C++ on the CLR, the only difference between that and C# will be the relative difficulty of writing clean code that does exactly what you want in C++.
