Is SVG Really the Answer? What About PNG?

Aiming for productivity and efficiency, but with a side of performance and stability

2

There's a swamp that app engineers inevitably experience at least once.
That is the swamp of resource management…
Especially the swamp of image resource management, which is our inevitable fate..
It is destiny..

But since we have to face this fate anyway, it’d be nice if it were a bit more efficient, and even better if it had excellent performance (and knowing why it's excellent would be a plus), and stability is a must, right?! So let's start the story I've prepared. (Honestly, it's hard to tell the whole story, so this is about the most commonly used formats: PNG and SVG.)

1. The Birth of the Swamp

Every problem has a cause. And the resource swamp is no different. So what caused this swamp of resources to be born?

Ironically, the cause of all problems is the advancement of technology.

To give a brief history, Apple launched the iPhone in 2007. And the iPhone at that time had a 3.5-inch display with a resolution of 240x320. But in 2010, they released the iPhone 4 with a Retina Display, giving it twice the resolution on the same screen size. And with the release of the iPhone 6 Plus, the resolution increased threefold.

And all too naturally, Apple will sometimes reject an app if the images aren't properly included.

If a low-resolution image is on a device equipped with a Retina HD Display, the image can be shown through upscaling, but it will look pixelated. Conversely, if there are only high-resolution images, lines like strokes might disappear on low-resolution devices.. Ultimately, to provide users with perfect images, we need to support devices with three types of displays.

1. Devices not equipped with a Retina Display
   (Models before iPhone 4)

2. Devices equipped with a Retina Display
   (iPhone 4 ~ iPhone 5)

3. Devices equipped with a Retina HD Display
   (iPhone 6 ~ present)

And to support these displays, we had to manage 1x, 2x, and 3x images, and that is how the current swamp of image resources was born.

But even so, you don't need to worry about your app's file size. Because the smart Apple App Store uses app thinning when a user downloads an app, so they only receive the necessary imageAsset 🙂

For example, an iPhone 4 user doesn't really need a 3x image Asset, so they don't even download it.

But there's one more problem. We aren't just supporting images of a single scale. 16x16, 24x24, 48x48, etc., as the icon set grows, the number of sizes we have to manage multiplies by n, which is amazing magic..🫢 Moreover, this approach also affects the user's app size..

You might ask, "Can't we just reuse a single image?"..
But Apple says not to do that... 😞

Create images so that they do not need resizing. If you plan to use an image at a particular size, be sure to create the corresponding image resource at that size. Do not create a larger image and scale it down to fit, because scaling requires additional CPU cycles and requires interpolation. If you need to present an image at variable sizes, include multiple versions of the image at different sizes and scale down from an image that is relatively close to the target size.

Is there really no escape from this resource swamp? Sure, there's a format called SVG that can handle all sizes, but Xcode didn't support it.. While we were mourning this, Kingple announced they would support the svg file format starting from Xcode 12. 🎉 (It was so late that I wondered why they were only supporting it now, hence Kingple, not Godple..)

2. SVG(Single Vector Image) Makes a grand entrance-!

So what are the advantages of using SVG? Why did people wait so long for Xcode to support svg?

Ba-dum-! Tss! 🥁

The biggest advantage is that the number and size of image Assets to manage are drastically reduced.
Because you manage it in a single scale, you no longer need to manage the 1x, 2x, and 3x versions that were required to support multiple displays. (This is surprisingly tedious. Especially when changing images..) In addition, you don't need sizing for 16x16, 24x24, and 48x48. That means with just one svg file, you can handle all sizes.

How is this possible?
The answer is exactly what you all know: because it's a Vector Image.
(Not a very surprising fact 😋)

At a glance, an svg looks like an image file, but when you actually look into the file, you can see it's written in XML (Extensible Markup Language) for data management.
That's why, no matter what size you convert it to, it draws it accordingly and prevents it from getting pixelated!
And what does being composed of xml mean? It means engineers can manually edit the svg file themselves.

<svg width="64" height="64" viewBox="0 0 64 64" fill="none" xmlns="http://www.w3.org/2000/svg">
<path opacity="0.2" d="M64 32C64 49.6731 49.6731 64 32 64C14.3269 64 0 49.6731 0 32C0 14.3269 14.3269 0 32 0C49.6731 0 64 14.3269 64 32Z" fill="#FCD823"/>
<path opacity="0.2" d="M58 32C58 46.3594 46.3594 58 32 58C17.6406 58 6 46.3594 6 32C6 17.6406 17.6406 6 32 6C46.3594 6 58 17.6406 58 32Z" fill="#EDBB07"/>
<path d="M52 32C52 43.0457 43.0457 52 32 52C20.9543 52 12 43.0457 12 32C12 20.9543 20.9543 12 32 12C43.0457 12 52 20.9543 52 32Z" fill="url(#paint0_linear_1796_2820)"/>
<path fill-rule="evenodd" clip-rule="evenodd" d="M22.8318 26.2567C23.1697 25.7397 23.8628 25.5945 24.3799 25.9325L28.3469 28.5257C28.4501 28.5931 28.5387 28.675 28.6117 28.767C28.7348 28.8646 28.839 28.9897 28.9142 29.1384C29.193 29.6897 28.9721 30.3625 28.4209 30.6412L23.7594 32.9983C23.2082 33.2771 22.5354 33.0562 22.2567 32.505C21.9779 31.9537 22.1988 31.2809 22.75 31.0022L25.7368 29.4919L23.156 27.8048C22.6389 27.4669 22.4938 26.7738 22.8318 26.2567ZM39.6201 25.9325C40.1371 25.5945 40.8302 25.7397 41.1682 26.2567C41.5061 26.7738 41.361 27.4669 40.8439 27.8048L38.2631 29.4919L41.2499 31.0022C41.8011 31.2809 42.022 31.9537 41.7432 32.505C41.4645 33.0562 40.7917 33.2771 40.2405 32.9983L35.5791 30.6412C35.0278 30.3625 34.8069 29.6897 35.0857 29.1384C35.1609 28.9897 35.2651 28.8646 35.3882 28.767C35.4612 28.675 35.5498 28.5931 35.653 28.5257L39.6201 25.9325ZM42.7746 35.4727C43.0585 35.05 43.6405 34.9314 44.0747 35.2078C44.5088 35.4842 44.6306 36.0509 44.3468 36.4736C43.3304 37.9871 39.5586 42.1848 32.34 42.1848C25.1378 42.1848 20.9308 38.0038 19.712 36.5519C19.3838 36.1608 19.4432 35.5847 19.8449 35.2651C20.2465 34.9455 20.8382 35.0034 21.1664 35.3945C22.2144 36.6429 25.9412 40.3558 32.34 40.3558C38.7223 40.3558 41.9776 36.6595 42.7746 35.4727Z" fill="#171D2E"/>
<defs>
<linearGradient id="paint0_linear_1796_2820" x1="16.7727" y1="45.1818" x2="43.8182" y2="16.7727" gradientUnits="userSpaceOnUse">
<stop stop-color="#FF8A00"/>
<stop offset="1" stop-color="#FFE34E"/>
</linearGradient>
</defs>
</svg>

The image below shows one Asset extracted both as an SVG and as a PNG 3x. Looking at the detailed information, you can visually confirm right away that they are quite different. And you can even see that SVG takes up less space than PNG. (svg = 2KB / png = 16KB)

So we should just change everything to this awesome svg, right?

3. Things to Keep in Mind

However, there are a few things to keep in mind when using this wonderful SVG.

1. Too obviously, the Xcode version.

• Since svg is supported from Xcode 12, we need to first check what version of Xcode we are using. Of course, I have no doubt that most readers will meet this requirement. 🙏

2. Is the App Target iOS 13, iPadOS 13, macOS 10.15 or higher?

• To use svg, it's essential to check the minimum version of our app. If you need to support anything lower than this, they say there's a way to handle it with the PDF format. (I haven't tried this myself, so I don't know much about it.)

3. Is the image too complex?

• It might sound a bit abstract, but svg ultimately requires mathematical calculations. You don't have to worry about simple images, but the more complex an image is, the larger its file size can get, making it potentially more advantageous to handle it as a png instead.

4. Limited Color Depth

• SVG images have a limited color depth. Because of this, they are sometimes reconstructed and displayed with approximated values. Our designers also sometimes give feedback saying, "It's often different from the expected color." Therefore, to express exact image colors, exposing them through PNG can be more effective.

5. Does it have a Gradation?

• I'm not sure why, but when using svg in Xcode, there's a weird bug where if the file has a Gradation, it just appears as an empty screen 🤔 Because of this, if there is a Gradation, I recommend managing it as a png for stability. Even if it looks normal in Xcode, after experiencing a few situations where it looked empty on users' devices, we stably manage gradation with png.

6. If Resizing is needed, Preserve Vector Data Check is a must!

• This isn't really a pre-use checklist item, but maybe because resizing imageAssets isn't very common due to the nature of mobile, I couldn't find anywhere pointing this out even when looking up places that use svg, so I wrote it down.
  Due to the nature of svg, you put in a single asset and convert it into multiple sizes to use it. If you don't check this box, you can see the image break when converted to a larger size. To fully utilize the advantages of svg, it's good to make sure this is checked.

4. Conclusion

To give you the conclusion, naturally, we use both.

When an image is simple and has few additional elements like a gradation, we use SVG (in fact, this applies to almost all of them). When we judge that elements like a gradation might cause stability issues, we use PNG.

Productivity is important, but we believe what's more important is always, always providing a stable app to our users. However, we aim for management with a high level of understanding, neither blindly rejecting nor blindly accepting things. And I have no doubt that the readers who have read this post feel the exact same way.

Lastly, I'll wrap up this post with the potential issues of using svg instead of png that I asked ChatGPT about.

Thank you for reading to the end 🙂

ref:
https://help.apple.com/xcode/mac/current/#/devbbdc5ce4f
https://www.mfractor.com/blogs/news/understanding-ios-image-assets
https://developer.apple.com/library/archive/documentation/2DDrawing/Conceptual/DrawingPrintingiOS/LoadingImages/LoadingImages.html