Hacker News Reader

Comment by pdog | Hacker News Reader

It's more complicated than you make it out to be.

Facebook has to work consistently on so many different platforms (not just iPhone, Android, Blackberry and Windows Phone; also, the billion+ feature phones out there) and continuous deployment is the process at the heart of Facebook (the motto: move fast, break things).

Facebook is always adding new features and improvements. By using Web technologies, they can share code and make these changes on the server side, not to ease developers' efficiency but to guarantee interoperability and a consistent user experience.

View on HN

> It's more complicated than you make it out to be.

I didn't make it out to be simple or complicated. They valued their sense of developer efficiency over user experience.

No matter how efficient your developers are, it's gonna take longer to get a new version of a native app submitted, approved, and downloaded by users, than it is to simple deploy to a webserver.

By going native, Facebook has greatly improved the user experience of this version of their app (which I applaud), but greatly slowed the speed at which they can iterate to the next version.

User spend their time using the application, not waiting for an update.

Sacrificing their user experience for rapid updates is putting a sense of engineering efficiency ahead of user experience.

What if the update is a bug fix?

That still isn't where the vast majority of user time is spent.

If the goal is putting user experience first, and you're concerned about critical bugs, then expend the engineering effort required to reduce the risk of rolling out a bug.

Related aside; Apple can roll out an emergency fix in an hour or two.

Because it's their app store.

To clarify, I was referring to Apple's policy regarding emergency fixes for 3rd party applications.

I think you're missing the point. How long does it take for that fix to be downloaded? Tons of users will never see it. Tons of users will continue to use the version with the vulnerability.

Here's a good talk on the subject:

http://www.youtube.com/watch?v=MksKaRpWD-o

How is this an argument in favor of an over-all worse user-experience?

If this is a significant concern to you, then prompt or enforce upgrades in your application.

Consider a UI update that is, provably, an improvement to the user experience. Delaying that update by 3 weeks (due to the App Store process) is itself a form of sacrificing the user experience.

Or more likely, consider an example where Facebook is not sure which of 3 UI changes would most improve the user experience, and they want to serve each of the 3 to small subsets to collect test data. Native UI rendering takes away this ability, potentially reducing Facebook's ability to improve the user experience--also a form of sacrifice.

Now maybe you believe that the poor performance of the HTML5 UI was an even greater sacrifice than these, and thus the switch to the native UI is a net improvement in user experience. I happen to agree with that, but that doesn't mean there aren't tradeoffs.

Performance issues aside, the user experience of the Facebook mobile app is miles better now than it was when they last rendered the iOS UI natively. A big reason for that is the speed at which they iterate changes in the HTML5 UI.

Edit to add TL;DR: There is more to optimizing the user experience than maximizing UI performance.

Given the reaction to any small UI update Facebook has rolled out since people began using the site has be pretty bad, maybe it's better that it takes more time to roll the changes out.

The reaction to any small UI update, anywhere, is pretty bad. People hate change (or more specifically, they hate having change forced upon them). The reaction to rolling back the changes after they've been out several months is usually equally bad.

If you look into their tech blog post about the update, they use HTML5 as a fallback render for new stuff. They then create the native renderer for the widget and push it with the new update a few weeks/months later. So they can still A/B test as quickly as they want.

I don't think that they said that their fallback renderer was HTML5, but they did say that there were still areas of the app that still used that technology.

I just want to correct a factual error in your post. I've noticed that the review process time used in a variety of responses continues to creep upwards -- here, it's up to three weeks.

As it currently stands, as per Apple's published status, 95% of applications are approved within 8 days.

After Apple publishes a new version of your app, your users must notice the update and choose download it--my guesstimation includes that. If you'd prefer to use 8 days, that is still a lot longer than the next HTTP request, which is how long it takes users to get a new version of a web app.

Who cares how fast you can iterate if your product is unusably and unfixably bad?

I didn't make it out to be simple or complicated. They simply valued their sense of efficiency over user experience.

