5 Best Practices Beginner Mobile Game Developers Must Know

Entire Post Here


For those who don’t know what Cocos2D is, it is the most popular game engine on iOS and was around before Sprite Kit (the official Apple Framework), and Sprite Kit also takes a lot of ideas from Cocos2D. What is great about Cocos2D is that it is open source, and with company called Portable it is also possible to write the game on iOS and then port it to Android.

A couple of great games were also have been made by Cocos2D, a great example being Badland, which won Apple’s design prize for games. It is definitely a very popular and well-maintained game engine.

Another tool that we’re using a lot is SpriteBuilder. If you used Unity before, it is very similar to Unity but it’s for 2D games where it allows you to create great game content, to create levels, and to do all that visually without writing code for the game content part. This means when you’re building games with SpriteBuilder or Cocos2D, you’ll get a nice separation between your content (e.g. levels, menus, etc.) and your core game mechanics.

Not all of the points here are iOS-specific, but one thing you should have realized when you started game development is that it’s pretty platform-agnostic. A lot of content also apply to PC games and web games.

#1 Don’t make assumptions about the screen size

When starting out with game development, a lot of people will use constants for the screen work. In the past, the only resolution for any screen size we had was 480 x 320 on the iPhone 4. That means people could make assumptions about the size of the screen, and you could code in constants and use them to position things on the screen.

After the iPhone 5 came out with a different screen size, all of these inexperienced developers’ games needed an entire redesign for the new screen sizes.

So, now with the current state of the platform, even for iOS where we don’t have that many different devices, we have enough different devices that you definitely can’t make assumptions about how big the screen size is. We should always place things relative to the screen size and not make hard code assumptions about the screen size.

let screenWidth = 320 
myButton.x = screenWidth - 50

We have constants for the screen width, and you calculate the position for an object on the screen based on that…this is usually a very bad practice. Instead, you have to think about what width to write while you basically correspond to the screen size like this:

// cocos2D example 
myButton.x = self.contentSize.width - 50

In Cocos2D, for example, that would be the content size property on the scene. So each scene has a content size property, and if you, for example, have a full scene and that content size property will be the full screen size.

But it’s also possible to have your scene smaller than the full screen. Either way, if you press the button relative to that scene, then you should calculate the position based on the content size.

That’s just a very simple example where you shouldn’t use constants for width and height. Calculate the things based on scenes or whatever is relevant to your specific example.

This is really important to keep in mind. That would save you a lot of time from redesigning your game for every different devices type (e.g. iPad, iphone6, iphone5, etc). The good news is that SpriteBuilder and Cocos2D have some good support for such relative layouts. This makes things pretty easy once you start thinking about how to implement a flexible design.

Beyond that very basic rule, there is another thing to think about and that’s basically I would like to divide the things I show on the screen into two categories. One for UI components, such as buttons or the HUD (Heads-up-Display) that shows current points in the game, and the other one for actual gameplay.

Entire Post Here

Understanding Async Programming with Starbucks

Helpful post to get a better understanding of Asynchronous programming.

Full article is here


've worked and trained with many developers over the years, and I found that many people struggle to get their head around asynchronous programming. Asynchronous structures like Futures, Promises and Blocks are literally everywhere now. Yet, they're still difficult to understand, so I thought I can help you wrap your head around it with some help from Starbucks. That said, grab your Pumpkin Spice Latte and get ready for a Caffeine-fueled adventure through the world of Async programming ☺

Pre-Starbucks - The Synchronous Model

