The code turns on diagnostic information that describes how the scene renders the view. The most important piece of information is the frame rate (spriteView.showsFPS); you want your games to run at a constant frame rate whenever possible. The other lines show details on how many nodes were displayed in the view and how many drawing passes it took to render the content (fewer is better).

The header file created by Xcode has the following content:

You don’t need to change the header file.

The app should launch and display a screen that is blank except for the diagnostic information.

The property tracks information that doesn’t need to be exposed to clients, so, it is implemented in a private interface declaration inside of the implementation file.

The didMoveToView: method is called whenever the scene is presented by a view, but in this case, the scene’s contents should only be configured the first time the scene is presented. So, this code uses the previously defined property (contentCreated) to track whether the scene’s contents have already been initialized.

- (void)createSceneContents

{

    self.backgroundColor = [SKColor blueColor];

    self.scaleMode = SKSceneScaleModeAspectFit;

    [self addChild: [self newHelloNode]];

}

A scene paints the view’s area with a background color before drawing its children. Note the use of the SKColor class to create the color object. In fact, SKColor is not a class; it is a macro that maps to UIColor on iOS and NSColor on OS X. It exists to make creating cross-platform code easier.

A scene’s scale mode determines how the scene is scaled to fit in the view. In this example, the code scales the view so that you can see all of the scene’s content, using letterboxing if required.

In SpriteKit, you never write code that explicitly executes drawing commands, as you would if you were using OpenGL ES or Quartz 2D. Instead, you add content by creating node objects and adding them to the scene. All drawing must be performed by the classes provided in SpriteKit. You can customize the behavior of those classes to produce many different graphical effects. However, by controlling all drawing, SpriteKit can apply many optimizations to how drawing is performed.

You should see a blue screen with “Hello, World!” in it. You’ve now learned the basics for drawing SpriteKit content.

All nodes have a name property that you can set to describe the node. You name a node when you want to be able to find it later or when you want to build behavior that is based on the node name. Later, you can search the tree for nodes that match the name.

In this example, you give the label a name so that it can be discovered later. In an actual game, you might give the same name to any node that represents the same kind of content. For example, if your game represents each monster as a node, you might name the node monster.

All node objects are subclasses of UIResponder on iOS and NSResponder on OS X. This means that you can create subclasses of node classes in SpriteKit to add interactivity to any node in the scene.

To prevent the node from responding to repeated presses, the code clears the node’s name. Then, it builds action objects to perform various actions. After creating all of the actions, it creates a sequence action that combines these actions together; when the sequence runs, it performs each of the child actions in order. Finally, the method tells the label node to execute the sequence.

You should see the text as before. At the bottom of the screen, the node count should be 1. Now, tap inside the view. You should see the text animate and fade away. After it fades away, the node count should change to 0, because the node was removed from the parent.

When you touch inside the scene, the text fades out and then the view transitions to the new scene. You should see a black screen.

This method creates the spaceship’s hull and adds to it a short animation. Note that a new kind of action was introduced. A repeating action continuously repeats the action passed to it. In this case, the sequence repeats indefinitely.

You should see a single rectangle for the spaceship’s hull.

Insert the following code after the line that creates the hull sprite.

SKSpriteNode *light1 = [self newLight];

light1.position = CGPointMake(-28.0, 6.0);

[hull addChild:light1];

SKSpriteNode *light2 = [self newLight];

light2.position = CGPointMake(28.0, 6.0);

[hull addChild:light2];

When building complex nodes that have children, it is a good idea to isolate the code used to create the node behind a construction method or even a subclass. This makes it easier to change the sprite’s composition and behavior without requiring changes to clients that use the sprite.

You should see a pair of lights on the spaceship. When the spaceship moves, the lights move with it. All three nodes are continuously animated. You could add additional actions to move the lights around the ship; they would always move relative to the ship’s hull.

The spaceship plummets through the bottom of the screen. This is because a gravitational force is applied to the spaceship’s physics body. Even though the move action is still running, physics effects are also applied to the spaceship.

When you run it now, the spaceship is no longer affected by gravity, so it runs as it did before. Later, making the physics body static also means that the spaceship’s velocity is unaffected by collisions.

The scene is also a node, so it can run actions too. In this case, a custom action calls a method on the scene to create a rock. The sequence creates a rock, then waits for a random period of time. By repeating this action, the scene continuously spawns new rocks.

Rocks should now fall from the top of the scene. When a rock hits the ship, the rock bounces off the ship. No actions were added to move the rocks. Rocks fall and collide with the ship entirely due to the physics subsystem.

The rocks are small and move quickly, so the code specifies precise collisions to ensure that all collisions are detected.

If you let the app run for a while, the frame rate starts to drop, even though the node count remains very low. This is because the node code only shows the visible nodes in the scene. However, when rocks fall through the bottom of the scene, they continue to exist in the scene, which means that physics is still being simulated on them. Eventually there are so many nodes being processed that SpriteKit slows down.

Each time the scene processes a frame, it runs actions and simulates physics. Your game can hook into this process to execute other custom code. Now, when the app processes a new frame of animation, it processes physics and then removes any rocks that moved off the bottom of the screen. When you run the app, the frame rate remains constant.

Pre- and post-processing in a scene, combined with actions and physics, are the places you build your game’s behavior.