
Framework 7 – Building native iOS apps in HTML5 - hwaal
http://www.idangero.us/framework7/
======
my3681
I'm not knocking this or any particular xxxx-to-mobile platform, but as a
native iOS and android developer, I would highly recommend just learning the
native languages and frameworks.

First, you have the absolute most control you will ever have over your
application. This may not be true when a particular tool becomes popular, say
at the release of a new tool, but this definitely shows up as time progresses.
Who knows what tools will keep up with the native frameworks terms of
functionality?

Another reason that is more qualitative, is that you come into contact
different design styles, code styles and paradigms. Objective-C, for instance,
is a tricky beast sometimes, but it is an interesting language with a lot to
learn both good and bad. The new things you learn will most definitely carry
over into your web programming!

The third reason to code natively, and I cannot stress this enough, is third-
party library support. Maven and cocoa pods may dependency management much
better on the mobile platforms, and using a third-party tool will most likely
render all those advancements useless. There are some amazing libraries for
both platforms that you definitely don't want to miss. They were reduce the
amount of time you spend coding and improve your baseline quality.

~~~
marknutter
So if you want a web app, an android app, and an iPhone app, you have to code
it up 3 different times in three different languages. The reason why the web
exploded in popularity as a development target is precisely because it made it
easier to target a larger number of customers. Imagine if Facebook had started
out as a Windows XP / Linux / OSX native application. It never would have even
got off the ground.

My take on this is that if you absolutely need the performance, go native and
pick the platform you'll get the most customers on. If you're app is a
glorified CRUD wrapper, though, HTML5 will probably suit your needs and you'll
only have to code it up once.

~~~
tluyben2
I don't buy it. Enterprises definitely buy into that idea and they do have
their employees work with these crippled apps because they have no other
choice. But the experience for this 'CRUD' app is definitely not good enough.
It's by forcing it that it gets used. It depends on how intensively it will be
used in reality, but I definitely know quite a few companies who went from
BYOD and an HTML5 Cordova app which was very intensely used to just buying
Android devices for the employees and making a native app to boost
productivity.

If you have to enter / search / whatever information in an app which is
horrible to use (a BIT of lag can ruin your day; you tap/swipe; because of the
lag it just responds a bit late, the keyboard pops for the wrong field or you
submit accidentally; plop seconds lost and so is your good mood) all day,
you're not going to want to work with crap. It's not 'good enough' even though
management might think so.

~~~
marknutter
You don't have to buy it, it's an undeniable reality. Yes, if you're an
enterprise and you can afford to write native apps for all platforms, then
that's the better choice. If you're a small startup or a single developer,
writing the app 3 times is just not cost effective.

~~~
rimantas
Most likely you never tried to do what you preach. You will end writing your
app only a little bit faster (if you are lucky) and then three times more on
debugging.

~~~
marknutter
I have. I built an HTML5 hybrid mobile app for Android and iOS. It was about
90% JS/HTML/CSS and 10% native code. Worked very well for our purposes. You
can judge for yourself, it's called Kona and in both major app stores.

~~~
auvrw
> 90% JS/HTML/CSS and 10% native code.

this was going to be my comment on the original comment: it's not like you
have to do _only_ HTML5 or _only_ native, or so i'm given to understand... i'd
be interested to hear more about the hybrid approach if anyone has links/blog
posts.

~~~
tluyben2
10/90 is Phonegap/Cordova; when hybrid _is_ viable (imho) is when you need to
show complex documents; what HTML _was_ made for. So the parts in your native
app where you need to show documents with nice flowing text, images, charts,
etc HTML is a good option, but then the 10/90 is usually not native/html, but
the other way around.

------
jfahrenkrug
Cross-platform UI is a bad idea on the desktop. Cross-platform UI also is a
bad idea on mobile. We need to learn from the past. Cross-platform UI is a
conceptual mistake. An app that has an icon on the home screen is perceived by
the user as "an app", no matter if it actually launches the browser without
the toolbar, if it is a web app wrapped in a PhoneGap shell of if it is a
native app. To the user, it's an app. It has an icon, so it's an app. The rest
are implementation details that the user doesn't (and shouldn't) care about.
So if the user perceives it to be a native app like all the other apps, it has
to behave like one. Otherwise the user will be disappointed. Web apps that
mimic native apps simply don't behave exactly like native apps: Imitating
native UI with web technologies on a mobile device will only disappoint.

~~~
dmix
As someone who spent years building "HTML5" JS mobile apps and then recently
spending the time to learn native languages, I 100% agree. There is no way to
match the performance and consistency of native with a cross-platform clone.
It will always be a half-baked solution.

That being said this only applies to _apps_. A ton of apps shouldn't be apps,
they should be well-optimized websites. For ex. content sites.

Side Note: Learning Objective-c and Android java dev isn't nearly as bad as I
thought it would be. It takes less time to learn and build native instead of
trying to hammer Javascript into a hole it doesnt fit into, and spending hours
attempting to optimize it's performance to no end.

~~~
Kiro
> Learning Objective-c and Android java dev isn't nearly as bad as I thought
> it would be

Where did you start? As a web developer Java and Objective-C seem really
complicated and require so much code for the simplest things.

~~~
dmix
The additional code involved in Java/Obj-c is less annoying since they are
well integrated in IDEs such Android Studio or Xcode which auto-generate most
of the boilerplate. After you develop for a while you depend less on the IDEs.

I always build an app to learn the language/platform. The only way you can
really learn it is by building something. Combined with that I usually buy a
book.

For Android, I hardly had to invest any time learning Java, since I came from
Ruby and it's pretty similar. Most programming languages are all the same
under the surface. Especially among OO-heavy ones.

Best android book: [http://www.amazon.com/Android-Programming-Ranch-Guide-
Guides...](http://www.amazon.com/Android-Programming-Ranch-Guide-
Guides/dp/0321804333/)

Best objective-c book: [http://www.amazon.com/iOS-Programming-Ranch-Edition-
Guides/d...](http://www.amazon.com/iOS-Programming-Ranch-Edition-
Guides/dp/0321942051/)

Both books assume you know the languages but I jumped in with limited
knowledge and learned the language as I went.

------
forgotAgain
The limit we've run into with iOS is not getting a good looking UI. Rather
it's the performance of Javascript in Safari. We have a fairly large one page
webapp that looks great on iOS however the performance is an order of
magnitude slower on an iPad than Chrome on an old laptop.

