Growth is on the Horizon

It's been almost one full year since I last made a post on this website.

It has been one hell of a busy year with the success of my iOS / OSX game development course and also being a co-author of the amazing iOS / tvOS games by tutorials book.

Right now, my focus is bringing more structured updates to existing content and more frequent release of new content, including this blog. Expect a whole heap of new video courses and a website revamp over the following weeks.

Stay tuned for content and as always I look forward to your feedback!

Would you like to make a game?

I wanted to give you a heads up on my latest project, I've watched a lot of video tutorials (in fact, it's my favourite way to learn something new) and I've been somewhat disappointed in the quality of the content and the presentation value.

It's easy to make a simple prototype app to teach people, you can do that within a days work, it's lazy but people still love it because they've never come to expect better.

I don't just want to teach people how to write abstract code, I want to teach people how to build full featured products using best practice coding principles. So 4 months ago I set out on the journey of creating a SpriteKit course that includes everything I wanted to know when I started working with SpriteKit over a year ago.

This course helps you at every step in the process to become a great game developer, it's currently at half price so get it quick. I hope you enjoy and please leave feedback. I'm happy to update the course as needed.

Just as a quick heads up, if you can wait this course will soon be available on the CartoonSmart subscription platform. This means you wouldn't just get access to this course, you would have access to many great courses!

"So I want to start iOS Development... what language should I choose?"

This is quite possibly the most common question i've seen in the months since the announcement of Swift. New developers used to have to endure Objective-C through to competency but now there is choice. So which choice is the right one? Objective-C or Swift?

What they say

The internet as a whole have very strong opinions on this subject, what I find interesting is that most people will still recommend that you start with Objective-C before learning Swift. Their reasoning seems mostly centred around "You learn the roots of iOS development and there are more resources available", I'm not sure I buy that argument at all though.

Objective-C may have more tutorials etc from previous iOS versions but when you look for iOS8 tutorials or guides almost all of them are written in Swift, even big iOS training blogs and companies have abandoned all Objective-C based courses to focus entirely on Swift. The Swift information available is quickly growing, it's rare that StackOverflow doesn't have a solution to a problem already and the rate at which resources are getting pumped out is incredible.

The other common argument is "It doesn't matter which language you choose, it's the frameworks that take most of the time to learn and what you learn is interchangeable". I do agree with this statement to an extent. It's important to focus on what you want to create and the language is really just what is best to perform the task, make decisions based on your objectives. That does make the language important when there is a clear winner regardless of the type of app.

What I Say

I've been using Objective-C for years and it's always been a love / hate relationship. There are things it does really well and a handful of big stumbling points but overall it felt good to work with. If I was to start iOS development today without any prior knowledge of the environment, I would definitely have to pick Swift though for the following reasons:

  • Resources and Training : As mentioned above, there is an amazing amount of resources available already on Swift and on iOS8 specifically there is more Swift content than Objective-C.
  • Ease of Learning : Another common myth spread over the internet is that both languages are equally difficult to learn. I disagree, each language has complexities but Objective-C is complex due to years of legacy design issues which come from building a language on top of an existing language. Simple things such as declaring variables can be done so many ways and have so many implications on memory management. Swift is logical and structured which makes even complex concepts much easier to learn than illogical problems based on legacy issues. Features such as the Swift Playground also make it really easy to prototype ideas and learn code quicker.
  • Robustness and Safety : You've seen the slides comparing speed and resource management before, I don't need to repeat them but it's definitely a strong consideration. If you could shave seconds off of loading screens at the point of initial design of your app, wouldn't you?
  • Time Management : Aside from most likely being able to get up and running faster you should also be able to develop faster with less wordy syntax and more optimised ways to code.
  • Potential to Grow : Objective-C is really at the ceiling of it's potential, would you really want to sink your time in to learning something which won't have the new powerful languages features the other language will have in one or two WWDCs time?
  • Eventually the String will be Cut : As it is, you can learn any framework in both Objective-C and Swift, how long do you think it will be before a new and powerful framework becomes available which is only in Swift? For all we know right now WatchKit may be Swift only. This may sound radical but the last thing Apple would want is resource hungry apps on this minimal resource device, by using a more compact and type safe language they can enforce a certain level of quality which they couldn't previously.
  • Stability : As of writing this Xcode is still going through some growing pains as it adapts for the future. Both Objective-C and Swift are at a point where they are fairly stable though, while at the beginning Objective-C was the clear winner that is no longer the case.
  • Apple Care about Training : Objective-C was always very hardcore developer focused which meant the learning curve was steep. With Swift Apple were quick to create easy to digest manuals and even keep a blog where they have started adding video tutorials.
  • Future Intension : If you are planning to learn Objective-C first then moving to Swift then this won't be an easy transition. As found by a lot of developers converting apps from Objective-C to Swift, if you do a straight conversion you're going to have a bad app. You need to have a good understanding on Swift paradigms and design patterns in order to write good apps in Swift. Knowing Objective-C is actually a disadvantage when it comes to writing good Swift.

What reasons should you be cautious about Swift for though?

  • Rapid Development : Depending on your personality this might be a pro or a con, Swift is young and not quite at maturity, it's likely parts of the language will continue to change and new features will be added fairly frequently. With Objective-C no major changes happened between major versions of iOS but with Swift it's likely to change a lot. If you can keep up, this might not be a bad thing.
  • Legacy Software : All the above points are null and void if you are planning to be hired or have been hired by a company that want to maintain a pre-iOS8 app make in Objective-C or an Objective-C library.

Why not learn both?

As suggested above there are different design patterns and paradigms in place in both languages and investing time in learning both may lead to a difficult and confusing learning curve which in the end will leave you a jack of all trades but master of none.

If you are an existing iOS developer then it makes sense to keep up on development in Objective-C and keep using it to stay sharp. Objective-C developer jobs are likely to be around for a while as legacy apps are updated, there are millions of them out there and not all will adopt new technology.

Final Thought

Don't lose sight of the big picture, the product is the important part but I honestly believe moving in to the future that Swift will be the better engine to ensure the longevity of your product and help it grow technically.

The longer existing developers wait to embrace Swift, the further behind they will be when the inevitable forced transition occurs (forced via required features not via Apple). I look forward to seeing how the language develops over the next few years, you can jumpstart your Swift immersion by subscribing to my newsletter at

Respect your customers

I've watched and read heaps of AppStore marketing and monetization reports and guides and each and every time I can't help but feel like I've witnessed something icky. I always get the impression that marketing gurus always consider every customer to be a mindless sheep or even a cashed up sheep which doesn't understand what they want and must be told or convinced.

I don't like the way software marketers, monetisers think.

My process for marketing is simple, find a deficiency is the software market, research that deficiency to find out why it hasn't been filled. If it makes sense to make a product then start work, talk to your target audience and see what they think of your idea. Work closely with a few individuals in the field, get their feedback and ideas regularly and make a great product.

When it comes to marketing and monetization, I come up with a pricing model that seems fair, covering expenses and ongoing costs. The very thought of jamming the app full of advertising and dummy in-app purchases in order to induce a decoy effect upon my customers just makes me feel ill.

As developers, we need to make money, we need to get paid. I'd much rather treat every client and customer like an intelligent person who wants an intuitive product with no annoyance or cash grabbing.

The underlying issue i have is respect. As a consumer I'd hope the company I have engaged with respects me enough not to shove annoying pop-ups and marketing propaganda in front of me and instead just tells me the raw facts. I'd also hope they respect me enough not to try and fool me or take advantage of me.

It gets especially frustrating when you receive a marketing call and the person on the phone is almost angry at you because you were unconvinced by their marketing ploy or you just didn't want their product. I'm sure they have to meet a quota of sheep they've managed to manipulate in to their flock but that's not my problem.

What would I love to see?

More companies like the creators of, domain management has been a playground for bad companies for years and hover have elegantly brought out a website with no horrible upselling on additional features, they just include them at no charge.

If your company is built on honesty and respect, you won't need to do marketing, your product and service will do that for you.

