iOS is about detail. Especially the "feeling".
Anatomy of a Native Feeling HTML5 iOS App
11–20 of 61 posts
Re: Anatomy of a Native Feeling HTML5 iOS App
#12This is a really nice looking html app. There's a couple of things not mentioned that I think help it look like a native app. One is that the app actually doesn't actually try to look like a "native" app with standard iOS controls - it looks like a custom styled app. In that way you don't actually have to trick the user into thinking the controls are all native. Perhaps some people might consider that cheating, but I think it's clever.
The other thing is that this app doesn't have navigating to new screens, especially swiping. I've seen some HTML apps that simulate swipe and it's damn close, but you can still tell that it doesn't feel exactly native.
I think it's great to see HTML apps getting better all the time, though. Having to manage three codebases (Android, iOS and Windows) in three languages can be incredibly challenging for small shops.
Re: Anatomy of a Native Feeling HTML5 iOS App
#13In my (very recent) experience building a relatively complex [1] mobile web app [2] as a first-time web-app-for-mobile developer, I learned a few important rules, so to speak, about how to make the app feel as native as possible. (If you check it out, let me know at frank at callingvault dot com if you have any issues. We're in beta, and we love when tech savvy folks test.) The rules: - Most of the browsers on Androi…
For my latest project I've did all that. Here are somethings I've learned:
I've discovered that chrome has a problem with zoom levels (Nexus 4), while my older Desire's browser worked well.
Overlaying text over images is a royal pain in the ass for all mobile browsers. (Your standard position:fixed and position: relative thing won't work well unless you write media queries for every single goddamn fucking resolution)
Chrome lags with JQuery animation and that's an issue I'm looking to fix (since I am using Bootstrap's carousel)
Media queries are fucking amazing. Javascript support on most mobile browsers are quite terrible, and even lags (I'm using an iPod touch to test my webapp)
Re: Anatomy of a Native Feeling HTML5 iOS App
#14Too bad Apple artificially limits the performance of the embedded browser.
Re: Anatomy of a Native Feeling HTML5 iOS App
#15I just recently completed a mobile web app for my start-up and was pleasantly surprise with what I was able to achieve. If I was to share anything from my recent experience these would be my main points: - use the correct HTML5 elements for input (eg: "number" brings up the keyboard with numbers already selected, "date" brings up a native datepicker (iOS5+)) - Use lightweight javascript frameworks, or write your own.…
Interesting. I found I had the exact same experience as you did for my latest projects. In fact you helped solved a problem I have with JQuery Mobile (i.e. it laaaaaaaaaaaaaaa....gs)
Guess I'll be picking up XUIJS.
Re: Anatomy of a Native Feeling HTML5 iOS App
#16Too bad Apple artificially limits the performance of the embedded browser.
In reality for the vast majority of apps you'll never notice the limit. By far the most effective thing to use for (hardware accelerated) smooth animation are CSS transitions which run at normal speed like safari.
The only circumstance where missing JIT support for the webview would come into play would be with games, and even here there is plenty of room for performance (check out impactJS)
Re: Anatomy of a Native Feeling HTML5 iOS App
#17The animations are smooth and I wouldn't be able to tell if it was native or not based on what the app can do. The problem is, the app doesn't DO anything. There's no scrolling. There's no loading anything from the web (except for the blurry non-retina ads). There isn't anything in this app that makes it a candidate for an app (vs a website) in the first place.
Scrolling feels 100% native using -webkit-overflow-scrolling: touch; I am currently working on the next (more complicated) app for UberMedia that has all of those components and works very nicely. It will be one month or so before it is ready for release.
-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.
Re: Anatomy of a Native Feeling HTML5 iOS App
#18There 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.
Re: Anatomy of a Native Feeling HTML5 iOS App
#19Earlier quoted context omitted.
Scrolling feels 100% native using -webkit-overflow-scrolling: touch; I am currently working on the next (more complicated) app for UberMedia that has all of those components and works very nicely. It will be one month or so before it is ready for release.
-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.
True. I wonder if there's a fix for this in PhoneGap, at least.
Re: Anatomy of a Native Feeling HTML5 iOS App
#20I just recently completed a mobile web app for my start-up and was pleasantly surprise with what I was able to achieve. If I was to share anything from my recent experience these would be my main points: - use the correct HTML5 elements for input (eg: "number" brings up the keyboard with numbers already selected, "date" brings up a native datepicker (iOS5+)) - Use lightweight javascript frameworks, or write your own.…
Interesting. I found I had the exact same experience as you did for my latest projects. In fact you helped solved a problem I have with JQuery Mobile (i.e. it laaaaaaaaaaaaaaa....gs) Guess I'll be picking up XUIJS.
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).