Get a Fucking Accountant (and an Attorney)

Tax day is around the corner and once again Twitter is littered with advice on deductions and ways to “save” money on your taxes. As the owner of multiple corporations, allow me to offer the only amount of advice that matters: get an accountant. As in, Certified Public Accountant and while you’re at, you should have an attorney, too.

In the beginning

If you’ve already created a corporation, you should already have both. I hear a lot of people often suggest, that you don’t need either and you can just fill out the paperwork yourself. Don’t. It’s a stupid idea and you can tell whatever friend/know-it-all/website that recommended it that I said it was a stupid idea.

There’s a place for saving money in your business, but the legal document that founds your company in the eyes of the government is no such place. Have an attorney do it and rest peacefully knowing you’re never a lawsuit away from losing everything you (and your family) own.

Second, you should consult an accountant for which tax entity you should use for your business. Picking the wrong entity can cost you a lot of money in unnecessary taxes. But accountants are also consultants. The good ones help you plan out the next year and can offer the best ways to finance purchases. You shouldn’t just speak to your accountant on April 15th; they should be your first call/email/twitter/whatever before you make any investment or major capital purchase. Same applies whenever you create a new type of revenue stream for the company. When you’re young and still small, consider your accountant as the first CFO of your company.

Pay your Taxes

As I allude above, your accountant is not just for taxes, but tax preparations are a big part of the yearly interaction. If this is your first business, you’ve probably had your head filled with all of these mysterious, unknown deductions that “can save you THOUSANDS” on your taxes. Be skeptical anytime there appears a mysterious way to cut your taxes in half. The first rule of business is that every dollar is hard-earned.

You’re in the big leagues now. Gone are the days of 1040EZ forms. If you underpay your taxes as a business the IRS will catch up with you. It’s dangerous to think “well, it worked last year…” because the IRS can go back 7 years to find a smoking gun. And when they do, you’ll pay hefty interest. So, instead of thinking of your accountant as a way to game the system, think of them as a protective measure. In the long term, the conservative approach is more prudent.

How do I Pick One?

Getting sued or audited are the two worst nightmares of any business owner, and for good reason. Your best friends during these situations are your accountant and your attorney, so choose someone you can trust. It helps if they have experience or understand the field of business you operate.

One of your usual methods of discovery as a geek, the internet search, often is no good. As a rule, CPAs and attorneys tend to stay away from the web, given the regulations and laws surrounding their official advice. (Did you know that conversations with your CPA are privileged, the same as conversations with your attorney?) So in lieu of a blind search, talk to your friends, go to a local developer meetup or even your parents. Chances are someone near you has first-hand experience with at least one accountant or attorney.

And since he’s my brother, I’d be remiss not to recommend my corporate attorney of choice. Jonathan Rhyne, while neither as handsome or intelligent as I, is a damn good business attorney. In addition to running the legal department of MartianCraft, he’s also a nerd.

CPAs are a little harder to recommend because they have to be licensed in the state you are incorporated, but if you’re looking for a Virginia accountant get in touch with me and I’ll send you his way.

Go Smart or Go Home

It’s no secret that using the services of an accountant and attorney costs money. It’s the cost of doing business well. Put another way: you’re an indie, you don’t have time to worry about this.

If you are not incorporated, if you don’t have an accountant and if you don’t have an attorney to call, your business is in danger.

Year One

A little over a year ago today I had the pleasure of founding a company with two of the brightest in the business. It’s not the kind of opportunity that comes along often and I was remiss to watch it pass by. What I didn’t know at the time was that I was three short months from abandoning my full-time job.

It is interesting now to look back and reconsider my mindset during the founding days of the company. You worry about a lot of things when starting out on your own and, in my case, almost none of them were valid.

I would wager, at the beginning, most are focused on failure. The fact is, we should be worried about success.

The Fall Doesn’t Kill You

I started off like most educated people: I spoke with my accountant. His advice was simple, if somewhat predictable. I needed to save money. Lots of money.

So there I was, chasing my dreams that were comfortably off in the distance. There were many that suggested I was “saving too much” or that I just “needed to make the leap.” But I was determined not to fail.

As you’d expect, this conservative thinking transferred as I started the company. With the fear of failure engrained in my psyche I pursued any and all jobs available. I was concerned with filling a pipeline instead of sculpting my company’s story. Instead of planning for the reality (mobile business is booming) I was trying to solve an imaginary problem.

Failure is Easy

Turns out that failure is easy to manage, when you get down to it. Sure, the stress and uncertainty are terrifying, but without work there isn’t much else to manage. There are few manpower issues without work to do, no accounting kinks to work out of a system with little money and few capital expenses beyond the idle hands you’re paying. A failing company is a ripe situation for innovation and great ideas because you have the most precious commodity available in abundance: time.

There is also little risk involved in strategic shifts, when there is little at the onset. And once you’ve completely failed, the business decisions make themselves. What other choice do you have, but to shut down shop and start looking for stable employment?

In contrast, a successful company has problems of varying colors. Success doesn’t happen steadily over a protracted period — rather, success attacks you like a rogue wave. One day you have one client, the next you have ten! Suddenly you need more time, more manpower and more infrastructure to handle the ten-fold increase in overhead costs associated with each project.

Or consider a company selling software. A featured app in the App store can create the same type of ten-fold increase in customers of your app. 10 times the support email, 10 times the feature requests. How do you account for the added time and material cost to support the incoming deluge of communication?

In hindsight, failure was the least of my concerns.

Plan for Success, Protect Yourself from Failure

In less than a year, MartianCraft transformed from an experimental coalition to a full-fledged consulting service, with an extended staff and Fortune 50 clientele. We didn’t get there without trying; good work is often rewarded with more work. However, to sustain the success and keep our standards of quality high, it required a change of thinking.

I’ve returned my focus back to what drove me to start MartianCraft: building great software for our clients. Failure is no longer defined as financial ruin and a dismantled business, but the failure to deliver the highest quality product to our clients. Instead of planning against worst-case scenarios, I’m pooling resources and talent around a successful future where the company continues in stride. In short, by preparing for success, I prevent failure.

But don’t take this as a vindication for ambitious thinking. A business is wise to plan for it’s next Big Thing™, but it’s important to avoid over-indulgence during the successful years. Remember your accountant’s advice and plan for a rainy day… just don’t forget to take some risk.

Metamorphosis

Just as MartianCraft has transformed, so have I. A year ago I was plotting the grand adventures of an indie. Now I’m plotting the course for the next year and a successful business strategy for the next five years. As MartianCraft’s success continues, my influence and role for the company approaches a disgusting three-letter acronym for any indie: CEO.

Cry not for me. Being the CEO is a role that any indie carries regarding their business, it’s just not often celebrated. It’s necessity, however, is no less relevant for an indie business than it is for a multi-million dollar company. The fact is, one of the three founders of MartianCraft needed to step into the role. Someone needed to direct our efforts so we could ride the wave of success instead of being crushed under its weight.

Unlike a traditional CEO, the role I’m describing rises out of need, not out of title. What sets apart an indie CEO from other’s is the fluidity of their actions. I am to MartianCraft whatever is needed at the time. If a project needs hand-holding, I become a project manager. If a contract needs negotiating I become a business developer. And if a toilet becomes clogged, I’m there with a plunger.

On any given day, I will negotiate a contract price, work with a developer to determine a release schedule, mentor another developer on the basics of memory management then fire up Xcode to clean up a project that needs to go out the door.

In other words, I’m still an indie, just one whose focus is on developing a company not just developing code.

I guess that makes me an indie CEO.

Always a Bridesmaid

Last Thursday, after working with Apple’s review team for nearly a year, they rejected Briefs again.

I feel like we’ve all been here before. Another App Store rejection and another post on my (barely can be called a) blog. Since this is likely my final tome on the subject, I’m opting for a simpler approach. Instead of a rambling post about my continued woes of app review and more logical pleas for guidance from Apple, I’m posting a FAQ. A place to direct people as more of them discover Briefs and wonder what could have been.

But please don’t read my cool, logical demeanor as sanguine. I’m madder than hell over the situation, but it doesn’t matter. It doesn’t matter that I rewrote the app, removing all networking code, replacing it with the worthless iTunes file sharing. Nor does it matter that I was doing this based on direct guidance from Apple’s review team. It doesn’t change the fact that I have a concept I can’t sell and an app half its audience can’t install.

When will Briefs be available on the App Store?
It won’t.

Bummer, how can I install and run Briefs on my device?
The same way that has always been available: download the source code, then build, sign and install the app for your device.

What was the reason Apple cited for rejecting it?
According to Apple, Briefs “downloads executable code that dynamically alters the behavior of the app.”

Downloads? I thought you said you were using iTunes file sharing.
Any means of opening a .brieflist in Briefs, including: (1) a direct network download, (2) sending it to Briefs from another app or (3) using the user initiated process of copying the .brieflist through iTunes file sharing. All are considered “downloading” according to Apple.

I thought iTunes file sharing would be the silver bullet. If someone gets a virus from using iTunes file sharing, they really have to try. Think about it, you already use iTunes to copy movies, music and applications to your device. I’m not sure how a plist file adds an unnecessary security risk beyond the current functions of iTunes.

I’ve been happily using Briefs for months. Why does it matter if it’s not on the App store?
First, thanks for using Briefs. Second, I wanted Briefs to be an easy way to test out your ideas and the audience for such a tool is larger than developers. Without a version on the App store, I can’t reach the rest of the audience.

Installing an app from source is not an easy task. Especially for those who are unfamiliar with the joys of device provisioning. Three quarters of the support email I receive is regarding installation issues.

Why not sell the app through Cydia or other similar app stores for jailbroken phones?
I fail to see how jailbreaking your device makes for a better installation process. Nor do I see how I gain more of the desired audience through Cydia.

I’ve never met a single person who jailbroke their device that wasn’t a developer. Developers can already use my tool, as is.

What about a Briefs Mac app?
I’ve started writing code and I have a lot of ideas surrounding a Mac app for Briefs, but I’m reticent to spend more time on the project at the moment. This latest rejection has spooked me and I’m looking for better uses of my time.

Is this the end of Briefs?
The beauty of open-source software is that it never goes away. I get emails every week from people happily using it and I imagine many will continue to find value from it. I’m always open to pull requests and patches are welcome.

I’m not saying I’ll never work on Briefs again, but it’s difficult to open the Xcode project right now. One day that feeling will pass and I’m sure I’ll start poking at it again. When I do, I’ll talk about it on Twitter.

Will we ever hear the whole story?
I’m not in this game to whine about my troubles and get a bunch of folks riled up about walled-gardens or curated something-or-others.

But if you ever run into me, feel free to buy me a beer, ask me for an interview or invite me to speak at your conference. I like to talk and you’ll get to hear about the hidden elevator in Moscone.

In the meantime, I have a business to run and new ideas to build. If reading this makes you angry and you feel compelled to do something about it, go build something great that will make people happy. That’s what I did with Briefs and I don’t regret it; app reviews be damned.

Support your Local Indie

The following is an open letter to Patrick Burleson regarding QueueUp, a wonderful app he recently released. This originally started as an email. Instead, I thought I would share with the class.

If you’ve been married for longer than an hour, you’ll probably recognize this scenario.

The Architect is watching the telly. Passing by, I casually enquire as to what she’s watching. Normally this creates an intellectual, but brief, discussion about something that typically involves: (a) fixing-up the house, (b) witty crime dramas or (c) dresses. However, today is not typical.

Today we’re crammed into a beach cottage with her in-laws. My father is browsing Facebook out loud, while my mother is discussing something with the boy at a volume several of our neighbors could complain about. Add to the mix a television with poor built-in speakers and suddenly my attempt at being an interested husband becomes an intrusion.

“I can’t tell you the name, because I can barely hear what is going on. I think that Adrian guy from Entourage made a documentary about the paparazzi. I really wish I could hear what’s going on…”

At this point, my options were clear:

1. I see if one can survive a dive from the 3rd floor balcony into the swimming pool below.
2. I threaten to put my parents in a retirement home if they don’t quiet down.
3. I save the day.

While #1 could be fun—if I survive—#2 would be a disaster since neither of my parents are near retirement age and we were staying at their cottage. So…

I Save the Day

For a brief moment, I forgot that we lived in the future. A quick pull from my pocket and I found a PBS opinion piece discussing several female celebrity’s perspective of Adrian Grenier’s documentary. I softly stroke my iPhone as I fire off a quick email to my bride. Case closed.

But before I took my victory lap, I remembered QueueUp—an app that I beta tested—which was recently released. A quick tap on the red & white icon revealed an expired provisioning profile. No worries, after a quick purchase¹ I was back in business. Once the app was running, it was mere micro-seconds before the movie was the newest addition to my Netflix queue.

“Dear, the name of the movie is ‘Teenage Paparazzo’ and it’ll be at the house on Monday.”

