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.
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.
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.
"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.
> 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.
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.
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.
I didn't make it out to be simple or complicated. They valued their sense of developer efficiency over user experience.