Universal App Template Rewrite

Almost 3 Years Ago

Just when I thought I had a somewhat decent grasp on developing and deploying iOS apps Apple came out with the iPad and threw a whole new element in the mix when it comes to developing.

It was almost three years ago that I published the first blog about my Universal App Template. I was inspired by, at the time, a little tutorial by a guy you might have heard of…Ray Wenderlich). His tutorial really helped me with a project I was working on and get through stumbling blocks. I wanted to provide a set of examples that any iOS developer could refer to that was straightforward and get up and running with creating a universal app in as short of time as possible.

Over the following months I added additional features such as iAd support, tabbar controller and iAd with tabbar support. Since then it is still the most visited article and starred/forked repo that I have.

Bueller, Bueller…

Over the years that followed I got busy and wasn’t able to keep up with the iOS updates, new features requested or bugs. The project was quickly becoming outdated.

I’m happy to say that I’ve carved out sometime to update this project. The plan is to start with the master branch, which is the most basic example, and update it from the ground up. I’ll then move on to the “feature” branches. I’m dropping support for iOS 3.2, 4.x and 5.x. Due to the fact that the iOS upgrades happen so rapidly, thanks to OTA, and iOS 7 is being released in less than a month, this is the perfect time to hit the reset button. The project, as well as, feature branches, will support ARC. I’ve also spent some time cleaning up the code base and removed a lot of duplicated code.

If you still need access to the “old version” I’ve tagged it.

No developer is perfect and I’m sure there are tons of things to improve so please drop me a line or file a bug and I’ll fix it ASAP.

It's a Dispatch Group Thing

One Thing Multiple Times

When it comes making iOS apps multi-threaded by now we should have at least heard of Grand Central Dispatch. The most common use case that is implemented and used is asynchronously fetching an image or web page, returning the resource…manipulating it in some fashion and the updating the main thread (UI) with updated resource.

Image Async Example

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_NORMAL, 0), ^{
    // fetch image from remote server
   dispatch_async(dispatch_get_main_queue(), ^{
     // set image for imageview
     // reload view if necessary...i.e. table view

Copy and Paste Should Work Right?

For a project I’m working on I thought I would be able to utilize the same paradigm for the following scenario;

Grab a list of all our customers accounts. For any given customer they can have n+1 accounts and I don’t want them to run serially, but concurrently (our vendor has a POORLY design datastore so the queries take forever) to keep wait time to a minimum. Once all the calls for getAccountDetailsForAccountNumber have finished the tableview on the main view controller is refreshed with the info.

// AccountInfoViewController

- (void)viewWillAppear:(BOOL)animated {
      [super viewWillAppear:animated];

      [self.imf getAccountListMetaInformation:^(id obj, BOOL success, NSError *error, IMFClientErrorType clientError) {

          if (error) {
           // handle error
          } else {
            // NSArray *aggregatedInformation = (NSArray *)obj;
            //refresh tableView with aggregatedInformation

// IMFClient pseudo

@property (nonatomic, strong) NSMutableArray *willHoldAccountDetails

-call getAccountListMetaInformation
       // do general setup and check for cache
      // BUT getAccountListMetaInformation COMPLETION BLOCK SHOULD WAIT
      -call getAccountDetailsForAccountNumber
         -run completion block
             - ADD return object from getAccountDetailsForAccountNumber to willHoldAccountDetails property
      -call getAccountDetailsForAccountNumber
        -run completion block
             - ADD return object from getAccountDetailsForAccountNumber to willHoldAccountDetails property
     -call getAccountDetailsForAccountNumber
        -run completion block
             - ADD return object from getAccountDetailsForAccountNumber to willHoldAccountDetails property
-finish getAccountListMetaInformation
-willHoldAccountDetails is now populated and passed to completion block

First Attempt

I failed.

Why It Failed

The first reason my code failed was because of my failure to take the time and truly appreciate and understand what happens with custom queues, dispatch_* methods and how objects are managed by queues and threads. I tried to apply the same logic to a totally different scenario.

The second reason my code failed was getAccountListMetaInformation is running on the main thread, so none of getAccountDetailsForAccountNumber’s dispatch_async calls are going to be able to run until getAccountListMetaInformation returns. Anytime the code runs on the main (or any) thread, that’s going to block other code from running on that thread.

I regrouped….literally

I went back and rewatched the WWDC videos from 2010 and 2011 on Grand Central Dispatch, as well as, read over Mike Ash’s posts regarding GCD. Paying particularly close attention to Friday Q&A 2009-09-04: Intro to Grand Central Dispatch, Part II: Multi-Core Performance.

Winning with Simplicity

dispatch_group_async to the rescue. When going back and evaluating what I was trying to do, which is to iterate over list of accounts and fetch each one concurrently, and then updating the comletionBlock with aggregated array, the simpliest approach was to push each request on to a dispatch_group and then WAIT for all of them to complete.

Shocker…it worked.

Lesson Learned

The most important lesson I took away from this is regardless how much abstraction and convience that GCD provides it can’t/won’t abstract the business logic and having a firm understanding of the GCD paradigms are paramount.


ThreadingHell. If you have a better/different implemenation then please let me know.

Fo' Swizzle

It is said that necessity is the mother of invention. Granted, I haven’t invented anything, however necessity did drive my latest solution.

Vendors – PIA

While working on a project for work I have the unfortunate requirement of using one of our vendor’s iOS frameworks that is horribly written and documented. From day one I discovered bugs and inconsistencies with how it is implemented. For one case I ended up reverse engineering what they were doing and sent them the snippet they should add in to fix the problem.

Not Wasting Time

Getting vendor to make changes that I needed, and consequently, the company, is about as quick as standing in line at your local DMV. I had to move the project along as fast as possible. During the early stages of the project I picked up a copy Graham Lee’s Test Driven iOS Development and took his advice on how to make my unit testing much more efficient with better coverage…so I started writing as many mock objects as I could for unit testing. In order to handle future test cases I created a MockObjectDataManager, but I found myself writing a lot of if/else statements throughout the app itself to handle switching between dev/test/stage/production web services vs. mockobjects. This was not good.

What I needed to do was setup the app so that any other developer, including myself, only had to write calls to the vendor’s framework, but could switch easily to using mockobjects when appropriate.

Method Swizzling to the rescue!

Fo’ Swizzle

The What

Unlike creating a category method with the same name as the original method (effectively replacing the original method), MethodSwizzling lets your replacement method make use of the original method, almost like subclassing.

Source: CocoaDev

Danger Will Robinson, Danger

I have read and seen developers using this technique, but it usually followed up with disclaimers such as:

  • unstable
  • experimental only
  • use at your own risk

Because of this general attitude I had seen I shy’d away from every really using this runtime feature. While I was foolish early on in my iOS development career to not learn more about it, using it without serious thought and consideration would probably proved distasterous. Granted, swizzling does allow a developer to swap methods for their own implemenations, sed developer has to make a lot of assumptions about the implemenation of the original method. If that implemenation changes the likelihood for your replacement method to break increases.


As stated earlier myself and my team needed the ability to rely on the vendor framework for communication to and from the web services, but also needed the ability to writing unit tests and CRUD mockobjects WITHOUT cluttering the app code base.

First, I recreated the json response from each endpoint and saved those into static files. Second, I rewrote the mock object manager to access and cache the models asynchronously, with better error handling. Third, I added in a preprocessor macro to flag whether or not the swizzled method should be used. Finally, added in a convience method to handle swizzle.

I hit Cmd+r and was off to the races. The app crashed. Had I been over confident in my ability to leverage the almighty runtime. Well, no…I just needed to pay attention to how classes are loaded. As I stated earlier, my mockobject data manager loads the .json files asynchronously. When the swizzled method was called the dispatch_queue was NULL and resulting in a BAD_ACCESS error.


The first attempt was to check for existence of the queue in the loadLoginResponse method:

if (!_fileQueue) { _fileQueue = dispatch_queue_create(fileQueueName, 0); } But wait…I had already instantiated _fileQueue in the sharedManager class method. Didn’t seem very reusble. As to not be out done this far into it I remembered the lifecycle of how/when classes are loaded and most importantly which the order of the meta methods. I moved the property and check from both the sharedManager and loadLoginResponse methods to + (void)initialize. Setting the USEMOCKOBJECTS to 1 and rerunning the app I successfully loaded my mock objects.

Lessons Learned

The most important lesson learned is to not be afraid to experiment with the more advanced features of Objective-C. When used correctly they provide a lot of flexibility and benefits to development and testing. My app is now setup to give any developer the ability to test against any live enviornment, as well as, test out new/existing features without changing a 3rd party framework or cluttering the codebase with a bunch of unnecessary “if/else” statements.

A great example of using these types of techniques is PonyDebugger from a little company called Square.

Get the Gist


Taming Core Location

In today’s mobile development environment using the device’s GPS in some shape, form or fashion is a given. Apple provides a great toolset for developers to access and utilize this functionality, but this is often done carelessly. I am not talking about privacy concerns or the misuse of the data, but many developers, myself included early on, had a poor code design implementation. The characteristics of such are usually:

  • CoreLocation implementation that was always tied directly to a particular UIViewController
  • Set the accuracy to kCLLocationAccuracyBest
  • Set filtering to kCLDistanceFilterNone.
  • Requests way to many location updates

Let’s examine each reason why these are not the best practice

Tight Coupling is Wrong

This is a more of a development practice that developers should always attempt to achieve in their code. There are always examples and uses cases as to why you would have to break this paradigm, but is still goal none the less. What we generally see, and most tutorials on the topic do this, is that the UIViewController sublcass will conform to the CLLocationManagerDelegate protocol, setup the manager and properties and listen for callbacks. I guess that is OK if you have only one use case and user interaction that requires CoreLocation, but in most cases you need to access CoreLocation more than once, thus you have to duplicate the same code. The “C” in MVC has now broken it’s intended contract and you have tightly coupled code.

Less Accuracy is More

This lesson is pretty simple. The more accurate the location you request, the longer it takes to get and the more battery power is drained. The faster the battery is drained the faster the iOS user gets pissed. The simplest example is a weather application. There is NO need to request such a detailed location. By setting your accuracy to kCLLocationAccuracyThreeKilometers you save yourself, and most importantly the user, time and end up with same information. Weather is usually shown based on a region area. i.e. zip code or city.

“For example, setting the desired accuracy for location events to one kilometer gives the location manager the flexibility to turn off GPS hardware and rely solely on the WiFi or cell radios. Turning off GPS hardware can lead to significant power savings.” – CoreLocationManager Reference

Filters are For Your Protection

Unless you are creating a turn-by-turn navigation app set a filter. Getting a location updates every half step or every second doesn’t add any value to the task of the application, but does have the same downsides as mentioned above. Poor battery life and horrible user experience.

You Don’t Need Updates Every Two Feet

This error is really an error in judgement. Apple provides developers with the fine grained control via distanceFilter and desiredAccuracy, but should be used sparingly and with apps that require multiple checks throughout the app session for location updates.

This service is most appropriate for applications that need more fine-grained control over the delivery of location events. Specifically, it takes into account the values in the desiredAccuracy and distanceFilter property to determine when to deliver new events. The precision of the standard location services are needed by navigation applications or any application where high-precision location data or a regular stream of updates is required. However, these services typically require the location-tracking hardware to be enabled for longer periods of time, which can result in higher power usage.

For apps that don’t require a constant stream of updates it is best to use start/stopMonitoringSignificantLocationChanges.

This method is more appropriate for the majority of applications that just need an initial user location fix and need updates only when the user moves a significant distance. This interface delivers new events only when it detects changes to the device’s associated cell towers, resulting in less frequent updates and significantly lower power usage.

Better CoreLocation Pattern Options

The first issue to tackle when implementing CoreLocation features is how to create your own manager that can be used and called throughout the app. The second issue that has to be addressed is how to allow other classe, regardless of type, UIView, UIViewController, NSObject, get notified of updated location information.

Issue One

The basic approach is to create subclass of NSObject that conforms to CLLocationManagerDelegate and implements the appropriate delegate methods. In my particular case I do have to listen for a stream of updates so I will be setting the desiredAccuracy and distanceFilter properties.

Issue Two

In order to tackle issue 2 I go one of three ways: NSNotification, Target/Action or KVO.

NSNotification would solve this problem, however it is seemed too decoupled and I personally feel that NSNotifications should be reserved for OS level notifications not service layer/domain model context changes. Finally, there are performance considerations when it comes to using notifications. No matter if the post to the notification center is done asynchronously or synchronously it is dispatched to the object synchronously. If there are a number of observers or if there is an instance where an observer must do a lot of work then your app could experience a significant delay.

Next on the list is the target/action pattern. While NSNotification was too decoupled from listeners, using target/action has now added a level of coupling that I felt a little unnecessary. In our custom manager class I would have to set a property, either NSMutableArray, NSSet or id that would hold the target instance, in addition, a property for the SEL, and when the location manager’s delegate method received a valid location update I would have to call something like:

`//NSMutableArray or NSSet

[clmListeners makeObjectsPerformSelector:@selector(methodToPerform)];`

`//id target

[target performSelector:@selector(methodToPerform)]`

There are two issues with doing the above proposal:

  1. You have the manager class now responsible for another class’s implementation without a contract.

  2. You are getting really close to having a delegate pattern which brings us closer to a one-to-one coupling between our classes.

The final option that we come to is Key Value Observing…which is the solution that I have gone with. Not only does it keep our manager class independent, but we also are also able to write our location code once while allowing our other classes to handle any UI or model manipulation as they see fit…independent of any other implementation or logic.

Custom Core Location Manager Class


View Controller Observing Change to Current Location


Creating a Universal iOS Framework Sample Project

Evolutionary Not Revolutionary

It is evolutionary, not revolutionary, for most iOS developers to go from copying the same set of “library” files from project to project, to creating a static library which is then shared between projects to finally creating a universal framework.  From my humble point of view the universal framework is the ideal solution because it gives you the ability to just hand off a single framework (which is really a directory), which keeps code implementation hidden, and still have access to a static library that can be edited and shared within a shared workspace.

Having read a few different tutorials on creating a universal iOS framework the task seemed quite daunting and quite honestly over engineered.  However, with a project that I am going to be working on shortly I needed to be able to have both options: static lib and framework. So I dove back into the documentation.  Of all the blogs and tutorials that I came across the one that helped the most was written by Justin DeWind over at Atomic Object.

The instructions were very straightforward and setting up a project was extremely easy. However, when I went to build the framework I got the following error

lipo: can’t open input file: /Users/cwiles/Library/Developer/Xcode/DerivedData/StaticFramework-akqynrxfwazyswaujkdqvysbbznj/Build/Products/Release-iphonesimulator/libStaticFramework.a (No such file or directory)
Command /bin/sh failed with exit code 1

I checked and rechecked my steps and Xcode project settings, but I kept getting this damn error message.  24 comments and a sample project later, Justin tracked it down.  The issue was in the original bash script for building and moving files around assumed that there was a custom build directory inside the project and not using the standard DerivedData directory. Justin kindly updated his scripts and everything ran great. The benefits of using the standard DerviedData build directory is that you can run clean the directory for a specific target for a given project.  The benefits of using a custom build directory are:
  1. Makes it consistent between xcodebuild and Xcode
  2. The directory is always known
  3. It is configurable
With the sample project now compiling for me using the DerivedData directory I wanted to see if I would make it work no matter what the setting was for an individual’s needs.  As I started looking at the different preferences and settings that could be made at the project and target level the rabbit hole went pretty deep and I could see how someone, including myself, could make a mistake and screwing up the process.  I decided to step out of my comfort zone and look into xcconfig files.  The configuration files are text based and allow you the same flexibility and micro tweaking of your projects as using the standard project setting panes that you are used to.

The way the order of importance works is this:

“GUI” Project Build Settings overwritten by “GUI” Target Build Settings” and “Config” Build Settings
“Config” Build Settings overwritten by “Config” Target Settings

The basic setup I implemented for using the xcconfig files is creating a Project-(Shared, Debug, Release) and Aggregate-(Shared, Debug, Release).  This might have been overkill or not have followed best practices, but it did allow for a large range of flexibility for the project and targets.

Two of the most recognizable customizations that are in direct relation to this project are the target’s name and build directory. You can set  them in the project level configs or the target level configs. I have set in the target level so that if you create other targets then they those can inherit project level settings or have specifics just for that particular target.

Canonical list of Xcode variables


A huge thanks for Justin DeWind and the rest of the Atomic Object crew for the original post and taking the time to help me troubleshoot this. I hope my sample project is a welcomed addition.  If you haven’t you should check out the rest of their posts...lots of great stuff.

If you have a feature request, find a bug or have a tip, especially with the xcconfigs PLEASE let me know.

Sample Project


UITabBarController Subview Gotcha

By far the most view blog article that I have, and subsequent Github project, is my Universal iOS App Template.  Unfortunately, it has been a tad bit neglected. There were some memory leaks, still supported 3.2 and not iOS5 compatible.  Now that I am working from home I have dedicated part of my day to personal projects and the first order of business is to get the app template up-to-date.  Most of the work was just cleanup and minor tweaks.  One of the branches however required a little bit more work. The template that comes with TabBarController support. A few months ago I added in the feature of having a “Tweetie” style indicator slider.  In 3.2 - 4.x iOS everything worked fine.  In iOS5 the indicator was not initially centered in relation to the first TabBarItem, but the entire TabBar.  When you selected another TabBarItem the indicator would move, but not in the correct position either.

The number of subviews are different between the iOS4 and iOS5.

--- iOS5
2011-11-17 09:14:54.290 UniversalExample[8989:f803] view frame: {{0, 0}, {768, 1024}}
2011-11-17 09:14:54.293 UniversalExample[8989:f803] view frame: {{181, 1}, {76, 48}}
2011-11-17 09:14:54.294 UniversalExample[8989:f803] view frame: {{291, 1}, {76, 48}}
2011-11-17 09:14:54.296 UniversalExample[8989:f803] view frame: {{401, 1}, {76, 48}}
2011-11-17 09:14:54.297 UniversalExample[8989:f803] view frame: {{511, 1}, {76, 48}}

--- iOS4
2011-11-17 09:16:06.751 UniversalExample[9033:b303] view frame: {{181, 1}, {76, 48}}
2011-11-17 09:16:06.754 UniversalExample[9033:b303] view frame: {{291, 1}, {76, 48}}
2011-11-17 09:16:06.754 UniversalExample[9033:b303] view frame: {{401, 1}, {76, 48}}
2011-11-17 09:16:06.755 UniversalExample[9033:b303] view frame: {{511, 1}, {76, 48}}

I now confirmed that there indeed was a difference in how the center position was being calculated. In iOS5 the first subview is the entire frame of the view.  However, I didn’t know which view(sub or super) that it might be referring to.

The best uiview debugging tool for situations like this is the recursiveDescription method.  If you haven’t heard or used it before I suggest/encourage you read Oliver Drobnik’s blog on it. In summary it is a private method to iterate over a views hierarchy.

After calling this method on the subviews in both iOS versions I saw the culprit. The first subview of a UITabBarController is an UITabBarBackgroundView, which obviously is going to extended the entire length of the tab bar.



Why did Apple add this subview you might ask? They added it because of welcome changes to UIKit.  Since iOS 2.0 developers have needed the ability to customize many of the UI elements, but unfortunately there wasn’t a straight forward way to accomplish this. The categories and hacks that people came up with are pretty cool, but not maintainable. With iOS5, and updates to UIKit, you can customize background images, tint color, selected images, etc. to your heart’s desire.

In order to fix the iOS5 bug in my template I just had to add a quick runtime check on the OS version and increment the index by 1.

All is right with the world.

Dynamic Model Update and Using Google App Engine

A few weeks ago I presented at the Mobile Technology for Teaching & Learning.  My talk was how to leverage service-oriented-architecture and objective-c runtime functionality in your enterprise applications.  In my demo app I had two json files to use as my datasource so that I wouldn't have to rely on an internet connection.

*I was glad that I did because I had lots of problems with it.

After that talk was over I pushed all the code to github with the goal of modifying the project to use an actual web service to show a real world example of how it works. In order to do that I needed to first create the web service.  Up to this point in my development career I have been using PHP for the service layer with CouchDB as the datastore.  With this particular project I wanted to take things in a different direction.  A few years ago I started tinkering with Python and have really grown to love the language. Unfortunately, I haven't been in a situation to were I could use it in any project beyond a few helper scripts (mainly because of me being a novice and my tight time constraints). I wasn't bound by these restrictions for this project.  What I wasn't looking forward to was doing the server side, "infrastructure" setup to get things going.  I wanted to focus on the development.

Enter Google App Engine to the rescue!  Setting up an account and application with GAE is out of the scope of this post, but Google makes it very easy to do…especially if you are focusing on Python.  I knew that scaling wouldn't be an issue nor would the data integrity. Google is somewhat good at both of those.

I was able to hack out a basic web service within a day.

My biggest roadblock came with handling class instances into JSON.  The awesome community of stackoverflow.com had it covered.

The demo app is modified to use these endpoints for data via GCD.  I also added a class extension for NSDictionary that simplifies the JSON parsing logic, thus removing a lot of the boilerplate code that I had in there originally.

I will be adding in some more enhancements and abstracting the code over the next few weeks.  As always, if you have any comments or suggestions please don't hesitate to contact me

Fun Times with Objective-C Runtime

Good reusable solutions to problems usually come out of necessity rather than luck or leisure.  Over the past 18 months I was always faced with problems of how to simplify the data integrity, security, and aggregation of multiple datasources, usually in big organizations that would then be fed in an iOS app.

The first solution to this issue is to create the "man in the middle".  Essentially a proxy/web services layer that acts as the gateway to all the necessary model objects.  Utilizing tools such as Gearman, CouchDB, MySQL, PHP, Python, Memcache and a little bit of Apache to make everything complete I was able to deploy a lightweight standard response to the iOS app.  As requests from various business groups would come in I found myself taking more and more out of the app and putting that logic into the services layer. Instead of having to rely on the app to handle security, data integrity, computational analysis, image manipulation, etc. I pushed that onto a light weight stack server side that could be scaled easily and mainainted without having to revision the app for basic model object changes.  The added benefits that I saw later on were that I could adapt the response based upon the request…(Android, iOS, mobile web, desktop browser, etc.)

Now that I was concentrating more on feature sets, bug fixes and UI enhancements I was still stuck with having to manage various model classes within the app.  This was a serious pain point to me. I wanted to be able to consolidate the various list and detail controllers that I had down to one instance of each.

Objective-C runtime to the rescue.

Let me be very clear that objective-c runtime is VERY powerful and not for the faint of heart, but when used effectively can be quite useful.  The approach that I took was as follow. 

Use the existing "standard" json format from a web services layer and restructure the "responseObject" so that it gave meta information about the model name, properties for class, which properties should be displayed on the list page and detail page.  By structuring the json  (xml, plist, etc) play load this way I now can push changes to model object and display anytime I want.

In the github project I use an "Employee" object as the example. The app should be able to show a list of employees (title and subtitle) and then a detail page for each employee that would display up to 3 properties.

I have included another json file for "Events" just so that I can show the flexibility. The same list/detail view controllers are now reused for two different objects.

The (current) limitations.
  1. There is an assumption that your list view will use the subtitle uitableviewcell enum type.
  2. Parsing and creation of classes doesn't take into account types other than nsstrings. I have an idea to remedy this, just haven't implemented yet.
  3. What about images?  Most list views have an image associated with it.  What I am thinking about it having a flag set in the properties specifically for images so that they can be loaded asynchronously.
I will be adding in these features.  I am still getting my head wrapped around some of the advanced features of runtime. Below are the links to resources that I used in my research.

Posted on slideshare is the presentation that I gave. It details the philosophical and practical importance of having an SOA that is similar to what I described.  It was heavily inspired by the presentation written on the subject of NPR's SOA.

Presentation References:

Solving Linker Error with New SimpleGeo Framework

One of the tasks that I had set for the upcoming 1.2 release of Stiqrd was to upgrade the SimpleGeo framework to their latest major release 2.0.  I was very excited about this because of the added features and bug fixes that include, but not limited to: simplifying model objects for places and block based logic and callbacks.
After some updates to my gitmodules file and a little bit of refactoring I was ready to go and test the compile of the project.
Unfortunately, I received the following linker error message.
As to not bore you too much with the technical details as why the error was occurring I'll get to the point.  With previous versions of the SimpleGeo, and most network operation based libraries, there was a ASIHTTPRequest library dependency which I had in my Xcode project.  What I had not paid attention to was the fact that the devs at SimpleGeo had include a version already of the ASIHTTPRequest library, but change the namespace changed to SGASIHTTPRequest.
This was an easy fix. Just do a quick find and replace all "ASIHTTPRequest" with "SGASIHTTPRequest". Then add the following import: <SimpleGeo/SGASIHTTPRequest.h>. Finally delete old ASIHTTPRequest that was in my project.
Recompile and off to the races.
If you are using SimpleGeo's iOS framework then I highly recommend upgrading your project to the latest.  I can definitely tell an increase in speed with the new library and the code management is much easier.

Fixing Blurry Text in iOS

Quick Pro Tip:

It never fails that no matter what project, simple or complex, I always run into a unique scenario that makes me scratch my head.  With the latest project I am working on the UI is almost 100% custom.  The views have custom CAGradientLayers, the views are positioned dynamically, special touch events, custom UI date pickers, etc.  Like most developers after staring at the screen for long periods of time text starts to look blurry.  After I looked closer I noticed that all my label text was actually blurry.  As far as I can tell it only occurs when the UILabels were added as a subview for a subclass for a UIView.  Though I am not 100% sure why this is occurring I am pretty confident that the blurriness is caused by frame calculation from the superview has a non-zero fractional component.

In order to remedy this situation, and future proof the app, I round the label's frame and center.

Everything is now all crisp and clear.