[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)

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!

[robmcm]

My understanding was that Safari used JIT which is prone to security issues with how it executes that code.

As to why it's safer to do so in Safar that in a webview must be because the only API to safar is from the JS/HTML/CSS but with a webview you have a C/ObjectiveC API from the other side, which may be harder to protect against.

[EDIT] - More information on the topic from Gruber http://daringfireball.net/2011/03/nitro_ios_43 although there is no reason given as to why a UIWebView is more at risk from exploits than Safari.

[Alphasite_]

My understanding is that you would have to mark some of the apps pages as executable, iirc, which could allow for arbitrary code execution.

[jamiesonbecker]

That makes little to no sense.

This reeks of the same logic that caused them to disable HTML file upload buttons (there's "no" filesystem -- which is apparently why you can't even browse for photos and uploads until recent IOS).

This is what drove "there's an app for that" for so many years: Apple's systematic limiting of web apps into a severely curtailed walled garden so that the app store would -- in fact, could -- be the only source for real applications.

"Web Apps aren't as performant as native" is a direct result of such strategies.

In other words, those strategies WORKED. As with all anti-competitive practices, they will keep doing their job for a while, until something new and better (or at least workable) comes along.

[stevekinney]

What's extra fun is that when Steve Jobs introduced the iPhone in 2007, he explained that developers could write web apps if they wanted to create software for the iPhone.

[jamiesonbecker]

I remember that, excellent point.

[rimantas]

Ok, show me Android apps which are as performant as native. This nonsense about Apple fearing web apps should stop already.

[Touche]

They made poor initial design decisions which effectively put a speed limit on JavaScript apps. Currently they are not motivated to do the probably very difficult work it would take to fix the problem, that's why it's so important that the Chrome team gets its shit together and makes the speed of Chrome Android awesome (which, to their credit, is a goal for this year).

Unfortunately the lack of competition on mobile makes innovation very slow, there's no motivation to make rapid improvements.

[x1024]

It's really easy to "fix the problem". There have been fixes on Jailbroken devices for years.

[maxmcd]

I'm not going to make an assumptions about how hard it is for apple to solve the problem, but I'm sure people writing solutions for jailbroken devices have a much greater degree of flexibility when it comes to making changes to the OS.

[dirtyaura]

Nitro, to my knowledge, only optimises Javascript performance, but JS performance is not the only bottleneck. We noticed that DOM manipulation together with style and layout calculations play a big part, see http://blog.mikie.iki.fi/2014/02/some-numbers-on-mobile-safa...

It's very tough to make a quality app using HTML5 if you use gestures and animations. Coding it in native Cocoa/Objective-C is much easier at the moment than trying to polish that last 10-20% of your HTML5 app performance.

[marknutter]

My take on this is that phones are only getting faster and people upgrade their phones far more frequently than they do their laptops/desktops. Compare what you're able to do with HTML5 apps today on modern phones to what you could do even 2 years ago and it's astonishing how fast things are progressing.

[tluyben2]

In the end HTML5 will work fine on phones. That'll take a few years yet though; currently it's shit. It's ok on an iPad, but compared to native, not so much. I like nice responsive HTML5 or HTML5 apps for stuff I use sometimes; like booking tickets, hotels, checking what's on TV and such. For stuff I click in all day long, like bugtrackers, PM systems, CRM, etc, HTML5 on mobile or desktop, is just wasting time. It's just not very nice to work with productively. This is improving fast on the desktop by building in provisions for being (temporarily) offline, easy drag & drop, offering small native plugins to interact with it, but it's not there yet.

On phones it's far from being a nice and productive experience; you can see that well when you 'quickly' check a task and end up trying to swipe something 10 times because it lags and swearing profusely. Which happens with all badly 'cross platform' written apps which are mostly HTML5.

[mike_hearn]

HTML5 was supposed to be the answer when the iPhone 1 was first announced. It still sucks many years later. Draw your own conclusions ....

[forgotAgain]

That's analogous to the advance of desktops. The hardware kept getting faster ("what Intel gives") but at the same time the software became more complex ("Microsoft takes away"). If you deliver software based on it performing better on future revs of hardware, you're going to get a reputation for delivering pokey software.

[umsm]

I don't know the details of your app, but I have a feeling that there are many places where you can optimize it.

You can't just take a desktop app and stick it on the phone. It will perform poorly.

But you have to design mobile (web) apps from the ground up relying on the strengths of the mobile platform.

One idea is to limit the functionality of the mobile app. Tasks which are very UI heavy should probably be simplified or removed.

[odonnellryan]

Can I see it?

[forgotAgain]

Sorry but we're limiting public access while we work out some issues. There will definitely be a Show HN when its ready for public viewing.

[Touche]

Tried React?