Tue, 12 Jun 2007

Quentin's note from yesterday has been linked quite a bit, with plenty of discussion in the comments. I'd like to follow up on a few things.

First off, I want to correct the idea that we believe web applications are somehow trivial compared to desktop applications. This is not the case at all, and if any comments implied this I apologize. There's a place for both types of applications right now, and we use both web and desktop apps daily.

What we're talking about here is the difference between web apps - applications that run on a remote web server and require an internet connection, and desktop apps - applications that run locally, with access to the local disk and hardware.

Apple is attempting to say (to a room filled largely with Cocoa developers) "Hey, you've got all you need to get on the iPhone. Just make a web app!". If this is a perfect solution, there'd be no reason to have custom-built apps on the iPhone at all. For that matter, no one would need to care about Leopard or any new OS, as we could just build everything for Safari, and we'd be on the Mac, Windows, and iPhone. But in reality, desktop apps aren't going anywhere any time soon.

Creating web apps to run on the iPhone will be a great solution for many tasks, but it is not a new solution, nor Apple hasn't done anything new for developers. This is what we had from the get-go, when Apple announced there'd be a full-fledged browser on the phone. Web apps on the iPhone will also be stuck with something of a second-class status compared to local apps, as they can't be accessed from the main menu, they can't be used offline, they can't access the local disk, and more.

Is there anything we can't do with web apps? As our own Mike Ash pointed out in discussing this, all computer systems are Turing-complete. The issue is time and cost to gain equivalent functionality. We have hundreds of thousands of lines of code written in Cocoa along with years of experience, and we'd like to be able to reuse it. After all, the iPhone is running OS X.

We didn't demand nor even expect an SDK before the iPhone's release. This is a 1.0, and as Michael Tsai correctly states, "it’s in everyone’s interest for them to take their time and get it right". However, we would like a bit of forthrightness from Apple, instead of continued misdirection.

From FUD about bringing down networks and other security concerns to an already-obvious "SDK", Apple has bungled the developer relations for the iPhone. Nothing more, and nothing less. As a consumer, I'm still intrigued by the device. As a developer, I'm not terribly pleased with how things have gone.

Posted by Paul | Permalink | View/Post Comments (30)

Comments


Tom
Tue Jun 12 15:52:55 2007

And my response is: the iPhone is not a desktop computer.

MacG
Tue Jun 12 16:24:58 2007

@Tom That's really not true. Apple is pitching this, as a computer in your pocket.

Call 'em "phonetop" apps if you want, but it's still the same. Some apps on here have local access, run offline, and what not. Web apps don't.

Dave Lowe
Tue Jun 12 16:37:11 2007

Agreed. I think it makes sense that Apple doesn't want to risk anything quite yet, but they should have been upfront about that. Instead Steve said they'd come up with a great solution. No... not really, Steve... your "solution" boils down to this: use CSS to make your web apps look like one of the built-in apps!

mhuyck
Tue Jun 12 17:09:01 2007

I couldn't agree more about bungled developer relations.  The lack of an iPhone SDK is a worry, but far more disconcerting is the lack of forthrightness.

Perhaps Apple executives have been spending too much time hanging around making deals with slimy characters from the recording and wireless phone industries and the slime is starting to rub off on them...

Michael
Tue Jun 12 17:17:08 2007

"And my response is: the iPhone is not a desktop computer."

And my response is my Nokia e62 has Nokia-endorsed Python and Perl interpreters, in addition to a webkit based browser that can browse the full web, not just WAP. And it has java, and it has flash, and there is an Xcode plugin, and it has... You get the point. All it's missing is a good UI.

Frank 'viperteq' Young
Tue Jun 12 17:57:16 2007

I'm sorry. All I keep hearing from you guys is "Can't". "Web apps can't do this", "Web apps can't do that". Sheesh!!! The device isn't even out yet and you all are crying foul. The last time that I checked, web apps could access the local disk drive. Sure, it's only uploading and downloading, but really, what more do you need than that? If you're talking about Database access, that's what your server will be for.