There's not much room for "simply" when you're talking about a service that has to work across dozens of OS/browser variants, is practically a utility to its (hundreds of millions of) users, and receives multiple daily updates. This isn't an upstart web service that can optimize around a platform that might be only a fraction of their potential user base either.

Perhaps not. But when your most valuable customers are clustering around one or two platforms...

Give me a freaking break, please. Tell me where the Android 100% native app is? Oh, it doesn't exist yet? In my book, not existing is the worst kind of user experience. There are concessions to be made when going full native just like they are when going hybrid. In this case, it's speed of development.

You just repeated your oversimplification:

"They valued their sense of developer efficiency over user experience"

No, they made a judgement that user experience would ultimately be better from being able to deploy rapid changes via a consistent cross platform experience under their control vs writing OS specific code and placing themselves under the control of a third party and that will significantly operationally limit them ("Can we roll out the new user profile yet? No, we're still waiting on Apple to approve the change ...").

They may have been wrong, but it doesn't change their original intent. If anything we should all be lamenting the failure of HTML5 as a truly viable app replacement at this point; I can't blame Facebook for wanting to believe it would be possible.

I'm curious as to whether you think users want, need, benefit, or care about whether Facebook can deploy rapid changes via a "consistent cross platform experience".

In my experience, users want a consistent platform experience -- one that fits in with the platform that they're using. They're also not interested in your development processes, especially if it means rapid dispatch of potentially breaking changes. In fact, I'd say that runs counter to user's interests.

Engineers and product managers seem to be the primary cheerleaders of "consistent cross platform experience". I don't see why a user would want that. I do see why developers and product managers would want that.

> If anything we should all be lamenting the failure of HTML5 as a truly viable app replacement at this point; I can't blame Facebook for wanting to believe it would be possible.

I'm not lamenting HTML5 as a viable application platform replacement, because it never was going to be one. The web industry consistently ignores 30+ years of experience that the desktop (and now mobile) development industries have in bringing high quality applications to user's devices. The web universe eschews common platform conventions, common rendering approaches, common widget libraries, and instead has attempted to force everyone to individually reinvent application development on top of DOM, CSS, and JavaScript -- a SGML-derived history-laden mess that served documents well and applications poorly.

The lesson for the web industry should be that they need to figure out how to bring align whatever ethos they have -- presumably of a common, open platform -- and bring them to bear on implementing something genuinely competitive with the native development platforms.

DOM/CSS/JS is not it.

> I'm curious as to whether you think users want, need, benefit, or care about whether Facebook can deploy rapid changes via a "consistent cross platform experience".

It's not about me; your statement was about what Facebook's values were (valuing their own expediency over their users). I just don't think your statement about their values was fair, especially in the light of history (do you remember Steve Jobs walking out on stage and telling everybody how the iPhone didn't need apps because the browser was so awesome?).

> In my experience, users want a consistent platform experience -- one that fits in with the platform that they're using

Well we're not that far apart then. You consider iOS the platform, I consider Facebook the platform. You can hardly blame Facebook for considering Facebook to be the platform.

I general I don't think there's a single answer to this. If lots of new features delivered rapidly are what your users need then it seems obvious that only writing code once and delivering it to lots of platforms can get them those features fast. If features are slowing and quality of experience is more important then native code is a better option. I'd posit that Facebook is actually transitioning from it's rapid-development-new-feature phase into a more mature, stable platform where quality of experience is more important, and this transition is just natural and even optimal for them rather than the kind of "mistake corrected" that people are making it out to be.

> Well we're not that far apart then. You consider iOS the platform, I consider Facebook the platform.

That's actually worlds apart.

There's a tendency for everyone to think that their platform is the platform. For users, that's not the case.

You are a genius, sir/madam.

Since mobile is their biggest growth platform and considering that they have the resources, I just don't see this as a strong argument. I always thought it was very silly that the website ran better and faster in Safari vs the "native" app.

