I just spent a few days enjoying all the iOS 10 UIGraphics renderer utilities for images and PDFs and wide colors and so forth. It’s lovely. I thought I’d share a post comparing the old world and the new.

Old

Remember this?

// Create a color space
CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB(); 
if (colorSpace == NULL) {
    NSLog(@"Error allocating color space");
    return nil; 
}

// Create the bitmap context.
CGContextRef context = CGBitmapContextCreate(
    NULL, width, height,
    BITS_PER_COMPONENT, // bits = 8 per component 
    width * ARGB_COUNT, // 4 bytes for ARGB 
    colorSpace,
    (CGBitmapInfo) kCGImageAlphaPremultipliedFirst); 

if (context == NULL) {
    NSLog(@"Error: Context not created!"); 
    CGColorSpaceRelease(colorSpace ); 
    return nil;
}

// Push the context.
UIGraphicsPushContext(context);

// Perform drawing here

UIGraphicsPopContext();

// Convert to image
CGImageRef imageRef = CGBitmapContextCreateImage(context); 
UIImage *image = [UIImage imageWithCGImage:imageRef];

// Clean up 
CGColorSpaceRelease(colorSpace ); 
CGContextRelease(context); 
CFRelease(imageRef);

New

let image = renderer.image { context in
    let bounds = context.format.bounds
    for amount in stride(from: 1.0 as CGFloat, to: 0.0, by: -0.1) {
        let color = UIColor(hue: amount, saturation: 1.0, 
            brightness: 1.0, alpha: 1.0)
        let rects = bounds.divided(
            atDistance: amount * bounds.size.width, from: .maxXEdge)
        color.set(); UIRectFill(rects.0)
    }
}

and

public func imageExample(size: CGSize) -> UIImage? {
    let bounds = CGRect(origin: .zero, size: size)
    let colorSpace = CGColorSpaceCreateDeviceRGB()
    let (width, height) = (Int(size.width), Int(size.height))
    
    // Build Core Graphics ARGB context
    guard let context = CGContext(data: nil, width: width, 
        height: height, bitsPerComponent: 8, 
        bytesPerRow: width * 4, space: colorSpace, 
        bitmapInfo: CGImageAlphaInfo.premultipliedFirst.rawValue) 
        else { return nil }
    
    // Prepare CG Context for UIKit
    UIGraphicsPushContext(context); defer { UIGraphicsPopContext() }
    
    // Draw to context using UIKit calls
    UIColor.blue.set(); UIRectFill(bounds)
    let oval = UIBezierPath(ovalIn: bounds)
    UIColor.red.set(); oval.fill()
    
    // Fetch the image from the context
    guard let imageRef = context.makeImage() else { return nil }
    return UIImage(cgImage: imageRef)
}

and

extension UIImage {
    public func grayscaled() -> UIImage? {
        guard let cgImage = cgImage else { return nil }
        let colorSpace = CGColorSpaceCreateDeviceGray()
        let (width, height) = (Int(size.width), Int(size.height))
        
        // Build context: one byte per pixel, no alpha
        guard let context = CGContext(data: nil, width: width, 
            height: height, bitsPerComponent: 8, 
            bytesPerRow: width, space: colorSpace, 
            bitmapInfo: CGImageAlphaInfo.none.rawValue) 
            else { return nil }
        
        // Draw to context
        let destination = CGRect(origin: .zero, size: size)
        context.draw(cgImage, in: destination)
        
        // Return the grayscale image
        guard let imageRef = context.makeImage() 
            else { return nil }
        return UIImage(cgImage: imageRef)
    }
}

Okay, I admit the bitmapInfo is still a little ugly, but isn’t the rest of it grand?

• No more hacky UIGraphicsBeginImageContext()/UIGraphicsEndImageContext() stuff, let alone getting image from context. Why wasn’t it like this years ago?
• I do love my Swift constructors. Creating the CGRect from the size is much cleaner now.
• If you want Core Graphics, Swift gives you Core Graphics: there’s still good reasons to create custom contexts (for example, device gray color spaces) or otherwise work at a low level without having to fire up Accelerate, Core Image, or other power frameworks.
• You can pair the graphic stack context push with its pop if you do need custom context work. I love defer pairs that prepare for cleanup at the same time you do set-up. (We need to extend Swift reference types to allow paired deinit tasks too!)
• Swift handles all the memory management. All of it!
• Swift optionals and errors let you fail so much more gracefully.
• As you’d probably expect, PDF drawing is just as easy as working with images.
• The “hoisted” CG utilities (like CGRect’s divided(atDistance:, from:) and the context’s draw and makeImage) are lovely too.

I’m seeing the light at the end of the tunnel for Swift Style wrapping up. Anyone interested in me revisiting “iOS Drawing” for Swift? Or are there other topics you’d rather me follow on?

