Many people have heard the phrase “Don’t live to work; work to live”.  This usually means that the goal of working should be to enable you to live your life, rather than allowing work to consume your life.  Far too many people in the tech industry sacrifice their families, spouses, children, and even their sleep, in order to make it in this industry.

The past year has been quite a ride, to say the least! I have been so busy with work, creating awesome features and technologies on iOS apps that over a year has raced by without an update to my blog!

I’ve also been neglecting my own apps due to being so overwhelmed with the requirements of my work as the lead developer for Salesforce.com’s iOS Chatter app, so it wasn’t until recently that I updated Docset Viewer to add support for iOS 7.  I’ve adapted the design to fit more in line with iOS7, while still providing the same experience as before on iOS6 and earlier.

In addition to iOS 7, I’ve added support for full-screen mode in landscape on iPad, hiding the sidebar.  I also added search term highlighting in search results to make it easier to find the matching text you’re looking for.

For the longest time it seemed that releasing an update to an iOS app was a random whack-a-mole process that I’d invariably get wrong in some way.  It was maddening, especially since iTunes Connect has only recently become a decent web application.  By switching to Jenkins for continuous integration of my iOS app builds I’ve greatly improved my process, but things didn’t really improve until I created a checklist for keeping track of my releases.

Since I’ve been asked many times about this very topic recently – both at work and on Twitter – I thought I’d write a post about how I bring some sanity to my release process so my app updates are timely and predictable.

Consider the following situation that happens far too often in mobile app development: You’ve just released an app that works perfectly for you, and you’ve tested it extensively. You’re proud of your accomplishments and submit the app to the world, only to have several emails sent to you from users who have nothing but difficulties in running the app. You send a bug fix release to the App Store, but since you’re still unable to reproduce the problem you’re at the whim of luck and end-user feedback. You can hope your users know how to send you a crash report, but what if the app isn’t actually crashing? Wouldn’t it be great to be able to access your app’s log information from that client to be able to troubleshoot the problems?

I’ve recently released version 1.2 of Docset Viewer, which fixes a number of bugs people experienced with the previous version. If you had problems with the previous release, please give this one a try.

One of the improvements I’ve added is the ability to customize whether or not you would like to back up your Docsets (which can get quite large) into iCloud. To keep with the instructional nature of this site, I’ll show you how you can do that in your own apps.

As I’ve shown in my previous post announcing Docset Viewer, I want this series of posts to be more than me talking about my new app. In keeping with the instructional nature of my site, I’m going to show you a few things that I did in my new app Docset Viewer and how I put it together. This time around I’m going to show how I use NSURLConnection for downloading large files, and even resuming them.

In Docset Viewer I’ve added the ability to download docsets directly from Atom feeds, either from custom URLs or from a pre-configured list of Apple’s available docsets. Since you may not be consistently connected to the Internet, it’s important to be able to download documentation packages incrementally, especially since they can be anywhere from 300MB to 500MB.

Over the years my blog has transformed from the usual “Wordy geek ranting about first-world problems” content toward more educational and informative posts on what I do for a living: developing awesome iOS applications. I don’t usually talk about the actual applications I’m writing though, since most of my work is on other people’s apps (and I’m not allowed to spill the beans on anything fun). I still consider myself an “Indie” developer though, and just like many other developers out there, I like to solve the problems that I myself face on a daily basis.

In this case what started with me complaining on Twitter turned into a new app due to the resounding and immediate “Me too!” responses I got from some of my followers. And with that I decided to create Docset Viewer.

For anyone who’s developed exclusively with UIViews on iOS may take the title of this post a bit oddly. “WHAT?!” they might say, “Are you insane? Core Graphics is not only a C-only API, but has confusing function names, and needs way more code to do the same thing I can do in less code in UIView”.  Yes, they might be right, but there’s a reason why Core Graphics exists. It’s FAST!

But using Core Graphics doesn’t mean that your code has to be confusing, or that you have to compromise flexibility for performance. You can have your cake and eat it too (aka you can have high-performing code that is easy to read). Read on to see what I mean.

As developers we spend most of our lives dealing with broken and barely-functional software: our own software. We do our best to make the applications we develop somewhat less broken and try to add features to make it functional. And once we finally get our software working bug-free and functioning stably, what do we do? Do we bask in the joy of a stable app and spend countless hours enjoying that moment? No, we move on to v1.1 or v2.0, adding more features and consequently more bugs.  It’s kind of sad if you think about it.

Since much of our lives are spent with applications in various states of brokenness, understanding how to debug our software and catch those exceptions that arise is vital to getting our applications to a stable state so we can release, consequently moving on to create a whole new set of bugs that need to be fixed.

Here are some basic tips and tricks to make your life easier dealing with Xcode 4, and tracking down those places where your code runs off into the bushes.

One of my pet peeves is Open Source iOS libraries distributed as just a collection of Objective-C classes, rather than being bundled as a static library. I know a lot of people prefer it that way, but from a maintainability standpoint it really doesn’t make much sense to me. So when I’m faced with another library I want to use that doesn’t have a static library readily available for it, I typically wrap it up in my own Xcode project, check it in to Github, and configure my Jenkins continuous integration build server to compile it for me.

I thought I’d walk you through the steps I go through to make this happen, so you can use this technique too.