If you feed seagulls, they will always come back looking for food.

The above quote is the downside, you can have great products, you can have an honorable and respectable business that respect their customers but in the end people will still spend good money on software developed by people who just want to make money any way possible with no remorse.

So do the world a favor, share great products, ignore the rest. It's a small movement but many small movements can be more powerful than any big one.

Top mistakes made by indie developers

For most businesses there is often a wealth of knowledge and constants out there to outline exactly what resources you need to achieve certain business goals. When someone choses to become an indie developer, they often don't have a detailed business model in front of them nor have done sufficient research to make great business decisions, in fact most don't change a thing in their work pattern form when they were just learning.

So what should a coder, designer, artist or all-rounder consider before going from enthusiast to full blown indie developer?

  1. Plan projects based on your restraints and abilities - We often plan projects based on the desired outcomes we would like but this isn't always realistic. As an indie developer you need to consider the amount of time you have to commit to each project, your skill and how much that will slow you down or prohibit you from succeeding and the impact these restraints have on the game.

    A great example of this is "Flappy Bird", the developer said he didn't have a lot of time so he had to make a small, short, simple game. He also said he didn't have time to keep adding content so the way this impacted the game was he had to make it really difficult to generate longevity for the limited amount of content.
  2. Set deadlines and milestone targets - If you were working in a big business you would have set timelines for all your projects and not meeting a timeline would have a negative effect on the business. It's easy as an indie to say "I have no real need to get it out by any specific date" or "It's done when it's done" but the impact can be big. You could be reducing your productivity by over 50% by not committing to a timeline. It also comes with other benefits such as knowing when you have to have the dialog ready to give to translators in order to get them back in time for release, plus producing localised marketing material. Reviewers will take you a lot more seriously if you can give them a date and you actually meet that date.
  3. Plan your monetisation strategy from day one - Research business models and marketing strategies well enough to have a good plan to move forward with. Make a quick list of your products and services you can offer then start putting rough numbers next to them of how many you think you can sell based on marketing demand and do a quick calculation of your annual income. If it isn't what you expect to be making then rethink your strategy.
  4. Plan to make money - In addition to the above, i know it is nice to give away software for free and get feedback but if you plan to have a business then eventually that business should be making money. Think of it this way, if you make enough money that you can quite your day job then you can spend more time making software and updating it and make your customers more happy. It's better for everyone if you are running a profitable business!
  5. Be realistic - Rovio made over 50 games before they produced "Angry Birds", if you expect to get it right in the first year you will probably be very disappointed. If you expect to be rolling in cash in 2 years then (if you are good) you might be earning enough to get more equipment / software and produce better products but I wouldn't quit your day job. We are all learning, even the people who know everything about coding are learning, even the people who write programming languages cannot comprehend all the things it can be used for. Be patient. 
  6. Be proud of your accomplishments - This tip is just from me, if you love what you do and love what you create, that love is often infectious and the community will get behind you and help support your products. You should also support your peers in the same way, some of the best developer friends I have are just people I've cold messaged saying "Hey, I tried your app you advertised on <forum name>, I really liked what you created because of <A B C D> and think you can improve on <E F G> but otherwise it was a great experience and I left you a review". People really appreciate community support and will most likely look at your apps and do the same for you.

Hope you find these comments helpful and as always leave a comment if you have anything you think I should add. I'd love to hear from you!

Create a scene helper class for iOS / Mac cross platform SpriteKit games

There was a lot of interest in my post giving a few vague suggestions for converting a sprite kit game from iOS to Mac. Since then I've refined my methods a bit and now work with a project which is targeted for both iOS and Mac to make it even easier to implement and test.

Even if you never plan to release your game on Mac OS X, the below is still useful. The iOS simulator is painful at times however running SpriteKit natively on the Mac is simply beautiful, it makes testing a lot more fun.

Getting Started

The first thing you need to do is make a project containing both a target for iOS and for Mac OS.

  1. Create a new Xcode project
  2. Select "Sprite Kit Game" from the iOS templates
  3. Give it a name
  4. Go to "File", "New", "Target..."
  5. Select "Sprite Kit Game" from the Mac templates

You now have a template containing both two targets. If you are familiar with both Mac and iOS development it shouldn't take you too long to work out what is going on here. Have a look at your schemes and project settings.

I like to arrange my folders so that my Mac only code is in a "Mac" folder, the iOS only code is in a "iOS" folder and the shared game is in a "Shared" folder.

You can control which target has access to which game files via the "Target Membership" settings in the file inspector on the right.

Platform specific code

In iOS you are probably familiar with performing different code specific you wether you are running the application on an iPhone or iPad. You will run in to the same problems when coding for both Mac and iOS.

There are a lot of differences in the way you code between both platforms, even which classes you are using, so in most cases a standard IF statement won't be enough and you will need pre-processor #IF statements.



There is also a TARGET_OS_MAC but you will probably find that iOS devices respond to this as well, so it is a lot easier to just check !TARGET_OS_IPHONE.

It's a different world

Before going any further it is worth noting that you are working in two different worlds governed by two different HIG documents. What you know in iOS may not apply to Mac development. 

You are also working with a touch screen device without keyboard and a mouse and keyboard operated device. This is a simple fact but it will show in your game if you don't pay attention to it. I had an app rejected at review once for the reason my start screen said "Tap anywhere to begin" instead of "Click", a rather embarrassing mistake but one I make sure to prepare better for now.

Ok, enough of the lecture, you all want the helper class right?

A scene helper class to get you started

This is a very simple class but I want you guys to take it and add your own code to it. If your game uses a onscreen DPAD on iOS then it makes no sense do the same on Mac, you would need to monitor key presses instead.

This class helps for all other cases, it allows you to single methods for handling both screen clicks and screen taps. Great for games where screen presses translate easily in to screen clicks.

Create a class called SKMScene that inherits from SKScene.

Put the below in SKMScene.h:

// Created by Neil North on 6/02/2014.
// Copyright (c) 2014 Neil North. All rights reserved.


@interface SKMScene : SKScene

//Screen Interactions


And the below in the SKMScene.m file:

// Created by Neil North on 6/02/2014.
// Copyright (c) 2014 Neil North. All rights reserved.

#import “SKMScene.h”

@implementation SKMScene

-(id)initWithSize:(CGSize)size {
if (self = [super initWithSize:size]) {
/* Setup your scene here */
/* Overridden by Subclass */

return self;

-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
UITouch *touch = [touches anyObject];
CGPoint positionInScene = [touch locationInNode:self];
[self screenInteractionStartedAtLocation:positionInScene];

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
UITouch *touch = [touches anyObject];
CGPoint positionInScene = [touch locationInNode:self];
[self screenInteractionEndedAtLocation:positionInScene];

- (void)touchesCancelled:(NSSet *)touches
withEvent:(UIEvent *)event
UITouch *touch = [touches anyObject];
CGPoint positionInScene = [touch locationInNode:self];
[self screenInteractionEndedAtLocation:positionInScene];
-(void)mouseDown:(NSEvent *)theEvent {
CGPoint positionInScene = [theEvent locationInNode:self];
[self screenInteractionStartedAtLocation:positionInScene];

- (void)mouseUp:(NSEvent *)theEvent
CGPoint positionInScene = [theEvent locationInNode:self];
[self screenInteractionEndedAtLocation:positionInScene];

- (void)mouseExited:(NSEvent *)theEvent
CGPoint positionInScene = [theEvent locationInNode:self];
[self screenInteractionEndedAtLocation:positionInScene];

-(void)screenInteractionStartedAtLocation:(CGPoint)location {
/* Overridden by Subclass */

-(void)screenInteractionEndedAtLocation:(CGPoint)location {
/* Overridden by Subclass */


That's it, now all you have to do is make sure all your scenes inherit from SKMScene instead of SKScene and implement the two screenIntereaction methods.

There's a lot more to this process and I'm only just starting to learn to make cross platform games myself but I hope the above tips have helped you on your journey. Give it a go and see what you think.

You can also download a sample project on GitHub.