Wil Shipley wrote a little blog post about the iPhone, lack of real SDK and a thing called AJAX. this started out as a comment, then grew up past an email, finally settling into a blog post rebuttal thing. that's why it's written largely in the second person. i was writing it directly to wil.
i also agree that it makes sense why they haven't released a real public api yet. i also believe that they will in time. i also think its gonna do away with a lot of cruft when they do. it's gonna be awesome dawesome. i'm saying i agree with a lot of what you're saying, but i couldn't disagree with you more ( in some places ).
Not very many companies on any platform are successful at selling web applications
1. That is kind of like saying "not very many companies are successful at selling mac applications". it's just demonstrably false. 37 signals knows a thing or two about making some scriller from web apps. flickr seems to be doing ok. wordpress.com makes money money. shopify is a web-app that makes money by enabling it's users to build web-apps that make money ( it's sooo postmodern ). fluxiom is pretty sweet. blinksale, the newsgator rss platform, dabbledb and on and on.
i'm not playing "nuh-uh, i've got these two or three exceptions so you're wrong" game for the sake of playing it. there are plenty of people are building web apps and selling them just fine. it's really no different than windows developers saying that "no one really makes any money selling mac apps, save for 3 exceptions." malarky.
I can't customize what controls the user sees from inside Safari.
2. is that really a deal breaker? you can't really control the window widgets in an os x app either. well, you can't but you don't. i imagine that you don't ( i mean, actually you wil, not the royal you, but actually wil shipley when you wrote DL ) because users expect those things to be there and that you actually like them there.
in fact, you expect them to be there because parts of your app depend on them. when i double click on a library item, a new window pops up that i can close by clicking that little red thingy in the corner and drag around by grabbing onto the metal stuff. same for the main DL window. as a user, i expect that to work that way. and you, as a developer, had to do nothing to get that behaviour. dope.
same is true of certain browser interface widgets. users hate having to figure out the custom back/forward mechanism in sites that are entirely flash. developers don't like making them either. i think its pretty swell that we get those for free. i do not want to keep track of your page views and there order while you're on my site.
wil, i know you like obj-c and cocoa. i know that you've said there is a recurring trend of people saying higher level languages are going to do away with C, but C just keeps on keeping on and there will always be a place for compiled languages. sure, sure. that's fine. something interesting is happening now though, that makes some of what seem less and less relevant.
page.delay(4) do page.select("td span.company").each do |column| column.set_style :fontStyle => "normal" end end
cocoa is essentially in bed with objective-c. they've definitely grown up together. but some new people are coming to the party. more languages are getting official backing from apple with cocoa bridges baked into leopard ( ruby, python ). rubycocoa and pyobjc.
this is the way that i ( and lots of others ) see application development going. higher level / interpreted languages. the more the expressive, the better. DSLs for languages that machines require of us, but we don't want to actually have to write. ( the rubinius folks have something called cuby that's a ruby looking DSL for generating C code. pretty awesome. ) a greater invasion of web technologies into desktop / hybrid apps. ( there will be desktop apps for a long long time. the line will just get blurred more and more. )
for my parting shot, imagine this equation. html interfaces using WebKit views. the bulk of your app written in ruby using rubycocoa to hook into that html interface. ActiveRecord talking to a SQLite db from the desktop app. a DSL (like cuby) for stubbing out C/obj-c code for areas that need to be optimized for speed. to me that sounds a lot like making a web app. in fact, it just might deliver a lot more of the write once promise that we've heard before. or at least some of it.
the web app version of the above is not too far off. ActiveRecord is still on the back end. this time maybe its talking to mysql or postgresql or oracle or even still SQLite. so that code doesn't need to change much, if at all. ruby code that handles the business logic specific to your app's domain. an html interface. maybe something like rjs sprinkled in there to replace some of what cocoa gives you ( which i fully admit that cocoa gives you lots and lots of cool things, like Core Animation ). then finally, instead of rubycocoa tying it all together on the web end, you use rails or merb.
that last part, switching out frameworks, i know is highly non-trivial, but doable. some very smart people will figure this out faster than you'd think. expect to see cool development happening in this space after leopard rolls out.