almost 6 years ago from Cihad Turhan, UI Developer and Designer
I design an app for both iOS and android in Sketch. I export all the assets for 1,2,3x and mdpi, hdpi,xhdpi, xxhdpi. However for an image, say a background image for splash screen, it costs around 0,6MB, 2.4MB, 4,8MB... for each size So just a background image would cost more than 7MB to an app which is big! Do you export in every size and also how do you export them?
Yes, you should export all required sizes, and most of the time your assets should be bitmap images.
For iOS, that means 1×, 2×, and 3× PNGs. For Android, that means 1×, 1.5×, 2×, 3×, and 4× PNGs or WebP images.
Yes, it can mean your images take up a bit of space overall. Where possible, avoid images with really big dimensions — they’re huge files at higher screen densities. It’s not just download times that are impacted, but also app launch time, the amount of memory used, and the amount of disk space required.
Android’s vector drawable format is good, when you can use it. Please note that it’s only suitable for some types of artwork, and you need to be a little careful on Android versions targeted, and drawing performance.
If you can, WebP is a more optimal format than PNG, so that should be used.
If you want, you can probably skip over the 1.5× assets, as not many devices use them. It could be worth checking with your target devices though.
You should definitely create a Android adaptive app icon, too. That means you’ll need a normal and adaptive app icon.
Don’t use PDFs. If you need or want to draw vector icons in realtime, PaintCode is a better option, because it means you’re actually drawing the artwork realtime (PDFs just render a bunch of PNGs when building the app, and offer pretty much no advantage).
You can optimise your PNG images, if you’d like. But, Xcode will recompress all your images, unless you tell it not to. That means your compression efforts will be lost unless you change your Xcode settings for the project. If you’re building Mac apps, and your 1× images end up in a different PNG format due to compression (greyscale 8bpc PNG vs RGBA 8bpc PNG etc), then macOS can use the wrong PNG to render. That means you can get a scaled down 2× image on a 1× display. It looks bad.
Don’t use PDFs.
Do use them but know the limits as described in the linked article. They are in fact recommended by Apple for “glyphs and other flat, vector artwork that requires high-resolution scaling”.
Beware that Photoshop PDF export tends to rasterize many features, e.g. layer fills (but not the corresponding vector masks).
With App Thinning introduced in 2015, Xcode and App Store effectively decide what formats and sizes will be send to a device. Standalone assets are currently missing all these benefits, and rarely used by top apps.
Xcode will recompress all your images, unless you tell it not to.
If you’re using Asset Catalogs, all images will be recompressed at build time, there’s no way to prevent it as of now. Compression can still help to reduce final app size when lossy and, at the very least, make your repo size smaller.
If you’re building Mac apps, and your 1× images end up in a different PNG format due to compression (greyscale 8bpc PNG vs RGBA 8bpc PNG etc), then macOS can use the wrong PNG to render.
Luckily, there’s a clean solution.
They are in fact recommended by Apple
Since when is that a definitive reason for anything. :P
Beware that Photoshop PDF export tends to rasterize many features, e.g. layer fills (but not the corresponding vector masks).
All the tools I’ve tested rasterise lots of features designers might use. The issue is more about the PDF format than Photoshop itself.
With App Thinning introduced in 2015, Xcode and App Store effectively decide what formats and sizes will be send to a device. Standalone assets are currently missing all these benefits, and rarely used by top apps.
Yep, I get all that. Asset Catalogs have so many other maintenance issues though. They’re definitely not a clear win. Even if you do use Asset Catalogs, I’d recommend using PNGs with them, and not PDFs. PDFs are terrible.
Feelings aside, simple shapes are rendered identical when comparing PDF and PNG. Apple can choose not to include bitmaps along with PDF assets for newer devices anytime soon flipping the point that PDFs make image assets larger. In practice coding-in vector assets is a much more involved process than getting and using PDFs.
All the tools I’ve tested rasterise lots of features designers might use.
It’s a pity tools don't warn about this.
Asset Catalogs have pretty straightforward structure with a few quirks, nothing that can’t be implemented in design tools. But I’m absolutely against the decision to force proprietary formats in Asset Catalogs. It‘s a more serious problem. PNGs are no longer PNGs there. With HEIF introduction, the same is going to happen to JPEGs, if not already.
Feelings aside, simple shapes are rendered identical when comparing PDF and PNG.
Yep. Well, identical if you’re comparing Core Graphics shapes with Core Graphics shapes (things exported in Ps, Ai, AD will look different, Sketch will be the same, probably). My main concern is that there is no benefit in using PDFs, except designers being lazy. We may as well call it out for what it is — anyone willing to risk the quality of their work because they don’t want to turn on some exporting options is being lazy. The downside is shipping assets that look bad, and you won’t know unless you carefully test all densities in the simulator or on device.
Why break such a robust process with PNGs, but introducing issues that often can’t be predicted ahead of time? Most designers don’t know the limitations of the PDF spec, and they probably won’t know which features are rendered to bitmaps by their design tool when exporting PDFs. The simple and better solution is to never use PDFs. You don’t gain anything in terms of app bundle size and launch time, and you certainly don’t gain quality.
Asset Catalogs have pretty straightforward structure with a few quirks, nothing that can’t be implemented in design tools
Yep.
But I’m absolutely against the decision to force proprietary formats in Asset Catalogs.
Yep.
I honestly do like vector drawables though. They are exactly what’s needed, and nothing more, in a good format.
I do agree that PDF is not the best format for vector graphics. Vector drawables give more freedom, e.g. adaptive icons. I guess it was a bet on the proven and widely used technology. Also, PostScript/PDF is deeply integrated into Core Graphics.
The difference in rendering is mainly in AA, which is superior in CG at least for flat shapes. In my test even gradients become a problem. It is fixable though.
Don’t use PDFs. If you need or want to draw vector icons in realtime, PaintCode is a better option, because it means you’re actually drawing the artwork realtime (PDFs just render a bunch of PNGs when building the app, and offer pretty much no advantage).
That Bjango article is 2.5 years old and out of date with the latest version of Xcode. Xcode 9 has asset catalog changes and using vector PDF's now preserve vector data[1].
For iOS, assets should be vector images and rendered as templates. This gives you the flexibility of settings a tint color. The only time you should be using PNG's is if you have an complex rasterized image.
No, the article is still very much correct, even with the additional preserve vector data checkbox — that checkbox includes the PDF assets as well as the PNG assets. The same rules still apply:
You should not be using PDFs, and the reasons in my article still stand. Feel free to test this yourself. I just built another test project with an iOS 11.1 deployment target, and it created PNGs for the PDF asset I gave it (please note that you have to use the assets somewhere for the PNGs to be generated).
For iOS, assets should be vector images and rendered as templates. This gives you the flexibility of settings a tint color.
You can do that with PNGs, too. You can do it on iOS and Android, without using vectors.
I’ve just updated my article. Here’s another huge downside:
…the asset catalog now contains 3 PNGs. Those PNGs aren’t the same as PNGs you’d create yourself, either. Xcode’s PNGs were 20837 bytes total, exporting them from Sketch resulted in 17324 bytes, and running the Sketch PNGs through ImageOptim with lossless compression reduced them further, to 4115 bytes. Using a PDF vs using PNGs in this instance made the assets take up 5× the disk space.
Just re-read your post, created a sample project and I don't think you have your Xcode settings for image assets set up correctly. I did exactly what you did with a vectorized PDF and i only have one vectorized pdf asset in my .car file. You need to adjust your settings in the attributes inspector to have lossless compression, and only a single scaled image.
I'll retest everything this weekend, but I think there is some misinformation in that article. This article goes more in depth into what you may be missing[1].
I’ll have to do some more tests, but even if you’re right, surely you understand that you’re now saying you can use PDF assets, but only if:
What are the chances most designers and developers have a firm grasp on any of those points, let alone all of them? I’d put it at close to zero for most teams and projects. The safer option is to not use PDFs.
While you’re testing, please keep in mind that the PDF has to be used somewhere for the PNGs to be generated.
Of those four bullet points, none of them are really a compelling argument for not using vectorized PDF's when you can. The only point that is viable is from the blog post:
PDFs can’t be used for web or Android assets. Mac apps can use PDF assets, and they’re rendered at runtime, giving many benefits over iOS’ implementation.
To your points...
What are the chances most designers and developers have a firm grasp on any of those points, let alone all of them?
Why don't you update the blog post and show developers and designers on how to set up their projects correctly? Let's educate the community on how to use tools properly.
Edit: This response is to far to the right — I'll do a blog post about this.
Of those four bullet points, none of them are really a compelling argument for not using vectorized PDF's when you can.
My main concerns are that there’s very little benefit, and the knowledge required to pick and choose when, and set up Xcode properly isn’t something most people understand. The safer option is to tell people to not use them.
Using them in a limited scope is fine
This is the issue. Look at the replies here. Lots of people ONLY use PDFs, because they don’t know when they can be used, and when they should be avoided.
I use Affinity Designer, but Sketch, Photoshop, and Illustrator all support vectorized PDF's.
Those tools have varying levels of success, especially if you want automated exporting. Photoshop fails in this regard (Save for Web, Export As, and Generator can’t export PDFs). I haven't recently tested its PDF output, but its SVG output is atrocious. The others have some issues that you need to be aware of when shipping vector data as assets (stroke position etc). It’s not a slam dunk if you see “PDF” listed in the export options.
That’s just not a concern with bitmap assets. They always work, because the tool renders them. It’s a simple format.
Why don't you update the blog post and show developers and designers on how to set up their projects correctly? Let's educate the community on how to use tools properly.
I still very firmly believe that even if there are advantages, they are not worth the hassle. There’s so many ways things can go wrong. It’s unlikely I’ll write about a process I don’t use myself.
Happy to continue this conversation elsewhere (not sure where though).
Some months ago, I tweeted about the same thing. Here is my export options: https://twitter.com/ckor/status/844165179755679744
I searched on DN and saw your post but it's sad no one posted a single comment. I was planning to ask how do you use SVG and PDF in iOS and Android? It's a nice coincidence you commented here :)
iOS supports PDF as the main vector format for icons. Android supports SVG for vector icons.
Unfortunately you can't do that for pictures, but I usually export only one big picture when I wanna use images inside the app, so every phone can use the highest resolution scaled down.
--
More on how iOS is using PDF. By using one PDF icon iOS is generating all the needed @2x @3x assets during app compilation, so technically you don't save a big mount of app size, but you save exporting time and the asset management becomes easier.
That's really great. Thanks for the explanation. Didn't know pdf is used by iOS but I think I should test some edge cases such as inner shadows and gradient border fills done by sketch. If it works with them, it will be better word :)
I wanna use only big picture too and I wonder if anyone tested whether scaling down the image affects device performance, and how optimised the process is. I will give an image in the highest device size (e.g 1920x1080) and iPhone 5 will resize it to 1136 x 640 and this process will take some time. I need to make sure it doesn't effect in a considerable amount for old devices.
PDFs don’t natively support layer styling features, so things like inner shadows, shadows and most gradients get rendered as a 1× bitmap in the PDF. The end result is 1×, 2×, 3× assets generated from 1× bitmap images.
Don’t use PDFs if you care about the quality of your work.
technically you don't save a big mount of app size
Using PDFs for iOS assets can make them bigger, and you can cause some significant quality losses. My advice would be to never use PDFs for iOS assets (I’ve written more about PDF assets and why they’re bad.
Android supports SVG for vector icons.
Android Vector Drawables are really good, but not without their caveats. You need to be extremely cautious about how you create the artwork, which Android versions you target, and the code used to render them. I gave a talk recently on the topic with a smart developer: Build Better Android Apps with Vector Assets
It’s a complex topic. I’m not here to pimp my stuff, but we did tons of research for the talk, and it surprised me how complex the topic is.
From the artwork side, there’s some important things to remember.
Gradients are supported in Vector Drawables, but that’s very much a new feature. Vector Drawables are a small subset of SVG, and they do not have all of the SVG features (thankfully!). You also need to be very cautious in terms of performance — icons need to be fairly simple paths and small render sizes, in places where render time is critical.
remember to run anything you export through tinyjpg.com or similar! Strips out all the unused data, and does a much better job than Photoshop
You need to be super careful of using image optimisation. ImageOptim and others can be really good, but there are some important things to keep in mind:
Maybe @1x could be dropped, not much iOS devices with such a screen these days
Also, as many comments point out ImageOptim and other optimisation techniques: always do it! (and always check your images visually after processing with those tools, you might in some rare cases have surprises, better check than sorry)
You’ll end up with huge files when exporting larger scaled images with PNG. PNG works best when you export singular icons, buttons or something relatively small. I’m guessing that you have a fancy background with a nice image.
You need to export that in JPEG. I know it’s not a developer friendly option but sadly neither your design is. Just check your everyday apps, neither them have a background. That’s just one color.
IF your background has just one colour, you don’t have to deliver that. Actually you shouldn’t either deliver if the component has solid colour. If your dev insists to send him/her bg, that means it’s a terrible developer who doesn’t know what to do.
You are right in every word!
I wouldn't mind if it would be an image with some simple shapes, gradients and shadows as they can be done by the developer (btw I'm also contributing UI development part on the interface builder) but they asked me as an background image of an historical place so should give them a picture.
Ah, clients. I can understand man. Here's a trick I've done before for such request.
I was requested to place a huge-ass image (like your case) on the background without loosing any quality - which was kinda impossible.
So drew a diagonal black line pattern on it and merged the image with the line. And then I actually deleted the black lines from the image and exported as a transparent PNG -with #333 matte (because dev insisted me to deliver in only PNG’s for some reason) It look pretty neat on a #333 background colour.
The results weren’t dramatic but it was enough to have in the app.
This is a project specific solution but I just wanted to share since you’re in a similar position like I’ve been before.
Good luck mate.
That's very smart actually.
I wonder how it looks. Is it distinguishable by the client?
1) Yes export the images for all sizes, but you need to compress them to not impact the app size if possible.
2) You can make this happen automatically by installing Image Optim & the Image Optim plugin for Sketch
3) Once you install Image Optim. Enable Guetzli in the preferences. Guetzli is a new type of image compressor by Google which removes the data from a picture your eyes can't see. The image itself appears unchanged but it results in a dramatic drop in file size. It works best on JPGs (For your background images).
Be aware Guetzli is a resource hog and can take a while to compress an image. Image Optim will select the best compression mechanism for your exported image and do this for you so don't worry about having to run the compressor multiple times and check the result.
Once you have eveything setup you should only need to export your assets as normal from sketch and the rest will happen automatically :-)
Thanks Vincent, this is super useful. Trying it out now.
Login to Comment
You'll need to log in before you can leave a comment.
LoginRegister Today
New accounts can leave comments immediately, and gain full permissions after one week.
Register now