New in UIKit in iOS 8

With all the excitement surrounding a new programing language and another major version bump in Xcode, I've found myself pleasantly surprised with some of the new API in UIKit in iOS 8. I wanted to mention a few new additions that may have managed to fly under the radar.

UIAlertController

Goodbye UIAlertView and UIActionSheet. Hello UIActionController and block-based callbacks. Provide UIActionController with a styleType (might we see new styles in the future?), and the syntax is now identical between an actionsheet and an alertview. Big fan of the UIAlertView+Blocks and UIActionSheet+Blocks categories out there? Yes, they are great and I frequently pull them in, but I prefer to use Apple API when I can. Every added dependency is one more thing to maintain (yes, even CocoaPods) or inspect for warnings/bugs when a new version of iOS is introduced.

// Actionsheet-styled alert controller
let alertController: UIAlertController = UIAlertController(title: "Action Sheet", message: "Woot woot!", preferredStyle: .ActionSheet)

// Add cancel action
let cancelAction: UIAlertAction = UIAlertAction(title: "Cancel", style: .Cancel) { action -> Void in
    // Cancel
}
alertController.addAction(cancelAction)

// Add confirm action
let confirmAction: UIAlertAction = UIAlertAction(title: "Confirm", style: .Default) { action -> Void in
    // Confirm
}
alertController.addAction(confirmAction)

// Present alert controller
self.presentViewController(alertController, animated: true, completion: nil)

UIVisualEffectsView

Been using iOS 7 hacks to add blur effects to your app? UIVisualEffectsView will be a welcome sight. You can now created blur views and add them to your backgrounds, imageviews, or wherever else you please.

UIVisualEffect *blurEffect = [UIBlurEffect effectWithStyle:UIBlurEffectStyleLight];
UIVisualEffectView *visualEffectView = [[UIVisualEffectView alloc] initWithEffect:blurEffect];
visualEffectView.frame = someView.frame;
[self.view addSubview:visualEffectView];

Layout Margins

Confused by these -8s you see in your IB AutoLayout constraints? Me too. In iOS 8 Apple introduces layout margins on UIViews. Layout margins let you define the default whitespace surrounding your view (think of it as padding). These layout margins also cascade down to subviews that are pinned to the edge of their parent view.

From the UIView header file:

/*
 -layoutMargins returns a set of insets from the edge of the view's bounds that denote a default spacing for laying out content.
 If preservesSuperviewLayoutMargins is YES, margins cascade down the view tree, adjusting for geometry offsets, so that setting the left value of layoutMargins on a superview will affect the left value of layoutMargins for subviews positioned close to the left edge of their superview's bounds
 If your view subclass uses layoutMargins in its layout or drawing, override -layoutMarginsDidChange in order to refresh your view if the margins change.
*/

It appears by default Xcode 6 gives a view layout margins of {8,8,8,8}. With layout margins only supported in iOS 8+ this may or may not cause immediate issues if you build you project in Xcode 6 for iOS 7. A solution until you can support iOS 8+ is to select the constraint in IB and unselect "Relative to margin", then readjust the constant from -8 back to 0, if needed.

What Else?

  • UITraitCollection class can now be used to describe an object like UIView or UIViewController in terms of size, scale, and idiom traits
  • UISplitViewController now supported on iPhone and iPad -- oh hai, iPhone 6 Plus
  • New properties on UINavigationController including hidesBarsOnTap, hidesBarsOnSwipe, navigationBarHidden, and others

  • Take users directly to your app's settings in the iOS Settings app by passing UIApplicationOpenSettingsURLString to openUrl:

Learn More

Pragmas in Swift

New language, same old Xcode. The are no #pragmas in Swift, but Xcode 6 supports comment detection in Swift for:

// MARK:
// MARK: -
// FIXME
// TODO: 

Xcode 6 will list the above in the jump bar, just as it did in Xcode 5.

jump bar

See also Swift Extensions for a new pattern to group semantically related code.

iOS Design Patterns for Data Communication

iOS design patterns have evolved a lot over the years. In the three short years I've been involved in the mobile dev world, different trends have come and gone and best practices once used by many have been replaced by newer, more efficient ways of solving a problem. If you work in software development you know this... no big deal... that's just how it is. I agree. I wanted to lay out a few of the patterns for my own benefit, and include a look into one of my favorite new* patterns, functional reactive programming.

There are several different approaches you can take in communicating information between objects. Borrowed from NSHipster, this list highlights differences in coupling and intended audience under different approaches.

  • Intimate (One-to-One)
    • Weakly coupled
      • Target-Action
      • Delegate
      • Callbacks
    • Strongly coupled
      • Direct method invocation
  • Broadcast (One-to-Many)
    • Weakly coupled
      • Notifications
    • Strongly coupled
      • Key-value Observing

I don't intend for this post to only hit the listed patterns, and accordingly don't plan to just walk through each of these approaches. However, I will briefly touch on several and add some thoughts on a few other patterns along the way.

Target-Action

The target-action pattern is probably most familiar from using different UI controls hooked up to their respective IBActions. When a target receives an event, such as a button receiving a tap or a date picker landing on a new date, an action is triggered.

Delegation Pattern

The trusty delegation pattern. I'll never forget this question from a job interview with Apple while I was still a student at BYU. Why are delegates protocols? Delegates are extremely powerful because any object can say hey, I conform to this protocol, I'll be the delegate. Delegates can also conform to multiple protocols (friendly tip: this was the answer the interviewer was looking for). If delegates were subclasses instead of protocols then the view controller would be forced to choose one set of instructions to support. It's not uncommon for an object to conform to 3, 4, or 5. The delegating object keeps a reference to the delegate object and sends messages to it at the appropriate time. Some of the more common UIKit protocols include UITableViewDelegate, UITableViewDataSource, UITextFieldDelegate, and UIAlertViewDelegate.

Blocks

Delegates are so old school, who uses them anymore? I mean, srsly:

Blocks are nice to use because they can keep the completion code/logic nestled up nice and close to the responsible party. In the words of Ryan Hodson:

Blocks are Objective-C’s anonymous functions. They let you pass arbitrary statements between objects as you would data, which is often more intuitive than referencing functions defined elsewhere.

For simple tasks it can end up feeling a lot cleaner than using delegate counterparts or creating and calling private methods. One downside: the syntax is impossible to remember. F***ing Block Syntax is your friend.

Notifications

The notification pattern is so core to Cocoa that I think I've yet to see a code base that doesn't use NSNotificationCenter. As the list above suggests, notifications are a broadcast form of communication. A notification is sent out and any object listening for it at that time will receive it and can respond accordingly.

