What's the relationship between GameScene.swift and GameScene.sks files in SpriteKit template - swift

Question

I've been playing around with SpriteKit, and am getting a pretty decent feel about how to drive it from code, but am pretty baffled by the level editor included in Xcode 6.
I've watched the wwdc videos ("platforms state of union" and "what's new in spriteKit"), and scrounged around the web, but haven't been able to find much description about the level editor, and what it's really doing.
What I don't understand, is how are the two files that the template sets up related? Is the .sks file an expression of the GameScene.swift file, or perhaps the GameScene class it contains?
OR do they both just hold separate objects/nodes that are going to play together in the same scene?
Or (this is my best explanation) is the .sks file and the editor basically for making the environment that responsive characters are going to "live" in? If that's true, how can my code in the .swift file relate to what's in the .sks file?

Answer 1

The .sks file is a static archive of your scene's content. If you've used Interface Builder to set up UI apps before, it's much the same idea, if rather different in implementation.
In a UI app, you could do everything in code:
override func viewDidLoad() {
let someText = UITextField(...)
let aButton = UIButton(...)
// ... position everything
// ... style everything
// ... etc ...
}
Or you could do all the static content setup in IB (a xib or storyboard), and use code only for setting up the dynamic behavior of your app — the things that happen when somebody starts touching those buttons. When you do that, the view controller you write code for exists as a proxy object in the xib/storyboard, making a bridge between what you set up in IB and what you set up in code.
In SpriteKit, you have the same choice. Before Xcode 6, many SK games took the all-code approach:
override func didMoveToView(view: SKView) {
let player = PlumberSprite(color: .Red)
player.position = // ...
player.physicsBody = // ...
self.addChild(player)
let ground = SKSpriteNode(...)
ground.position = // ...
ground.physicsBody = // ...
self.addChild(ground)
let block = QuestionBlockSprite()
block.position = // ...
block.physicsBody = // ...
block.contents = CoinSprite()
self.addChild(block)
// ... etc etc etc ...
}
That's a lot of code for what's ultimately a graphical, static scene — even before you start adding code to make it into a game (input handling, enemy behavior, physics callbacks that increment the score or go to game over, etc). And it doesn't lend itself well to designs where you split out the general game logic from the content, so it's harder to add multiple levels to your game.
Instead, you can use the SpriteKit editor in Xcode to build your static content (levels), and stick to code for dynamic behavior and game logic. Just like how, in IB, the view controller is a bridge between your storyboard and your code, your scene class (GameScene.swift in the template) is the bridge between the editor and code. When you load an .sks file at run time (the code for this is in GameViewController.swift in the template), it becomes an instance of your GameScene class, and anything you set up in the editor is accessible as child nodes of the scene.
Checking out WWDC talks is a good idea, but you missed the one that covers this: see session 608: Best Practices for Building SpriteKit Games for more on the motivation behind the SpriteKit editor, how to use it, and how to work with the scene contents loaded from an .sks file in your scene code.