It’s possible, however, to bring over some of the ideas from the Land of Lisp to other languages. Indeed this is essentially what has been happening for the past several decades, people just call it something different (“a new language”, or “new features”). Today, I’d like to show what happens when you bring one such idea to Objective-C:

It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.

—Alan Perlis

PXSourceList is a wonderful and popular Cocoa view for creating iTunes-like source lists created by Alex Rozanski:

Unfortunately, the example code that created the screenshot above suffers from a very common programming paradigm called Object Oriented Programming (OOP). The OOP paradigm has dominated Earth’s developers for the past several decades. I used to follow (and teach!) it, but after learning Clojure, I’ve changed my mind. I now agree with the Alex Rozanski quote above and Rich Hickey: it is better to have a small number of core data structures (preferably immutable) that are manipulated by hundreds of functions.

For this post, I will focus on just one of the many benefits of dropping the OOP perspective: code brevity.

The chief source responsible for the screenshot above is copied below. My point here isn’t to ask you to actually read through all of it, just note its size.

Instead of this:

// =========================
// = File SourceListItem.h =
// =========================

#import <Cocoa/Cocoa.h>

@interface SourceListItem : NSObject {
    NSString *title;
    NSString *identifier;
    NSImage *icon;
    NSInteger badgeValue;

    NSArray *children;
}

@property (nonatomic, copy) NSString *title;
@property (nonatomic, copy) NSString *identifier;
@property (nonatomic, retain) NSImage *icon;
@property NSInteger badgeValue;

@property (nonatomic, copy) NSArray *children;

//Convenience methods
+ (id)itemWithTitle:(NSString*)aTitle identifier:(NSString*)anIdentifier;
+ (id)itemWithTitle:(NSString*)aTitle identifier:(NSString*)anIdentifier icon:(NSImage*)anIcon;

- (BOOL)hasBadge;
- (BOOL)hasChildren;
- (BOOL)hasIcon;

@end

// =========================
// = File SourceListItem.m =
// =========================

#import "SourceListItem.h"

@implementation SourceListItem

@synthesize title;
@synthesize identifier;
@synthesize icon;
@synthesize badgeValue;
@synthesize children;

#pragma mark -
#pragma mark Init/Dealloc/Finalize

- (id)init
{
    if(self=[super init])
    {
        badgeValue = -1;    //We don't want a badge value by default
    }

    return self;
}

+ (id)itemWithTitle:(NSString*)aTitle identifier:(NSString*)anIdentifier
{
    SourceListItem *item = [SourceListItem itemWithTitle:aTitle identifier:anIdentifier icon:nil];

    return item;
}

+ (id)itemWithTitle:(NSString*)aTitle identifier:(NSString*)anIdentifier icon:(NSImage*)anIcon
{
    SourceListItem *item = [[[SourceListItem alloc] init] autorelease];

    [item setTitle:aTitle];
    [item setIdentifier:anIdentifier];
    [item setIcon:anIcon];

    return item;
}

- (void)dealloc
{
    [title release];
    [identifier release];
    [icon release];
    [children release];

    [super dealloc];
}

- (void)finalize
{
    title = nil;
    identifier = nil;
    icon = nil;
    children = nil;

    [super finalize];
}

#pragma mark -
#pragma mark Custom Accessors

- (BOOL)hasBadge
{
    return badgeValue!=-1;
}

- (BOOL)hasChildren
{
    return [children count]>0;
}

- (BOOL)hasIcon
{
    return icon!=nil;
}

@end

// ======================
// = File AppDelegate.m =
// ======================

#import "AppDelegate.h"
#import "SourceListItem.h"

@implementation AppDelegate

#pragma mark -
#pragma mark Init/Dealloc

