iPhone Development – Innovative, or a Cop-Out?

iphonedevelopement.jpg

Earlier today I posted some Thoughts on the Keynote, but I didn’t address the iPhone “Web 2.0″ development issue on purpose. I think it’s worth a post by itself. After watching the Keynote, then watching it again – this time looking at it a bit differently – I couldn’t help but notice the utter silence that washed over the crowd when it was announced that all 3rd Party iPhone applications would have to be developed through “Web 2.0 and Ajax”.

It wasn’t a stunned silence – the crowd wasn’t amazed with the idea. It was the sound of 5,000 developers being disappointed.

What I find phenomenally insulting is the constant mention of keeping the iPhone safe and secure. The way that it keeps being said makes it sound like developers have the plague or something. It seems , to me anyway, to be disrespectful to the developers that make the Mac so great.

I love my Mac. I love the Apple software on my Mac too…but part of what makes my Mac so great are the Applications that Apple had nothing to do with (Quicksilver, anyone?)…and I can’t understand why they wouldn’t want the same style of innovation on the iPhone.

This web based concept, at least in its current form, is also very anti-Apple from a simplicity standpoint. Instead of pressing a button to launch the application you need, you’re going to have to open a web browser, open your bookmarks, then click on the application you want – then (in most cases I would assume) you’re going to have to log in to said application.

That’s turning what should be a one button press process into a three button press (and a log in) process. I don’t believe that’s the right way to go about this. If they’re going to require that all applications be web based, they could at least allow you to have an icon on the screen that links directly to the website and stores your log in information. I don’t think that’s asking too much.

The average user is not going to understand, use, or pay for applications this way…and I think that may actually be why they chose this route. That average user is probably going to be fine with the applications that Apple puts on the phone…they probably aren’t going to need many – if any – third party apps. I don’t think Apple thinks that they’re going to be switching any Crackberry addicts…I think they’re targeting iPod owners and people who like shiny, pretty things (of which I am one, btw).

I don’t think Apple is taking third party development seriously on the iPhone because I don’t think they believe it will be an issue. by choosing this route, they can say “we gave you an option” and when it doesn’t take off, it won’t matter. They gave us an option, and we chose not to use it.

Of everything at the Keynote, the only thing I can look at after the fact and say that I’m disappointed about is the iPhone “development method”. An overpriced SDK to keep all the little guys out would have been less disappointing than this. At least THAT would have shown a little respect to the larger companies that have a few extra bucks laying around.

This…something about this just doesn’t sit well with me.

Comments

  1. I think the apps run on Safari and Web 2.0 standards, but that they will be launched just like any app (just like you mentioned). I think Jobs said that the apps will look just like the Apple apps that are on the phone. I think there’s still hope that at least the end-user side of this will turn out ok.
    You’re right that it’s a shame that there is no complete SDK for serious developers.

  2. Michael says:

    @Tycho -

    They actually say in the Keynote that you will have to go to Safari to launch the apps.

    Hopefully that will change, but for now, that’s the way it’s going to be.

  3. I think it’s fantastic (for web developers). I love the idea that I can develop for the iphone using my existing skillset. This is only going to put more emphasis on web apps. Is it perfect? No. But it’s a start.

  4. I think that the thought of *any* thing going wrong with the initial iPhone roll-out scares the bejeebers out of them. Developers be damned. The iPhone can’t tolerate negative press if Apple wants to become a serious player in this space. They’ve bet the company’s reputation on this. The stakes are too big.

    Expect a real SDK if they make it through the tsunami.

  5. Apple/AT&T don’t want people clogging their bandwidth with buggy apps and apps that are used to circumvent their services (Skype anyone?). Also, think of the new virus potential with this kind of device. Opening up the iPhone to third party development opens up a whole new arena for malware/viruses. Keep in mind, it’s supposed to be a phone, not a computer. As soon as everyone heard “OS X” they immediately went “ooh! I can write my own apps for it.” How many of you wrote apps to put on your Tivo, your Xbox, or your Palm Pilot? Exactly. So maybe they should be able to throw in their 2 cents as to what data packets they push. Let Apple be Apple, don’t worry, you guys can ruin the iPhone later.

  6. HouseCatStew says:

    I think webapps are the way to go. There shouldn’t be much in terms of an application that you need to do on a device that couldn’t be done with web 2.0. Unless you’re trying to hack something. Also, if I can leverage my existing skills and deploy to any user regardless of whether they’re using an iPhone, all the better.

  7. arajara says:

    Webapps are the future…. Google Apps are going to work like this, compatible with .mac and iGoogle and Safari for Windows.

    Also, isn’t it possible that an app can be stored locally on the iPhone as a directory with html, css, etc. files? And you can launch it by launching that file?

  8. One way around this is for Apple to create a .iPhone button on the iPhone, which upon tapping connects to a .iPhone (like .Mac) backend where all the user’s local data could be stored as well as buttons for all the user’s web apps (bookmarks).

    So one tap to get to .iPhone. Then one tap to log into any of your web apps.

  9. Relax people. This is not a big deal. The iPhone is not meant as a general purpose computer. Im sure you don’t want to run iPhone M$ Word or WoW on it or anything like that. If anything, Apple will fill in a few of the gaps themselves, as they know how to do it right. I we can all agree that they will be “adding features” to the iPhone as time goes on, as well as regular software updates. Also, if you look around, a lot of new apps are becoming web-based already, websites providing services of various kinds. You will have full access to all the internet-based games, and we can logically expect Google to make their online office apps iPhone-ready within a reasonable time. There is ample room for innovation in a web-based environment.

  10. Ok, if the iPhone is running on a stripped down version of OS X then it’s quite possible that it will support shortcuts and keychain. If so, all you need is mechanism for adding a shortcut to the interface, “clicking” that and Boom (couldn’t resist), Safari starts and you’re running the web app.

    I applaud Apple for not letting 3rd party developers directly onto the iPhone as they are resposible for so much of the grief on other smart phones.

  11. Am I just stating the obvious or is this something that people are just not getting with the whole “web-app” architecture?

    What I am referring to is the first half of the word — web — to use any of the so called apps, you have to be connected. What about when I am on an airplane? Or on a train? Or in the mid-west where I am unable to access wifi or a decent connection to the (sl)edge network? What then, no app?

    What Apple is proposing is future looking, however what is missing that would make it a viable development platform is two things:

    1) an off-line hook into the browser/OS for the apps to store data when the user goes off the grid.

    2) better control of when a web-page is refreshed, as it stands now, I am barely able to switch between safari and the ipod app if I happen to loose connectivity — very frustrating.

    Apple could bundle a local “storage server” with Safari and provided a JS interface into it. The server would provide web-developers the ability to specify client-side logic for handling data on the web page if the user is unable to contact the server that served the page. Once the user gets connectivity again, the storage server would pass the data back to the server. Not a new concept UUCP worked the same way. The whole cross-domain security model for JS can be leveraged to limit the data access and damage potential of the apps.

    (a quick but limited hack would be to persist the data to a cookie and build the logic server-side to check for the cookie when the user connects to the web-site again, but that’s a hack and you’re limited to 4k)

    The issue with pages refreshing is something within the control of Apple since they control Safari/the OS. Once they get that under control and provide local storage via the aforementioned “storage server” it gives web developers free reign to code away within the confines of a browser, but without feeling as though they are the redheaded stepchild of Steve Jobs.

Speak Your Mind

*