Practicalmadness

Nomenclature

Prediction: in the first six months after third-party apps and the App Store are publicly released in June, “[app name] Touch” will be just as prevalent — and just as annoying — as the plethora of Ruby on Rails plugins named “acts_as_[plugin name].”

Distribution

Speaking of the App Store, I’m not 100% settled in how I feel about Apple serving as the gatekeeper for all iPhone software in the universe. Obviously having someone vetting publicly available apps to make sure they’re not malicious or liable to destroy one’s $600 $400 gadget is good, and $99 for some great access and support is (as John Gruber has written) a no-brainer. But this does make establishing a legit homebrew community for the iPhone rather difficult, which means serious hackers will probably stick with the existing jailbreak/toolchain stuff for a while to come.

My real question would be this: Apple’s announced some great processes for development, public distribution through the App Store and private distribution through the Enterprise App Store. But are developers allowed to load their apps onto their own iPhones for testing without keeping them tethered to the Mac the whole time? And if so, couldn’t a developer write a little homebrew app for themselves and load it onto the iPhone directly?

I had originally posed the question of whether developers could load and test their own apps without keeping their iPhones tethered to their Macs, but John Gruber’s already answered it:

So it seems like the answer to my question yesterday about how users will be prevented from running apps downloaded directly from developers (rather than through the App Store) is that unsigned apps will only work on your iPhone if you pay (and get approved) for a $99 iPhone developer account. But does that mean that approved developers will be able to freely exchange unsigned apps with each other?

I’ll be looking into this further, but my first impression is that no one can install unsigned apps onto the iPhone. An IDP membership includes an Apple-provided digital signature you can use to load your own apps onto your phone, which you need even if you want to use the live testing/debugging features they showed off yesterday. Non-IDP members and people who don’t yet have their certs can only test their apps in the Simulator. And I’m sure there will be some controls in place to ensure that developers can only install their own apps, to prevent a gray market in unsigned/unapproved apps.

The above notwithstanding, I love the idea of the App Store. Just imagine if Apple had a program that let musicians and filmmakers distribute their content on the iTunes Store in a similar way, in return for a nominal membership fee and a 30% cut of sales. It would be absolutely huge. This is the kind of thing Apple can do when they don’t have record labels and movie studios to make nice with.

Simulation and Simulacra

The iPhone Simulator (which is actually called “Aspen Simulator,” after the iPhone’s original codename) is teh shit. Even if I never succeed at learning enough Objective-C to write a real iPhone app (which is where I’m at right now), this is a fantastic tool for iPhone web development. Right now developing an iPhone interface for a web site (like I did for the Oscars Game) requires one to have their iPhone physically in front of them for previewing, and other so-called iPhone simulators are simply desktop WebKit views inside an iPhone-looking window.

Well, the iPhone Simulator really is the iPhone UI environment, with a real copy of Mobile Safari. But it’s not the whole iPhone OS stack. I know it at least shares networking stuff with the host OS (i.e., Leopard) because I was able to browse to one of my handy projectname.local.practical.cc URLs in Mobile Safari for testing. This is actually not a bad thing, since it means that (theoretically) anything that works on your Mac, network-wise, should also work seamlessly on the iPhone.

Coming Up Hard(ware)

Though I’ll take this opportunity to make one thing abundantly clear: iPhone developers do not seem to get any access whatsoever to any hardware besides the camera, and the camera looks like it’s only accessible via the Photo Picker UI element. Apps will not be allowed to talk directly to the Dock Connector port (so no fancy new peripherals) or the cellular modem (so no picture messaging until Apple sees fit to provide it).

Ironically, the only hardware an iPhone developer will have to worry about is memory, since the iPhone’s APIs don’t have the fancy new garbage collection introduced in Objective-C 2.0 for the Mac. (Though to be clear: iPhone apps are written in Obj-C 2.0, just without garbage collection.)

Get The Data (or Not)

And all iPhone apps will be sandboxed: they won’t get access to any memory or filesystem resources except their own, so one couldn’t write an AmazonMP3 client which downloaded songs over the air and loaded them directly into the MobileiPod app, nor could you hack in the ability to upload or download files from a web view. You can store and use data on the device in your apps, but you can’t sideload or sync that data from a PC, and you can’t get it from any other iPhone application. And you also don’t have access to any shared data stores besides the ones Apple’s made available. So while Mac desktop apps can talk to the shared calendar/to-do store on Leopard, the same cannot be said about the iPhone’s calendar.

It’s a (necessary) shame that Apple doesn’t yet offer anything like Palm’s “HotSync conduits,” some kind of interface allowing iPhone apps to synchronize with a data store on the user’s desktop PC via iTunes the way Apple’s own iPod, Mail and Calendar apps do. Without desktop syncing, my dream of somebody building a world-class iPhone task manager that integrates seamlessly with, e.g., iCal or Things or OmniFocus seems at least a little harder to achieve.