How #available works in Swift

This article from the Big Nerd Ranch blog goes back to 2016, but it’s a great little rundown by Mark Dalrymple of #available, introduced back in Swift 2.0.

Hi! I’m #available!

Sometimes we just use language features like this and don’t really think about what’s going on under the hood when we use them, or perhaps we have a mental model based on past assumptions. However, Mark does a an excellent job filling in some of the details on this handy feature of Swift, explaining not only what it is but also what it is not.

The article also clarifies Xcode’s Target SDK version and Deployment Target version, which can initially be a point of confusion to many developers on the iOS platform.

Here’s a great summary of the article from the article itself (a TLDR;):

The take-away points: #available is not #if—it is not conditional compilation based on OS platform. Instead, at compile time, #available tells the compiler to temporarily raise the SDK level above your deployment target so that you can safely use newer API. At run time, the code will execute depending on the version of the OS the app is running on.

Handy Swift Resource: Hacking With Swift’s Auto Layout Cheat Sheet

This is a pretty great one-stop-shopping resource for Auto Layout by Paul Hudson.

The Auto Layout cheat sheet – Hacking with Swift

Auto Layout is a powerful tool for creating flexible, maintainable rules for your user interface. It can also be a real brain vortex if you’re unlucky – it’s something that makes hard things easy and easy things hard.

To help relieve the pain, in this article I’ve put together code snippets to solve a variety of common Auto Layout problems: creating constraints, animating constraints, adjusting constraints at runtime, and more.

As with all of Paul’s articles, it’s well thought out, and it’s a useful resource to stash away for the next time you need to do in-code work with Auto Layout and Swift.

It is disappointing that he does not use the word “vexing” anywhere this blog post as I had thoroughly expected him to do (and would have been so appropriate in any article about Auto Layout), but the tips are so good, I’ll overlook it this time.

Excellent resource.

When Worlds Collide: How to call complex Objective-C selectors from Swift

When developing in Swift, you will eventually need to interact with Objective-C APIs. Most of the time this is fine, and fairly straightforward to do using #selector.

However, every once in a while you will need to invoke an Objective-C selector that you did not write (usually when the selector is part of the iOS or macOS SDK), does not have a unique signature, or is just pretty hard to figure out.

This article put out by Big Nerd Ranch’s Mark Dalrymple is an excellent rundown of how to properly invoke Objective-C selectors from Swift. He even covers really hairy signatures that may be very difficult to come up with on your own at first glance.

Big Nerd Ranch — Hannibal #selector

The selector is key to Objective-C’s dynamic runtime nature. It’s just a name that’s used, at runtime, as a key into a dictionary of function pointers. Whenever you send a message to an Objective-C object, you’re actually using a selector to look up a function to call. Sometimes selectors bubble up in Cocoa/CocoaTouch API, and you will need to deal with them in Swift.

Zero to BLE Part Two Core Bluetooth Post Updated for Swift at Cloud City Development Blog!

I’m happy to announce that I recently updated Part Two of my Zero-to-BLE series on Core Bluetooth Post Updated for Swift at Cloud City Development Blog! It’s been updated for Swift 2, because when I wrote it, Swift 3 hadn’t officially been released and I honestly thought it would be published well in advance of the September 7 Apple Event.

Zero to BLE on iOS – Part Two – Swift Edition

Better late than never!

Who knows? Maybe there will be a Swift 3 version in the future? For sure all my code samples will be in Swift 3…

Hope you like it!

Syntax highlighting for Swift in BBEdit and TextWrangler

Big thanks to Curt Clifton (https://github.com/curtclifton – his bio indicates that he’s with the Omni Group!) for creating this codeless Language Module for Swift that can be used in BBEdit and in TextWrangler.

A BBEdit Codeless Language Module for Swift

Curt indicates there are some limitations to codeless language modules:

Keyword, comment, and string highlighting work. Top-level classes, structs, enums, functions, and extensions are indexed and can be folded. Because of limitations in the matching power of codeless language modules, nested declarations are not indexed and are not fold-able.

However, it works great if you want to do some Average Joe coding in Swift in TextWrangler or just see your .swift files highlighted outside of Xcode.

Installation is super easy:

BBEdit

  1. Copy the file swift.plist to ~/Library/Application Support/BBEdit/Language Modules. You may have to create the Langauge Modules folder if it doesn’t exist.
  2. Quit and relaunch BBEdit.

…and for TextWrangler it’s just as simple:

TextWrangler

  1. Copy the file swift.plist to ~/Library/Application Support/TextWrangler/Language Modules. You may have to create the Langauge Modules folder if it doesn’t exist.
  2. Quit and relaunch TextWrangler.

Smoother transitions when showing a View Controller with a UINavigationBar in Swift

Here’s the scenario. You want to display a modal view controller without a navigation bar, and then from that view controller you want to navigate to another view controller that displays a navigation bar.

First to get things set up, in the Storyboard we set up the view controller that would be displayed modally. We create a view controller, perform the Editor -> Embed in -> Navigation Controller. Then, in the viewWillAppear method, we hide the navigation bar programmatically.

It turns out that there are two ways to do this and, at least in my case, one way turned out to be better than the other. The first way I tried worked, but the animation for the transition from one view controller to the next looked a little odd.

The first way is the more obvious of the two, because you can simply just set the hidden property of the navigationBar like in the following example:

self.navigationController?.navigationBar.hidden = true

There is also another way to do the hiding and showing of the UINavigationBar, and the second way is do do it via the UINavigationController, as in the second example:

self.navigationController?.setNavigationBarHidden(true, animated: true)

There are two advantages to doing it the second way. First, because you get a method to hide and show the navigation bar, you get the additional animated parameter that you can set.

The second advantage is that when you use it in this way with the animated parameter set to true, iOS performs a slightly more smooth transition.

Your mileage may vary, so try both ways and see which you personally like best.

How to create an Objective-C Bridging header

Super important to know during this time of Objective-C to Swift transition. I’ve had to use this technique and it will be good for all Swift developers to have in their kit-bag until we can finally be 100% Swift.

How to create an Objective-C Bridging header – iOS-Blog
So you want to use an Objective-C Library or SDK in your Swift application eh? Well do not fret. This quick tutorial will show You how you can create an Objective-C Bridging Header in your Swift application so you can use them both together and seamlessly.

UIView Animation with Swift

Here is a very simple way to do UIView Animations in Swift.

First, you create an IBOutlet for a constraint created in Interface Builder in Xcode – in my case, I had a constraint that anchored to the bottom of the containing view. In the code example, the constraint is named “constraintToAnimate”. You just control drag from the Storyboard to your code as you would when connecting a control, but in this case you connect a constraint. It will look something like this (the name of your constraint will hopefully be different):

    @IBOutlet weak var constraintToAnimate: NSLayoutConstraint!

The following snippet is basically a straight-up conversion of Apple’s own Objective-C example given in the documentation article Auto Layout by Example in the Animating Changes Made by Auto Layout section (you may need to scroll down to find that section).

    self.view.layoutIfNeeded()
    UIView.animateWithDuration(0.3, animations: {
        // make constraint changes here...
        self.constraintToAnimate.constant = 250 // your value here.
        self.view.layoutIfNeeded()
        }, completion: {
            (value: Bool) in
            // completion code here...
    })

Basically, in pre-Auto Layout days you would just animate the frame. Today you just animate the constraint. It works great and once you get your head wrapped around it, it’s pretty straightforward.