Lord Codes » iOS & Swift Feed

Installing and running Swift tools with enforced versions

2023-12-21T00:00:00Z

Working on Swift projects often involves using tools to help with tasks such as linting using SwiftLint or generating code using Sourcery. When running tools we want to ensure all developers of the project are using the same version and that a specific version can be chosen to ensure compatibility. For most Swift tools there is the choice of many different installation methods, each with its own benefits and drawbacks, so for many people it might not be obvious what the best option is.

Before we look at the installation methods, let's consider what we would like to be able to do:

Enforce versions between team members
Use a specific version for each project
Use the same version locally and on CI
Install tools quickly

Installation options

Homebrew

Homebrew is a popular package manager for Mac and is useful for installing tools and apps, even allowing use of a Brewfile. Unfortunately, unless a particular version is provided as a formula we cannot install a specific version, instead we would need to require team members to update to the latest version. On top of this some tools may not be published to Homebrew and releases can take longer to arrive.

Swift Package Manager Plugins

SPM has support for command and build-time plugins, linking to specific versions. Unfortunately, adding them to Xcode projects only allows running command plugins via the UI, so we would need an SPM package with a Package.swift to run them from the command-line. Depending on the tool we are running we may need to build our own plugin.

Cocoapods

Many tools offer installation via Cocoapods and running them from the Pods directory. Although we can pin to a specific version, not all tools will be available via Cocoapods. The main issue is that it requires the project to already be using Cocoapods or to add Cocoapods to it, which is Ruby-based.

Mint

Swift tools can be built and installed using Mint, where we can enforce versions using a Mintfile. We will of course need another method for installing Mint at the right version itself. Many people use Mint happily, however it can be very slow building tools from sources when the version changes, particular on CI where we will need caching to avoid this happening for every build.

Binary or cloning

Instead of using a package manager, we could download the tool as a binary from the GitHub release or clone the repository and build it for ourselves. It will be difficult to ensure developers keep tools up-to-date and so the approach will likely involve maintaining some scripts.

An alternative approach

For many teams one of these installation methods may be the right approach, however they do come with some potential drawbacks:

It may not be easy to use or error-prone
Specifying and enforcing the version may not be possible
Installation may involve building the tool from sources with its dependencies
One of the tools may not support a particular installation method
Our project may not be using Cocoapods or SPM

For a while I have been successfully using binaries wrapped with scripts to manage download, installation and execution. For developers it is much quicker than any method that builds from sources, it ensures consistent versions and it isn't dependent on use of any external package managers.

The scripts

First, we need to create a folder in the project to store the tools and then a script for the tool in question, such as swiftlint.sh. We start the script by specifying the version at the top where it is easy to update.

VERSION="0.54.0"

We need to calculate the installation directory based on the script location. Make sure to add BuildTools/Tools to the gitignore to avoid binaries or sources being added to source control.

BASEDIR=$(dirname "$0")
INSTALL_DIR="${BASEDIR}/Tools/SwiftLint"
EXECUTABLE="${INSTALL_DIR}/swiftlint"

SwiftLint is provided as a binary on the GitHub release so we can download the version we need.

DOWNLOAD_URL="https://github.com/realm/SwiftLint/releases/download"
DOWNLOAD_URL+="/$VERSION/portable_swiftlint.zip"

We can now write our install function which will download and unzip the binary, before marking it as safe to execute on Mac.

function install_tool {
    mkdir -p $INSTALL_DIR
    curl -LO $DOWNLOAD_URL --output-dir $BASEDIR
    unzip $BASEDIR/portable_swiftlint.zip -d $INSTALL_DIR
    rm -rf $BASEDIR/portable_swiftlint.zip
    xattr -dr com.apple.quarantine $EXECUTABLE
}

If the executable is not already installed, we use our function to install it.

if [[ ! -f $EXECUTABLE ]]
then
    echo "$EXECUTABLE not found, installing…"
    rm -rf $INSTALL_DIR
    install_tool
fi

If the executable is already installed, we check if it is the right version and re-install it if not.

INSTALLED_VERSION=$(./$EXECUTABLE --version)
if [[ $VERSION != $INSTALLED_VERSION ]]
then
    echo "Version out-of-date, re-installing…"
    rm -rf $INSTALL_DIR
    install_tool
fi

Finally, we run the executable, passing any arguments to it.

./$EXECUTABLE ${@:1}

An installable version of the full script is available on GitHub.

Supported tools

Whenever a binary can be linked to for a particular version by URL, such as GitHub releases, it will be compatible with this approach. If no binary is available the script could be adapted to obtain it via cloning and building from the Git tag as a backup.

I have been using this approach to run:

SwiftLint, installable version on GitHub.
SwiftFormat, installable version on GitHub
Sourcery

The installable versions also include details of using them witin Fastlane, which is great for projects that are using Fastlane for automation.

Wrap up

Using scripts to install and run our tools combines the best of the options, whils keeping performance high:

Easy to use
Enforces versions of our tools across the team
Independent versions for different projects
Quicker than approaches that checkout and build from source
Supports local and CI

It would be unfair if we didn't also consider the drawbacks, in that we have to maintain a script for each tool and the approach only works best when there is a binary available for download.

Hopefully eventually SPM command plugins will be executable from the command-line for Xcode projects in a performant way. This would make that the preferred approach due to being built-in and not involving maintaining custom scripts to run.

Manage automation tasks using Swift Package Manager

2020-03-08T00:00:00Z

Now that we have Swift Package Manager for including framework dependencies, wouldn't it be great if we could use it to install and run our command line tool dependencies as well? What if I told you that this was already possible, allowing you to add tools like SwiftLint to your project within Package.swift and run automation tasks easily and with minimal configuration.

When working on software projects there are usually a set of different scripts for running project automation, or maybe a selection of different command line tools all the developers install on their system. For a Swift project many of these tools are written in Swift, yet we still end up installing them with other package managers such as Homebrew or Mint. These package managers are fantastic and perfect for installing our tools, however when we already have Swift Package Manager (SPM) it would be great if we could use that directly.

We will explore setting up all of our command line tool dependencies using Swift Package Manager, discuss how to run them and then move onto how to write automation tasks using a small CLI within our project.

Installing and running

Swift command line tools can be added to our project by simply adding them as a dependency within Package.swift, alongside framework dependencies we may already be using. We will be running the tools directly and so there is no need to add them as dependencies to any of our targets, we just need SPM to download them for us.

