Xcode and Asset Catalogs: Love Em or Leave Em?
I’ve never been to a WWDC, but each year I get positively gitty when the session videos become available. And what do I get the most excited about? No, not Passbook, iCloud, or the big-ticket stuff. No, I like the small stuff. The simple stuff. The stuff that improves my day-to-day and fixes things I constantly find annoying.
This year, that something was Asset Catalogs.
Why Asset Catalogs? Well, simple. Ever since we got the iPhone 4 in all it’s retina glory, I’ve always found it frustrating to manage keeping TWO versions of every graphic. (The original and it’s double-resolution version.) There’s so much monotony in it:
- I need to keep all the files paired together in Xcode, in the right order. (Partly due to OCD, partly due to basic organization.)
- I need to make sure they’re both named EXACTLY the same.
- If I want to rename an image, I GOTTA DO IT TWICE.
- I hate how much space it takes up on the Project Navigator when the folders inevitably all expand.
- I need to make sure the @2x is exactly twice the dimensions of the original. (Designers always flub this.)
Sadly, Asset Catalogs don’t fix #5, but they do help us a ton with the other four, and hey, that ain’t bad! Still, not all is rosy in a catalogued world, so let’s take a look, shall we?
Asset Catalogs: The Good
No longer do you have to bother keeping your images paired next to each other in XCode (you *do* that, right?) Asset Catalogs allow you to specify retina and non-retina versions together in one spot.
Now, you simply drag your images into the the catalog and then drop their countertops right alongside them. They’re still files, too, just right-click and reveal them in Finder to see. This is lovely! It also alleviates the need to keep the naming in sync since they share one name.
Even nicer, you no longer have to manage the naming of fifty-billion Icon images for all the different device models and iOS versions Apple has out there. (And there’s no single standard.) You simply specify to use your Asset Catalog and it’ll find all the right sizes for you.
As an extra bonus, it’s much easier to browse through all your images and make sure you have both versions! This is really nice for older projects that pre-dated retina, though you’ll still have to migrate to asset catalogs first. In the old days, verifying the retina images involved a sharp eye as you scrolled through lists of filenames.
Asset Catalogs: The Bad
Bad? How can they be bad? We’ve already seen how Asset Catalogs keep the image files organized, correctly named, and easily viewable. What more could you add?
Well, there’s something that we lost. You can no longer Command-Shift-O to look for an image. Try it. Now, why would you want to do that? Well, sometimes I’m crawling through code and I find code loading an image:
UIImage *buttonImage = [UIImage imageNamed:@"btn_clear"];
Hmm, what is that image, let’s Command-Shift-O and…oh. No image. I found this REALLY useful before. Now, if you want to search for an image, you need to open your Asset Catalog and do your search in the field in the bottom left corner.
It’s not hard, but it’s bulky and involves multiple steps. I really hope they add this to the indexer someday. And one more thing, and if you’re familiar with this search then you know where I’m going, have you noticed the search bug? Yes, hopefully it’s temporary, but Xcode will often persist your search forever. Got Xcode in front of you? Enter an asset search, clear it, tap another file in the Project Navigator, then tap the Asset Catalog again.
HOORAY! You’re locked into your search again! Ugg. Fix it, Apple!
One Final Quirk
Another little annoyance to Asset Catalogs, that hopefully will change in the future, is that Test Flight still wants to see an Icon.png file in your uploaded apps. The only way around it is to include a separate icon image in Xcode and add an icon entry back into the plist.
I’m sure this will get cured in the future as well, but for now if you use TestFlight you should keep a regular icon file around.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)