That's not Facebook's fault its Apple's. iOS's UIWebView uses an older version of webkit and a much older version of there javascript engine. Apple doesn't want you building web apps they can't monetize.

So really, it's Facebook's fault for using UIWebView, vs. a true native app.

I don't know if you're an iOS developer, but that's plain mis-information.

The reason native apps use a different flavour of WebKit to Safari is because the latter operates in a privileged security mode, whereas the former are all sandboxed. Mobile Safari uses a JIT compiler, but this introduces the possibility for remote code execution.

It's not that Apple 'doesn't want you building web apps they can't monetize' - it's that JIT compilation of JavaScript doesn't sit well with the current iOS security model.

People seem to easily forget that Mobile Web was originally the only way to get apps onto the iPhone. A number of Apple's own apps (the App Store, for example) are HTML based rather than ObjC based.

"It's not that Apple 'doesn't want you building web apps they can't monetize'"

That's simply not true.

1) A year ago Apple rejected one of our app updates because a webview inside the app had a payment form. (They told us that they do not allow any other payment option other than Apple in app purchases)

2) Yesterday they rejected yet another update for our app because it had a form where users could enter bonus codes.

Their explanation: We don't know if you are not selling those bonuscodes to your customers somewhere else on the web. (We don't, thats just bonus codes from promotion agreements with blogs/newspapers etc)

That's insane, I just had the same 2) rejection and spent literally weeks thinking that I wasn't able to properly explain what the codes where for, because it didn't make any sense for them to reject that. But since you've had the same issue, i guess they really start to be seriously deranged.

Whilst that's arguably true, UIWebView being the poor cousin of mobile Safari isn't evidence for it.

Of everything that irks me about the app store (and I say this as someone who uses almost exclusively Apple computers / mobile devices), this is pretty high up there. It makes it damn near impossible to run a successful marketplace businesses on iOS: if your business is based on skimming a percentage fee off the top of your user's transactions, Apple taking 30% is more often than not a dealbreaker.

That being said, that's not an issue of native apps vs. web apps. If you want your application distributed through the app store, anything payment-related (or even potentially payment-related) needs to go through Apple's payment services. Period. Apple would complain just as much if you had a native app that had your own payment form, and they'd be 100% fine if you built a pure webapp (i.e. not on the app store) that accepted non-Apple payment.

> because a webview inside the app had a payment form

You didn't get rejected because it was inside a webview. You got rejected because you were selling something outside of In-App Purchases. You know this.

Why do webviews have anything to do with it?

This seems like a silly argument. You can release a free app in the iOS app store with a UIWebView or as a native app. It seems like Apple is optimizing for safety (a sandboxed version of the web view) and encouraging app performance. I don't see any monetization strategy at the heart of this (since Apple's cut of a free app is still 0).

That issue is not as simple as you make it out to be. Just in time compilation of Javascript requires an app to have permission to execute code that is generated as data on the fly. Applications with this permission are vulnerable to exploits.

The standard UIWebView available to applications doesn't include just-in-time compilation because 3rd party applications don't have this permission. This is the biggest reason why its Javascript engine is slower than the one built into Safari.

Apple doesn't want you building apps that open up exploit vectors into iOS.

But it's OK to write web pages that do?

No, but web pages (including apps that are installed to the home screen and run full screen) run inside the MobileSafari process, which is much more carefully audited than your typical iOS app.

Can you give an example of an exploit that would do harm from within a UIWebView but would not do harm from within Mobile Safari? Not questioning you, I'm genuinely interested.

Given the current architecture, if UIWebkitView within an application can execute data, then the entire application can execute data.

So you could have a buffer overrun anywhere in the app. For example, if they are silly, you could go to the preferences for Facebook and enter a very, very, very long user name, overrun the name buffer, and have executable code.

That's not an exploit of UIWebkitView, it's an exploit of giving the application the permission it needs to have UIWebkitView use a JIT compiler for JS.