While powerful, I've seen notifications abused more than once or twice. What happens is the developer thinks to him or herself, "hmmm, I could do it this (other, more preferable) way, ORRR I could just setup a notification and be listening for it in this one (or five) other places and be done with it." The problem is that program execution suddenly goes from readable, flowing, easy-to-follow, to JMP over here and JMP over there. I'm not saying don't use NSNotificationCenter, but know when and when not to. If you are setting up notifications, listening for more notifications, and routing those to other view controllers all in your app delegate... you may be doing it wrong. Want a good use case for notifications? Currently I use NSNotificationCenter to notify listeners that network reachability has changed. It seems (to me) to be an appropriate use of a one-to-many broadcast.

KVO

Key-value observing is another of those patterns entrenched deep in the heart of Cocoa. The biggest problem in my book: it's extremely easy to write bugs into KVO code. The first time I did Startup Weekend I joined a team with an experienced, long-time Mac dev and KVO was almost the death of me that weekend. The idea is powerful: observe keypaths and get notified about state changes in any other object. At CocoaHeads last week we were on the topic of KVO in Swift and began hopeful speculation for next year's WWDC providing a new API built on top of KVO that makes KVO super nice in Swift.

ReactiveCocoa

Speaking of super nice KVO... enter ReactiveCocoa (RAC). What is RAC? The first question is what is functional reactive programming (FRP)? The best explanation of FRP I've hear thus far, from one of the creators of RAC:

Programs take input and produce output. The output is the result of doing something with the input. Input, transform, output, done.

The input is all the sources of action for your app. It’s taps. It’s keyboard events. It’s timer triggers, GPS events, and web service responses. These things are all inputs. They all feed into the app, and the app combines them all in some way to produce a result: the output.

The output is often a change in the app’s UI. A switch is toggled or a list gets a new item. Or it could be more than that. It could be a new file on the device’s disk, or it could be an API request. These things are the outputs of the app.

But unlike the classic input/output design, this input and output happens more than once. It’s not just a single input → work → output—the cycle continues while the app is open. The app is always consuming inputs and producing outputs based on them.

To put it another way, the output at any one time is the result of combining all inputs. The output is a function of all inputs up to that time.

When I mentioned FRP in the first paragraph I put an asterisk next to new. That's because FRP is not new. The principles of reactive programming have existed since at least the 90s, and KVO in many ways accomplishes similar goals in eliminating state and observing objects for changes. ReactiveCocoa includes a powerful API that achieves many of the goals in reacting to property changes but without the pain points of KVO.

The de facto RAC example seems to be observing a UITextField (or perhaps many) for text changes and updating say, a login button, to an enabled/disabled state based on the contents of those text fields. The same approach without RAC requires, no joke, checking the contents of fields in viewDidLoad as well as the use of at least two different UITextField delegate methods (namely, textField:shouldChangeCharactersInRange: and textFieldShouldClear:).

One of my favorite other use cases so far is reloading tables in UITabBarController's root view controllers. If you've used UITabBarController before, you may have been surprised, confused, frustrated (or just not cared) to find out that the root view controllers in each tab are only loaded once (or you may have been smarter than me and realized from the beginning that it actually makes more sense that way). You don't get a full refresh of the view lifecycle, so you can't rely on viewDidLoad being called... ever again, really, unless the app is FCed. But at the same time putting a fetch operation in viewWillAppear just feels like a bad idea, right? Do you really want to fetch all that data again if the user leaves the screen and comes back 2 seconds later? Of course not. Okay what next... setup an NSTimer or some sort of timestamp and only fetch it if it's been at least 60 seconds? All that hairiness for something as simple as fetching some data? And what if on top of that you fetch that same data on a different screen or on appDidResume, how do you notify that view controller?

ReactiveCocoa has made my life so much easier when it comes to this. I setup an observer for the data cache property that feeds the table on that screen, then simply fetch ze datas on viewDidLoad. Once the data returns and updates the cache, the observer reacts to that change and reloads the tableview. I've also added a call to fetch that same data on applicationDidBecomeActive so it's periodically updated. It works great, is super clean, and avoids some ugliness in subclassing UITabBarController and using timers.

Summing it up

Functional reactive programming and ReactiveCocoa is the latest of many new patterns to influence iOS development and Objective-C. It borrows good ideas from other paradigms and brings new solutions for solving familiar problems. Each of the patterns mentioned above have their own characteristics and intricacies. I'm not advocating for a complete functional revolution, but learning functional programming does make you a better programmer. For those who just haven't bought into the FRP hype, I leave you with this story from Rob Napier's post, Swift is Not Functional:

I used to ride a motorcycle. When you’re riding a motorcycle, you have to be much more aware than when you drive a car. If you’re not, you’re going to get hurt. But the thing I noticed was that riding a motorcycle made me a better car driver, too. Functional programming is like that. Riding a motorcycle isn’t always the best way to get somewhere, but we’d have better drivers if everyone learned on motorcycles. We’d have better programmers if colleges taught Haskell first and Java later.
And a picture of my motorcycle for good measure.

And a picture of my motorcycle for good measure.

Writing more performant mobile apps

Although I earned a technical degree in college I would still say that I am in large part a self-taught programmer. Yay for DIY. I started programming in a 100 level CS class at BYU years ago, but I wasn't really programming back then... I was blindly following TA help sessions and being handheld through everything. A few semesters and a couple CS/EE classes later I still wasn't much of programmer. It wasn't until Dr. Liddle's Android class in Winter 2011 that things finally clicked for the first time.

For the semester project I was creating a simple Cow Tipping game where you tap cows until they tip over. I remember trying to figure out how I would track how many taps are left before the cow tips over. I discussed the problem with a friend and he gave me a couple suggestions. I eventually arrived at using a map with keys being cow ImageViews and values as the number of taps left until it falls over. It was the first practical application for data structures that I'd found.

From that point on I did a couple more side Android projects and landed my first Android contract job and, a few months later, an Android internship at rain. Then in summer 2012 I began interning at Solutionreach and was asked to learn iOS. I was gaining experience and a portfolio, yes, but thinking back I made the jump from DIY coder to writing enterprise apps pretty quickly, to be honest. I've spent a lot of the last two years trying to supplement my ability to write apps with software design principles and performance optimizations. Having recently started with iTV and getting exposed to a different, mature iOS codebase it's been a great opportunity to challenge existing lines of thinking and learn about better, more performant approaches and patterns. It's one of my favorite things about the gig.

Okay so finally to the code part. In Objective-C, NSDictionaries and NSArrays can do anything, right? Well, yeah, they can, probably, but what about NSSets? NSSets offer better - O(1) - performance for extremely routine tasks such as accessing items in a collection or checking if a collection contains an item. NSArrays on the other hand must iterate through their entire contents until the particular object is found - O(n). So here's my suggestion: don't forget about the awesomeness of NSSet.

Okay, so some examples... First up I'm going to create a collection of twitter handles for my favorite followers. Here's three potential approaches.

1. NSFastEnumeration

NSMutableArray *mutableFavs = [NSMutableArray array]; 
for (TwitterUser *user in user.followers) { 
  [mutableFavs addObject:user.handle]; 
}
NSArray *favorites = [mutableFavs copy];

