Ups and Downs…

Sorry for the delay since my last post, life has been getting in the way.

I have been looking at the SDK and documentation that Apple released on Thursday, and have some good news and bad news.

Good news:

- Interface Builder Lives! Well, not yet – Apple announced it, but has yet to actually deliver it to developers, although it’s supposedly coming very soon (with only 3 months until launch, it has to). Still, just the fact that they will be releasing an IB for iPhone OS (the official name of the iPhone software, I personally prefer Mobile OS X, but whatever) is a massive gain for developers, especially with its support for multi-touch events.

- The App Store is the future of software distribution – a one-stop shop for the purchasing and updating of apps on the go. The terms (70% of revenue goes to the developer) are pretty fair (I’ll admit I whined a bit on Twitter, but since I’ve realized that it’s still a steal comparing to going it on your own), and the ability to be advertised on the iTunes Store is fantastic. It will also allow to possibly price AutoPilot lower than I originally planned – stay tuned for more…

Bad News:

- Intel-only? Boooooooooooooo! My 2-year-old iBook may be a little slow, but to make it obsolete is a bit over the top. As of right now, I have no legal machines that can run the SDK according to Apple. However, parts of the SDK are, in fact, compiled as Universal apps (specifically the platform information, dev documentation, and the Aspen Simulator), and will run on my machine. This, however, is a stop-gap, so I am in talks with a possible source of a brand-new Intel Mac (The source? My parents.) I also have a desktop PC that “tolerates” OSx86, and as a worst-case scenario, a copy of Leopard might just happen to be installed on that system to start native development.

- A funny thing happened to the APIs on the way from Leopard to the iPhone – the Calendar Store framework disappeared! Calendar Store controls the system’s central calendar and to-do database, where everything from iCal is stored. In Leopard, apps could make calls to Calendar Store and read or write directly to the central database. This framework is non-existent in iPhone OS (yet there is a Contacts API (albeit read-only) – thanks Apple *rolls eyes*). What does this mean for AutoPilot? A couple of things:

1. I’ll need to find some workaround to allow for alarms for to-dos with due dates, although with the absurd lockdown on anything non-Apple-specified, I’m not sure what I can do (I’m still reading through the programming guide, hoping there’s some way to tie directly into MobileTimer.app (AKA Clock), but I’m not holding my breath…)

    2. Syncing just became a LOT harder on both sides. Since I can’t write directly to the central Calendar Store (not that I expected to be able to – after all, there is no to-do functionality, but it was a nice pipe-dream), I have to maintain my own database. I have yet to read anything about writing sync conduits for iTunes, meaning that as far as Apple is concerned, unless the data you are trying to sync involves contacts or pictures, the iPhone is an island.

Coming from years as a Palm user, where it was constantly bashed into my head that a PDA is a mobile COMPANION to a desktop computer, as opposed to a replacement, I am in disbelief at the naivety in blocking all syncing. Just because the iPhone is a whole new generation of mobile computer, doesn’t mean it should be artificially blocked from talking to one’s home system. I have some ideas of how to get around these limitations, but they are all very ugly and hacky workarounds that skirt around the real issue: Apple doesn’t want anything that they didn’t write to sync with iTunes.

Part of this I can write off to security paranoia – Besides abolishing Calendar Store, they have essentially castrated every framework one would think could write to other apps, because Apple is obviously scared stiff of hackers attacking this now dominant platform. In case Apple somehow missed a malicious application, if they had read-write frameworks available to signed apps, suddenly people downloading these bad apps would get burned. Thus, instead of boosting the security of the actual operating system, they have instead completely crippled legit developers’ ability to interact with other apps on the phone, while meanwhile hackers will just dodge around Apple, find stealth ways to “jailbreak” a phone and gain access to the underpinnings, where they can do anything they want.

*sigh*

Now that I’ve gotten all that vitriol out of my system, I can assure you that AutoPilot will work perfectly fine and as planned in every way except syncing. I will ensure the app works great as a standalone trusted system, and then I will work on possible solutions to the sync issue. I also plan to let Apple’s engineers have an earful over the issue (hooray bug reports), and I’m likely not alone – after all, my “competitor”, Omni Group, has said they want to make their “Mobile OmniFocus” sync with the desktop app, and to be denied that, needless to say they’re likely LIVID. Maybe, just maybe, we angry developers can rattle the cages at 1 Infinite Loop enough to cause Steve to call off the absurd paranoia and allow developers to truly take advantage of this incredible platform.

Christmas Eve for Developers…

Tomorrow is the “big day” – Apple will be holding an event at their campus Town Hall at 10 A.M. PST (that means 1 P.M. for me) to announce their “software roadmap” for the iPhone regarding the official SDK and various enterprise features. I could bloviate on and on about the various rumors of what said announcement will bring, but I am sure that if you are interested in that information, there are plenty of better sources for it.

That said, I would like to talk about what I want to see from the official SDK. As a relative beginner to programming and a complete novice at Objective-C, I am obviously not the best source of insight into the wants and needs of the developer community. However, speaking as a hobbyist looking to dip his toes in the water, I would really like to see:

- Some form of Interface Builder for the iPhone: IB is an incredible asset for Mac OS X developers. Not only does it make designing a program’s UI drop-dead simple, but it also gives the programmer a surprisingly large amount of power even before they start writing a single line of code. For some proof of this, look at Scott Stevenson’s tutorials on learning Cocoa: The first tutorial doesn’t even involve any code at all, but rather is entirely created in IB. Similarly, an IB for Mobile OS X would be a huge boon to developers. Currently under the unofficial SDK used by jailbreakers, all interface elements need to be declared in code, making UI design slow and tedious. If no version of IB is announced as part of the SDK, expect app rollout to take a bit longer.

-Deployment and distribution of applications via iTunes: Many developers are against the idea of Apple forcing applications to be vetted and sold through the iTunes Store, but as an amateur developer with minimal resources, it is a dream-come-true. By taking this approach, Apple is essentially offering developers hosting, bottomless bandwidth, and promotion on the iTunes Store, a web page that sells more than 5 million items a day, all for (likely) a small cut of the sale price.

As an independent developer, I would have to spend a great deal just to get a mediocre hosting and bandwidth package together on my own. If my app suddenly became massively popular, I would be suffocated by the immense bandwidth requirements. By requiring sale of apps through iTunes, Apple is democratizing the third-party software marketplace – suddenly, a little guy like myself can compete with giants like Omni Group (and judging by this comment, I will be…), and stand a great chance of being successful.

The ideal terms for such a system would be Apple not requiring any fees upfront, but rather just taking 10-15% of an app’s revenue through the store. While some will cry murder at such a rate, for the independent developer, it is a steal compared to finding hosting of one’s own, especially for lower-priced apps. If I wanted to put out AutoPilot and had to host a site and pay hosting and bandwidth charges, I would have to charge 4-5 times what I want to just to break even. Currently, the plan is to price AutoPilot at $5-10, based on what Apple announces tomorrow and market demand, which seems to be pretty massive according to Macworld. At that price point, even with larger, more well-known competitors, I can still be highly successful in my chosen market. However, if I had to pay for all of these services on my own, I wouldn’t stand a chance.

- Custom sync conduit support on both Mac & PC: Sync should be easy enough to manage on the Mac side, as long as I am allowed to manipulate the iPhone’s Calendar Store directly – it should all just get carried over via iSync when the iPhone is next connected to iTunes. The PC side, however, will be a whole other can of worms (Outlook = yuck, writing an Outlook plug-in = BLECCH). If Apple enables developers to write custom sync scripts that hook directly into iTunes, it will make my life a lot easier, although how they would manage the installation of these eludes me at the moment. (Would they install when you buy an app?  What if you use multiple computers to sync with the iPhone (as I do, calendars/bookmarks/pictures on my Mac, music/movies/TV shows on my PC)?)

- Rollout to consumers in some form BEFORE WWDC: Various rumors are saying that the kit isn’t ready yet, and anything that will be put out tomorrow will either be a developers-only beta/alpha of the SDK, or a rather barebones kit rolled out to the world with more advanced functionality coming later on. As a developer, I would greatly prefer to see the latter, especially given the nature of my app – I don’t need a whole bunch of whiz-bang features to develop the 1.0 version of my app, although I can certainly see places to add them on in the future. I would rather see some form of third-party app support being placed in consumers’ hands sooner rather than later.

I will be following tomorrow’s announcement very closely (fortunately, I’ll be out of class when it starts, so I won’t have to sneak peeks at my iPod touch every 2 minutes just to see what’s going on), and I will post a follow-up tomorrow evening outlining a roadmap of my own for the development of AutoPilot. As both a developer and a future user of AP, trust me when I say I am itching to get started on this project, and will share concept pictures and demo screencasts as soon as humanly possible.

Until tomorrow,

- Bill Kline, Developer, AutoPilot

What is AutoPilot?

AutoPilot is nothing yet – but it WILL be a first-class native iPhone to-do list manager built around the Getting Things Done philosophy. AutoPilot will be built from the ground up to be the ultimate GTD experience an iPhone/iPod touch user can find, with a robust, 100% trusted database, fast to-do entry, full arbitrary tagging, project management, and syncing to and from Macs (iCal/Leopard’s central To-Do Database) and PCs (Outlook).

Development has not yet begun, but with Apple about to announce their “iPhone Software Roadmap”, we will soon find out when the native SDK is to be launched, at which time I will begin serious development.

I look forward to sharing more information about AutoPilot as soon as I can.

-Bill Kline, Developer, AutoPilot