Jun 3, 2010

Almost on the App Store

I’ve noticed a lot of recent comments bouncing around Twitter about Briefs and some misinformation I hope to clear up. In addition I’d like to share some new things related to Briefs and talk about the future.

Version 1.0

It’s been said that version 1.0 will try to kill you. Funny thing is that 1.0 will not be the first public release of Briefs and it still tried to kill me. The first release was as a developer-only open-source framework at C4 last September. But I decided early in development that version 1.0 would be a general release to the App Store. iPhone app distribution is limited to the App store, it was the only way one could use Briefs if they had not paid $100 to become an iPhone developer.

In short, I could continue to provide open-source software to developers and charge others who wanted to use it. Likewise, for designers and others who wanted to try their hand at creating something on the iPhone, they could pay $15 for an app instead of the $100/year. It was a sweet deal for everyone.

Not an App Framework

But that’s where things started to break down. I’ve presented Briefs in front of several audiences since C4 and without fail, at least one person asks: “Is Briefs an app framework?” I always answer it the same way: “Not at all.” My reasons are simple:

  1. I want it to be simple.
  2. It’s for design prototypes (they are shallow on purpose).
  3. I wanted to make as few assumptions possible about how one designs an app.

In other words, the purpose of Briefs is to better understand the design of your app. I tried to find the most concise way to articulate your design and then get out of the way. I couldn’t do that if Briefs was an app framework.

The Power of Creation

Regardless of my answer and despite the fact that a brief makes for a very limited app experience, (seriously, no data entry, no network connections — just images!) people still insist on labeling it an app framework. Unfortunately, I’m afraid the Apple reviewers believe the same thing and this misconception is causing a stir. Last week, after initially submitting on May 7th, I received a phone call from Apple to update me on the status of my submission.

The gentleman on the phone was courteous and polite, but his message was blunt. While I had not been officially rejected (at least, not yet), he asked me some questions and hoped to manage my expectations. Based on the information available to him, the reviewers believed Briefs contained a non-Apple interpreter and the first team initially rejected it for non-compliance with section 3.3.2 of the iPhone Developer Agreement. I’m still waiting to hear their final decision.

Before I go any further, I want to make myself clear. I do not assume malice is at fault and this is not another developer rant about Apple’s App store policies. I believe this is merely a misunderstanding.

Communication Breakdown

Allow me to explain. First, Briefs has a lot of moving parts and my documentation, until recently, has been lacking. The current workflow is, at its essence:

  1. Write a .bs script on your Mac
  2. Compile that .bs script into a binary plist with a .brieflist extension, on your Mac.
  3. Copy that binary plist onto your phone. (there are several ways)

When the Apple reviewers saw bs chunks of code littered throughout the documentation, it’s not hard to see how they thought I was running a custom script interpreter on the phone.

So, after my 15 minute phone call with Apple, I composed an email to the reviewer on the phone (at his request) and explained the process in similar detail. I also articulated that I was compliant with 3.3.2.

3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).

Above is the 3.3.2 clause of the developer’s agreement that the reviewer kindly provided in an email. The emphasis was added by me, to clarify my point. The final statement is key, because in Briefs 1.0, a brief can be downloaded to the phone and run inside of the app.

Below is a code excerpt from Briefs that is responsible for loading a downloaded brief into memory:

