A Faster Facebook for iOS
newsroom.fb.com
newsroom.fb.com
Given the resources available to them, switching to UIWebView was a ridiculous trade-off. I'm glad to see they rectified this decision.
The lesson to be learned is this: at the end of the day, it's the product and user experience that matters. If you sacrifice product quality for some notion of engineering perfectionism -- whatever it might be -- you're not doing your job as a professional engineer.
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.
I didn't make it out to be simple or complicated. They valued their sense of developer efficiency over user experience.
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.
Sacrificing their user experience for rapid updates is putting a sense of engineering efficiency ahead of user experience.
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.
Here's a good talk on the subject:
If this is a significant concern to you, then prompt or enforce upgrades in your application.
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.
As it currently stands, as per Apple's published status, 95% of applications are approved within 8 days.
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.
"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.
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.
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.
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.
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.
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 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.
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?
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.
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.
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...
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.
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.
Pure conjecture on my part.
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.
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.
ref: https://developer.apple.com/appstore/in-app-purchase/index.h...
So not really sure what your point is ?
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.
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.
It's basic organizational politics. Any organization will have difficulty adapting to a completely different platform, and management will attempt to reframe the problem to fit within the bounds of their existing organization.
In this case, a traditionally web-focused organization attempted to co-opt mobile development into their existing organizational hierarchy by reframing the problem. It wasn't until persistent external pressure was applied (user complaint, blatant failure obvious to external management) that they were forced to accede ground.
What I forgot to take into account is that Facebook isn't really led by product management. Could FB's PMs force a change like that, after development has built it? I don't know.
This isn't a trade-off Facebook needed to make. Whether it's a trade-off your organization needs to make depends on your resource availability, skills, and target market. However, there's no value in dressing up the trade-off as anything other than a trade-off.
The target market and product factors into the question of resource allocation. Nest would not have made such a splash if they decided to skip user experience and focus on fast feature roll-out, and Dropbox would not have succeeded to nearly the same degree (if at all) without first-rate native user experience.
You're making a case for why Dropbox didn't have to go through the time-to-market-driven experimentation Facebook did. That is indeed an advantage to being Dropbox. It isn't a very good indictment of Facebook's strategy.
It's not as if mobile was unproven at the time they decided to switch away from their native mobile client.
- It's not easy because they have a historically web-centric organization.
- They have a web-centric organization because they had not invested in building a broader engineering team.
- They did not invest in building a broader engineering team because they have a web-centric organization, so they stuck with web technologies.
Their engineering management put appeasement of their existing web-centric engineering organization ahead of user-experience.
I'm interested in your supporting argument for other governing factors or software as a social activity, and how that relates to making engineering choices that sacrifice product quality for some notion of engineering perfectionism.
- Facebook fails to deliver features through the superior approach ...
- ... but does deliver them through a lesser approach ...
.. then the mechanism they use to deliver the features provides a better user experience, because it has the features, thus justifying the choice to deliver them in the through a subpar mechanism?
That's ... circular. Painfully so.
It would be better for the user experience if they delivered features with the highest level of quality they're capable of providing, and that's demonstrably not inside of a UIWebView.
Sorry, but how do you know this? Also, politics in of itself is rarely the real reason why decisions are made. Someone who seeks to gain benefit by making decision (which is deemed therefore political) can certainly be a reason. So, I'd be curious as to what benefit some individual or individuals sought to gain by making this decision.
http://www.readwriteweb.com/archives/redux_how_facebook_mobi...
> It's not difficult to determine
I'm really curious as to who benefits from this internally at FB? Seriously, I'm having a hard time determining who?
Pretend that Facebook's hitherto web-centric engineering team is external to Facebook -- they're a consultancy. Now imagine Facebook comes to them and says: We want a mobile application. Who benefits if they manage to convince Facebook to pay for them to produce a web application?
Let's reel it back to reality. How do people inside an organization benefit if they expand their area of purview, responsibility, and increase their value to the organization? Likewise, what power dynamics come into play when a new, potentially distinct engineering team garners additional purview, responsibility, outside of your domain, skills, or control?
That is correct in theory, but falls on the face with facebook and others. Unless you literally just mean "more features", and not improving what they're making. E.g. paying for promoted updates so friends see them in their cluttered stream surely is Yet Another Feature, but is it good? I guess it depends on who the market is, here..
If the thing were written in spaghetti code, it would at least mean people would have some time to think in between, or even manage to get out of their 20s before their redefine how grandma keeps in touch.
Still, I'm happy that they improved how their crappy soulless product runs on another crappy soulless product, it keeps them off the street.
FB users don't use it because of the slick interfaces, they use it because of network effects. For that type of business, adding features fast (to create more lock-in) > focusing on great UI.
I'd be interested in your supporting arguments, especially in light of this investment they just made entirely for UX reasons.
No, of course not. What they invest in is irrelevant. Only results matter.
Just look at Mootothemax's comment further down the thread. Poor UI wasn't causing people to not use FB.
Valley execs are probably the most susceptible group to falling in line with the echo chamber. Currently the chamber is reverberating with 'APPLE GOOD!'.
Now that they've had the opportunity to fully A/B test their app, and they have a good sense of what users find valuable (based on this news story, the news feed and photos), it makes sense to switch to a more performant native app.
With the benefit of hindsight the move was biased by ideology. The takeaway should be pragmatism over ideology and intellectual aesthetics, not the super-prioritisation of UX.
Note that around the same time, the Financial Times jumped off iOS and went pure HTML5. For them this turned out to be a good move - it is a delight to use.
Let this be a lesson to us all: when putting user experience as the first priority, the nirvana of writing your UI once in HTML and having it work universally still isn't there.
Are you sure? It's better, yes, but it's not a model of UX and on an iPad it seems not much thought was taken into making it a truly universal app. There's a lot of unused space and everything is too large.
The Google+ app with its combo of Path and Flipboard is a much better model to follow. Fast, and it takes advantage of the screen size in both versions.
Some pages do load slightly quicker though, so good job on that. :)
I wouldn't go this far. Sure, the CoreData backend and table view controller implementation is beautiful and awesome. However, the root level navigation could be improved. The pseudo-popovers for messages, notifications, and friend requests is inconsistent with the rest of iOS, even though it might be consistent with past versions of the application and the versions of Facebook on other platforms.
And it will never be. HTML just sucks for application development.
Why on earth exchange the benefits of using the hardware resources properly for the mess that HTML+CSS+JavaScript is? To mess the customer's experience?
Don't be afraid of touching C, C++ or any other language with native code compilers and at most rewrite the UI part. Or shell out some money for tools like Mono or similar.
Although I am forced to code Web applications at work, I am a firm believer that web should only be used for communication protocols and documents as such.
Like you I write web apps, but I'm old enough/lucky enough to have had some other experiences, and to be quite honest I find even Gtk+ is more pleasant overall than the MV* framework of the month. That we have folks now trying to write AutoCAD or Photoshop in JavaScript just like a loss for our industry.
My first programming languages were Spectrum BASIC and Z80 Assembly shortly thereafter.
At the same time, having watched my friends swear at Facebook on their smartphones and yet continue to use the app, day-in, day-out, maybe Facebook are more clever than I give them credit for; I haven't seen people move elsewhere because of the problems.
You can measure the elasticity by adding anything detracting from user experience (i.e. wasting your user's time when you could automate solutions (e.g. cragislist spam apartment listings you spend 20 hours sorting through manually) or speed up your site (e.g. social website slowness/downtime/high variance in page load times)). You've found some elastic jumps when users start leaving because you're wasting more and more of their time.
People only have so many minutes of focusable attention every day. It's precious and irreplaceable. Don't waste your user's limiting waking attention with errors, manual aggregations, confusions, slowness, or "oops this failed try again and it may work or it may not work and you'll have to try again and it still won't work."
They are getting dragged into a better UX. They aren't pushing for it.
Despite that, the Android FB app, and most other WebView-based apps on both platforms, tend (IMHO) to be rather dog-slow and buggy anyway. The App Store in iOS6 is one as well, and it shows.
http://newsroom.fb.com/ImageLibrary/detail.aspx?MediaDetails...
Some are just ugly for example ecards are all screwed up. Others could seriously piss some people off. Quicky scrolling through my feed I saw two imagines that were originally of a female friend standing somewhere, taken in portrait orientation. On the new feed they appear as zoomed in "body shots" with the head and below the knees cut off.
This sort of thing is especially odd given their face recognition on every photo. Surely they could have it center over the faces.
(down at time of writing)
Some time after a terrible webapp was released. Not quite sure why someone else there couldn't take over maintenance of it.
They were appearing for me in the old iOS app & are only be shown every 150 or so (at the moment in the tests they are performing) which has been confirmed by Facebook's CFO David Ebersman who said Facebook are "being very careful about the volume of sponsored stories in the news feed because it’s so core to the user experience."
http://www.netmarketshare.com/operating-system-market-share....
It definitely needs to be rewritten for Android.
[1] The application doesn't work well in landscape mode
[2] No feature to edit comments, this was existing as a feature in the previous app.
If the iOS app is more responsive, users tap on more ads, and Facebook makes more money.