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.

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.

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.

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.

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.

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.

Because it's their app store.

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

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