Offline access even for traditional web applications is still a far way off from being something universally asked for, so why do you need it for the iPhone? Hell, a web app actually great sense because the iPhone is ALWAYS connected to the Net. Doesn't it have WiFi built in? And whenever the user doesn't have access to a WiFi network, they can get online using AT&T's data connection. And if you REALLY need offline access, then as a dev I'd suggest you try out Adobe's AIR runtime or maybe even give Microsoft's Silverlight runtime a try. And if none of those suit your fancy, the iPhone is supposedly running actual OS X with the actual Safari browser....an enterprising dev could certainly write a SIMBL plugin that gives you persistent offline storage capabilities.

Seriously, I know that you all are a bunch of dedicated Cocoa devs that would really like to push the envelope and reuse the various frameworks that you've written, etc., but really this is the best course of action for right now. I do agree that Jobs shouldn't have made the announcement sound as if they innovated in web app development for the benefit of Apple devs, but other than that, I don't really see the issue. If you don't want to invest the time needed to write a nice solid web app that will bring your company more users and more money, that's fine, don't do it. I'm sure that companies like 37Signals, We Break Stuff and 9Rules will be more than happy to step in take on the challenge.

Martin Pilkington
Tue Jun 12 18:26:57 2007

What people seem to be forgetting is that compared to Desktop APIs, web APIs are baby frameworks. This is not to say that they're not good, just that they offer a tiny fraction of the functionality a desktop framework can add. Now with regards to the apps that Rogue Amoeba make, it isn't just a case of wanting to reuse code, or not knowing web development (any good desktop programmer can pick up web development within a week or two). It's the fact that Audio software is simply not doable on the web.

AJAX and Web 2.0 are great, but they aren't the be all and end all of application development and they never will be, simple physics ensures that (seconds are longer than nanoseconds and when you can't change the speed of light that counts). Proof that web apps are still way behind desktop apps is the choice to create a desktop client for google maps on the iPhone

Now nobody is complaining about web apps being the only way to develop apps for the iPhone for now, it's simply the way Apple announced it. Personally I wouldn't find the iPhone that compelling a development platform even if it did support Cocoa apps, it just doesn't lend itself very well to the sorts of apps that I create.

Drew Thaler
Tue Jun 12 20:24:50 2007

You're absolutely right, Paul. An equivalent way for Steve to say what he said, but without pissing developers off, might have been this:

"Now, I know you're all interested in an iPhone SDK. We're still exploring our options and have nothing new to announce. But what I do want to show you is the way that AJAX/DHTML web applications will work beautifully in Safari on the iPhone."

See? Honesty, not bullshit. There would have still been disappointment, but everyone would feel a lot less like they were just being talked down to.

Personally I think a lot of the limitations are likely due to the certification process imposed by Cingular. Steve can't really complain or slam them because he want to keep a good relationship, but really this has been a surprising faux-pas for him. He usually knows his audience better than that.

Jarin Udom
Tue Jun 12 22:42:57 2007

It's not entirely true that web-based iPhone applications won't be able to work offline. They will if they support Google Gears or some other data cacheing and syncing API.

I wrote a short article about it on my blog: http://jarinudom.com/2007/6/13/will-the-iphone-work-with-google-gears

Anonymous Swine
Tue Jun 12 23:16:06 2007

@ Frank:

"And if you REALLY need offline access, then as a dev I'd suggest you try out Adobe's AIR runtime or maybe even give Microsoft's Silverlight runtime a try. And if none of those suit your fancy, the iPhone is supposedly running actual OS X with the actual Safari browser....an enterprising dev could certainly write a SIMBL plugin that gives you persistent offline storage capabilities."

Frank, I'm not sure how what you wrote above makes any sense at all. Adobe's AIR runtime, Microsoft Silverlight, a SIMBL plugin? Are you kidding me? How precisely do you propose for anyone to install an Adobe or Microsoft runtime, let alone develop and install a SIMBL plugin on the iPhone? Do you even understand what we're talking about here?

@ Jarin:

Isn't it safe to assume that if Apple were planning to deploy Google Gears on the iPhone it would have been part of Steve's keynote demo? The implication seemed pretty clear when he talked about "just update it on your server" that there would be no offline use.

