>>>I'm not going to write native iOS apps, so if a client wants that he can go elsewhere.
>
>OK. Hank's solution that you criticize doesn't involve shutting out 29% of *the* growing market.
>
>>>We're building asp.net apps with javascript mapping components (ESRI) and jquery to spruce up the client side. Works fine on pretty much any current browser.
>
>Browser is not a natural decision for business apps on a mobile device- which is why banks, online travel agents, ebay and others are all offering native apps rather than pushing their traditional web interface. It was fine for desktops that usually used a network under the customer's direct control, but mobile devices are distributed by telephony providers who encourage customers to use the provider's data network and once hooked into that, it's hard to go back. Outages are to be expected and are tolerable- unless you're using a browser app that may crash or lose work if an inconvenient outage strikes at a bad moment. Customers won't put up with it, especially if somebody else is doing it properly.
>
>>>Try it in VFP.
>
>That's not the proposal. Hank is contemplating re-using VFP code in native apps to run on any platform. The comfortable pejoratives to justify a move away from VFP aren't useful rebuttals if he can do that and you cannot.

Prove it.

eTechnologia was the second coming a couple of years ago.