Swipe Conference Of the many excellent sessions at this week's Swipe Conference, the one titled "Build Better Cocoa Apps Using Game Mechanics" by Paris Buttfield-Addison was unique in its topic. In it, Paris outlined how gamification is currently viewed as something that can be quickly slapped onto an existing product in order to increase its appeal, whereas in reality, successful gamification requires carefully thought-out integration, for when done correctly it should form a core part of your app's user experience.
We’ve all heard developers say it: “I’m a terrible drawer” or “I’ve got no design skills”. Perhaps we’re even guilty of saying it ourselves - I know I am. But after attending this year’s Swipe Conference I now subscribe to the opinion that this is no longer acceptable. We are all responsible for the design of the app we are building; developer, designer, tester, or producer: every member of the team is accountable for helping shape the app’s design and interactions.
Yesterday was the last day of Swipe Conference so I thought I would take this time to reiterate one of the points I took from the first presentation by Josh Clark.  Josh covered quite a few topics and if you haven't already you should check out his book Tapworthy: Designing Great iPhone Apps. In short:
  • Gestures can be brilliant … if the context they are used in feels natural
  • If you're using gestures make sure your users will find them
  • If you don't think your users will figure out your gestures easily, don't overload your users with lots of help hints all at once; instead, let them "unlock" them over time, like a reward for using your app
  • Downside though is that there is no consensus on what a 3 finger swipe gesture might do. Every iOS app that uses this gestures decides it for themselves.
It was obvious from the way Josh presents that he has so much passion for touch / gesture based devices. What I personally took away from his presentation was that gestures can be awesome shortcuts within your app. In a lot of cases gestures are a natural progression with how we interact with real world items.
When I first started learning Objective-C and the iOS SDK 2.x a few years ago, one thing that I constantly struggled to get my head around was Interface Builder.  More specifically, why should I use it and how it could possibly benefit my iOS development - given that I could code a UI programmatically, and know exactly how it all worked? A colleague of mine even wrote a blog entry that mirrored my exact feelings towards Interface Builder back then. Well over the past 6-12 months my attitude towards Interface Builder has changed. There are two reasons for this. Firstly, it's now nicely integrated into XCode 4. Prior to that, who wanted to have 2 different apps running (XCode and Interface Builder) with popup windows spamming your desktop? That was a deal-breaker for me. Secondly, I'm now a more experienced developer. After using Interface Builder on a couple of projects, I am confident to say I am now more efficient as a developer when using Interface Builder. However, that wasn't always the case, which leads me to my key message here:
If you're new to iOS development, don't touch Interface Builder until you are capable of building UIs programatically.
Recently we released an iPhone app to the iTunes appstore which contains consumable products that can be purchased by a user.  I want to share with you some of the pain we encountered when the app went live, and what errors we came across when configuring our server from sandbox to production.
Perhaps the most indispensable tool when developing iOS applications is the iOS simulator. However, if you want to test an app whose functionality revolves around utilizing the device's GPS, then you're out of luck - Apple's iOS simulator will only provide you with a single location (the location of Apple's headquarters). Furthermore, whilst the next version of XCode promises some progress in this area, it's still not clear if/how it'll be able to recorded data for later playback. In this entry I'm going to detail the process we followed to create a small location simulation framework that can also record data.
A common problem that we often experience when developing iOS applications, is how to allow communication between our controllers, without the need to have excessive coupling. Three common patterns that appear time and time again throughout iOS applications include:
  1. Delegation
  2. Notifications through Notification Center, and
  3. Key value observing
So why do we need these patterns and when should and shouldn't they be used?