UIColor and UIImage in Xcode 8 using literals

Working with UIImage and UIColor from code was not very convenient, because it is difficult to imagine the color UIColor(red: 0.2, green: 0.4, blue: 0.6, alpha: 1) or UIImage(named: "pattern25") if you are not a designer , of course.

For me, it was a miracle that Apple did in the latest versions of the Playground, namely

• The ability to specify a color by choosing from the color palette:

• The ability to choose an image from those that are in the resources:

The color is presented very clearly and when you click on it, you can find out what RGBA values ​​it has and adjust it as necessary.

Thumbnails of pictures also look much clearer than just the names of resources. Also, by initializing a UIImage with a failable initializer init(named: String) -> UIImage? we risk getting nil by incorrectly specifying the name of the resource. Literals always return value.

Recently, delving into the settings of the wonderful SwiftLint linter , I discovered that there is an optional object_literal rule in it that requires colors and images to be indicated from the code using literals. Really, I thought, did the benefits of PlayGround become available in Xcode? It turned out to be true. The truth, which miraculously passed by me and, possibly, by many developers. Therefore, I think it would be useful to share my little discovery with the public.

It turns out that by setting a variable of type UIColor in the code, we can start writing color

And, if we choose Color Literal , a palette of color selection will appear and it will be possible, for example, to specify cgColor like this:

With pictures the same story, you can write

and then choose from the gallery of thumbnails of pictures, or if we know the name of the picture, you can just start to write this name and Xcode will offer options for pictures from assets in which the entered name is found. As a result, we get the following line:

The code creates an invisible line #imageLiteral(resourceName: "ocelot.jpg") , which is replaced by a picture and the name of the resource, but if we start typing this line manually, we will achieve the same effect.

Conclusion

The code in which colors and images are presented visually, it looks very well and concisely. In addition, the use of picture literals allows you to immediately notice where something went wrong. If we, for example, remove our ocelot from assets, the code will look like this:

And we can return the missing cat to our application before the compilation begins. Than, we will probably save a lot of time when testing.

Read more about this in the WWDC 2016 Sessions of the Using and Extending the Xcode Source Editor.