let package = Package(
    name: "Uploader",
    products: [
        .executable(name: "uploader-cli", targets: ["Uploader"])
    ],
    dependencies: [
        .package(
            url: "https://github.com/realm/SwiftLint",
            from: "0.39.1"
        ),
        .package(
            url: "https://github.com/nicklockwood/SwiftFormat",
            from: "0.44.4"
        ),
        .package(
            url: "https://github.com/apple/swift-argument-parser",
            from: "0.0.1"
        )
    ],
    targets: [
        .target(
            name: "Uploader",
            dependencies: ["Uploader", "ArgumentParser"]
        )
    ]
)

For our Uploader Package.swift alongside ArgumentParser which we are using as a dependency on our main target, we can include tools: SwiftLint and SwiftFormat. As they are added just like other dependencies, we can specify the version of the command line tool to use, allowing all developers on the project to use the same version. This is especially important for tools that are linting or formatting code, as it means the same rules will be applied for all developers.

Running our tools is now as simple as using swift run, simple! The same process can be used locally and on CI, which means we get the same versions of the tools in both places!

swift run swiftlint
swift run swiftformat .

Managing automation tasks

On top of running command line tools as we have done so far, it would be great if we could also run all of our project automation in the same way. We could of course simply use Swift scripts, however, if any of them need dependencies this would need to be managed and having a bunch of different scripts may not be as discoverable as it could be.

An alternative is that we create a small CLI within Package.swift that provides a set of automation tasks via subcommands that can then be called in a similar way to the lanes in Fastlane for those who are familiar with it.

The first step to creating our CLI is adding a target that will contain the code for our automation tasks.

targets: [
    ...
    .target(
        name: "UploaderTasks",
        dependencies: ["ArgumentParser", "ShellOut"]
    )
]

The next step is adding an executable product that uses the new target. Make sure to use a simple name for the executable so that it is easy to run, a personal preference being task. Our automation tasks will now be ran using swift run task TASK_NAME.

products: [
    ...
    .executable(name: "task", targets: ["UploaderTasks"])
]

The main command

Our task executable is developed just like any other CLI, although it will be a simple one containing very little code. We could do it manually within main.swift, however, as we will need to run different tasks as arguments to the main command we will need to be parsing these arguments and making it easy for users to find the tasks they can run. To make this really easy there is the ArgumentParser framework from Apple.

Within the main.swift file we create a struct for our main command. This configures the command name, offers text for the help message and provides our tasks as subcommands. We will be providing lint, install and uninstall. To execute our program we call Tasks.main() at the bottom of the main.swift.

struct Tasks: ParsableCommand {
    static let configuration = CommandConfiguration(
        commandName: "tasks",
        abstract: "An automation task runner for Uploader.",
        subcommands: [Linting.self, Install.self, Uninstall.self]
    )
}

Tasks.main()

Before creating our first subcommand, we need to make sure it is easy for our subcommands to execute shell commands such as running other CLI tools or scripts. For doing this there is a great framework called ShellOut. Rather than calling it directly we can write a small wrapper function that handles errors, streams output as output from our CLI and allows execution to continue after an error.

func runShell(_ command: String, continueOnError: Bool = false) throws {
    do {
        try shellOut(
            to: command,
            outputHandle: .standardOutput,
            errorHandle: .standardError
        )
    } catch {
        if !continueOnError {
            throw ShellError()
        }
    }
}

struct ShellError: Error, CustomStringConvertible {
    var description: String {
        "Failed when running shell command"
    }
}

If the outputHandle and errorHandle weren't connected to standard output and standard error, we would need to print the output of the shellOut call. By using these handles it will appear in the terminal we are running our task from as it is produced. This means we don't need the output from shellOut or the error it throws as the information has already been shown to the user by the point it is received.

Lint

For each task we want to add, we create a subcommand to our main Tasks command. We already registered these above and will now work through creating each of the subcommands, starting with the lint task. We are running SwiftFormat in lint mode and then SwiftLint, allowing execution to continue on error so that we get all of the failures out of both tools.

extension Tasks {
    struct Linting: ParsableCommand {
        static var configuration = CommandConfiguration(
            commandName: "lint",
            abstract: "Lint the Uploader codebase, such as static analysis."
        )

        func run() throws {
            try runShell("swift run swiftformat . --lint", continueOnError: true)
            try runShell("swift run swiftlint")
        }
    }
}

This task is ran using swift run task lint.

We can create another subcommand to format code using SwiftLint auto-correct and SwiftFormat in its regular mode, feel free to add this to your project in the same way as writing our Linting struct.

Install and uninstall

If our Swift project is itself a CLI, our users will need to install and uninstall it, both tasks either being provided by a script or a Makefile. We can offer these tasks via subcommands in our task runner.

extension Tasks {
    struct Install: ParsableCommand {
        static var configuration = CommandConfiguration(
            commandName: "install",
            abstract: "Install Uploader for running globally."
        )

        func run() throws {
            try runShell("swift build -c release")
            try runShell(
                "install .build/release/uploader-cli /usr/local/bin/uploader"
            )
        }
    }
}

Users can now clone our repository and then run swift run task install to install the application globally on their system. We can also provide an uninstall task, in case they wish to remove our application.

extension Tasks {
    struct Uninstall: ParsableCommand {
        static var configuration = CommandConfiguration(
            commandName: "uninstall",
            abstract: "Uninstall Uploader and remove from system."
        )

        func run() throws {
            try runShell("rm -f /usr/local/bin/uploader")
        }
    }
}

Help

A really nice feature of ArgumentParser is that it generates a help message from the command structs we have created. This aids discovery of the tasks that can be executed on our project by using swift run task -h or --help.

OVERVIEW: A task runner for Uploader.

USAGE: tasks 

SUBCOMMANDS:
  lint        Lint the Uploader codebase, such as static analysis.
  install     Install Uploader for running globally.
  uninstall   Uninstall Uploader and remove from system.

Using this on CI

Now that our command line tools and automation tasks are managed using SPM, using our project on CI services such as GitHub Actions and Bitrise couldn't be easier. We simply call the same commands we use locally and SPM will handle checking out the correct versions, building and executing our tools.

swift build
swift test
swift run task lint

Most CI services will also come with built-in support for caching, so we could speed things up by caching the SPM dependencies for future runs.

Wrap up

Swift Package Manager is a really great way to manage our Swift projects and it is nice being able to use the first-party official build tool and dependency manager. Now we can manage all of our automation and project command line tools using SPM as well, bringing all the project configuration together with one tool.

By building our automation tasks using a CLI within the project, it keeps everything together and easily discoverable. It is also great to be able to build all of this in Swift, meaning the source code and automation is all based on the same language and technologies.

