Logging with CocoaLumberjack and TestFlight

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?
Continue reading “Logging with CocoaLumberjack and TestFlight”

Back To Basics: Simple debugging tips in Xcode

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.
Continue reading “Back To Basics: Simple debugging tips in Xcode”

Recovering from bit rot

One of the things that’s hard as a developer is keeping your legacy code up to date.  It’s all too easy to fire-and-forget; write your code, debug it just enough so that it compiles, and then forget it until it breaks again.  I’m guilty of that as well.  In fact, just today I discovered that my continuous deployment configuration for Boomle was broken…for the past 3 months.

After merging my code from a private repo over to Github, it still didn’t work.  After updating the Hudson build configuration to point at the proper repos and to respond to the proper webhooks (to get automatically triggered on a new check-in), it STILL didn’t work.  You see, not only does configuration change, but SDKs and APIs shift out from under you.  The iOS SDK had changed out from under my project, and the Xcode configuration was pointing at libraries and SDKs that no longer were shipped by Apple.

The lesson for me here is this: I need to get off my ass every few weeks to at least look at my source code.  Kick the tires a little, hit a build every now and then, and check that everything is still okay.  Because the longer you wait, the more things can fall apart.  Each one of those issues I mentioned above would have been simple to fix, had I addressed them right away.  But the more problems that build up, the more difficult it is to clean up your code.

As it is, I still need to integrate Game Center with Boomle, and refactor its drawing routines to be more efficient.

Now, I don’t believe in New Year’s resolutions.  Instead, I believe in making resolutions whenever they’re relevant, and sticking to them without the excuse of a New Year to motivate you.  My resolution is to take care of my projects proactively, instead of forgetting them.  Treat it like the quasi-living thing that I’m anthropomorphizing it to be, because even inactive projects need love too.

How to automate your iPhone app builds with Hudson

As any iPhone application developer who’s released at least a single app to the App Store will tell you, releasing your app is a terrible pain in the…well, it’s not a fun experience.  After your second or third app you start to get the hang of things, but there’s still pain and suffering involved.  Managing certificates, getting settings configured properly, and iterating between development, AdHoc beta builds, and the final App Store release builds, all make the process seem tediously manual and prone to human error.

In professional software development shops, you would use a Continuous Integration server to monitor your source control repository, check out changes as they’re submitted, compile, test and package up builds, and notify developers of the build’s health via emails and a web-based “Dashboard”.  I missed having this while developing my PhoneGap-based iPhone applications, so I decided to once and for all bring good development practices to my iPhone work.

Why do I need to configure automated builds anyway?

I get this a lot from people when I’m trying to convince them of the need for automated builds.  I personally find it hard to imagine people getting by without them in a single-developer project, let alone when multiple developers contribute to a project.

Monitoring the health of an application

Lets face it, we’re human, and we make mistakes.  It’s alright to break code from time to time, but what really sucks is when you find out far too late.  Did your recent changes accidentally eliminate your Entitlements.plist file, thus breaking distribution or release builds?  Do you have a file or library you forgot to check in, meaning when you delete the project from your working directory all those changes will just vanish?

Instead of having to remember to check each of those things manually (which, lets face it, you’ll forget at least half of the things you’re supposed to do inevitably), why not have an automated system tell you every time you make a change?  And if you’re in a multi-developer project, you’ll be able to see who broke the build and what change specifically broke it.

Always be ready for distributing your application

Many times in the natural course of development you’ll break code.  You’ve gotta break something in order to improve it.  But sometimes someone (your wife, a client, a beta tester) will want to try out your application before you have an opportunity to finish off your recent changes.  Instead of spending ages back-tracking your work to get your application to compile, why not rely on your automated build system to keep archives of previously successful builds?

Release what you test

Since you want to test an application before you release it to the App Store, you’ll probably create an Ad-Hoc distribution build to give to friends, family, or official beta testers before you bundle your application up to send to the App Store.  Maybe your testers will find bugs, maybe they won’t.  But at the end of the day that compiled app bundle you just created isn’t actually what you submit to Apple.  You need to compile a completely different app bundle with very different files stored in a Zip file, and if you’re not careful you could potentially be releasing something different than what you tested.

Why not have your automated build system create both your Ad-Hoc distribution build as well as an App Store release build every time?  That way you’re not only always ready to release something to the App Store, but you can be guaranteed that you’re submitting to Apple the exact code that your testers evaluated.

More benefits than I can list

If you’re really serious about best practices, you’ll probably want to write unit tests for your code and have those run after your code has been compiled, but before your build is packaged and archived.  Just because your code compiles doesn’t mean that it will behave correctly.  And lets face it, if you have a lot of tests, you’ll never wait for all of them to run throughout the course of your work.  So by running your tests as a prerequisite to a build succeeding, you’re guaranteed that you’ve got a safety net.

