I started my career as an iOS and Mac developer. I was born in that world. From my experience, the community sometimes seems stuck in the pre-internet way of shipping. You work on your product for a year, come to Macworld and give users a nice discount on that year’s update. This is back when shipping something actually meant physically shipping it. You know, using the mail system.

We're not really aware of it, but the iOS and Android community have continued to maintain the physical software shipping schedule. Not because of any particular reason, mostly because we we don't realize there are other ways. Plus: the best examples we have, Apple and Google, still only ship major product updates once each year. It took a foray into web development, and not shipping the first three versions of the Karma iPhone app, before I realized it doesn't have to be that way.

The first three versions of our iOS app unfortunately never saw the light of day. We felt it was missing necessary features and the design was never finished. Not shipping it for so long was unfortunate because we were using the apps internally; the app provided value to us, it would have provided value to our customers. Had we shipped weekly test versions, like we do now, our users would’ve let us known the usefulness of the app even without what we thought were the “necessary” features.

We make mistakes and we learn from them. Ever since the first public release, I'm on a weekly beta release cycle. I am the entire Karma mobile team. Meaning I can only focus on one app at a time. Whichever app I'm working on (Android or iOS), a new test version is shipped every week. On Friday.

A tight schedule forces me to make choices.

“Heresy”, some developers would say. Shipping on Friday is sort of a developer sin. The predominant punishment is having to fix major issues during weekends. In general I agree with this sentiment: I don't think major product updates should be done on Fridays. These weekly releases are different, they're meant for testing. I make an effort to maintain existing functionality, but not everything has to be perfect yet. Worst case scenario: testers can fall back to the version currently live in the app store.

Parkinson's law says: “work expands so as to fill the time available for its completion”. Every Friday is a deadline. By limiting the available time for a project, the scope reduces too. On Monday, I plan what I want to release next Friday. That's my goal for the week, that is what needs to get finished. Overambitious planning usually means I'm in the office longer at the end of the week. Planning too little work isn't a problem either, it gives me time to pick up some of those things that never get done, play around with something new or just begin work on next week's project. It's safe to sidetrack for a little bit because I'll always be back on track come next Monday.

Shipping frequently helps prevent something I call the “ivory tower syndrome.” I'm a perfectionist. I can spend a lot of time perfecting things that are good enough. A tight schedule forces me to make choices. It helps me figure out what parts need extra attention and where corners can be cut. If a particular problem is important enough for me I'll find time to resolve it. Usually by staying late or investing some of my spare time.

If I had an ivory tower —that is, if I wasn't shipping every week — I would spend most of my time in it. I would keep polishing forever. Never to venture out into the world. Never giving users a chance to tell me that I'm solving a particular problem the wrong way, that I'm building something users don't need, or simply, that I'm wrong.

After every weekend I get into the office with a full two days of usage to analyze. Our awesome beta testers will usually have written in with some useful feedback and it's likely there are one or two new crashes in Crashlytics that need attention. Usually Mondays are spent incorporating the feedback. If an issue is important enough I'll ship a quick test update the same day. Most of the time that's not necessary. Normally I have the entire week to prepare for and look forward to leaving my ivory tower and get the much needed feedback required to build a great app.

The App and Google Play Store review times are usually blamed for shipping speeds. That's nonsense.

Now you might ask: “Why not daily? bi-weekly? maybe monthly?”. That's a valid question. The answers depends.

Daily, or anything more frequent than weekly, is not worthwhile. Our weekly updates don't have to go through Apple's or Google's review process. This saves a lot of time, but it still takes time to prepare and ship a build.

Unlike my web colleagues, who can ship multiple times a day, a new native build requires pre-work. Version numbers need to be updated, the build needs to be made, release notes have to be written and the entire thing needs to be uploaded. All this takes time. Also, depending on the platform, user action is required to install the update. Bombarding them with too many updates will quickly become annoying.

Less frequent than weekly diminishes the return. Too many changes in one build diffuses the focus. It becomes much harder for testers to focus on specific changes. Resulting in broader feedback. A longer release cycle also mean there is more available time to finish. It will slow down the pace because, as said before, work fills the available time. Releases are always at least a little bit stressful. Reducing the frequency of builds makes it far too appealing to slack off the week after.

I think weekly is a nice balance between effort to ship, getting feedback early, and keeping a steady, but not overwhelming, pace.

The App and Google Play Store review times are usually blamed for shipping speeds. That's nonsense. Before we had App Stores, even in the internet age, it usually took months to ship something new. Bypassing the Apple App Store is easy, using tools like HockeyApp, and has been done since almost the very start. The Google Play Store even has distributing test builds built-in. There is no need to limit yourself when it comes to getting feedback.

Ironically, at Karma we don’t have a schedule for shipping regulars versions of the app. Our beta testers receive a new build every week, our normal users get it whenever the feature I’m currently working on is done. Depending on the complexity of the feature this can be one week, as with the upcoming Paypal support in iOS. Or several weeks: the usage graphs, for example, took a couple of weeks of iteration to get right.

Even though Apple and Google are still stuck on archaic yearly release cycles, there is no need to limit ourselves to follow in their footsteps. They have the resources to test everything internally and still get the required feedback. Most of us don't. Break the rules, ship often, get early feedback.

About Klaas Pieter Annema

That guy who makes the apps