- (void)awakeFromNib
{
    [selectedItemLabel setStringValue:@"(none)"];

    sourceListItems = [[NSMutableArray alloc] init];

    //Set up the "Library" parent item and children
    SourceListItem *libraryItem = [SourceListItem itemWithTitle:@"LIBRARY" identifier:@"library"];
    SourceListItem *musicItem = [SourceListItem itemWithTitle:@"Music" identifier:@"music"];
    [musicItem setIcon:[NSImage imageNamed:@"music.png"]];
    SourceListItem *moviesItem = [SourceListItem itemWithTitle:@"Movies" identifier:@"movies"];
    [moviesItem setIcon:[NSImage imageNamed:@"movies.png"]];
    SourceListItem *podcastsItem = [SourceListItem itemWithTitle:@"Podcasts" identifier:@"podcasts"];
    [podcastsItem setIcon:[NSImage imageNamed:@"podcasts.png"]];
    [podcastsItem setBadgeValue:10];
    SourceListItem *audiobooksItem = [SourceListItem itemWithTitle:@"Audiobooks" identifier:@"audiobooks"];
    [audiobooksItem setIcon:[NSImage imageNamed:@"audiobooks.png"]];
    [libraryItem setChildren:[NSArray arrayWithObjects:musicItem, moviesItem, podcastsItem,
                              audiobooksItem, nil]];

    //Set up the "Playlists" parent item and children
    SourceListItem *playlistsItem = [SourceListItem itemWithTitle:@"PLAYLISTS" identifier:@"playlists"];
    SourceListItem *playlist1Item = [SourceListItem itemWithTitle:@"Playlist1" identifier:@"playlist1"];

    //Create a second-level group to demonstrate
    SourceListItem *playlist2Item = [SourceListItem itemWithTitle:@"Playlist2" identifier:@"playlist2"];
    SourceListItem *playlist3Item = [SourceListItem itemWithTitle:@"Playlist3" identifier:@"playlist3"];
    [playlist1Item setIcon:[NSImage imageNamed:@"playlist.png"]];
    [playlist2Item setIcon:[NSImage imageNamed:@"playlist.png"]];
    [playlist3Item setIcon:[NSImage imageNamed:@"playlist.png"]];

    SourceListItem *playlistGroup = [SourceListItem itemWithTitle:@"Playlist Group" identifier:@"playlistgroup"];
    SourceListItem *playlistGroupItem = [SourceListItem itemWithTitle:@"Child Playlist" identifier:@"childplaylist"];
    [playlistGroup setIcon:[NSImage imageNamed:@"playlistFolder.png"]];
    [playlistGroupItem setIcon:[NSImage imageNamed:@"playlist.png"]];
    [playlistGroup setChildren:[NSArray arrayWithObject:playlistGroupItem]];

    [playlistsItem setChildren:[NSArray arrayWithObjects:playlist1Item, playlistGroup,playlist2Item,
                                playlist3Item, nil]];

    [sourceListItems addObject:libraryItem];
    [sourceListItems addObject:playlistsItem];

    [sourceList reloadData];
}

By using “special” dictionaries, we can greatly reduce code size, and enhance flexibility

Clojure has the concept of “records”. These are basically “special dictionaries” (AKA maps). Clojure uses maps/dictionaries all over the place, because it realizes that it’s not only not necessary to create a new class for every type of data you have, but it’s counter-productive.

Today I spent some time adapting the idea of Clojure’s records into its Objective-C equivalent simply through the creation of categories on the NSDictionary and NSMutableDictionary classes. The result is that I was able to reproduce the screenshot above with the following code (equivalent sections to the ones above):

// ======================
// = File AppDelegate.m =
// ======================

#import "AppDelegate.h"

@protocol SourceListItem
@property (nonatomic, retain) NSString *title;
@property (nonatomic, retain) NSString *identifier;
@property (nonatomic, retain) NSNumber *type;
@property (nonatomic, retain) NSImage *icon;
@property (nonatomic, retain) NSMutableArray *children;
@end

@implementation AppDelegate

- (void)awakeFromNib
{
    sourceListItems = [[NSMutableArray alloc] initWithObjects:
                       _MD(@"title", @"LIBRARY",
                           @"identifier", @"library",
                           @"children",
                           NSARY(_MD(@"title", @"Music",
                                     @"identifier", @"music",
                                     @"icon", NSIMG(@"music")),
                                _MD(@"title", @"Movies",
                                    @"identifier", @"movies",
                                    @"icon", NSIMG(@"movies")),
                                 _MD(@"title", @"Podcasts",
                                     @"identifier", @"podcasts",
                                     @"icon", NSIMG(@"podcasts")),
                                 _MD(@"title", @"Audiobooks",
                                     @"identifier", @"audiobooks",
                                     @"icon", NSIMG(@"audiobooks")))),
                       _MD(@"title", @"PLAYLISTS",
                           @"identifier", @"playlists",
                           @"children",
                           NSARY(_MD(@"title", @"Playlist1",
                                     @"identifier", @"playlist1",
                                     @"icon", NSIMG(@"playlist")),
                                 _MD(@"title", @"Playlist Group",
                                     @"identifier", @"playlistgroup",
                                     @"icon", NSIMG(@"playlistFolder"),
                                     @"children",
                                     NSARY(_MD(@"title", @"Child Playlist",
                                               @"identifier", @"childplaylist",
                                               @"icon", NSIMG(@"playlist")))),
                                 _MD(@"title", @"Playlist1",
                                     @"identifier", @"playlist1",
                                     @"icon", NSIMG(@"playlist")),
                                 _MD(@"title", @"Playlist1",
                                     @"identifier", @"playlist1",
                                     @"icon", NSIMG(@"playlist")))),
                       nil];
    [sourceList reloadData];
}

Not only is the code above more flexible and significantly shorter, but it’s clearer as well! You can practically visualize the GUI’s structure from the code itself!

The rest of the code (related to the delegate methods) is essentially equivalent, except it’s again, shorter.

“Magic” Dictionaries with Properties!

Dictionaries are created using the _MD and _D macros (for creating mutable and immutable dictionaries, respectively). These are plain old standard Foundation dictionaries. They can be saved to the hard disk, read back, key-value coded, etc. The reason for the macros is code brevity and because they use a new dictionaryWithKeysAndObjects: method that’s added to all dictionaries through the categories (I have no idea why Apple’s engineers throught it would be better to have values come before keys as with dictionaryWithObjectsAndKeys:…).

Next, let’s have a look at how dictionary values are manipulated and obtained. Most semi-intelligent languages have a map literals and simple syntax for fetching and setting map key/value pairs. Objective-C has no such intelligence imparted to it. However, it does have the very nifty forwardInvocation: mechanism. By combining forwardInvocation: with Objective-C protocols and properties, it’s possible to create “Objective-C records”.

Instead of this:

- (NSUInteger)sourceList:(PXSourceList*)sourceList numberOfChildrenOfItem:(id)item
{
    //Works the same way as the NSOutlineView data source: `nil` means a parent item
    if(item==nil) {
        return [sourceListItems count];
    }
    else {
        return [[item children] count];
    }
}

We can now use the dot-syntax notation to do this:

- (NSUInteger)sourceList:(PXSourceList*)sourceList numberOfChildrenOfItem:(id<SourceListItem>)item
{
    return item ? [item.children count] : [sourceListItems count];
}

Behind the scenes, item.children is turned into [item objectForKey:@"children"].

Setting values is also done through the standard dot-notation of Objective-C properties:

- (void)sourceList:(PXSourceList*)aSourceList setObjectValue:(id)object forItem:(id<SourceListItem>)item
{
    item.title = object;
}

Grab on Github

You’ll find the project for TERecord here, and the converted example of PXSourceList here.

Some of these “sub-standard” applications appear to include:

• The popular Rolando 2 for breaking 3.3.1 and 3.3.2 (Lua interpreter)
• Zombieville, #1 in all Games for a while, a Unity3D game (breaking 3.3.1)
• Ravensword: The Fallen King, #1 in Role-Playing at one point, also a Unity3D game.
• Broken Sword, a top-selling RPG game, for apparently using the SCUMM scripting language
• And yes, it turns out that Tap Tap Revenge does indeed violate both 3.3.1 and 3.3.2 for using Lua
• Command & Conquer Red Alert and Star Wars The Force Unleashed both seem to interpret proprietary scripts, violating 3.3.2.

It will be interesting to see how Apple responds to this. If they ignore it, is that essentially a green light to break their TOS, so long as you’re not on their shitlist and your name doesn’t begin with an ‘A’ and end in ‘dobe’?

This type of selective enforcement and hypocrisy does not breed developer loyalty and trust, rather, it fosters animosity and FUD.

Just in case the Google Docs link goes down here’s a mirror: (PDF | XLS).

On MonoTouch and other 3rd Party Tools

Some people appear to be under the mistaken impression that these changes are designed to prevent Java-like “non-native” UIs on the iPhone.

To be clear, the situation on the iPhone is completely different from that of the Mac. From the user’s perspective, you cannot tell the difference between an application written using MonoTouch or NimbleKit or Unity3D (non-Apple sanctioned tools that allow developers to code for the iPhone in non-C languages), and those written using Apple’s tools and Objective-C.

They look and feel exactly the same.

This is because they’re all using Apple’s UIKit to display the UI. In the case of Unity3D, which produces OpenGL games, you can’t tell whether the game was made using Unity3D or directly in Xcode, so it’s dubious that this is solely about “quality control” and keeping a uniform UI. If that was their sole motivation they could simply mandate that all non-OpenGL user interfaces make use of the native Cocoa frameworks and widgets.

Is it possible that these applications might be somehow better, perhaps faster, were they written directly with Apple’s tools? Maybe. Is that reason enough to outright ban them though? There are already hundreds of apps on the AppStore built using Unity3D, some of which are best-sellers.

There appear to be rumors online that even the Tap Tap Revenge game that Steve demoed during the iPhone 4.0 keynote is partially written in the Lua programming language. Oops.

It’s not surprising though (if true), because many popular games use a non-C scripting language for their game’s logic. It’s a versatile and common practice that gives developers (and even users) flexibility and creative freedom.

Whether Apple will remove these games I don’t know (I doubt it really). If they don’t, it’s hypocrisy because the wording of Section 3.3.1 clearly forbids it, and if they do then a bunch of great apps get pulled, a bunch of great developers get screwed, and a bunch of users are left disappointed. Even if they don’t pull these apps, Section 3.3.1, in its current state, is likely to deter future developers from taking advantage of these powerful techniques.

On Firefox

Many commenters seemed to be confused as to why I brought up Firefox. That discussion was tangential to the issues with Section 3.3.1. Steve referred to the “intermediate layers” that have existed on the Mac, suggesting that they all ultimately lead to sub-standard applications:

We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.

Though there is truth to that I feel it is only half the story.

The question isn’t whether you agree or disagree about the quality of cross-platform applications, but whether they should be allowed to exist on a platform at all (please don’t forget we’re still talking about the Mac, not the iPhone, where most, if not all, 3rd party toolkits produce native-looking applications).

As far as the Mac is concerned, I’m grateful for the existence of high quality cross-platform software such as Firefox. A lot of people were puzzled at why I chose Firefox as an example of high-quality cross-platform software, the reason is simple: it fulfills my needs for web browsing better than every other web browser.

Only because so many people brought it up, here’s a brief list of features that explains why I feel this way, and please note that I consider the availability and quality of plugins/add-ons as part of the browser’s whole:

• The Firefox AwesomeBar is awesome. It’s like Spotlight for your web browser.
• Firefox’s bookmarks allow both tags and descriptions, which I make heavy usage of.
• I love Firefox’s find-as-you-type feature.
• I can drag my Firefox data folder to any machine on just about any operating system and everything will just work there.
• I’ve noticed that Firefox uses far less RAM than Safari on my MacBook Pro. Where Safari will use upwards of 1.5GB of RAM, Firefox will use only about 800MB for the same “level of browsing,” and it’s far better about clearing that out when you close windows. To those who claim the opposite to be true, I suggest you delete your Firefox application support folder and reinstall the latest version.
• Firefox’s diverse and remarkably powerful addons are my #1 reason for using it. Many of the addons that I use have no equivalent on other browsers, and this simply seals the deal for me. Some of my personal favorites, in no particular order, include: Tab Mix Plus, ProxyButton, Session Manager, URL Link, WikiLook, Adblock Plus, BlockSite, DownloadHelper, Firebug, and Greasemonkey.

Why does Firefox have so many awesome add-ons while Safari and other browsers do not? Oh, that’s right, it’s because Firefox runs on just about every operating system, and the addons are cross-platform as well. Firefox’s users thereby reap the benefits that an open platform and an army of developers provides.

Sure, Firefox doesn’t integrate with OS X’s Services and other Cocoa-only things, but for me it more than makes up for those relatively benign flaws, and I’m grateful to have it prominently displayed in my Dock.

EDIT: It appears the latest versions of Firefox do integrate with OS X’s Services. Some minor Cocoa functionality still appears to be missing (like the Dictionary lookup shortcut, though there are add-ons for that), but this is certainly a pleasant surprise. I could only find this two year old article referencing the changes.

Conclusion

Don’t let the digression on Firefox fool you into thinking that I’m demanding Apple allow XUL apps like Firefox on the iPhone. That’s not what Section 3.3.1 is about.

Section 3.3.1 bans applications that look and behave like all the other “native” apps on the iPhone, but are “originally written” in languages other than C/C++/Objective-C. Details here and here, and there’s also this excellent 37signals post.

Update (4/12/10): Existing iPhone Apps Breaking the TOS

Update (9/10/10): Eventually, Apple updated and relaxed their terms.

Hi Steve,

Lots of people are pissed off at Apple’s mandate that applications be “originally written” in C/C++/Objective-C. If you go, for example, to the Hacker News homepage right now:

<http://news.ycombinator.com/>