Rich
Tue Jun 12 23:26:02 2007

Frank --

Your comment drips so much ignorance and the lack of any clue about how development (and web development) or the iPhone works that it's hard to even respond intelligently, especially considering your acidic tone.

Even so, I'll take a stab.  All the suggestions -- AIR, Silverlight... they require the type of access that developers are requesting.  SIMBL plugins?  Are you kidding me?  None of this will be available.  You will be stuck with web-apps that have significantly less ability than what will run on my Windows Mobile phone (which supports Java, Flash, and more) or most any other smartphone in existence.

foobaz
Wed Jun 13 00:43:03 2007

Turing-completeness doesn't do you any good if you're trying to interface with other components, like the address book or the touchscreen. The issue isn't the language so much as it's the available APIs.

snu
Wed Jun 13 05:00:56 2007

Turing-completeness also doesn't do you any good from a performance perspective. You can't implement anything even remotely processor intensive in JavaScript on the client-side, and the latency for a round-trip to the server makes that unfeasible for many applications.

RA fan
Wed Jun 13 05:50:08 2007

Turing-completeness makes rock stars' spouses happy.

But seriously, our hosts and any of the developers actually capable of writing decent Mac apps seem to be upset not so much by the fact the the iPhone API isn't public yet, but rather by Apple and Steve Jobs using the WWDC Keynote to announce that Web 2.0 was the iPhone API.

(Look at the current set of widgets available on Apple's site. For every useful one, there are dozens of useless "look, I put up a picture" and "yet another countdown" widgets of the types that Apple gave up and made Dashcode templates for. Even for the most talented programmers, developing a good app on a brand-new platform would surely take more than 18 days. If the iPhone API had been released this week, consumers' first impression of iPhone software would be a huge pile of useless countdown apps.)

What developers are apparently forgetting is that the WWDC Keynote addresses not only a few thousand Cocoa developers, but also millions of consumers, directly and through journalists.

If Apple had just said "no iPhone API," people would have heard "iPhone is missing desired feature!" (Not to mention even more whining from developers, of course.) If Apple had announced that the API would be published later, journalists and consumers would hear "future iPhones will have a feature current iPhones lack!" Either situation would have been bad for iPhone sales.

Instead, Apple said "developers can write Web apps for iPhone." People like Tom and Frank here heard "developers can write apps for iPhone." On June 29 they'll each buy a first-generation iPhone.

Sure, developers felt slightly insulted if they didn't consider the consumer/media impact of the Keynote. But it's not like Steve Jobs got up that morning and decided to annoy a bunch of developers for no reason. If he wanted to do that, he could have shown up on the projector screen and announced that he was going to quit and shut down Apple and the developers should just all go home....

Matt Thomas
Wed Jun 13 07:17:06 2007

While I do think it's possible to do amazing things with web-based applications (heck, look at all the features of google maps), one of the biggest drawbacks of web-based applications is that you need an internet connection to run it. While the iPhone does have WiFi and EDGE, that doesn't guarantee be a constant (or consistent) internet connection.

The thing that really bothered me was the fact that they said "We support developers" and then show us running a website. It wasn't even a widget! Even worse, it wasn't accessed through the main iPhone interface. It was in a safari bookmark.

We already knew the iPhone could go to bookmarked websites. Apple was trying to pass that off as something it wasn't.

Slarrg
Wed Jun 13 08:54:22 2007

I think some posters here are having a hard time understanding instances where local apps would be preferable to web apps. Web apps can be wonderful things (I've been the senior developer for a number of corporate and government intranets over the last 10 years) but they also have limitations.

1) Web apps expose data to outside entities. When a third-party writes an application, you install it locally and all of the data is maintained locally. This is not true for web apps. The google word processor and spreadsheet are great pieces of software but I would be upset if an employee under my charge was writing internal corporate documents on these services. Sensitive and private data should remain only on devices within your control.

2) Web apps are services. When I install a local application it functions exactly the same way from day one. Web applications can be changed at any time by the service provider without any notice. The most important feature for any given user could, potentially, be removed because it's not worth the headache for the service provider. Additionally, services need to be paid for on an ongoing basis. This could be through subscription fees or advertising but it is still the case.