McFly says: I keep getting the following error and can’t seem to find solution on stackoverflow: “Cannot convert value of type ‘String?’ to type ‘NSString’ in coercion”

First the answer: you have to unwrap an optional before casting it to a different type.  “String?” means a value is stored within an Optional enumeration, which can contain a value or be nil. That’s why you’re getting the error.

You don’t want to force unwrap so you’ll want to conditionally bind that string and cast it to NSString. But before going there, let me step back a moment and discuss why you have an optional string to begin with. You may have used an optional initializer, or called a function that returns an optional string:

let test = "abcdef"
let optionalString = String(test)

Or you more typically may have looked up a key in a dictionary, and your variable is actually typed as Any?, not String?.

let optionalValue = dict["key"]

The thing that kept nagging at me is that it’s pretty rare to pick up optional strings and then want to convert them to NSString. At first I thought McFly was pulling values from a JSON dictionary or the like (which is [AnyHashable: Any]) but the error message for calling a function that expects an NSString value with an Any optional is “error: cannot convert value of type ‘Any?’ to expected argument type ‘NSString'” so no, he really was working with String? and NSString.

I asked McFly why he had a String?, and it turns out he was using this API:

My Post class has the following declared:

private var _imageURL: String?

In any case (leaving apart the sin of naming a string as “URL”, argh), given this scenario, you have two goals:

1. Safely unwrap the value to get at the string
2. Convert that string to NSString so you can pass it to the function

Don’t do this:

functionCall(string! as NSString)

Forced unwrapping kills Tinkerbell quicker than kids who refuse to applaud. Instead, conditionally unwrap and *then* cast:

if let string = optionalString {
    myFunction(string as NSString)
}

(And yes, you usually shadow with the same name as the optional string so you don’t accidentally collide with a different existing symbol. I wanted to make clear the roles of the newly bound unwrapped variable and the existing optional string)

To do everything at once, so you have a bound local variable that stores an NSString instance, you can cast your optional string to Optional<NSString> and then conditionally bind:

if let string = (optionalString as Optional<NSString>) {
    myFunction(string)
}

This solution is easy for new devs because you can explain: “What you’ve got is an Optional<String> and what you want is an Optional<NSString>, so cast with as, which can be checked at compile time and is guaranteed to succeed.

Experienced developers might prefer optional mapping:

if let string = optionalString.map({ $0 as NSString }) {
    myFunction(string)
}

This is not an especially obvious solution for new learners. Assuming you’ve already gotten past the basic concept of optionals that can store either a value or nil via the Optional enumeration, picking up the notion of  “mapping” optionals let alone collections isn’t intuitively clear especially without an existing background in  functional languages.

The nice advantage to this approach though is that it easily expands to type-erased casting. Substitute flatMap for map so you don’t conditionally bind an Optional(Optional).

if let string = string.flatMap({ $0 as? NSString }) {
    myFunction(string)
}

In any case, I told McFly, I’d write this up. And, as it turned out, I cut out about half or more of this post to save for another day because there are some particularly interesting ways that Swift handles casting “Any?” lookups from dictionaries.

As always, I’m sure I probably messed up somewhere in this post, so I invite you as always to offer feedback and corrections. Thanks!

I put up a poll asking whether it was good style to move attributes and access modifiers to their own line. Results are here.

My take on things after the poll and after talking directly with a number of developers is this: Placing attributes like @objc, @testable, @available, @discardableResult on their own lines before a member declaration has become a conventional Swift style.

@objc(objectAtIndex:)
internal func objectAt(_ index: Int) -> AnyObject {

@available(*, unavailable, renamed: "Iterator")
public typealias Generator = Iterator

@discardableResult
func _copyContents(initializing ptr:
UnsafeMutablePointer<Iterator.Element>)
-> UnsafeMutablePointer<Iterator.Element>

This approach limits declaration length. It allows a member to float below its attribute and supports flush-left access modifiers, so `internal`, `public`, etc appear in the leftmost column. Many developers mix-and-match styles for short Swift attributes like `@objc`. It is common to see `@objc(countByEnumeratingWithState:objects:count:)` on its own line while `@objc` moves down to the primary declaration, particularly for single-line declarations:

@objc internal var count: Int

@objc internal final class _SwiftDeferredNSArray
: _SwiftNativeNSArrayWithContiguousStorage

Others prefer to break attributes out universally, regardless of length. This approach is consistent, and it promotes consistent leftmost access modifiers:

@objc
internal var count: Int

@objc
internal final class _SwiftDeferredNSArray
: _SwiftNativeNSArrayWithContiguousStorage

This comes up often enough that I’m wondering whether it would be nice to have something standard-library-y in a zip-ish kind of way to handle it.

I put together this. Thoughts?

https://gist.github.com/erica/0aad0d8fc0b7a982e542c4b28ce53fc5