Dealing with file extensions and Uniform Type Identifiers

2019-01-18T00:00:00Z

There are different ways of representing a type of file, two popular ones being file extensions and another being Uniform Type Identifiers (UTIs) from the UIKit APIs. When working with a UIKit API such as UIDocumentPickerViewController we may need to distinguish between these types.

We can create independent types to hold file extensions and type identifiers, this makes it really clear which one is required for a particular piece of functionality.

struct FileExtension {
    let rawValue: String

    func asTypeIdentifier() -> TypeIdentifier {
        let identifierCreated = UTTypeCreatePreferredIdentifierForTag(
            kUTTagClassFilenameExtension, rawValue as NSString, nil
        )
        if let typeIdentifier = identifierCreated?.takeRetainedValue() {
            return TypeIdentifier(rawValue: typeIdentifier as String)
        }
        return TypeIdentifier(rawValue: "public.data")
    }
}

struct TypeIdentifier {
    let rawValue: String
}

Clear and searchable logging in Swift with OSLog

2019-01-14T00:00:00Z

When it comes to logging in Swift and iOS applications in particular, the APIs that first come to mind might be print and NSLog. More recently, however, Apple has introduced a new standard for logging in the form of unified logging, accessed via OSLog. It is the current recommended way of logging, providing an efficient way to capture information across our applications.

Unified logging provides a number of improvements over previous techniques and also some differences to what we are used to.

Each message can be logged at an appropriate level, including: default, error, debug and info. They affect how messages are displayed to us and persisted.
Messages are grouped within subsystems and categories to enable efficient searching and filtering.
There is no need to wrap log statements in conditionals, due to the system being designed for performance and logs being rendered only when read.
User privacy is carefully respected, with dynamic string content needing to be explicitly marked as public, else they are redacted in any logs.

Let's get logging

Using unified logging from Swift is as simple as using the os_log function, which we will quickly notice takes a StaticString as an argument rather than a regular String. The easiest way to log messages, is to place the String constant directly in the function call. Extracting the message to a property is possible, however, we will need to define it's type as StaticString.

os_log("User signed in")

let errorMessage: StaticString = "404 - NOT FOUND"
os_log(errorMessage)

Due to the StaticString requirement, instead of using string interpolation we will need to use format arguments. This may feel jarring initially, however, it isn't too hard to adapt to and it provides benefits to user privacy that we will discuss a bit later on. We have access to all of the standard format arguments, as well as a number of extra value type decoders. The idea is that the logging system handles as much formatting for you as possible, to make the system even more efficient.

let responseCode = "404 - NOT FOUND"
os_log("HTTP response: %@", responseCode)

let logMessage = "HTTP response: \(responseCode)"
os_log("%@", logMessage)

// error: cannot convert value of type 'String'
// to expected argument type 'StaticString'
os_log("HTTP response: \(responseCode)")

It's good to be organised

Calls to os_log can specify an OSLog to use, containing a specific subsystem and category. This information is invaluable when filtering, searching and trying to understand our logs later. When the log argument isn't specified a default one is used, which has no subsystem or category configured.

let uiLog = OSLog(subsystem: "com.lordcodes.chat.ChatApp", category: "UI")
os_log("Contact selected", log: uiLog)

let networkLog = OSLog(
    subsystem: "com.lordcodes.chat.ChatKit",
    category: "Network"
)
os_log("HTTP response: %@", log: networkLog, responseCode)

The subsystem groups all the logs for a particular app or module, allowing us to filter for all of our own logs. From evaluating Apple's logs, the convention for subsystem is a reverse domain style, such as the Bundle Identifier of the app or framework itself. If the app is modularised into frameworks, it is a good idea to use the Bundle Identifier of the framework to split logs into their corresponding components.

Categories are used to group logs into related areas, to help us narrow down the scope of log messages. The convention for categories is to use human-readable names like UI or User. We could group logs into layers across multiple subsystems or features, such as Network or Contacts. Alternatively, we could group all the logs for a particular class, such as Contacts Repository. It would be perfectly acceptable to combine both approaches in the same project, we should simply use the most appropriate categories to allow us to understand the context of the project's log messages.

We can add our different categories and subsystems as an extension of OSLog, making them easily accessible across the app. Storing them in one place avoids creating OSLog instances all over the codebase and helps keep the different categories in use nicely organised.

extension OSLog {
    private static var subsystem = Bundle.main.bundleIdentifier!

    static let ui = OSLog(subsystem: subsystem, category: "UI")
    static let network = OSLog(subsystem: subsystem, category: "Network")
}

os_log("Contact selected", log: .ui)
os_log("HTTP response: %@", log: .network, responseCode)

Logging levels

The unified logging system employs a set of different logging levels at which we can target different types of messages. The levels control how messages are displayed to us, how and when they are persisted and whether they are captured in different environments. How the system handles each level can even be customised through the command-line on our machine. It is a good idea to use the most appropriate logging level for each message, to get the most we can out of the logging system.

Default: To capture anything that might result in a failure and essentially a fall-back if no other level seems appropriate. Unless changed, messages are stored in memory buffers and persisted when they fill up.

Info: To capture anything that may be useful, but is not directly used to diagnose or troubleshoot errors. Unless changed, no persistence is used, messages are just stored in memory buffers and purged as they fill up.

Debug: To capture information during development to diagnose a particular issue, whilst actively debugging. They aren't captured unless enabled by a configuration change.

Error: To capture application errors and failures, in particular anything critical. Messages are always persisted, to ensure they are no lost.

Fault: To capture system-level or multi-process errors only, likely not of use in our app code. As with the error level, messages are always persisted.

Logging at each level is as simple as specifying the corresponding OSLogType as an argument to the os_log call.

os_log("Contact selected", log: .ui, type: .info)
os_log("Saving contact failed", log: .database, type: .error)

User privacy

To ensure private user data is not accidentally persisted to application logs, which may be shared with other people, the unified logging system has a public and private argument process. By default, only scalar (boolean, integer) values are collected and dynamic strings or complex dynamic objects are redacted. If it is necessary, dynamic string arguments may be declared public and scalar arguments could also be declared private.

os_log("Contact %ld selected", 2)
os_log("Contact %{private}ld selected", 2)

os_log("HTTP response: %@", responseCode)
os_log("HTTP response: %{public}@", responseCode)

It is important we resist making all arguments public, as it could easily result in private company or user data being exposed within device logs.

Reading logs

Whilst the debugger is attached, log messages will be shown in the Xcode console. The best way to read our logs, however, is with the Console MacOS application. Here we will be able to sort, filter and search our logs, as well as view them more easily.

Display logs in a table, making each piece of data easy to read
Search and filter by subsystem and category
Show and hide different fields for each log message
Turn on and off debug and info level messages
Save search patterns to access them more easily in the future

Wrap up

Unified logging is a promising and powerful logging solution, especially when it comes to performance and filtering your log messages. Initially it might seem like it has quirks or differences to what you may be used to from NSLog and print. After looking a bit more and providing os_log with subsystems, categories and making good use of logging levels, you will find it makes working with logs significantly easier. If you want more log coverage with better performance, you can ditch NSLog and print statements and start integrating os_log into your apps.

OSLog is Apple's current recommended logging approach

Simpler categories when using OSLog

2019-01-10T00:00:00Z

Organised logging in Swift that can be searched is simple thanks to the built-in os_log. By storing our categories as an extension on OSLog we can access them using a short syntax.

This makes categories so much easier to specify and helps with auto-completion!

extension OSLog {
    static let logAuthentication = OSLog(
        subsystem: "com.myapp.App",
        category: "Auth"
    )
    static let logDatabase = OSLog(
        subsystem: "com.myapp.App",
        category: "Database"
    )
    static let logNetwork = OSLog(
        subsystem: "com.myapp.App",
        category: "Network"
    )
}

os_log("User signed in: %@", log: .logAuthentication, type: .default, email)
os_log("Chat messages sync complete", log: .logNetwork, type: .info)
os_log("Chat messages saved successfully", log: .logDatabase, type: .debug)

Create Xcode file templates and share them with your team

2018-12-14T00:00:00Z

Something all Xcode users will be familiar with is the process of creating new files. When the new file command is triggered, we are presented with a window containing a selection of templates to base our new file upon. These new templates often contain lines of code we immediately delete or code that needs to be changed to fit into our preferred style.

Many people may be unaware that instead of relying solely on the provided templates, we can create our own and have Xcode present them to us. This can simplify the process of creating new files and allow them to match more specific requirements.

The process of creating templates can seem a bit confusing at first, but the end result can be really useful. We are going to explore the process of writing our own Xcode file templates, before delving into how we might go about sharing these with other developers on a particular project.

Creating a template

When Xcode launches, it looks for file templates within a specific location: ~/Library/Developer/Xcode/Templates/File Templates. To get started, we need to create a directory within here that will house all of our file templates.

mkdir -p ~/Library/Developer/Xcode/Templates/File\ Templates/Custom

Within this directory, a quick way to get started is by copying one of the built-in templates and then altering it. They can be found within the Xcode application bundle, with a good option for Swift-based templates being the one for a new Swift file, Source/Swift File.xctemplate.

/Applications/Xcode.app/Contents/
  > Developer/
    > Library/
      > Xcode/
        > Templates/
          > File Templates/

After copying the files, we find the xctemplate contains 4 different files.

TemplateIcon.png and TemplateIcon@2x.png are the thumbnails that are presented within the new file window. We could use these for all of our Swift templates or create specific ones of our own.
TemplateInfo.plist is where we configure our template.
___FILEBASENAME___.swift contains the Swift source that forms the basis of the template.

We will start by creating a template for a new Swift struct, called Swift Struct.xctemplate, that is based upon the Swift File.xctemplate mentioned above.

→ TemplateInfo.plist

Within the property file we can change the Description and Summary keys to clearly describe the template within Xcode.

<key>Description</key>
<string>A Swift struct.</string>
<key>Summary</key>
<string>A Swift struct.</string>

→ ___FILEBASENAME___.swift

By calling the file ___FILEBASENAME___.swift, the resulting Swift file will be named according to what is entered into the new file window. This same argument can be used within the template using ___FILEBASENAMEASIDENTIFIER___. This means that if we enter Contact into the new file window, the generated file will be Contact.swift, containing the struct Contact.

struct ___FILEBASENAMEASIDENTIFIER___ {
}

Once completing the template, starting up Xcode and requesting a new file, we can find our template being offered within a section called 'Custom'. The name of the section is controlled by the directory name we used within ~/Library/Developer/Xcode/Templates/File Templates.

What else can we do

Although they can start very basic, there are some more significant things we can do with templates.

Offer the option of Swift or Objective-C when creating a new file.
Change the filename based on what is entered, for example naming the file UsersRepositoryTests if UsersRepository is entered.
Ask for arguments to be entered in the new file window and then use these within the code.
Add file headers or copyright notices.
Add imports or skeleton code to be included in the file by default.

Some example file templates can be found on GitHub, demonstrating some of the options available.

As we explore the possibilities that file templates provide us, one problem becomes extremely clear. It would be really great if we could create project-specific templates and share them with the other developers on the project. Although templates for a specific project are not supported automatically by Xcode, it can be done through a clever use of symbolic links.

We should place all templates in a directory within our project, such as FileTemplates. It is likely the project is kept in source control, which will ensure the templates are tracked and shared with everyone else in the team.

The directory Xcode expects to find our templates should already exist if the steps were followed above. If not then we need to ensure it does.

mkdir -p ~/Library/Developer/Xcode/Templates/File\ Templates

Once the directory exists, the symbolic link can be created here that points to the templates within our Xcode project. It is worth mentioning that if we delete the project or move it, the symbolic link can simply be deleted and recreated.

ln -s [Project Location]/FileTemplates \
  ~/Library/Developer/Xcode/Templates/File\ Templates/[ProjectName]

For example:

ln -s ~/projects/github/chatapp/FileTemplates \
  ~/Library/Developer/Xcode/Templates/File\ Templates/ChatApp

After restarting Xcode, any project templates will now be presented within the 'New File' window. It would obviously be great if Xcode could offer a solution without the extra work, however, for now it works nicely.

Wrap up

Xcode file templates can be a great way to get started quickly when creating new files. They are very powerful, although quite under-documented and there is much more they can do than discussed here.

Map the keys of a dictionary to a different type

2018-12-13T00:00:00Z

The Swift standard library includes functions to transform the values of a Dictionary, we need to add one ourselves to do the same to the keys.

There are situations this can come in handy such as converting a Dictionary of analytics event parameters from using an internal enum for the keys to using Strings for reporting to our analytics API.

This neat little extension will allow us to do just that!

extension Dictionary {
    func mapKeys<NewKeyT>(
        _ transform: (Key) throws -> NewKeyT
    ) rethrows -> [NewKeyT: Value] {
        var newDictionary = [NewKeyT: Value]()
        try forEach { key, value in
        let newKey = try transform(key)
            newDictionary[newKey] = value
        }
        return newDictionary
    }
}