3) Web apps require much more trust from the user. I'm guessing that many of you who argue in favor of web apps have never lost data as the result of a service provider going out of business or discontinuing a service. When it happens, it can be a very traumatic problem for anyone who relies on the service to fill a mission critical need. With an local app, you never have this exposure to risk.

4) Security is less convenient. Let's assume that a company can control the entire environment by writing a custom web app and hosting their own servers. As an example, we'll assume that the company requires employees to enter time and billing codes as they work on different projects. The phone is an ideal tool to allow the employee to enter this data since it will be with them when they are offsite or away from their desks. With a local application, they can allow the user to select a billing code and enter hours worked, later the phone can be synced to their office desktop computer and automatically transfer the data into the corporate database. With a web app, the user would need to find a location that allows an internet connection (you may have lousy reception in any given location), select the appropriate bookmark for the time entry system (perhaps a secure https connection), the user would need to enter their username and password (the data entry system cannot be wide open to the whole world, after all), then finally enter the time and code. In addition to being more cumbersome, the user needs to pay fees for transmitting data in each direction.

There are other problems, too, such as limited control over the interface interaction (multitouch, pinching, animation, etc.), access to specific local hardware (harddrive, camera, bluetooth, etc.) or other local software (contact information, calendar, photos, etc.).

Imagine smaller apps in which a user simply wants to keep track of expenses while on vacation to sync to a computer when he gets home and you'll see that it would be unlikely that the user would have the resources to keep his data private.

Web apps are not, by any means, a bad thing. They're just not the solution to every problem. Just because Apple only gave us a hammer does not make every problem a nail. It's insulting for Apple to insist otherwise while they continue to create local interfaces for internet data (Google Maps) which proves that they understand the limitations of a web app.

George M.
Wed Jun 13 10:31:35 2007

I think you guys are absolutely right to pick on Apple for pretending that web access is the same thing as a full iPhone SDK for developers.  It remains to be seen how extensive the web access is to the iPhone's features, but it's not premature to assume that it can never reach the same level of control as a full SDK would.

I'm of the opinion that having a true SDK was simply far too big of a task for Apple to accomplish at the same time as finishing the iPhone, so I happen to think that they're correct in not offering it at the same time as the phone's release.  I do wish they were more straightforward in explaining this, I think some developers would whine that they want an SDK NOW NOW NOW but most would understand the magnitude of work involved in making this happen, and would be willing to wait.

However as a developer (and part-time marketer due to my company), I do have a beef with this oft-repeated statement that the iPhone is marketed by Apple as a computer.  I beg to differ - that is YOUR interpretation of what the iPhone is, based on extrapolating the features it has and assigning your own label to those features.  If Apple really wanted you to think of the iPhone as a computer, they would say so directly - you'd see marketing tag lines like "Your Mac. In your pocket." or something to that effect.

No, what Apple is doing is far more subtle - they are telling users this is a "revolutionary phone".  Sure, some of its features are reminiscient of a computer (OS X, Safari, etc.), but essentially, this is a phone+iPod+internet device.  To an engineer, this may seem like a pointless distinction, but it means the world to end users from a marketing standpoint.  Computers are complicated and messy and somewhat annoying to a lot of end users.  They need things installed, need rebooting and special care and all that.  A cool phone, with a few extras in it, should be a reliable gadget you WANT to use every day, not just for work.  True, lots of people play games and do leisure stuff on their computer, but it's still a fundamentally different concept to sell a cool phone vs. a pocket computer.

So given that you guys started with "it's a computer, duh", you naturally assume Apple thinks so too, so it makes sense to think they're being insulting by not offering an SDK for it.  After all, what kind of "computer" doesn't allow 3rd parties to write software for it?  But has it occurred to you that maybe Apple doesn't think like you guys?  Maybe they're not offering an SDK at this point because they DON'T want people to think their shiny new toy really is a computer, at least not yet?

~bc
Wed Jun 13 13:26:28 2007

