The void

Every time a new version of iOS has been announced there is always what feels like a void of any actual activity. It doesn't make sense to put out any app updates because there are such big changes coming soon. My time is better used to keep downloading the Xcode and iOS builds to get my mind in the game and watching / reading all the new stuff from WWDC.  

It feels like we were just getting comfortable with iOS6 and now iOS7 with it's completely different way of thinking has been thrust upon us.  It's a good thing, change is good, it stops us developers from getting completely burnt out.

So what are my priorities for iOS7? 

  1. Notography - This app has received a great response, I have a lot of new features and a whole new design ready for iOS7, it's going to be great!
  2. Defects Collector - I have been wanting to release an update for this for ages! iOS7 will be that time. 
  3. Wicked Freefall! - I really want to make big improvements to this app. May even start from scratch and re-imagine it... i still find it fun but it needs more and it needs modern objective C
  4. Evil Block Company - Not much needs to change, minor improvements. 
  5. ManaSlam - I'd love to re-release this game, my original iOS title that deserves love. 

Early testing of iOS7 have shown positive results and possibilities to improve products. Can't wait to share with you all what I have been working on. 

Why developers should start caring about AutoLayout

WWDC this year gave the impression that Apple really wanted to push developers to start building apps with auto-layout. Historically auto-layout has been kind of difficult to use which lead to people hard coding their layout constraints or having fairly static UIs. In iOS7 there have been a lot of improvements which makes auto-layout a lot more appealing. Why should we use it though? 

Apple don't push a particular technology unless they plan for it to be used. We've already heard rumors of a larger screen iPhone later this year and while we all thought it would be up-scaled, it feels now a lot more like it will be expecting apps to have used a responsive design.

It wouldn't surprise me if all apps which don't have auto-layout properly configured will be automatically disabled for download on this device until the issue is resolved. This may seem crazy in the apple environment but it would definitely force developers to start designing their apps for auto-layout.

There are a lot of ways this can go but one thing is for sure, auto-layout deserves a second look if you had previously given up on it.

What does the introduction of MFi game controllers mean for developers?

Another WWDC and another swag of great feature and framework updates for iOS and Mac OSX. The introduction of Sprite Kit and update of Game Center is a much needed step in the right direction for producing more and better games on iOS but one feature that really interests me is the introduction of MFi game controllers. 

In the past if developers wanted to be able to support controllers on their iOS games they would have had to use 3rd party bluetooth controller which pretty much just emulated a keyboard being attached. This wasn't bad but it also wasn't overly popular and had limited use. The iCade was a popular devices along with the iControlPad, there was even an app so you could use a second iOS device as a controller called Joypad. All of these systems were fairly easy to implement, the problem is though not many developers did, instead opting to focus on the built in tools like accelerometer and on screen controls. 

So the introduction of controllers that are easy to implement to a consistant standard is a pretty cool thing. What do developers have to think about though?


Very soon when kids go to their apple stores or local electronics store they will start seeing some very interesting controllers on display, there might even be demo units out for kids to have a play on. They will probably sell reasonably well and in the short term if there are only a handful of games which support these controllers then you have a huge opportunity to boost sales of your apps. 

It's also an opportunity to do things differently, there has always been a gap between games based on consoles and those based on touch devices due to the difference in controls. This is no longer such an issue. 

People don't remember all the products that do great things, only the ones that do them first. 


Gameloft also released a controller once for use with their games, it's sales were pitiful but that may just be because it only worked on a very small selection of their games. One thing that really stood out on their first person shooters though was that it was much easier to aim at something with a controller than with the touch screen, just like it is easier to drive a car with a controller than an accelerometer. 

There is a huge balance risk here as the control scheme could potentially change the difficulty of the game quite heavily and reaching a mid point is hard work. In a first person shooter you may have to have higher aiming assists and racing games may need more powerful driving assists, etc. You also run in to the problem that the Wii had with Mario Cart by designing it to work with those annoying plastic wheels, the game became so simplified that it just wasn't fun to play with a controller, there was no depth and nothing exciting about driving.