~~~
stevekinney
My understanding is that only Safari gets access to Nitro (Nitro : Apple :: V8
: Google). Web Views inside native apps don't get access to Nitro. Even web
apps that you save to your home screen don't get access to the faster
rendering engine. This is apparently for security reasons. I think it's one of
the biggest barriers to web apps being competitive on iOS. (The other is that
there really isn't a good installation story.)

~~~
mikemoka
"security reasons" (= [http://bit.ly/1d7p5Tq](http://bit.ly/1d7p5Tq))

it would be interesting if they elaborate on those...

~~~
wildpeaks
More like "job security" reasons as they have less control over webapps than
apps.

~~~
streptomycin
Same reason I think they're dragging their feet on various parts of HTML5 that
everyone else has already implemented, such as IndexedDB.

~~~
rimantas
You forgot to mention the part where Apple was first to implement features
that later become known as HTML5. Also, the story of Web SQL and IndexedDB is
not so simple.

~~~
streptomycin
Can you tell the story that explains why Apple has done nothing with IndexedDB
for years while every browser vendor implemented it a while ago? Because the
story as I see it is very clear: Apple embraced the web when they had very
small market share, and they're doing the opposite now that they have a good
chunk of the market. Walled gardens generally aren't very profitable if you
have only a tiny fraction of the market.

Of course, it'll be hard for you to tell a convincing story because (AFAIK)
Apple hasn't even commented on IndexedDB. Strange, for such a well-established
open standard. Even MS has supported it for years!

------
redindian75
Wow what a tough crowd. So many off topic discussions. The framework is
buttery smooth, and very well done. Kudos to the dev! I have never seen any
html5 framework (like ionic, jqm, wink etc) nail swipe to delete row so
acurately Awesome job!

------
oakesm9
Don't frameworks like this which try and emulate one platform very well get
rid of the only advantage of building an app using web technologies, that it's
cross platform. Apps using this will feel really out of place on Android and
Windows Phone, and you'll end up spending lots of time porting the web app to
those platforms if you want to support them properly.

~~~
tfinniga
> the only advantage of building an app using web technologies, that it's
> cross platform

There are other advantages of building an app using web technologies. Maybe
you want to link to a store that doesn't pay Apple 30%. Maybe you want to
control your own updates. Etc.

~~~
CmonDev
> Maybe you want to link to a store that doesn't pay Apple 30%

Isn't this explicitly forbidden on AppStore by Apple regardless of technology?

> Maybe you want to control your own updates.

This is what some games do, you don't need HTML/JS for that.

~~~
tfinniga
Right, that's an app store rule. However, if you've got an HTML 5 app you
don't need to install it through the app store. For example, forecast.io.

I'm not sure what you're saying about games controlling their own updates.
What I was talking about specifically is that a web app can update at any
time, without the vetting process required of apps in the app store. My
understanding was that app store apps couldn't download and execute new code.

------
joshmlewis
I wanted to enjoy this but I opened it on my phone and was immediately cursed
with problems.

\- When I scrolled the list items where my thumb was scrolling started
lighting up

\- When I clicked a button nothing happened, I had to click a few times
repeatedly before it changed screens and even then it didn't feel like I
clicked

\- When I clicked back nothing happened, and after a couple more tries I saw
it was working and then changed the page. That might could be solved with
something like fastclick.

I would love a tool like this but it has to be damn near perfect for me to be
able to consider it with my team.

EDIT: After playing with it a little more I found it gets a little better. The
big issue is lag and fluidness for me. It's got to be very responsive to touch
and movements and not have any lag or choppiness.

------
joeblau
The problem with HTML5 is and always will be performance, not because of HTML5
but because of the platform it sits on. The DOM simply can not perform with
the efficiency of native applications. I'm more hopeful for companies like
famo.us that have basically subverted the DOM renderer for their own Unity-
style game engine. You can see demos of their projects at
[http://demo.famo.us/](http://demo.famo.us/). Running those on your phone will
give you an idea of what a truly native web experience should feel like.

All of these attempts to make a web page run fast on the phone are all bound
by one single performance constraint; Document Object Model.

------
jbverschoor
Very impressive! One of the best mimics so far. Performance is good and very
lightweight. Might use this for prototyping an app.

------
apierre
The title should say, mimics native iOS UI in the browser. Nice job though.

~~~
jimejim
This. I like the look of it and it's still useful, but we need to stop abusing
the word "native." Let's be clear that this is just an html framework that
looks like a native app. It's still a website.

This is not the same thing as Phonegap, for example, which lets you build a
native app you could install from the app store.

Again, still useful if you want your mobile website to look native, but not
the same thing.

------
timmm
This is a webview app not a native app.

------
thewarrior
I played with this just now on an IPod Touch and must say that it is
incredibly smooth. It could easily be mistaken for a native app.

------
Dogamondo
I've had quite a lot of luck developing HTML/JS apps in Sencha Touch (very
basic CRUD apps of course). Really noticed a speed improvement running the
latest release on an iPhone 5S. Not sure how much room there really is for
HTML/JS ports at this stage. Titanum was a let down for me. Am keen to try
Xamarin next. Or just go native? Thoughts?...

------
noinput
Very impressive. As someone who uses Appcelerator a lot, this makes me rethink
the ability to prototype and app quick and wrap it with Phonegap, or a similar
strategy.

Colors, spacing, swipe translations are all very solid. While a majority of
everyone else here complains about pixels and the right words to use, I'd like
to congratulate you on this.

------
kosso
Nice work.

Suggestion: Add the new iOS7.1 "minimal-ui" key to the viewport tag.

It makes the top bar a lot smaller and makes it fullscreen in landscape mode.
Much nicer for an 'app-like' experience.

<meta name="viewport" content="width=device-width initial-scale=1.0 maximum-
scale=1.0 user-scalable=yes, minimal-ui" />

~~~
lukifer
minimal-ui is a god-send. Without it, bottom-screen tab bars in web apps are
effectively unusable.

------
pjmlp
Native apps in HTML5 is an oxymoron.

~~~
romanovcode
It's important to add words like "native" to main product description tho.
Adds credibility. It's ok that this is completely NOT native.

------
WillKirkby
Just tried it on Android (Chrome, Nexus 5, 4.4.2). Very smooth, but the
sideways page-to-page transition was incredibly stuttery. It also doesn't
handle the "back" button the way I'd expect from something like this.

------
maxehmookau
Yeah, this is shiny and cool. But not native.

~~~
kosso
True. This is different to how Appcelerator Titanium does it - which does
build native apps with native components, despite the code to build the apps
being written in JavaScript.

------
jfahrenkrug
They did a nice job on this framework, but I think it is a fundamentally wrong
approach. Here is why: [http://www.springenwerk.com/2011/09/thoughts-on-
mobile-ui-de...](http://www.springenwerk.com/2011/09/thoughts-on-mobile-ui-
design.html) Or, if you prefer a video:
[http://vimeo.com/32256530](http://vimeo.com/32256530)

------
fvt
I'm baffled that a technology stack (HTML, JS) that every single web developer
think is broken (but still have to deal with) is being considered for iOS
development, and being promoted as an easy way to develop native apps.

This is where I think RubyMotion offered the best of both worlds: native APIs
and Ruby's flexibility (even if Objective-C is really not that bad or hard to
learn).

~~~
beagle90
Web Dev here. I don't think the stack is broken.

~~~
fvt
Positioning elements, fighting to implement the support of multiples screen
resolutions, dealing with JS quarks, etc. All those topics are mastered in
most native frameworks and clearly a hot topic in web dev.

Maybe broken is a little bit exaggerated, but very well deserved IMHO.

After several years in web dev _and_ mobile dev, I can safely say that even in
a couple of years, native toolchains won't be relegated to a marginal role and
remain the only efficient way of developing native apps.

------
krrishd
I remember that you built this in the Static Showdown hackathon!
Congratulations, and it looks like a really promising project :)

------
madeofpalk
I'm very impressed with the page transitions. They're pretty spot on.

Havent got the toggles right though. The stretched out dot is not it moving
into another position, it's the result of you tapping it. If you tap and hold,
the dot shoud expand out.

------
jonashickisch
Correction, "Native look & feel". But well made!

------
SimeVidas
So the "Download" button is a regular link to the GitHub repo. Ugh, not a
smart move.

Ok, so the technical details are:

* JS file (minimized): 33k * CSS file (minimized): 62k

------
jameshk
I would say best used as a web app that one can use along side a native app IE
Gmail, which has an ok mobile web app and a good native app.

------
haar
Was anyone else disappointed when they opened it on their iPhone and it
rendered the same page?

------
danbruc
Congratulation! You have managed to create a web page where even links no
longer work. Okay, that is a bit of an overstatement - open in new window,
download and probably also the social media links do work.

------
zschoche
There is nothing native. Go home and read a books.

------
ing33k
nice, but where are the docs ?

------
geoffroy
really cool I think !

------
EC1
This is honestly so pointless and bad for the community, further dividing up
mobile technology. Why not just improve on something that already exists like
jQM?

"Building native iOS apps in HTML5". You're building them in HTML5, to look
like iOS7, not exactly native now is it? This is the same thing as making a
theme for jQuery Mobile.

I clicked on this hoping to download something that converts my HTML5 app to
native code, but then I clicked this, and immediately had severe performance
issues on iOS7, iPhone 5S.

I really hope this does not take off, and if it does, I hope they fix the
performance ASAP.

Not even REMOTELY close to native performance, look, or feel.

~~~
tluyben2
Did you ever try jQM? My god. I applaud any efforts to move away from it.

~~~
EC1
JQM is so unbelievably terrible. Been working with it for the past year.

~~~
tluyben2
I'm so sorry... I have seriously not often in my 30 years of being a coder
seen something so promising turn out so bad. It doesn't even get the 'hello
world' right. Why have you been working for it for the past year?