Smiling, she switched the channel. Checkmate.

¹ Patrick was kind of enough to offer a promo-code for beta-testing, but I never considered it. Support folks who make software you love. ↩

Selling Open Source

The past few days have proven interesting and encouraging. I’ve received many thoughtful comments and hopeful messages from users. However, there is some misinformation surrounding the timing and my motivations for making Briefs open-source. This post is the first of two I hope will clear up some confusion. First, I want to tackle the how and why I released the source for Briefs.

It was Always Open Source

Let’s get this out of the way: Briefs was always open-source. From the first release in September 2009, I announced that the current and future releases would all be open. I selected a modified MIT license for the first iteration because I wanted anyone to use the code how they saw fit. No strings attached and this solved the distribution problem perfectly. It was a framework for developers and any one could install it on their device.

Even before September, many designers were approaching me with a dilemma: how could they use the app if they were unable to build it from source? In that question, a version of Briefs for the App store was born. So, Briefs was open first; a for-pay build second.

With the App store version, designers could purchase a pre-built version that was dead simple to install on their device. (it was also an easy way for developers to give money to a project they found useful) The version I submitted to Apple in May was built as a way to get the app in a designer’s hands.

The Revised License

Many have already noticed that the original license for the Briefs.app source has been modified in the 1.0 release. In particular, I added lines protecting the Briefs trademark and the following clause:

“The Software and/or source code cannot be copied in whole and sold without meaningful modification for a profit.”

The complete license can be read here.

I had planned to detail the various sources that served as inspiration but, as luck would have it, a slashdot commenter has already done that for me. The commenter posits that the license is not “Open Source”, “Free Software” or “DFSG-free.” The basis of their accusation is that I don’t use an existing open-source license. They offer the addition of the above clause as proof that I hate freedom, apple pie and the American Way™.

Why do I Hate Your Freedom?

The irony of the slashdot comments is rich. Not only do I offer two separate embeddable libraries—one for reading briefs, another for running them—I do so under a license without the above modification clause. The truth is, I want people to use the .brieflist format. I envisioned it not only as a prototyping format but also as a UI specification document. Imagine if you could hand a developer a brief instead of a Photoshop mockup?

If you explore the briefs.app project, you’ll notice the revised license only covers the UI (e.g., view controllers, local storage, etc.) of the app. None of the core pieces of the Briefs framework are covered under the more restrictive license (since they’re part of sub-projects in other repositories).

I tried to use a scalpel when applying the clause.

Why the Clause Matters

You might ask, what essential liberty am I excluding by adding the modification clause? Ironically, nothing. My motivation for adding the clause was to prevent a scenario where someone would upload a carbon copy of my application to the App store, under their name, with their price. If I charged $15, someone could ask $8 and undercut me with little effort on their part. If I allowed that to happen, it would destroy my ability to sell the app. Then I’d have to make the choice to either sell or open-source the app. I wanted to do both.

However, this entire train of thought is moot if I can’t sell the app in the first place. Currently I’m only withholding your right to submit this app to Apple and wait three months not to be accepted or rejected. I’m such a greedy bastard. Shame on me.

The New Open Source Business Model

The license, despite opinions, is actually a professionally engineered piece of legalese that allows you to open-source your app and still sell it. A lot has been said about Apple’s walled garden but since they control distribution, a majority of the market can’t install an app from source. That sucks if you’re a user, but fortunate if you’re a developer that wants to open-source your application.

Most assume you can’t sell open-source software because no one would pay money for something they can install for free. Free software is practically synonymous with liberty and no cost. When the App store, the equation changed. Interested parties now have the liberty to examine or modify (and re-install if you pay Apple) an application while developers charge a fair price for their applications. Freedom for users, beer money for developers.

Needless to say, I’m excited about the prospect of the new model. Imagine how powerful this would be for budding developers? What if you could look under the covers of your favorite apps? What could you learn?

Even users would see a direct benefit. Jeff LaMarche talks about coding as if everyone is watching and with an open-source business model everyone could be watching. Vanity alone would dictate better engineering!

Introducing the Rhyne Open Source Software (ROSS) License

When I asked Jonathan Rhyne to author a new open-source license I provided a simple wish list:

1. Royalty free use in commercial and non-commercial projects
2. Attribution should be required
3. Prevent people from submitting an unmodified copy to Apple for sale
4. Simple language

The result is a modified MIT license with BSD-style attribution that is compatible with the Apple’s distribution model. It gives the discerning developer peace of mind knowing that your brand and trademark are protected, while freeing them to share the coolest bits of their implementation.

This license is my gift to you. Take it and use it.

You Still Need an Attorney

There is some fine print. Obviously this license, as with most open-source licenses, has not been tested in a courtroom. I cannot guarantee it’ll hold up in court and we live in a world where some stooge will try to find a way around it. When that happens, you’ll want an attorney.

Jonathan did a spectacular job bringing classic open source licenses into the modern age. He’s a closet Apple lover and he knows the answer to the ultimate question¹. If you’re an app developer, you want him on your side. Who else has an attorney that does consultations over FaceTime²?

He’s even on the Twitter.

¹ Which ship would win, an Imperial Star Destroyer or the Starship Enterprise? ↩
² Of course, he isn’t as handsome as his older brother. ↩

Update on Briefs

It has been three months since I last threw myself upon the court of public opinion. I have waited three months for a resolution—any resolution—on the matter of Briefs’ admission into the App store and have grown weary waiting for a response. Many have asked where things stand, so I decided to grab the megaphone once again.

Executive Order

Before showering the interested few with details, I’ll summarize where things stand as of today. First, the app is not available on the App store and I have no reason to believe it will be anytime soon. That is not, however, for lack of effort by a great many inside of Apple.

At WWDC I was connected with two developer evangelists and eventually the director of the App store to discuss Briefs’ prospects. All three were very encouraging and helpful. This was in addition to several Apple engineers detailing their use of Briefs for company efforts. I left the conference with hope that differences could be resolved and Briefs would be up for sale.

That was until a few weeks later, when I was told (by the director himself) that the review had reached the “executive level.” Considering he reports directly to an Executive Vice President within Apple, I have every reason to believe him. Unfortunately two and half months have transpired since reaching the executive review. (and what a two and a half months it has been for Apple executives!) I have not completely given up hope, but it is time to move on.

Moving On

Many have asked about development status, including a version for the iPad and a visual builder for .brieflist files. I’m a new indie of four months and trying to feed a family. I have already poured hundreds of hours preparing Briefs for a public release while simultaneously bootstrapping my consulting business with Jeff and Dave. With the status unknown and Apple openly opposing the strategy behind Briefs, it has become hard to stay motivated.

So instead of trucking along, and growing more resentful of the project, I’ve decided to take a break. And to cool the sting, I’m releasing the 1.0 code base to github today.

1.0 Source Available Today

The completely redesigned user interface. The underwear-laden app icon designed by IconFactory. The brief:// and briefcast:// url schemes. It’s all there, including a few bits of code I actually take pride in releasing to the public.

→ Go get it

Also, if you were having problems getting scrolling actors to work, all of the fixes are in the new code base. Everything should just work. As always, email me with any questions or problems you’re having.

The Road Ahead

I am not finished with Briefs and I would like to find a way to devote more time to it. I’m considering a lot of ideas—including a Kickstarter project to fund iPad development. I still have some good ideas for the platform and I hope to get back to them in good time. However, it’s time to focus on other work and projects that can get into the App store.

In the meantime, feel free to email me with questions, comments or even links like this. It never gets old hearing how others are using Briefs. It still amazes me that I’ll never know everyone who’s ever used it and doubtful that I can thank you all in person.

Thanks. If it wasn’t for folks like you, I would have given up long ago.

In Loving Memory

She’d tell me I was acting old, then giggle at the length of my sideburns.
She’d rail on Sarah Palin, then build a mosque in her front yard.
She’d eat more hot dogs than any grown woman should.
If only, she were here.

She was care-free and irreverent.
She was unforgettable.
Bookish and charming.
Beautiful.

On June 16th, 1999 she was a month into her twenties,
When small piece of candy, coated in peanut oil, claimed her life.
I remember driving to the hospital.
I remember the doctor shaking their head.

Everything stops when they unplug your friend.
I squeezed her mother and sister’s hand.
I couldn’t bear to look at her father.
I wept openly.

On August 16th, 2010 I pledged $100 in her memory.
For her family.
For families with allergic children.
For my six year old niece.

—

A parent should never bury their child. Help support Amy Jane Gruber and others like her. http://www.foodallergywalk.org/goto/amyjanegruber

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.