There’s plenty of other best practices that having an automated build system can help with, so what I’m discussing here will just cover the tip of the iceberg.  If I’ve convinced you that automating your builds, read on.

Continue reading “How to automate your iPhone app builds with Hudson”

Native UI Controls in PhoneGap coming along nicely

They say a picture’s worth a thousand words. Frankly I think inflation has really taken its toll on the cost of words, but nevertheless here’s a quick view of what’s been going on in my UIControls PhoneGap branch on Github.

In that screenshot the UIWebView frame, aka the actual webpage content of the app itself, was automatically resized so the toolbar and tabbar has room to be shown. And yes, those are native widgets for the toolbar and tabbar.

Currently the toolbar doesn’t support showing of any buttons, but the tab bar is fully functional. What it doesn’t support (or at least, it’s not tested at all yet) is using custom images in the tab bar items. But that’ll happen shortly.

Next on my roadmap before this feature can be pulled into the main PhoneGap branch is adding buttons to the toolbar, and animating the tool and tab bars when they’re shown. Currently they just pop into view. I’d like it to be possible for it to slide or fade in instead.

Check back here, or subscribe to my feed, to stay tuned on my additions to PhoneGap.

iPhone Certificate Woes

Like many people before me, and I’m sure many more after, I’ve had an ungodly amount of difficulty with Apple’s iPhone certificate provisioning system. I personally think it’s a brilliant solution to a difficult problem, but unfortunately for us they made it a pain in the ass to deal with. I’ve only run up against a few basic issues with them, and thought I’d document my solutions to them here.

And before you say it, yes I know there’s already tons of people complaining about iPhone app certificates, and there’s plenty of pages describing how to fix them on the ‘net to go around. But it was like finding a needle in a haystack for me. There were too many hits on forums and mailing lists that gave bad advice, or weren’t relevant anymore due to updates in XCode and the iTunes Connect website. So I’m summarizing here what works for me, and I’ll leave it up to the reader to figure if it works for you.

Entitlements.plist

These aren’t to be used for Debug builds. This file is necessary for some sort of magic when you deploy an app on the phone for either distribution or release mode. A lot of documentation will explain how you have to create it and add it to your Info.plist file.

This is great, but if you’re trying to figure out why your Debug profile isn’t working anymore, don’t attempt to add the Entitlements file to that build profile. It just makes things come to a screeching halt.

Debug vs Distribution vs Release

This one is annoying, and keeps popping its ugly head up. Say for instance I’ve got my developer certificate that I’ve been using for debug builds. Then I want to test my app on a few phones, so I go about creating a distribution certificate for it. In the project settings pane I change the drop-down to the new certificate, hit build, and *bam* I hit a certificate signing error when it tries to install the app on the phone.

As many people on the ‘net have pointed out, XCode is dumb and doesn’t assign the certificate to the correct profile. Some people manage to play around with it enough to get it to work, usually involving lots of restarts of XCode, removing and re-adding certificates, etc. I find some of that works, but when I get frustrated I just drop to VIM on the console, edit my project.pbxproj file, and change my cert settings manually.

If I’m really in a bind and I can’t get XCode to do what I want, I change my debug certificate to use the one I want for distribution and then drop into VIM. From here I can copy and paste the certificate lines it put in there to represent my distribution cert, and I copy it to my distribution or release build section. Then I change my debug cert back to my developer certificate.

Removing old certs from your system

Sometimes you just need to rebuild a cert. You might have made a mistake, or more often you have another phone you’d like to test your distribution build on. This means going into the iPhone Developer Portal and adding a device to the certificate. This means that the cert will now be different, and you’ll need to download the new provisioning profile.

Ah, but you already have that cert in XCode and, as you might have guessed, XCode isn’t smart enough to replace the old cert with the new one. You’ll just get two certs that will fight it out, and will always lose. So go into the XCode organizer and delete your old certs. You add the new cert, it compiles and signs itself, but when you try to install it on the phone it falls flat on its face.

You can go into the Organizer, select your phone, and remove provisioned apps and provisioning profiles from there. Or you can go onto the phone itself, and go to Settings -> General -> Provisioning, and you can delete your certs manually. Once that’s done, you might want to give XCode a restart for good measure and then add the new certificates from the iTunes Developer Portal.

Wildcard Certificates

I haven’t tried this myself personally, but when I started writing iPhone apps I was under the false impression that a more specific certificate was a good thing, as opposed to using wildcard certificates. But I’ve seen tons of references on the web of people recommending using them, and “You’re just asking for trouble if you create different certs for each of your apps”.

All I can say is…Whoops! I already released two apps to the appstore, and I don’t think I can change my certificates after the fact. Plus, I’m not sure if suddenly switching to wildcard certs for the rest of my apps will be a bad thing. Either way I’ll be doing this for my next app. If I only have 2 apps that will give me certificate pain when I maintain them, then so be it.