13 ms·
Facebook Plans to Speed Up its iPhone App
- glhaynes 14y agoExcellent news. I know it says that the design isn't really changing, but I hope that a few things get cleaned up, too — say, like the way comments views sometimes show Likes and sometimes don't. That one's baffling to me.
- anuraj 14y agoThere is no excuse for using HTML5 when the native platform offers you so much more and the user base is substantial. Only cheapos try to get away with it. Web is dead, welcome to app economy!
- kombine 14y agoIt's not that the web is dead, but the technology stack on the front end side of things is crappy. There's a lot of hype about front end development of course(yes I expect the downvoting by posting it here on HN), but it is not that the tools are superior, but rather because of the necessity of the web.
- anuraj 14y agoI agree .. what I meant when I said 'web is dead' is the new web is made of services accessed through apps. Crappy front end technology and mega monolith browser are no longer required.
- ceejayoz 14y ago> There is no excuse for using HTML5 when the native platform offers you so much more and the user base is substantial. Sure there is - the ability to push rapid updates to the UI, without needing to go through the Apple review process each time.
- flatline3 14y agoIt's unlikely that the cost of the review system outweighs the costs involved in going non-native for most use cases.
- marknutter 14y agoAre you trolling? If you go native you have to write and maintain a different codebase for ever platform you want to support. With HTML5 you can update code without going through Apple's lengthy update process, and you can share that code across as many platforms as you like. HTML5 also allows you to tap into a much wider pool of developers.
- flatline3 14y agoNone of what you covered provides any advantage whatsoever to your users. It's all about making web developers happy.
- cluda01 14y agoI think that this is one of those instances where the needs of the company were prioritized over the needs of the user. Not to say this isn't uncommon in any industry, however, in prioritizing maintenance cost minimization they made the user experience markedly worse for the end user.
- marknutter 14y agoIn the case where you only have the resources to make an iOS version of your app, you certainly are thinking of your users when you use a cross-platform solution so that Android is supported.
- duaneb 14y agoPerhaps, but the better thing to do would be to write native apps for both users.
- anuraj 14y agoDo you think it matters to a company with a substantial mobile user base - and tons of money? HTML5 is for cheapos.
- marknutter 14y ago
- pjmlp 14y agoAgreed 100%! HTML is for documents, not Frankenstein coded applications.
- RoyceFullerton 14y agoI think the bigger problem is still iOS's webview from within native apps, not that it has to pull most of the assets from the server. If you go to m.facebook.com in Safari it is much faster than using the native application and most of it is the same HTML5 code that is running within the webview of the native app. The twitter app is also painfully slow when clicking a link and it opens up the resulting page in a webview.
- wonnage 14y agoI've noticed this as well, and it seems to be a recent phenomenon - it's gotten to the point where I just open links in Safari when possible. Any idea why?
- RoyceFullerton 14y agoOne reason: "...performance of UIWebViews is less than in mobile Safari. This has a lot to do with the absence of the new Nitro JavaScript engine in UIWebViews, apparently for security reasons. I ran some tests on my iPhone 4 with iOS 5.1.1, the JavaScript benchmark Sunspider running in Mobile Safari was 3 x as fast as running in a native app with a UIWebView. Also, to communicate from the UIWebView to the native app, a JavaScript bridge is needed. This is tricky stuff, slow and not really thread safe." http://blog.mobtest.com/2012/05/heres-why-the-facebook-ios-app-is-so-bad-uiwebviews-and-no-nitro/ http://blog.mobtest.com/2012/05/heres-why-the-facebook-ios-a...
- raganwald 14y agoThis. IIRC, the reason is that the Nitro engine compiles directly to native code, which is then executed. This requires writing to memory as data and then executing the data. However, Apple doesn’t allow third-party applications to execute data for any reason. This would violate security policies. Thus, any and all third-party scripting—be it JavaScript in a Webkit view or something else—must be interpreted. The best a third-party application can do is compile to byte codes and then interpret the byte codes.
- deleted 14y ago[deleted]
- Timothee 14y ago"the company had chosen to build its apps predominantly using HTML5 so that it could take advantage of reusing programming code across multiple mobile platforms" This is certainly a benefit, but at Facebook's scale, it made sense to dedicate engineering efforts to have the best experience on the iPhone. I'm glad they're finally going in this direction. However, I think that one of the benefit that is not mention here is the easiness to change the UI at any point, which they've been doing all the time. That being said, I would think that it would still be possible to modify a native UI without going through an App Store review, since more or less everything can be created and customized programmatically: so you can send some kind of file that describe the UI tweak. Surely, it can become a mess pretty fast, but it's an option.
- marknutter 14y agoThat would violate Apple's terms. Apple allows updating of HTML/JS/CSS without going through the update process but not the updating or changing of any native code.
- Timothee 14y agoI'm not saying changing the native code, but with the same native code building a different interface from some kind of description file that could be updated remotely. Maybe Apple would not be happy about that, but I don't know if they'd be able to tell you're going to do that during the review process.
- reddit_clone 14y agoYou still can not dynamically download anything that needs to be 'interpreted' on the device application. Your 'UI Description' file most likely will fall under that category.
- pohl 14y agoNo, that would be ludicrous. It would be impossible to fill a UITableView with data from a server if that were the case. The rule is really about linking interpreters into an app and then having them run code fetched over the net.
- lbarrow 14y agoJeff Atwood said it best: performance is a feature. http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.html http://www.codinghorror.com/blog/2011/06/performance-is-a-fe...
- cpeterso 14y agoUnless you are Chrome for iOS.
- zaidf 14y agoI have tonnes of emails saved in my iPhone Notes app of people I met, tried to unsuccessfully find on facebook using the app, and later found them using the facebook.com from a normal computer. I'm starting to feel that facebook purposely broke its iPhone app to limit use. There is simply no other explanation why the most basic feature of finding and adding a new friend would be so terribly broken.
- kevincennis 14y agoFacebook's current app isn't slow because it's written predominantly in HTML5. It's slow because it takes forever to retrieve assets from their servers. There's nothing magical about Objective-C that's going make the HTTP requests quicker. The whole "native vs web view" performance debate is about things like animations and scrolling and rendering, not about the speed of retrieving assets from a remote server. And that's what's terrible about the current iOS app.
- spaghetti 14y agoI agree. Sometimes it's fun to think of the limiting case: all data on the device locally and displayed in the simplest viewController. Then step towards the real app and you most likely come to your conclusion. Only corner case I can think of is the previous engineers went overboard on the networking code on the device. In theory the facebook apis are plenty fast but the networking code on the device is a c or c++ mess and the current engineers are using higher level objective-c libraries.
- jcromartie 14y agoUser perceptions play into performance more than you'd think. If the HTML app can't scroll or transition smoothly, or it's spinning up new WebViews and you have to wait (there is an inherent delay in loading any content in a new UIWebView), then users will say it's slow. Not to mention memory usage of HTML elements, and managing that whole mess (the "rococo pandemonium" of HTML CSS and JavaScript, as Tim Bray put it) of objects in (usually) one giant container... I've never found a situation where a WebView-based app is better than native.
- marknutter 14y agoDownload LinkedIn's iPad app. It's a situation where a WebView-based app is as good as native.
- devinfoley 14y agoSorry, but I'd disagree. The transitions aren't very smooth and often times you're faced with a blank screen while waiting for assets to load. I was actually very hopeful that the app would feel as good as native after I'd read about it, but I was disappointed.
- programminggeek 14y agoHaving done some PhoneGap dev lately, it is possible to make a great app using HTML5, but to make it perform well and have the right look and feel requires a ton of work, and the tooling around it still leaves something to be desired, especially on the UI side. Libraries like Kendo UI or Sencha Mobile help a lot, but if I were Facebook, I'd spend the dev time to do it right and make it awesome. Whether that means optimizing the crap out of their HTML 5 or going native is a judgement call.
- jcromartie 14y agoI've had a hard time finding a really convincing "great app" that is largely HTML5. Can you mention what it was?
- inerte 14y agoLinkedin's app is mostly web tech. While I personally have used it a few times, I think most people enjoy it.
- jcromartie 14y agoLinkedIn's app on the iPhone has a lot of native views. There are some telltale signs that indiciate native components make up everything but the "leaf nodes" of the app's UX.
- mehrzad 14y agoHe/she meant the iPad app.
- marknutter 14y agoLinkedin's mobile app is a hybrid, but their iPad app is 100% HTML5 and runs beautifully. I'm also pretty sure that Google's Gmail iPhone app is 100% html5 as well as I've seen it re-render the entire interface occasionally as if it were an app in a UIWebView.
- MattRogish 14y agoI think the biggest problem here is that iOS/Android WebViews are incredibly sensitive to memory and CPU, and if you just take an otherwise amazing desktop or backend developer and throw them in mobile webview, you're setting them up for failure. The webview is a whole different ball of wax (my last gig was PhoneGap development on iOS and Android) and if you are not, from day one, incredibly focused on performance (CPU and Memory) you're gonna have a bad time. Knowing what I know about making PhoneGap apps, there's nothing inherent in what FB is doing that the WebView is incapable of doing. It's just really hard to get it right, much harder than a native app.
- evilduck 14y agoHow much alike or different are the tweaks required for optimizing for webviews between platforms?
- marknutter 14y agoNo harder than getting it right in native code on 3 different platforms.
- MattRogish 14y agoDepends on what you mean by "hard". Although it's time consuming to learn different platforms, there are not a whole lot of gotchas you have to discover on your own. It's all been done before and well documented. PhoneGap development is hard inasmuch as there are tons of gotchas you don't know about and haven't been clearly and extensively documented.