The Breaking of the Fellowship

In 2007 my wife and I celebrated our third anniversary by spending a week in Chicago, Il. We chose Chicago for several reasons — one of them was C4, a small indie Mac developer conference. I recently had completed some freelance Mac development and had dreams of building Mac products for a living. I was intimidated. The emphasis on design drew me in and I used many indie Mac programs in my daily work. MarsEdit, NetNewsWire, VoodooPad, Transmit, etc. The developers had achieved a larger-than-life status in my universe and for one weekend, they would be in the same room in a smaller setting. It was too good to resist.

So, in Spring of 2007 I summoned up the courage and registered (back when C4 didn’t sell out in hours). I wanted to see this world up close and find out if I had what it took. Needless to say the following August was a revelation. Not in the humbling way I thought it would feel. Instead what I discovered is the developers were just like me. Simple people, with computer science backgrounds and a passion for great software. Meeting them, and seeing them in the wild proved to me that I could be one of them. That was C4’s gift to me.

Yesterday, Jonathan Rentzsch announced he’s shuttering the doors on C4. The conference that forged me into an indie (both figuratively and literally — Briefs was released at the last C4, catapulting me on that trajectory) was no more. That it is gone is painful enough. However, Jonathan’s reasons for closing down C4 is what stings the most.

The Respect

First let me state, unequivocally, how much I respect Jonathan and his choice to stick by his principles. I cannot imagine the agony over making this decision. Second, I’ve had the pleasure of discussing 3.3.1 with him in person and his argument is neither shallow or misdirected. I challenge anyone to engage him in a discussion on the topic and not second guess their own opinion afterwards. Especially those who think he’s overreacted. It would be too easy to dismiss him as a curmudgeon and disregard his message.

His gripes are valid and they’re not with Apple, but with the community of developers surrounding Apple. The same community he has served and helped grow. If you dismiss his point, you only make a stronger case for it.

The Dilemma

What Jonathan would like to see is simple: that developers ask more of Apple. Don’t let them get away with this “war on Computer Science,” as he refers to it. The App store is too restrictive and Apple is working to restrict it more. They want to dictate the manner in which you write for their platform. Section 3.3.1 of the SDK agreement gives them that latitude. It’s not about what gets in and what doesn’t get into the store. What matters is that Apple calls the shots and can do so in a opaque manner with singular discretion.

Despite these facts (and demonstrated behavior), there are developers queuing in the streets for an opportunity to write for the platform. This developer included. It’s a great platform with tons of potential. Potential we have yet to see realized.

But it is impossible to criticize the platform when Apple is the gatekeeper. And a petty gatekeeper, with no sense of humor. Just ask Ellen Degeneres. How should a developer who has invested months, possibly years of time in the platform effectively criticize Apple for its policies? How can they do it without fearing removal from the store?

Here in lies the rub. iPhone developers are weary about criticizing a capricious distribution channel with absolute control. This has led to an uneasy silence regarding 3.3.1 that finally wore Rentzsch down.

The Dreamers

I now look out at the community I love and see a divided house. There are those in the community that look down on me as merely an iPhone developer. They lump me in with the one-hit wonders and wannabe stars who only seek App store glory. I offend those who object to Apple’s policies because I implicitly defend those policies when I don’t lay down my UIKit in protest.

However, I choose to see things a little differently. There are two apples within Apple, Inc. The first is building a series of barriers and partitions that will eventually undo the company if it fails to cede control. The second is building the computer science of tomorrow.

I dream of a day when the second group will drive the first group out of Apple. But I recognize the second group is just as likely to jump ship when the first group finally destroys the company. And when the mass exodus of the second group occurs, this developer will follow them wherever they go.

Until either scenario comes to pass, I find it in my best interest to work the problem from within. In fact, Briefs should be considered my first missile launched at the bunker called 3.3.1. When I publicly protest it will not be an abstract argument, but one based on a concrete example.

I don’t have the luxury of ignoring the platform until Apple gets their act together. Instead I have to shape the barriers the best way I can: by challenging them with apps. Find out what rules can be bent and what can be broken.

The Message

If I could say one thing to Jonathan it would be this: Don’t take my silence as a willful act of contrition, but as a steeled act of resolve. In fact, I think there is no better time for developers to have a little C4 in them than the present. Jonathan, thanks for the memories; Your work will be missed, but your legacy will endure.