Whether it’s a software application or a spatula, a well designed product is the end result in a long process. We can sometimes forget this. Looking at the finished product, it can be easy to imagine a designer bringing it to life whole and immaculate in its final form. In reality, what’s more likely is that the thing you’re looking at is the last step in a long, tiring, arduous process. A process full of false starts, failed attempts, trial and error, and “creative borrowing” from other designers. This is why I love reading behind-the-scenes accounts of the design process. I find it fascinating to learn how different designers tackle it.

Here is a little peek into my own process for designing and developing Flickit and Flickit Pro, and a look at some of the design and engineering challenges I encountered.

Design philosophy

For a while now, I’ve been trying to think of a way to summarize my approach to software user interface design. I’ve recently started thinking about modeling my UI design philosophy around the concept I’m calling the “English Butler” approach to UI design. Amongst other things, a good UI should:

• Dress sharp
• Be polite
• Appear instantly when needed
• Prepare things in anticipation of your actions

I admit I’ve never employed an English Butler, but that’s my impression of what a good house servant would be, based on what I see in the movies. Software should be the digital equivalent of the same.

How often have you used a piece of software that was ugly, rude, interrupted you at inappropriate times, was sluggish to respond to your commands, or made you perform administrative UI busywork that it could have done for you? I suspect we all have at some point. I strive to build software that is exactly the opposite of all those things.

From sketch to pixels

Most of my UI designs usually start with a sketch. At first, they are fairly rough, just to get a feel for the major components. I may do a few different screens from the same workflow at first, to get a sense of how the high-level pieces of the UI will work together. Typically all these sketches are just wireframes blocking out the major components. At this stage, a lot of crazy ideas will appear, but a lot will get thrown out as well. The goal is just to play around and experiment and generate possibilities.

After a rough wireframe is laid down, sometimes I like to dive into a little more detail in the sketch to see if the ideas in my head make any sense at all. I’ll add some refinement to placements of buttons and custom UI widgets and try to at least tease out a vision for a final UI layout.

Sketches are good for experimenting, but can only go so far. After I’ve spent a bit of time with pencil and paper, I move pretty quickly over to Photoshop to start arranging elements with correct sizes and placement.

Flickit

For the standalone Flickit uploader, I knew from the beginning that I wanted to do something unique with the UI. Anybody could create an interface to let you pick a photo from your library and then present them in a simple table or grid - I wanted to take it a step further. After a few sketches, I had the idea to make the selected photo appear as it was coming out of the camera like a filmstrip. I liked the notion that it gave the app a sort of “physical device” feel to it.

After the photo selection UI was worked out, next I tackled the problem of how to let the user enter the photo metadata and upload settings. One thing I wanted to avoid was having a completely separate screen for entering these details. I felt that bouncing back and forth between the photo list and a separate details screen could quickly become tiring if you were trying to enter details for more than a few photos at a time. I struggled for a while to come up with a way to keep the user on the same screen. Eventually I landed on the idea to “shrink” the filmstrip UI and slide in the details form at the bottom:

I liked that you could see the list of photos at the top of the screen, while keeping the data entry part of the UI in the same screen. Tapping a photo on the top could just replace the contents of the details below without needing to go back and forth between two screens.

Surprisingly, this was one of the more challenging bits of UI to implement. The iPhone’s UIViewController framework is really only designed to handle view controllers that occupy the entire screen. Having a separate view controller slide in that only occupies a portion of the screen was tricky to get right. Also, getting all the animations right when the UI switches to the detail-entry mode and back again was a major pain. It probably took me a few days to iron out all the quirks of animating all the views with the correct transforms in the correct sequence in order to make everything look seamless.

Flickit Pro

As I mentioned in a previous post, the original Flickit app was my “test run” at iPhone development. I had a lot of fun building that app, so I set my sights higher for the next version. Flickit Pro was going to be a full-featured Flickr client for iPhone.

One of my goals from the very beginning with the Pro version was that I wanted to give the app some justification for being a native app. After all, the mobile-optimized Flickr website was pretty good. I needed to give customers a reason to use (and spend money on) a native app.

Continuous scrolling

My first target for improvement was the scrolling list of thumbnails. One thing I found less-than-ideal was the pagination of photostreams in the mobile web version. You had to keep tapping “next page” constantly. I felt that I could improve on this a bit with a native app. It was a perfect example of what I mentioned above about software being able to anticipate what the user is about to do. The app could detect when we’re getting to the end of the page and start the request for the next page automatically, saving the user from having to manually perform that action.

I set out to make thumbnail lists continuously scrolling. The app would handle all the paging requests in the background as the user was scrolling. This was a simple concept, but getting it to work smoothly turned out to be a major engineering challenge. I spent weeks on this. I probably re-wrote this part of the app 4 times before I got it to where it is now, and I feel like it could still use some improvement. There’s a ton of stuff happening on the device while the user is scrolling: network requests are being fired off, data is being downloaded from multiple sources, caches on disk are being written to and updated, and JPEG images are being decompressed. All at the same time, on the fly.

Photoflow

The continuous scrolling feature was cool, but I felt like the app still needed another “hook” feature. Something that would entice people to give it a try. Arguably one of the most attention-grabbing features of Flickit Pro is what I ended up calling “Photoflow”. The Coverflow/Time Machine-esque photo browser view:

My initial designs had some fancy effects where the photos were supposed to look like they were “falling” off a ledge as you scrolled. The photos rotated a bit as they approached the viewer. In fact, this is how I implemented it at first. It turned out this was a big performance hit. I took out the tilt effect and none of my beta testers seemed to notice or care. It still looked pretty good, and scrolling performance was way better, so I left it out.

As far as the engineering effort required to build it, a lot of the work was already done after I built the thumbnail scrolling engine. All I really had to do was change which image size to load - most of the caching and request processing foundation was completely re-usable.

The hard part for Photoflow was getting the UI and interactions to feel “right”. If you’ve played around with the coverflow feature in the iPod app, you can see that a lot of effort was put into making it feel like you were really throwing around physical objects. It took me a lot of trial-and-error to give the UI in Photoflow that same behavior. (And it’s still not perfect)

At first, I tried implementing the animations with the Core Animation framework in iPhone OS. For the most part, it was working OK, but there were little glitches here and there that I had a hard time suppressing in order to make the interactions feel polished. Core Animation is very powerful, but you trade some flexibility for that power. Core Animation wants to handle a lot of stuff automatically, and if you try to subvert some of these behaviors, you run into trouble. In the end, I decided to scrap Core Animation and implement the code to animate the effects frame-by-frame myself. In retrospect, this was probably what I should have done to begin with, since it wasn’t really that hard. This gave me full control over how the images behaved and all the edge-case problems I had with Core Animation were eliminated.

Keeping Tabs

A big challenge for writing an iPhone app for a site like Flickr is figuring out how to take all the different navigation options available on the full website and boiling them down into a format that makes sense on a tiny iPhone screen. Your main home page on Flickr has 6 menus on it, and each menu has between 5-17 items in it. Lots of navigation possibilities. How do you present all these options in a way that makes sense on the iPhone?

One thing I didn’t want to do was to create a tab bar with 17 items in it. In fact, in general I think creating a tab bar with more than 5 items in it is a bad idea. Yes, the iPhone will automatically place a “More” tab in there for you, but this is a bad user experience.

Any time you have hidden UI elements in an interface, that increases the cognitive load for your users. They have to create a mental image of all the tabs behind that “More” link every time they use your app. This usually ends up causing a lot of hunting and pecking around in your UI and generally leaves the user feeling lost. Better to have 5 solid tabs. This way, there is never any confusion about where to go. Launch the app, see 5 tabs, that’s it. This will keep your users feeling grounded.

Infinite linking

Another problem with a site like Flickr is that everything is linked together. For example, from a member’s profile, you can go to their photos, then navigate to sets/tags/groups, then more photos. Or, navigate to a photo in their favorites, then pivot to the owner of the photo, see their favorites, etc, ad infinitum.

On the web, this is great because you can jump from link to link and have great time exploring. Everyone is used to using the back button or history list in their browser to navigate backwards.

