TL; DR: I made a Mac app that asks you a bunch of questions about your game and then tells you how to set up your SpriteKit scene and asset documents.
Sometimes I feel like I’m losing my mind—is it really this complicated? Have I missed some simple, fundamental thing about supporting iPads that every other SpriteKit dev knows about?
On the other hand, there’s no denying that iPads really are significantly larger than iPhones (A groundbreaking insight, I think you’ll agree) and Apple acknowledges this huge difference in UIKit.
UIKit apps can have a single storyboard to serve all devices but this is heavily augmented with technologies like autolayout, size classes, and trait collections.
With these technologies, this single design document can create responsive UIs that can look radically different from iPhone to iPad.
Nothing like this exists for SpriteKit.
This means that it probably is that complicated but Apple leaves it to us to figure out how we want to deal with it, which is fair given how unique game interfaces can be.
The vastly different screen sizes can make it difficult to design a game that looks and works exactly the same across all the different devices. However. it’s not impossible if we are willing to accept some trade-offs.
Which trade-offs are appropriate?
That all depends on the game.
Never Having to Think About This Again
Having written thousands of words about this, and assuming that we don’t want to maintain completely different scenes for iPads and iPhones, I have found that there are basically five scene size situations that will cover most 2D games:
- Single-screen game where clipping on one or more devices is acceptable
- Single-dimension scrolling game where clipping is acceptable
- Single-screen game where borders on one or more devices are acceptable
- Single-dimension scrolling game where borders are acceptable
- Camera-based game that scrolls in all directions
Having decided that, then, in terms of scene management, it comes down to whether we want to deal with two spatial data sets or not.
Once the scene type is decided, the next step is to decide how difficult we want asset management to be:
- Easy: Measure everything in pixels then use the same large @2x iPad image for each asset on all devices (even though this is memory intensive, may crash or slow down on older devices, and may be rejected by Apple for memory usage).
- Medium: Use points and asset catalogs but use @2x iPhone assets on the iPad and accept they’ll be scaled up and might be a little fuzzy.
- Hard: Use points and asset catalogs but make the @2x iPad assets twice the size of the @2x iPhone assets, knowing that that this will entail doubling every spatial value in the game for the iPad version.
Add in whether we want the game to be portrait or landscape, and whether the asset image documents will be vector-based or raster-based, and we end up with quite a few combinations of possible development situations.
A Quick Aside on Spatial Data
The question about spatial data comes down to whether it’s OK for things to look fuzzier on an iPad.
In order for assets to not look fuzzy, the iPad needs them to be equivalent to a 4x scale.
However, iOS only understands up to a 2x scale for iPads, which means that any measurement that is based in space—size, location, movement speed, etc.—needs to be doubled for the iPad (or halved for the iPhone).
It’s extra work, but doubling or halving values is still much more straightforward than trying to develop separate, individual scenes for iPads and iPhones. The process can be helped further by using asset catalogs for the data.
The difference between fuzzier 2x assets and crispy pseudo-4x assets is noticeable but not as much as you might think. It’s worth doing some testing to see if it can work for your game or if the fuzziness bothers you (it bothers me).
In my quest to never have to think about this again, I started by putting together a small questionnaire that goes through all these options.
Initially, it was a flowchart that I could follow and it would tell me how to set up my scene, which drawing app document size to use, and which assets I’ll need to create from that document.
Then I thought this would be better as a small Mac app, where it could ask me a series of questions and then tell me what to do at the end.
Then, because I’d already gone this far down the rabbit hole, I thought it would be cool to see the consequences of all my decisions.
I created device previews to see what trade offs my choices had against the original design document (e.g. how severe was the clipping? How much does the camera show on different devices?):
The resulting app is called AdventureKit Answers and, if you’d like to try it, it’s free and version 1 is available to download here.
It covers three of the five situations listed above—single scene clipping, single scene borders, and cameras. It also covers all three options for asset generation.
The previews show how a sample background will be affected by the choices made on an @2x iPad Pro 12.9", an @2x iPhone 8, and an @3x iPhone XS.
It also has code samples for any situation that requires extra work to correctly set up the scene (e.g. using pixels instead of points, or halving iPad values to use Universal assets).
And, with that, let us never mention SpriteKit scene sizes ever again.
Get all of my latest posts direct to your inbox! Pop in your email address here: