This article suggests that the new iteration of the Facebook app for iOS is written mainly with Web technologies and the fronted runs in a WebView, which explains why it sucks so much more than the previous version. Has anyone else noticed lots of really sluggish content loading, occasional hangs, mysteriously empty panes, etc? While the app is polished enough to seem native (kinda), it seems to be an argument that Web technologies are not yet ready to be an alternative to native UIKit development -- on iOS, at least.
Yep. I've spent some time investigating the possibility of using web views to replace some native Android/iPhone views (e.g. ListViews), and I assure you it's not easy. We didn't do anywhere near as much stuff as Facebook did (of I read that right, they bundle a version of WebKit with their app, and write client side compilers from JavaScript to native languages for phones with bad or no JavaScript environments). It's getting there, but web still hasn't quite arrived as the write once run everywhere platform. At least it's somewhat reassuring that Facebook still has lots of problems after spending many more hours on the mobile web than I have.
What really intrigues me is that average users feel the same way; it's not just us. Read the iPhone app reviews (current average: 2.0 stars). Ouch!
Facebook should hire back Joe Hewitt. His native app was fast and powerful, at the very least. Is employing one talented full-time iOS developer really too much to ask from a company as big as Facebook?
I went ahead and looked, and none of the complaints appeared obviously due to anything related to the current discussion.
The vast majority of them complain about "crashes" and problems logging in. The few complaints about it being "slow" appeared to be due to network issues, specifically related to getting new content from facebook. A handful report that content was attributed to the wrong user. Most of the remainder were just unsubstantial complaints. In the cases are something is actually mentioned, they are mostly about the lack of random features.
I've gone through many pages of comments on the app store reviews and I see no complaints that can be obviously attributed to the technology decisions discussed in the article.
Is employing one talented full-time iOS developer really too much to ask from a company as big as Facebook?
You might as well add the Python SDK to that. The "we don't have the resources" claim rings a little hollow, in that the company probably very likely has the resources, but thinks such things are strategically unimportant.
You may not have the experience of supporting a large web service, but I do. Believe me, supporting native apps for multiple platforms is not only a multimillion dollar money pit, but an integration nightmare. You end up building a web interface anyways then hacking together a ui in native code for every platform. The long term support structure can very quickly (exponentially) get out of hand.
I don't personally, but the people I work beside do, and it doesn't seem from talking and working with them that it's as bad as you suggest, no where close. Having launched successful apps on multiple platforms for a website, I've seen it done successfully.
Large saas, social media, and rich media delivery services have many times more complex factors than a simple content site. Why do you think Netflix, Facebook, many major banks and loan servicing institutions and most financial portals have chosen the web app strategy. It's not just because they are idiots and don't get it, it's that theyve recognized the unsupportable nature of multiple mobile platforms with such limited penetration.
Was referring to a "web site" akin to Facebook. A social network. Not merely a "content site." So, that point is moot.
> It's not just because they are idiots and don't get it
Didn't suggest otherwise. But your reasoning is flawed, I'd imagine. Your suggesting that they don't go native because smaller platforms have limited penetration? If so, that seems silly. Why not support the platforms with large penetration natively, and support the platforms with smaller penetration with a web app?
I'm not suggesting going native for every platform, but going native for none because you can't do them all is even more silly.
I was referring to the actual penetration of mobile users vs desktop browser users -- which is often on the order of 5% or less. This makes it a very expensive investment for such a minority of users.
Besides that still leaves you with Android and/or iOS plus web -- two to three times the development costs. This becomes very hard to justify for such a small percentage of total product users.
Not only that but it doesn't really sound that much easier. By the time you've pasted all this stuff together, custom JS scrolling lib etc and all, how much work are you really saving yourself?
But once they have set that up (which they have), they can build a feature once and deploy it on every mobile platform supported, iterate and fix things quickly without distribution delays (like 30-50% is on iOS?). It's not for everyone, and I don't like the Facebook iPhone app and I don't take this approach generally, but it works for Facebook because it works for most end-users.
Actually, while I'm still the first to say that web technologies are not ideal for apps UIs, the latest iteration (the one with the timeline) is working better than previous ones for me. Images or comments not loading or loading the wrong content are gone now.
Sure, it minimizes developer effort, but the end result of e.g. the iPhone app is very uninspiring and clunky. Compare it to a true native app like Path if this isn't immediately apparent to you.
(The use of the phrase "native goop" to describe the non-web parts seems telling. They don't seem focused on the end-user experience, but rather developer ease and (that old chimerical developer holy-grail) code reuse.)
There's a reason why this is important - it allows the 'native' app to stay up to date with the desktop web app. Yes, the Facebook native app is less usable and more clunky than it was before - on the other hand, it's feature-by-feature more up to date with the main site.
Is that a trade-off worth making? Perhaps, perhaps not - but in the very least, there's an argument to be made, right?
There's an argument to be made, but I'd still argue against it :) As a user, I'd much rather have a polished, pleasant to use native app that lagged behind a feature or two occasionally than unified junk. As others have pointed out on this thread, FB's gotta have the dev resources to do separate versions (though maybe not the kind of developers happy to be working on such a "boring" problem).
I think code reuse is often a chimerical holy-grail because in and of itself it is not a good thing; what matters is user experience, the amount of development work, how easy it is to fix bugs, &c. But developers still often obsess over code reuse, even at the expense of things that matter.
Often, code reuse leads to less bugs and less duplicated effort which leads to more time spent on important things like features and usability.
Except that, I don't disagree with anything else you said.
Fogbugz has their own custom compiler that generates code for the platform of their choice. Facebook has already written their own PHP->C++ compiler. I wouldn't be surprised if they have some team there working on some high-level infrastructure that lets them write UIs and code that gets compiled down to custom Objective-C/html+javascript/AndroidJava/etc...
That's the exact phrase that stuck out to me too. Reminds me of Java developers who exclusively use GWT to build web apps because they want to "abstract away" the browser component of the web app and write it like an applet or desktop app. It's no wonder that Facebook's native app is going downhill, because their developers think the web is king and native code is just clunky junk they're forced to deal with.
Somehow your point got lost when you use GWT as an example.
Alright, it's time to explain the whole situation one more time (sigh).
GWT is a platform people. It has tons of goodies from doing the CSS sprites without having to write a home-grown CSS sprites merge scripts up until optimizing JS code.
Any developers that don't know their stack is limited to write high quality code, regardless you use GWT or pure JS (don't give me crap that front-end developers worth their salt without pulling the "yeah, only the best ones").
I used to code in GWT and we all need to know DOM API, we all need to know CSS. But we don't need to know the various "Object Pattern" in JS. We don't need to re-invent the module system in JS (we use Java package).
The difference is that we can write testable code via unit-tests that we can run automatically using JUnit, integrated to our build systems, without having to jump through hoops and prepare a full-blown infrastructure like those that required by Selenium or WebDriver.
I feel like this is bound to happen anytime you're optimizing for ease of development rather than user experience. Same reason to beware of cross-platform UI frameworks.
But for Facebook, at this point perhaps their users are so entrenched that the app just has to work, however lackluster it may be. On the other hand, between this and the Python thing, I just can't understand why FB seems so stingy with its dev resources. I realize there is a lot of ground to cover but this is one of the biggest companies in tech we're talking about.
They aren't one of the biggest companies in tech. I believe they just barely passed 3,000 total employees recently. Compare that to Google, Microsoft and Yahoo who all have more than 10,000.
Facebook's goal is to penetrate as many markets as possible with the fewest lines of code.
Does this mean they don't give a shit about experience? No. It means they want to have a large reach without much maintenance. After that is accomplished, then they can worry about experience on a per device basis.
I don't believe it's correct to just dismiss this as garbage because the application is currently buggy. The entire idea of this approach is to improve the experience across all devices, but for now they are limited because they are still on the first step, implementation. Also note the slide that says "betting on the browser," meaning that Facebook is betting that issues between platforms will eventually fade away.
> Does this mean they don't give a shit about experience? No. It means they want to have a large reach without much maintenance. After that is accomplished, then they can worry about experience on a per device basis.
Facebook maybe able to get away with this, but almost every other developer and plenty of device makers will not get that second chance and will be dismissed by customers.
This is the same thing that happened to cross platform Smalltalk programmers (e.g. VW, VisualAge). They sure could target a lot of machines, but their programs always acted crappy and slow with poor UIs. This is ok when your "customers" are forced to use your program like a custom app for a business, but it sure doesn't work for others. Even Adobe runs into user hate for their non-native widgets and ignoring platform conventions.
Most non-technical consumers are good about getting a feel for how things work on a platform (e.g. ctrl-c for copy on windows, smooth scrolling, metro on WP7). This leads to a disconnect when an app behaves differently. They may not be able to express the problem, but they will certainly notice it.
To me, there's pros/cons to this approach with the perspective of making it as EASY as possible for developers to ship across all types of hardware (which is great). But the con seems so big to me: the end-user experience is so slow (iPhone and Android) that when you think of "Facebook for Mobile", you think "Maybe I can wait to access FB on my iPad or back on my laptop when I'm home?"
All of the native apps that I've seen, played with and analyzed, speed = to some the best experiences for a user. I mean, doesn't a FB user want exactly that when they check the Newsfeed? For instance, today, I turned off 4G and moved to 3G on my Android, checked the FB app and it crawled. It junked new screen loads, comments, liking, etc. Switching over to 4G made (some of) the pain go away.
developer-centric vs. user centric approach in effect.
if you don't care about utilizing every inch of platform functionalities and performance to achieve a great user experience - why bother with such meta-apps at all? just let your user place a bookmark on the home screen and be done with it. save even more developer effort.
from a pure user perspective, this approach can be summed up pretty simply: "half-assed".
The new Facebook mobile site is gorgeous and is faster than the native app on my Galaxy Nexus (for whatever reason the FB app takes ages to load, and ages longer to load data after it gets off a white screen). It's so nice in the browser and it's every bit as functional as the proper "app".
Sadly, they're doing some weird user agent sniffing and are giving me the WAP site currently and are also telling me I have a Droid Bionic, so I'm not 100% sure what's up with that.
After reading the comments here, maybe my experience is so pleasant due to the power of the Nexus and the tuning in the 4.0 browser.