2. EnumerateObjectsUsingBlock

NSMutableArray *mutableFavs = [NSMutableArray array];
[user.followers enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
    [mutableFavs addObject:[obj handle]];
}];
NSArray *favorites = [mutableFavs copy];

3. NSSet's valueForKey

NSSet *favorites = [user.followers valueForKey:@"handle"];

This is a fairly simple example, with the big question being okay, what now. My ultimate goal is to create a collection of favorite tweets by looking through a timeline full of tweets, comparing the author's Twitter handle, and pulling out the matches. Since I don't care particularly care about the order of the collection, valueForKey and using a set is an excellent option. Or, I may care about order eventually, but for now I don't, and later on I was planning on sorting the results alphabetically anyway, which means I have less reason to preserve order by using NSArrays at this point.

So how can it be done? Here's two approaches:

1. NSFastEnumeration x 2, aka the double for loop - O(n^2)

NSMutableArray *mutableFavs = [NSMutableArray array];
for (TwitterUser *twitterUser in user.followers) {
    for (Tweet *tweet in timelineTweets)  {
        if ([twitterUser.handle isEqualToString:tweet.authorHandle]) {
            [mutableFavs addObject:tweet];
        }
    }
}
NSArray *favoriteTweets = [mutableFavs copy];

2. NSSet's valueForKey + NSPredicate - O(n)

NSSet *favorites = [self.followers valueForKey:@"handle"];
NSPredicate *predicate = [NSPredicate predicateWithBlock:^BOOL(id evaluatedObject, NSDictionary *bindings) {
    Tweet* tweet = evaluatedObject;
    return [favorites containsObject:tweet.authorHandle];
}];
NSArray* favoriteTweets = [timelineTweets filteredArrayUsingPredicate:predicate];

I know what you're thinking....

If you didn't catch it, we used an NSSet to drop the complexity down from a BAD BAD BAD O(n^2), to an ALRIGHT, I CAN DEAL WITH THAT O(n) by using NSSet's constant lookup time. Think about it this way, if this user had 500 followers and we were looking at 200 tweets, with the first approach it could take 100,000 loops until we successfully had our collection of favorite tweets. With the second approach we are looking at orders of magnitude faster, and arguably cleaner code too. (For more on cleaning up these types of operations further, check out ConciseKit... or maybe just forget obj-c and jump into Swift. :)

Moral of the story is to continue to look for ways to improve your code. "Yeah, it works" may be a huge accomplishment in the beginning, but performance is key as you scale. Although it probably won't "make" your app, it can definitely "break" your app if done wrong. It's true that it may not matter either way when dealing with small data sets, but avoid the urge to think meh, it probably won't matter. In your testing you may have 4 or 5 objects in your collection, but in the real world what happens when a user ends up with 700? Combine that with a poorly designed filtering method and you could be in trouble.

David and Goliath

I've recently been reading Malcolm Gladwell's latest book, David and Goliath. Gladwell really took my understanding of the David and Goliath story and turned it on it's head. Take this quote from historian Robert Dohrenwend, cited in the book, which reads:

Goliath had as much chance against David as any Bronze Age warrior with a sword would have had against an [oppo­nent] armed with a .45 automatic pistol.

Didn't expect that, did you? You'll need a little context. In the book, Gladwell explains that ancient warfare in many ways was a game of rock, paper, scissors, the way the infantry, cavalry, and artillery balanced one another. With long spikes and armor, infantry could stand up to calvary. Cavalry, moving quickly on horseback, moved too fast for projectile warriors, and lastly projectile warriors were deadly against sitting duck infantrymen. David was a slinger, a projectile warrior, and Goliath was heavy infantry. According to custom, the best warrior from each army would fight in hand-to-hand combat, with the losing side surrendering to the victor. David, however, didn’t play by the rules. Another excerpt:

Goliath is heavy infantry. He thinks that he is going to be engaged in a duel with another heavy-infantryman. David, however, has no intention of honoring the ritu­als of single combat. When he tells Saul that he has killed bears and lions as a shepherd, he does so not just as tes­timony to his courage but to make another point as well: that he intends to fight Goliath the same way he has learned to fight wild animals—as a projectile warrior.

He runs toward Goliath, because without armor he has speed and maneuverability. He puts a rock into his sling, and whips it around and around, faster and faster at six or seven revolutions per second, aiming his projectile at Goliath’s forehead—the giant’s only point of vulnerability. Eitan Hirsch, a ballistics expert with the Israeli Defense Forces, recently did a series of calculations showing that a typical-size stone hurled by an expert slinger at a distance of thirty-five meters would have hit Goliath’s head with a velocity of thirty-four meters per second—more than enough to penetrate his skull and render him unconscious or dead. In terms of stopping power, that is equivalent to a fair-size modern handgun. “We find,” Hirsch writes, “that David could have slung and hit Goliath in little more than one second—a time so brief that Goliath would not have been able to protect himself and during which he would be stationary for all practical purposes.

Underdogs like David often learn to think differently, to change the rules of the game. When facing incredible odds what are your options? Certainly a hand-to-hand fight with a powerhouse will lead to failure. But this is where underdogs have a distinct advantage. The threat of sure failure leads to creativity, determination, and incredible courage. David was able to conquer Goliath by changing the rules of the game, and by the same vein many heavy underdogs can succeed in business by using their position as a strength.

Larger excerpt available at 'David and Goliath': Understanding the dynamics in a power struggle.
Book available on Amazon.


Another point Gladwell makes is about what most of us know as the big fish in a small pond effect. His ultimate point is that he is against someone attending a prestigious university just for the name. To choose the "elite" university more often than not means choosing to be a little fish in a big pond, since only a few will shine among the best. Gladwell believes firmly that people are generally better of being a part of a lesser known institution or company where they have a great chance of standing out.

I think this point is especially true at BYU. BYU isn’t ivy league, but it does brings out some of the best students from around the United States and from around the world. Many students, accustomed to straight A’s and the frequent praises of their professors and parents, struggle when facing B and C grades for the first time in their life. I'll be honest, I was no exception. As a computer engineering student who was top 25 in my high school class, I struggled heavily when the concepts did not come easy to me and I faced low B grades. I felt dumb and it made want to quit. After trying my hand at a mobile development class in the Information Systems department I did well and regained some confidence. Rather than trying to be the small fish in the engineering pond I decided to switch majors to Information Systems, where the business topics came easy and the technical topics were not so rigorous (or low-level). The largest personal benefit from this move was the feeling of confidence and empowerment. I no longer felt dumb among my peers, and the confidence led to great success in the classroom and earned me qualified positions at local software development companies. Now, officially one day from completing my last class at BYU, I am very grateful that I decided to make the move to Information Systems.

Gladwell explains this phenomenon as relative deprivation. The worst STEM students at Harvard are likely to be the top students in other programs, but Harvard students compare themselves to their peers and as a result have similar dropout rates as all programs across the county. In Gladwell’s opinion, it is better to attend a non-elite institution and leave feeling successful, then to have been a small fish in a big pond. Similarly, companies should not hire based on a name alone. Top performers - at any size institution or company - prove to be better employees than average performers at top ranked institutions and companies.


Based on what I've read of David and Goliath so far, I'd recommend grabbing up a copy. Gladwell taught me a couple history lessons and opened my mind on how you can turn disadvantages into strengths.

Objective-C has fallen

It's been quite a ride since the plethora of WWDC announcements yesterday. In addition to awesome new end user features in OS X and iOS, cool new frameworks like HealthKit and HomeKit, and some expected upgrades and enhancements to Xcode, Apple really threw everyone for a loop by announcing a new programming language, Swift. When Craig Federighi dropped the news it felt like getting hit by a brick wall. You could tell something big was happening when he started talking about how great Objective-C would be "without the baggage of C,"  but you had no idea what. Then it hit. Swift.

What's crazy to me is the fact that Objective-C developers were the hottest engineers on the market just 2 days ago, and now the technology has effectively had its fate sealed. Thought you were golden as an iOS dev, bought completely into Objective-C? Nope.

I'm not saying iOS developers are all of a sudden SOL and should start worrying for their jobs, but man it hits close to home that an industry I'm so entrenched in is completely upended in a day. Sean Hess put it well in our CocoaHeads google group that "framework and platform knowledge has always mattered more than language syntax. Syntax is really easy to pick up. So all the knowledge that matters you'll carry with you. It won't take much time to get up to speed for any good Obj-C dev." Indeed, there's much to look forward to as an iOS developer right now, not the least of which being the ability to build better apps in less time with Swift.

Windows going free for phones and small tablets

Microsoft announced today that they are cutting prices of Windows for manufacturers to spur adoption. And by cutting prices I mean to $0 for Windows Phone and tablets under 9". Is this big news? I don't know. In the world of Microsoft it's definitely big news, because Microsoft's original business model was almost exclusively built around Windows OS licensing agreements. Microsoft aficionados may be rejoicing, but in the greater world of mobile my read on the situation isn't so optimistic.

I feel it's somewhat contradictory to Microsoft's recent actions -- increasing vertical integration with the Nokia purchase and the forward play into manufacturing their own Surface tablets. It felt like the strategy was shifting towards emulating Apple's model of controlling the end-to-end experience by owning the software and hardware, differentiated by a heavy dose of business/productivity functionality. Now they want to compete with Android by becoming an open platform? I'm confused.

