A Beautiful Solution to Non-Optional UIImage Named in Swift

Yesterday, I got around to watching the Swift in Practice WWDC15 Session, and I LOVED the suggestion for dealing with Image naming in Swift.

The big issue of course is that UIImage:named: takes a hard-coded string, and returns an optional UIImage. That means dealing with potential mis-spellings and unnecessarily unwrapping optionals throughout your application.

Of course one way to deal with this is to have one file of Image Constants, but that doesn’t deal away with the optional image problem. With Swift, there is an even better solution. You can extend UIImage to include an enum of all your image names, and create a convenience initializer that initializes your image via an enum:

So now, whenever you need to use an image anywhere in your application, you just initialize it like this:

Note how clean this is! First, you get to use a nice enum value – no more hard-coded Strings! Oh, and the enum auto-completes for you! And second, the image is no longer an optional – you’re guaranteeing that it’s there.

One of my favorite take-aways from this WWDC session is the notion of letting the compiler help you. By using an enum value for image names, you’re getting the compiler to do the work of auto-completing and checking that your image is there.

I wanted to test this out for myself, so I created a small sample project on Github here. Check it out if you’d like to see how this would be used in an application.


As several people pointed out, there are open source libraries that with a script for exporting your image names into enums.

Check out:

Feel free to add any additional ones in the comments!

Enjoy the article? Join over 20,000+ Swift developers and enthusiasts who get my weekly updates.

  • Perluete

    You still have to spell correctly all the AssetIdentifiers. We still don’t have that “R.” ressources autocompletion like in Android IDEs. have a look here https://github.com/AliSoftware/SwiftGen & here http://www.jessesquires.com/swift-namespaced-constants/

  • Jason R Tibbetts

    The init! can, of course, still fail.

    • Natasha Murashev

      Yes, that is true. According to the video, they expect you to force unwrap UIImages that you know are there in your asset catalogue, which doesn’t feel good but you know it’s there, so I’m fine with using force unwrapping in this case. You’ll know if the image is not there (or if you misspelled something) right away, before shipping to customers.

  • Siddhesh Mahadeshwar

    Will this work with objective C as well ?

    • Adam Waite

      Nah, can’t back an enum with a string. Make an NS_ENUM with your image names and a category method on UIImage to switch through the enums returning a string. That’s the closest you’ll get.

  • Alex Gra

    You can look this library

  • Izk Rivera

    The compiler does not check “that your image is there.” It just checks that the enum case is there. The image could still be missing. And now instead of dealing with an optional, you have a crash. However, this should be caught easily during development and, depending on the project, could save a ton of boilerplate code.

  • Thomas Hanning

    Nice idea!
    However, if the file name of an image changes one day, you have to change the identifier as well. So I think it would be a good idea to assign raw values.


  • As some people have said, this can still fail, but this is still a good solution because:

    – Yes, you still have to use the correct spelling for the image – but at least you only have to do it once, the rest of the time the enum name will autocomplete for you.
    – Yes the initialiser can still fail if the image doesn’t exist but this can be mitigated by a) having unit tests for your images (we have test coverage now!) b) using a script that generates the extension from your asset catalog (look on GitHub, there are many).
    – The code at the call site becomes more declarative.

    All wins in my opinion.

  • John Mejia

    Have you looked at KSImageNamed Xcode plugin, it will autocomplete image names and avoid mis typing.. This solution is nice, but it’s just more code to maintain every time you add an image, and the possibility of typos still exist: