Hacker News Reader

In my experience, implementing a sufficiently complex app in PhoneGap targeting Android, Windows Phone, iPhone and iPad is absolutely more work with lower quality result than doing native versions of each app through Xamarin.

HTML apps have a tremendous hurdle to overcome. Customer expectations are different between something opened in a web browser and something downloaded from the app store. Apps that are amazing as web pages can be awful as apps. The amount of effort required to get a web application to perform in a way that matches user expectations for native UI cues, animations, quality and responsiveness across platforms is enormous and incredibly more difficult than your standard web app.

Of course, if you target just one platform, things get a lot better, but at that point, why not just use the native tooling?

This has been my experience, having tried both approaches over the course of several years, across team sizes ranging between one and ten developers.

Ah, I see. All that matters for me is that it works and it looks good. I constantly modify my designs so that they are as easy as possible implement, without losing any usability. There are no fancy transitions, no fancy widgets, just a handful of animations where they are necessary for comprehensibility. My focus as a designer is on what users are able to do with my app. All my design effort is in service to that.

I don't have the resources to care about nativeness. I think you're definitely right that if you want something that behaves like a native app you're much better off just building a native app. I suspect for most people that level of nativity doesn't materially affect their business though.

One thing to keep in mind is that targeting a browser is not the same as targeting an API level. API levels guarantee consistent behaviors across different targets, but if you use the WebView, you'll encounter different behaviors across the same version of Android across different hardware vendors. Debugging PhoneGap apps isn't exactly painless, either.

It's a bit of magic to see a game work reliably across Android devices dating back to Froyo with excellent performance. Running your web app on the same hardware is not quite such a delight.

It's also interesting to note the bigger players that have recently made the transition from HTML5 to native apps. That said, the good enough bar may be good enough for many people.

Netflix has been using HTML5 for their mobile apps for years and the vast majority of people you will ask about it, developers or otherwise, probably don't realize it. It can be done, and is being done by many apps out there. And no, it does not take as much effort as writing N native apps for N platforms.

YMMV.

There's no argument that it can or can't be done, only that the time and cost to implement is equal to or greater than implementing N native apps. Wouldn't mind a contradictory citation for apps that have taken the plunge and found it to be worthwhile, and that the write-once-run-anywhere promise was fulfilled to their satisfaction.

You'll notice that the Windows Phone Netflix app certainly isn't using the same approach as the iOS and Android counterparts, and the iOS/Android versions use a non-trivial amount of native UI components for their respective platforms.

> Sorry, are you saying that it's the effort for you to build...

native development takes advantage of sdks you wont find on your html plateform ( which is really an hybrid app, since you depend on phonegap container,so it's still native somehow, you just abstracted it away ,so it's not an html app ). so you are just building a packaged website.

> I just spent six months building a quite complex single page web app

define complex.

> while I can easily imagine a single person building a web app that could run well in PhoneGap

Except your app wont have a native feel , wont follow the plateform guidelines regarding ux since you are not using native widgets and will feel like a second rate ux on the plateform yo u are developing on.

Let's not even talk about performances. Is Your app multithreaded ? can it run on the background and to some stuffs while the user is on another one ? can it display anything on the user homescreen ? see , unless you go native , your capabilities are limited to the least common denominator instead of embracing the platerform , maybe that's why you spent 6 month on building it.

Background geolocation and background fetch are possible with PhoneGap.

https://github.com/christocracy/cordova-plugin-background-ge...

https://github.com/christocracy/cordova-plugin-background-fe...

Of course since phonegap is just an hybrid app container. Someone had to write that java and objective-c code for you.

Why must it have been "someone" else who wrote it for me? I wrote it.

> Sorry, are you saying that it's the effort for you to build a native Android app, a native iOS app, a native Windows Phone app, and a mobile web app combined add up to more than the effort it takes to make a single web app and get it to run well on Phonegap on multiple platforms?

Actually, depending on the level of quality you need, yes. A very basic form based app can be better served by a phone gap app, and be of better general quality.

But the case where you won't be helped by a cross platform solution are numerous. It is obvious if you heavily need performance or rely on a lot of native API where you want very fine grained control (you might even not want feature parity between platforms, if some platform give better tools than an others), or use native third party libraries.

But even in cases where you require near pixel perfect layouts for a wide range of devices, or have unusual set of rules to position or move your elements, handle device rotation in non standard ways. In these cases you might be better off doing native apps as many times as you need to. It seems extremely wasteful, but dealing with hacks on top of hacks in a single HTML+CSS+js codebase relying on an extra abstraction layer enclosing wildly different platforms is a hell in itself.

edit: spelling