You’ll see that most of the front page stories about this new restriction, with #1 being: “Steve Jobs Has Just Gone Mad” with (currently) 243 upvotes. The top 5 stories are all negative reactions to the TOS, and there are several others below them as well. Not a single positive reaction, even from John Gruber, your biggest fan.

I love your product, but your SDK TOS are growing on it like an invisible cancer.

Sincerely,
Greg

His response:

We think John Gruber’s post is very insightful and not negative:

http://daringfireball.net/2010/04/why_apple_changed_section_331

Steve

Of course he was right, I had somehow missed that post by Gruber, having only read the original. Gruber’s second post, which Jobs appears to be endorsing here, is indeed, very insightful, and may explain Apple’s motivations for the updates to section 3.3.1.

That said, I did not, and still don’t, consider those reasons to be very good, so I sent a reply in kind:

Sorry. I didn’t catch that post, but I finished it just now.

I still think it undermines Apple. You didn’t need this clause to get to where you are now with the iPhone’s market share, adding it just makes people lose respect for you and run for the hills, as a commenter to that article stated:

“So what Apple does not want is for some other company to establish a de facto standard software platform on top of Cocoa Touch. Not Adobe’s Flash. Not .NET (through MonoTouch). If that were to happen, there’s no lock-in advantage.”

And that makes Apple evil. At least, it does in the sense that Google uses the term in “don’t be evil” – I believe pg translated “evil” as something along the lines of “trying to compete by means other than making the best product and marketing it honestly”.

From a developer’s point of view, you’re limiting creativity itself. Gruber is wrong, there are plenty of [applications] written using cross-platform frameworks that are amazing, that he himself has praised. Mozilla’s Firefox just being one of them.

I don’t think Apple has much to gain with 3.3.1, quite the opposite actually.

Sincerely,
Greg

Within about 3 minutes a second reply graced my inbox:

We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.

With replies this short (understandably, of course) I can only guess at his meaning. Perhaps he’s referring to the days when some applications were being written with CodeWarrior and various other build systems. Or maybe he’s referring to the transition from Carbon-based applications to fully Cocoa applications (like Apple’s own Finder), or applications that were written using Macromedia’s Shockwave, or applications written in pure Java or those written in the now-defunct Java-Cocoa bridge. Perhaps it’s a bit of all of these.

Sure, many of the apps written using these systems aren’t very pretty, but can you imagine a Mac without Mozilla’s Firefox? Or a Mac that couldn’t run applications written in Python, Ruby, Java or a myriad of other languages? You would probably consider such a Mac severly handicapped. I don’t believe the existence of these in any way hampers Apple’s ability to progress the Mac platform, to the contrary, they enhance it. The existence of some sub-standard applications should not remove our ability to use those works of art that just so happen to be written without the aid of Apple’s tools.

I have nothing against Apple’s desire to enforce “quality applications”, but there are far better ways of going about it. Mandating that applications be “originally written” using Xcode and the C-based languages is just foolish as it does not magically create quality. What it does do, as I explained previously, is send developers running for the hills, or more specifically, to competing platforms where they have more creative freedom.

Does Section 3.3.1 help Apple in any way?

Gruber makes several claims:

So what Apple does not want is for some other company to establish a de facto standard software platform on top of Cocoa Touch. Not Adobe’s Flash. Not .NET (through MonoTouch). If that were to happen, there’s no lock-in advantage. If, say, a mobile Flash software platform — which encompassed multiple lower-level platforms, running on iPhone, Android, Windows Phone 7, and BlackBerry — were established, that app market would not give people a reason to prefer the iPhone.

And, obviously, such a meta-platform would be out of Apple’s control. Consider a world where some other company’s cross-platform toolkit proved wildly popular. Then Apple releases major new features to iPhone OS, and that other company’s toolkit is slow to adopt them. At that point, it’s the other company that controls when third-party apps can make use of these features.

There is truth to this, but I think it’s absurd to think that a third-party toolkit that failed to keep up with Apple’s APIs and produced poor quality apps would ever be popular. Why would users and/or developers willingly choose to use an inferior product? And if they do, so what? No one is forcing you to use them. Further, the vast majority of applications written for the iPhone *have* been written using Apple’s tools, before these changes were made to Section 3.3.1.

Are these imagined advantages worth the consequences?

Many (if not most) developers do not view a company that is blatantly trying to “lock them in” favorably. It is not a virtue that people respect. If I were to write an app for the iPhone, I would choose the tools that I deemed “the best”, voluntarily, and that probably means I’ll use Objective-C and Xcode. But the notion that those are the only tools that I’m allowed to use scares me, and it seems, many others.