Using anchors to match a parent view's constraints

2018-12-07T00:00:00Z

Swift extensions are really great, including when working with Auto Layout. We can make a child view fill its superview using constraints, as well as having insets between them. This is very useful when adding a child view controller to its parent within a subview.

extension UIView {
    func attachAnchors(to view: UIView, with insets: UIEdgeInsets = .zero) {
        NSLayoutConstraint.activate([
            topAnchor.constraint(
                equalTo: view.topAnchor,
                constant: insets.top
            ),
            rightAnchor.constraint(
                equalTo: view.rightAnchor,
                constant: -insets.right
            ),
            bottomAnchor.constraint(
                equalTo: view.bottomAnchor,
                constant: -insets.bottom
            ),
            leftAnchor.constraint(
                equalTo: view.leftAnchor,
                constant: insets.left
            )
        ])
    }
}

Animating view colour changes

2018-12-06T00:00:00Z

When animating the addition of cells to a UICollectionView, we may notice that text and background colours aren't animating when using UIView.animate. Using UIView.transition instead works perfectly!

UIView.transition(with: commentContainer, duration: 0.6,
                  options: .transitionCrossDissolve, animations: {
   commentContainer.backgroundColor = UIColor(red: 17, green: 215, blue: 198)
})

UIView.transition(with: commentLabel, duration: 0.6,
                  options: .transitionCrossDissolve, animations: {
   commentLabel.textColor = UIColor(red: 143, green: 155, blue: 174)
})

Create time intervals with explicit units

2018-12-04T00:00:00Z

In Swift, many APIs take a TimeInterval instead of just a Double, you need to know they are in seconds. Instead we can add functions that provide them with explicit units and allow us to convert them. It makes for a really readable call site!

extension TimeInterval {
   // Hide the calculations from the call site
   private static var secondsPerHour: Double { return 60 * 60 }
   private static var secondsPerMinute: Double { return 60 }

   // Functions to provide time intervals with explicit units
   static func hours(_ value: Double) -> TimeInterval {
      value * secondsPerHour
   }

   static func minutes(_ value: Double) -> TimeInterval {
      value * secondsPerMinute
   }

   static func seconds(_ value: Double) -> TimeInterval {
      value
   }
}

// They make very readable call sites
TimeInterval.hours(3)
TimeInterval.minutes(46)
TimeInterval.seconds(35)

A modular analytics layer in Swift

2018-11-27T00:00:00Z

There is a saying, "if a tree falls in a forest and no one is around to hear it, does it make a sound?" Monitoring user behaviour is a bit like that; if people are using your app in a particular way, but you don't know about it, then how can you work out how to improve it.

There are many different options available to us in order to monitor user behaviour, such as user testing, collecting surveys and analytics. Here we are going to be discussing the topic of analytics, specifically using it within a Swift app.

When building and improving your apps, knowing how it is being used by real users in the wild can be very valuable. It allows you to make data-informed decisions rather than just estimating what you think is a good idea. You can also use it to verify and test out ideas once they have been released to your users.

Whilst adding analytics to an app can be quick and easy, ensuring the implementation is easy to use, alter and extend can be more complex. The implementation should be able to stand the test of time and give us the flexibility to make changes to the analytics data we are reporting in the future. We are going to look through one way of building an analytics layer in Swift, that is both modular and extensible.

Backend

When analytics data is captured within our apps, we would normally want to submit this to our preferred backend. This allows data to be collected over time and analysis to be ran over the data.

It is very common for this backend to be a third-party SDK such as: Firebase Analytics or MixPanel. You may also want to use a tool such as Segment, to control where the data is sent and have the flexibility to change the destination whenever you want.

Your backend may be an in-house analytics system, reporting data to your own backend API or pumping data into a data warehouse of some kind. This can be beneficial if your data is specialised or you need to do something with it that the third-party destinations don't support.

Whichever backend solution has been settled on, it is good to wrap its API in one of your own, to avoid the codebase being littered with a specific analytics API. Doing this will give you the flexibility to change the solution more easily and help make your code more maintainable.

Features

We are going to build a layer that avoids using a static API, puts any backend APIs behind a protocol, uses the power of Swift enums and pairs each event with the pieces of data it needs to contain.

More specifically it should:

Be easy to report new and existing events.
Allow the data be sent to whichever analytics backend we wish to use, even multiple.
Be testable and mockable, allowing it to be an injected dependency.
Allow events to be reported from anywhere in the app, but encourage best practices.
Have compile-time safety of events and their properties.

There are a few different components that make up our analytics layer, each covering part of the process.

The main event

The events themselves can be modelled through our AnalyticsEvent enum.

enum AnalyticsEvent: Equatable {
    case addContactTapped
    case contactSelected(index: Int)
    case messageSent(threadType: ThreadType, length: Int)
    case userSignedIn
}

The enum contains a case for each event we want to fire, with associated values for any pieces of data that need to be attached to the event. When we report an event, we are required to provide any data it needs. By writing events in this way we can reduce the amount of code required to report an event, whilst checking for correctness at compile time.

When the event is passed further it provides the set of parameters that are attached to it. These parameters use an enum for their names, to allow them to be mapped differently later on, similar to the events themselves.

extension AnalyticsEvent {
    var parameters: [Parameter: String] {
      switch self {
      case .addContactTapped,
           .userSignedIn:
          return [:]
      case let .case contactSelected(index):
          return [
              .contactIndex: String(describing: index)
          ]
      case let .messageSent(threadType, length):
          return [
              .threadType: threadType.rawValue,
              .messageLength: String(describing: length)
          ]
      }
    }

    enum Parameter: String, Equatable {
        case contactIndex
        case messageLength
        case threadType
    }
}

For writing the switch statement over the AnalyticsEvent enum it is best to avoid using a default case, as this enforces that each new event is handled.

Providers

Each backend you wish to report data to will conform to our AnalyticsProvider protocol. This will document the different analytics operations we can perform.

protocol AnalyticsProvider {
    func report(event: AnalyticsEvent)
}

The report(event:) function is taking our event enum as an argument. This allows each provider to map the event to whichever format they need it in. For example, Firebase Analytics requires events to contain underscores (_) instead of hyphens (-). Once the event has been mapped, it would then be reported to the destination for that particular provider, often calling through to the provider's SDK.

A final solution may also report screens, user properties, preferences and more. These would be added to the AnalyticsProvider protocol.

Let's implement a provider

Making our backend conform to the provider protocol is relatively simple, let's start by building one for Firebase Analytics. The event name and parameters are mapped to strings, before being passed through to the Firebase Analytics SDK logEvent function.

