Sorry but the app doesnt feel native at all. it is slow ,doesnt feel snappy on the last iphone. And you can easily tell the difference on touch event ,there is an noticiable lag, and nobody cant do anything about it. Web apps are good for basic lob apps. But for anything more complicated , going native is the way to go.
Anatomy of a Native Feeling HTML5 iOS App
31–40 of 61 posts
Re: Anatomy of a Native Feeling HTML5 iOS App
#32There is what appears to be a UIPickerView in this app. Did the developer re-implement this in HTML5? If so, doesn't that defeat the purpose of using HTML5 if they're just going to replicate iOS's look and feel? And more importantly, why is this on the App Store if it's HTML5? I'd like to see this running 100% in the browser and then compare vs. native app.
I actually think the app is pretty well made; I didn't notice too many of the problems that the other people are critiquing when viewed on my iPhone 5.
Having said that, the bigger question is: why do all that custom work when you can make a native one much quicker and more easily?
I think what this app shows is the lack of a HTML5 framework to quickly put together mobile apps that feel native the way you can with the iOS SDK or Android SDK. In the HTML5 world there are a lot of frameworks and libraries to create a mobile website, but there isn't one that lets you make a native-feeling web app. There are a lot of disparate pieces addressing different issues (PhoneGap/Titanium for native app launching, Bootstrap/Foundation for UI controls, fastclick implementation for faster tap response times, removing the URL header, hiding browser scroll bars, ...).
Re: Anatomy of a Native Feeling HTML5 iOS App
#33I'm probably missing the point (not sarcasm). I'm about to start writing my first mobile app - a UI client to a ReSTful image rating API. I've been debating between native and HTML5 for the past few days, and reading this article makes me lean ever more toward native. I see that the author's goal is possible. However, he's also illustrated that getting an HTML5 app to feel native on iOS requires a deep understanding…
The author here. You bring up a very good point. The caveats will be different for all different devices. And this does depend on a very deep knowledge of HTML5 hacks and tricks as well as a lot of experimentation.
Have you considered titanium appcellerator for your project?
Re: Anatomy of a Native Feeling HTML5 iOS App
#34Earlier quoted context omitted.
-webkit-overflow-scrolling:touch disables the feature where tapping the phone's status bar scrolls content back to the top. That has been a showstopper for most of the things I have worked on.
You can fake it with some pretty simple Javascript.
I have tried many a workaround, all quickly reveal a pretty crappy non-native experience.
Re: Anatomy of a Native Feeling HTML5 iOS App
#35This app is so painfully a web app. Here's why. First thing I did, started dragging around when I was presented with some grey/brown screen (an intermediary between the load image and the web app actually being loaded?) so I got a nice little rubber bandy action on a grey screen. Web app. Since there is no normal iOS UI pieces, I find myself being more critical of it because it's unfamiliar. I tap the input for the d…
Hey, at least you got that far. I'm on a completely brown screen that brings up keyboards when you click in places, but that's it. Can't even kill it in the multifinder, the app isn't there!
Re: Anatomy of a Native Feeling HTML5 iOS App
#36Earlier quoted context omitted.
Zepto is also worth checking out, especially if you're looking to reuse bits built with jQuery from a larger web app (API is almost identical).
Yeah I've tried Zepto as a drop-in replacement for JQuery once ... a long time ago. The results were disastrous (everything broke!) but I guess I'll try it again
It's still not a drop-in replacement, but it's close. You need to include more modules than just the core for eg. ajax or transition effects (the official modules are all available from http://zeptojs.com and/or the github linked there). I maintain a pretty hefty Backbone based web app where we use Zepto for mobile/non-IE to save on file size, and serve the exact same code but with jQuery for IE. In about a thousand lines of code, there are only 3 or 4 edge cases where the code paths diverge for a line or two, and they're due to IE peculiarities rather than Zepto/jQuery conflicts.
Re: Anatomy of a Native Feeling HTML5 iOS App
#37There is what appears to be a UIPickerView in this app. Did the developer re-implement this in HTML5? If so, doesn't that defeat the purpose of using HTML5 if they're just going to replicate iOS's look and feel? And more importantly, why is this on the App Store if it's HTML5? I'd like to see this running 100% in the browser and then compare vs. native app.
The UIPickerView is the default control that pops up when you use an HTML dropdown. It's built into the webview/browser.
Re: Anatomy of a Native Feeling HTML5 iOS App
#38I've been working on a more polished version of HTML5 Clear, trying to bring the "native-like HTML5" concept a bit further. It's still work in progress (around 85%) but it can be found here: http://clear2.youyuxi.com
Re: Anatomy of a Native Feeling HTML5 iOS App
#39This is a great example of the power of HTML5 and excites me about the future of it.
I'm a web and iOS developer and I'm starting a consumer facing app and here's my release priority:
1) Web app for desktop, tablet, and mobile using responsive web design
Pro: Every device in the world can reach my app. Since I'm trying to gain exposure, I want everyone to be able to experience what the app has to offer no matter their device or OS.
Con: Currently, users don't expect to interact with my app in this way. They want to go to the App Store and download an app. They also want to use something that they are used to on their specific platform. (To counter this (and for other reasons), the plan is to label the app as beta, so users know what they're getting themselves into and what to expect.)
2) Native App for tablets and smartphones
Pro: Performance, distribution, and native controls. Also, mobile users will use my app differently than desktop users so they deserve their own design and features.
Con: Resources in time and stress managing several code bases.
3) Native App for desktop
Pro: Performance, distribution, and native controls. Also, desktop users will use my app differently than mobile users to they deserve their own design and features.
Con: Resources in time and stress managing several code bases.
Existing case in point - Trello. They started with a responsive web app, they made a great native mobile app, and I expect them to release an awesome desktop app soon.
Re: Anatomy of a Native Feeling HTML5 iOS App
#40The reality is that the quality of any app depends on the skill set of the developer(s). Some of the native apps I use are wonderful, others are terrible.
As a web developer who is currently on a mobile app project that uses HTML5 and PhoneGap, I have been pleasantly surprised that we have been able to create an app that, in my opinion, looks great, is wonderfully fast on newer devices, and is a pleasure to use.
HTML5 is not the right choice for a lot of apps. But it's an option that should be taken seriously by anyone who has web development experience and it's a solution that I feel is getting better every day.