How to get that native iOS feel with PhoneGap | Hacker News Reader

How to get that native iOS feel with PhoneGap

mikedellanoce.com

155 pointsmdellanoce47 comments

Why do people hate on PhoneGap so much? Specifically, I mean when people complain that the UI of the apps produced with PhoneGap don't "feel" right. PhoneGap sacrifices the quality of the UI for benefits in other areas (a boost to development speed, and making it easier for a novice developer to get started).

The argument against PhoneGap seems to be either that there isn't a place at all for such a technique, or that people think the benefits don't outweigh the drawbacks. Another option is that people dislike the developer accessibility aspect out of pure snobbery.

However, I rarely hear people making these arguments. I just hear (not necessarily in this thread, but in previous ones) "blah blah it sucks blah blah why not write native code blah blah".

> PhoneGap sacrifices the quality of the UI for benefits in other areas

You said it yourself. PhoneGap is an easy way to get a sub-par user experience and that is what matters the most, not development speed.

The UX is the absolute most important thing. Anything that sacrifices the user experience just to make it easier to develop is a bad tool. It's a tool for the lazy.

Well, maybe, but this is also a great tool for the enterprise that wants a consistent look and feel across their supported range of devices with one code base.

Probably the biggest problem with PG is that it's frequently used with JQM, which in my opinion (after over a year of development with this combo) is slow. Mostly because it's browser compatibly goal is too broad.

I'd really like to see a mobile optimized version of twitter bootstrap for PG.

Great point. I started out with JQM early on and had to drop it. I ended up just pulling some of the touch event handling code from JQM since that was the only part still being used.

General statements are dangerous. UX is often but not always the most important part of a project. For projects where speed of development or cross platform support trump UX, PhoneGap can be an awesome tool.

I've seen a pretty complex app which had been implemented a both a native iOS app, and as a PhoneGap app. The PhoneGap version launched faster and was smoother.

I suppose the lesson of the story is that the developers matter more than a the framework used.

in my experience more often than not the only people who can tell a well-done app is phonegap/cordova rather than native are nit-picky, self-righteous developers. if it works as advertised, users are generally happy and cannot tell the difference... and, unless your app is built specifically for developers, that's all that really matters.

No, they cannot say "this is not native, must be PhoneGap". They don't even know what "native" and "PhoneGap/Cordova" is. They just say "it's does not feel snappy/right" and that's it.

Are you stating that native apps are always snappy/right? Because if you are, I have a list of App Store apps for you to look at.

That is hardly a universal truth. I'd take ugly code that ships on time over beautiful code that doesn't.

Ok Mark Zuckerberg. Shipped code does not always beat unshipped code if the shipped code is shitty. In App Store contexts, badly shipped code can kill your app before it gains any traction leaving future updates moot. Anytime you deliver less than a beautiful UX you are doing a disservice to the user. The product can be simple and MVPish, but you should never ship shitty code. Zuckerberg doesn't know what he's talking about.

I've noticed this, too. The arguments are more recently drawing around how the UX harms users...but wouldn't this be true of any HTML5 app? Does PhoneGap have some voodoo magic abilities to ruin the UX beyond what any HTML5 app is capable of? Otherwise, are you saying HTML5 apps are bad? PhoneGap is a wrapper that provides native-API to HTML5 apps. It doesn't automatically add horrible UI or whatever people think it does.

Crap PhoneGap apps and crap native apps are no different from each other.

Yeah, I deal with this on (almost) a daily basis. My response is, "I'm not LOOKING to emulate the iPhone interface. I design my own buttons and widgets" There is nothing that does a great job of emulating the iPhone interface. And even if you DO get close, it looks foreign on an Android device. As far as performance, all these kids that follow a few Obj-C tutorials and build a couple of forms in Xcode make me crack up. You're NOT gaining performance, you're probably leaking memory like crazy because you don't understand C very well. I agree with the sentiment of the snobbery. Hey, if you write Java and Obj-C at the speed that I can code a web app, great. But don't complain when mine looks nicer than yours... and the performance isn't THAT much different.

So much wasted effort to achieve something which a) doesn't really work well b) comes for free if you just go native. And your Android users will of course be super happy to find a bad iOS interface which is just slow. And once you are done imitating the iOS interface, the real work only begins ;)

Trust me, these tips are still useful.

My team is working with a company whose site is just shy of the top 100 in the US by traffic. Big company, been around for almost 100 years. What surprised us was that 50% of their traffic comes from mobile browsers. They even already have mobile apps for both iOS and Android, and still that much traffic goes to their mobile site. Also of interest: iPad users get the normal site. So 50% of their traffic is from phones.

What do you serve to those people? Bug them to get the app anyway? On large sites involving several different divisions of a company, the native app probably only has 10% of the functionality. And serving the full "desktop" web experience might not be possible or desirable.

While I think it can be a huge mistake to try to completely mimic a native app on the web, you can make the experience much better by at least adopting some mobile UI patterns. And in those cases, the tips on this list will save you. (Our work with this company involved adding stuff to both their "desktop" and mobile sites. We didn't use PhoneGap, but did use several of the tricks on this list.)

As an aside, almost all of these tips have nothing to do with PhoneGap. They all apply just as well to any mobile site that's going to be using transitions to look like an app.

It won't ever really 'feel' like a native app but it might look like one if you try real hard. My own experience and Facebook's too is that you just won't get the performance and you'll also be dealing with quirky CSS/HTML rendering.

Edit: That's not to say that you can't make an app work, but you shouldn't try to make a typical app using mobile framework that tries to mimic a native app such as jquerymobile or others. If using a non-standard UI it can probably work where the user isn't expecting it to work and feel like a UITableView and every other basic thing in iOS.

I agree -- it is exceptionally difficult to create the look and feel just right in HTML5, CSS3, and JS. I swear that there's an "uncanny valley" for look and feel. To me it is better to bring over some of the "ios"-isms without duplicating the UI (and failing to get 100% right).

If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."

http://ycombinator.com/newsguidelines.html

Sorry about that. I will be sure to remember this.

Why are people still using phone gap? What's the point? Might as well just build a web app. PhoneGap is the Dreamweaver of mobile.

Isn't PhoneGap just the interpreter for an HTML5 web app - the wrapper to get it on the phone as an ipa?

Unless it's changed a lot since 1.0 I don't believe it's some kind of WYSIWIG iPhone maker that creates bloated, terrible, code.

It is called Apache Cordova now, and it is a set of implementations (one for each platform) providing JS hooks into native APIs, so they can be called from JS in a web view, so your web app runs in a native app container.

Phone gap is now a set of technical/busisness services for managing Cordova projects, such as Build deployable packages for all platforms via a web service

PhoneGap is getting better with every release, and it isn't too hard to make a nice, functional app. The promise of cross-platform holds only for so long - until either a plugin doesn't exist for the platform or a platform-specific glitch gets in the way, but overall it is a fun and rewarding thing to work with.

Clients want apps in stores. It's much easier to promote than mobile web apps. And even though for a nicely looking, nicely working cross platform phonegap app you will be paying a lot of money (the tweaking takes a lot of time between different phones/pads), it is still cheaper and faster than going native.

We advise native for productivity apps and such; day to day use apps should be fast and snappy, while promotional apps / marketing apps should look pretty.

it is still cheaper and faster than going native.

It sounds like you make apps for people. Assuming you have someone on staff who knows iOS and someone who knows Android is it still faster to do it in PhoneGap? We attempted a phonegap app which ended up failing because of performance reasons. We rewrote the app in native iOS and it didn't take nearly as long as the original phonegap did with the constant tweaking in an attempt to get it to look and perform acceptably.

It depends definitely on the app; we have been in the 2 camps. The problem is that often we are also asked to make the mobile web site and then you have 3 very similar things in Phonegap while native you need to write 3 different things. I do agree though that for a lot of apps native is faster to write if you target one platform.

And the Phonegap experience isn't really good unless you spend a huge amount of time. Webview is just not very good; you need something which is native but crossplatform to replace it; everything we tried so far (appmobi, appcelerator, rhomobile) actually was worse than Phonegap/jqm to get right. But we keep at it as we know what our clients want.

Often the Phonegap version is treated like a prototype; then the client saw it and knows what they want; after that they have it rewritten to native on the platform which makes them the most/gets the most attention (etc). Which is almost always iOS by the way.

My current client is using PhoneGap to enable publishing to numerous device types without the need to hire developers for each platform. Particularly important due to their customers' global spread; supporting multiple platforms is a decided competitive advantage and finding devs is tough these days.

Build web app, package as smartphone app with phoneGap. Makes users happy.. right?

Max Ogden also did a great write up on Web View optimizations.

http://maxogden.com/fast-webview-applications

One thing I didn't notice, but is important in stoping overscroll is to se the UIWebViewBounce property in Cordova.plist to NO. This ensures you don't have to worry about things like ScrollFix which almost-but-not-quite-solves the same issue. Why Cordova defaults this to YES is beyond me.

Nothing kills the illusion of an iPhone app feeling native faster than getting rid of overflow bouncing in a scrollable view. I understand there are performance benefits, but it feels so wrong on iOS.

Great point, I wish I had remembered to add that!

Are there any working examples using these tricks so we can test the difference? (The author's product request an invite to use)

Unfortunately, the app is still in review with Apple, so not at the moment. I also didn't realize this post would do so well with HN. I will work on a more in-depth follow-up with some working examples. Thanks so much for reading!

Looking forward to it, I already feel like you saved me 2 weeks in testing.

I recommend checking out the Photoswipe source. It uses many of these techniques to create a swipe-based image gallery optimized for iOS and Android.

https://github.com/codecomputerlove/PhotoSwipe

Here's a simple HTML5/Photoswipe/Phonegap app I wrote that you could experiment with:

https://github.com/stungeye/HTML5-Tumblr-Mobile-App

Explained here: http://mobilehtml5.stungeye.com

They make a /huge/ difference, especially if you stay within the tile size.

In fact, using translate3d and CSS animation is pretty much the only way to get smooth animation - if you do it with pure JS (setting left/top styles), things get very herky-jerky.

I can speak from experience that using the 3d transform trick can make a real difference.

We use them to emulate the Facebook / Path / Twitter swipe to move the main panel, performance isn't 100% of native - but it's pretty close.

Great tips. For anyone who cares, here's a way to get around one of the fixed layout bugs with #6 (-webkit-overflow-scrolling: touch): http://blog.joelambert.co.uk/2011/10/14/a-fix-for-ios5-overf...

You know a great way to get the native iOS look/feel? Use Kendo Mobile. It gives you native UI without all the bugginess of other frameworks like JQuery Mobile.

Out of the box, using Kendo on iOS gives you a pretty native feeling app, esp. for things like form and image viewing type apps.

Just know going in that PhoneGap has limitations and it is not going to be 100% perfect, but it's outstanding for hitting the first 80% to prove out an idea and get it on the app store.

For an example of an app I wrote using Kendo Mobile, check out ReMeme on the app store. http://itunes.apple.com/us/app/rememe/id536802283?mt=8

How much does optimizing for iOS do anything bad for the app on, say, Android?

I can't really say, because we haven't done much testing on Android yet. My understanding is that Android's WebView uses a webkit rendering engine, but generally has poorer performance than the iOS UIWebView. So my guess is optimizing for iOS won't necessarily hurt anything for Android, but Android won't have quite as good of an experience. Hopefully this will get better with time... the UIWebView performance increase we saw from iOS 4 to iOS 5 is encouraging.

We use PhoneGap and thought it would fit well for us since our app is a touch based board game. We don't really use native widgets. It's all customized graphics for the game board and menu screen.

I probably wouldn't use PhoneGap for an actual application that needed the native widgets look and feel, but for something like we are aiming for, I think it fits perfectly. We wanted to target as many platforms as possible.

Awesome tips. Congratulations for the awesome and informative article. :)

Hiding elements by applying offscreen translation - how's the support on non-iOS devices?

Having just worked on a mobile site using this technique: it's fine. The one issue we found is that some older Android browsers support 2D translation but not 3D. We ended up using translate(x, 0) for the actual movement, but kept translate3d(0, 0, 0) around for the performance boost.

Reply on news.ycombinator.com