58 Comments

Summary:

It’s no secret that the iPhone App Store is a walled garden. Mobile platform developers like Apple have several ways to control what can run on their devices: Prohibit plug-ins like Flash, cripple the Java they run, or simply limit the installation process. But HTML 5, […]

appstore_iconIt’s no secret that the iPhone App Store is a walled garden. Mobile platform developers like Apple have several ways to control what can run on their devices: Prohibit plug-ins like Flash, cripple the Java they run, or simply limit the installation process. But HTML 5, the next big standard for the web, will dramatically reduce this control by creating a new generation of web sites that look and feel like they’re iPhone apps.

Limiting what can run on a phone requires some degree of collusion among the device maker (Nokia, HTC), the phone operator (T-Mobile, Canada’s Rogers), and the application store itself. Many other mobile device makers have policies that are similar to, though less obvious than, Apple’s: Android doesn’t support Flash (but it’s coming), for example, and has a special application for YouTube videos; and some carriers block Skype, location functions and streaming TV. The problem becomes much more noticeable when one company, like Apple, is both a platform and a service provider and co-develops features (like Visual Voicemail) with a single carrier.

HTML 5 is poised to change this. It’s rich enough to do all kinds of things within a browser that once required dedicated applications or plug-ins. Available in Firefox 3.5, and soon many other browsers, it allows advanced graphics (to rival Flash), real-time two-way streaming (including binary data) and audio. Every new feature in browsers chips away at the walled nature of the App Store because it makes web sites behave more and more like dedicated iPhone applications.

So when Apple removes an application, the affected company can rebuild on a web site using HTML 5, and deliver similar functionality. Just look at what Google said it would do when Voice was pulled from the App Store. This is one reason why the search giant is a strong proponent of HTML 5: As browsers get more powerful, mobile platform developers lose their stranglehold on the application market.

Apple and others face a difficult choice. They can embrace HTML 5 on mobile browsers, and lose their ability to constrain what applications can do. Or they can cripple their browsers, controlling what runs on their devices but delivering a second-rate surfing experience.

To keep up with the resulting arms race, mobile devices will have to inspect web page content or blacklist specific sites — rather than just blocking a plug-in or removing an app — in order to exclude certain applications. That’s a net neutrality nightmare: If the iPhone blocks voice.google.com, the Federal Trade Commission is sure to come calling. As a result, richer browsers may well tear down the garden walls — and chip at the enviable revenues — of companies like Apple.

You’re subscribed! If you like, you can update your settings

  1. @Alistair,

    I have noted across many tech blogs that the success of the App Store was due to browser limitations since the App Store was launched. It is inevitable that native applications on phones will die as handset browsers evolve. I think too many bloggers have enjoyed Apple’s cool aid to the point that they’ve lost site of the fact that browsers drove the end of life of desktop applications. These market forces are happening much more quickly on phones.

    My $.02.

    Best…

    1. The success of the App Store was due to a multitude of reasons (Great SDK, powerful platform, Apple’s app guidelines, great programmers, low prices, EASY to use / buy, etc.) and I would put browser limitations so far down the list that it is insignificant.

      Native Apps give a better user experience than web apps – it’s that simple. I have yet to see of a single example of a web app being better than a well done native App.

      The desktop applications have met their end of life? Really? Tell that to Microsoft – Office, Adobe – CS4, Acrobat, Lightroom, Apple – iTunes, iLife, iWork, etc.

      iPhone (same for other platforms) will need more powerful hardware, MUCH faster and more persistent data connections and advances in software / HTML before the situation changes. Native Apps are here now and deliver a great experience and are a great value. If it ain’t broke…..

      1. @SFMitch,

        I agree in principal with the multitude of reasons that you cite, however these requirements were necessary given browser limitations. These multitude of reasons became ubiquitous for web development which disrupted the market for desktop applications. Sure they exist today, but the market is much smaller when measured in dollars. Microsoft enjoys a monopoly position due to their OS and the WinTel stranglehold, so they are not a good indicator of the desktop software market.

        I also agree native apps are better for now. Again a browser limitation which will be overcome.

        Final point, most developers aren’t making any significant revenue from the App Store. To my knowledge, the App Store hasn’t created any software companies with a healthy market value, this despite the fact that many have been capitalized with venture money.

        Best…

      2. hey FUDster:

        FYI: it was apple itself that invented the CANVAS feature in html5 – canvas is the core technology that makes html5 a viable alternative platform against the (proprietary) Flash gunk from adobe!

        Apple is not “threatended” by html5: apple is a founding charter member of the consotrium that originated the spec (as a protest to the W3C’s glacial progress on XHTML etc).

        maybe you should actually do some RESEARCH before you start writing!

        all you have done here is made yourself look like a dufus – and embarrassed a brand (gigaom) that that is known for normally being tech savvy.

  2. Peter Cranstone Wednesday, August 12, 2009

    Totally agree – but (there’s always a but) here comes the really hard part. Agreeing on a standard and then implementing the standard across all the platforms. People write about HTML 5 like it’s a done deal – not even close. It will be years and it will not solve all the problems. There will always be a need for a dedicated app to supply the “missing meta data” from the phone —-> to the browser —-> that then sends it to the web server.

    1. What “missing meta data”? What standards-based web-apps are you writing that need an external NATIVE application that supplies it with non-standard data? It seems like this is some sort of weird hybrid application that has nothing to do with standards. It should be up to the browser developers (via a standards body) to insert environment data into the DOM, so that it can be accessed by the web-app. The whole point of writing standards-based web-apps is to make them portable across different platforms and browsers.

      1. >> What “missing meta data”?

        Anything that the OS has an API too.

        >> What standards-based web-apps are you writing that need an external NATIVE application that supplies it with non-standard data?

        SaaS.

        IMO there is no such thing as “non-standard data”. It’s all meta data.

        >> The whole point of writing standards-based web-apps is to make them portable across different platforms and browsers.

        Absolutely. Try writing a web based app that supports iPhone, Blackberry and Windows Mobile, Android, Symbian devices?

        All we did was take the HTTP standard (which is extensible) and added some new headers to it. Those headers are HTTP_X compliant – and in the spirit of openness we also added an open API to our app. So now you can now send virtually any piece of data from either a BB or WM device to any web service and all you have to do is read the incoming headers. After that CGI to any backend web service that needs it.

        Works identically across all platforms and in all browsers (except iPhone which doesn’t allow you to access programs running in the background via the browser).

        The browser manufacturers will take forever to add things that customers want. So we just did it ourselves using what is arguably the biggest standard of them all – good old HTTP (read rfc 2616 – section 12.1)

    2. As I side note regarding web-apps and native iPhone development…

      It is very easy to create local* web-apps wrapped in a native iPhone application. (*By local, I mean web-based applications that reside in the device file system, not on a web server somewhere. Local web-apps are pure HTML, CSS, and Javascript applications, that do not require a web server for pre-processing. This would be akin to Palm Pre applications and OS X Dashboard Widgets.)

      Create your web-app as your normally would, using whatever tools.
      Create a basic “shell” iPhone project, that consists two objects, UIWindow and UIWebView.
      Add the web-app to the project.
      Upon launch, load the root page of the web-app into the UIWebView object.

      Very simple, very few lines of native code, if any. Most of this can be done through Interface Builder. And because the native application can interact with the hardware and the WebView, it can pass data along to and get data from the web-app, through Javascript commands.

      And there you have an HTML5 application running as a native application on the iPhone. The whole point of most of the new technologies in HTML 5 is to remove the need of having a server. The browser itself becomes a run-time engine that can replace proprietary RTEs such as Flash, SilverLight, Java, etc.

  3. Safari on the iPhone already supports HTML 5. And one look at googles latitude webapp shows why HTML 5 can only remove apples stranglehold in theory. The performance is sluggish, the experience subpar. There is a reason why facebook wrote an app though they had a great iPhone webapp. By the time the webapps catch up it is going to be one or two years. That is pure science fiction in mobile land.

    1. I’ll take any bet that puts advances in broadband, computing, and storage on my side. The trifecta will create online apps that rival local ones. Where HTML5-based apps can’t compete is in advanced haptic interfaces — pinch, for example, isn’t a standard feature that browsers can easily understand and respond to. But for many apps (like Google Voice) they’re just fine.

      Working offline is also a challenge; I use Gears for GMail and Remember The Milk offline, and I guess the phone manufacturer could prevent the installation of an offline framework like Gears. But for apps that need to be connected anyway, this is less of an issue.

      As for HTML 5 support, nobody fully supports it yet; but it will do for mobile app stores what the web did to desktop apps. You might argue (as @sfmitch does) that desktop software is healthy — but the price pressure SaaS has introduced on enterprise software is considerable, and even Microsoft has Ray Ozzie clamoring for “Software plus a service” these days.

      1. Totally agree – extending current SaaS models to mobile is critical. The only issue to overcome is the small screen, small keyboard and no mouse.

      2. HTML5 on the iPhone supports local databases. Part of the functionality Gears gave you.
        GMail webapp on the iPhone uses this feature to give you offline web access.

        iPhone’s Safari gives you access to location services which was one reason to write these apps.

        Latitude webapp also supports pinch to zoom.

        The problem is not that these apps do not exist or the apis to create these apps do not exist, Its just that the UI experience is way below that of the native maps/ mail app.

        I am saying that its not really a threat to the Apple controlled native apps till the experience catches up. The iPhone is all about the experience factor anyway..

    2. Yuvamani,

      That’s really interesting. I had no idea that HTML 5 slowed things down that much on an iPhone. We’ve developed a free mobile app that supplies the browser with all kinds of meta data that can be sent to a web server. We have it running on Blackberry and Windows Mobile and have not seen any slowdown in the browser at all. In fact you can do real time GPS enabled search and it works great.

      We haven’t bothered with iPhone because you can’t run an app in the background.

      Thanks for the info though – something we didn’t know.

      Peter

      1. The way I read Yuvamani’s post is that

        He didn’t say that HTML 5 is the reason Google webApp is slow. He was noting that a webapp (as opposed a Native App) is slower with a subpar experience.

        Presumably, a native Google Latitude web app would offer a noticeably better experience.

      2. @sfmitch Exactly. The native maps app and the latitude webapp are miles apart as far as experience goes. What causes the slowdown, I do not know. It could well be bad code from Google. But if Google cannot write a performant webapp, very few other people can .

  4. Are you kidding me? Apple wants HTML 5. They were orginally pushing developers to develop web-based apps — it was the developers that wanted a native SDK. What they don’t want is Flash or other proprietary stack. They’re touting new HTML standards because they don’t want Adobe to own the web.

    Apple’s not going to blacklist anything. This is a ridiculous post.

    1. I completely agree that Apple seems firmly in favor (strongly in favor) of HTML5 and advancing the capabilities of the Web.

      I must disagree that Apple wasn’t planning on Native Apps all along. There shouldn’t be any question that Apple introduced the Web App as a stop gap measure while they were furiously finishing the iPhone OS and creating a SDK, App Store, etc.

      Apple has had a very clear roadmap for the iPhone / iPod Touch platform. They priortized and shipped the phone without a native SDK because there was no way to launch the iPhone simultatenesouly with SDK anywhere near the original June 2007 launch date. Apple, wisely, chose to release the phone without the SDK full well knowing (but not publicly saying) that the SDK would be released ASAP (a year later).

      This is basically the same thing Palm chose to do (Palm will have a smaller window between launch of their OS and SDK).

    2. I completely agree that Apple seems firmly in favor (strongly in favor) of HTML5 and advancing the capabilities of the Web.

      I must disagree that Apple wasn’t planning on Native Apps all along. There shouldn’t be any question that Apple introduced the Web App as a stop gap measure while they were furiously finishing the iPhone OS and creating a SDK, App Store, etc.

      Apple has had a very clear roadmap for the iPhone / iPod Touch platform. They prioritized and shipped the phone without a native SDK because there was no way to launch the iPhone simultaneously with SDK anywhere near the original June 2007 launch date. Apple, wisely, chose to release the phone without the SDK full well knowing (but not publicly saying) that the SDK would be released ASAP (a year later).

      This is basically the same thing Palm chose to do (Palm will have a smaller window between launch of their OS and SDK).

  5. Peter Cranstone Wednesday, August 12, 2009

    >> Presumably, a native Google Latitude web app would offer a noticeably better experience.

    Why? A web app delivers data via the browser. Therefore you’re dependent upon bandwidth, processing power and also access to device side capabilities like the GPS.

    IMO they’re architecting it the wrong way around. When I connect to a web server via a mobile browser the web server should already have all the data it needs to deliver the service, e.g. I open up a search page on Google – it should already have my GPS coordinates, it shouldn’t have to ask for them.

    Of course this brings up the whole privacy issue which is really all about trust. If you trust a web site to not abuse your privacy then send the data – if not then don’t.

    1. On initial connection the browser doesn’t understand what you’re trying to connect to. How it could possibly know that the server wants/needs your GPS coordinates? So you’re saying when I connect to this page, my browser should send my GPS coordinates to it automatically? The only way a browser knows what a server wants, is when it’s asked for it. Can you imagine all the data that would need to be shoved to the server to make sure every single service on the web is already aware who you are and what you want without needing to ask for it? That’s ridiculous to expect.

      While I agree this would be ideal, it is not practical, ethical or realistic. This is why native applications are much more efficient; they know what they need in order to interact with a very specific server and service. The FaceBook application knows exactly how to communicate with the FaceBook server and vise-versa and all that’s passed back and forth is data. The native FaceBook application doesn’t need the code to interact with the data like a browser does.

      1. >> On initial connection the browser doesn’t understand what you’re trying to connect to.

        Yes it does – it’s making a get request.

        >> How it could possibly know that the server wants/needs your GPS coordinates?

        It doesn’t – you do. Here’s a simple example. I have a GPS in my Blackberry, I want to do GPS enabled search, so I set my app that when I navigate to http://www.google.com it sends either my GPS or Cell Tower ID.

        >> Can you imagine all the data that would need to be shoved to the server to make sure every single service on the web is already aware who you are and what you want without needing to ask for it?<> While I agree this would be ideal, it is not practical, ethical or realistic.

        It works like a champ. You download and check it out. It’s free. As for ethical – we talked to a lot of “customers” before we built it. They all wanted three things – Convenience, Privacy and Control. We built all that in – you can control everything. As for realistic – imagine you have a web service that could do wonders with GPS data and the exact browser capabilities in real time. Imagine if all you had to do to get that data was read a header (The Windows Mobile version supports JavaScript access to the device capabilities as well).

        The consumer doesn’t want to type in anything on mobile, they just want it to work and deliver relevant information. You can build a mobile app – but that gets exponentially more difficult as you go cross platform – or you can take a current web service and extend it to mobile with no mobile programming. One takes a day to get running, the other, considerably longer.

        RE: Your Facebook comment. Totally agree – now how does that help me in the Enterprise. I have a real need (in say Banking) to support multi-factor authentication and need access to the devices fingerprint reader. Facebook won’t support that. Our solution does – it’s just more meta data that can be sent to ANY web server (presumably the banks) that needs it.

        From a cost/risk standpoint the future (especially in the Enterprise) is going to be web apps. The issue (technical) boils down to one thing – devcap – device capabilities. We focused on solving that problem vs. building apps.

      2. This basically sounds like nothing more than a work around for something lacking in the browser itself. You could in fact create a small native iPhone application that acquires all necessary meta data from the system, and launches into Safari (or creates it’s own web view) to a specific site. I could create a small application called “Google Locale Search” which upon launching gets my GPS coordinates (if permitted) and then attaches those to a url request string and launches into Safari. If you don’t like the jumping around applications like that, I could just throw a web view in my native application and send it the URL. That entire native application would only take a few lines of code actually.

  6. AFAIK Safari 4 was the first to begin to implement HTML 5 support amongst the major browsers. When Safari 4 first launches, it uses HTML 5 in its initial launch screen.

    If you have it installed you can see it for yourself at:

    http://www.apple.com/safari/welcome/

    That said, it’s probably pretty clear on where Apple stands on HTML 5.

  7. I cannot completely agree with this view.
    Jut realize that , out of the 2 main HTML 5 editors, one is from Apple and the man is David Hyatt.
    Check out.
    http://dev.w3.org/html5/spec/Overview.html

    David had made significant contributions to safari, webkit and co-created firefox as per wikipedia.

    Usually standards progress is slow with different vendors having different view points. Example is the
    web services specification being battled still by IBM, MS, SAP,Oracle(earlier sun, bea were in the game ).

    Apple will ensure that it’s technology or rather it’s offering thru a good ecosystem will be ahead of ahead of a pure technical progress such as HTML5.

    Twitter :#sampathmanda

  8. I don’t understand this article at all. Apple is pushing HTML 5 like mad. They even see it as a better alternative to Flash. Safari supports it, and its underlying rendering engine — Apple’s open source WebKit — is what Google uses in Chrome.

    Further, Apple couldn’t care less about web apps, having opened those up a year before they introduced their SDK. As for Google Voice on the iPhone as a web app, I think it’s what Apple wants. It gives the iPhone GV functionality while still preserving any contractual relationships with AT&T they probably felt the app would break. It’s the perfect win-win for Apple.

    1. I agree with Mr. Reestman 100%.

      This whole article has the wrong paradigm: who will REALLY be hurt by HTML5? The companies with buggy, cpu-sucking, very inferior, direct competitors to HTML5, that is Adobe (Flash) and MSFT (Silverlight).

      It’s like those dudes who say netbooks will kill “expensive” Apple. yea, maybe, someday, but Netbooks will leave MSFT hemorhaging in the streets FIRST, since, right now, Netbooks and MacBooks address different segments of the market.

      Or the Noobs that say Android will cream the iPhone because its “Open” (should say “more” open, because OS X is based on FreeBSD). “Open” matters to geeks; useful, elegant, fun– matters to the rest of us.

    2. Apple, and everyone involved in Webkit, is pushing HTML5. That’s not the point here. Apple is a big company, with lots of businesses in it — music revenue, hardware sales, software development, and application retailing among them. Each of these has different agendas and priorities.

      The point was that as HTML5 moves onto mobile devices, the line between an installed application and a website that feels like an application blurs; and because HTML5 can do many things for which a plug-in was previously required, the device manufacturer will lose one of the main ways in which they can restrict what runs on their phones.

      Ultimately, Apple won’t get to say that certain applications are “inappropriate” or “conflict with core features on their phone.” Hopefully, as @realitybites points out below, this will encourage Apple to keep innovating ahead of what’s possible with a web application (for example, with gestural interfaces, augmented reality apps, and so on.) But it won’t be able to command the margins it enjoys today for app sales.

      1. Alistair, you really need to just stop posting because you haven’t a clue as to what you are talking about. You just keep digging yourself deeper and it is downright embarrassing.

        Safari Mobile on the iPhone supports more of the HTML5 spec than ANY other mobile browser. Even the browser that ships with Google Android isn’t as robust in HTML5 support.

        Second, Steve Jobs and Apple initially promoted writing web apps to the Safari browser as THE way to develop apps for the iPhone. Developers threw conniptions and Apple finally opened up native development for the handset. If anything, Apple wants to see MORE web app development for the iPhone, not less.

        Third, your last statement regarding Apple commanding margins for app sales is just non-sensical. While Apple generates revenue off of app sales, it is purely a fee to the developer to cover Apple’s hosting, management and transaction costs for the App Store. It is a cost center, not a profit center for Apple. Therefore a reference to margins makes no sense

        I can’t believe Om Malik let’s someone as clueless as you write for what is otherwise an excellent blog network.

      2. “But it won’t be able to command the margins it enjoys today for app sales.”

        What is that supposed to mean – 100 % of $0.00 is better than 70 % of $0.99? Where’s the payment solution for web apps? The freebie mentality among consumers is one of the main detriments to web development, and every mobile web developer should think long and hard if they can make enough money through ads alone or if they should move to low-priced native apps.

  9. Will HTML 5 Break Apple’s Stranglehold on Apps?

    In a word, no.
    Your question seems curious at best as Apple is pushing HTML 5.
    What sense would that make if it was to be the agent of the App stores demise.

    Apple innovates and succeeds, they’re not that stupid as to promote a technology that hurts themselves financially, especially since they are one of the only technology companies to continually make ever increasing amounts of it even during a recession.

    There seems to be a consortium of failed coders, bloggers and basically disenfranchised technology pundits that keep posing similar questions over and over again, questioning whether this new or that new technology will succeed in knocking Apple off whatever throne they particularly feel threatened by.

    Invariably, the answer keeps being no.

    Wishful thinking won’t make it so.

  10. Hmmm… Yeah not sure what angle this argument is coming from? There’s a huge gaping hole knocked into it when you include the fact that Safari already supports HTML 5, both on the iPhone and on the desktop. People are free to create HTML 5 web-apps for the iPhone. The problem is the AppStore and the 60,000+ native applications have overshadowed web-apps to the point that it seems some people assume Safari must not support HTML 5 or any of the advanced features of the new WC3 standards. They naively disregard the fact that Apple has made it extremely easy to develop applications that can interact with web servers and therefor replace the browser experience with a fully native application.

    RE “Advanced Graphics”:
    You also must realize the ‘canvas’ tag came out of Apple and was handed over to the WC3 for inclusion into the HTML 5 standard. As well as the ‘transform’ CSS3 styles. These are specifically created for one reason, to remove the need for a proprietary technology (Flash) on an open medium. And let’s not forget, Apple also created and is pushing the HTTP streaming protocol as an open standard, which already available on the iPhone as well.

    In conclusion… Apple is not afraid of HTML 5.

Comments have been disabled for this post