Replacing Crashplan

I’ve been pretty happy with Crashplan for five years or so, although lately not so much. Obviously, one reason to be unhappy with Crashplan is that they’re no longer supporting the family plan I was using to back up all our Macs. Worse, their quality of service seems to have (understandably) slipped as the plan I still have for nearly another ninety days has dropped.

Exhibit 1: my wife bought a new laptop. When she tried to restore files from her old laptop, they were MIA.

So, here we are at a nasty juncture where our supposedly bulletproof fire-and-forget backup system is (a) not working terribly well and (b) shortly going to not work at all.

Possible Crashplan Replacements

The obvious replacement is Carbonite. The problem with Carbonite is that it’s going either (a) be a lot more expensive than Crashplan was (because of our family plan — which is the equivalent of, effectively, n $100/year plans where n is the number of computers you back up; the small business plan works out as being stupidly expensive if you have more than 250GB of data) or (b) require me to do a bunch of work (i.e. set up one computer as the family server, have all the other devices back up to it, and then back it up via Carbonite. So Carbonite will either cost $300 (say) per month or $100 per month but require me to be my own network engineer. Oh, and forget mobile backups.

If I want to do a whole bunch of work I might as well just use Amazon S3. For 2TB of data that’s a mere $46/month. Ouch. I could probably use their cheaper long term storage, but now I’m basically starting my own Crashplan / Dropbox implementation and that sounds kind of like hard work. Forget that.

So, on to the “consumer” options:

Annual Cost$99 for 1TB$540 for unlimited10TB for $60$120 for 2TB$240 for 2TB$100 for 5 users 1TB each$120 for 2TB

Note that all these services support web browser access, so you can get at your files from any device with a web browser, but I’m talking about file-system integration where you can just save your file in the usual place and it’s seamlessly backed up to the cloud.

At first glance, Hubic looks like the standout value-for-money option. (Hubic is essentially like Dropbox, except it’s run by a gigantic hosting company). The problem is that I’ve found Hubic to have a poor user experience, especially with regard to performance. (My own experience is quite limited — and I’m kind of shocked that my blog post on Dropbox vs. Box vs. Hubic ranks quite high on Google searches for “Hubic Review”.) This may be a result of server location, or simply under-provisioning (10TB is so close to “unlimited” that I imagine it attracts a lot of abusive users).

At second glance, Microsoft OneDrive seems like a great deal at 5TB for $100/year. The problem is that it’s 5x 1TB per user, which is effectively 1TB. Still, a great deal if you’re happy with 1TB and want Microsoft Office for your family.

The shock comes at third glance — Apple’s product is competitively priced (cheaper than Dropbox!). It doesn’t support Android (surprise!) but aside from that it’s a great deal, you can share it with your family, it requires no real configuration and — this is the kicker — it’s smart about mirroring stuff to your devices. Want a 1TB photo library in the cloud? Great. Want it on every one of your family computers? Not so much.


Hubic is the clear winner in terms of price per unit storage. Apple is the clear winner in terms of functionality and comes second in price. When I take into account the fact that I pay Apple $3/month for a lower tier of storage just for convenient mobile backups it’s an even better deal (hooray for Opportunity Cost). After some consideration I’m thinking of doing both. Hubic for volume backup and iCloud for convenience.

I’ll let you know how it works out.

What does a good API look like?

I’m temporarily unemployed — my longest period of not having to work every day since I was laid off by Valuclick in 2010 — so I’m catching up on my rants. This rant is shaped by recent experiences I had during my recent job interview process (I was interviewed by two Famous Silicon Valley Companies, one of which hired me and the other of which “didn’t think I was a good fit”). Oddly enough, the company that hired me interviewed me in an API-agnostic (indeed almost language-agnostic) way while the company that didn’t interviewed me in terms of my familiarity with an API created by the other company (which they apparently are using religiously; although maybe not so much following recent layoffs).

Anyway, the API in question is very much in vogue in the Javascript / Web Front End world, in much the same way as CoffeeScript and Angular were a couple of years ago. (Indeed, the same bunch of people who were switching over to Angular a few years back have recently been switching over to this API, which is funny to watch). And this API and the API it has replaced in terms of mindshare is in large part concerned with a very common problem in UI programming.

A Very Common Problem in UI Programming

Probably the single most common problem in UI programming is synchronizing data with the user interface, or “binding”. There are three fundamental things almost any user-facing program has to do:

  • Populate the UI with data you have when (or, better, before) the UI first appears on screen
  • Keep the UI updated with data changed elsewhere (e.g. data that changes over time)
  • Update the data with changes made by the user

This stuff needs to be done, it’s boring to do, it often gets churned a lot (there are constant changes made to a UI and the data it needs to sync with in the course of any real project). So it’s nice if this stuff isn’t a total pain to do. Even better if it’s pretty much automatic for simple cases.

The Javascript API in question addresses a conspicuous failing of Javascript given its role as “the language of the web”. In fact almost everything good and bad about it stems from its addressing this issue. What’s this issue? It’s the difficulty of dealing with HTML text. If you look at Perl, PHP, and JSP, the three big old server-side web-programming languages, each handles this particular issue very well. The way I used to look at it was:

  • A perl script tends to look like a bunch of code with snippets of HTML embedded in it.
  • A PHP script tends to look like a web page with snippets of code embedded in it.
  • A JSP script tends to look like a web page with horrible custom tags and/or snippets of code embedded in it.

If you’re trying to solve a simple problem like get data from your database and stick it in your dynamic web page, you end up writing that web page the way you normally would (as bog standard HTML) and just putting a little something where you want your data to be and maybe some supporting code elsewhere. E.g. in PHP you might write “<p>{$myDate}</p>” while in  JSP you’d write something like “<p><%= myDate %></p>”. These all look similar, do similar things, and make sense.

It’s perfectly possible to defy these natural tendencies, e.g. write a page that has little or no HTML in it and just looks like a code file, but this is pretty much how many projects start out.

Javascript, in comparison, is horrible at dealing with HTML. You either end up building strings manually “<p>” + myDate + “</p>” which gets old fast for anything non-trivial, or you manipulate the DOM directly, either through the browser’s APIs, having first added metadata to your existing HTML, e.g. you’d change “<p></p>” to “<p id=”myDate”></p>” and then write “document.getElementById(‘myDate’).text = myDate;” in a script tag somewhere else.

The common solution to this issue is to use a template language implemented in Javascript (there are approximately 1.7 bazillion of them, as there is of anything involving Javascript) which allow you to write something like “<p>{{myDate}}</p>” and then do something like “Populate(slabOfHtml, {myDate: myDate});” in the simplest case (cue discussion about code injection). The net effect is you’re writing non-standard HTML and using a possibly obscure and flawed library to manipulate markup written in this non-standard HTML (…code injection). You may also be paying a huge performance penalty because depending on how things work, updating the page may involve regenerating its HTML and getting the browser to parse it again, which can suck — especially with huge tables (or, worse, huge slabs of highly styled DIVs pretending to be tables). OTOH you can use lots of jQuery to populate your DOM-with-metadata fairly efficiently, but this tends to be even worse for large updates.

The API in question solves this problem by uniting non-standard HTML and non-standard Javascript in a single new language that’s essentially a mashup of XML and Javascript that compiles into pure Javascript and [re]builds the DOM from HTML efficiently and in a fine-grained manner. So now you kind of need to learn a new language and an unfamiliar API.

My final interview with the company that did not hire me involved doing a “take home exam” where I was asked to solve a fairly open-ended problem using this API, for which I had to actually learn this API. The problem essentially involved: getting data from a server, displaying a table of data, allowing the user to see detail on a row item, and allowing the user to page through the table.

Having written a solution using this unfamiliar API, it seemed very verbose and clumsy, so I tried to figure out what I’d done wrong. I tried to figure out what the idiomatic way to do things using this API was and refine them. Having spent a lot of spare time on this exercise (and I was more-than-fully-employed at the time) it struck me that the effort I was spending to learn the API, and to hone my implementation, were far greater than the effort required to implement the same solution using an API I had written myself. So, for fun, I did that too.

Obviously, I had much less trouble using my API. Obviously, I had fewer bugs. Obviously I had no issues writing idiomatic code.

But, here’s the thing. Writing idiomatic code wasn’t actually making my original code shorter or more obvious. It was just more idiomatic.

To bind an arbitary data object to the DOM with my API, the code you write looks like this:


The complex case looks like this:

$(<some-selector>).bindomatic(<data-object>, <options-object>);

Assuming you’re familiar with the idioms of jQuery, there’s nothing new to learn here. The HTML you bind to needs to be marked up with metadata in a totally standard way (intended to make immediate sense even to people who’ve never seen my code before), e.g. to bind myDate to a particular paragraph you might write: “<p data-source=”.myDate”></p>”. If you wanted to make the date editable by the user and synced to the original data object, you would write: “<input data-bind=”.myDate”>”. The only complaints I’ve had about my API are about the “.” part (and I somewhat regret it). Actually the syntax is data-source=”myData.myDate” where “myData” is simply an arbitrary word used to refer to the original bound object. I had some thoughts of actually directly binding to the object by name, somehow, when I wrote the API, but Javascript doesn’t make that easy.

In case you’re wondering, the metadata for binding tabular data looks like this: “<tr data-repeat=”.someTable”><td data-source=”.someField”></td></tr>”.

My code was leaner, far simpler, to my mind far more “obvious”, and ran faster than the code using this other, famous and voguish, API. There’s also no question my API is far simpler. Oh, and also, my library solves all three of the stated problems — you do have to tell it if you have changes in your object that need to be synced to the UI — (without polluting the source object with new fields, methods, etc.) while this other library — not-so-much.

So — having concluded that a programming job that entailed working every day with the second API would be very annoying — I submitted both my “correct” solution and the simpler, faster, leaner solution to the second company and there you go. I could have been laid off by now!

Here’s my idea of what a good API looks like

  • It should be focused on doing one thing and one thing well.
  • It should only require that the programmer tell it something it can’t figure out for itself and hasn’t been told before.
  • It should be obvious (or as obvious as possible) how it works.
  • It should have sensible defaults
  • It should make simple things ridiculously easy, and complex things possible (in other words, its simplicity shouldn’t handcuff a programmer who wants to fine-tune performance, UX, and so on.

XCode and Swift

I don’t know if the binding mechanisms in Interface Builder seemed awesome back in 1989, but today — with all the improvements in both Interface Builder and the replacement of Objective-C with the (potentially) far cleaner Swift — they seem positively medieval to me, combining the worst aspects of automatic-code-generation “magic” and telling the left hand what the left hand is doing.

Let’s go back to the example of sticking myDate into a the UI somewhere. IB doesn’t really have “paragraphs” (unless you embed HTML) so let’s stick it in a label. Supposing you have a layout created in IB, the way you’re taught — as a newb — to do it this is:

  1. In XCode, drag from your label in IB to the view controller source code (oh, step 0 is to make sure both relevant things are visible)
  2. You’ll be asked to name the “outlet”, and then XCode will automagically write this code: @IBOutlet weak var myDate: UILabel!
  3. Now, in — say — the already-written-for-you viewDidLoad method of the controller you can write something like: myDate.text = _myDate (it can’t be myDate because you’re used myDate to hold the outlet reference).

Congratulations, you have now solved one of the three problems. That’s two lines of code, one generated by magic, the other containing no useful information, that you’ve written to get one piece of data from your controller to your view.

Incidentally, let’s suppose I wanted to change the outlet name from “myDate” to “dateLabel”. How do I do that? Well, you can delete the outlet and create a new outlet from scratch using the above process, and then change the code referencing the outlet. Is there another way? Not that I know of.

And how to we solve the other two problems?

Let’s suppose we’d in fact bound to an input field. So now my outlet looks like this: @IBOutlet weak var myDate: UITextField! (the “!” is semantically significant, not me getting excited).

  1. In XCode, drag from the field in IB to the view controller source code.
  2. Now, instead of creating an outlet, you select Action, and you make sure the type is UITextField, and change the event to ValueChanged.
  3. In the automatically-just-written-for-you Action code add the code _myDate = sender.text!

You’re now solved the last of the three problems. You’ve had a function written for you automagically, and you’ve written one line of retarded code. That’s three more lines of code (and one new function) to support your single field. And that’s two different things that require messing with the UI during a refactor or if a property name gets changed.

OK, what about the middle problem? That’s essentially a case of refactoring the original code so that you can call it whenever you like. So, for example, you write a showData method, call it from viewDidLoad, and then call it when you have new data.

Now, this is all pretty ugly in basic Javascript too. (And it was even uglier until browsers added documentQuerySelector.) The point is that it’s possible to make it very clean. How to do this in Swift / XCode?

Javascript may not have invented the hash as a fundamental data type, but it certainly popularized it. Swift, like most recent languages, provides dictionaries as a basic type. Dictionaries are God’s gift to people writing binding libraries. That said, Swift’s dictionaries are strongly typed which leads to a lot of teeth gnashing.

Our goal is to be able to write something like:


It would be even cooler to be able to round-trip JSON (the way my Javascript binding library can). So if this works we can probably integrate a decent JSON library.

So the things we need are:

  • Key-value-pair data storage, i.e. dictionaries — check!
  • The ability to add some kind of metadata to the UI
  • The ability to find stuff in the UI using this metadata

This doesn’t seem too intimidating until you consider some of the difficulty involved in binding data to IB.


The way tables are implemented in Cocoa is actually pretty awesome. In essence, Cocoa tables (think lists, for now) are generated minimally and managed efficiently by the following mechanism:

The minimum number of rows is generated to fill the available space.

When the user scrolls the table, new rows are created as necessary, and old rows disposed of. But, to make it even more efficient rather than disposing of unused rows, they are kept in a pool and reallocated as needed — so the row that scrolls off the top as you scroll down is reused to draw the row that just scrolled into view. (It’s more complex and clever than this — e.g. rows can be of different types, and each type is pooled separately — but that’s the gist.) This may seem like overkill when you’re trying to stick ten things in a list, but it’s ridiculously awesome when you’re trying to display a list of 30,000 songs on your first generation iPhone.

In order for this to work, there’s a tableDelegate protocol. The minimal implementation of this is that you need to tell the table how many rows of data you have and populate a row when you’re asked to.

So, for each table you’re dealing with you need to provide a delegate that knows what’s supposed to go in that specific table. Ideally, I just want to do something like self.bind(data) in the viewDidLoad method, how do I create and hook up the necessary delegates? It’s even worse if I want to use something like RootViewController (e.g. for a paged display) which is fiddly to set up even manually. But, given how horrible all this stuff is to deal with in vanilla Swift/Cocoa, that’s just how awesome it will be not to have to do any of it ever again if I can do this. Not only that, but to implement this I’m going to need to understand the ugly stuff really well.


Adding Metadata to IB Objects

The first problem is figuring out some convenient way of attaching metadata to IB elements (e.g. buttons, text fields, and so on). After a lot of spelunking, I concluded that my first thought (to use the accessibilityIdentifier field) turns out to be the most practical (even though, as we shall see, it has issues).

There are oodles of different, promising-looking fields associated with elements in IB, e.g. you can set a label (which appears in the view hierarchy, making the control easy to find). This would be perfect, but as far as I could tell it isn’t actually accessible at runtime. There’s also User Defined Runtime Attributes which are a bit fiddly to add and edit, but worse, as far as I’ve been able to tell, safely accessing them is a pain in the ass (i.e. if you simply ask for a property by name and it’s not there — crash!). So, unless I get a clue, no cigar for now.

The nice thing about the accessibilityIdentifier is that it looks like it’s OK for it to be non-unique (so you can bind the same value to more than one place) and it can be directly edited (you don’t need to create a property, and then set its name, set its type as you do for User Defined Runtime Attributes). The downside is that some things — UITableViews in particular — don’t have them. (Also, presumably, they have an impact on accessibility, but it seems to me like that shouldn’t be a problem if you use sensible names.)

So my first cut of automatic binding for Swift/Cocoa took a couple of hours and handled UITextField and UILabel.

class Bindery: NSObject {
    var view: UIView!
    var data: [String: AnyObject?]!
    init(view v:UIView, data dict:[String: AnyObject?]){
        view = v
        data = dict
    func subviews(name: String) -> [UIView] {
        var found: [UIView] = []
        for v in view!.subviews {
            if v.accessibilityIdentifier == name {
        return found
    @IBAction func valueChanged(sender: AnyObject?){
        var key: String? = nil
        if sender is UIView {
            key = sender!.accessibilityIdentifier
            if !data.keys.contains(key!) {
        if sender is UITextField {
            let field = sender as? UITextField
            data[key!] = field!.text
    func updateKey(key: String){
        let views = subviews(key)
        let value = data[key]
        for v in views {
            if v is UILabel {
                let label = v as? UILabel
                label!.text = value! is String ? value as! String : ""
            else if v is UITextField {
                let field = v as? UITextField
                field!.text = value! is String ? value as! String : ""
                field!.addTarget(self, action: "valueChanged:", forControlEvents: .EditingDidEnd)
    func update() -> Bindery {
        for key in (data?.keys)! {
        return self

Usage is pretty close to my ideal with one complication (this code is inside the view controller):

    var binder: Bindery
    var data:[String: AnyObject?] = [
        "name": "Anne Example",
        "sex": "female"

    override func viewDidLoad() {
        // Do any additional setup after loading the view, typically from a nib.
        binder = Bindery(view:self.view, data: data).update()

If you look closely, I have to call update() from the new Bindery instance to make things work. This is because Swift doesn’t let me refer to self inside an initializer (I assume this is designed to avoid possible issues with computed properties, or to encourage programmers to not put heavy lifting in the main thread… or something). Anyway it’s not exactly terrible (and I could paper over the issue by adding a class convenience method).

OK, so what about tables?

Well I figure tables will need their own special binding class (which I shockingly call TableBindery) and implement it so that you need to use an outlet (or some other hard reference to the table) and then I use Bindery to populate each cell (this lets you create a cell prototype visually and then bind to it with almost no work). This is how that ends up looking like this (I won’t bore you with the implementation which is pretty straightforward once I worked out that a table cell has a child view that contains all of its contents, and how to convert a [String: String] into a [String: AnyObject?]):

    var data:[String: AnyObject?] = [
        "name": "Anne Example",
        "sex": "female"
    override func viewDidLoad() {
        tableBinder = TableBindery(table:table, array: tableData).update()

In the course of getting this working, I discover that the prototype cells do have an accessibilityIdentifier, so it might well be possible to spelunk the table at runtime and identify bindings by using the attributes of the table’s children. The fact is, though, that tables — especially the sophisticated multi-section tables that Cocoa allows — probably need to be handled a little more manually than HTML tables usually do, and having to write a line or two of code to populate a table is not too bad.

Now imagine if Bindery supported all the common controls, provided a protocol for allowing custom controls to be bound, and then imagine an analog of TableBindery for handling Root view controllers. This doesn’t actually look like a particularly huge undertaking, and I already feel much more confident dealing with Cocoa’s nasty underbelly than I was this morning.

And, finally, if I really wanted to provide a self.bindData convenience function — Swift and Cocoa make this very easy. I’d simply extend UIView.

Dropbox vs. Box vs. HubiC

Edit: Brain Fart — I seem to have omitted about a paragraph of pertinent information.

I’ll assume you all know what Dropbox is. If you don’t, go get Dropbox now. It’s free and it’s awesome.

The only downside of Dropbox is that if you want more than the 2GB of storage you get for free, it gets more expensive, and the upper limit on how much you can store is (for practical purposes) quite low. Personally, I haven’t found either of these an issue — but thanks to my link on, I have a pretty huge “free” account. But it would be awesome to have something like Dropbox that was so big I could just stop managing what I keep on it altogether (of course, this is the problem with stuff that’s free — you waste it). has been around about as long as Dropbox (heck, it has an even better domain name, right?) but has been targeted at the enterprise. (their capitalization) I just found out about via Hacker News. It offers more free storage than Dropbox, but not quite as much as Box, and vastly cheaper paid plans, including about $140/year for 10TB. (I’m not sure how you can actually get 10TB into it, short of using a ZFS or Drobo style multi-disk volume.)

2GB vs 50GB vs 25GB

This is how much storage you get for free.

$100/year for 100GB vs. $10/month for 100GB vs. $13.60/year for 100GB (or $136/month for 10TB)

Edit: I’ve corrected the costs for HubiC.

This is how much it costs for more storage. Box gives you — by far — the most free storage but gets more expensive than Dropbox (while offering various enterprisey features). HubiC is insanely cheaper than both of them. By way of comparison, iCloud costs $20/year for 20GB, so in terms of dollars per unit storage, only HubiC is a better deal. In terms of useful features out of the box, Dropbox support is built into far more programs while iCloud offers useful functionality (notably over-the-air backups of devices and integration with Apple products) to Mac and iOS users that no other platform can (currently) match.

For Android users, the iCloud equivalent is Google Drive, which gives you 15GB free, and costs $60/year for 100GB, making it a bit cheaper (and less useful) than Dropbox.

Mac OS X Integration

All three programs appear as folders in your home directory by default, and stick shortcuts to themselves in Finder’s sidebar. Having installed HubiC and then Box after installing Dropbox, Box was very flaky when first installed. Its installer provided no feedback, and the first few times I tried to launch the application nothing seemed to happen, followed by weird broken delayed launches. Once I’d patiently killed a bunch of instances and started over it worked well.

Box and Dropbox have similar levels of Finder integration — they indicate the state of files and provide context menu items for sharing links. HubiC appears not to do anything like this, unfortunately.

All three applications provide status menus — those icons that appear in the menubar to the left of the Spotlight magnifying glass. I should note that HubiC’s icon looks like a shapeless blue blob — a blue cloud? — which is an anti-feature. The status menus of all three seem to be perfectly fine and offer decent functionality. Oddly enough, Box and Dropbox no longer keep you apprised of your usage level whereas HubiC does.

Box has one glaring defect — it won’t sync Mac OS X “bundles” (i.e. directories masquerading as files). I have no idea why — they’re just directories. It tells you to zip them up first (gee, how about doing it yourself?)

All three services offer support for all the usual platforms — although I can’t comment on how good any of them are (except the Dropbox client for iOS is decent, and all three work decently in a web browser, although HubiC’s in-browser account management is awful). I cannot yet comment on the security of Box or HubiC. Dropbox offers, and I use, two-factor authentication, and I’m pretty sure HubiC does not (but its website is pretty hard to navigate so maybe it’s there somewhere).


If you just want some free storage and don’t mind not being able to sync bundles then Box is a better deal than Dropbox and it’s probably quite robust given the money behind it. If you’re already using Dropbox and don’t need more storage, Box does not work as well so unless you want its enterprisey features (and you know who you are) you might as well stick with Dropbox. I can’t really comment on HubiC until I’ve exercised it by, saying syncing a buttload of RAW files to it (if I’m going to get more cloud storage, I want enough of it to not need more than one service). If you’re interested, HubiC is a damn good deal for free and it works side-by-side with the others. If it turns out to deliver the goods, I may well end up buying a 10TB plan and switching to it from Crashplan.


Yesterday, 9to5 Mac noticed that Apple had rejigged its online store so as to position AppleTV as a product category. Also interestingly, Lee Clow has apparently hinted that, for the first time since 1984, Apple may be airing a super bowl spot. And then during Apple’s first quarter earnings call, Tim Cook foreshadowed new product categories for 2014. We’ve also had rumors of Apple cutting content deals over the last year that never turned into announcements.

It seems pretty clear that one new product category is going to be AppleTV. And here’s where things get really interesting.


  • Apple’s online store now treats AppleTV as a product category rather than an accessory.
  • Apple is not currently selling an Apple-branded 4K display (the 4K displays it is selling are from Sharp)
  • Apple’s OS-level support for 4K displays is conspicuously poor (they need to be treated as Retina displays)
  • iOS now provides proper (API) support for bluetooth game controllers
  • The price for high quality 4K displays is about to drop well under $1000
  • The current AppleTV does not support 4K displays
  • The current AppleTV does not support 802.11ac


  • The last crop of consoles (Xbox One, PS4, Wii U) had the most anemic rollout (in terms of launch titles) in recent memory
  • The way AppleTV’s remote app works is primitive compared to the way Chromecast can be “handed” a playback task (and Apple knows this)
  • AppleTV currently needs a system update in order to add a new content channel; the tools for managing “apps” in AppleTV are primitive to put it mildly
  • There is already an ecosystem of iOS-compatible controllers and iOS games supporting those controllers
  • 4K displays blur or even erase the line between monitors and TVs


  • Apple has bought a Super Bowl spot
  • Nintendo has suggested it is looking at developing titles for mobile platforms
  • Apple has been negotiating content deals with major players (movie studios, etc.) but it has borne no visible fruit as yet


  • Apple is at last going to release an AppleTV console (whether it’s called AppleTV or not remains to be seen)
    • It will have access to major new sources of content
    • It will have an App Store
    • It will support Bluetooth controllers
    • It will support the use of other iOS devices as controllers
    • It will be powered by the A7 or something more powerful
    • If it is powered by a new chip (e.g. “A7x”) it will support 4K (the A7 can drive 2K)
    • It will have a shockingly good set of launch titles (how else to explain the lackluster launch titles for all the other consoles?)
    • It will not have a tuner or Cablecard support or any other horrific kludge
    • It may introduce streaming video with ads for content from networks (effectively on-demand playback of licensed content with ads)
    • It will cost $199-399 (I’d predict $199, but Apple might actually sell a range of products with varying storage capacities)
    • The ghastly Apple Remote iOS app will be given a proper overhaul, and work in more of a peer-to-peer manner (and be able to hand off tasks to the AppleTV)
  • An even smaller $99 version which doesn’t play games might continue as AppleTV Nano or some such
  • We’re going to see extensive 4K support across Apple’s product lines over the next 12 months
  • We’re going to see Apple-branded 4K displays (“Retina HD” perhaps?) designed to work seamlessly with all this new stuff

Drawing on the iPad

iOS Apps for Sketching Ideas — the top five apps shown are the ones I'll discuss below.
iOS Apps for Sketching Ideas — the top five apps shown are the ones I’ll discuss below. I may review the other three another day. (The desktop picture is a Paul Klee, in case you’re wondering.)

I’m willing to give almost any halfway-decent looking iPad graphics application a shot, and I thought I’d discuss some of my favorites. What I’d really like is for a single app to take the best ideas from each of them and combine them into a single super app (that was nonetheless lightweight and simple, right?)

Autodesk Sketchbook Pro ★★★★★

Autodesk Sketchbook Pro has some nice pencil tools, and the pinnable palettes are also good, but — once the leader in this category — it lags behind the other apps in almost all respects.
Autodesk Sketchbook Pro has some nice pencil tools, and the pinnable palettes are also good, but — once the leader in this category — it lags behind the other apps in almost all respects.

This was my favorite of the lot until I started working on this review and compared it to its rivals. It used to have the edge on ArtRage in terms of responsiveness, a decent UI (I still like its three-fingered swipe for undo), and a not-quite-so-digital feel to its brushes compared with ArtStudio, but as I compared the latest versions of these apps, I rethought what I assumed would be my take on these apps. It’s probably worth noting that my love of Sketchbook Pro dates to my using it on my first generation iPad, while I revisited all these apps for this review on my fourth generation iPad. So if you’re using an older iPad you may find Sketchbook Pro significantly more usable than, say, ArtRage.

There’s basically nothing about Sketchbook Pro that stands out from this crowd, and — especially compared with ArtRage — I really don’t see any real reason to use it at all right now. Too many of Sketchbook Pro’s brushes are, essentially, booby-traps.

  • Really nice pencil tools
  • Being able to pin various palettes in place is nice, and I like the three-fingered swipe to undo
  • The “lens” thing for changing brush size and opacity still perplexes me despite using this app for years
  • Very fast and responsive
  • Annoying: support for multiple resolutions makes the document navigation UI even more cumbersome
  • Mixed: they’re trying to improve color management (which kind of sucked) but app is currently a bit buggy as a result
  • Syncs to iCloud (good) but torpid syncing owing to large file sizes (bad).
  • Bad: many of the brushes are pretty awful (including most of the defaults) and produce mechanical results (compared to ArtRage)

ArtRage ★★★★

ArtRage is a touch-optimized version of the desktop program of the same name (which I used before the iPad came out). It’s essentially a simplified version of the ridiculously complicated and cluttered Fractal / Metacreations / Corel Painter. I’m not a hardcore Painter user so for my purposes it’s the program I really wanted Painter to be (at the price I wanted to pay), but there are some seriously awesome artists using Painter, who probably use it all day every day, and I doubt ArtRage meets their needs.

All that aside, ArtRage on the iPad was great but sometimes sluggish on the original iPad. On my new iPad 4 it’s just great.

ArtRage has, flat out, the best brushes and produces the best looking images with the least effort if you're simply after an "organic" look.
ArtRage has, flat out, the best brushes and produces the best looking images with the least effort if you’re simply after an “organic” look.
  • The best brushes and simulated natural media by far (ArtRage started out on the desktop as an indie clone of Painter)
  • Produces the best output for the least effort
  • Generally good color picker although it can be hard to get the color you want
  • Bad: can be quite sluggish on older hardware
  • Bad: configuring brushes is fiddly — indeed, so is just creating a new, blank document

Paper by Fifty Three ★★★★★

Paper by Fifty-Three has the best interface for organizing your documents and creating new documents. Unfortunately, it is by far the worst actual program to work and the most expensive of those discussed.
Paper by Fifty-Three has the best interface for organizing your documents and creating new documents. Unfortunately, it is by far the worst actual program to work and the most expensive of those discussed.

I have more to say about Paper than any of the other programs because it’s so infuriating, but has so much potential. Basically, I want its best features ripped off and added to Adobe Ideas.

Paper makes a very good first impression — so good I paid for the tool package. The problem is that Paper is by turns enchanting (document management) and infuriating (half-baked UX ideas). It uses pinch to zoom to switch between the book, page-flip, and drawing views as a result of which you can’t pinch to zoom or pan in the actual drawing view. At first you’ll love the “two-fingered rewind” to quickly go back and forth through lots of changes. Soon you’ll curse having to use it every time a failed page turn or palette retrieval leaves a random spot on a drawing.

In the drawing view you can flip between pages of your book by swiping from the screen edge (and this also creates new documents if you turn past the last page) — it’s delightful when it works, and creates marks on your pages when it doesn’t. Even so, the entire metaphor of organizing your work into notebooks with customizable covers is great and I wish the other programs did something half as nice. But once you get past the surface, it’s not very deep. E.g. no cloud or dropbox sync.

Two of the tools — the basic pen (free) and the watercolor brush ($1.99 by itself) — are lovely, but you can’t configure them at all and the other tools (I can’t speak for the color mixer, which came out recently and costs another $2 to activate) are pretty much useless to me. (And you can’t configure them either.)

  • Lovely interface for flipping through images (drag from off-screen to switch pages)
  • Great feel on some of the tools (especially the pen and watercolor)
  • Looks good, easily customized “book” covers
  • Mixed: lots of interesting interaction ideas, unfortunately most are half-baked
  • Meh: the tool palette autodisappears — getting it back often leads to mistouches
  • Meh: novel “two finger wind” for undo/redo — might be better if it weren’t so often needed to handle mis-touches caused by other novel UI features (e.g. the page turn frequently leads to stray splotches in pages.
  • Bad: can’t undo after turning a page (and turning a page often causes accidental marks on a drawing)
  • Sort of bad: No actual text tool, forcing you to write text with your finger (which I wouldn’t mention if this were a better drawing program — e.g. let me zoom in — but it really detracts from the whole “virtual moleskine” thing)
  • Bad: Cannot zoom and pan
  • Good: default pen and watercolor brush are lovely. Bad: Other tools are kind of useless Worse: They charge you (quite a bit) for every little feature.
  • Good: nicely designed five-color themes. Bad: only five colors. Ugly: you need to pay $1.99 to be able to create new colors. Uglier: missing tools (e.g. the two dollar color mixer) appear as silhouettes in the tool panel, and when touched you get advertised at.

ArtStudio ★★★★

ArtStudio takes a pragmatic approach to simply being a very good color image manipulation tool.
ArtStudio takes a pragmatic approach to simply being a very good color image manipulation tool.

Originally, Art Studio seems to have been targeted at kids, and included things like (quite good) drawing lessons. It had a very similar interface to Sketchbook Pro, and essentially behaved like a very solid “color Mac paint with layers”. I pretty much ignored Art Studio over the last year or so, and when I returned I was initially shocked and soon delighted to discover it had chosen to carve its own path. It now seems to be trying to be the swiss army knife image editor for the iPad. The only thing it really lacks is ArtRage’s simulated brushes and media.

  • Probably the closest thing to the desktop version of Photoshop for the iPad
  • Pragmatic decision to go for — essentially — desktop interface mostly pays off
  • Easiest app to learn for desktop users
  • Fast and light
  • Editable text layers
  • Latest version has very configurable brushes and good preview of settings

Adobe Ideas ★★★★★

Adobe Ideas was designed specifically for sketching out ideas (hence the name) and I have to say it's a fabulous program for exploratory sketching.
Adobe Ideas was designed specifically for sketching out ideas (hence the name) and I have to say it’s a fabulous program for exploratory sketching.

Adobe Ideas is a really interesting program. It was Adobe’s first iOS app as far as I know, and seems to have been produced by some kind of skunkworks team along the lines of Lightroom, so it shows no sign of bloat or deliberate handicapping. It’s vector based, but works like a drawing/painting program and produces quite organic-looking results. It has excellent layer support (I think this is a freemium feature, but I paid $5 or whatever it was within minutes of downloading the app when it first came out).

  • Vector-based, resolution-independent, zoom in and draw details in nooks and crannies, etc.
  • Small file sizes (which also makes syncing quicker relative to, for example, Sketchbook Pro)
  • Rather good feel to the brushes (similar in feel to Paper in many respects, but with the advantages of being vector-based, having zoom and pan, and so on)
  • Individual tools remember their color settings making it very easy to switch between (say) a nearly black pen tool and a translucent grey or colored high-lighter.
  • Bad: color management is pretty bad (why are themes restricted to five colors?).
  • Bad: an actual text tool would be nice.

The Perfect Art Program

  • Paper’s interface for organizing documents into “notebooks” and flipping through sketches by dragging from off-screen etc. But pan and zoom should be for working on images, not navigating the file system.
  • Artrage’s pens, brushes, and media.
  • ArtStudio’s basic functionality — filters, editable text layers, configurable brushes with live preview.

Improving Adobe Ideas

Obviously, I think Adobe Ideas is pretty great as it is (and you know how much I have grown to despise Adobe in general), but it could still be better. Adobe Ideas is in a category by itself, and it would still be useful beside the perfect drawing program described above. Fundamentally, Adobe Ideas with Paper’s notebook metaphor for managing your stuff (suitably modified to match its minimalist aesthetic) would be wonderful.

  • Adobe Ideas drawing engine
  • Create brush/color presets and add them to the palette.
  • More colors in a set, easier to redefine colors and perhaps shortcut to pick shades of a color easily (it’s not that hard as it is).
  • Paper’s document creation/navigation interface