When it comes to dynamic templating of apps sometimes it’s helpful to determine at runtime if two colos have enough constrast so that one can be the background color and the other the foreground color. The W3C defines in it’s Web Content Accessibility Guidelines (WCAG) 2.0 a formula to find this ratio. Let’s take a look on how to implement this calculation using a Swift UIColor extension. We start by creating a simple UIColor extension:
Swift Array contains a lot of quality of life functions that help the developer code operations on Array elements. One thing that the Swift Standard Library falls short is in it’s ability to remove duplicates from an Array. By leveraging Swift Extensions we can create a function that enhances the Swift Array built-in functionality to remove duplicates, provided their element conforms to the Equatable protocol. We begin by writing a Swift Array Extension, specifying that it should only apply if the Element conforms to Equatable.
While working on a past project, a requirement was to set the background colour of a button with a specified colour retrieved from a REST API endpoint. This colour was a HEX string value in the format #FF0000. Unfortunately, UIKit has no UIColor constructor that receives a colour in the Hex format, so I needed to implement a way to achieve this. Firstly we need to understand what colour in the Hex format is.
(At least for me…) I have been developing iOS apps for the past 5 years, much has happened then in the world of iOS development. Objective-C is starting to (slowly) be replaced with Swift and if you don’t master Auto Layout yet, you should definitely consider it heavily. However as much as something changes I always have this gut feeling, that programming for iOS could be done better, cleaner, and that it has nothing to do with the OS itself, or even how Apple develops their APIs, but instead how you think your code, and ultimately how you structure it.