The iPhone is the #1 smartphone because people *like it*. They chose it based on the quality of the product itself, and developers flocked to it because of its popularity and its amazing tools. There was no need to lock anyone in, Apple got to where it is on merit, and that’s respectable. Trying to forcibly lock users and developers into the platform is a sign of insecurity.

Everyone fears The Ignorant Boss

For developers, this is the person who knows nothing about programming yet insists that you use X tool and write it in Y language. Now, suddenly, it is as if the formerly independent iPhone developers all have such a boss, and the worst part is that they can’t even communicate with this one. He lives several thousand miles away in Cupertino and isn’t even aware of their existence or anything related to their project.

Gruber goes on to discuss the impact Section 3.3.1 has on the user’s point of view:

I can see two arguments here. On the one side, this rule should be good for quality. Cross-platform software toolkits have never — ever — produced top-notch native apps for Apple platforms.

Ignoring the fact that Gruber is making objective that which is totally subjective, this is just plainly untrue.

One of my favorite applications on the Mac is Mozilla’s Firefox, and certainly my favorite web browser. I think it beats the pants off Safari. As this is not a review of Firefox I won’t get into the details, but I will point out that Firefox is written using a cross-platform software toolkit.

A friend of mine is a musician who thinks the world of Ableton Live (also written using a cross-platform software toolkit), while deriding Apple’s Logic Pro as “lackluster.”

Without question these are all examples of “top-notch” software written using cross-platform toolkits. There are hundreds of others. Much of the software that’s hidden from view and supports the foundations of Mac OS X itself is software that is written using cross-platform toolkits, and all of these are “native” in the sense that they run just as fast as software using the Cocoa frameworks. Some might have widgets that look different, but so do most iPhone games written in accordance to Apple’s rules, should we ban them because of it? That would be absurd and tantamount to software-racism!

I sent a final response to this effect:

The Mac has only been helped by the fact that Firefox, Ableton Live, and hundreds of other high-quality applications can run on it thanks to the fact that developers have a choice as to what tools they can use on it.

Crappy developers will make crappy apps regardless of how many layers there are, and it doesn’t make sense to limit source-to-source conversion tools like Unity3D and others. They’re all building apps through the iPhone developer tools in the end so the situation isn’t even comparable to the Mac where applications can completely avoid using Apple’s frameworks by replacing them with others.

In my opinion, 3.3.1 only serves to make the platform less attractive to legitimate developers, giving them reason to write their software for competing platforms instead.

Thanks for considering this.

Sincerely,
Greg

Apple is free to write whatever absurd rules they want for their SDK, but in doing so, I think the “creative company” is undermining creativity itself, and at its own expense.

The full text of this exchange with headers (sans the final reply), is right here.

Update (4/11/10): Steve Jobs’ Response: A Brief Followup

Update (9/10/10): A few months after this posting, Apple updated and relaxed their terms.

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

And rightly so.

On our About page we explain why we develop software for the Mac:

We believe that Apple has created an environment where great software can really thrive.

I still feel this way about the Mac, but I no longer consider the iPhone or the iPad worthy of such sentiment because of the draconian terms under which one must operate to develop for those platforms.

What Apple’s engineers have done with the iPhone is amazing. They’ve simply outdone themselves when it comes to the quality of both the software and the hardware. However, I no longer think Apple can continue to honestly claim that they have the best phone around. Steve Jobs and Apple’s legal department have taken a figurative dump on their hard work with these insane restrictions, and that creates an foul odor that stains the product as a whole.

Missing Applications

The new rules, interpreted as written, ban all kinds of applications written by great folks who have put in countless hours of work developing for this platform.

Games developed using the great Unity3D engine are not “originally written” in Objective-C, C, or C++.

The incredible work that James Long put into creating what is probably the first-ever OpenGL game written in Scheme on the App Store, is now thrown into question.

With these terms, Apple is going against its own Think Different model, destroying creativity itself through the enforcement of a monoculture of developer tools. They are effectively saying that you can be creative, so long as you’re creative our way, an absurdity known in psychology as a double bind.

Developers Running Away

The SDK terms are not just insulting, they’re bad business. Great developers like Tim Bray are forsaking the iPhone platform out of disgust and running to Google’s Android platform. Dan Grigsby of Mobile Orchard just announced they’re abandoning iPhone development because of these restrictions.

Despite my familiarity with Apple’s tools and the language Apple insists developers use, at the present time I can’t envision myself writing an app for the App Store, because in clicking that Agree button on the license terms I suddenly find myself feeling like an infant, as though I can no longer be trusted to make basic decisions and must therefore be locked in a crib surrounded by child-proof toys and bars.

For companies like Google, all of this should be good news, because despite its shortcomings, Android’s relatively open platform is starting to look far more inviting.

Therefore I’ve started a Posterous account to which I’ll be posting that sort of goodness.

The Union: The Business Behind Getting High

And you can watch it, right now, for free on Google Video.

According to Steve, however, the iPad is designed primarily for the following activities:

For some, even that may be something of a stretch.

As many have pointed out, the iPad is more of an oversized iPod Touch than an undersized MacBook Air, or as Daniel Tenner so aptly put it: “The uncomputer for the masses”.

When you send someone an email, you expect it to fall into the hands of its intended recipient, not someone who happened to get a hold of their device. I would never download all of my email onto an iPad because I can neither encrypt nor password protected it. Apple’s lockdown of the OS means third-party developers cannot intervene and remedy this situation because they’re not allowed to touch certain parts of the system.

Businesses and hospitals won’t be thrilled with employees and nurses running around with an easily swipeable device containing unprotected company secrets, client data, and patient information. Thanks to the “duplicating functionality” clause of the SDK TOS, developers can’t even write their own encrypted versions of Mail or the iWork suite.

If you want a secure iPad, you’ll either have to hope Apple implements it, or depend on each individual developer to properly secure their application’s data—a situation that nobody should be thrilled with.

This weekend I saw Michael Moore’s latest film Capitalism: A Love Story. Like most of his films, this one should come with a disclaimer: for the duration of the film you’ll be looking at the world through the eyes of Michael Moore and those who reflect his views. Don’t expect to see or hear any conflicting views or arguments.

For those that hate Moore’s films, there’s plenty in the film to nit-pick about. There’s a scene where he does his best to convince you that all Christian priests hate Capitalism and consider it an evil. Some have argued that he’s misusing the word “capitalism” altogether and should instead say “corporatism”. He also tends to group various corporate entities into a single-group. AIG, Citibank, Goldman Sachs, Bank of America, etc. All of these are placed in the group of “evil rich people bent on screwing over the lower-classes while having cocktail parties on corporate yachts.” In some cases, there is actual truth to that notion, but of course for those looking to put down Michael and nit-pick, he leaves plenty of room in his films to accommodate you.

However, despite the flaws, I enjoy watching Moore’s films precisely because of how rare their kind is.

It has been my general experience in life that many of the people that I encounter are perfectly satisfied to watch the latest action blockbuster out of hollywood, and when a movie like Capitalism rolls out they do two things: they pass up the ticket to see it for another action blockbuster, and then proceed to lambaste his films with a level of ignorance that far exceeds anything that I’ve heard Michael Moore say.

What further amazes me is how successful Moore has been at getting his films to play at major theaters. There are many many other films out there that do a much better job of espousing upon the insanities of our society and yet hardly ever make it into major theaters. Documentaries like Food Inc., Jesus Camp, The Century of Self (video link), Who Killed the Electric Car, and many others only find home to a handful of theaters across the country. These important films have been kicked out of mainstream society, to be replaced by the latest blow-em-up out of Hollywood that has sold out several times over.

That scenario never ceases to amaze me. How such a large amount of people, often the group that stands to benefit most from seeing movies like The Century of Self, who often live quite miserable lives because of their complete ignorance of their surroundings, can constantly, repeatedly purchase tickets to the same exact action script that Hollywood modifies slightly on a bi-monthly basis.

Ironically, it may in fact be because of the overly narrow viewpoint espoused in Capitalism, and its heavy use of emotional content, that he is able to get it distributed so widely. I say that’s better than nothing.

Further, while there are many imperfections in his films, they nevertheless tend to bring up worthy causes and viewpoints into the mainstream for discussion.

I also have to credit Capitalism for making me consider a thought that I hadn’t thought of before, namely,

Why do we allow corporate lobbyists and advisers at all?

It seems to me that just as we supposedly have the separation of church and state, we should institute the separation of the state from all other entities other than, of course, “the people.”

One thing that I’ve been astonished to learn from some of these films (Moore’s and others), is how incredibly entrenched major corporations are in the decision making of our government.

I considered the opposing viewpoint, that perhaps “because they represent the interests of a large amount of people and jobs” they should therefore have a strong say in policy making.