Audited how? Unless MobileSafari is itself tightly sandboxed, I don't see how auditing the code inside it is useful. Once you get malicious executable code inside MobileSafari, it can do whatever MobileSafari can do.

Edit: I think a better hypothesis is that Apple wants to be able to analyze app code, and thus disallows executable memory, which also rules out JITs. See: http://apple.slashdot.org/comments.pl?sid=2044470&cid=35...

I doubt they're trying to audit behaviour, you can always write an app in Lua with an interpreter and they would have a hard time "auditing" the app statically.

The propblem is that if you allow executable memory you open aup a lot of exploit vectors. Now, that's true of Mobile Safari as well, but they trust their own team more than they trust you, and they have one app to watch instead of 100,000, and if an exploit os found they can push out a fix immediately, whereas 3rd party apps have a tortuous process for pushing out bug fixes.

Remember, it's part of their value proposition that apps from the app store appear to be relatively safe in comparison to the clusterfuck that is downloading random desktop apps, especially on Windows.

If it really is an engineering challenge it needs to be fixed. We're going on 2 years of Mobile Safari having JIT and UIWebView not having it. They can simply make an exception for UIWebViews without making an exception for the rest of the app. I don't know their codebase and it might be really really hard to fix, but I hope it isn't something they've given up on. It cannot continue in perpetuity, as the web cannot continue to evolve if the makers of one of the most popular browsers have given up on speed improvements.

No they can't: part of a process cannot create executable memory while another part cannot. They'd have to move WebKit completely out of process: a huge task as it already does most text drawing.

> They'd have to move WebKit completely out of process

Then that's what they need to do, JIT is a requirement for fast JavaScript and 2012 JS speeds cannot be the end of the line.

A task that they are doing with http://trac.webkit.org/wiki/WebKit2

An interesting alternative would be to enhance the current 'Save to Home Page' feature beyond specifying a manifest of resources and a home page icon. If this was fattened up to allow developers to make something that looked even more like an app but was running Safari (not a UIWebkitView inside a native app), you might have something interesting.

Pure conjecture on my part.

Which is what Safari does on OS X.

And that is somehow a valid justification for writing an inadequate "native" app? Why would you choose to do it this way then if the platform you are targeting is 1) important and 2) doesn't have good support for whatever technology you are using?!?!

This is equivalent to being hired by a bank to re-write an entire enterprise timesheet app and then I decide on using Websockets and WebGL. Of course I will blame the fact that the app doesn't work on any of the internal bank computers because "they run crappy IE8 and nobody should be running it anyway". Nevermind that 50% of the bank's computers have those constraints.

Sometimes, you have to face reality and write the best application that you can considering the current constraints that you presently have.

You know it takes talent to write a statement that is so completely wrong.

Others have addressed the JS point but Apple originally wanted developers to only build web apps and it took a lot of convincing to get them to change their mind. Also Apple has a lot of free apps. So this idea that Apple is somehow obsessed with monetizing apps is simply not true.

Not really... if you write an app that's native, then in-app purchases are controlled by Apple and they get a 30% cut of those sales. If you build an app using UIWebView then you could by pass those in-app purchases and get 100% of the sale.

ref: https://developer.apple.com/appstore/in-app-purchase/index.h...

I'm well aware that in app purchases exist. And absolutely nothing is stopping you from offering payments from a website in a UIWebView.

So not really sure what your point is ?

Wrong. Quoting from earlier post in this thread:

That's simply not true.

2) Yesterday they rejected yet another update for our app because it had a form where users could enter bonus codes.

> Apple doesn't want you building web apps they can't monetize.

This doesn't even make sense. You have it backwards.

If you run a web app in Safari, or save it as a web app in the home screen, it's going to run full-speed. If you wrap it in a UIWebView and sell it in the App Store (hello monetization) it's going to be slower.

If UIWebView is the cause, how come the Android Facebook app is also really slow? And to be honest, even surfing to mobile.facebook.com in Mobile Safari the app was really slow.

Reply on news.ycombinator.com