Reaching a midpoint where both playing with the device or with a controller feels equal will be the hardest thing developers need to deal with.

Hybrid Controls

One idea Apple seemed keen to push was using the controller for some things but then using the screen or accelerometer when it makes sense to. The case controllers that keep the device in the centre could make use of this fairly well. 

To me, it seems like something worth exploring. That same theory is what made the Nintendo DS a very popular console before the rise of iOS gaming, so it is definitely an area worth exploring. I'm sure finding a new and exciting hybrid control scheme would be a great way to get featured by Apple. 

The challenge here is supporting gameplay when a controller isn't actually connected, you need to be able to design it in a way so that the two control elements don't get too jumbled when you are just playing on the single screen. 

Don't forget the screen!

While controllers are cool, not everyone will use one and not everyone who uses one will take a controller everywhere they go. You should still offer the alternative of onscreen controls or similar and unless you specify your app is controller only fairly clearly and have good reason for it, your app would probably be rejected. 


Imagine you have a computer or iDevice with an Apple TV and controller in the house, you can pretty much emulate a console experience! Playing the game live on TV with your controller while the computer or iDevice handles the game like a console.

Optimising your game to run over airplay could extend sessions of play quite significantly, don't believe me? Try comparing the average play time of a kid sitting in front of a TV playing a game to that of a kid sitting in their bedroom on an iDevice. More play time means more iADs presented, more in-app purchases bought and more feedback on your product.

Cool! So how do I get started? 

If you are a registered developer you can get started right now, the only issue you will have is that you will have a small testing window to see if it is all working. The first controllers come out in fall around the same time as iOS7. 

One final thought... 

If you can now share the same achievements and leader boards over both OSX and iOS and share game data and state information via iCloud between OSX and iOS AND use the same controller for both OSX and iOS AND use Sprite Kit to developer games that will work with the same code on both OSX and iOS.... doesn't it seem like the era of true mobile gaming has begun where you can start, stop and pick up your game / match from where ever you are and whatever device you are on? The first game to take TRUE advantage of the opportunities Apple have provided, will be pretty damn awesome!


When and why developers should use iCloud

There has been a lot of discussions over the past months about the quality of the iCloud service for syncing and storing data between multiple devices, a lot of these discussions seem to have come from a post about why developers should never use iCloud, while some of their points were valid I now want to tell you what I tell anyone trying to make these sort of decisions.

You don't always need to lock yourself in to doing something just one way, especially when services can run side by side without incident and without dependence.

I will admit, iCloud has both issues and limitations but it also has great strengths which other services cannot provide. The strongest of which is the absence of a login screen to access your data, there is nothing more damaging to apps than providing a login screen to the user prior to proving the app itself is worth it's time in gold to the user. Since you require an apple account to be logged in to be able to download any apps, it can be assumed you will most likely be logged in when using the app.

There are other advantages such as it being free to use and the API isn't entirely horrible and seems to handle the key value store and documents reasonably well even if the core data functionality needs a little work. The point is though that it is perfectly functional in some capacity. So how can you make the most of these strengths?

It is important to have your own data service, you want your product to be fully scalable and able to be rolled out on multiple platforms, that is a good thing, all developers should want this option. What you could do though is store a unique account key in the key value store on a users iCloud account as well.

What would this allow you to do? Well, it means your users could potentially log in once on an iOS device and then never log in again across all of their devices. While this mechanism only really works on iOS there is some value in it as more and more people have both an iPhone and iPad in their lives.

The other advantage is you can delegate certain data storing and syncing to be handled by iCloud to lower the stress and bandwidth usage on your own servers. This would have to be non-essential to non-iOS devices of course but leaves you some breathing room. Maybe you have certain settings and parameters which only apply to iOS and don't need to be stored on the same data system as your website.

iCloud isn't the knight in shinning armour we want it to be and most likely never will be but it can still be used to produce better products. Shunning it entirely just closes a door and avenue to improve your product.