It’s not often you’ll see me defend Apple on this blog. As a whole, Steve Jobs and his gang of merry men (here’s looking at you, Phil Schiller and Scott Forstall) are annoying in the way they create products, present those products, and immediately claim that those products are the greatest thing since sliced bread and that EVERYONE needs to get out and buy them. I’m not a huge fan of companies taking direct shots at other companies (with a few exceptions; see Verizon vs. AT&T) and the PC vs. Mac ads are a great example of classic Apple advertising: comical, but at the very least misleading and some just outright lies. (It should be noted, however, that those ads might work. I currently own an iPod 5G (with video), iPod Touch, iPod Shuffle and iPad, work every day on a MacBook pro, and have spent a small fortune on songs from the iTunes store. I’ll go stick my face in a food processor now.)

But the recent war of words and action between Apple and Adobe is a little different. A lot of the Internet is bemoaning the fact that Apple is not only blocking Flash on the iPhone OS devices, but it’s also using its admittedly Draconian App Store policy to block Flash-developed, Objective-C compiled apps because they use a third party API or SDK. I, however, am on the other side. More after the jump.

I ran across this post today on TechCrunch (er, sorry, I guess it was on MobileCrunch). For those uninterested in reading the full article, I’ll speak a little bit about the bug, which has the potential to be very costly. Basically, the article states that when you’re viewing a motion-JPEG (a video format based on JPEG photos – often found in digital cameras or security cameras) file in Safari on the iPhone and then closing Safari, the browser actually stays open. Mobile Safari will continue to use up bandwidth as it loads the motion-JPEG at the specified interval, and if you’re on a pay-per-megabyte-downloaded plan, you could foot the bill for thousands of dollars.

The article kind of justifies this bug. After all, it states, it doesn’t affect you if you’re on an unlimited plan (because hey, if you have all that extra bandwidth, why not waste it?) and it only seems to occur if you’re viewing a motion-JPEG (which isn’t the most common file format, but it’s not unused either). So, fine. It’s a bug, it doesn’t really affect a ton of people that greatly, oh well, right?

Wrong.

The first comment on the article:

How is this a bug?

The website refreshes…it’s not apples fault the person would have a crazy bill, it’s the user for not closing out the page.

And here’s the real beauty of making an Apple product. No matter how bad it sucks, no matter what kind of problems it has, Apple users defend Apple products like they’re defending their children. This attitude either stems from or causes Apple’s ridiculous arrogance about its own products. (For an example, check out any of Apple’s recent commercials for any of their products.)

I’ll address the commercial first. Here’s the thing. Apple’s made a good operating system. It didn’t happen overnight. If you think this operating system has been rock solid from day one, look again. If you remember, OS X only really started even getting stable at around 10.3, and it got good at around 10.4. The OS has been really a work in progress since 2001, and it’s had its share of problems. That’s not to mention Mac OS 9 and below, whose codebase was, for all intensive purposes, abandoned when the company was on the brink of bankruptcy in the late nineties. But that’s an argument for another day.

Let’s get one thing straight: when you close a program, it should close completely or give you some indication that it’s still open: in OS X, an open program is a shiny light under the icon in your Dock, in Windows it appears in your taskbar or system tray, etc. Not only does Safari not give you any feedback that it’s remaining open, it’s the only application on the iPhone to do so. It’s far from expected behavior, and when using an electronic device, users prefer devices that they can guess what’s going to happen based on their actions.

If any users get a bill in the triple digits (in some cases, as noted in the article, over $3000 for an hour of unknown downloading), Apple should pay it themselves. This isn’t user error. It’s either by design (for whatever reason), or it’s a bug. Apple should fix it.

One of the more controversial topics in the software industry in the last year is the Apple App Store. Originally released in 2008, the App Store is already up to 65,000 apps and has been a commercial and critical success. The App Store alone has probably sold half of all iPhones that have been sold since its debut, and seemingly, no matter what you want to accomplish, “there’s an App for that.” But while the App Store is doing great now, I believe it needs to make serious changes before too long; otherwise, it will risk losing its momentum. It’s been well-documented that the App Store’s rejection policy is inconsistent, at best. But in today’s software development landscape, the idea of a members-only program in general doesn’t make much sense.

First, let’s look at the actual idea of writing an app. iPhone apps are written in Objective-C, a newer language than C and C++, but still low-level enough that the developer manages his own memory. For any non-programmer reading this, memory management errors cause probably 75% or more of all crashes for iPhone apps. “That’s bad,” you might say, “but don’t other programmers of other platforms deal with this too?” It’s true that memory management is important for all software development, but these days, most modern languages do that for you. Through managed frameworks such as .NET and high-level programming languages like Ruby, Python, C# and PHP, developers no longer need to worry about managing their memory; it’s done automatically. This saves developers time, energy and sanity. It’s true that managed frameworks and languages take a performance hit, but for most applications, it’s a reasonable sacrifice, and if performance becomes an issue at some point, there’s always the option to write at a lower level.

The problem with the iPhone SDK is that not only does it use an unmanaged language, but it also prohibits the use of frameworks that would make the process of developing an app faster. One iPhone rejection story highlights this pretty well, but the gist of this is that his app was rejected because he made use of an external framework to save time. It’s pretty outrageous. We live in a Ruby On Rails world – there’s a framework, an external library, a helper file for anything you might want to do, whether it’s rapidly building a website or building a game in XNA. The latter example is something that would be excellent for the iPhone – a pre-baked physics engine – but is expressly forbidden by the iPhone SDK agreement. That means that no matter how complex or how simple your app is, you’re ALWAYS writing it from the ground up. This is terrible for the iPhone developer culture (each developer is encouraged to stay in his own little sandbox and never really work with anyone else to make something bigger) and completely against the general trend towards frameworks and libraries.

So you write your app and submit it. Then you wait. Some apps get approved within 72 hours, some take weeks. There’s really no way to know how long yours will take to get approved. And then, when it comes back, it’s entirely possible your app gets rejected and you have no idea or aren’t told why. Run that search linked above and you’ll be regaled with strange stories about iPhone developers and their interactions with the Mothership. The App store criteria isn’t consistent, it’s certainly not timely, and in the case of the Baby Shaker app, you have to wonder what the heck the review process is.

This wouldn’t be a problem for me if there were alternative ways to get your App out there. You can manually e-mail fresh builds to up to 100 people, or if you’re in an enterprise, distribute them through a customized portal, but unfortunately, that’s it. You might have the best App in the world and a site that gets hundreds of thousands of pageviews a month where it’d be downloaded hundreds of times per day…but if it gets rejected (no matter how grievous the cause), it’s not going anywhere.

This is something Apple’s always done: developing for their products is a members-only opportunity. Microsoft, on the other hand, opens their products to virtually anyone with an Internet connection (and clearly, developing for Linux is, well, about as open as it gets). You can make the argument that reviewing each app ensures that the App Store has apps that are well-written and useful, but let’s be honest, a lot of those apps are absolute garbage. Better apps have been rejected. I think for the App Store to continue to skyrocket, developing should work a little bit more like Facebook’s platform:

Apply for an SDK license, pay the $99 or whatever it has to be.

For each app, generate an API key and secret so that the app can be properly signed.

Allow distribution wherever the heck the developer wants to put it.

If the developer wants to put it on the App Store, he can submit his App for inclusion. If it’s good, it’ll go up, and if it’s awesome, it’ll be featured.

If the App is found to be malicious, figure out who developed it and talk to them about it. In general, if people install Apps to their phone from somewhere that’s not the App store, it’ll be a trusted location so I don’t anticipate this happening often.

This makes the App Store much less of a jungle, much cleaner and more useful to the average user. Also, it makes writing App Store apps much less risky (doesn’t make it to the App Store? No problem, throw it on the website).

Much like all fresh developer communities, the iPhone community hasn’t really matured yet and there isn’t a lot of great documentation on the web. Apple isn’t helping matters with the NDAs it occasionally puts on developers who get to beta test new features, and doesn’t seem to respond well to criticism either. Look, if you want people to be excited about your platform, you should let them know what’s coming, let them give you feedback, and listen to them. That’s how Firefox became the juggernaut browser that it is, that’s how Google became what it is today, that’s why Windows 7 is getting raves. Apple seems to understand this with their hardware, and Phil Schiller did send an e-mail recently that suggest they’re starting to get it here, too. (Phil Schiller sending e-mails to tech blogs? What is this world coming to?)

The iPhone has been a commercial and critical sucess since its release in 2007, and has only gotten stronger since the debut of the App Store in 2008. Hopefully, Apple will learn from some early mistakes and cease the draconian review process and/or provide alternative channels for developers to get their apps out. If they don’t, I’m sure Palm will gladly give up some control of the apps on their phones for a sliver of the iPhone’s tremendous market share and momentum.