3 May 2010

Daring Fireball: Middleware and Section 3.3.1

De Icaza argues that this is the sort of decision that should be up to third-party developers:

As a developer, I feel that I should be responsible for my technological choices. If I pick a cross-platform toolkit that looks horrible on the iPhone, it will just leave the space open for a competitor to do a better job. Or if my application does not take advantage of a new API in iPhone OS, I am also leaving a flank open for a competitor to take over. Apple does not need to intervene with guidelines as the application quality, the App Store, magazines, reviews and word of mouth are creating the conditions for an all-out darwinian survival of the fittest.

I think the above paragraph expresses very well the sentiment of many developers who strongly oppose, and in many cases are downright offended by, Apple’s new Section 3.3.1 restrictions. “Let me take the risk of a chasm opening between the middleware I want to use and the underlying Cocoa Touch frameworks,” more or less.

And that’s totally reasonable. But Apple’s perspective is reasonable too — they have suffered in the past when popular developer tools and frameworks have been out of their control. At this moment, Apple has the clout to forbid these “third party layers of software between the platform and the developer” by fiat. If they waited until actual compatibility problems arise in the future, it might be too late — at that point, if the incompatible middleware systems are popular enough, the clout will reside with the collective third-party developers relying upon the middleware, not with Apple. Apple can ban them by fiat now; they can’t ban them by fiat in a future where they’re in widespread use.

John Gruber nails it. This is why the MonoTouch users get all bent out of shape and why Apple doesn't appear to, nor should it, care that they get bent out of shape. They've been burned before. It hurt OS X.

Never again.

29 Apr 2010

Steve Jobs' Thoughts on Flash

Besides the fact that Flash is closed and proprietary, has major technical drawbacks, and doesn’t support touch based devices, there is an even more important reason we do not allow Flash on iPhones, iPods and iPads. We have discussed the downsides of using Flash to play video and interactive content from websites, but Adobe also wants developers to adopt Flash to create apps that run on our mobile devices.

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.

Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.

This cuts to the core of not only why Flash won't be a permitted dev tool for the iPhone OS, but also why tools such as MonoTouch shouldn't be allowed either.

15 Apr 2010

Another Reasoned Take On the New iPhone Developer Rules

But the reason isn’t technical. It’s partly business (Apple doesn’t want another company to control any important part of the iPhone platform), but it’s also in no small part grounded in aesthetics and the progress of the platform. Apple wants developers to do things the iPhone and iPad Way because they believe it will result in a better user experience and better designed apps. That’s an aesthetic, design-centered argument about how touch apps should be done. Apple has created tools customized to the iPhone and iPad; hell, they built a whole new touch-based operating system. They created a whole set of user interface metaphors that are supposed to be standard and system-wide, and they want developers to do things the new way not because Apple just loves power, but because they believe it’s necessary to force developers to think about the new world of touch-based computing correctly. All of this in service of giving users who are taking their first steps into touch-based computing a great experience.

...

Developers who want to write software for the iPhone have to write iPhone-like software. To do otherwise will hinder the progress of the platform.

I would be surprised if many of the people who want to use the cross-platform frameworks even read the iPhone Human Interface Guidelines (http://developer.apple.com/iphone/library/documentation/UserExperience/Concep.... This focus on a standardized user experience is alien to people accustomed to developing for the web, Flash, or even Windows. They don't understand it, it frustrates them, and they end up screaming "freedom" or "innovation."

Rarely is doing it right easy or cheap. Suck it up.

Contributors

Mike Pulsifer