I think everyone is getting really upset, but without knowing the facts of the case.

First thing: the iPhone is not a Mac. Neither is an iPod, an AppleTV, nor an AirPort Express. Just because Apple makes a new product doesn't mean they're are going to let anyone develop for it, just because they allow developers to write for Macintosh. I'm not saying this is good or bad, I'm just stating it as fact. (I am a paying user of RA software, btw, several titles, I like Mac developers :-)

And this is all we know for sure about developing for the iPhone right now.

Everything here on out is speculation. Will Apple allow you keep your web-tech-based app on the phone, or will it only be temporarily accessed through a URL when a connection is live? Does anyone know this answer for sure? I can't find the answer on the ADC site, and everything happening at WWDC is NDA'd.

I think if Apple let web-based-apps have some sort of base on the iPhone for offline (albeit rarely) access that would be great. We need to know what type of system-level hooks Apple would supply that can be accessed via JavaScript. Steve said you would be able to access phone calls, adddresses, and GMaps, if I am not mistaken… how? Are there more hooks they're not announcing yet? Or none? We won't know until they tell us or it's released, or after, when they add more functionality.

The crux of all this is: we shouldn't get our panties all in a knot when we don't truly know what's happening with this brand new product.

All I know is an iPhone is not a Mac, and everything is new here. And I'm willing to wait and see for something that's ready to be talked about. I'd rather see that than them announce something then have to change for whatever reason.

