This is native vs. java all over again. Apps that use UIKit look like iPhone apps.
Phonegap apps look and feel like phonegap, but 'run everywhere'.
I think Phonegap is a suitable replacement for Android & Blackberry where cheap > good.
On iOS I'm not sure how receptive the market would be... I think we all know how horrible Java apps feel on OS X, because it uses a slightly different UI paradigm (one menu bar).
I do think that you can do quality work on Phonegap, however, it's never going to 'feel' native iOS for a few years until the CPU performance improves on iPhone. That said there are certainly places when writing 'native' code that you throw in a UIWebView because getting iOS to do what you want is a major PITA.
Except the "native" look and feel is falling out of style fast anyway. The iOS app store is a fashion show and nothing screams amateur now like stock widgets.
Can you please provide examples? After uninstalling Facebook, every single third-party app on my phone is built of stock widgets. Some skin them, but that retains both behavior and dimensions. I would even say that the "snob masterclass" of iOS apps is all about using stock widgets in style, like Instapaper and Carcassonne do it. Or only in select places, like Paper, but still seamlessly.
The only example of well-received custom widgets on my iPad is eBay.
I'm looking through the top free iPhone apps in Germany and I can't see a clear trend. Also, I'm not sure how to prove or disprove my point - because being a top app is orthogonal to looking like an amateur effort. WhatsApp has long been #1 here, and while I welcome its stock navigation UI for usability reasons, I think their tacked-on timestamps are as "amateur" as their name.
Some of the UIs are badly imitating UIKit, like Zoosk. They still often replicate the navigation concepts, UIKit shadows (skeuomorphism), widget sizes … - I don't think the stock look & feel is dead yet.
By "amateur" I mean that I think the typical app consumer is getting pretty good at spotting stock UI and tends to equate that with a slapdash app, justified or not.
I think you're misunderstanding. Of your examples, all of them use stock widgets, except for the last two.
In the last two they replaced stock controls with custom ones, even where they didn't have to, and that supports your hypothesis.
But all of the others, however, are using stock controls for all the controls where there is a stock control, and only using custom controls where there is no stock control.
The ability to customize the stock controls has increased a fair bit and gotten more popular as its gotten easier. But these developers (at least, I can't speak for the whole appstore) are using the standard controls.
What is true is that they aren't using the blue-pinstripe look of the original iPhone anymore.
The reason this distinction is important is that its a whole lot harder to do a custom control (like a turntable) than it is to use a standard control, and its also very easy to take that standard control and make it just the right shade of grey, or make it look like wood, etc.
Thus customizing how these standard controls look has gone up dramatically, yes.
What is true is that they aren't using the blue-pinstripe look of the original iPhone anymore.
That's what I mean and that's why I don't think people should waste so much time trying to emulate that look down to the last pixel in Phonegap apps. Users don't care anyway as long as your app looks good.
Oh, I guess Flipboard is also mostly customized. There's probably a stronger incentive to come up with your own stuff on a tablet where UIKit is not as helpful for the overall navigation. For example, the eBay phone app still looks like Apple could've built it.
I totally agree with this example. Both eBay for iPad and Facebook use that concept too, so to most users it will probably feel like a stock widget already. I hope it will eventually become one :)
It's not about the widgets - it's about how smooth the app works, and what it does. The fancy widget or two like accents (necessary like decor) can take a basic stock widget pile and allow the user to focus on what they're using the app for...
And thank god for that. Android started out ugly, but I don't hear many people asserting that iOS apps are de facto better than Holo-themed apps for Android anymore. Frankly, I feel like it's 2003 when I pick up an iPhone. Plastic and faux-wood. Comforting.
Your point being that Cyberduck is not 'native', but people still like it because it gets the job done? Sorry, I'm not familiar with cyberduck but that's what I gleaned from looking at that site.
Cyberduck is a Java app. It looks decent and follows the OS X paradigm of a single menu bar at the top of the screen.
My point is it's possible to do a functional and native-looking app with non-native tools. But of course, not all tools are equal. I was just answering to Java on OS X.
Wow. I use cyberduck all the time, this has to be the first app that's java that I didn't know was written in java either through generally sluggishness or horrid UI.
>On iOS I'm not sure how receptive the market would be
I'm not convinced that normal people care that much about design. If the app solves a pain point for them, they could care less about how native it feels.
Do _not_ assume this will always work. If you bind to the tap events and change content positions you _will_ end up firing the click on an unintended element. Remember the click almost always trails the tap (save for on the Windows Phone platform). He mentions that jQuery Mobile does some "magic" to deal with the click and tap. This is the vmouse module and you can use this independent of the library for just this purpose.
"JQuery is enormous and has no business being on a phone"
It's a phonegap application, the assets can be packaged with the application itself which means that in many cases this doesn't apply.
"Massive Footprint. 248k wowsers"
I'm still confused why this matters if you are packaging your assets with the phonegap build which I would expect most people do.
He's very right. Phonegap is no trumpcard, but I'd appreciate a more thorough treatment of the "best practices" he espouses.
That article is on a desktop (well, laptop) processor. The timings on mobile are obviously higher. JS parse & load is mostly ignored on the desktop but I know I've read at least one article where a team was pulling down their JS as plain text and eval()ing it later to get their load times down.
I don't recall when this kind soul made this document public, but I believe it was in a similar discussion on hacker news and I've had it bookmarked since.
I have also done my own tests, and the iOS numbers are similar (depending on the device of course).
People sometimes have slow connections, particularly BB users who feel no need upgrade to the latest connection speed. The app has to be completely downloaded before it runs, unless you put external references in your PhoneGap packaged HTML, I guess, but then it would only run online.
Additionally mobile browsers are often slow to execute, so loading a lot of JS can bog down your app. For a while there was a big stink about iOS only using their best JS engine in Safari and not web controls, not sure if that every got solved, but laggy HTML based apps is a big problem.
A few issues with this article. First, if jQuery is censored in the app bundle, it could be 500k and it wouldn't matter. 500k isn't big for an app.
Second, ontouchstart is a tricky game. It's wonderfully fast, but breaks scrolling completely if you start scrolling from an ontouchstart-bound element.
Basically, it's a shortcut around learning Objective-C. You get a lot of quick wins, but the end product isn't quite as good - except if you're doing something unusual, like one-page apps with no scrolling. I find it's good for prototyping.
The problem is absolutely not about initial download, but rather about runtime performance. Parsing and executing 500k of JavaScript on mobile is crazy slow, and it blocks the whole app while this is happening. You can mitigate this by loading the JS on demand, but you still need to pay the cost at some point. For the time being, the best approach is to only include what JavaScript you absolutely need.
I just want to echo want apike is saying. There are several comments here incorrectly stating that this much javascript doesn't matter. It seems pretty obvious that those commenters have no experience developing mobile web apps. Loading jquery is a huge hit, taking anywhere from .5s to 1.5s to initialize, depending on the device and what else is eating up resources at load time.
That's not a big footprint for an app, especially compared with image assets, app code and CSS bundled alongside.
It also means being able to add more functionality at will without having to rebundle, or worse, work on basic functionality helpers. Just seems like wasted time for such a small improvement. These devices were built to have application code on them.
Zepto is 24k. Does that extra 70k really make that big of a difference? A single retina resolution png is going to be bigger than that. I think there are other reasons to consider a library that's tailored for mobile webkit but size doesn't seem like a dealbreaker.
The ontouchstart issue can be avoided by using the ontouchmove/end to check of the user is scrolling. Infact zepto.js has a custom event called "tap" which does exactly that.
I've built a few apps in Objective-C and in HTML5 and on both platforms you've got to be careful about performance. I don't think it's a HTML specific problem:
I remember building my first Objective-C application and having it perform terribly. I had to learn to reuse table cells and not to redraw an entire UIView.
Each platform has its quirks and if you're willing to learn about them you can make terrible and good apps in either.
You certainly cannot approach HTML5 apps as a standard chrome browser. That's just unrealistic.
This is a really good example of the kind of app that users want now. A completely custom UI with a distinct style is what it takes to get attention. For better or worse the stock UI is out and it's actually easier in some ways to build this kind of UI in HTML/CSS.
I used PhoneGap to develop my app (http://chaincalapp.com) and I've been very pleased with the result. It's not so much the cross-platform targeting that interests me, but the ability to use the tools I already know and enjoy (e.g. Backbone.js). Furthermore, the ability to use a language designed for presentation only (CSS3) is a great improvement in terms of separation of concerns. The author is also spot on about the value of not having to spend time studying native APIs in depth.
He's also absolutely right about results equalling effort. I've seen plenty of terrible mobile apps developed in JS, and I also have yet to see a jQuery Mobile app that feels right to me. I think some of this stems from attempting to recreate stock native UI elements and failing halfway. I wasn't interested in doing so with ChainCal, so I avoided that issue altogether.
As for performance, JS execution has never really been a bottleneck -- it's DOM manipulation. My advice would concur with the author's: use CSS transitions for everything. If you put in the time with benchmarking small operations and you approach things in different ways to squeeze out performance, your app can feel native. Trial and error led me to plenty of performance discoveries. As an example, using translate3d to move an element offscreen is tremendously faster than setting its display to 'none'.
Finally, I will agree about jQuery being a very large library with a lot of cross-browser support that isn't necessary for mobile. However, from my benchmarking, it would seem jQuery is still faster at most DOM operations than Zepto.
Happy to answer any questions about my experience with PhoneGap.
It pushes HTML5 canvas to its limits to create a completely cross-platform 2.5D action shooter. Also, a lot of players really like it and that is really the only metric that matters.
The game has its share of mobile specific optimizations, none of which are related to it being a PhoneGap application. Overall, PhoneGap just gets out of the way, the way things should be.
This article hits pretty hard on jQuery Mobile. I'm considering it for an upcoming project and hadn't heard about it being such a steep tradeoff on performance. Can anyone who has played around with it comment?
I used it with PhoneGap. I had no issues with PhoneGap, and unlimited issues with jQuery Mobile.
Basically, jQuery Mobile wants your whole app to be on one page. You can either have one giant HTML file that has a bunch of divs representing multiple pages, or you can have several different HTML files and link them as normal. Then jQuery Mobile will take all of your anchor links and turn them into something that fetches that page's contents and inserts it into the DOM of the current page, instead of loading a new page. Then their "page transitions" are triggering hide and show actions on the various pages in the DOM.
This also makes registering event handlers awful. First, all of your javascript has to be in one file and it has to be included in every page that a user could possibly navigate to. This means that you can't just bind on document.ready like normal, because some of the elements you're binding to don't actually exist on the page until you try and navigate to the page.
Then, jQuery Mobile uses custom events to tell you when there's been a page transition. However, you can't put your event bindings in there, either, because then your event bindings will be reapplied every time the user navigates away from and back to that page - basically, every action will be applied multiple times. Terrible.
So this means that all of your bindings have to be live bindings. Oh, also, you need to make sure none of your elements on different pages have the same id since, in the long run, jQuery Mobile mashes them all onto one page.
I recently made a very small jquery mobile web app. It still feels like alpha software, I was on an extremely tight deadline so I persevered with it, the end result worked out ok. I would be interested in other javascript framework recommendations that perform better, however from my research they all seemed to be at a similar stage to Jquery Mobile, either that or they were abandoned. If I was spending a lot of time on a mobile web app I'd probably invest the time into writing it without the layer of abstraction.
Two big tips:
1. Turn off the transitions, they perform poorly and look out of place on most devices.
2. Don't use the navbar, it just doesn't work properly on all devices, I wasted so much time trying to work out the issues with it before changing my navigation scheme.
Jokes aside, yes... it is that bad. I help out in the PhoneGap IRC channel, and I see more frustration surrounding jQuery Mobile in the PhoneGap community than any other single tool.
One of the core PhoneGap devs even tried to use it just so he could try and help people who come to us with issues relating to it. The experience was so bad I think he gave up on the idea.
I ended up making the above joke tumblr instead ;) I just try and steer people away from it.
Its performance and (in my opinion) visual appearance bely it's post 1.0 version number.
I think you're confusing jQuery with jQuery Mobile. You're right about the former, but the latter exists to paper over the differences between different mobile platforms, as well as provide an HTML-based UI framework.
Using PhoneGap at all seems like half-assing it to me. Just because some people think iPhone and Android apps should look the same doesn't make it so. A native app for each will look and perform much better.
It's easy vs simple. HTML is familiar and therefore perceived as the easy way to build apps. Native apps are invariably simpler after a certain level of necessary complexity.
I'd wager a guess that the "single codebase" app written in PhoneGap get exponentially more complex with each platform due to browser/device/OS quirks, whereas the native implementation means an effectively linear complexity for each additional platform.
maybe the PhoneGap website should make it more obvious that it is a bad idea to use jQuery Mobile instead of listing it on its Tools page: http://phonegap.com/tools/page/2/
What concerns me the most of this post is that it offers no clear alternatives. Are we expected to write all of the UI by hand? That's not really comparable to native development.
I would like to see a light-weight Javascript UI and MVC library that is recommended by Phonegap.
one reason we use JQM is for page transitions. what other frameworks provide page transitions? we could obviously roll our own, but are just curious what the other options are. zepto and XUI are two alternatives to JQM mentioned in the article. what other ones have people tried?
I've had great experience using Zepto, Backbone & custom styles. Was able to field a single-page app with about a dozen views - very interactive and very fast. Total app size about 25K including support libraries. Data loads asynchronously, cached using localstorage. I ran into endless glitches with JQM, but Zepto/Backbone/CustomCSS has been bulletproof every step of the way.
I'm heading this way on a PhoneGap app I'm working on right now. Once you give up the goal of a pixel-perfect emulation of a stock iOS UI the combination of Zepto/Backbone/CSS is pretty powerful and much, much faster than Cocoa for prototyping.
So this guy thinks knowing your target platform is a burden and not knowing it somehow is a pro?
On topic of half-assing: If you're using a multi platform 3rd party layer because you're too lazy/reluctant to learn the native technology you are already half assing it.
Take a look at all those multi platform desktop frameworks like Qt, wxWidgets, etc. Apps made with those don't feel native and usually deliver subpar user experience. It's not much different with PhoneGap, RubyMotion and friends.
If you want to make a new iOS app, it is not a big deal to learn ObjC + XCode etc. If you want to port your existing application to work on iOS while you are still managing the web, desktop, and other mobile/tablet development, it is difficult to devote enough time to properly learn ObjC.
The goals are different. Flipboard and InstaPaper wanted to make great iOS apps and spent the time and effort to learn the right away. And it took well over a year for a native Android port of InstaPaper. When your value proposition is finesse and performance, go native.
If BingoCardCreator wants an iOS port so teachers can easily drag and drop words using touch on an iPad while sitting in front of the TV, I don't see why Patrick/BCC should spend months and months learning ObjC when he could just hook something up easily with jQuery draggables UI.
I've released ObjC and PhoneGap apps on the App Store and frankly, like everything else in life, you have to make the best use of the resources (time/budget/energy) available to you to make the best product. What this blog post is saying, is that just because you use PhoneGap, does not necessarily mean your application will be subpar. You must know how to use it well.
Also, RubyMotion uses the exact same iOS objects as ObjC does (and then some). So it should be no different than coding natively in ObjC.
I get the business justification for using PhoneGap, but it doesn't change the fact that you're still half-assing it. Half-assing something with good reason is still half-assing, and the experience is still expectedly sub-par.
Actually, Qt does support the native look and feel on every device I'm aware of (linux, win, mac and symbian). And with Qt quick you can even make any kind of UI you want using QML (a sort of javascript).
>Take a look at all those multi platform desktop frameworks like Qt, wxWidgets, etc. Apps made with those don't feel native and usually deliver subpar user experience. It's not much different with PhoneGap, RubyMotion and friends.
This is not actually the case with RubyMotion, since it compiles directly to native code and uses iOS-native UI. A RubyMotion app is indistinguishable from a native Obj-C app.
Can someone explain why loading 240k of library files is a negative? Is this a performance issue or a storage issue? If the later, surely consumers don't care about space?
Because loading 50+ kB of code when you probably only need 10 kB of it is really stupid. This is compounded by underpowered mobile devices that can't digest a single-page ExtJS "app" with 2 MB of script.
performance issue, all this javascript code has to be parsed by the application before it is able to execute it. So you might end up parsing 95% of jquery/jquery mobile code that your application won't use.
Correct. Where "high quality" is pegged to apps like Tweetbot or Instagram, it's not currently possible to make webkit-based apps that are equally performant.
Even examples of "web with native wrapper" apps, like Facebook and OkCupid, are dramatically, dramatically worse than best of breed native apps.
Interesting that your two examples of "high quality" apps don't have web counterparts. Both Tweetbot and Instagram exist solely as native applications - which means that it makes business sense for them to develop natively.
Companies like OkCupid and LinkedIn, whose apps both rely heavily on web views, need to think about the benefits of using the same code across multiple platforms. I'd tend to argue that both of those apps are pretty well-done. They certainly lack some of the really slick transitions and polish of an app like Tweetbot, but I definitely don't think either one feels cheap.
No offense, but Facebook's webapp is stellar compared to the native app, Instagram can't stop crashing left and right and I don't even follow anyone, Twitter's app has taken it ages to get where it is today.
Oh, I'm fully on-board with the idea that web apps can be a reasonable alternative to native. I spend a huge amount of my time at work building mobile experiences in HTML5, because that approach makes sense for our product. I was just sort of hoping that gfosco would enlighten me as to why PhoneGap is so universally terrible.
I have a hard time believing that. Yeah it may take meg or so extra space, but if you think that is bloated it is time to upgrade that PDP 10 to a phone were it is about a rounding error.
Can you articulate this any more than a really poor analogy that falls flat for more than one reason?
Do you just have a problem with the native components that are all always there versus just the shim pieces you need, etc? Any evidence that that really causes any sort of perceivable issue? It seems like it would all be microscopic compared to... anything else in a real application.
Phonegap apps look and feel like phonegap, but 'run everywhere'.
I think Phonegap is a suitable replacement for Android & Blackberry where cheap > good.
On iOS I'm not sure how receptive the market would be... I think we all know how horrible Java apps feel on OS X, because it uses a slightly different UI paradigm (one menu bar).
I do think that you can do quality work on Phonegap, however, it's never going to 'feel' native iOS for a few years until the CPU performance improves on iPhone. That said there are certainly places when writing 'native' code that you throw in a UIWebView because getting iOS to do what you want is a major PITA.