Forgot your password?
typodupeerror
Facebook Apple

Facebook iOS App Ditching HTML5 For ObjectiveC 240

Posted by samzenpus
from the goodbye-5 dept.
Wrath0fb0b writes "The New York Times reports that Facebook is overhauling their iOS App to ditch their HTML5 based UI for a native ObjectiveC one. This is an about face from their position a few months ago in which FB said HTML5 would allow them to write once run anywhere. While WORA certainly has a lot of appeal for both programmers (due to desire not to duplicate effort) and management alike (due to desire not to pay programmers to duplicate effort), the large number of negative reviews that FB for iOS has illustrate that this approach is not without drawbacks. No matter how the new app is received, this is more fuel on the native vs. web-app fire."
This discussion has been archived. No new comments can be posted.

Facebook iOS App Ditching HTML5 For ObjectiveC

Comments Filter:
  • by xtal (49134) on Thursday June 28, 2012 @02:28PM (#40482819)

    Native code is _always_ better.

    • by jythie (914043) on Thursday June 28, 2012 @02:32PM (#40482923)
      Well, 'better' is relative. The question is often 'is it better enough to justify the decreased portability and increased cost of supporting multiple platforms?' Sometimes the answer is yes, sometimes the answer is no.. sounds like the answered wrong in this case.
      • by xtal (49134) on Thursday June 28, 2012 @02:35PM (#40483009)

        Better, in the sense that cost considerations aside, technically, it is superior almost every time.

        In reality, your logic and communication bits should be abstracted anyway - isn't that the hallmark of good programming practice? ..and even then there's performance tradeoffs.

        Write it all in assembly and get off my lawn. :)

        • In reality, your logic and communication bits should be abstracted anyway - isn't that the hallmark of good programming practice?

          I agree in principle [pineight.com]. However, sharing components among versions of an application for different platforms works only if all the platforms can run programs written in the same language, and in practice, there are a lot of platform pairs that lack a shared language. For example, how do you share a component between an application for Windows Phone 7, which runs only C# and other languages that compile to verifiably type-safe CIL and do not use the DLR, and the corresponding component for iOS, which runs Obj

          • It's called web services, that return a standard format like JSON, or XML. That's how we do it at my work. Currently I'm working on a project where I serialize perl hashes and arrays into XML, and pass them via a REST based web service to a C# system that serializes it into a DataTable for display in some .NET controls. C# can deserialize the DataTables back into XML, post it to the REST based web service to where it gets re-serialized into hashes and arrays for various CRUD type actions.

        • Better, in the sense that cost considerations aside...

          Yep, that one's usually waaay down the list ;)

          Write it all in assembly and get off my lawn. :)

          Now, real programmers... [xkcd.com]

        • by BZ (40346)

          Write it all in assembly, and more likely than not for a large system you get http://en.wikipedia.org/wiki/Therac-25 [wikipedia.org]

    • Re:Ask any grey beard. Native code is _always_ better.

      Ask any game developer, well those working on anything beyond the simple casual game segment.

    • by Kenja (541830) on Thursday June 28, 2012 @02:36PM (#40483027)
      What if I build an OS with a native API that runs on the souls of war orphans, but it also has a web browser? What then Mr Beard?
    • by roc97007 (608802)

      And while we're on the subject, get off my lawn!

    • Not if you don't own that device.

    • by orlanz (882574)

      The only thing true about this statement is that is will _always_ resolve to be "False". Or 0 for you grey beards.

    • you'd have to be a fucking moron to think html5 was ever "write once run anywhere."
    • by gl4ss (559668)

      in mobiles, since 2003 or so there has been certain developer marketing folk pushing for all-html/js solutions as the magic bullet that will make development cheaper by not having to need experts(who know what the device can do and how) and that it's just a matter of mapping javascript api's.

      so after that mobile developers have been constantly bombarded with propaganda that in 1-2 years there's going to be so good js engines and renderers that it'll as good as native. an example about this is nokias web run

    • Nothing is always the best solution for every scenario. but I would expect that sort of answer form a senile old man or grey beard if you prefer.
    • by Simon Brooke (45012) <stillyet@googlemail.com> on Friday June 29, 2012 @05:35AM (#40491557) Homepage Journal

      Speaking as a greybeard (both literally and as a thirty-year veteran of this industry), bullshit. When I was young there were still a few people around who could write software by writing opcodes out in pencil on the train home and have them work first time without bugs (Chris Burton, who helped build the Manchester Mark One, I'm thinking of you), but most people can't. And most people cannot write C well enough to outperform the software that the same person can write in a decent high level language.

      Virtually no-one, now, can write anything sophisticated or complex in opcodes. Virtually no-one can do it even in assembler (yes, I know you did a little assembler project in CS101, but that really doesn't count). Yes, I know that a few rare geniuses can write exceedingly efficient fault free code in C or C++. Most complex programs written in C or C++, however, are too expensive in debugging and maintenance costs to outweigh any very small performance advantages they might have over high level languiages. Grow up, and live in the modern age. Toggling switches on the console, teletypes, punchcards, assembler and C are all history.

      (Mind you, of course, there is some exceedingly bloated code around. I recently installed, on Windows, a Bluetooth device driver that was 60 Megabytes, which I found unbelievable... the fact that we have high level languages is no excuse for bloat or sloppy engineering practices.)

  • WORA.... (Score:3, Insightful)

    by jythie (914043) on Thursday June 28, 2012 @02:30PM (#40482861)
    Has appeal in theory (and sometimes practice); looking great on paper, but it is easy to get swept up in enthusiasm for the concept and not really think though how applicable it is to any given environment.... and even when it does work it is pretty rare for something to truly 'work anywhere' in the real world.
    • Re:WORA.... (Score:5, Interesting)

      by steelfood (895457) on Thursday June 28, 2012 @02:52PM (#40483459)

      The problem with WORA is that the interpreter has to both be present and consistent across all environments. It worked for Java, because Sun wrote all of the initial JVMs, and every such JVM conforms to the same spec. Even then, Java was for the desktop/server. Sun had to change to a new spec for mobile, which they recognized was a completely different playing field. The scope of WORA that Facebook wanted to apply wouldn't have worked even they were using Java.

      Something as massive and as fractured as HTML5 where everybody "supporting" it has actually only implemented a portion of the standard and not the full thing, it's virtually impossible to get right. Not only this, but there needs to be a layer that changes elements based on device capability and type. This layer does not exist in the standard. Thus, WORA cannot and does not work for HTML5.

      And to be honest, it may never work.

      • by dgatwood (11270)

        In Facebook's case, the problem with WORA is much larger than that. Because the interpreter must be consistent across all environments, it is difficult to take maximum advantage of features that do not exist everywhere. Not just the sorts of device capabilities that impact HTML5, e.g. screen size, but also device features, e.g. address book, built-in camera, etc. that cannot be taken advantage of from within a web app.

        As a result of this, the Facebook app was never WORA. It was a custom, probably iOS-spe

    • by bjwest (14070)

      Why does WORA have to be a scripting type language? How about a WORA complied language? I see no problem with having to recompile an application for different platforms. The gaming industry should've done this years ago for cross-platform games. One language, write once run anywhere with a simple recompile. I know it's been tried in the past and screwed up by (usually MS) someone wanting their own standard to be THE standard, but come on people, this is the 21st frigging century. It's well within our

  • by blahbooboo (839709) on Thursday June 28, 2012 @02:32PM (#40482915)

    Weird, their web browser app is what I use since their app sucks. Guess this is why?

  • C'mon (Score:5, Insightful)

    by tthomas48 (180798) on Thursday June 28, 2012 @02:32PM (#40482935) Homepage

    They're having trouble returning a few hundred lines of text and 10 photos. Methinks HTML rendering speed is not even remotely their problem.

    • No. (Score:2, Insightful)

      by Anonymous Coward

      UI Rendering speed is exactly the same for native code and html elements. The reason is, guess what browsers do to show you lists, buttons, drop down boxes, etc?? They use *NATIVE* UI elements. It is plainly obvious you understand nothing on this topic.

      The issue is UI *latency*. HTML based UI cause increased round trips from mobile devices to their data-centers creates a terrible experience for users when compared to native apps. Mobile devices already are worse off when it comes to network latency, and th

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        at-least it would look the same everywhere.

        And here we have the problem. Web pages are not supposed to look the same everywhere.
        Yet PHBs trying to achieve that are what cause literally every problem in Web standardization.

        Just serve me the information, and I'll render it how I like.
        Quit obsessing about controlling my user agent!

      • by dgatwood (11270)

        UI Rendering speed is exactly the same for native code and html elements. The reason is, guess what browsers do to show you lists, buttons, drop down boxes, etc?? They use *NATIVE* UI elements.

        Although that is pedantically true if you did all your own UI drawing using programmatic calls and did all your own layout work using something as complicated as the DOM and CSS, in practice, you're completely and totally wrong. The UI layout engine used for a native app is orders of magnitude faster. And this is w

  • Good start (Score:5, Insightful)

    by MrEricSir (398214) on Thursday June 28, 2012 @02:34PM (#40482991) Homepage

    That's good, but I don't think it's fair to blame the poor quality of Facebook's app entirely on HTML5. For example, the app will occasionally chew through hundreds of megs of space, crash randomly, or even navigate to the wrong page when you click a link. Pretty glaring bugs that even the greenest QA testers would have noticed.

    At some point you have to blame management for not spending the time for proper testing and bug fixes. It *should* be a fairly straightforward app no matter how it was written.

    • Re: (Score:2, Insightful)

      by roc97007 (608802)

      That's good, but I don't think it's fair to blame the poor quality of Facebook's app entirely on HTML5. For example, the app will occasionally chew through hundreds of megs of space, crash randomly, or even navigate to the wrong page when you click a link. Pretty glaring bugs that even the greenest QA testers would have noticed.

      At some point you have to blame management for not spending the time for proper testing and bug fixes. It *should* be a fairly straightforward app no matter how it was written.

      And (this is the point, really) not just on IOS! Blaming the problems on html 5 and changing to old crufty Objective C sounds like a rationalization. An excuse used by executives to board members who don't know any better.

      • by Dog-Cow (21281)

        Why would anyone use old crufty ObjC when there's a nice modern runtime and language to use instead?

        Oh, I get it... you're stuck in 1995. Hint: NextStep is history!

    • ....and he departed FB or said he was done with iPhone development or some other small-scale hubris?

      Part of me thinks that FB doesn't really *care* if the iOS app works, they just want to know what platforms you use FB on and if they see regular use from an iDevice, they know that you fit in a specific demographic bucket of "iPhone owner".

      • by alen (225700)

        yes, he used to work for Mozilla. explains everything

        he thought he was da sh1t and the app was always buggy

    • by homb (82455)

      The problem is that the Facebook engineers went too far.
      In their hubris (not necessarily generally bad) they thought that they could literally create a very deep interface between their html code and the underlying native APIs. Essentially abstracting the underlying native APIs with a code interpreter that would allow their servers to send the same html to any device, and some additional stuff for those that had other features.
      As usual, they started simple and everything worked, but then over a few months t

  • by benjfowler (239527) on Thursday June 28, 2012 @02:37PM (#40483055)

    If it were purely about performance, then they could just use web services to grab the data they needed, style it on the client side and run it in an HTML control. How would drawing content using a native app help performance if the data requirements are the same -- rendering HTML isn't *THAT* slow on iOS, is it?

    And with a web app, they have far more control over QA and the release process, and can potentially turn around minor updates much faster than if they had to jump through the App Store release process.

    OTOH, they think they have a problem, then good for them. The current client has been buggy for me for quite a while, with navigation buttons sending me to random parts of the application -- they clearly have QA issues that aren't going to be helped (and likely will be made worse) by an app rewrite.

    • by Bogtha (906264)

      rendering HTML isn't *THAT* slow on iOS, is it?

      It depends on exactly what it is you are doing, but generally speaking, native is usually noticeably faster. Even when rendering local content with a web view, you can usually see redraws and flickering where there wouldn't be any if you used native controls. You have to remember that these days, rendering a web page is actually a huge task, and this is a mobile platform, not a desktop PC. Mobile computing has come a long way in the past five years, but

  • by PolygamousRanchKid (1290638) on Thursday June 28, 2012 @02:40PM (#40483155)

    Debug Everywhere . . .

  • by Jake73 (306340) on Thursday June 28, 2012 @02:45PM (#40483299) Homepage

    They are a multi-billion dollar company dealing with an app running on one of (if not the) most relevant and widely-used smartphones in the market. They should dedicate a team specifically for the iPhone. And if Apple changes the API every week, they would be wise to rewrite the app every week just to maintain that market.

    I don't care for Facebook and have my issues with Apple, but this is just a business decision on ROI.

  • what what what? (Score:2, Insightful)

    by roc97007 (608802)

    But... isn't html 5 the latest and coolest thing, and Objective-C some really old thing that Apple inherited from medieval times?

    And and... hang on... wasn't the coolness of html 5 the excuse for Apple not supporting some old and crufty thing called Flash?

    • Re: (Score:3, Insightful)

      by Dynedain (141758)

      This is just Facebook trying to blame their shoddy implementation on someone else.

      None of the bugs and issues reported by users are HTML5 caused problems.

      • by roc97007 (608802)

        This is just Facebook trying to blame their shoddy implementation on someone else.

        None of the bugs and issues reported by users are HTML5 caused problems.

        (You are absolutely correct. I was being ironic.)

    • by jbolden (176878)

      The coolness of HTML5 video (h.264), was one of the many reasons. And that works great on the iPhone.

    • by Vellmont (569020)

      FB can afford to piss away money on a proprietary app now that they're a multi-billion dollar company. The vast majority of companies can't. I just don't see a huge resurgence of native apps replacing web functionality. Very few companies have the resources to develop for multiple platforms like that, and you really can't afford to just ignore android, or whatever else comes out into the mobile world in 5 years.

  • Write once, run anywhere? Didn't they say that about Fortran? Write it all in Fortran and get off my lawn.

    • by Old97 (1341297)
      Oh you kids! I bet you are talking about some fancy modern FORTRAN like FORTRAN 77 or later. When I was a young coding buckaroo all we had was FORTRAN 66. Not that was definitely not portable. It wasn't even complete. Every vendor had to complete the language with their own extensions in order to do any thing with memory or I/O. You had it easy.
  • Facebook is google's enemy
    they are frenemies with Apple

    why support HTML5 which also supports your enemy when you could make your frenemie's platform "better" with a native app and hurt your enemy

  • Android version (Score:5, Informative)

    by gauauu (649169) on Thursday June 28, 2012 @03:01PM (#40483657)

    Does the Android version use HTML5 as well? Because it is beyond horrible. I can't figure out why the app would actually be SLOWER and harder to deal with than viewing their site on a browser, but somehow they have managed it.

    • My guess is that the problem is on Facebook's end and Michael Stonebreaker was on to something when he critiqued Facebook's database architecture: http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/ [gigaom.com]

      So to compensate for some of those issues, they have to go to a more responsive UI.

      • An unresponsive UI isn't behind stuff like the app's apparent inability to follow outside HTML links without throwing errors, as happens all the time on the Android version for me. It really is one of the poorest excuses for an app that I've ever used.
    • by ArsonSmith (13997)

      The only reason i have the facebook app installed is it's integration to the share button in gallery/photos. If I'm going to browse the site I use the browser.

  • As long as they... (Score:4, Interesting)

    by Grizzley9 (1407005) on Thursday June 28, 2012 @03:11PM (#40483857)
    fix what's broken and allow the same functionality as the website. I hate it when apps like Pandora, FB, or even G+ or any others that have an app and a website where the website gives you many more options. They only give you the basic experience on the mobile app and am still tied to a computer for doing anything more than basic.
  • But will it help? (Score:5, Interesting)

    by FellowConspirator (882908) on Thursday June 28, 2012 @03:13PM (#40483891)

    It seems to me that the Facebook app's issues are not so much about HTML5 performance, but rather the way that they handle transactions with their servers. The network performance of the app is atrocious. Look at the traffic of the iOS app and compare it to the Facebook mobile website. How many hundreds of XMLHTTPRequests do you think it should take to render a page?

    There's nothing inherently wrong with the HTML5, it's their ludicrous network activity that kills the app.

  • Its just that using HTML to build "native" apps for iOS has been proven to be poor over and over again.

    Apple just does not want ANY competitive technology to shine on iOS. They dropped Flash not due to "performance and battery" issues, but simply put that Flash would eat away at Apple's walled garden. Building HTML apps that can be easily ported to other platforms wasn't going to be something that worked better then native iOS apps built for the walled garden.

    It comes down to whether you want to be cheap

    • They dropped Flash not due to "performance and battery" issues, but simply put that Flash would eat away at Apple's walled garden.

      Having experienced Flash on Android, I think you're mistaken. And the fact that Adobe basically gave up on making it useable on mobile devices supports Apple's stated position.

  • Sure, many find it useful anyway, but theirs is not a technological problem.

  • by Dixie_Flatline (5077) <vincent.jan.goh@gmTIGERail.com minus cat> on Thursday June 28, 2012 @03:53PM (#40484687) Homepage

    Given that Apple is integrating FaceBook support into iOS 6 (I've got it on my phone right now, and the 'post' button works exactly as advertised), it seems to me that this is probably being done in no small part because Apple is doing a bunch of stuff in Obj-C anyway. I have no idea what the FB API stuff is like (or even if it's available to devs like me) but there's clearly *something* going on under the hood.

    So Apple does some of the heavy lifting, and the FB programmers just piggyback off of it. At that point, why not switch?

  • Now, I have an Android phone so if it's remarkably different on iOS I could be off base here, but from what I saw of the app, it was exactly the same as the mobile web interface except that it also had access to your GPS and potentially camera. Having an app like Facebook turn on GPS as soon as I logged in was enough for me to limit myself to accessing it through the browser. *tightens tinfoil cap*

  • Facebook's iPhone app is so crappy I started just using the mobile version of their website in Safari. It's more responsive, less prone to hanging during I/O, and lets me do everything the app did.
  • by tillerman35 (763054) on Thursday June 28, 2012 @06:34PM (#40486955)

    Apple's formula for success under iOS:
    1. Control the hardware
    2. Control the software
    3. Make others do the work and because (1) and (2), you get to take a BIG cut of their business. No, not BIG... HUGE.

    Part of (2) is to not allow any development that might result in GOOD write-once/run-anywhere software. Backing HTML5 is a perfect example. The amount of effort required to produce a decent product is just plain insane. Even big companies like Facebook can't do it. Little companies don't even try. In the end, damn near everybody who tries to deploy an application that runs on an iOS device comes to the same sad realization: cough up the dough or go home.

    Products that actually worked, and worked well (e.g. Flash, Silverlight, etc.) were killed with feeble excuses like battery consumption and quality control. How the DoJ didn't launch an investigation into anti-competitive practices is a mystery to me. The "browser included in OS" investigation of Microsoft seems a pale shadow of the "you don't run software on iOS devices- despite the fact that their OWNERS want you to- unless you pay us a shiatload of money." /Bitter? You betcha.

"Ahead warp factor 1" - Captain Kirk

Working...