Let's take a moment to picture yourself in line at your favorite coffee store, where they can process only one transaction at the time. You get to the counter, what happens next?

  • You put in an order for a quadruple espresso (it's going to be a long day ahead)
  • You pay the extortionate price (when did coffee get so expensive?!)
  • You stand still...
  • While you stand your server goes and crushes some beans;
  • You stand still...
  • The barista turns some handle's, bangs a big metal thing loudly, steams, froth;
  • You stand still...
  • Everyone behind you stands still...
  • The barista holds the little paper cup under the coffee machine as it pours your drink in;
  • Everyone behind you waits, checking their phones/watches, wondering who the awkward person ordering a quadruple espresso is;
  • Finally, the barista gives you your coffee;
  • You grab your drink; add any additions of your choice and leave;
  • Now the Server moves on to the next person, who orders a single bottle of water they've been holding the entire time, they pay and leave immediately!

Welcome to the world of synchronous programming! You ask a function to do something and you wait until they've done it. And if someone else wants to do something that could be much quicker, they have to wait!

Read the rest here ...

Clean Swift Architecture - an alternative to MVC


Read the entire article here

A couple of years ago, all of the iOS apps were small containing less than 10 screens. The codebase was small, storyboards were working excellent, and it was easy to maintain your project. From an architectural point of view, MVC was doing a great job.

How about today?

Today, we are facing big technological advancements and an insane app market growth. In other words, apps are becoming big and complex. We are working on projects that contain 20, 30 or even 40 screens making it impossible to be maintained with MVC.

As technology moves forward, so should we (developers).

Recently, I really got tired from MVC and started looking for a new architecture. After a short research, I have noticed the Clean Swiftarchitecture and instantly fell in love with it! This architecture was exactly what I was looking for. 🚀

About the Clean Swift Architecture

Clean Swift (a.k.a VIP) is Uncle Bob’s Clean Architecture applied to iOS and Mac projects. The Clean Swift Architecture is not a framework. It is a set of Xcode templates to generate the Clean Architecture components for you. That means you have the freedom to modify the templates to suit your needs.

In an MVC project, your code is organized around and grouped by models, views, and controllers. In Clean Swift, your project structure is built around scenes (or screens). Here is an example how does one scene looks like. In other words, we will have a set of components for each scene that will "work" for our controller. These are the components:

  • Models
  • Router
  • Worker
  • Interactor
  • Presenter
  • Configurator

Read the entire article here

How to optimize swift and iOS build times

Here is a FREE opens source repository that can help speed your builds


  • Type checking of functions and expressions
  • Slowly compiling files
  • Build active architecture only
  • dSYM generation
  • Whole Module Optimization
  • Whole Module Optimization for CocoaPods
  • Third-party dependencies
  • Modularization
  • XIBs
  • Xcode Schemes
  • More

Here is a FREE opens source repository that can help speed your builds

Introducing Snapchat Snapkit DIY Docs

Part 3 in a continuing saga of working with Snapchat Snapkit for iOS/Swift

I have been chronicling my attempts to use Snapchat Snapkit. Now, I’m putting my GitHub where my Repository is ;)

Introducing Snapchat Snapkit DIY Documentation and Best Practices

Are you looking for plain English instructions for Snapkit? Do you find the current documentation inscrutable? Are you interested in building a community of developers for Snapkit?

Please come by Snapchat Snapkit DIY documentation and best practices

Huge collection of fantastic tips for Swift Development

All I can say is Wow! Check this out. Swift tips and tricks

So many icons, so little time

Need the crazy number of sizes and resolutions for your in-app icons or the app icon itself? This in browser tool is great


UI helper - iOS Sizing / resolutions

Need help with all the iPhone and iPad sizes and the assets (graphics/images) you need?

This site is super handy http://iosres.com/

Optionals and ifs and lets and guards

What if.. if let and guard let and var let and well .. there is a lot of “let” in Swift. Two goodreads:

Error Domain=PlugInKit Code=13 "query cancelled

So subtle yet so vexing.

Error Domain=PlugInKit Code=13 “query cancelled

To fix this, I changed one tiny piece of code, but there are a number of related issues to check


    func imagePickerController(_ picker: UIImagePickerController, didFinishPickingMediaWithInfo info: [String : Any]) {
        let chosenImage = info[UIImagePickerControllerOriginalImage] as! UIImage
        userChosenPhotoFromGalleryOrCamera.image = chosenImage
        self.dismiss(animated: true, completion: nil)

        userChosenPhotoFromGalleryOrCamera.isHidden = false

Get rid of self.dismiss and replace with picker.dismiss


    func imagePickerController(_ picker: UIImagePickerController, didFinishPickingMediaWithInfo info: [String : Any]) {
        let chosenImage = info[UIImagePickerControllerOriginalImage] as! UIImage
        userChosenPhotoFromGalleryOrCamera.image = chosenImage
        picker.dismiss(animated: true, completion: nil)

        userChosenPhotoFromGalleryOrCamera.isHidden = false

Forcing iOS orientation for single or all ViewConroller

The app I am building really makes sense in portrait mode only. So I want to force that. And also, there is just too much to test with all the orientations. So why not?

Here are some resources that helped me: