Using single image vs @2x & @3x

So I've started to build my super game using SpriteKit. And there is one problem I can resolve with two different ways.


When creating a sprite it is needed to point .png-file (SKSpriteNode(imageNamed: "hero")).


.PNG file can be in .xcassets folder and have several versions (@2x, @3x) for each device (4s, 5, 6, 6+). But there is a way to use just one .png file and set correct scale property for a sprite.


Is it a good practice to use one image and set scale or it is better to use concrete file (@2x or @3x) for a cpecific device?


Pros using one file – smaller app size.

Replies

The con is that you are using more memory than you need to be using on devices with lower resolutions.


Also, it sometimes is suggested to recreate different images with less detail for lower resolutions. High resolution images with lots of detail scaled down may not look 'as good' on a non-retina screen. Most of the time though developers just scale down the high resolution resources. Unless you are a designer yourself or you got money bags to pay designers to recreate another batch of resources. For most images scaling down retina is fine, but don't do it at runtime. Fill the asset catalog.

I would rather have a bigger app bundle than waste memory...especially if you're making a game.

Also note that in iOS 9 with App Slicing/Thinning that only the appriopriate files for a device will be downloaded. So for iPhone 6 Plus only @3x files will be downloaded (where available), etc. Therefor the only person who would actually 'benefit' from using one image size to keep the app size small is you, when you are uploading to the App Store 😉


For more info on App Slicing/Thinning: https://developer.apple.com/library/prerelease/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AppThinning/AppThinning.html

"Set scale" does not mean one thing. If you don't resample a high-res asset, it will be bilinearly-filtered for display, which is not the right solution for 2D games. You could use a better sampling algorithm at runtime, but it will eat battery and cause delay; App Slicing is the best solution available.