Skip to main content

Apple doesn’t care how much HTML Facebook uses in its app

By Jason Grigsby

Published on August 29th, 2012

Topics

Since Facebook announced their “fully native” app, some speculation has centered on the idea that Apple may have made a native app a precondition for the upcoming integration of Facebook with iOS 6.

Hogwash.

I doubt Apple cares how much HTML Facebook uses in its app. And if it does, it is being hypocritical. All of the following Apple-made iOS apps use embedded webviews in some capacity:

  • App Store
  • Newstand
  • iTunes
  • iBooks
  • iTunes U
  • Podcasts
  • Cards
  • Apple Store

And that’s not counting the fact that both the iAd and iBooks formats are built on HTML5. Why aren’t people clamoring for Apple to create a “native” version of iBooks or the App Store?

Apple has a lot invested in HTML5. How quickly we forget that WebKit—the rendering engine used by Google Chrome, Android Browser, Samsung’s Dolfin Browser, Blackberry Browser, and numerous others I’m forgetting—was partially created by Apple because of the need to embed web content in a native application.1

On the mobile front, Apple has pushed the browser more quickly and further than other companies. The advances still aren’t fast enough for my tastes, and I hope competitors catch up and turn the heat on Apple’s browser effort. Regardless, you’d be hard pressed to make a case that Apple isn’t a major contributor to HTML5.

I suspect Apple does what we do at Cloud Four when we look at apps. Apple likely takes a look at the features of the app and tries to determine if the feature is better as native, web or some combination thereof. When I took a look at the traffic from Apple’s own apps, I certainly saw indications of that thought process. I found:

  • Screens that were full native and receiving binary plist files
  • Screens that were native and received JSON data
  • Screens that were embedded webviews with the full HTML document, associated CSS and JS downloaded
  • Screens that were mostly native, but received JSON with HTML encapsulated inside of it for display in certain areas of the screen

So do I think Apple cares if Facebook uses HTML5 in their app? No. I think Apple cares that users have a great experience using Facebook on its platforms. And it is clear that the old Facebook app wasn’t a good experience, and they needed to improve it.

Does that mean that Facebook had to go “fully native” to create a great experience in the eyes of Apple? Obviously not given the fact Apple is using a mixture of web and native its own apps.

There’s a common saying in startups: Ideas don’t matter. Execution does.

For apps, a similar statement can be made: Languages don’t matter. The experience does.

Focus on a great experience, use whatever tools you need to create that experience, and if you succeed, no one will care how the app is built.

  1. When Steve Jobs announced Safari at MacWorld Expo 2003, he also announced the WebCore framework and how it had been included in Sherlock. Did the need for a browser come first? Or the need to embed web pages in apps like Sherlock and later iTunes come first? Probably the browser, but it is clear Apple thought early on how the browser rendering engine could be reused inside apps.

Jason Grigsby is one of the co-founders of Cloud Four, Mobile Portland and Responsive Field Day. He is the author of Progressive Web Apps from A Book Apart. Follow him at @grigs.

Comments

Billy Hoffman said:

Jason,

Agreed. And the “HTML inside of Native” approach has a huge benefit: Easy porting to the web.

Look at Apple’s store applications (iTunes, iOS app store, Mac App Store). All of these are native applications, but since most of the content is HTML, Apple can easily create a web pages for all the items, automatically, regardless of the store. This allows indexing by search engines, seamless sharing, and deep linking. They also use a little bit of JavaScript and custom URI handlers to then launch the native app directly from the web page if a visitor wants to buy. Very slick approach, and all because of the choice to use “HTML as content in native”

Kristofer Layon said:

Great post, Jason. Although you don’t use the words, I think this is a great piece about the application of product management. Clear product management thinking focuses design and development on delivering the most value and best UX to customers, rather than being prematurely disposed toward solutions for technical or political reasons.

So especially in mobile, where there’s still a bit of “culture war” going on in terms of pitting the false dichotomies of native vs. web apps, you help reinforce that these dichotomies are indeed very false. All mobile experiences are inherently hybrid… including viewing web pages in native browsers.

Steven Roussey said:

Safari based on KHTML rather than Gecko was just as much about the private development agreement Netscape made Apple sign back in the day. And yeah, Sherlock looked a lot like KISS. Just a few years later.

Jonathan Cutrell said:

You bring up a great point: HTML(5) is a brilliant way to manage applications that are already primarily derived from a web interface. However, there are a few issues to consider.
1. Native is, indeed, quite fast.
If a user experience is suffering because of speed, a move by a team as resource-independent as Facebook could be native application. Why? Because it has potential to speed up the application, which certainly has positive effects on the experience.
2. In-app web is not the same as Safari
Apple has intentionally disallowed the use of their JS engine inside apps. This means less-than-stellar performance for Webkit embeds for third party apps. Of course it’s not a problem for Apple to use them – they have access to a super-fast JS engine, and therefore can optimize their applications to the fullest extent when moving towards a language-agnostic scenario. This isn’t the case for third party apps.
3. It’s about more than languages
It’s about data retrieval and responsiveness as a whole. The reliability of HTML embedded inside a Webkit view is not the reliability of the native environment.

Would apple require a fully native app? Doubtful. Are there user experience benefits to gain from going native? Absolutely. Would Apple encourage native? I know they do silently, so I’m sure they’re fairly vocal about it in these conversations with partners.

Bridget Stewart said:

“Focus on a great experience, use whatever tools you need to create that experience, and if you succeed, no one will care how the app is built.”

Amen. I’ve been promoting a similar sentiment around the office, albeit not as eloquently stated. 🙂

My take has been — if native makes sense, do the best native app you can; if web makes sense make the best web app you can. Each has its strengths. Users don’t care which you use. They just care that it works for them.

Justin Avery said:

^ What Jonathan said in point 2.

There is a clear performance penalty when porting html into native apps. Ok, so we’re considering there is some javascript functions here… but we’re also talking about apps so the chances are there’s a bit of js going on.

This then causes an issue with two solutions

1) Build the app natively
2) Keep it as a web app

Option 1 means that less effort is put into the web version and Option 2 means Apple lose the store income, so I’m guessing that as much effort Apple put into HTML in apps it’s not high on their agenda for the rest of us to join in.