In a native iPhone app, this causes a bit of a problem. One way that some apps achieve this type of link-hopping navigation is to keep pushing new views onto the view stack. If you allow this kind of navigation, then pretty soon you’ll find yourself 10 levels deep in a navigation stack with no easy way to get back to the root of where you started your navigation. The iPhone’s navigation stack doesn’t really provide an easy way to see the breadcrumb trail of your navigation - you’re stuck hitting the back button 10 times to get back to the root. To get around this, some apps introduce a “tap and hold” gesture on the back button to automatically go back to the root. This kind of thing feels like a hack to me. It’s unintuitive, and most users won’t discover it.

I made a conscious decision to prevent this kind of infinite deep-linking in Flickit Pro. You’ll notice that no matter how you tap around in the app, you’ll eventually always end up in a dead-end. (Usually a photo screen)

I designed the navigation this way purposefully, to try and prevent users from getting lost. This decision has some drawbacks. Namely, it prevents the kind of exploring that you sometimes want to do. For example, following a photo in the “Interestingness” list to that member’s photostream is currently not possible in the app. I have some ideas for how to get around this problem, but I decided to hold off on implementing them until I was sure it was the right approach.

It’s always easier to add new features than to remove or change existing functionality.

Deleted scenes

No “behind the scenes” post should be complete without a look at some of the designs that didn’t make the cut. Sometimes, seeing what was removed can teach you more about the process than what was left in.

Most of the time, I throw out ideas early in the process, in the sketching phase. But sometimes, I like to take an idea a bit further. I toyed around with this concept for a different take on the standard “list view of contacts” for the People tab in Flickit Pro:

The idea was that your contacts would be presented in the scroll-wheel at the top. By rotating a contact into place in the center, the bottom area would update to show that contact’s most recent photos. An indicator under the contact’s avatar image would show which contacts had new uploads since the last time you checked. I thought that this might be an interesting way to present two levels of information in a small space: contacts + recent uploads.

In the end, I decided to scrap the idea due to the development effort required to implement the scroll wheel. It was getting late into the development process, and I didn’t want to hold up shipping the app any further. Perhaps this idea will find it’s way back into the product in a future version.

You can still see some vestiges of this design in the final product. Namely, the “new uploads” indicator was something I thought could still add some value, with minimal implementation effort.

I could go on, but this post has gotten a lot longer than I thought it would. If you’d like to hear more about specific design decisions or engineering challenges, leave a comment with a suggestion and I’ll do a follow-up post.

You can also check out more pics of Flickit’s design journal on my Flickr photoset.

I was hoping I’d never have to write this blog post.

The 2.0 update to my iPhone app, Flickit was rejected by Apple. In order to get the update approved, I had to remove some functionality, and a month later, version 2.0 has finally made it into the App Store. If you’re wondering why some of the features you’re been accustomed to are now missing, here’s why.

This is also a cautionary tale for other iPhone developers. I was certainly caught by surprise by some of the reasons for this rejection, so hopefully I can save other devs some unexpected headaches.

First, let’s take a look at what Apple’s reviewers had a problem with. The iPhone SDK has a nice, easy to use, pre-packaged user interface for picking photos from your library - UIImagePickerController. You’re probably familiar with it. It looks like this:

All 3rd party apps have to use this standard UI in order to get access to the photo library.

One of the problems with the buit-in UI is that it forces you to pick one image at a time - there’s no facility for multiple selection. What this means for my app is that if a user wanted to upload several photos at once, they’d need to open the UIImagePickerController’s screen for every photo. This can become tedious fairly quickly if you wanted to select a more than say 2 or 3 photos. In Flickit’s initial release, this is how it worked, and it was something people complained about right away. I started thinking about ways to work around this limitation and allow users to select several photos at once without having to re-launch the UIImagePickerController. The solution I came up with looks like this:

As you can see, I added a couple of things to the UI. I added a toolbar at the bottom that shows the number of photos you’ve already picked and a ‘Done’ button that lets you complete the selection and dismiss the picker UI. I also added a little progress indicator overlay on top of the photo grid. The overlay displays an activity indicator while it’s processing the selected image, then briefly shows the checkmark you see in the screenshot. After that, it goes away.

The rejection notice specifically called out these modifications. Here’s the email I got:

Thank you for submitting Flickit (Flickr uploader) to the App Store. Unfortunately it cannot be added to the App Store because it is modifying or extending an undocumented API, which as outlined in the iPhone Developer Program License Agreement section 3.3.1 is prohibited:

“3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.”

There is no documentation for creating custom subclasses of UIImagePickerController, the organization or layout of the view hierarchy managed by UIImagePickerController, and any of the custom classes managed by UIImagePickerController in iPhone OS 3.0.1.

Specifically, the the organization and layout of the image picker view hierarchy is undocumented. Please refer to the attached images.

Now, there are several interesting things about this rejection when you consider the app’s history, competitors, and details of Apple’s policies. Let’s take a look:

7 strikes and you’re out

The first interesting thing is the fact that this wasn’t a new feature in this release. It had been there for a while, and passed approval through several updates. In fact, this same UI had been in the app through 6 updates that were all previously approved. Lesson learned #1:

Past approvals don’t guarantee future approvals for the same feature

It strikes me as a bit odd that it would be approved so many times before and then suddenly catch their attention. Were the App Store approvers just missing it the first 6 times? Was this a new policy going into effect recently?

One possibility that occurred to me is that Apple might be taking a risk-based approach when scrutinizing apps for approval. With hundreds of app submissions a day, and only a small team of approvers, it’s no surprise that the approval system has quickly become overwhelmed. Perhaps Apple has made the decision to review some apps more closely than others? How would you decide which apps to let through with a quick glance and which to take a closer look? Impact on number of end-users seems like a good metric. Perhaps the review process takes into account the number of people that have installed the app, and then more closely examines apps that will have an impact on a large number of users. Flickit is no chartbuster, but by this point it had already been out for close to a year and has a somewhat sizable install base. That could explain why the app only got rejected now. Of course this is only speculation, but it seems plausible given the next lesson:

Consistenly inconsistent

The reviewer’s primary concern was the overlay message on top of the photo grid. Apple doesn’t want you messing around with the built-in views of the UIImagePickerController. Out of curiosity, I took a look at the official Yahoo Flickr app. This is what they do when you select an image:

A smaller overlay than mine, but effectively the same approach: Briefly show a progress indicator while processing the selected image.

This next bit really threw me for a loop. On the same day, I submitted two apps. One was Flickit 2.0, and the other was Flickit Pro. Flickit is a strict subset of Flickit Pro. In fact, Flickit’s entire UI is copied into Pro’s feature set as a separate tab. Both apps have the exact same modifications to UIImagePickerController that I mentioned above. Flickit Pro was approved, Flickit was rejected. I specifically asked Apple about this, but didn’t get an answer. Lesson #2:

Approvals of identical features in other apps is not a barometer for approval success of *your* app

It’s bad enough when there is inconsistency in applying the rejection criteria across different apps, but when the exact same functionality is approved in some cases and not others, it’s really baffling and frustrating.

Intentional consequences

This whole thing would be a lot easier to accept if I was deliberately trying to get away with a hack that I knew was violating the approval guidelines. Even if I unknowingly violated a policy that I at least understood, that would be OK with me too. I’d fix it and move on.

The irony here is that I was well aware of this policy, and took a lot of time and effort to ensure that I didn’t violate the policy of using undocumented APIs. In general, I think Apple’s crack-down on developers’ use of hidden APIs or modification of built-in UI is actually a good thing. If developers start building apps that do these things, then it makes it very difficult for Apple to make improvements to the implementations of these system components without breaking a lot of apps. It makes the whole ecosystem less stable, and isn’t good for Apple, developers or app users. A perfect example was when Apple introduced video capture features in iPhone 3GS. The UI for UIImagePickerController added a bunch of controls for handling video capture. If your app made assumptions about the layout of the controls on the camera, then it probably broke when Apple released the update for video capture on the 3GS.

I knew I didn’t want to make assumptions about the implementation of UIImagePickerController so I didn’t implement anything that did. I knew my app would break if UIImagePickerController changed in future iPhone OS updates.

After my first rejection notice, I started trading emails with a very patient and friendly engineer from Apple’s Developer Technical Support team to try and explain my implementation and make an argument for why I didn’t think I was violating their policy. A few dozen emails later, I was still not able to convince him that my app wasn’t making any assumptions about undocumented APIs.