Overall I think it's probably good for the industry, so that companies like Amazon, Samsung, Pebble, Fitbit, or other OEMs have more options than just homegrown or Android if they want to start a line of phones, tablets, or watches... but as an outsider the read between the lines here is that MSFT can't make the money they want by licensing Windows Phone/Windows RT (under 9"), so they are going to try and go the open route and see if they can build the ecosystem and make money off the app store like Android. The problem with that approach is that they are 3 years too late to that game too.

Hackdance & Second Government

Dru and I participated in Hackdance this past weekend. It was a 48 hour hackathon at the Deer Valley Lodges in Park City as a part of Collective's Disruptfilm event at Sundance Film Festival. From the site:

Hackdance: the first celebrity-driven social impact hackathon kicks off on January 16th, & you're invited to take part in this historical event! Your mission: partner your tech skills w a celebrity passionate about changing the world to design apps/hacks that use technology to create social impact.

We took school and work off on Thursday and Friday, not quite sure what we'd gotten ourselves into. Dru brought her product management and design skills to the game and I came in with my iOS and Android background. The event started with the celebrities sharing their ideas for social impact. There were a lot of good ideas, including the use of Plexi APIs for reporting and preventing cyber-bullying, an ambitious but thoughtful idea for virtual second government, and a movement for improving the Plant-a-Fish donation collection, among other ideas. Dru and I liked a few of the projects, and ended up joining our first choice with Alex Ebert for the idea of Second Government.

Dru and I teamed up with two "serial hackathoners" who were invited out from Silicon Valley. I think they've done something like 15+ hackathons in the past year, placing top 3 in over half of them. It was pretty cool getting teamed up together...until I realized how serious about hacking they were. With no hackathons under my belt, my most similar experiences were the BYU Mobile App Competition and Startup Weekend. Joining with a team of hackers was quite an adjustment.

The main difference was that both the mobile app competition and SW had an end goal to build a complete product or business, not just put something together for demo purposes. We had significantly different theories on how to tackle the weekend, but overall ended up with a pretty good balance. We ended up creating a semi-functional Reddit- and Stack Overflow-inspired website and iOS app, featuring proposals for governmental change and a system of comments and upvotes.

The goal of the platform is to provide an open system for proposing governmental change without all the bureaucracy and pessimism. Ideas are then voted, vetted, and refined, with the most popular suggestions rising to the top. While most people don't bother voicing their opinions on government because of little hope it will ever be heard, SecondGov provides the platform to test out ideas in a virtual world without the worry of what can or can't be accomplished. Ultimately, proven, popular ideas from SecondGov can be taken (with their tens or hundreds of thousands of upvotes) to the real government to make real change happen.

The team

The team

Alex, who won a golden globe for best original score just last week, was awesome to work with. He was definitely the most hands-on and supportive of the celebrities from my perspective. He spent a lot of time working with us on the direction of the app, design, and prepping for our pitch. Plus, he's an artist, a writer, and a performer... he knows how to make a point with some conviction.

Dru making an awesome face

Dru making an awesome face

Our pitch to the judges went well. We definitely bit off more than we could chew by working on a web app, iOS app, exploring a virtual reality platform, and trying out a pre-release iOS motion-tracking SDK by Plantronics in the two days. Our demo included a piece from all four, but my personal favorite was the Plantronics concept headset. We used it in conjunction with the iOS app to view proposals hands-free and upvote or downvote them with a nod or shake of the head. It wasn't necessarily a cornerstone piece to the premise of SecondGov, but it was fun to work with one of the hackathon sponsors and brought a little wow factor into the pitch. I'll post a video later if I get my hands on it.

Pitching to the judges

Pitching to the judges

The result was awesome. We won first place for social innovation, including a 5k cash prize and a 10k investment from the Sorenson Global Impact Investing Center.

Alex sharing the vision

Alex sharing the vision

Awesome projects from every single team. Other final products included a Google Chrome extension for reporting cyber-bullying, YoungStarter, improvements to the Plant-a-Fish donation system, Rah Rah's tech truck, a SHFT mobile app, and a Lead and Pledge movement to end domestic violence.

Related links

Finding the Right iOS Dev

Over the past few weeks I've had a few friends and colleagues ask me about the iOS developer interview process -- both on the interviewer and the interviewee sides. Having sat on both sides of the table, this post is a collection of thoughts on how to find the right developer for the job. I should note that these opinions are entirely my own and are completely subjective.

First, I think there a few things to consider before diving straight into interview Q&As -- there's a lot more to it than just rattling off a list of Objective-C programming questions found from a Google search. Yes, that can help you find smart engineers, but it might not get you the whole picture. Here are a few main points to consider when looking at a candidate:

  • Published work
  • Knowledge of Objective-C and Cocoa Touch
  • The right ratio of hackerness vs convention-use
  • Online reputation*
  • Overall tech savviness

Published work

You'll want ask for examples of published work. While at Cocoa Camp last summer I noticed several things that Apple looks for in a perspective engineer. Here are two from my notes:

  1. Someone who is driven to learn - and ship.
  2. Someone who has an obsession with creating - and delivering.

There are lots of extremely talented computer scientists and web developers in the world, but it takes a unique blend of hard-skills and finishing ability to make a good iOS developer. While pet projects are nice, that alone shouldn't impress you. Half-baked ideas are just that, half-baked, and not something you want to publish as your company's next app. Looking at the candidate's apps on the app store will tell you more about their experience level than their resume ever could. If their work was written as a team effort, ask them which pieces they developed or what percentage contribution they made to the overall app.

Knowledge of Objective-C and Cocoa Touch

You'll want to be sure the person has a solid understanding of programming principles, design patterns, Objective-C, and the Cocoa Touch frameworks. The depth of knowledge and understanding required will vary depending on the experience level you're looking for and how much you want to pay, but here are my suggestions for a good junior-level iOS developer.

  • MVC pattern - Ask the candidate to include an example or explanation of how they've used it in an app. 
  • Protocols and delegates - Ask the candidate "why are delegates protocols?" (and not normal classes). What I would look for is that the candidate can explain that protocols are more flexible than a normal class, because they can be implemented by any class, allowing for greater reuse. If they can explain this to you, in addition to the general idea behind the delegation pattern, that's a good sign.
  • Strong vs weak pointers - What's the difference? When would you use one vs the other?
  • Check out Ray Wenderlich's post on iOS interview questions.
  • Any questions specific to your project, code base, or existing development team that can help determine if this person is the right fit.

Hackerness vs Convention-use

I'm not sure what else to call this one. Objective-C is a very convention heavy programming language. If the candidate is a recent transplant from another development stack or a hobbyist iOS developer turned professional, they may not have fully embraced the Objective-C way (no ill-will towards these groups, I came in with almost exclusive Java/Android experience when I started with Objective-C). There are always opinions when it comes to code formatting, design patterns, and naming conventions, but with iOS in many cases there is a recommended best practice that should be followed.

You might be thinking "so what if they do it their own way, so long as it works" (especially if you're just looking for a temporary contractor). Wrong! No matter how small you think your project will be, there are going to be changes to be made down the road. And who's going to read that code? It might be the original developer, or it might not. Use of conventions allows for easier readability and better maintainability, and will lower your switching costs if the original developer doesn't work out or decides to suddenly leave for another gig.

If you yourself have a good knowledge of iOS development, brush up on your Cocoa Coding Guidelines and ask for a code sample. Look at things like use of class prefixes, method names, constants, and categories. Ask the candidate about software design. Do they design their code for personal use, quick-and-dirty, never to be touched again, or do they design their code with reusability and efficiency in mind. One of the best signs of a modern programmer is that they design their code -- internal and external -- as if it were an externalizable service - taking a page of Amazon's book. A code sample can also be useful to see their design style and identify particular areas of focus (e.g. networking, UI, data persistence, animations, etc).

Online Reputation*

I put an asterisk next to this one because I think this might be the most debatable point. For me personally though, I give bonus points for active use of GitHub, StackOverflow, App.net, and Twitter (unless its to manage a Biebs fan handle). Open-source software is huge both in web and mobile. If the candidate is familiar with pulling code off GitHub (properly attributed of course), it could definitely come in handy in the future. Better still if the candidate has contributed to open-source projects or created one of their own.

Completely on the other side of the coin, I know several excellent developers who don't care much for social media or personal branding. It's no knock on them, it's just not in their interests. That's fine too, just be aware of it and make sure the candidate is a good cultural fit for your team. e.g. if you're launching a social network for chihuahuas and the candidate isn't active on Facebook, Twitter, or Instagram, it's probably not the best fit even if they are extremely smart.

Overall Tech Savviness

Lastly, and you've probably done this by now, Google search the person's name and see what turns up. In emails or an interview ask them what they like about programming, iOS, and technology. You know this, but design is HUGE in mobile app development. It should be a big deal to the interviewee. UI/UX will make or break your business, so make sure you value this appropriately. I love that in a mobile developer job posting for Alpine Replay, their "next steps" are simply:

  • "Send us an email. Please include some of your sample work, a collection of your favorite designs (not yours) and whatever else you feel may be applicable."

A savvy design enthusiast who's up on the latest trends and upcoming iOS 7.1 or iOS 8 features could help take your app's user experience to the next level.

Disclaimer

All the suggestions in this post are personal opinion. Any and all of it should be adjusted to fit your needs and your team's culture.

Five Word Tech Horrors

Got a kick out of this hashtag over the last 24 hours.

No, Apple didn't copy Android

I wanted to get this thought out about 2 months ago, but here it is now. Better late than never.

There's been a lot of talk around the interwebz about Apple knocking off Microsoft, Google, or __________ (fill in the blank) with the latest refresh of iOS. While it's easy to complain about how this or that already existed elsewhere, rather than pointing fingers and chalking everything up to someone copying someone else, to me the much more logical explanation is that Apple has simply updated its design to be more modern (as have others). To say that flat buttons belong to Android is somewhat naive, because certainly Windows Phone has been leading the way in flat UI when it comes to smartphone OSes over the last few years. Further, if you read into iOS 7 and get your hands on it you'll see that Apple did not simply flatten everything out.

In the developer keynote, Craig Federighi stated that the goals of iOS 7 included three overarching themes.

  1. Deference - The UI defers to the content. It's helpful and intuitive, but unassuming and out of the way. This is a big change from the skeuomorphic ways of the past.
  2. Clarity - Clean, precise UI as well as a major increase in accessibility support.
  3. Depth - This is where Apple has struck gold IMO. They were able to modernize the interface, yet kept a distinctly unique experience by focusing on depth and contextual awareness using blurs and realistic, physics-based animations.
The focus on these themes and the amount of detail included at each and every level of iOS 7 make it apparent how truly unique Apple's approach to a 2013 mobile OS is. And the best part, Apple didn't go sell their soul to the flat UI gods - it's still very much iOS. More at Designing for iOS 7.

No, Apple did not copy Android. Apple took their time in moving on from the iOS design of the old, but they did it in their own way. And if you look at it, all major platforms and companies have moved to simpler, cleaner UI over the past 2-3 years. It's not one company stealing another's idea, it's the major players realizing the direction of design trends and incorporating them how they see fit.

It took Apple two years longer than it should have in my opinion, but as usual they came through with a excellent product in iOS 7 and I highly recommend updating if you haven't already.

Why singletons are bad

Disclaimer: This isn't a total knock on singletons. Alternate title: "Why singletons can be bad".

Software Design

Yesterday I had a conversation about software design with an experienced colleague and found myself reaching when discussing design patterns. Specifically, we got onto the topic of the singleton pattern. 

Knowing from recent experience at Cocoa Camp that singletons are not the end all be all solution for object oriented programming (yes, I might have thought that at one point), I was careful not to sound overly enthusiastic that I used the singleton pattern. I  first learned about the singleton pattern an Android dev class that I took in Winter 2011 (at BYU). It sounded pretty cool then, and it was even a semi-significant part of the midterm. I later began learning Objective-C, and after using the pattern in a few iOS apps over the past year - including collaborative projects with other developers who hadn't ever mentioned any negatives in the singleton pattern - I had gradually assumed that they were a pretty solid way to go. Last month at Cocoa Camp the pattern came up and although we didn't get into any detailed discussions on it, I got the impression that singletons weren't as favorable as I had thought... 

Back to our conversation, I mentioned that I knew singletons had positives and negatives and explained a little more about why I'd used them in the past. He pried pried a little deeper, asking two questions that I want to expand on. "What are some of the downsides to the singleton pattern?" "What alternative design patterns would you suggest?" I mentioned a few things, including keeping the object in memory for the entire life of the application, rather than when specifically needed, and that an alternative method could be to pass the data between view controllers rather than via the shared singleton instance. Then we moved on.  Conversation over.

Why singletons are bad

Later (okay, ten minutes after the conversation ended), I found Steve Yegge's blog post, Singleton Considered Stupid:

Begin Quote 

Here's what most people got out of Design Patterns: "blah blah blah blah SINGLETON blah blah blah blah". I kid you not. I've seen this so many times that it's become a full-fledged pattern in its own right; patterns need a name, so let's call it the Simpleton Pattern.

The Simpleton Pattern unfolds like this:

Me: So! Have you ever heard of a book called Design Patterns?

Them: Oh, yeah, um, we had to, uh, study that back in my software engineering class. I use them all the time.

Me: Can you name any of the patterns they covered?

Them: I loved the Singleton pattern!

Me: OK. Were there any others?

Them: Uh, I think there was one called the Visitater.

Me: Oooh, that's right! The one that visits potatoes. I use it all the time. Next!!!

I actually use this as a weeder question now. If they claim expertise at Design Patterns, and they can ONLY name the Singleton pattern, then they will ONLY work at some other company.

End Quote

I really hope I didn't fall into this category in the mind of my colleague, but wow was I unprepared for those two questions. Especially the second question. There are few design patterns with a name as catchy as the singleton pattern. There certainly are other ways and methodologies to accomplish a programming objective, but what's the catchy name for instance classes, interfaces, and passing data between controllers?

I've done some more reading and in hopes of getting it right the next time, here are some of my thoughts.

What do you think are some of the downsides to the singleton pattern?

There are actually a ton. The reasoning is pretty straightforward and I don't know why I didn't think of these earlier.

  • A shared singleton class requires that memory be in use throughout the entire application, even when the object isn't needed.
  • Singletons hide dependencies!
  • As a result of these hidden dependencies you can lose track of the coupling. Instead of meticulously passing each object you need (and only the objects you need) into a function, you instead call [AppUser sharedAppUser] to access your shared instance. While it feels cleaner since it can mean less lines of code to get the access you need, you can end up with very tightly coupled code.
  • You can't (really) subclass a singleton
  • Singletons are hard to test! (1) With hidden coupling it's difficult to create mock objects and (2) singletons generally exist for the lifetime of the app which presents a problem for unit testing, as each unit test should run independently of other unit tests.
  • Just think of it as the "global-ton" pattern. The name isn't that far off. Does it still sound as sexy? 

There are some upsides too, but I'll save that for another time. 

What alternative design patterns would you suggest?

  • Object oriented programming. This isn't just a snarky answer. Use instance classes that are instantiated within the scope that they are needed and pass those objects between methods or controllers as necessary. 
  • Create the instance of your object only within the scope that is needed (be careful not to abuse the AppDelegate).
  • Use dependency injection to pass a single instance of the object to the components that need it (like your unit tests).

Takeaway

      Be smarter. Understand what is actually happening when you use the singleton pattern. As tempting as slapping in SynthesizeSingleton.h into an iOS project is (see http://www.cocoawithlove.com/2008/11/singletons-appdelegates-and-top-level.html), it is NOT the solution to all your problems. You may not need it at all. Tightly coupled code can be a major problem with singletons, and chances are you probably aren't unit testing (or not properly anything) whichever objects you've transformed into singletons ...which you should fix. Most of all, if you enjoy software design but can only list of the singleton pattern when trying to have an intelligent conversation about design patterns, you have homework to do.

      Sources / Related Material

      Xcode Shortcuts

      Wanted to create a collection of my favorite shortcuts for Xcode. Some of them are muscle memory, but there's many more that I'm not using yet that I wanted to list here, probably more to help me remember than for anything else.

      Xcode Navigation

      • cmd + shift + 2 - open organizer
      • cmd + option + return - show assistant editor
      • cmd + return - show standard editor (hide assistant editor) 
      • cmd + shift + o - quickly open or jump to a file
      • cmd + ctrl + up/down - switch between header and implementation file
      • cmd + ctrl + left/right - navigate to previous/next file
      • cmd + click - jump to method declaration
      • option + click - open quick documentation

      Inline

      • ctrl + spacebar (or escape) - show code completion suggestions
      • ctrl + a + k + k - delete line
      • cmd + ctrl + e - rename variable in scope
      • cmd + f - open find bar
      • cmd + option + f - open find & replace bar
      • cmd + e - copy selection to find bar (without copying to clipboard)
      • cmd + g - find next
      • cmd + shift + g - find previous
      • cmd + ] - indent
      • cmd + [ - outdent
      • cmd + / - comment/uncomment current line

      Also, just stumbled across this great info graphic created by Robert Saunders

       

      Trying out Android Studio

      logo.gif

      Note: this post assumes you have an existing knowledge of Android development, probably using Eclipse. 

      The first time you download Android Studio, before you head straight into creating or importing your first project, start by checking for updates. In my case I downloaded Android Studio 0.2.0 from the developer site, but 0.2.6 was available. Definitely update to the latest version!

      One of the big fundamental differences between Android Studio and Eclipse + ADT is that you will now be using Gradle for your build system rather than Ant. I'm no expert on build systems, but I do appreciate good build tools (like Rake) and hopefully Gradle. I've only done 20 minutes worth of Googling Ant vs Gradle, so feel free to do the same. Or, if you want just think of Gradle as a more flexible version of Ant with superior certificate signing and command line build tools. Also, its integration with Jenkins is solid, if CI is your sort thing.

      configuration.png

      With Android Studio updated and a little knowledge of Gradle under your belt, create a new Android project. (The new project wizard is so straight forward my mom could do it.) You'll notice that the project structure is mostly familiar in terms of java packages containing your source code and your res folder containing layout files and image assets. Good, right? One major difference, however, is that you no longer live within a workspace. Each Android Studio instance now belongs to its own project. I haven't gotten used to the multiple projects with dependencies workflow yet, but I trust it will be eons more logical than it is in Eclipse. Okay. now for another new feature look at the top bar towards your configurations (upper right). This is something new. Here you can setup build configurations with specific application/target combinations. It's an easy way to switch between multiple emulators and devices.

      Couple other things to point out in Android Studio. The undo functionality is really smart. In addition to all the things you would expect, it can undo file deletions, creations, and its memory is very impressive. Another small thing that makes you happy is that Android Studio will replace @string/label references with the actual string in manifest and layout files. Hover over it to see the code and click to access it. Another cool thing in layout files is that missing files or resources will show up as red! This is huge! For me anyway I would run the my app on the device and only then find out that I had typed in the image name incorrectly. This has the potential to be a major timesaver.

      Keyboard shortcuts rock. Far and away my favorite shortcut in Eclipse is cmd+D (or ctrl+D) to delete line. I miss it every day in Xcode. Here are a few tips and tricks I've discovered so far:

      • cmd+backspace - delete line (a little different, but I could get used to it)
      • cmd+d - duplicate line
      • cmd+o - quickly jump to any class in the project
      • cmd++ - fold code
      • cmd+- - expand code
      • ctrl+spacebar - code completion
      • ctrl+r - build and run (using last selected configuration)
      keyboardshortcuts.png

      It's not all peaches and cream though. Even with just a few hours under my belt, there are already a couple things that slowed me down which I'd like to see improved:

      • When adding a new activity, double click does not move to the next screen (currently you must to click next)
      • Also in the new activity wizard, changing the activity name does not automatically update the layout name (even eclipse did this!)
      • Creating a new activity defaults to a vanilla package (rather than the currently selected package)
      • Double clicking a "error: gradle: no resource found that matches [filename]" doesn't link to the place where the invalid resource is being referenced
      • The Android emulator hasn't changed a bit

      Android Studio is still not a perfect solution, but neither is Eclipse. Overall it feels like a solid start and if its progression is anything like the progression of Android (oh boy the dark days of Froyo), it's only going to improve significantly over the next couple years.

      Growing Pains is Making a Comeback

      If you know me personally, you probably knew that I worked on an app called Growing Pains for last year's BYU Mobile App Competition. It's a photo journal designed to help you easily capture photos of your growing child. The interface is designed to allow you to quickly browse through and see your child's growth over various time periods (ideal for newborns and toddlers -- or puppies). While Growing Pains was a success in the competition, winning over $2000 value in awards and placing 5th overall, unfortunately it has not yet seen the light of day.

      A partner on the project and I have been talking recently about bringing it back to life, and last week while at Cocoa Camp Apple challenged us to bring our own ideas to work on, so I did just that. On Monday of last week I ctrl+shift+N'ed a new project in Xcode and started clean. Did this for several reasons, firstly, because Cocoa Touch changes so much from year to year that I'm sure our existing code base would require some amount of updating to get in line with the latest conventions and best practices. Secondly, and the bigger reason, is that while SDK changes have been semi-significant, changes to iOS design patterns have been EXTREMELY significant. Take the example below.

      You've probably seen and heard all about iOS 7, so I'll save my personal thoughts on the change for another discussion, the important points to note are the focus on simplicity, utility, and depth. With the greater population generally familiar with smartphones, as an app designer & developer I can now eliminate the use of some of the more cutesy effects that previously communicated "tap here", "I am a menu", "this is a button", and so on. Apple has also stressed depth in the new design, despite it looking more flat than before. By adding blurs, realistic motion effects, and new levels of perspective, iOS 7 is inherently more realistic than before, albeit far less skeuomorphic.

      Growing Pains is now undergoing its own transformation from the old world to the new. Here are a few of the design concepts for the new UI, shown alongside the original designs. Please feel free to jump in if you have any thoughts or suggestions. These designs are being iterated on almost daily at this point.

       

      What do you think? Are there any elements of the old design that you like better, or feel are missing in the new versions? Is it any more or less intuitive than before?

      Maybe Microsoft is doing it right. Or maybe they're not.

      Dell Venue Pro, running Windows Phone 7.5

      Since I first began seeing concepts of Windows 8 I kept thinking, huh, maybe Microsoft is onto something here. Despite being both an Android and an iOS fanatic, I have been impressed with the Windows Phone OS since trying out Windows Phone 7.5 from Dec 2011 - March 2012 on an extra Dell Venue Pro my dad had available. The hardware was...a brick... to put it nicely, but the OS itself was excellent. 

      Over the last 18 months I've found myself continuously (and to my friends' amusement) defending Windows Phone as a viable mobile operating system, and, as an extension, defending Windows 8. I've gushed over the Lumia 920, HTC 8X, and now the Lumia 1020. I almost bought all three of these devices on numerous occasions (just ask Dru). While I maintain that Windows Phone is a great OS, I'm coming to terms with the idea that maybe Microsoft isn't doing it right and that they did in fact jump the gun on the idea of the convergence of the desktop and the mobile experience. Since MS's release of Windows 8 there's been talks of how revolutionary and visionary it is. Ahead of its time. Some referred to it as showing that Microsoft had not only caught up to Apple and Google, but far surpassed their ability to deliver innovative products that end users didn't even know they wanted until they tried it (take the iPad for example).

      Well, after a year of saying to myself, yeah, maybe they did get it right, maybe Windows 8 isn't as radical as all the critics say, maybe we will all be using touchscreen desktop computers in a couple years, I'm now saying maybe not

      The truth is that the people don't want the same experience on a tablet as they have on their desktop or laptop. Sure, they like familiarity, but at the core a user's interaction with a tablet and user's interaction with a desktop computer is just different. And people are fine with that. The design of an application on the desktop environment is (and should be) vastly different than the tablet and the phone representations of that same application. Probably one of the best examples of this is the Day One app for iPhone, iPad, and Mac. Ask any active Day One user if they'd like to combine either the iPhone and iPad experience or the iPad and Mac and they'd look at you like you were crazy.

      Day One for iPhone, iPad, and Mac

      Further evidence that people just don't want to merge desktop computing and mobile computing... look at this Acer commercial comparing their 8" Windows tablet to the iPad mini. This is my opinion, and I bet some Windows 8 fans view this commercial as a win for Acer and Windows 8 Pro, but firstly, who wants to play Halo on a tablet (not that they even look like they're actually playing...)? Don't get me wrong, I love iPad games... Plants vs. Zombies vasebreaker endless mode... that'll keep me busy for HOURS. But I don't really care for the idea of getting a dumbed down PC gaming experience on my iPad. Maybe if the entire game was reimagined for iPad, and it really was just a distant relative of Halo, but the ability to run full-fledged PC games on a tablet just doesn't do much for me. Okay, next flaw in the video, of all the things you can do on a tablet, why show someone accepting changes to a Word doc? I mean, seriously, of all the things I've used a tablet for (thinking my Kindle Fire, Nexus 7, and iPad), I have never once wanted to accept changes to a reviewed Word doc. And if I did, I wouldn't want to be using the traditional Word app to do it (see all those tiny touchpoints?!).

      UPDATE: I hadn't done my research on Halo Spartan Assault, and it looks like it very much is  the Halo experience reimagined for touch. That's cool. What I was trying to get at is the idea of playing traditional PC games on a tablet running Windows 8 Pro.

      What I'm getting at (and have probably repeated 20 times by now) is that I no longer believe that we are heading in the direction of an integrated desktop and mobile computing environment. Those who never got on the Windows 8 bandwagon are probably thinking, yeah, knew that all along. But for those who have seriously entertained the idea of everything converging into a single, universal experience, either the timing is wrong or the implementation is wrong. Either way, maybe Microsoft isn't doing it right after all.

      Configuring Xcode and Bamboo CI Server

      NOTE: This document was written with respect to Bamboo 4.4 and version 1.8 of the Xcode plugin. I'll update it to Bamboo 5 and v 2.1 soon.

      Here's the process, from top to bottom, including my little discoveries along the way.

      Install the Bamboo iOS, Cocoa and Xcode plugin

      • First off, note that Bamboo has its own marketplace (as opposed to one for your JIRA instance). In order to do this, you need to be an administrator in Bamboo (but not JIRA).
      • Navigate to Administration -> Plugins -> Find New Add-ons. Search Xcode and install the plugin. No additional configuration or plugin management needed here. This simply enables a few features like support for adding the iOS SDKs and Xcode tasks, which you'll get to later.

      Creating a remote agent in Bamboo

      • From the Administration tab, go to Agents and select install remote agent. You can install it wherever you'd like... I wouldn't recommend your downloads folder though. I put mine in /Documents/dev/bamboo-agent-home.
      • If you have problems running your remote agent to the tune "Could not load properties", you may need to explicitly set your port number or open a port on your firewall. This Atlassian Support Q&A was helpful for addressing this issue.
      • For more information see the Remote Agent Installation Guide.

      Configuring Capabilities for your Remote Agent

      • Agents use capabilities for two purposes, (1) to tell the agent what it can do, and (2) in order for jobs to identify which agents can run which build plans.
      • Regarding point 1, you will now create two capabilities that will allow you to build you project for iPhone and for the simulator.
        • From the Agents screen, select your remote agent
        • Select Add Capability
        • Select Xcode SDK as the compatability type
        • Enter Simulator - iOS 6.1 as the SDK Name
        • Enter iphonesimulator6.1 as the SDK Label. ****This part is what took so much time to figure out. In a couple of the blog posts out there it recommends using the command 

      • Regarding point 2, this is important because if you don't specify capabilities, your build plans will try to run on all agent that meet their basic requirements. In our case, our web team's build plan's requirements weren't set to the appropriate capabilities, so whenever a build occurred and the OSX remote agent was running, it would try to run on both agents, causing it to fail immediately on our remote agent. Note that custom capabilities are often used to control which jobs will be built by which agents, the most common one I've seen being an isLocal flag, which only allows the local agent to run the build plan.
      • For more information see Agents and capabilities.

      Connecting to your GIT repository

      • After you have configured your remote agent, create your plan. This part is fairly straightforward, which the exception of connecting to your GIT repo, which can be tricky.
      • In our case, a user named 'fisheye' has already been setup with the appropriate permissions and keys on neptune. Unless something has changed, don't worry about generating new ssh keys for yourself and putting them up on neptune. Have Jacob login and upload the private key for this user.
      • Note that the repository URL should include ".git" at the end, i.e. ssh://fisheye@neptune.communitect.com/home/git/onedesk.git

      Creating Tasks for Your Build Plan

      • Task 1 - Source Code Checkout
        • The first task you'll want to create is Source Code Checkout. Actually, it was probably done automatically. Make sure the repository is set to your project and run your build plan. You should be green.
        • At this point, if you run into a NoClassDefFound error, check out this support Q&A. Basically, the fix is to downgrade your Xcode plugin to v1.8 and try again. You can download it at the link at the top of this post. To install it, within Bamboo go to Administration -> Plugins -> Manage Add-ons -> Upload Add-on. My guess is that the latest version of the plugin targets Bamboo 5.0 and at the time of this posting we are running Bamboo 4.4.4. The plugin says it supports 4.4... but yeah...no dice.
      • Task 2 - Build the Xcode project
        • Next up we want to create a task to build the Xcode project. This is where those iOS SDK capabilities that we setup earlier come back into play. The first thing to keep in mind here is that essentially all this task will do is build your project, the same way you would if you built it from terminal using xcodebuild, e.g. xcodebuild -sdk iphonesimulator6.1 -project PRTablet.xcodeproj -alltargets -configuration Release. 
        • My personal suggestion here is to forget Bamboo for a minute and try building your project from the command line. In our case, command line builds failed with compile errors because the main PRTablet target can't see the RestKit subproject files (despite it building correctly in Xcode). To get around this, you'll want to setup a workspace and scheme rather than an xcodeproj and target, which will build all projects in the same directory, referred to as the workspace build directory. Now, all of these files are visible to each project. Verify it now builds successfully from the command line, e.g. xcodebuild -sdk iphonesimulator6.1 -workspace PRTablet.xcworkspace -scheme PRTablet -configuration Release.
        • Now that you know it will build successfully, create a second task under your build plan. Select Add Task -> Xcode. When you're done, it should look something like below.
        • Save and run your build plan. If you got a "possible compilation error" check the logs. If it's an xcodebuild error: "The workspace does not contain a scheme named," you need to go back into your workspace, go to Manage Schemes... and check the Shared box next to your scheme. Push your code and run your build plan again (Bamboo may even do it automatically this time). You should now be green.
      Screen Shot 2013-07-26 at 6.27.42 PM.png
      • Task 2.5 - Unit Tests
        • To run have your agent execute your unit tests, you'll need to check the "Include OCUnit Test results" box above. See the Xcode docmentation. Note: I've been unable to get this working so far, since Bamboo for some reason is unable to see our unit tests. The error message reads "Failing task since test cases were expected but none were found." I found a support Q&A for this problem and added comment asking if anyone has found the fix.
        • UPDATE: Looks like unit tests with a test host cannot be run in the simulator in v1.8 of the app. If you can, upgrade to v2.1. In versions 2.0+ of the plugin, you can use the ios-sim method to run application tests from the command line.