class FirebaseAnalyticsProvider: AnalyticsProvider {
    private let eventMapper = AnalyticsEventMapper()

    func report(event: AnalyticsEvent) {
        let name = eventMapper.eventName(for: event)
        let parameters = eventMapper.parameters(for: event)
        Analytics.logEvent(name, parameters: parameters)
    }
}

The flexibility of the solution means we can easily build another provider to log events to the console.

class LoggingAnalyticsProvider: AnalyticsProvider {
    private let eventMapper = AnalyticsEventMapper()

    func report(event: AnalyticsEvent) {
        let name = eventMapper.eventName(for: event)
        print("Event reported: \(name)")
    }
}

We can create a provider for whichever destination we wish to use.

Get mapping

Each provider needs to convert the event enum into a reporting format. Most analytics SDKs require events in a string format and so it an be a good idea to provide a default mapper that does this.

If a particular app doesn't need the flexibility for each provider to control the mapping, we can instead return data in the correct format directly within the AnalyticsEvent.

For now we will give ourselves full flexibility, by using a separate mapper.

class AnalyticsEventMapper {
    func eventName(for event: AnalyticsEvent) -> String {
        ...
    }

    func parameters(for event: AnalyticsEvent) -> [String: String] {
        ...
    }
}

The first part to the mapping process is to get a name for the event. This is as simple as using a switch statement to map each event case to a String.

func eventName(for event: AnalyticsEvent) -> String {
    switch event {
    case .addContactTapped:
        return "addContact_tapped"
    case .contactSelected:
        return "contact_selected"
    case .messageSent:
        return "message_sent"
    case .userSignedIn:
        return "user_signedIn"
    }
}

The second part is getting a dictionary of event parameters.

func parameters(for event: AnalyticsEvent) -> [String: String] {
    var newParameters = [String: String]()
    event.parameters.forEach { key, value in
        let newKey = parameterName(for: key)
        newParameters[newKey] = value
    }
    return newParameters
}

func parameterName(for parameter: AnalyticsEvent.Parameter) -> String {
    switch parameter {
    case .contactIndex:
        return "contact_index"
    case .messageLength:
        return "message_length"
    case .threadType:
        return "thread_type"
    }
}

The parameters(for:) function is simply converting the dictionary keys from an enum to a String. If used in multiple places, it can be easily extracted to a generic extension on Dictionary.

Putting it all together

We now need to bring together all of the components we have built and create the API for our analytics layer, the AnalyticsReporter. The reporter is the dependency you will be injecting and using throughout your app to report events.

class AnalyticsReporter {
    private let providers: [AnalyticsProvider]

    init(providers: [AnalyticsProvider]) {
        self.providers = providers
    }

    func report(event: AnalyticsEvent) {
        providers.forEach {
            $0.report(event: event)
        }
    }
}

This reporter allows multiple analytics providers to be used, obviously if an app only required a single provider we could decide whether this was worth supporting or not. Due to each analytics backend being wrapped with our provider, the reporter is pretty simple.

As with the provider, a final solution may also include reporting of other entities such as screens and user properties.

Time to use it

We can now put our implementation into practice to see how it is to use.

class ContactsViewModel {
    private let coordinator: ContactsCoordinator
    private let analyticsReporter: AnalyticsReporter

    init(coordinator: ContactsCoordinator, analyticsReporter: AnalyticsReporter) {
        self.coordinator = coordinator
        self.analyticsReporter = analyticsReporter
    }

    func contactSelected(at index: Int) {
        analyticsReporter.report(event: .contactSelected(index: index))
        coordinator.startContactThreads(at: index)
    }

    func addContactTapped() {
        analyticsReporter.report(event: .addContactTapped)
        coordinator.startContactCreation()
    }
}

The AnalyticsReporter can be injected wherever we wish to use it, in the case above in a ContactsViewModel. Using the API is as simple as selecting the correct event and providing any values it requires.

If we need to report a new event, we just need to add it to the AnalyticsEvent enum, provide its parameters and update any mapping code. ⚒

Testing

It is very important that our analytics code be testable and that it doesn't make any other code more difficult to test. To verify the correct events have been reported, we can create a TestingAnalyticsProvider within our unit test sources. The test provider stores reported events so that they can be asserted on afterwards.

class TestingAnalyticsProvider: AnalyticsProvider {
    var eventsReported = [AnalyticsEvent]()

    func report(event: AnalyticsEvent) {
        eventsReported.append(event)
    }
}

Wrap up

That wraps up implementing, using and testing our new analytics layer. In general the approach we have put forward is flexible and can be altered where necessary to suit a particular app's needs.

We have seen that:

Our implementation uses a modular approach that should minimise the impact analytics has on the rest of the app.
It is easy to configure and report both new and existing events.
Each destination is wrapped in a provider protocol, giving the flexibility to support any backend we wish to use, including a test one.
By avoiding a static API, we encourage the reporter dependency to be instantiated or provided via dependency injection, whilst it still being easy to do so.
The use of an enum for the event type enforces compile-time safety for events and the properties they each require.

Protocol functions with default parameter values

2018-11-26T00:00:00Z

Being able to specify default parameter values in Swift allows us to reduce the number of function overloads in our code. For protocols it is still possible as long as we use an extension and delegate to the version without the default values.

protocol ErrorController {
   func showError(_ error: String, delegate: ErrorViewControllerDelegate?)
}

extension  ErrorController {
   func showError(_ error: String, delegate: ErrorViewControllerDelegate? = nil) {
      showError(error, delegate: delegate)
   }
}

class ContactsViewController: UIViewController, ErrorController {
   func showError(_ error: String, delegate: ErrorViewControllerDelegate?) {
      print(error)
   }
}

let contacts: ErrorController = ContactsViewController()
contacts.showError("I don't need a delegate.")

Access the call site of a function using special Swift literals

2018-11-26T00:00:00Z

Accessing information about the call site of a function is surprisingly simple in Swift by simply using #file, #function and #line. This can be a great help when we want to put assertions within a shared function or print text without losing the original context.

extension  XCTestCase {
    struct UnexpectedNilError: Error {}

    func unwrapAssert<ValueT>(_ value: ValueT?,
                              message: String = "Unexpected nil",
                              file: StaticString = #file,
                              line: UInt = #line) throws -> ValueT {
        guard let value = value else {
            XCTFail(message, file: file, line: line)
            throw  UnexpectedNilError()
        }
        return value
    }
}

Safely index items within a collection

2018-11-25T00:00:00Z

