July 2015 — Coding Explorer Blog

With all of the new and awesome APIs that come out every year for each successive iOS version, it can be tempting to just drop support for the previous versions of iOS, and just go completely to the new stuff. Of course though, we usually can’t do that for many reasons. As such, we need to support older versions of iOS, and maybe dropping the oldest ones after they just become too difficult to support, or when active users on that platform drop to a certain amount.

There have been ways to check for API availability for some time, by checking if something responds to a selector, or just checking the iOS version ourselves and using that in a normal Swift “if” statement. With the arrival of Swift though, we have an even nicer version of API checking, that is even helped by Xcode itself. This allows Xcode to actually warn you if you try to use something that is unavailable on one of the deployment targets for your Swift app.
[Read more…]

So, if you’re using a class, structure, or enumeration which did not provide a method that would be very helpful for your app, you could simply add it via an extension (which you can read more about in the posts Swift Extensions Part 1, and Swift Extensions Part 2). With extensions, you can easily add methods to a type that builds upon the existing types. One of my favorites is writing my own UIColor convenience initializer (shown in the post How to Create a UIColor in Swift), that takes a value between 0 and 255, and hardcodes the alpha to 100% opacity. I definitely understand why the authors did it the way they did, it is general so you can do many things with it, but I didn’t want the boilerplate required to convert my 0-255 based RGB values, and I CERTAINLY didn’t want to set the alpha to 100% each time when it would never be anything else in my app.

Well, that’s great and all for classes, structures, and enumerations…. but what about protocols? In Swift 1, you could write your own protocol and have methods in it that would then have to be implemented by those types that adopt the protocol… but if it doesn’t have a method you need, the only thing you could do was either write an extension for each type that adopted the protocol, or write it as a global function. That’s exactly what Apple did for a lot of functions in Swift 1, particularly many that worked with several CollectionTypes like Arrays, Dictionaries, and Sets.

With the coming of Swift 2 though, we now have a recourse that no longer requires global functions. Now you CAN extend protocols with Protocol Extensions. You can even provide default implementations for these methods defined in those protocol extensions!

[Read more…]

API Availability Checking in Swift

Protocol Extensions in Swift

Archives for July 2015

Subscribe to the Coding Explorer Newsletter