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.

  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…

    Share
    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…..

      Share
      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…

        Share
      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.

        Share
  2. 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.

    Share
    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.

      Share
      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)

        Share
    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.

      Share
  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.

    Share
    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.

      Share
      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.

        Share
      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..

        Share
    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

      Share
      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.

        Share
      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 .

        Share
  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.

    Share
    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).

      Share
    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).

      Share
  5. >> 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.

    Share
    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.

      Share
      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.

        Share
      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.

        Share
  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.

    Share
  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

    Share
  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.

    Share
    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.

      Share
    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.

      Share
      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.

        Share
      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.

        Share
  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.

    Share
  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.

    Share
  11. I also wanted to point out that Apple has had a “Safari for iPhone” section on their developers site since the summer of 2007. It describes how user interaction should be handled, human interface guidelines, etc. There have also been many web-apps available since then that feel like you’re using an actual iPhone application. In fact, there are currently over 4,000 iPhone specific web-apps…

    http://www.apple.com/webapps/index.html

    Share
  12. Does the author of this article actually use an iPhone?

    Web apps really fail when you can’t connect to the web, when your data plan is severely limited and when your cell connection is intermittent. You can use a native app anywhere.

    Share
  13. Micheal wrote… “That entire native application would only take a few lines of code actually.”

    Bingo! You have described it perfectly. An native app that needs a minimal UI that scales across multiple platforms and “talks” to the browser.

    Think about this command – “on navigate”. The customer launches the browser – he/she types in http://www.google.com and hits the send key – “on navigate” then scans the OS looking for apps with “meta data to send”. It finds your app – grabs the data, adds it to the HTTP headers and off to Google we go. Now all Google has to do is read the header data and then they can send it to any web service they want – it scales to all of them, including those in the Enterprise.

    Commenting on something Tom Ross wrote: “Where’s the payment solution for web apps?

    One word – Enterprise. Consumers want everything for free – you have to go “where the money is” – the Enterprise. They’re all moving to a SaaS model – and for that you can use the approach I’ve outlined above, and you can charge for it.

    Share
    1. Peter, but coming back to the premise of the article, we’re talking about the iPhone, and the enterprise is not Apple’s strong suit. And there’s also the option of enterprise level deployment for custom iPhone apps that Apple neither censors nor charges for.

      Share
      1. Enterprise has been a HUGE problem for Apple traditionally: the combo of very simple needs and a “penny wise; pound foolish” mindset made Enterprise fertile ground for the Windows cult. Enterprise needs basic word processing, E-mail, and some database, and the lure of cheap-appearing (if you don’t count the tech support) PC’s in the ’80s and 90′s sucked them into the Windows trap.

        But phones are different. The upfront cost of an iPhone is not much different from a Blackberry or other smartphone and people have been slowly becoming more savvy about what you can do and WANT to do with computers over the past decade– look at the trend away from PC’s toward more powerful systems, like Macs and, in some markets, LINUX.

        Share
      2. Absolutely correct.

        Apple is really a consumer play – developers are now learning that their hard work doesn’t necessarily (in 99% of the cases) translate into $$$. Apple makes all the money instead.

        Regarding Tom B’s point below on the upfront costs. Yes and No. The iPhone is naturally more expensive like all Apple products. However I don’t think that’s the point. Apple is very new to the game and has no legacy products like BB and WM do. So get Enterprises to adopt “yet another phone with only ONE carrier” is a significant hurdle to overcome.

        Apple is like Porsche – they sell to the 20% of the market that can afford it. Windows sells to the rest and to keep them honest we have Linux. Apple’s goal will always be high margin products and total control over all end points. It’s a model that works for them. The good news (for the rest of us) is that there are other products to develop for.

        The key is to focus on products that people are willing to pay more than .99 cents for otherwise you cannot build a sustainable business.

        Share
    2. And actually the GPS example is moot since mobile safari supports the WC3 Geolocation API allowing web-apps access to current GPS data.

      As far as “scans the OS looking for apps” … that just seems like a security nightmare. What’s to stop some other program from killing off the original and passing back bogus data?

      Share
      1. >> And actually the GPS example is moot since mobile safari supports the WC3 Geolocation API allowing web-apps access to current GPS data.<> As far as “scans the OS looking for apps”

        It’s a little bit more sophisticated than that. Our open API listens for data – if you app has included our API then you’ll pass us the data, if not nothing happens.

        Share
  14. @Cranstone

    @Al is right without a connection a web app is dead and I don’t think enterprise will go that direction. I don’t have to go into the losses the company will face when that happened. A native app will save a lot of grief.

    Perhaps one day when the whole planet is covered with wi fi or wimax and when that day comes web apps will have their day in the sun but who wants to pay perpetually for usage when an enterprise can develop its own native apps and use for free (I maybe wrong here).

    I am no developer, just a user.

    Share
    1. Adam… you’re correct. No connectivity then your web app doesn’t work. Also any mobile app that requires data from the web is also dead.

      So what’s the solution. Local caching until you’re connected again. Remember every iPhone you buy HAS to have a data plan with it – so even Apple see the future is web apps. What was the last time you remember that you weren’t connected within 5 – 10 minutes? (Probably when the battery died :)

      Share
    2. This isn’t a problem for a properly coded iphone webapp. Apple provides apis so a webapp can specify that it’s downloadable, and from that point forward will not require a connection to the internet. New HTML5 apis that the iphone support means webapps can also store large amounts of data locally. These things are possible, it’s just so few developers know, or do anything about it that it seems like it’s not possible.

      Share
  15. Always believed in “Super Powerful Browser”, replacement of OS and Windows to Web. PC App Dev was killed by Power of Web Browser, similarly, it will cast doom to all App Store of todays.
    Future Mobile Browser will be able to read all mobile sensor data (GPS, Accelerometer, bio sensor, camera etc.) and pass in HTTP request to Web Server and you know the rest of the story.
    It is the time of “Mobile App to Mobile App”
    http://bit.ly/17Qvr7

    Share
    1. >> Future Mobile Browser will be able to read all mobile sensor data (GPS, Accelerometer, bio sensor, camera etc.) and pass in HTTP request to Web Server and you know the rest of the story.<<

      It can do it now (Windows Mobile & Blackberry), supports older browsers, has an open api for developers and is free. http://bit.ly/3veZeF

      Share
      1. Fun will start when HTTP requests will incorporate all these. :)

        Share
    2. Sending it via HTTP is a stupid way to do it. The direction it’s going is this data will be accessible via DOM apis, which means it will be accessble from javascript. Javascript can elect to send this to the server, if it wants. But the client is getting fatter, not thinner. Webapps will be doing more and more without the intervention of the server.

      Share
  16. [Oops... This got posted in the wrong spot as a replay to an early post... Reposting it here... Sorry.]

    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.

    Share
    1. I mostly agree with you, but I believe you can do most of that without a shell app. There’s some special meta tags that apple has provisioned for this purpose. The main reason these shell projects exist (one example is phonegap ) is to get access to the more advanced apis like the accellerometer. But the direction seems to be that apple will eventually add them anyway. They’ve already added javascript access to multitouch gestures, and limited access to the accellerometer. The technical challenge to giving full access to the accellerometer is getting the javascript engine fast enough to deal with that firehose of data. As it stands, apple controls the fastest javascript interpreter on the market, and it’s only getting faster. It’s only a matter of time before the APIs you get in a webapp are virtually indistinguishable from the apis you get in a native app, and the speed of javascript now roughly comparable to unoptimised C, or java.

      Share
  17. HTML 5 is only for mobile browsers??

    Share
    1. No. HTML 5 is designed to run on all browsers. The issue is getting all the browser manufacturers to agree on a common spec and then integrating it. The irony is that the day after they all agree, new features will be available on mobile that HTML 5 won’t have access to.

      Share
  18. [...] we wrote back in August, HTML5 is a good way to break Apple’s stranglehold, as illustrated by this Pie Guy variation of the classic Pacman game, which uses HTML5 to replicate [...]

    Share
  19. “…advanced graphics (to rival Flash)…”
    DirectAnimation has been able to do this in IE6 for almost a decade now. How is it going to be different with HTML5?

    Share
    1. because now it’s every browser except IE.

      Share
  20. [...] that are made available to their phone users. For more information on this, you can check out Will HTML 5 Break Apple’s Stranglehold on Apps? For readers that are more advanced [than me], you can read up on how HTML 5 will change mobile at [...]

    Share
  21. [...] Underscores the open, developer-friendly Web as key. See this week’s launch of the HTML5 version of Google Voice as a case in point… [...]

    Share
  22. The exciting news for Flash developers is that the new Packager for iPhone due to be release in Adobe Fash CS5 will allow any application or game built using Flash to be exported for use on the iPhone.

    see:http://www.siliconbeachtraining.co.uk/blog/whats-new-in-flash-cs5-iphone/

    Share
  23. This is an awesome move by Google. We’re so excited about the possibilities for HTML5 that we just shipped search + discovery for HTML5 apps at parity with our existing native app offering. We need help filling out our HTML5 catalog to give these developers a hand with distribution – y’all come! http://bit.ly/drg0NB

    Share
  24. [...] Just as people stopped downloading AOL’s software and switched to browsers, we may well abandon most of the apps on our phones [...]

    Share

Comments have been disabled for this post