+ (NSDictionary *)dictionaryFromData:(NSData *)data
    CFStringRef errorString;
    CFPropertyListRef propertyListRef = CFPropertyListCreateFromXMLData(kCFAllocatorDefault, 
            (CFDataRef) data, kCFPropertyListImmutable, &errorString);

    if (errorString != NULL) {
        NSLog(@"The following error occurred while converting the incoming data: %@", errorString); 
        return nil;

    else return (NSDictionary *) propertyListRef;

For the non-technical reader, I’m taking binary data I received from a network connection and converting it to an NSDictionary object. (for the technical reader, this is a convenience category I created on NSDictionary) Once in this representation, Briefs can render the brief to the user.

In other words, I use a public API provided and documented by Apple to load the brief into memory from a network connection. When reading a brief from local storage, I use the + dictionaryWithContentsOfFile: method built into NSDictionary. Also public, documented and provided by Apple.

Forest and the Trees

I believe this is a miscommunication and one I hoped will be resolved as a result of my email exchange with the Apple reviewer. Perhaps this post can provide further clarification. Legally, Apple has done nothing but exercise their legal right (granted by my acceptance of the developer agreement) to review my application and hold it against the terms of the agreement. However, I believe they are missing the larger picture.

The purpose of Briefs is to make better designed apps. By using the design on the phone and quickly iterating, you can better pair your app with the device. You’re in a better position to understand the iPhone and its capabilities if you use a Brief first. And if you want proof of its effectiveness, just look at the recently released Bistromath from Black Pixel. The designer told me that Bistromath was the first app he designed entirely in Briefs before starting development. Briefs isn’t about rapidly building apps —in fact the opposite. It’s about taking your time and carefully considering the design before building. That is right in Apple’s wheelhouse.

I want to take Steve Job’s comment that they “make mistakes… but we correct them” at face value. The language of their agreement was written by lawyers, not engineers. And technology is still not well understood by lawyers. My brother is a good attorney, who we use for our MartianCraft legal needs because he understands technology. He’s 26 and not at all representative of the broader legal field. Therefore, it’s expected that Apple will not foresee every impact of the (often broad) language of their developer agreement. What Apple can do (and often does) is amend the terms of their agreement when there are unintended implications of the language. In this case, 3.3.2 is restricting an app that would improve the apps on the platform.

So, the language must be challenged. In fact, challenging the legality of the agreement is precisely how our legal system is intended to work. It’s simply not enough to complain, you have to push back with apps. That was the point of my first post on this blog. In Briefs, I’ve posed an app that challenges section 3.3 of the agreement that is intended to improve the quality of native apps, not degrade it.

Looking Ahead

The value of Briefs is well understood by developers already using it to improve their apps. It has also brought me personal success well beyond what I could’ve imagined. I have big plans for the iPad, Mac and future iPhone releases. However, if Apple ultimately rejects Briefs it will affect that direction.

Assuming the worse, I refuse to fold. The improvements I’ve made will be pushed out to the github repository regardless if it appears on the store. Briefs will continue to live on as a developer tool, but not in the grand manner I envisioned. I believe it has value to non-developers, but there is simply no other way to put it in their hands.

The New Shiny

This post was supposed to be a celebration. I was going to show off the redesigned website, with a new documentation section. I wanted to share my first foray into screencasting and let newcomers see what they’ve been missing. I wanted it to be a victory lap, instead of a concession speech.

Since this is my official 1.0 “release” post, I want to close this by thanking those who’ve helped me get to the finish line:

Jose Vazquez wrote the first real brief (hint: it’s the sketch you see everywhere on the site and in the video) and the first version of the BS parser. He wanted an app like Briefs and he convinced me to write it. He then convinced me to submit a Blitz proposal to C4 after I told him he was insane. Next to the Architect, he has been my biggest supporter.

Chris Clark beat the crap out of the early versions of Briefs and found more bugs that I care to remember. He understood the potential early and pushed me to make it better. He also re-wrote the scene transitions code because he didn’t like the way I named them. I appreciate his immense amount of help and his patience with my love for the ternary operator.

Jonathan “Wolf” Rentzsch gave Briefs an audience, but more importantly he gave me a voice. Without C4 I would not be a Cocoa developer and I’d still be working for BigCo government contractor. I am who I am today because of Jonathan. One word of advice: Never ask him about schedule unless you want to go first!

Alex Vollmer wrote the definitive article on getting started with Briefs back in January. I always have his post loaded in Safari on my iPhone in case I need to explain how it works to someone. He is also the author of a killer cheat sheet for Briefs that has been updated for 1.0 and is included in the newly released starter kit.

Chris Wetterman found a crasher and a gigantic memory leak that artificially limited the number of scenes one could have in a brief. He did this four days before I was set to submit to Apple. His methods are obsessive, a little insane and absolutely brilliant! He made the code base better when I needed it the most.

Craig Hockenberry, John Gruber, Matt Drance, Brandon Walkin and Jason Snell gave me untold amounts of encouragement, words of wisdom and motivation. Thanks for your patience while beta testing an app with less than complete documentation.

Finally, a sincere thanks to every person who has ever used Briefs. You’ve made it a success and keep me motivated every time I open Xcode.

Rob Rhyne is a designer and developer. His company, MartianCraft, builds mobile software for hire. He's creator of Pris, a unique mobile camera and Briefs, a toolkit for creating live wireframes on iPhone OS devices. You can follow him on twitter here.