We can make some great things with extensions in Swift, as well as subscript functions. This one allows us to safely access collection elements by index, getting back an optional instead of errors being thrown!

extension Collection {
    subscript(safe index: Index) -> Element? {
        indices.contains(index) ? self[index] : nil
    }
}

let numbers = [1, 2, 3, 4]
numbers[safe: 3] // 4
numbers[safe: 10] // nil, no error

Managing secrets within an iOS app

2018-11-20T00:00:00Z

Almost all iOS apps need private values, such as API keys, secrets and passwords. Some of these may need to be used in the source code, to setup third-party SDKs or backend APIs. Some secrets may be needed during the build process or to use developer tools, such as communicating with an Apple Developer account.

Simple approaches for including secrets into an app would include: putting values directly into the code, placing them into build scripts or keeping them in the Info.plist file. Unfortunately, these approaches mean the secrets are committed to source control and are visible to anyone with access to the the code. Furthermore, scripts and plist files added to the app bundle can be extracted from the compiled app.

We are going to look through some more secure ways of managing secrets within our iOS projects, in order to access them from code. It is worth noting that it is practically impossible to keep anything within an app 100% secret, as apps are "out in the wild" on users' devices. A good approach is to enforce a suitable level of protection for the situation, for example a banking app should probably have a higher level of security than a to-do list app.

Control the sources

It is important to keep secrets out of source control for both open and closed source projects for various reasons.

By committing secrets to source control, you are sharing these values with all users who have read-access to the repository, including anyone who gets access in the future. You may have users who need to access the project, but not necessarily use all of the secrets.
After a user checks out the repository, they would gain a copy of all the secrets stored on their local machine.
If your source control system is compromised, not only would the source code be obtained, so would all of the passwords and other secrets.

Git allows us to include a .gitignore file, where we can list files (or expressions) that should be kept out. If these files are required by our app, each developer just creates these files and adds any required values. We could include template versions of these files in Git or a guide for what is needed in documentation, including contact details for who to provide secrets if they are required.

Cocoapods Keys

As most iOS developers are aware, many iOS projects use Cocoapods as a dependency manager. Cocoapods includes a plugin system that allows its processes to be hooked into. One such plugin that can be used to manage your app secrets securely is cocoapods-keys.

Not only does cocoapods-keys keep the secrets out of the project sources, it holds them securely in your system keychain. When pods are installed or updated, the developer is asked for each key that has no value already stored. An Objective-C class is generated that contains obfuscated versions of keys and their values. As this class is built by running Cocoapods, the Pods/CocoaPodsKeys directory can be added to the .gitignore.

The plugin has many advantages:

It asks for a value to be provided for each key, avoiding the need to document the required secrets. This makes it very easy for each developer to get their project environment configured.
The source file is generated, which allows it to be easily kept out of source control.
Secrets are scrambled within the generated sources, to protect against the keys being extracted from the app binary.
It can be used from both Swift and Objective-C sources.
By reading from the keychain, we could access the secrets within build scripts if we needed to.
We can share keys between different projects that use cocoapods-keys.

Let's setup our keys

Incorporating cocoapods-keys into our project is very simple and starts with including the plugin into our Podfile.

plugin 'cocoapods-keys', {
  :project => "ChatApp",
  :target => "ChatApp",
  :keys => [
    "ChatAPIClientSecretProd",
    "ChatAPIClientSecretTest",
    "AnalyticsWriteKey"
  ]
}

After we next run pod install, we will be asked to enter the value for each of our keys listed above. Once all keys are configured, the plugin will generate a source file that can be referenced in our code to read the keys.

import Keys

let keys = ChatAppKeys()
Analytics.setup(with: keys.analyticsWriteKey)

For values like our backend API secret, where we may want it to be different for debug and release, we can include both keys and then read a different one at runtime. There are obviously many different ways of handling this, depending on the exact use case we have. Therefore, we aren't going to discuss all possible options here and will simply look at switching based on whether the app is built in the debug configuration.

var apiClientSecret {
    #if DEBUG
    return keys.chatApiClientSecretTest
    #else
    return keys.chatApiClientSecretProd
    #endif
}

If you are using Cocoapods in your project, I would recommend looking into cocoapods-keys over other options, due to it being a secure and easy-to-use way to solve the problem.

Doing things ourselves

Many projects don't use Cocoapods or we may not want to use a plugin and so we can also consider implementing a solution ourselves. Secrets will be passed into the build process, where they will be made available as environment variables. We can then read these variables and use them to generate a source file that will give our code access to our secret values.

We can have different values for different environments

Xcode offers xcconfig files that can be linked to a particular build configuration in order to load in settings specified within them. An xcconfig file can be specified for each build configuration, allowing us to have different values for each environment. We may wish to point our app at our production API for release apps, but a test backend for debug apps.

Note that if a particular app doesn't need different values depending on the build configuration, we can use a shell script instead of the xcconfig files and source the file into our final build phase later on.

We start off by creating example versions of our xcconfig files. If we place these files within a directory such as BuildConfig it will keep them separate from other project files. It is recommended to include these files into the project, so that they appear within Xcode, but we should ensure they aren't added to any targets within the Target Membership area of the File Inspector.

→ debug.example.xccconfig

CHAT_API_CLIENT_SECRET = CHAT_API_CLIENT_SECRET_TEST
ANALYTICS_WRITE_KEY = ANALYTICS_WRITE_KEY

→ release.example.xccconfig

CHAT_API_CLIENT_SECRET = CHAT_API_CLIENT_SECRET_PROD
ANALYTICS_WRITE_KEY = ANALYTICS_WRITE_KEY

By duplicating and renaming the example files we can easily create the real files that will be used by the project. As with the example files, we want these files in the project, but not attached to any targets.

→ debug.xccconfig

CHAT_API_CLIENT_SECRET = 123456789
ANALYTICS_WRITE_KEY = abcdefgh

→ release.xccconfig

CHAT_API_CLIENT_SECRET = 987654321
ANALYTICS_WRITE_KEY = abcdefgh

To avoid the real xcconfig files being added to source control, they should be listed in the .gitignore file. We can use a regular expression in the rule to catch the files for all configurations.

BuildConfig/*.example.xcconfig

The final step, is telling Xcode to use our xcconfig files, which is specified within the project file under Info → Configurations. Make sure to select an xcconfig for each build configuration and for the target you need.

Generating the source

When Xcode builds your project, the values in the xcconfig files are made available as environment variables. You could simply use these values in your Info.plist file if you wished with the form $(CHAT_API_CLIENT_SECRET). We have already discussed that putting secrets into plist files isn't very secure, but have mentioned it for completeness.

We are going to generate a source file using a tool called Sourcery and then reference this source file in our code to access our secrets. Needless to say, we will need to start by adding Sourcery to our project, for example including a standalone version within our repository or using Cocoapods.

Sourcery uses a template system, where we create a stencil file to show the tool how to generate our code. We will create AppSecrets.stencil including some syntax to substitute in the secret values when the file is generated from the template.

struct AppSecrets {
  static let chatApiClientSecret="{{ argument.chatApiClientSecret }}"
  static let analyticsWriteKey="{{ argument.analyticsWriteKey }}"
}

We next need to add a build phase to our project by selecting the project file, then selecting the correct target and going to the Build Phases tab.

Tools/Sourcery/bin/sourcery
    --sources Sources
    --templates Templates/AppSecrets.stencil
    --output Generated
    --args chatApiClientSecret=\"$CHAT_API_CLIENT_SECRET\",
           analyticsWriteKey=\"$ANALYTICS_WRITE_KEY\"

The path to the Sourcery executable will depend on how it is installed.
The sources argument needs to be specified, even though it isn't used in this situation. We can simply point it to our main sources, or any valid directory.
The templates argument is a path from the root of the project to our template file.
The output directory is where the generated source file is written. We need to ensure this folder exists, possibly by adding mkdir -p Generated at the start of the build phase.
Within args, values are separated by commas in the form: arg1=one,arg2=two. It is a good idea to escape as above incase the secret values contain any special characters.

We can use a more complex script instead of manually specifying secrets within the build phase. This can be beneficial if there are more than a couple of secrets or the build phase is hard to maintain.

After adding the build phase, we can build the app as normal and then add the generated AppSecrets.swift file to the project so that it is compiled and linked to the project target. As with the xcconfig files, we should add AppSecrets.swift to our .gitignore file to keep it out of Git.

Using secrets within our code is as simple as referencing our generated struct.

Analytics.setup(with: AppSecrets.analyticsWriteKey)

Wrap up

The goal we wanted to achieve was being able to reference secret values within our source code, without these values themselves needing to be kept in source control. The two solutions we have looked at are quite different, but both achieve the same goal.

By using cocoapods-keys, we can avoid the manual setup and also avoid the values being stored in plain-text anywhere in the project. However, our solution using Sourcery can be used without Cocoapods and will still require very little maintenance. There will definitely be even more solutions available online for more use cases, it will come down to using the most appropriate solution for the situation.

Sharing accessibility identifiers between app and tests

2018-11-16T00:00:00Z

For identifying views within UI tests we can use accessibility identifiers, which are String values. We can register all of our identifiers within an enum, using an extension to set them on our views. By adding the enum to the app target and the UI test target, an extension can be added to find views within tests suing our ID enum. It's really nice to use an enum, avoiding duplicating the strings and avoiding errors!

App sources

extension UIAccessibilityIdentification {
    var viewAccessibilityIdentifier: ViewAccessibilityIdentifier? {
        get { fatalError("Not implemented") }
        set {
            accessibilityIdentifier = newValue?.rawValue
        }
    }
}

addContactButton.viewAccessibilityIdentifier = .addContactButton

Test sources

extension XCUIElementQuery {
    subscript(key: ViewAccessibilityIdentifier) -> XCUIElement {
        self[key.rawValue]
    }
}

XCUIApplication().buttons[.addContactButton].tap()

Protocol function that returns the Self type

2018-11-12T00:00:00Z

We may find situations in which we want a protocol function to return the current type, here the metatype Self can come in handy. In these situations rather than just returning the protocol type, we likely want to return the type that conforms to the protocol. An associated type can be added to the protocol that defaults to Self to achieve this. Pretty handy!

protocol ChatThreadsRobot {
    associatedtype ChatThreadsType: ChatThreadsRobot = Self

    func tapCreateThread() -> ChatThreadsType
}

extension ConnectionThreadsRobot: ChatThreadsRobot {
    func tapCreateThread() -> ConnectionThreadsRobot {
        app.buttons["createThreadButton"].tap()
        return self
    }
}

Using metatype Self to return current type

2018-11-09T00:00:00Z

A helpful keyword in Swift is Self, which is a metatype that represents the current type. The current type may be the class, subclass or current implementer of a protocol, depending on where it is used.

A handy use-case for it is to avoid specifying generic placeholder types. Neat!

class ThreadRobot<CallerT: CallerRobot> {
    private let app = XCUIApplication()

    func tapCompleteButton() -> Self {
        app.otherElements["actionButtonRail"].buttons["Complete"].tap()
        return self
    }
}

Constraints for a child view controller within a subview

2018-10-23T00:00:00Z

When a UIViewController is added within one of it's parent's subviews, there can be an issue where it doesn't expand to fill it. This can often happen when we only tested on a specific device size.

The fix involves preventing the auto-resizing mask from being turned into constraints and ensuring the child view controller's anchor constraints are all attached to the edge's of its container view.

addChild(child)
containerView.addSubview(child.view)
child.view.translatesAutoresizingMaskIntoConstraints = false
child.view.attachAnchors(to: containerView)
child.didMove(toParent: self)

Lord Codes » iOS & Swift Feed

Installing and running Swift tools with enforced versions

Installation options

Homebrew

Swift Package Manager Plugins

Cocoapods

Mint

Binary or cloning

An alternative approach

The scripts

Supported tools

Wrap up

Manage automation tasks using Swift Package Manager

Installing and running

Managing automation tasks

The main command

Lint

Install and uninstall

Help

Using this on CI

Wrap up

Dealing with file extensions and Uniform Type Identifiers

Clear and searchable logging in Swift with OSLog

Let's get logging

It's good to be organised

Logging levels

User privacy

Reading logs

Wrap up

Simpler categories when using OSLog

Create Xcode file templates and share them with your team

Creating a template

What else can we do

It's nice to share

Wrap up

Map the keys of a dictionary to a different type

Using anchors to match a parent view's constraints

Animating view colour changes

Create time intervals with explicit units

A modular analytics layer in Swift

Backend

Features

The main event

Providers

Let's implement a provider

Get mapping

Putting it all together

Time to use it

Testing

Wrap up

Protocol functions with default parameter values

Access the call site of a function using special Swift literals

Safely index items within a collection

Managing secrets within an iOS app

Control the sources

Cocoapods Keys

Let's setup our keys

Doing things ourselves

Generating the source

Wrap up

Sharing accessibility identifiers between app and tests

Protocol function that returns the Self type

Using metatype Self to return current type

Constraints for a child view controller within a subview