It’s hard to communicate this stuff over email. Subtle technical details sometimes don’t translate clearly into paragraphs of prose. I have no doubt that if we were in front of a whiteboard I could draw a few pictures that would make my arguments a lot clearer. Lesson #3:

Don’t rely on cute workarounds, even if you think they’re “legal”

Another thing fueling the confusion is what seems to be a hyper-sensitivity on Apple’s part for anything that touches the camera or photo library UI. Maybe too many users got hit with broken apps after upgrading to iPhone OS 3.0 with the video camera updates?

Endgame

The message from Apple was loud and clear: Don’t mess with UIImagePickerController.

I decided it wasn’t worth the effort to continue my arguments for why I thought my app was built within the boundaries and the spirit of their guidelines. I had other new features and bug fixes that I wanted to get released in the update, and continuing the emails back and forth would only prolong the release even further, without a clear outcome.

I removed my “enhancements” to the UIImagePickerController, re-submitted the app and it was approved a week later.

I’m now preparing myself for the inevitable backlash of users who will miss this feature and complain about it being removed. (If you’re one of those people, I’m sorry!) Adding new features is easy. Taking them away always ends up making somebody angry.

Another thing I’m not looking forward to is trying to explain to customers why other apps have this feature, but mine does not. Most customers don’t care about “Undocumented APIs” or the intricacies of Apple’s app approval process. If someone sees a particular feature in another app it’s only natural to think another developer should be able to implement something similar. I wouldn’t blame anyone for thinking I was trying to blow smoke with some of these explanations. It’s a tech support nightmare.

This experience hasn’t exactly been great. Has it affected my opinion of the App Store in general or plans for future apps? I’m not sure yet. Flickit Pro is kind of a litmus test for me and my future plans for developing iPhone apps for my company. The jury is still out on whether my investment will pay off or not.

One thing’s for sure: In the future I’ll definitely think twice about implementing any workarounds for limitations in the iPhone OS.

Make sure to visit http://www.indierelief.com/ on January 20th to get some great software and support relief efforts in Haiti.

Green Volcano will be participating and donating 100% of all sales on January 20th to Doctors Without Borders.

Special thanks to Justin Williams of Second Gear and Garrett Murray for organizing this event. Herding 130+ indie developers is no small task!

I’m happy to announce today the introduction of Flickit Pro, Green Volcano’s latest iPhone app.

You can think of Flickit Pro as Flickit’s big brother. Pro rounds out the Flickr experience and adds all the features you’d want from a full Flickr app.

This app has been in the works for a long time. In fact, I blame the dearth of postings in this blog mainly on the fact that I’ve been spending practically every night and weekend of the past year working on Flickit Pro.

Here are some quick stats looking back on this year:

• Dozens of Photoshop mockups
• 190 source code files
• 598 source control checkins
• 24,000 lines of code

It takes a lot of work to create a good Flickr client - more than I anticipated when I started diving into this project!

I’m sure I’ll have lots more to say about the development of Flickit Pro in the near future. I hope to do a few “behind the scenes” posts about the development and design process. Keep an eye out.

But for now, it’s time for a quick (much needed) rest as I observe the feedback on the launch.

After that, it’s back to work on the next version! I have a ton of features planned that I wanted to get into the initial release, but just didn’t have the time to add.

As always, if you take the app for a spin and have any feedback or suggestions, don’t hesitate to drop me a line.

I think that every now and then it’s a good idea to remind yourself how far along you’ve come in the pursuit of a skill or hobby. I decided to go digging through my code archives and try to find the earliest piece of Cocoa code I have. I came up with this little gem:

This is the first “real” Cocoa app I built. It’s a little kaleidoscope graphics toy that lets you play around with Bézier curves. Here’s a movie of it in action.

The best way to learn a new technology/programming language/development tool is to just get your hands dirty and write some code. This is a silly little app, but it taught me a lot:

• How to build custom views
• How to draw with Quartz, the 2D graphics API on Mac OS X
• How to capture and handle mouse events
• How to create a document-based app
• How to use Interface Builder to lay out my UI

I’m still amazed at how little code there is. Just a few files, each with a page or two worth of code. Now that I think about it, it was probably the simplicity and elegance of my initial experience with these APIs that got me hooked on Cocoa programming. Everything just sort of ‘clicked’ for me when I was writing the app.

If you’re interested, you can play around with it yourself. I’ll even give you the code:

• App. Intel only: FlowerGen.zip
• Source code: FlowerGen-Src.zip

Feel free to use the source however you like. If you make any fun modifications to it, please drop me a line.

The earliest source file is dated December 10, 2002. These were the Mac OS 10.2 Jaguar days. Back then, it was hard for me to imagine working somewhere where I could write Cocoa apps all day. Mac-only programming jobs were hard to come by.

Fast-forward almost 7 years. Now I spend all day writing nearly the same Cocoa code for a computer that fits in my pocket.

Crazy.

Interesting:

(Via http://www.flickr.com/cameras/ as of July 5, 2009. Emphasis mine.)

Take another look at that graph. Notice the other cameras on the list? The iPhone is now not only the most popular cameraphone on Flickr, it’s the most popular camera, period. The iPhone camera is more popular than digital SLRs from Nikon and Canon.

Does this mean that people are chucking their DSLRs for iPhones? No, let’s not get too carried away.

There is an old photographer’s saying along the lines of: “The best camera you have is the one you have with you.” The iPhone certainly makes having a camera with you easy. And if this graph is any indication, iPhone users love to use their cameras.

With the introduction of the iPhone 3GS, the iPhone now actually has a respectable camera. The old camera was barely passable with it’s lack of autofocus and macro capability. People are buying 3GS’s like hotcakes. I don’t see this graph changing direction anytime soon.

What I am starting to wonder about is the future of pocket-sized point & shoot cameras. Sure, the iPhone has fewer megapixels and isn’t as good as a dedicated p&s in many other dimensions, but I wonder if many p&s owners with iPhones will care. If you’re carrying around your p&s for opportunistic photography, and you already have an iPhone, will it be worth the extra hassle of another device in your pocket?

I’m not yet sure what else we can deduce from this, but as a developer writing photography software for the iPhone, seeing graphs like this sure is fun:

(Via http://www.flickr.com/cameras/ as of July 5, 2009)

Last week Apple began giving developers access to crash reports from end users. The availability of these reports is surprisingly good news for developers, as it now gives us access to valuable information that we otherwise might not have.

This newfound access is a bit of a mixed blessing, however. Some crash reports are difficult to decipher, and without an understanding of what the user was doing when the crash happened, can drive a developer mad.

A spectrum of crashes

For those not aware, every time an app on your iPhone crashes, it records a report of the crash, and sends this report (anonymously) to Apple when the device is sync’ed with iTunes. The report contains information about the operating system version, type of crash, and the location in the code where the crash occurred. As of last week, developers now have access to these crash reports via their iTunes Connect accounts.

Sounds good, right? A report containing details of the crash! Now go fix the bug you lazy developer!

For some types of crashes, it is in fact that easy. By examining the location of the crash, it becomes clear what caused it, and the developer knows exactly how to fix it. Unfortunately, many times it’s not that easy.

Investigating crash reports is a lot like detective work. You’ve got a crime scene, and some evidence about what happened. Sometimes the evidence clearly shows all you need to know. Other times, you need to use your detective skills to deduce what happened.

While the format of a crash report is always the same, the evidence contained in the report can vary in its usefulness. Continuing our criminal justice metaphor, there are a few different types of crashes that developers can run into:

Caught red-handed — You’ve found the cookie thief with his hand in the jar. You’ve got fingerprints. There is no mistake about who did it or how he did it. These are the simplest crash reports to deal with. By knowing the location of the crash, the cause is immediately obvious. Often times, these kinds of crashes are due to simple coding mistakes, and would cause a crash in the same place in the same way every time. These crashes are the easy ones, and putting a fix in place is usually just as quick as reading the crash report itself.

High-value suspect — You’ve got a hunch about who did it. The list of possible suspects is small and it’s easy to check for alibis. While these types of crash reports are not as obvious as the previous one, they provide some good hints about what might be causing the crash. Often times, they give the developer a clue he can use to try to reproduce the bug himself (Which is always a good first step to fixing a bug). And with time, once you’ve got a reproducible case, you’ve got your man, and a fix is often just a few keystrokes away.

X-File mystery — These are the spooky ones. Lights flashing in the sky. Footprints too big to be human. Weird shapes in corn fields. Ships and planes disappearing mysteriously without a trace. These crash reports are the developer’s worst nightmare. Yes, you can see exactly where the crash is happening, but it doesn’t seem possible. There is seemingly no explanation for how the program could crash where it appears to be crashing. You can stare at your code for days, and never see how to reproduce the crash. If you want to see a grumpy programmer, give him one of these types of crash reports. Much like the mysteries listed above, the real explanation (if one is ever found at all) is often something obvious that’s easy to overlook.

Retracing your steps

One thing that crash reports don’t capture, which is invaluable when trying to solve crash mysteries, is a description of what the user had been doing up until the point of the crash. Knowing the steps that the user took to cause the crash is often the difference between finding the root cause of the problem in a few minutes versus a few days. This is something to keep in mind when submitting crash reports to developers. The more detail the better. If you are able to get a concise set of steps that reproduces the problem every time, this is best thing you can give a developer when reporting a crash. It’s a dream come true when you’re battling a tough crashing bug.

This is where you can help as the recipient of a crash. While getting the crash report document from Apple is useful, understanding the history of actions that led to the crash is even better. And there’s no way a developer can get this information unless you give it to them.

It’s understandable that being the recipient of a crash is a frustrating experience. On top of losing time and work after a crash, the last thing you may want to do is spend more time composing an email to the developer explaining what happened. After all, isn’t it the developer’s fault for writing bad code? Shouldn’t they have gotten it right the first time?

Yes, absolutely.

Pitching in

There is no disputing that crashes (and bugs of any kind) are caused by bad code. Unfortunately, it’s nearly impossible to write bug-free code. Good programmers know how to minimize bugs, but even the best coders can never really say their software is 100% bug free.

The problem is exacerbated for one-person indie developers, some of who design, develop and publish their software in their free time during nights and weekends. We don’t have large development teams with dedicated quality-assurance testers. Many times we’re the only ones writing code. We depend on the generosity of beta testers (who are usually just enthusiastic customers) to sanity-check our software.

This is not meant to be an excuse, or a license to write buggy software. Of course, no one likes to have bugs in their apps, and we do our best to minimize them. But, under these circumstances, tradeoffs are often made that favor publishing our software early and often, at the risk of letting some defects slip through.

So, the next time one of your favorite apps crashes, consider emailing the developer. Don’t assume that they already know about the problem. Don’t vent about the crash in an App Store review. Do send them a crash report and a description of what you were doing when it happened.

No developer likes learning that their software is crashing, but they’ll love you for taking the time to help them fix it.

I’ve had more than a few people ask me why Flickit is free. Several have said they can’t believe I’m not charging money for it. While I take this as a huge compliment, I get the feeling that some people are asking this question suspiciously, waiting for me to hatch some sort of nefarious plan by luring everyone in with a free app.

Let me be clear: I don’t plan to ever start charging money for Flickit or to introduce ads. I just don’t think either is appropriate for this app.

So if I wasn’t planning on making any money with Flickit, then what was my motivation for writing it?

The truth is that Flickit was a bit of an experiment for me. I saw this as a learning opportunity. Not only in terms of getting experience with new technology, but also gaining knowledge about all the peripheral issues related to writing software for this new platform. Things like: how to navigate Apple’s app approval process, the mechanics of App Store distribution, dealing with technical support for mobile users, and understanding the impact of being in the “Top X” lists on the App Store.

I also had a lot of questions I was trying to answer from a design perspective: What was the smallest amount of functionality people were willing to live with? Did they prefer a small, focused app, or did they want a more full-featured, desktop-like experience? Would people appreciate a custom, graphically rich user interface, or were they just as happy with the standard iPhone UI controls? How much UI polish is too much? What is the best balance between form and function for a small app?

Flickit was my attempt at trying to answer these questions. Granted, some of these things could be divined by reading about other developers’ experiences, but I felt like it was important for me to get first-hand knowledge using one of my own apps. Now that it’s been in the App Store for a while, and I’ve gotten a lot of feedback, I feel like I have a good idea for how to answer most of them.

I’m certainly glad that the app is popular and that it’s solving a real problem for a lot of people, but this is only the tracer round. The heavy artillery is still yet to come.