Cocoa for Windows + Flash Killer = SproutCore
June 14th, 2008
Daniel Eran Dilger
Regular readers will recall that when Safari for Windows shipped, I suggested Apple was likely looking to move its Mac OS X Cocoa development model into the Windows arena in order to broaden Cocoa’s visibility and adoption.
Over the last year, I’ve also outlined Apple’s efforts to starve Adobe’s Flash and AIR (and by extension, Microsoft’s me-too Flash plugin called Silverlight), at a time when pundits have insisted that Flash was a vital missing element on the iPhone and that Apple could/should/would be scrambling to port Flash to it. It might be a surprise to find that Apple’s air supply attack on Flash and its interest in dusting Windows with Cocoa are actually related.
Cuckoo for Cocoa: Is Safari on Windows the next iTunes?
Safari’s Controversial Potential as a New Yellow Box for Windows
Gone in a Flash: More on Apple’s iPhone Web Plans
Flash Wars: Adobe in the History and Future of Flash
A Few More Surprises.
It might also come as a surprise that Apple will soon release a suite of apps that will join QuickTime, iTunes, and Safari on the Windows platform. Like Apple’s existing Windows apps, the new ones will all put the Mac OS X user interface in front of millions of new users. Additionally, they will also advance Cocoa-style development in front of a much larger audience, because Apple is also giving away the frameworks it used to create those new apps.
Another surprise is that all those apps will also run cross platform on Linux. How will Apple do this? Not by shipping a large, cross platform Yellow Box runtime for various other operating systems as it attempted to do back in 1997.
Instead, Apple is refining Cocoa for deployment within the web browser to enable developers to build those so called “Rich Internet Applications” that Adobe wants users to build in Flash/Flex/AIR, Microsoft in Silverlight, Sun in Java, and so on.
Despite the marketing efforts of Adobe, Microsoft, Sun, and other RIA toolkit vendors to generate a level of RIA hype that echos the client Java excitement of the mid 90s or the thin client enthusiasm of the late 90s, RIAs haven’t really taken on the world by storm. Instead, Flash, Silverlight and other proprietary tools and their required runtime plugins are all still aiming at some future date when they can claim the status of being the platform monopoly in RIA development.
The Challenge of Funding Open Tools Development.
One might think that all web developers would flock to free and open solutions rather than selling themselves into slavery to a propriety web-like platform such as Flash or Silverlight. After all, once they’re dependent upon those runtimes, the power will lie with Adobe and/or Microsoft and competitive pressures to improve those tools will dry up, just as Windows and Internet Explorer flatlined after reaching their monopoly critical mass.
Of course, one might also think that PC makers would embrace free and open Linux, but that largely hasn’t happened either, for many of the same reasons. The problem in both cases is that open web standards don’t directly make anyone rich. Nobody owns them, so as with Linux, nobody can make much of a business model out of investing development efforts into improving them… unless they do so indirectly or for indirectly strategic purposes, as RedHat and IBM do in profiting from sales Linux related services.
Indirect strategies explain why both Google and Apple share the same strong affinity for an open web, in contrast to more short sighted developers would would blindly shackle themselves to Flash or Silverlight simply because those tools might help them accomplish their immediate objectives without too much effort.
Why Google and Apple Want an Open Web.
Google is investing in standards-based tools for web development because it wants an open Internet; Google needs an open web because it can’t compete and sell ads if Adobe or Microsoft infect the open web with proprietary Flash or Silverlight plugins and subsequently convert web content into opaque binaries instead of open HTML.
Apple doesn’t sell ads, it sells hardware. But if the web requires Flash or Silverlight to run, Adobe or Microsoft can either intentionally kill alternative platforms like the Mac (or Linux), or simply make them work so poorly due to their own incompetence that those platforms risk becoming non-viable. Adobe has already proven its incompetence in delivering Flash for the Mac (and really any platform outside of Windows), and I shouldn’t need to recap Microsoft’s historical readiness to destroy anything that isn’t Windows.
And so Google and Apple are bound together by different interests that happen to converge: Google wants the web open so it can sell ads, while Apple needs it open so it can sell hardware that browses the web well. Currently, the two companies are both working to achieve these goals in independent, often complementary ways.
Google’s API Inexperience.
Google introduced its Google Gears as a mechanism for beefing up rich web apps with offline storage. However, Google’s API development experience is really limited to exposing access to its web services such as Maps, Gmail, and others. Google Gears, Android, and the company’s other efforts to deliver significant new platform APIs are still unproven.
An an example, Google’s progress in delivering the Android SDK, while introduced back in November 2007, has been eclipsed by Apple’s iPhone SDK both in release cycles and in sophistication and polish since its debut in February 2008.
Another problem for Google is that it doesn’t have a large and committed user base. Google has contributed a lot code to the community, but that doesn’t mean that the community will necessarily use it.
The Apple of Your API.
In contrast, Apple has very strong and mature development tools and platform frameworks that have been proven in the marketplace for many years and are widely adopted in the markets Apple competes in.
Apple originated the first mainstream graphical platform with the Mac. That model subsequently served as the basis for Microsoft’s Windows, which grew into popularity as Apple lost itself in the conundrum of Copland in the early 90s.
Apple employees who left in the late 80s to form NeXT created the first mainstream object oriented platform frameworks, again establishing the standard that the rest of the industry would aspire to clone or use as a reference to develop upon. Apple and IBM’s Taligent, Sun’s Java, and Microsoft’s unfinished Cairo all intended to ship something that NeXT already had in production use among high profile clients.
Apple’s API Philosophy.
After the remains of the old Apple acquired NeXT in 1996 and began work on Mac OS X, the company worked to continually develop and refine its desktop APIs using a unique philosophy that focuses upon:
- enabling features
- abstaining from developing unnecessary APIs
- iterating over code to refine it
- and delivering quality over quantity.
Apple’s emphasis on code quality and elegance in the API has allowed Apple to move faster than Microsoft over the last decade while also preventing Apple from having to painfully revisit major legacy problems resulting from sloppy coding and poor planning. That in turn has rebuilt Apple’s reputation in API development following its mid 90s Copland disaster.
Despite having a significant following of developers behind its desktop platform, Apple hasn’t begun resting on past performance. With the iPhone, Apple didn’t just directly port its desktop Cocoa API, but took the opportunity to refine and rethink how things should work given an entirely new set of circumstances and the opportunity to start fresh. As cited by the SproutCore blog from the Apple document “iPhone Getting Started Docs,”
“One of the biggest differences is the extensive use of properties throughout the UIKit class declarations. Properties were introduced to Mac OS X in version 10.5 and thus came along after the creation of many classes in the AppKit framework. Rather than simply mimic the same getter and setter methods in AppKit, UIKit employs properties as a way to simplify the class interfaces. For information about properties, see Properties in The Objective-C 2.0 Programming Language.”
Apple’s Cocoa Flavored Open Web.
One of the biggest announcements of WWDC was Mobile Me, a rebranding of .Mac that aligns it with the iPhone and cross platform users. Apple added a new web calendar and contacts, and a revised Mail and iDisk online file manager modeled after the Finder. The Gallery component of Mobile Me is an update of the existing .Mac version of Web Gallery, which was built using an earlier version of SproutCore.
Charles Jolley’s SproutCore.
Cocoa Bindings Programming Topics: What Are Cocoa Bindings?
Oh No, Web Apps?
That makes SproutCore a light Cocoa alternative for deploying web apps that look and feel like Mac OS X desktop apps. At WWDC, Dr. Michael B Johnson of Pixar gave a lunchtime presentation where he pointed out that if you don’t need 64-bit addressing, multithreading, or other desktop-only features, it makes a lot of sense to deploy apps using the web.
But aren’t web apps awful? They historically have been, particularly in the days when every server response required a page load. The development of Ajax technologies, which allow the current page to draw new data from the server asynchronously in the background, has helped. Modern Ajax websites such as Flickr offer drag and drop features, and Google’s use of Ajax in its web apps has made them more desktop-like, but web apps are often well behind those designed for the desktop in terms of a usable interface.
SproutCore helps push things forward; it keeps rich interaction local within the user’s browser and supports offline functionality, making web apps behave more like desktop apps and less like the constantly reloading HTML pages that users dislike. They also look like desktop apps, and in particular can look like Mac OS X desktop apps.
The SproutCore framework also solves a lot of problems for web developers. It takes care of browser incompatibility issues to run cross-platform in Safari, Firefox, or Internet Explorer 6/7. It also makes it easy to leverage the fancy CSS features of modern browsers.
A Front End to WebObjects, WebDAV.
SproutCore also delivers the premise of thin client computing, where applications all run remotely from a back end server and therefore don’t need to be installed or managed on every client.
The disadvantage of thin client apps is that they have typically offered minimal functionality due to the weaknesses in thin platforms such as the web. SproutCore solves this by relying on modern web browser features, which are now sophisticated enough to enable thick client web apps.
SproutCore web apps also combine the power and flexibility of web services with the advantages of client-server computing, prompting Apple to refer to the new model as “web client – server.” In Mobile Me, its new web apps tie into web services vended by WebObjects and WebDAV servers, but anyone can build SproutCore web apps that tie into PHP or any other existing servers that offer up data in XML or JSON objects.
Thinking Outside the Yellow Box.
Being based on open web standards and being open source itself means SproutCore will enable developers to develop cross platform applications without being tied to either a plugin architecture or its vendor.
Sitting on top of web standards will also make it easy for Apple and the community to push SproutCore ahead without worrying about incompatible changes to the underlying layers of Windows, a significant problem for the old Yellow Box or some new Cocoa analog. SproutCore also lives in a well known security context, preventing worries about unknown holes being opened up by a new runtime layer.
Make Apple SaaS.
All of this advances some interesting new potentials. Apple already has a silent lead in the consumer “Software as a Service” market with .Mac; While Google, Yahoo, and MSN have built models around pushing ads to fund their online mail, photos, and other applications, Apple has been quite unique in being actually able to sell its .Mac service to subscribers. Everybody wants to do what Apple is actually doing.
Mobile Me will retarget .Mac to also serve iPhone users, greatly widening its potential audience and putting Apple’s Mac OS X apps in front of a lot of Windows users. In the future, Apple will undoubtedly add new apps to its Mobile Me suite. Will it get into the online Office race with SproutCore versions of its iWork apps, available to both Mac and Windows users? How about an expanded Back to My Mac, with direct home file sharing and VNC Screen Sharing services available over the web?
And what about third parties? Surely there are enterprising developers who’d like to get in on the Mobile Me platform. Apple should consider hosting third party web apps, either bundled as part of the service (and making Mobile Me more valuable) or as additional apps users can subscribe to for a small additional cost. Imagine a Mobile Me version of QuickBooks that offered similar direct web access and mobile push sync with the iPhone.
The WebApps Store.
Web developers have often found it rather impossible to sell their services, but Apple can solve this problem just as it is solving the same problem in mobile software. By offering the equivalent of an iPhone Apps Store within Mobile Me, Apple could create a viable subscription market for web apps and web services that worked like an extension of iTunes. In fact, Apple could add a WebKit view in iTunes and use it to display Mobile Me apps to a wide audience, tied right into iTunes for billing.
Of course, Apple doesn’t need the iTunes infrastructure to sell web apps, as it also has Safari for Windows and its apps also run in Firefox or Internet Explorer. If you thought the Apps Store was interesting, a market inside of Mobile Me should really get interesting.
With everyone clamoring over Facebook for offering Flash-like applets as a free service in the high turnover, profitless profile market, perhaps Apple’s ability to serve real applications and web services as a paid service to its highly loyal users who are driving record profits will get some attention, too.
WWDC 2008: New in Mac OS X Snow Leopard
Myths of Snow Leopard 1: PowerPC Support — RoughlyDrafted Magazine
Myths of Snow Leopard 2: 32-bit Support
Myths of Snow Leopard 3: Mac Sidelined for iPhone
Myths of Snow Leopard 4: Exchange is the Only New Feature!
Myths of Snow Leopard 5: No Carbon!
Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!