Friday, July 11th, 2008

Remember the Web Apps; Don’t forget the first iPhone baby today

Category: iPhone, JavaScript

We see the birth of the second baby when it comes to building and running apps on the iPhone. People have already spent almost $100k in the first few hours of the AppStore not being open, so tomorrow is likely to be a great day for Apple, and developers, as people run around clicking on buy without thinking of the price.

I spent some time running the applications, and thinking about how different they are to Web versions. For example, when I launch Twitterific vs. a web based Twitter it actually was faster for the Web page to load Safari up with everything. Twitterific also had a strange feature for loading images. As I moved up and down the list the images looked like they were being pushed out of cache which made for a weird experience.

What if the iPhone offered the ability to aggressively cache “applications”. When you open the application it opens its own instance of Safari instead of just linking over to Safari. What if it had access to local storage APIs in WebKit?

The native applications do have benefits. They have access to the camera, addressbook, … well wait, those could be JavaScript APIs too.

There is the tool chain. You can have fine grained performance knowledge of your application with the Objective-C tools, but with SquirrelFish Apple is getting better and better there too. Other nice tooling could work well when constraining the Web interfaces to the iPhone form factor.

What about games? You couldn’t do super monkey ball, or could you if you had a really solid Flash, or feature complete canvas.

The native apps are great, but I am still betting on the Web as a great platform for mobile applications too.

Posted by Dion Almaer at 10:01 am

3 rating from 26 votes


Comments feed TrackBack URI

It does have support for local storage, through window.openDatabase and db.executeSql

Comment by pottedmeat — July 11, 2008

I agree that the web has a lot of potential for mobile apps. The one issue that stands out is how to monetize web apps, since you cannot ‘sell’ them, at least not the way the appstore is selling native apps. I wonder if this is a contributing factor to the development of native apps? Is advertising revenue viable on mobile web apps?

Comment by BH23 — July 11, 2008

I know I’m going to get flamed for this.

I doubt you could do serious OpenGL/embeddedGL games on a phone even if the 3D API was exposed to Javascript without wasting battery life or performance. Javascript is not a universal hammer, there are just some things better written in systems programming languages, null pointers and malloc() and all. Undoubtedly, someone’s going to try and point to the usage of UnrealScript, Lisp, or QuakeC, in games, etc but remember, those languages drive game rule logic, not rendering logic, and they are not on CPU/memory/battery constrained platforms. It’s fine to use Javascript to compute the next position of a robot, or determine whether a flag has been captured or not and what sound to play, but you would not want to use it to compute physics, or pathfinding, or visibility, or matrix transformations, etc

I also think the native UI widgets are alot more CPU and memory efficient, than loading up an HTML/CSS engine, and loading a bunch of markup and script, to initialize the UI. This might not matter on the desktop, but on mobile devices, battery life is a big deal as is UI latency.

I think the open web as a platform is great, but there is alot of work left to make it the best platform for mobile apps, and while I think many apps could and probably should be done with AJAX, I think it is premature to try and run something like Google Docs on the phone, vs an Objective-C version. And I think writing the kind of games that gamers want leveraging the 3D hardware of the phone, games that you will want to pay for, demands a tougher development approach.

When you have a hammer, there’s a tendency to see everything as a nail.

Comment by cromwellian — July 11, 2008

Of course, there’s always the subscription/software as a service model. Web app doesn’t mean free.
On the other hand, until 10.6 is in the wild, the most evident performance work Apple is doing is in Webkit, presumably for exactly the reasons you’re on about. I’m not saying it’s “there” yet, but Javascript *can* be a lot more useful than is generally assumed, which is kind of the subject of this site in the first place.
I don’t know that we’ll ever see high performance, graphically intensive games developed in client-side Javascript; I don’t know that we won’t either. It really depends on how one defines those concepts and the degree to which power efficiency increases over time.
But there’s really no question that Javascript, in its current state, especially in a more modern platform like Webkit 3+ or Gecko 2+, can do a hell of a lot more than it’s doing now. What that means still remains to be seen.

Comment by eyelidlessness — July 11, 2008

Aside from the technical aspects, I think Apple has screwed over web apps some. There is a lot of hype around the app store which will lead novice/non-tech IPhone users to believe it’s the only means to get applications for the IPhone.

I just had a user asking how to download my webapp for the IPhone (like from the store). I think they stumbled upon it on the web but didn’t realize they could just visit the web site on the IPhone.

They need an App Store interface for the web apps.

Comment by AaronW — July 12, 2008

It probably depends on your app’s purpose and success. If it is web-related in the first place, it’s going to be assumed that it’s on the web. If your app is iPhone-only, exposure to it will be minimal and likely people won’t think to go looking for it.
Also, no one’s stopping anyone from putting a Webkit wrapper around their web app and deploying that on the App store. I imagine there’s tutorials for it online and I doubt it’s that arduous a task.

Comment by eyelidlessness — July 12, 2008

The Cocoa iPhone framework has the ability to embed Webkit browsers in to any application.

Also, you can call Objective-C from Javascript and vice-versa.

I don’t think it would be that difficult to create a framework for developing javascript applications that could utilize all of the iPhone native functions such as locationing, camera, sqlite, etc…

Comment by williamcotton — July 14, 2008

It is possible to access the Javascript environment from Objective-C, but accessing the phone from inside the browser environment is considered a security hazard and therefore restricted.

With the release of 2.0, they certainly have not left webapps behind – they’ve just stopped blowing that particular trumpet as loudly now that they have the SDK to promote. As a result, Apple are trying to focus the spotlight on the App Store and away from web applications, if only to simplify the message, showcase a few select applications and promote the new distribution system.

I have found a hybrid approach interesting, but that is because I am coming it this from the angle of a web application that wants to appear native but really needs to be a web application but nevertheless wants the exposure that the App Store provides.

Comment by davidroe — July 29, 2008

Leave a comment

You must be logged in to post a comment.