However, this is simply not true. Corporate interests do not include various idealized notions such as the right to a trial by jury, and even more idealized, yet worthy, concepts such as the rights to “life, liberty, and the pursuit of happiness.” Corporate interests are much simpler than that, they just want to “make a lot of money.”

Worse, they have demonstrated unequivocally that the way they’ll go about getting this money will often be by screwing over their workers, and quite often, their customers as well.

So, it seems to me that such entities should have no place whatsoever in any policy making that affects the lives of people outside of their corporation (and in some cases even inside of their corporation). Their advice is usually, simply put: bad. And in the rare instances where it’s not, we certainly did not need them for it. Instead of dictating policy to our representatives, they can call in like the rest of us. Respected scientists, nutritionists, farmers and various other in-field experts make good advisers to the FDA and USDA, not the board members of Kellogg’s and Monsanto.

Government, people often forget, should be owned by the people to serve the interests of the people. When corporations get in the picture, the people are no longer represented, instead the interests of a very small minority is represented, usually at the expense of all the others.

This is what has happened to our government. Although this situation is not anything new, it’s nevertheless messed up and it’s certainly worth changing.

A good way to upset the status quo is simply through the spread of information and the systematic removal of ignorance. Michael Moore’s Capitalism: A Love Story, though certainly flawed, helps to serve this purpose by bringing some of these issues to the forefront of America’s consciousness, and for that reason, I recommend you see it.

We’ve become accustomed to the notion that every product must come in its own packaging, that this is “obvious” and that it’s the only way things can be done.

Every day I use a variety of container-based products (CBPs for short): shampoo, face-wash, toothpaste, liquid soap, orange juice, etc. etc. The list of CBPs goes on. This causes a huge strain on the environment. Companies use giant factories across the world to manufacture hundreds of thousands, and in some cases millions of CBPs. For each CBP resources and energy are used to create the container, then all of these little containers are shipped all over the world in an inefficient manner.

Wouldn’t it be great if we could get rid of most of them? I think such a world is possible.

This brings up several questions: Could this cause difficulties for brands to compete? After all, you recognize that this particular brand of sugar-water belongs to Pepsi because it comes in a CBP that has the Pepsi logo on it. And how are you to know what’s in your shampoo if it doesn’t have a container to list the ingredients?

Imagine the following:

A Different World

A consumer walks into a local grocery store in search of body wash. He grabs a sleek bottle of Product 5eX promising to make him more attractive to the opposite sex. Except, this isn’t a CBP, in fact, while the store’s isles are packed with various bottled products much as they are today, there’s not a single CBP to be found, what our gullible protagonist holds in his hands is actually an RBP—a refill-based-product.

After weeks of usage and several unsuccessful attempts at attracting a mate, our friend runs out of Product 5eX and decides that perhaps he hasn’t used it long enough and so drives back to the grocery store in search of more. However, instead of going back to the isle where he originally found it, he places the empty container, along with empty containers of toothpaste, face-wash, and 9-liter bottle of cola on a conveyor belt at the front of the store while swiping his credit card. After shopping around for various food products inside he’s ready to checkout, and so are his RBPs.

In such a world there are many possibilities. Perhaps you could use a generic container and simply use the product’s unique ID number to refill it. There could be a huge online database that matches product IDs with detailed information about each product such as nutrition facts, ingredients, etc. All with the latest information on each ingredient and links to further information.

Not So Different

In fact the concept of an RBP is not so foreign. Recently my local OfficeMax began offering refills for all ink cartridges. Refills have existed at restaurants as long as I’ve known.

While many of today’s containers are recyclable, recycling is not nearly as good as reusing and reducing. Recycling takes energy, and many of the things that you put into your recycling bin don’t actually get recycled for one reason or another. It does not really tackle the core issue.

Instead of creating and shipping millions of little bottles, companies could send entire vats of refillable goop all over the world. The RBP model is not just a giant win for the planet, it’s a boon for consumers and producers alike, as it would drive down the cost of production and therefore the cost of products.

Challenges

There are certainly many questions that need to be addressed for such a world to become a reality. For example, the question of sanitation. How can you guarantee that a refilled product will be as fresh as a brand new one if the container has been opened? I’m sure that through various techniques and technologies such challenges can be overcome. Perhaps each major reseller can have its own mini-sanitizing doo-hickey that cleans the insides of containers. Like all engineering problems, the solutions are out there as long as someone is willing to put in the effort.

Think it’s a good idea? Pass it on.