Skip to content →

Tag: platform

Web vs native

imageWhen Steve Jobs first launched the iPhone in 2007, Apple’s perception of where the smartphone application market would move was in the direction of web applications. The reasons for this are obvious: people are familiar with how to build web pages and applications, and it simplifies application delivery.

Yet in under a year, Apple changed course, shifting the focus of iPhone development from web applications to building native applications custom-built (by definition) for the iPhone’s operating system and hardware. While I suspect part of the reason this was done was to lock-in developers, the main reason was certainly the inadequacy of available browser/web technology. While we can debate the former, the latter is just plain obvious. In 2007, the state of web development was relatively primitive relative to today. There was no credible HTML5 support. Javascript performance was paltry. There was no real way for web applications to access local resources/hardware capabilities. Simply put, it was probably too difficult for Apple to kludge together an application development platform based solely on open web technologies which would get the sort of performance and functionality Apple wanted.

But, that was four years ago, and web technology has come a long way. Combine that with the tech commentator-sphere’s obsession with hyping up a rivalry between “native vs HTML5 app development”, and it begs the question: will the future of application development be HTML5 applications or native?

There are a lot of “moving parts” in a question like this, but I believe the question itself is a red herring. Enhancements to browser performance and the new capabilities that HTML5 will bring like offline storage, a canvas for direct graphic manipulation, and tools to access the file system, mean, at least to this tech blogger, that “HTML5 applications” are not distinct from native applications at all, they are simply native applications that you access through the internet. Its not a different technology vector – it’s just a different form of delivery.

Critics of this idea may cite that the performance and interface capabilities of browser-based applications lag far behind those of “traditional” native applications, and thus they will always be distinct. And, as of today, they are correct. However, this discounts a few things:

  • Browser performance and browser-based application design are improving at a rapid rate, in no small part because of the combination of competition between different browsers and the fact that much of the code for these browsers is open source. There will probably always be a gap between browser-based apps and native, but I believe this gap will continue to narrow to the point where, for many applications, it simply won’t be a deal-breaker anymore.
  • History shows that cross-platform portability and ease of development can trump performance gaps. Once upon a time, all developers worth their salt coded in low level machine language. But this was a nightmare – it was difficult to do simple things like showing text on a screen, and the code written only worked on specific chips and operating systems and hardware configurations. I learned C which helped to abstract a lot of that away, and, keeping with the trend of moving towards more portability and abstraction, the mobile/web developers of today develop with tools (Python, Objective C, Ruby, Java, Javascript, etc) which make C look pretty low-level and hard to work with. Each level of abstraction adds a performance penalty, but that has hardly stopped developers from embracing them, and I feel the same will be true of “HTML5”.
  • Huge platform economic advantages. There are three huge advantages today to HTML5 development over “traditional native app development”. The first is the ability to have essentially the same application run across any device which supports a browser. Granted, there are performance and user experience issues with this approach, but when you’re a startup or even a corporate project with limited resources, being able to get wide distribution for earlier products is a huge advantage. The second is that HTML5 as a platform lacks the control/economic baggage that iOS and even Android have where distribution is controlled and “taxed” (30% to Apple/Google for an app download, 30% cut of digital goods purchases). I mean, what other reason does Amazon have to move its Kindle application off of the iOS native path and into HTML5 territory? The third is that web applications do not require the latest and greatest hardware to perform amazing feats. Because these apps are fundamentally browser-based, using the internet to connect to a server-based/cloud-based application allows even “dumb devices” to do amazing things by outsourcing some of that work to another system. The combination of these three makes it easier to build new applications and services and make money off of them – which will ultimately lead to more and better applications and services for the “HTML5 ecosystem.”

Given Google’s strategic interest in the web as an open development platform, its no small wonder that they have pushed this concept the furthest. Not only are they working on a project called Native Client to let users achieve “native performance” with the browser, they’ve built an entire operating system centered entirely around the browser, Chrome OS, and were the first to build a major web application store, the Chrome Web Store to help with application discovery.

While it remains to be seen if any of these initiatives will end up successful, this is definitely a compelling view of how the technology ecosystem evolves, and, putting on my forward-thinking cap on, I would not be surprised if:

  1. The major operating systems became more ChromeOS-like over time. Mac OS’s dashboard widgets and Windows 7’s gadgets are already basically HTML5 mini-apps, and Microsoft has publicly stated that Windows 8 will support HTML5-based application development. I think this is a sign of things to come as the web platform evolves and matures.
  2. Continued focus on browser performance may lead to new devices/browsers focused on HTML5 applications. In the 1990s/2000s, there was a ton of attention focused on building Java accelerators in hardware/chips and software platforms who’s main function was to run Java. While Java did not take over the world the way its supporters had thought, I wouldn’t be surprised to see a similar explosion just over the horizon focused on HTML5/Javascript performance – maybe even HTML5 optimized chips/accelerators, additional ChromeOS-like platforms, and potentially browsers optimized to run just HTML5 games or enterprise applications?
  3. Web application discovery will become far more important. The one big weakness as it stands today for HTML5 is application discovery. Its still far easier to discover a native mobile app using the iTunes App Store or the Android Market than it is to find a good HTML5 app. But, as platform matures and the platform economics shift, new application stores/recommendation engines/syndication platforms will become increasingly critical.

I can’t wait :-).

(Image credit – iPhone SDK)

22 Comments

fbPhone

image

This past weekend, a TechCrunch article caught the tech blogosophere off guard with an interesting claim:

Facebook is building a mobile phone, says a source who has knowledge of the project. Or rather, they’re building the software for the phone and working with a third party to actually build the hardware. Which is exactly what Apple and everyone else does, too.

The question is, does a Facebook phone platform (or, fbPhone to borrow the i/g prefix style corresponding to Apple and Google) make sense for Facebook to pursue?

On the one hand, Facebook is rapidly becoming an “operating system” of sorts for the web. According to Facebook’s statistics page, Facebook has over 550K active applications developed on it and over 1 million additional third party websites which have integrated in some fashion with this monumental platform. But, beyond sheer numbers, Facebook’s platform passes what I consider to be the true “is it a real platform” test that Windows, Linux, and Mac OS have passed: it has the ability to sustain a large $100M+ software company like Zynga (which has been estimated to generate over $800 million in annual revenues), capable of now spending enormous amounts on R&D and sales & marketing (and even of experimenting with its own rival gaming platform). This is something which, to my knowledge, the iPhone and Android ecosystems have yet to achieve.

Given its status as an “operating system” for web developers, there is certainly some value Facebook could gain from expanding into the mobile operating system sphere. It would make the Facebook experience more sticky for users who, once they step away from their computers, can only interact with the most basic Facebook features (pictures, notifications, news feeds) by making it easier for developers to truly view Facebook (mobile and desktop) as one application platform.

image

On a strategic level, Facebook probably also sees potential dangers from Google and Apple’s control of the underlying smartphone software platforms. This control could transform Apple’s very shoddily constructed music “social networking service” Ping and Google’s thus-far unsuccessful attempts, as per its usual business strategy, to weaken Facebook’s dominant position in the social web into a serious threat to Facebook’s long-term position.

So, there are obvious benefits to Facebook in pursuing the platform route. However, I think there is an even more obvious downside: its HARD to build a mobile phone operating system. The TechCrunch article points out that Facebook has hired a number of the top mobile/tablet OS developers in the industry – while this means that its not impossible for Facebook to build a phone platform, its a long shot from building a full-fledged operating system. Assuming Facebook wants to build a phone, its unlikely to take the Apple route and build one monolithic phone. Like Google, Facebook’s business model is built around more user engagement, so a Facebook phone strategy would more likely be centered around getting as many users and phones possible to plug into Facebook.

The path towards such a phone platform (rather than single phone) requires many complicated relationships with carriers, with middleware providers, with hardware manufacturers, and with regulatory bodies (who are not too keen on Facebook’s privacy policies right now), not to mention deep expertise around hardware/software integration. Compare the dates for when Google and its wide swath of partners first announced the Open Handset Alliance (November 2007) to when the first Android phone was available (October 2008). A full year of committed development from industry giants HTC (hardware), Qualcomm (silicon), T-Mobile (carrier), and Google – and that’s assuming the alliance got started on the day that the project was announced and that partners like Verizon/Motorola/Samsung/ARM/etc did absolutely nothing.

From my perspective, Facebook has three much more likely (albeit still difficult) paths forward given the benefits I mentioned above for having its own mobile phone platform:

  • Build another “Open Handset Alliance” with the ecosystem: This is the only route that I see for Facebook to take if it wants its own, strong foothold in the mobile platform space. The challenge here is that the industry is not only tired of new platforms, but is also not likely to want to cede as much control to Facebook as they did to Google and Apple (and potentially Microsoft when it rolls out its Windows Phone 7 OS). This makes the path forward for Facebook complicated at best and, even when successful, requires it to compete against very well-established operating systems from Google & its partners and Apple.
  • Pull a HTC/Motorola and build a layer on top of or modify an open OS like Android or MeeGo: This, to me, makes the most sense. It eliminates the need for Facebook to invest heavily in hardware/network/silicon capabilities for deep phone platform development, and it also allows Facebook to leverage the application and ecosystem support that Android and MeeGo command (provided they don’t make too many modifications). Instead, Facebook can focus on building the tools and features that are most relevant to its own business goals. The downside to this, though, is that Facebook loses a fair amount of control over the final user experience and still has to play nice with the phone manufacturers, but these are things it would have to do no matter what strategy it picked
  • Just build a more complex mobile app which can support Facebook apps: This is the path of least resistance but leaves Facebook at the greatest mercy of Apple and Google, as well as forces Facebook to keep up with phone proliferation (iPhone 3G vs iPhone 3GS vs iPhone 4 vs DROID vs DROID 2 vs DROID X vs…)

Bottom-line: I don’t know if Facebook is even thinking about a bold mobile platform strategy, but if it is, I doubt it comes in the form of a full-fledged fbPhone. To me, it makes a lot more sense to stay the course and build more a sophisticated app in the short-term and, if needed, figure out ways to integrate rich user interface/development tool layers on an open operating system like Android or MeeGo.

(Image credit) (Image credit)

Leave a Comment
%d bloggers like this: