About 2 weeks ago, I showed a teaser for my new iPhone app, Lockbox. I was deliberately ambiguous, as I wanted to surprise everyone at WWDC with it. After getting some much-needed feedback on the app, I’d like to talk about what Lockbox actually is.

Lockbox is an app that lets you store encrypted photos and notes on your iPhone. Encryption requires that users enter some sort of key into the system, as a means of proving that the person who stored the data encrypted is the person trying to decrypt it. This has historically been done with passwords, which are easy to turn into a key. However, the iPhone’s screen doesn’t really lend itself to entering a complex password. The alternative that Apple has put forward is a 4-digit PIN number. This is too insecure; it would take at most 10,000 iterations to brute force the password, which is child’s play. Clearly, another system is needed.

Lockbox solves this problem with a very unique and innovative means of key entry. Rather than using a password or a PIN, Lockbox lets users draw a gesture with their finger on the screen. The gesture can be as long or as short as the user wants. In my tests, I’ve found the best gestures to be somewhere between 12 and 20 cells, which increases security over PIN numbers against brute forcing by 2 and 4 orders of magnitude respectively. And, as a bonus, gestures are much easier to remember and much faster to enter.

Lockbox will allow users to store encrypted versions of photos and notes. The raw key is never stored on disk, and is overwritten a few times when the application quits. Encryption and decryption is completely transparent and happens in the background. Furthermore, Lockbox is using industry-standard algorithms (specifically SHA-1 and AES). There are two advantages to this: first, the encryption algorithm currently has no known weaknesses; second, these algorithms are hardware-accelerated on the iPhone. Photos can be added from the photo library or the camera, and notes can be edited directly from within the app. Once you get past authentication, the user interface will be very familiar to users of the Photos and Notes apps already on the iPhone.

I’m currently working on getting the app finished, and will hopefully have it ready for the App Store on or near launch. Everyone who has seen it at WWDC has been completely blown away by how easy it is to enter these gestures. Furthermore, I’ll be exploring other options for key-entry. I already have a handful of ideas on other implementations, including one which I’m calling antigestures. However, I’m keeping that a secret for now. 🙂

I’m going to make this one quick, as it’s really late and I’m in the process of packing for WWDC.

• Tubular 1.0 has been released! Check it out at the awesome new site.
• Announcing Lockbox, gesture-based photo and note encryption for your iPhone. Coming this summer.

See you all at WWDC/the Internet!

So, 2008 has gotten off to a very interesting start. So far, I’ve found out that I had to leave Rochester, found out that I don’t have to leave Rochester, released the Tubular public beta, and accepted a position as a Cocoa engineer at Ambrosia Software. It’s been an absolutely crazy few weeks, and we’re only midway through February. With that in mind, I’d like to take a look at what 2008 holds in store for past, present and future projects.

First, the obvious. Tubular is completely on track for a 1.0 release very soon. The public beta is going very well, and the newest version, 1.0b2, is the most stable and feature-complete build yet. Of course, there are still bugs to be fixed, which is why it’s not at 1.0 yet. The march continues on towards that very important goal.

One thing to note is that while Tubular’s development has been somewhat stagnant for a little while, that’s not to say I haven’t been thinking about it and its future. From a product perspective, there’s a million things I want to do in Tubular, but the underlying architecture hasn’t been there to support these future-looking features. So, to make it work, I’ve been reworking some of the plumbing that moves data around inside the app. Some of this labor has already started to bear fruit in development builds of Tubular, although the new features that will result from it won’t show up until 1.1. But suffice it to say, there are a lot of new features in the works.

One thing I didn’t realize at the onset of this project is how to difficult it is to manage and maintain a large list of people, as well as sending out thousands of emails at once. Turns out you get put on spam filters and stuff like that. Recently, to make this problem more manageable, I set up SugarCRM on my new Slicehost server. This tool is fantastic, and helps me keep track of bugs, support emails, registrations, announcements, and more. I’ll hopefully be expanding on SugarCRM in the future, as it has quickly become the hub of my business, and having a full-featured customer relationship management tool has saved me a ton of time. It’s a very powerful and sophisticated tool which contains a bit of extra cruft (which is to be expected; its mostly intended for people in sales), but once you get the system working for you, it becomes indispensable.

Aside from Tubular, I hope to be releasing a good amount of source code over the next few months. The first project I’ll be open-sourcing is my popular app DeskTunes. I’ve been told that it doesn’t work properly in Leopard, and the whole app (aside from some utility code I had lying around) was created in 6 hours, so there remains some cleanup to be done on the codebase. It should be ready to go pretty soon, and of course I’ll announce it when that happens. However, for the most part, I’ll be removing myself from any active development (not that there ever was any).

There are some other pieces of code I’ll be releasing over time. I’m not sure what exactly will make it out yet, so I can’t give any insight as to what it will be, but there will definitely be some good amount of code released before summer.

One more thing…

There is a project that I’ve been planning for over 9 months, and has been under development for a little less than a month. It is Mac-based, and it will be open-source. It won’t be released until after Tubular hits 1.0, and I’m not going to be giving out any details just yet. However, I will tease just a little bit: One of the major goals of this project is to start a huge revolution in Internet-based software. Details forthcoming. 🙂

First, woah, I’m posting.

Second, I think it’s time to look at what Apple may be announcing tomorrow, based on rumors around the internet and my own wild hopes and dreams. I’ll probably be completely wrong, so don’t go making stock decisions on this stuff.

iPhone Software Update – Definitely

The iPhone 1.1.3 software update is definitely expected to be released tomorrow (or at least formally announced). There have been several probable video leaks of the new firmware update, and even rumors that newer internal versions include copy/paste. These rumors are very logical next steps for the iPhone, given the impending SDK release and the need for more interaction for specific apps. I think a software update given the SDK is pretty much assumed to be happening, so I won’t spend any more time on it. But speaking of the SDK…

iPhone SDK Details – Definite

It may be Macworld, but Apple is growing far too diverse to limit Apple’s announcements to purely Mac stuff. Steve is going to spend some time talking about the details of the SDK for reasons I’ll illuminate in a moment. However, since the details are being released at an open trade show, and not behind the veiled curtain of WWDC, that means they’re going to be crowd-pleasers. So, I’m suggesting that the model will be open where anyone with a copy of Xcode can start building apps. No major details are going to be released (will there be developer tools for Windows developers, in the form of Visual Studio, Eclipse, or other tools? Is Apple porting Xcode to Windows? Will there be an iPhone emulator? How will you do testing on a physical iPhone? etc.), but you can be sure that there will be a business model involved, and it’ll almost certainly go through the iTunes Store.

As an aside, I’m going to predict right now that independent apps on the iPhone will have some sort of sandboxing that will restrict them from writing to the filesystem. To read/write data, they will need to use a database that’s local to the system or the process (most likely SQLite). One of the biggest advantages to this approach is the security that it provides, at least to Apple/AT&T. Since all of the UNIX underpinnings of the iPhone rely on using files, there’s very little possibility for files to get overwritten with malicious data. If nothing can write, then you can’t have a problem. This also starts pushing developers towards moving towards database development, which I’ll talk about later.

That being considered, Apple hasn’t had much time to write their own new apps, as they’ve been clearly busy finishing the SDK. Which is why they’re providing details now. Because, this way, they can announce…

Major 3rd-party iPhone developers – Definite

Expect there to be some major companies bringing some awesome new apps to the iPhone. Specifically, I’m predicting Twitter (partially because the CEO was quoted by, well, Twitter, as having said that he’s ”looking forward to a big week”) as a certainty. I think they’ll probably partner mostly with companies who provide Internet services, as Apple no doubt wants to push the connectivity options of the iPhone. With that in mind, I’ll predict Fandango (buy tickets on your phone!) as one of them, and Last.fm as another one (mobile scrobbling!), but there are a lot of services that apply. I’m guessing they’ll also probably want some gaming on the iPhone, and will have partnered with PopCap or, hey, maybe the Iconfactory. That would stir the crowd up in a Frenzic.

iPhone Hardware Update – Very unlikely

No hardware update is going to come for a while. Too many iPhone announcements would suck too much time out of the rest of the show.

iTunes Movie Rentals and on-the-DVD video files – Definitely

For crying out loud, the proof is all over the place. People are already even receiving DVDs with iTunes files on them. It’s happening.

Existing Mac Hardware Updates – Definitely

Well, duh. They always update some of the models. We’ll say the Mac mini and the iMac will get updates, as they were last updated at the event in August. Also, the MacBook Pro will definitely get a big bump, and will probably be the one that steals most of the time for the current Mac lineup. At this point, Steve will probably start talking about how their laptops are outselling their desktops, and it’s because people want to go more and more mobile in an ever-increasing way, and we here at Apple want to make that whole ecosystem work better, and so we’re going to announce some new products today…

Thin MacBook (MacBook Air) – Definitely

This is the big daddy of the rumor mill; the really, really, really, really, really, really, really thin MacBook. This device has been all over the rumor mill, with all kinds of mockups and photoshoppery being passed off. But I think there’s so much evidence at this point that it’s a certainty. I’m still unsure as to if it will replace or supplement the existing MacBook. My predictions on the thin MacBook:

• Core 2 Duo processor, with two models: 1.8 GHz and 2.0 GHz
• Intel X3100 Integrated Graphics
• 1 GB 667 MHz DDR2 SRAM, upgradable to 4 GB
• 32 GB Flash hard drive, upgradable to 64 GB
• No FireWire, 2 USB 2.0 ports, no ExpressCard slot
• 13″ display, 1440×900, 3 pounds
• Multi-touch trackpad, but not display, with the trackpad taking up the whole surface of beneath the keyboard
• 802.11b/g/n connectivity built in
• No EVDO or anything like it, no wireless induction power charging
• Priced at $1,299, with the beefier model at $1,599
• Black with a silver Apple logo. Period. That’s it.

Somehow, Steve would use his RDF magic to weave the keynote into a talk about mobile technology, and would talk about wireless networks like Wi-Fi. And then, the “one more thing” would come out, and be that which was in the air…

AirPort Digital Hub – Very Likely

The AirPort Digital Hub (which I’ll just call “the Hub”) is a new device that will be a souped up version of the AirPort base station and a NAS box. It will be a wireless router, but it would also act as a file server. It would include 2 mirrored 250 GB hard drives (with 500 GB models), as well as bays for extra hard drives. USB and Firewire ports aplenty in the back would provide external storage. The drives would mirror each other, using hardware RAID, but the user never sees it (although this would require adding two hard drives simultaneously; you wouldn’t be able to just add one). The data itself would be pooled using ZFS, and could be encrypted at the bit level. Combine this with the wireless router, which also happens to know about all of Apple’s networkable products, not to mention a way for developers to integrate with it, you’re talking about a home server that could keep your content in sync across every machine on the network.

Some possible uses for such a device:

• Automated Time Machine backups, encrypted and mirrored. You’re never, EVER losing that damn photo of the kids on that trip.
• One global iTunes database, where everyone in the family could contribute music to a huge pool and sync anything to an iPod. In fact, you could even sync your iPod from another computer on the network
• One photo repository for everyone in the house
• One calendar database, so I can remind my roommates that yes, the rent really is 3 weeks past due and you really do need to pay me
• Sharing files across the house network becomes a cinch
• Create your user account, log in anywhere on the network. Everything comes with you

In fact, properly done, the Hub could be coupled with .Mac. But, Apple can build off the premise of one of .Mac’s cooler features, Back to my Mac, to let you remotely connect to the Hub from anywhere. Oh, your laptop is in sleep mode at home, but you need that file while you’re in the office? Back to my Mac fails, because, well, the machine isn’t on. But “Back to my Hub” has that file (and, in fact, all the backed-up versions of it in Time Machine), and is always on. In fact, you could possibly set up a VPN server to run on the Hub and get access to every machine on your local network from remote locations. You could also create calendar events, and invite people to them (who don’t necessarily have .Mac), and they could accept or reject it, which would then update your calendar. Tons of possibilities of integration with .Mac.

In many ways, the Hub is an awesome mixture of bits of Leopard Server, Windows Home Server, Kerberos, rsync, and the old Apple finesse. But that doesn’t really reveal what it truly is. In a rare, one more, more thing…

Hub replaces the AppleTV – Likely

Oh snap! Turns out the Hub is actually a more sophisticated AppleTV! Steve conveniently forgot to show the back of the device, where the AV ports were. A more sophisticated version of the AppleTV firmware is up there, with integrated iTunes store a la the iPhone. Aside from that, I’m not really sure what else they’d do. However, I think the likelihood of the AppleTV and the Hub being combined is a great idea, and will give Apple some serious headway in the living-room computer space.

Apple Tablet! – Unlikely, but dammit I can dream

I definitely think Apple is going to release a new type of computing device this year, just not at Macworld. This device has commonly been called the “Apple Tablet”, although it is effectively a small notebook with a multi-touch screen. However, I’ve got pretty high hopes for what this device can be, so we’ll just call it the Apple Tablet for now. The Apple Tablet, not the Mac Tablet.

First, I don’t think this will be a tablet computer in the sense that Toshiba or Lenovo makes tablets. I think this device will fit somewhere in between the dismal failure of the UMPC and the dismal failure of the tablet, and will address all the problems that both have suffered. In the case of the UMPC, they’re very difficult to use, and yet they run a full version of Windows CE. The tablet is as large and heavy as a laptop, and just isn’t easy to write on without some effort. The Apple Tablet will be powered by OS X, have a screen size of somewhere between 7-9”, and weigh around 1 pound. I doubt it’ll have the tablet’s signature swivel-screen; instead, it’s just a solid, flat screen, much like the iPhone.

However, note that I’m calling it the Apple Tablet, and not the Mac Tablet. That’s because I don’t think this device will be a Mac. It’ll be powered by OS X, sure, but in the sense that AppleTV, iPhone, and iPod touch are powered by OS X – it doesn’t make them Macs. It’ll use Apple’s mobile device platform that they built with the iPhone, and extend it more onto this device. Of course, interface paradigms will have to change to take into account different screen sizes and use cases, but it’ll be a meld between the Mac and the iPhone. This means it’ll get to cherry pick some things from the Mac, and some from the iPhone. I firmly believe that Apple is trying to create a serious mobile version of OS X that can be used in all, or at least many, things that Apple makes that aren’t Macs. If that’s the case, then it’s plausible that Apple may be extending the idea of an SDK to the Hub, as well as to the Tablet.

So, since Apple is developing a mobile OS X for these devices, let’s look at where the three devices that Apple has released with it (iPhone, iPod touch, and AppleTV) differ from their Mac counterparts. First, there is dramatically less capability to edit and organize information (no ability to add IMAP folders in iPhone Mail, for instance). This is important for my second point: No user-visible file system. At all. Everything you see is organized into clusters of objects. Songs in the iPhone’s music player are physical files on the actual UNIX file system, but to the user, they are merely records. Same is true for calendar events, emails, contacts, and notes. The user never sees a file anywhere. My guess is that Apple is trying to move towards keeping the Mac the only place where you’ll ever worry about a file. The sacrifice comes in the fact that you can’t do as much editing on these portable devices.

In this sense, the Tablet will have an SDK similar to the iPhone. However, applications will have to store their data in a database instead of files. This is very important, because it effectively prevents developers from ever presenting a file-system to the user. If they do, it’s because they’re trying to hack the concept of files back into a database, and if you ever see an app doing that, you really need to run far away from it, because the developer has no idea what he’s doing. Even though this sounds really weird and foreign, it becomes very useful when you start to think about it. Even applications like Microsoft Word, which are completely tied to files, can be adopted to this architecture. The key is to present useful metadata to the user about the actual record the application is maintaining. Think about how Google Docs show you “documents”, not “files” for an idea as to how it would work. And as it turns out, this is a much better way to organize data than files, at least on a mobile device. iPhone has proven that much.

At a technology level, I think this thing will have a serious processor in it. Definitely an Intel x86 of some kind. A full multi-touch display with no keyboard other than onscreen. A pretty decent graphics engine (most likely Intel-integrated). If you’re detecting a trend, yeah, this is effectively a stripped-down Mac from a hardware level. Including all the connectivity options. Built in Wi-Fi, WiMax(?), and Bluetooth.

Oh, and a cell phone radio. Not just EVDO, but a full radio for making calls, doing text messaging, and everything else. It integrates with your iPhone if you have one, but attach a Bluetooth headset or use the built in speakers/mic for making calls (with voice dialing and spoken names when receiving a call).

That’s what I’m hoping for, anyway.

On June 11th, 2007, Apple held the WWDC Keynote where they talked about three things. Leopard, Safari for Windows, and iPhone apps. I don’t need to replay this for you all, but I will anyway – the Leopard announcements were for the most part rehashes, and Safari for Windows was simply fantastic news, both for users of Safari and for web developers. But the iPhone announcement definitely left a sour taste in many mouths, mine included. Not so much the lack of a true iPhone SDK, as I wasn’t really anticipating seeing that at WWDC (as hopeful as I was), but rather the buildup of the announcement.

One of those sour sour mouths is that of Wil Shipley, one of the founders of Delicious Monster. In his latest blog post, he decrys the idea of using JavaScript and Safari as a platform for developing iPhone applications. Many of his reasons, such as a lack of Keychain and difficulty in monetization, are valid. However, there are a couple things that I, as both a Cocoa and web developer, disagree with. Furthermore, it’s completely plausible that the iPhone SDK that we all want soooo bad will be something that runs in the iPhone’s JavaScript interpreter, which I’ll talk more about in a bit.

First, he spends a good time railing against JavaScript. Specifically:

JavaScript was thrown together by some dudes a couple years ago to make web pages kind of, like, do shit and stuff. It’s famous for being slow, hard to read, hard to program, and incompatible across different platforms.

This statement is pretty wrong on all counts, both with respect to JavaScript as a language and a platform for writing the client-side logic of iPhone applications.

1. Hard to read/write. JavaScript isn’t any harder to read or write once you get used to it. In fact, it’s arguably easier to read, as JavaScript’s method calling syntax is significantly closer to C than Objective-C’s is. Someone with experience can read a function like:

Foo.prototype.bar = function(baz) {
	var foobar = document.getElementById("ohsnap");
	foobar.style.backgroundColor = "black";
};

…pretty easily. Compared to the same ObjC method:

-(void)bar:(id)baz{
   id foobar = [document getElementById:@"ohsnap"];
   [[foobar style] setBackgroundColor:@"black"];
}

There isn’t really a readability difference. Once you get used to the prototype syntax in JavaScript, it’s completely a non-issue – and I went from knowing zero JavaScript to doing full OO stuff in less than a weekend.

2. Slow execution. This is mostly a per-browser thing (IE, I’m looking at you). And while I agree that, in generic web development, this is an issue, you don’t have to worry about any of that. Because the iPhone doesn’t run Firefox, Opera, or IE. It runs Safari, and specifically JavaScriptCore (which is part of the WebKit framework on OS X that runs as a JavaScript interpreter), which is the fastest out of any of them for most tasks.

Furthermore, the speed of JavaScript interpreters across the board (with the exception of Internet Explorer, as it’s pretty obvious that Microsoft, with Windows and Office, feels very threatened by web applications) is bound to increase significantly in the next couple years. With the rise of more JavaScript-heavy web apps, the optimizations should definitely continue as they have for the past couple of years. Stuff like JIT compilation of code will help a lot.

And all that being said, JavaScriptCore is already pretty damn fast. You can pull off some decent framerates with even full-screen animations on the iPhone’s version of Safari. It’s no Core Animation, but it’s usable.

3. Incompatible across platforms. JavaScript as a language is pretty standardized. The DOM bindings in the browsers are where the incompatibilities lie. It’s fairly easy to spot where to workaround browser incompatibilities.

And besides, if you’re not concerned with generic web development and are only focused on writing iPhone apps, who cares?! You’ve got one target, Safari. Period. You don’t have to do the cryptic tests, like checking for the existence of document.all, to determine what browser you’re running on.

Apple’s got a decision to make: it can try to fix all the myriad problems with developers actually trying to deploy non-free applications using AJAX, OR it can say, “Look, this isn’t going to be easy, but we’re smarter than hell, and we’re going to make a secure, tight, mini-Cocoa for the iPhone — this is our chance to start fresh and do everything right. No NSCells, everything animated, resolution-independent from the start, no CF stacks under and NS stacks, always garbage-collected, all database-driven…”

And now we come to the crux of my argument. Who’s to say that this new mini-Cocoa couldn’t be written as a set of JavaScript calls embedded in the interpreter? JavaScript is already all garbage collected. Apple could embed technologies such as Core Animation right into JavaScriptCore, so creating an animation with CA could be as simple as a couple JavaScript functions, exposed to John Q. Developer in a similar fashion as the window and document objects.

Here’s the kicker – since these functions and properties would be compiled into the interpreter, they would be running as native, (I’m assuming) Cocoa code, so any possibility of slowdown would come from the JavaScript lexer and not from the actual JavaScript code. Therefore, your only speed limitation is that of JavaScriptCore’s ability to quickly process code.

If Apple’s claim of security threats presented by Cocoa/Obj-C apps is real, then it completely makes sense for them to want to sandbox it. That’s not stopping them, however, from implementing an entire application framework into iPhone’s JavaScriptCore. Throw in SQLite storage and the ability to save the app to the iPhone’s app launcher, and you’ve got yourself a pretty rock solid, secure application platform. And it wouldn’t surprise me if this is the compromise that Apple comes up with.

Granted, there are definitely speed issues to contend with; Apple’s only got a 620 MHz ARM processor in the iPhone, so it may just not be fast enough. But languages like Python have much faster interpreters, and may be investigated rather than JavaScript. But if Apple really needs the sandboxing that something like Safari requires in order to open up to native application code, well, I’ll take what I can get.

Also, someone please tell Shipley that you can’t do “programming in AJAX”. 🙂