(I also wrote more thoughts on this on my blog, WWDC 07

abcd
Wed Jun 13 13:45:52 2007

How many people will spend 600$ on a "cool phone" (= ipod nano + phone + browser capabilities)

ssp
Wed Jun 13 14:38:07 2007

However this will work out in the end. I think that compared to Cocoa, web applications will at least be much harder to make.

You don't need to look further than OS X's Dashboard for this. How many widgets have good support for things like localisations, number formats or just having the same UI behaviour as the rest of the OS? A: Quite a few. With the ubiquitous Weather widget being a prime culprit. Of course getting most of these things right isn't impossible in JavaScript, but actually doing so requires the programmer to be aware of all the details that Cocoa gets right automatically and then spend the time to actually implement them.

mark
Wed Jun 13 17:37:26 2007

Like the first poster said, the iPhone is not a desktop computer (a la Mac).  It is a special-purpose computer, in the same vein as an iPod or AppleTV, but it has two additional special purposes - phone and internet device. And as a phone and internet device, its job is to access services via the phone network and the internet.  (BTW, the AppleTV looks like it will become an internet device with the 10-ft interface.)

So Jobs said nothing to intentionally insult or spin.  His words were absolutely consistent with his view (which has been consistently advertised on the Apple site).  However, his words were completely opposed to the view held by developers who think of the iPhone as a computer, like a Mac, just because it runs OS X.

And yes, there is tremendous untapped potential because it is OS X.  But for now, the use of OS X is just an advantage internal to Apple.

Tom
Wed Jun 13 17:49:09 2007

"Instead, Apple said "developers can write Web apps for iPhone." People like Tom and Frank here heard "developers can write apps for iPhone." On June 29 they'll each buy a first-generation iPhone."

----

Yes, that's exactly what I heard, because I understand the power of JavaScript (and I happen to have a very cool technology, hopefully debuting soon, that I think a lot of the developers complaining here would love)

Of course none of Rogue Amoeba's existing apps could be implemented in JavaScript, but seriously, which of them would ACTUALLY be useful on the iPhone. Perhaps Airfoil but that's about it. In this respect, a large number of "desktop" applications would be completely useless on the iPhone.

That said, I definitely agree it would be nice to have access to hardware, filesystem, etc for CERTAIN types of applications, but I think JavaScript is perfectly suited for the vast majority of iPhone... especially once the above mentioned secret technology is released...

urs
Thu Jun 14 03:37:27 2007

hmm. reading all this and all over the web Developers are complaining, I actually can't understand why. I think that this is a very smart move for now.
I would like to hear from Developers of Applications for a phone, i mean really usefull on a phone, that couldn't be done with AJAX.
There is even Quicktime present on the phone, so music playing and video playing is done throug Quicktime.. who knows if this is not tied into safari on iPhone? Just a speculation.

Hearing what they said on the last Earnings call, this phone will be constantly upgraded.. (as the AppleTV will be, see YouTube): So who knows what comes along? 

But anyway, I'd really love to here what usefull apps for a phone you imagine, that couldnt be done  with AJAX?

Conor
Thu Jun 14 05:33:17 2007

"I'd really love to here what usefull apps for a phone you imagine, that couldnt be done  with AJAX?"

It's not that it can't be done with AJAX, it's what you lose by not being a regular app. Take my software for example, software to catalog your media, I can host users media on my server and display it for the iPhone; but as a future iPhone owner and DVDpedia user though I would want to be able to browse my collection even if I don't have internet access, if I do have EDGE access how much will AT&T charge me for downloading that data? And I have to get charged every single time I browse my collection. The iPhone has a very good resolution and as a user I would want crisp covers, how long will it take to download all the covers to scroll through them in cover flow style; how fast and reliable is EDGE? As a developer I lose the ability to leverage my familiarity with Cocoa, and the fact that I don't get an icon on the apps page. When it comes to marketing this is a huge advantage: "I am visiting DVDpedia's website to view my collection" is not as good as a user telling another "I have DVDpedia on my iPhone".

Pedro Miguel César de Carvalho
Thu Jun 14 14:39:55 2007

I am very sad with the "solution that Apple arrange for developers"!

But for all the people like me, I would like to say:
- Do not worry iPhone will be cracked, as Apple TV was... believe me it will not take long. And if it will be really needed we install Linux on it... look to the iPod linux. Apple will never stop our imagination.

Tom
Thu Jun 14 21:16:21 2007

Even if the iPhone is "cracked" and non-Apple people are able to execute their own (non-JavaScript) code on the iPhone I think it will be much harder than you think to write native iPhone applications...

Kai Cherry
Fri Jun 15 02:01:31 2007

Ok. I've written in a few places about this, but I think folks need to understand that developers have a different relationship with Apple than regular customers have.

And to my fellow devs, I have to ask you, after having worked with Apple for years and years:

"How could you confuse the marketing message from the business one? This is APPLE guys...c'mon"

We are supposed to know better. The iPhone "runs OS X" is marketing...it's a VERY narrow definition of what "OS X" is. You know the desktop requirements for the OS...did you really think a Pentium class cpu like the ARM was running Mac OS X? :)

Also...the iPhone is an iPod. No, really. It happens to be the Best NAND Flash-based iPod "evar"...but in the Grand Scheme of things, it's an iPod:

"An iPod...a phone...an internet device...an iPod...a Phone...an internet device...are you guys getting this yet?"

Apparently...

Not :)

Or as I asked another dev friend of mine that was crying in their ice cream: "Sooo...when is your new 5G iPod game coming out."

He got the point. Instantly. Because he's a Mac dev...he knows he's supposed to not take hyperbole from Apple any more literally than he'd take his own marketing :)

That said, Apple marketing kinda of did the "mouth writes check behind can't cash" thing with the iPhone; it's an iPod that happens to have phone and web...but it is not a "smartphone"...it's a music phone/"fashion phone".

The problem is...it is kinda hard selling a $600 music phone :) Those things are like...super cheap "with two year contract, plus mail-in rebate."

Selling a (ahem) smartphone in the $400-$600 range tho is less challenging...assuming that is what you are selling ;)

If anyone can do it, it will be them...much to the joy of Nokia and Sony Ericsson...since it helps them more than hurts them. They wouldn't mind pricing moving up  a bit more in the US to fall in line with Europe and Asia, where folks are used to paying more for premium mobiles, as opposed to the US where they pretty much have to strip them to making them attractive pricing-wise for operator subsidy.

Slarrg
Fri Jun 15 04:59:09 2007

@Connor:

In addition to your DVDpedia app, over the web, being slower and likely not to work when there's a slow connection or no connection at all. You also have to provide a robust server to host all of the user's data and plenty of storage space. The storage needs for the app are generally not that great for each user but in the aggregate on your server could be quite a bit of data.

In addition, you incur legal risks by hosting copyrighted images of each user's DVD covers which are certainly protected use for your users but not for you on a server. How much more will you need to charge for the software now? Should you charge a monthly fee to pay the ongoing server needs, too? Can you litigate the lawsuits that arise from Apple's chosen architecture that requires you to store the copyrighted images?

It will be very hard for you to compete in this arena as a small company but Amazon.com could build a web-based app for this and eat your lunch because they already have agreements in place for images. Of course, users will have no control over the images that get sent to their phone like they would with your app and users would have no control over the data associated with each DVD as with your app but the big company will be allowed to write an app that you cannot because of the architecture.

Also, as a user, I would not be real keen about anyone having all of my collection maintained on their server. It's nobody's business but my own which movies are in my collection. Why should they be sitting on a server for others to use as marketing data?

To those who mention the iPhone is not a computer:

I'm assuming this comment comes from users who are not developers. If you're a developer and saying this you are missing some serious fundamentals in your programming knowledge. Most apps I can think of writing for the iPhone would use fewer local resources on the iPhone as a local app than as the same thing running within a browser. Browsers use a fair amount of system resources just by their very nature. The more capable it is (Javascript, CSS, video, etc.) the more resources it consumes. Most apps that would be developed for the iPhone would need fewer resources as a stand-alone app than as a web based app on the phone itself. So if the argument is that we shouldn't be writing apps for the iPhone because it's not a powerful computer then, logically, we certainly shouldn't be writing them with a much more resource-intensive browser running them.

stingerman
Fri Jun 15 10:46:17 2007

I think all these comments are premature.  Apple just announced their Web 2.0 plus Ajax for the iPhone, they didn't give us enough detail to the extent of which they would be integrating it other than to say that the iphone would expose its functionality as services to the browser.  (I think this is a big deal in itself).

What we have are questions that need addressed. For example, will Apple support offline web apps, including a local store (google gears?)?  Will Apple give us the ability to have our own web2.0+Ajax iPhone App screen were users can add our apps to?  This seems new to Apple as well and that they are working out the details. 

Apple initially stated that initially there will not be a development platform for iPhone.  Now, they said they feel that they have an initial solution.  Really it seemed to be something that was only recently given the green light.  I don't believe in any way that Apple has past alpha on how all this will work together in the end.  June 29 is too soon for them to include what they will eventually design.  I think a 1.2 update will give us a better idea of where it is going.

MacG
Fri Jun 15 20:18:35 2007

@Kai Cherry - You're nuts. What the heck does the average user care about it running OS X? What does that mean to them? If it means anything, it's that this is A COMPUTER! Of course it's not running Mac OS X. But Steve Jobs has repeatedly stated that it's got everything you'd expect.

From D 2007: http://www.engadget.com/2007/05/30/steve-jobs-live-from-d-2007/

"12:42pm - But the iPhone doesn't REALLY have the whole OS X operating system on there...

The answer is: yes it does! The entire Mac OS is gigs, a lot is data. Take out the data -- every desktop pattern, sound sample -- if you look at Safari it's not that big. It's REAL Safari, REAL OS X. We put a different user interface on it to work with a multi-touch screen... it's an amazing amount of software."

"Real OS X" he said. Again, that means next to nothing to users, and everything to developers.

This is an iPod? Bull-F'ing-S. This is a computer. This is not "an iPod with extras" any more than it's "a phone with extras". This is a PDA, with iPod functionality, phone functionality, web functionality, and more. The iPod video is an iPod with extras.

But to call this an iPod? Please. You're drunk on kool-aid. Did Apple ever pitch an iPod this way, as a platform? No way.

@stingerman - Did you actually watch the keynote? Apple gave enough detail. "Exposing the iPhone functionality" is nothing, nada, zero. It's mailto: and tel: links. They didn't change anything to do this, they didn't "just give this the green light". This is Safari opening web pages, which it always did.

As far as the future, sure, it'll change, no doubt. But the issue here is a crummy marketing message, and poor developer relations.


This post is archived, and commenting has been closed.