Paul Peelen

OS Style settings view, Part 2

Sat, 04 May 2024 18:00:00 +0000

Introduction

In part one of OS Style Settings View we make a Generic Setting View with groups and nice toggles instead of checkboxes. But as I wrote in that post, there are the two most common ways to have a settings view is by either using a NavigationSplitView with only the details view and sidebar, or using TabBar. Now, lets implement the split view to make it a bit nicer.

MacOS setting

Looking at the above window, you see there are a few things that are missing for our Generic Settings View, first off… we only have toggle for now, secondly we only have one page. Lets stsrt off with making the main view. For that, we’ll add a new view called SettingsView.swift. Go ahead and add this to your project. The code will be the following:

import SwiftUI

struct SettingsView: View {
    var body: some View {
        NavigationSplitView {
            Text("Sidebar")
        } detail: {
            GeneralSettingsView()
                .padding()
        }

    }
}

#Preview {
    SettingsView()
}

And in our main App file, we change the settings view to the following:

Settings {
    SettingsView()
}

So, what did we do here? In the first file, SettingsView, we create a NavigationSplitView with an empty sideBar and the detail view set to our GeneralSettingsView. In the second step, we set the new SettingsView to be our main view for settings, meaning that it’ll open this view when we open settings instead of the former GeneralSettingsView.

Now you should have a settings view that looks something like this:

Lets create our sidebar now. Lets start off with 2 pages, one being the generic page and one being an about page.

import SwiftUI

struct SideBar: View {
    var body: some View {
        List {
            Label("Generic settings", systemImage: "slider.horizontal.3")
            Label("About", systemImage: "info.square")
        }
        .listStyle(.sidebar)
    }
}

#Preview {
    SideBar()
}

This will just make a list with the two items, however running this code now will not give us any links or so. In order to do that, we need to improve our pages a little. For that we will update our sidebar to the following code:

struct SideBar: View {
    @Binding var selectedPage: SettingsPages

    var body: some View {
        List(SettingsPages.allCases, selection: $selectedPage) { page in
            Label(page.name, systemImage: page.systemImage)
                .tag(page)
        }
        .listStyle(.sidebar)
    }
}

enum SettingsPages: String, CaseIterable, Identifiable {
    case generalSettings
    case about

    var id: String {
        self.rawValue
    }

    var name: String {
        switch self {
        case .generalSettings:
            "General settings"
        case .about:
            "About"
        }
    }

    var systemImage: String {
        switch self {
        case .generalSettings:
            "slider.horizontal.3"
        case .about:
            "info.square"
        }
    }

    static var allCases: [SettingsPages] = [.generalSettings, .about]
}

#Preview {
    SideBar(selectedPage: .constant(.generalSettings))
}

And we will also have to update our SettingsView to the following:

struct SettingsView: View {
    @State private var selectedPage: SettingsPages = .generalSettings

    var body: some View {
        NavigationSplitView {
            SideBar(selectedPage: $selectedPage)
        } detail: {
            GeneralSettingsView()
                .padding()
        }
        .frame(width: 800, height: 600)
    }
}

So, what did we do? In the Sidebar view, we added an enum called SettingsPages which inherits from CaseIterable and conforms to Identifiable. This enum will decide the pages that exist and will also define the image and name for each page. In the SettingsView we then create a State variable and give it a default value of SettingsPages.generalSettings. This state variable we then pass on to the SideBar.

In the sidebar we then update the list to use allCases from SettingsPages and render its content. Each row that is rendered will have a tag which List then uses to set the selectedPage variable, when the user selects it. For each label, we call the computed variables from the enum.

So, why did we move the @State variable to the SettingsView instead of having it in the SideBar? We did this, because the SettingsView decides which page is shown in the detail view, which we are now going to update.

Updating the page

Now that we have the selectedPage variable in SettingsView, we can changes pages… however, we don’t have any pages to move to. Lets make a new view called AboutView.swift and add some content there. I’ve added the following code:

import SwiftUI

struct AboutView: View {
    var body: some View {
        VStack {
            Text("Demo app")
            Text("https://getclicker.app")
                .padding(.bottom)
        }
    }
}

#Preview {
    AboutView()
}

Now, go back to SettingsView and lets change pages. Lets update the detail part of the NavigationSplitView to the follwing:

    switch selectedPage {
    case .generalSettings:
        GeneralSettingsView()
    case .about:
        AboutView()
    }

Here we reference the selectedPage and dependent on the type of the enum that is selected, we render a different view.

Lets build and run, and you should have something like:

Details

Now, we have to apply some minor details to make it look a bit better.

NavigationSplitView automatically adds the sidebar toggle, lets remove this because we don’t want to show this in settings. Add the following code inside SettingsView, just below the creation of SideBar:

.toolbar(removing: .sidebarToggle)

As you might have noticed, the sidebar is a bit small. Lets change that by setting the width to 240. Add the following code inside SettingsView, just below the creation of SideBar:

.navigationSplitViewColumnWidth(240)

This should be the endresult:

Code

This is en final code thus far. All put into one file though, so you’ll have to split it up.

OS Style settings view, Part 1

OS Style settings view

Sat, 04 May 2024 11:00:00 +0000

Introduction

There are many ways to let your user change different settings, you can have it inline with the function they’re using, and/or combine them in a settings page. In this post we’re going to look at a simple and nice way to get this working.

Old vs New

For MacOS, adding a settings page can be done by adding Settings to your main app. For my App Clicker I made a quick and simple settings page, without realising there is a better way to do this. I only started noticing this when I wanted to add more details to the settings page that it didn’t work well.

So, this is how my settings page looked in Clicker version 0.2.0:

After my updates, the same views look like this:

Adding Settings to your app

The two most common ways to have a settings view is by either using a NavigationSplitView with only the details view and sidebar, or using TabBar. For us, lets start off with simple page that changes some app storage settings.

Lets start off with just a view that contais the settings. On your project, create a new view called GeneralSettingsView.swift with the following code:

import SwiftUI

struct GeneralSettingsView: View {
    @State private var settingOneValue = false
    @State private var settingTwoValue = false
    @State private var settingThreeValue = false

    var body: some View {
        VStack {
            HStack {
                VStack(alignment: .leading) {
                    Text("Title")
                        .font(.title2)
                    Text("Subtitle for the setting, explaining what it does")
                }
                Spacer()
                Toggle("", isOn: $settingOneValue)
            }
            HStack {
                VStack(alignment: .leading) {
                    Text("Title 2")
                        .font(.title2)
                    Text("Subtitle for the setting, explaining what it does")
                }
                Spacer()
                Toggle("", isOn: $settingTwoValue)
            }
            HStack {
                VStack(alignment: .leading) {
                    Text("Title 3")
                        .font(.title2)
                    Text("Subtitle for the setting, explaining what it does")
                }
                Spacer()
                Toggle("", isOn: $settingThreeValue)
            }
        }
    }
}

#Preview {
    GeneralSettingsView()
}

You should now have a simple page showing toggles to the right, each item having tite and subtitle. Now, in your App file, lets add a settings page by adding the following code right beneath the WindowGroup of the App:

        Settings {
            GeneralSettingsView()
                .padding()
        }

Now, if you launch your app, you should see a settings option in the app’s finderbar menu, like so:

And the settings view should look like:

The reason why I chose to add seperate VStacks and not use the option to add it directly to the Toggle, is because I’ve seen a bunch of questions on e.g. Stackoverflow where people choose to seperate their views and I want to show in this post why you shouldn’t do that.

Updating the UI

The second UI in the view shown above uses Form and Groups for the UI, so lets start off with updating our UI to use the view added to a Toggle.

Lets exchange the above HStacks with toggles and VStack for the following.

            Toggle(isOn: $settingOneValue, label: {
                VStack(alignment: .leading) {
                    Text("Title")
                        .font(.title2)
                    Text("Subtitle for the setting, explaining what it does")
                }
            })

            Toggle(isOn: $settingTwoValue, label: {
                VStack(alignment: .leading) {
                    Text("Title 2")
                        .font(.title2)
                    Text("Subtitle for the setting, explaining what it does")
                }
            })

            Toggle(isOn: $settingThreeValue, label: {
                VStack(alignment: .leading) {
                    Text("Title 3")
                        .font(.title2)
                    Text("Subtitle for the setting, explaining what it does")
                }
            })

Now your settings view will look like this:

… Not ideal yet… but better.

Adding groups

Finalising the UI by adding groups is the last thing to do here, lets change out our root vstack for Form and lets add some sections. Lets update the code to the following:

    var body: some View {
        Form {
            Section {
                // Toggle 1
            } header: {
                Text("Section 1")
            }

            Section {
                // Toggle 2 & 3
            } header: {
                Text("Section two")
            }
        }
    }

As you might have noticed, I removed the toggles above, but this you shouldn’t do. I only did this to emphasise the changes I made.

Now, there is one thing left… you need to set the form style to the form by adding:

.formStyle(.grouped)

below the closing } of Form. Since the default form style is .columns, you need to change it to .grouped so SwiftUI knows how you want it formatted. Now your view should look like this:

It can happen that the view is too small, you can resize it so it fit. You could add .frame(width: 800, height: 600) if you want a fixed size.

The end result should now be:

OS Style settings view, Part 2

Create a calendar view in SwiftUI

Tue, 26 Sep 2023 09:00:00 +0000

Introduction

Ever had a need to add a calendar page? You know, like the one in Apple’s Calendar app? Apple does offer a few components like the date picker amongst other, but not the complete calendar page. For this reason I created Simple Calendar.

In the image above, you’ll see a short demo of SimpleCalendar.

SimpleCalendar is fully written in SwiftUI and fully open source. You can help out with the source code over here at Github.

Installation

Simple Calendar can be installed with the Swift Package Manager. Add the following to your Packages.swift or Xcode:

https://github.com/ppeelen/SimpleCalendar.git

Usage

Simple Calendar comes with documentation right inside Xcode, however here are some quick examples:

Adding a Simple Calendar is just one line of code:

SimpleCalendarView(
    events: eventList,
    selectionAction: .sheet
)

eventList in the example above is a list of EventRepresentable items; such as Event. See the example app for further examples.

When the user selects an event in the calendar, Simple Calendar can either inform using a closure, show the default sheet, a custom sheet or move to a custom destination.

Documentation

You can find the documentation here: https://ppeelen.github.io/SimpleCalendar/docs/documentation/simplecalendar

SwiftUI Multi data-type chart

Mon, 13 Feb 2023 09:00:00 +0000

Introduction

In iOS 16, Apple introduced the Swift Charts. With Swift Charts you can make charts such as Bar-, Line- and point charts. See Apple’s documentation for more information and examples. [https://developer.apple.com/documentation/charts]

In this article we are going to create the following chart in Swift UI.

In the image above, you’ll notice that we have a line chart with, on the left hand side, one type of data and, on the right hand side, another. In the case above, the left shows the electricity consumption in Kilowatt hours (kWh) and on the right a total cost for the selected hour. The X axis shows the time of the date for the consumption.

The basics

Lets start with setting up our data first, which we will respresent in SwiftUI. In the example above, we are looking at a 24 hour period of electricity consumption for a home, summarised hour by hour. A similar type of chart you can find in my app Tobbe, where you can login with a Tibber account and show your data.

We’ll start off with a basic playground which will show two charts, one for Consumption and one for Cost. These two we are going to merge later in this article. You can check the gist here: https://gist.github.com/ppeelen/46fa0183f71e761df0c416af0cc0b7f7.

Once you have it running, it should look like:

Axis labels

As you might have noticed, the axis information is not good enough. Lets change that first.

Add the modifier for chartXAxis to both Charts:

.chartXAxis {
    AxisMarks(values: .stride(by: .hour, count: 4)) { _ in
        AxisValueLabel(format: .dateTime.hour(.twoDigits(amPM: .abbreviated)))
    }
}

This will add the X axis labels, which in our case are hour labels for every 4th hour of the given dates.

Now we are going to add the Y axis for both charts, but these are different from each other. One thing they will have in comon is the amount of marks each charts has. We want both charts to have the same amount so they will match up later when we are going to merge them.

Add the following line directly after the vstack in the top of the ChartView body, on line 12:

let strideBy = 6

And then add this chartYAxis modifier to the cost chart:

.chartYAxis {
    let costs = consumption.map { $0.cost }
    let min = costs.min()!
    let max = costs.max()!
    let costsStride = Array(stride(from: min,
                                   through: max,
                                   by: (max - min)/strideBy))
    AxisMarks(position: .trailing, values: costsStride) { axis in
        let value = costsStride[axis.index]
        AxisValueLabel("\(String(format: "%.2F", value)) kr", centered: false)
    }
}

And this chartYAxis modifier to the consumption chart:

.chartYAxis {
    let consumptions = consumption.map { $0.consumption }
    let min = consumptions.min()!
    let max = consumptions.max()!
    let consumptionStride = Array(stride(from: min,
                                            through: max,
                                            by: (max - min)/strideBy))
    AxisMarks(position: .trailing, values: consumptionStride) { axis in
        let value = consumptionStride[axis.index]
        AxisValueLabel("\(String(format: "%.2F", value)) kWh", centered: false)
    }
}

What these will do is add the Y labels to the right side of the chart (trailing) and calculate each of them to their own respecive value by taking the max and min values into account.

Now your chart should look like:

Merging the two

Now that we have two charts we know what data we want to show and how each of them should look. Now lets make one chart of them. We can merge them by moving the second LineMark for the consumption chart, inside the cost chart directly after the first line mark. So go ahead and move that one for now.

When you have move it, you need to let the chart know that these are two different data sets. You can do this by adding the following modifier to the first LineMark:

.foregroundStyle(by: .value("Value", "Cost"))

and this modifier to the consumption LineMark:

.foregroundStyle(by: .value("Value", "Consumption"))

Now we need move in the labels for the Y axis too, but we also need to modify them a little. Instead of moving the Y axis labels we’ve created, lets add these instead to the already existing chartYAxis modifier for the Costs chart:

    let consumptions = consumption.map { $0.consumption }
    let consumptionsMin = consumptions.min()!
    let consumptionsMax = consumptions.max()!
    let consumptionStride = Array(stride(from: consumptionsMin,
                                            through: consumptionsMax,
                                            by: (consumptionsMax - consumptionsMin)/strideBy))
    AxisMarks(position: .leading, values: consumptionStride) { axis in
        let value = consumptionStride[axis.index]
        AxisValueLabel("\(String(format: "%.2F", value)) kWh", centered: false)
    }

Now, we can remove the second chart so we only have one chart left. Your body for ChartView should now look like this:

VStack(alignment: .leading) {
    let strideBy: Double = 6

    Text("Cost")
        .font(.footnote)
    Chart(consumption) { item in
        LineMark(
            x: .value("Hour", item.from),
            y: .value("Price", item.cost)
        )
        .interpolationMethod(.catmullRom)
        .foregroundStyle(.green)
        .lineStyle(StrokeStyle(lineWidth: 3))
        .foregroundStyle(by: .value("Value", "Cost"))

        LineMark(
            x: .value("Hour", item.from),
            y: .value("Consumption", item.consumption)
        )
        .interpolationMethod(.catmullRom)
        .foregroundStyle(.blue)
        .lineStyle(StrokeStyle(lineWidth: 3))
        .foregroundStyle(by: .value("Value", "Consumption"))
    }
    .chartXAxis {
        AxisMarks(values: .stride(by: .hour, count: 4)) { _ in
            AxisValueLabel(format: .dateTime.hour(.twoDigits(amPM: .abbreviated)))
        }
    }
    .chartYAxis {
        let costs = consumption.map { $0.cost }
        let min = costs.min()!
        let max = costs.max()!
        let costsStride = Array(stride(from: min,
                                                through: max,
                                                by: (max - min)/strideBy))
        AxisMarks(position: .trailing, values: costsStride) { axis in
            AxisGridLine()
            let value = costsStride[axis.index]
            AxisValueLabel("\(String(format: "%.2F", value)) kr", centered: false)
        }

        let consumptions = consumption.map { $0.consumption }
        let consumptionsMin = consumptions.min()!
        let consumptionsMax = consumptions.max()!
        let consumptionStride = Array(stride(from: consumptionsMin,
                                                through: consumptionsMax,
                                                by: (consumptionsMax - consumptionsMin)/strideBy))
        AxisMarks(position: .leading, values: consumptionStride) { axis in
            AxisGridLine()
            let value = consumptionStride[axis.index]
            AxisValueLabel("\(String(format: "%.2F", value)) kWh", centered: false)
        }
    }
    .padding(.bottom, 20)
}

Last, but not least… lets decrease the height for MainView to 250 from 500.

.frame(minWidth: 450, minHeight: 250)

Now if you run the code, the result should look like this:

but wait… this looks messed up! I’ll tell you why:

Fixing the messed up chart

The reason things look messed up now is because the chart’s max value is now at ~53, which is the highest value of the cost per hour. However, the kWh consumption never gets this high. The Chart doesn’t understand that these are two different types of data, it is only concerned about the value… so we can’t use these values. There is a way to solve this though.

Since both the left hand side and the right hand side need to have the same types of values, we could calculate the values to percentage of their respective max values, since that could be the common dinominator here.

Add the following directly after the strideBy towards the top of ChartView:

let costs = consumption.map { $0.cost }
let costMin = costs.min()!
let costMax = costs.max()!

let consumptions = consumption.map { $0.consumption }
let consumptionMin = consumptions.min()!
let consumptionMax = consumptions.max()!

This is merly getting the highest and lowest cost values and highest and lowest consumption values. Now change the value of Price in the first LineMark to:

.value("Price", item.cost / costMax)

and change the value of Consumption in the second LineMark to:

.value("Consumption", item.consumption / consumptionMax)

Now we need to update the Y axis, since the values won’t match up. You can replace the chartYAxis with the following code:

.chartYAxis {
    let defaultStride = Array(stride(from: 0, to: 1, by: 1.0/strideBy))
    let costsStride = Array(stride(from: costMin,
                                    through: costMax,
                                    by: (costMax - costMin)/strideBy))
    AxisMarks(position: .trailing, values: defaultStride) { axis in
        AxisGridLine()
        let value = costsStride[axis.index]
        AxisValueLabel("\(String(format: "%.2F", value)) kr", centered: false)
    }

    let consumptionStride = Array(stride(from: consumptionMin,
                                            through: consumptionMax,
                                            by: (consumptionMax - consumptionMin)/strideBy))
    AxisMarks(position: .leading, values: defaultStride) { axis in
        AxisGridLine()
        let value = consumptionStride[axis.index]
        AxisValueLabel("\(String(format: "%.2F", value)) kWh", centered: false)
    }
}

So, what are we doing above? We start off by adding a default stride, one that works for both LineMarks, which goes from 0 to 1 and is offset by the amount of marks we want to make. We use this defaultStride for both Y axis (left and right).

When we create each Y axis marks, we then calculate the value of each mark by using the costsStride and consumptionStride and add our own custom label instead. Now, lets re-run the code and see the result:

As you can see, both LineMarks use the full size of the chart, but each side has their own value.

Now, the only thing left to do is adding the scales in the correct order. Right now they show Cost and Consumption, but they should be the other way around. You can add the following modifier to the Chart to change the order:

.chartForegroundStyleScale([
    "Consumption": .blue,
    "Cost": .green,
])

This is the final result:

Here is the final code for you to try out in a playground:

Post notification to Slack from Xcode Cloud

Mon, 13 Jun 2022 19:00:00 +0000

Setup

This article is an continuation on the previous article I wrote called Getting Started with Xcode Cloud, I assume that you already have setup your Xcode cloud by now. In this article we’re going to continue to use the same demo repo which I’ve setup in the last article, this project is located on GitHub and can be found here.

Prerequisites

You will also need to be able to change the Slack settings for the team you want to implement this for. Being familiar with Slack Apps is also a pro, which is what you are going to setup here.

Changing the workflow

Now that you have your project ready, lets pop open the project in Xcode and navigate to the report tab (CMD + 9), and select the Cloud tab. Xcode will now show you your workflows which you created in the previous article, if you followed it step-by-step, it’ll be called Default. Now right click the Default workflow and select Edit workflow. A new modal window will pop up.

Connect slack

In the left hand menu, navigate to the Post-Actions section and select the action Notify.

Here you can select the (+) under “Slack”. Xcode will now ask you to connect your teams workspace. Select the Connect button and your webbrowser will open and browse to a page where you can add the Xcode Cloud app to your workspace. If you want to change workspace to add it to, you can select a different workspace in the top right corner.

For this article, I’m using one of my own workspaces in Slack on which I have admin rights. Yes, you could try to join that workspace.. but there issn’t really anything happening there though… so I’d say.. don’t bother 😆.

Once you have selected the Allow button, the browser would try to open Xcode again and have you select a channel to post to. Now, full disclosure… I had issues adding a channel here. The list keeps showing up empty. However, what I did was I opened my app in AppStore Connect and navigated to the Xcode Cloud tab > Manage Workflows > Default, here I went down to the bottom of the page where is stated “Slack” and selected the edit button. Here my channels did show and I could select the random channel.

Now, select Done and save your new workflow.

Result

Now, back in Xcode, right click on main under Default and select Start build. If you get the confirmation pop-up, select Start and a new build should be starting now.

Xcode will start a new build now and when finished, it’ll post a message in Slack like so:

Getting started with Xcode Cloud

Tue, 07 Jun 2022 19:00:00 +0000

Setup

For this article, I’ve setup a quick app which you can fork on GitHub. It is a simple app with a Hello, world! view and a manager with some tests. The project is located on GitHub and can be found here.

Prerequisites

In order to get going, you need to have the appropriate access in the Apple Developer Console, preferably admin or Team Agent. The latest agreement needs to be accepted by the team agent as well, which is done in the developer console.

You will also have to be able to grand Xcode Cloud access to your GitHub (or GitLab, or bitbucket cloud) repository. Being an admin for the repository does help here.

Setup bundle ID and app

In the example app mentioned above, I’ve setup the bundleId com.paulpeelen.setupxcodecloud. You will have to change this to something that suits you, and needs to be added to the developer console as well. Of course you can use automated signing in Xcode too, but I like to be explicit here.

When this is done, you can add the app to AppStore Connect too. Open AppStore Connect and go to your apps, select the (+) in the top left corner just next to “Apps” and add your app.

Now you should be ready to add your first workflow.

Adding your workflow

Workflows are sets of actions for Xcode Cloud to perform when running your app. An app can have multiple workflows. For instance, when a push is done towards a branch you might want the tests to be run but when a push is done towards the main branch, you want the tests to be run as well as the app to be uploaded to TestFlight

Lets create the first workflow for the project. There are two ways of doing this, either by going via the menu Product > Xcode Cloud > Create Workflow, or via the Report Navigator (CMD + 9) and select the cloud tab. If you don’t have any workflows yet, it’ll instruct you to create a workflow after analyzing your project. In the picture below you’ll see both options.

For this article, we’re going to focus on adding a workflow which will archive and upload to AppStore Connect so the app will be available in TestFlight. Select the Create workflow option of your choice and start adding a workflow. A modal view will popup which will let you select the team:

… after which it will show you a predefined selection of what to do. We’re going to edit the suggested workflow

So lets select that “Edit workflow” button and edit the workflow. The next view will show you the different steps that will be preformed.

In the left you’ll find a menu with the different steps for the workflow. The first one selected is the general flow. Here you can set some default settings for the workflow, like name and description. You can also restrict the workflow if you like.

Environment

In the next page, under Environment, you can select which environment you want Xcode cloud to build upon. For instance, do you want Xcode cloud to build on the beta version, as well as do you want to use caching (default) or would you like Xcode Cloud not to restore the derrived data. This can be useful for some project, but it will also increase the overall build time on Xcode. If you have a lot of developers on a large project, this might increase the build time per build with a few minutes… resulting in an overall increase per day of a possible few hours (depending on the amount of developers and the amount of builds). The last thing you can select here is whether you would like some environment variables to be set.

For this article, we’re just going to put it on the latest beta and be let the rest on this page be.

Start condition

This is the actual trigger for the workflow. This is by default set to the current branch you’re working on… in this case main. Any push to said branch will trigger this workflow to be started. We would like to keep it like that for this article, but there are other triggers available for it too: E.g. you can schedule a start of the workflow (good for nightly builds) or whenever a tag or Pull Request has changes.

For this article, we’re going to use the default setting, being whenever something is pushed to main.

Actions

For actions, by default it’ll just archive… but we want a test too. So. lets add it by selecting the (+) sign in the left menu, right of the “Actions” title, then select “Test”. We want the tests to be successfully passed before we start archiving, so lets make sure the option Required to pass is enabled. The default settings are fine here for this project, but for yours you might want to adapt it. For instance, you might want multiple test actions, one for each platform.

Post actions

Last but not least, the post notifications. Here you can make Xcode Cloud post a message to Slack or send you an email when the build has completed. For the slack connection, you’ll have to connect that via AppStore Connect settings, but there is a button that will take you there so you can configure it directly.

Here, I’m going to add my email address under “email”. For now, I’ll leave the slack integration for what it is. There will be a seperate article on that in the future if needed.

Now, lets select the Save button and close this view.

Review

Now, if you have done evertything correct… the review should look like this:

Grant access

Follow the granting access link and a website where you will grant Xcode Cloud access to the repository will show. For this article we’re using GitHub, and those pages will look like so at the time of writing this article:

Xcode Cloud

GitHub
Scroll down to the bottom to see the repository selection:

When you’re done… this is the message that should be presented on Apple’s website:

… and in Xcode:

Complete

Now you can select next and complete the setup of your first workflow. You are now able to add multiple others as well, maybe one for when pull requests are updated?

Xcode will ask you now if you want to start your first build… and of course we want that. Select “Start build” and… start your first build:

Now you are thinking… what now? How can I follow what is happening and not only just in my IDE? Well, in AppStore Connect you can open your app, and select the Xcode Cloud tab and see more details. You can also view this in the Report Navigator (CMD + 9), you can see all the builds that are ongoing or have completed.

When the first build is completed, it should look something like this:

Conclusion

When the setup is done, you can send the app in TestFlight directly for external testing. There is no need for another CI anymore; unless it is important for the company you work for the have the same CI for different platforms (e.g. iOS and Android).

Pros

Working with Xcode cloud is easy and fast. Everything is within the same IDE and access to the items are easilly controlled via AppStore Connect. The visualisation is great too, you can have access to the logs once builds are completed. There is no need for another CI nor Fastlane and everything exists within the same eco system that the developer is already used too.

Cons

I think the biggest drawback with Xcode Cloud is the dependency towards Apple and that the limitation that comes with it. The actions and post actions are decided by Apple, so if you want to do something custom you’ll have a harder time. There are no “run script” post actions or actions for that matter. That being said, there is a possibility to setup a custom webhook to a service of your choice to be informed about specified events happen. You can set this up in AppStore Connect > Your app > Xcode Cloud tab > Settings > Webhook, that said page looks like:

This also brings me to my second point… no Fastlane. Although Xcode Cloud takes away a lot that fastlane does, such as Scan, Deliver, Match ect… there is still a lot that Fastlane can do which Xcode Cloud doesn’t.

One thing I noticed while writing this article, there is no possibility for a Status Badge in your github repo with the branch status. If you would like to show in your public or private repo that the latest on your main branch has tested and build successfully, you can’t.

Next up

Now that you’ve setup your first project with Xcode Cloud, you can continue connecting Slack to your workspace. Learn more about how to do this here:

Setup Slack Notification with Xcode Cloud

Setup GitHub Actions Runner on M1 Mac

Wed, 18 May 2022 20:00:00 +0000

Intro

I assume you have a project setup and GitHub actions working. However, you can’t seem to figure out why the self-hosted runner issn’t using the full potentional of the M1. This is where this article comes in.

Background

Over my years as a developer my interest in continous integration and continuous deployment has increased from year to year, up to a point where I would like to argue that I am rather good at setting up and maintaining a few of the well known CI services on the market. However, GitHub Actions has not been in my aresenal of tools… that is, until now.

Runners

As of the writing of this article, GitHub runners run your code on x86_64 architecture. Meaning if you setup a runner on an M1 on MacOS, it’ll use said architecutre. In order to get the runner to run on arm64, you will have to tell phases in our workflow file to do so.

This is an example of a workflow file which runs using the M1 CPU:

name: iOS test branch

on:
  push:
    branches:
      - '*'
jobs:
  setup:
    name: Setting up the project with cache and pod- & bundle install
    runs-on: m1max
    steps:
      - name: Checkout repo
        uses: actions/checkout@v2
        with:
          clean: false
      - name: Install GEM dependencies
        run: arch -arm64 gem install bundler
      - name: Bundle install
        run: |
          cd MyProject
          arch -arm64 bundle install
      - name: Pod install
        run: |
          cd MyProject
          arch -arm64 pod install
      - name: Test project
        run: |
          cd MyProject
          arch -arm64 bundle exec fastlane ios buildAndTest

What this does is that is tells the workflow script at each step to perform an action using the arm64 architecture. The clue is using arch -arm64 when calling commands from your workflow.

If you have build using the runner already, make sure you clean your derived folder so it can make a clean build. It might sometimes also be good to clean the Pods folder (if you are using Cocoapods).

Setting up your first CarPlay "app"

Wed, 18 May 2022 19:00:00 +0000

Intro

Allthough apps on CarPlay are commonly refered to as “Open the CarPlay app”, it is actually not an app by itself.
CarPlay is merely a seperate screen to your iPhone, much like a projector is to a laptop. The content that is shown on the car’s headunit is generated by the iOS device and streamed to the headunit. The only thing the headunit does is it tells the iOS devices connected (either via bluetooth & Wifi or via USB cable) the input from the user (which can both be touch and non-touch) and some pheripheral information such as screen size, GPS, button press ect.

So, a “CarPlay-app” shares the resources with the main app on the iOS device; thus if you would launch your app from CarPlay and then open it on the iOS device; the app should already be loaded into memory… and vice-versa.

The evolution of CarPlay

A few years ago, before the launch of Xcode 12 and iOS 14, the CarPlay documentation was a bit hush-hush… only a selected few such as Waze, Spotify and BookBeat ect were allowed to build a CarPlay integration.
This, however, all changed in 2020 when Apple released CarPlay to all developers to play around with. That being said, in order to add support for CarPlay in your app and release it to the world you still need Apple’s approval. You (or better yet, your team agent) need to contact apple via http://developer.apple.com/carplay/ and request access. If you have made a strong enough case and get approved, an option to your provisioning profiles page on Apple’s developer portal will be added. It is at this point that you can build your app to a device and test it in an actual car as well as releaae it on the AppStore. Until that point you can only test it locally using the simulator.

The essentials of CarPlay

The CarPlay Framework consists of templates which you set in your code and send to the Interface Controller, whom in turn will take care of all the rendering. Which templates you’ll have access to depends on the category you are using in your entitlement and provisioning profile. Be careful when you make your choice, since your app can only have access to 1 category.

These are the templates which are availble to you: Source: CarPlay App Programming Guide

Getting started

Lets start off with a basic app. I assume that you already have an app in place, if not then there are multiple good guides out there on how to get started with your first project.

Now that we have our app, we need to add an entitlement to it. The easiest way to have Xcode add an entitlement is by opening the project and add a capability to it. Add something like Associated domain or so, and it’ll add the entitlement file.

Now with the entitlement file created, you can open it in Xcode and add the category. In this tutorial, we’re going to use the com.apple.developer.carplay-parking category, since that is the one I am most familiar with. Add a new line and add the category name as key and 1 as value, like so: Now you can also select the Associated domain line and remove it.

With this added, you also need to make a change to your Info.plist file. Open your project, select the Info tab. Copy the XML below, and paste this into your Info.plist. If you are adding CarPlay to an app which uses Scene Delegates than locate the row called Application Scene Manifest and paste the contents of UISceneConfigurations, otherwise paste the whole thing.

<key>UIApplicationSupportsMultipleScenes</key>
<false/>
<key>UISceneConfigurations</key>
<dict>
    <key>CPTemplateApplicationSceneSessionRoleApplication</key>
    <array>
        <dict>
            <key>UISceneClassName</key>
            <string>CPTemplateApplicationScene</string>
            <key>UISceneDelegateClassName</key>
            <string>$(PRODUCT_MODULE_NAME).CarPlaySceneDelegate</string>
            <key>UISceneConfigurationName</key>
            <string>ParkingPlay-Car</string>
        </dict>
    </array>
</dict>

The endresult should look like this:

What this last part does is it tells the system where to send the scene lifecycle event when your app is launched. So when the app is launched via CarPlay, the file CarPlaySceneDelegate will be called, which will have to conform to CPTemplateApplicationSceneDelegate.

SceneDelegate

Now that those are in place, lets start with some code.

Create a new folder called “CarPlay” under your main project folder and add a file called CarPlaySceneDelegate.swift. Open this file and lets start adding some code:

import CarPlay

class CarPlaySceneDelegate: UIResponder, CPTemplateApplicationSceneDelegate {
    private var interfaceController: CPInterfaceController?

    /// 1. CarPlay connected
    func templateApplicationScene(
        _ templateApplicationScene: CPTemplateApplicationScene,
        didConnect interfaceController: CPInterfaceController
    ) {
        // 2
        self.interfaceController = interfaceController

        // 3
        setInformationTemplate()
    }

    /// 4. Information template
    private func setInformationTemplate() {
        // 5 - Setting the content for the template
        let items: [CPInformationItem] = [
            CPInformationItem(
                title: "Template type",
                detail: "Information Template (CPInformationTemplate)"
            )
        ]

        // 6 - Selecting the template
        let infoTemplate = CPInformationTemplate(title: "My first template",
                                                 layout: .leading,
                                                 items: items,
                                                 actions: [])

        // 7 - Setting the information template as the root template
        interfaceController?.setRootTemplate(infoTemplate,
                                             animated: true,
                                             completion: { success, error in
            debugPrint("Success: \(success)")

            if let error = error {
                debugPrint("Error: \(error)")
            }
        })
    }
}

The following things happen in the code above:

1

This is called by the CarPlay Framework when CarPlay is launched.

2

We store the interface controller to our class. The Interface Controller is what we use to set which template should be shown, animations and transitions.

3

We call our method setInformationTemplate(), which will show us an information template.

4

The information template method.

5

For the information template, we need an array of items to show. Here we’re just going to show one item on our template with a title and a subtitle.

6

Now we setup our CPInformationTemplate, giving it a title and a list if items to display in the template. It can also take actions and have a different layout.

7

Now we are telling the Interface Controller, which we stored in step 2, that we want to display an template. When it is done, it will show the template we’ve send in.

Launch

Now lets launch the app on the CarPlay simulator and see how it looks. If you have done the above right, the result should look like this:

End

Now you have successfully built your first CarPlay app and launched in the simulator. Before I continue and write a Part 2 to this article, going into depth about the other templates in the sample project, send me a comment below if this is of interest to you!

Happy coding!

Creating an API serving CoreML results

Mon, 13 Sep 2021 23:00:01 +0000

Using CoreML

Build intelligence into your app by adding CoreML to it, it can help you recognize shapes, images, depth and much more. This can improve your app immensely, but it also comes with some downsides. A CoreML library can increase the binary size of your app rapidly; it will also require a new app release each time you improve your model. This can be painstaking and annoying to do. A nice way of solving this would be by using an rest API, which is common for many apps and the app you are working on might already have support for it… the problem is, CoreML doesn’t have support for it. So, how can we solve this?

In this post we’re going to try to solve this by setting up a rest API and trying to have it classify images using’s Apple Image classification model.

Requirements

Before you scroll to the end of this article and try to download the source and push it to heroku… there are some thing you need to keep in mind. First and foremost, you need to run the api on MacOS. E.g. you can set this up on an old MacBook you have laying around? Maybe you already rent a server with MacOS? Because we need to use the CoreImage framework as well as CoreML and Vision frameworks, we need to run it on MacOS… running it on Linux won’t work.

Also, if you have done some Vapor before, it’ll help a lot.

1. Installation

If you have Vapor already installed, you skip this section.

Make sure Xcode installed on your system, if not download it and while installing, start by going to Vapor.codes and read their getting started documentation. Once installed, install Homebrew, followed by installing Vapor using the following command:

brew tap vapor/tap
brew install vapor

Now that you have Vapor installed, we can continue to setting up your project.

2. Setup new project

Now that you have vapor installed, you can setup your new project. Because we will be using the SqueezeNet model from Apple later on, lets call our API the SqueezeNetAPI. Open a terminal window, go to the location you wish to create your project and write the following:

vapor new SqueezeNetAPI

Once completed, you will have a new folder called SqueezeNetAPI. Enter the folder and launch the project in Xcode:

cd SqueezeNetAPI
vapor xcode

Xcode will open the project and start downloading the dependencies for the project, defined in the Package.swift file. There is no Xcode project file or workspace; vapor uses the Package.swift file for using Swift Package Manager. Details about the vapor structure of the project can be found here and here.

Once done, we need to change the working directory for the project. To do so, open the Edit Schema view in Xcode and select the Options tab under Run. You can open this view via the menu Product > Scheme > Edit scheme, or selecting Edit Scheme from run target selection (see image), or using the keys ⌘ Command + <.

Select Use custom working directory to enabled and select the root of your project as target.

3. Adding and compiling the CoreML model

Before we write code, lets add the CoreML model. Start by visiting Apple’s Core ML models website for downloading the model called SqueezeNet.

In your SqueezeNetAPI project folder, there is a folder called Resources, open this folder and inside create a new folder called coreml. Place the SqueezeNet.mlmodel you’ve just downloaded inside this folder and return to your terminal.

Since this issn’t an iOS or MacOS project, we can’t just drag and drop the mlmodel file into our project and run it normally, instead we need to compile the model ourselves. First off, let’s compile the mlmodel to a binary format which we can include into our project. Go back to your terminal and while in the root of our project, run the following command:

xcrun coremlcompiler compile Resources/coreml/SqueezeNet.mlmodel Resources/coreml

Once completed, a set of new files will have been created in the same location and the mlmodel was stored. If you look in Xcode, your folder structure should now have two “files” called SqueezeNet

Now that this is done, we need to generate the source code to this interface. Back in the terminal, execute the following command:

xcrun coremlcompiler generate Resources/coreml/SqueezeNet.mlmodel --language Swift Sources/App/

This will generate a file called SqueezeNet.swift inside Sources/App/. This is the file we’re later going to use with our model.

4. Adapting the CoreML file

Now that we have our model included in the project as well as the source code to it, we need to adapt it. In Xcode, open the file called SqueezeNet.swift. In the top of the file, add the import of Vapor like so:

import Vapor

Thereafter go to the definition of urlOfModelInThisBundle, at line 104. Here we need to change how we are going to load our model. In Vapor, we don’t access files using our bundle, but instead we use something called DirectoryConfiguration. Change this method to the following:

class var urlOfModelInThisBundle : URL {
    let directory = DirectoryConfiguration.detect()
    return URL(fileURLWithPath: directory.workingDirectory)
        .appendingPathComponent("Resources/coreml/SqueezeNet.mlmodelc",
                                isDirectory: true
        )
}

What this will do is that it will access the compiled mlmodelc at the correct location when we need it.

If you like, you can now run the project and in safari you can browse to http://localhost:8080/hello. You will now see a Hello, world! page of you project.

5. Adding our first route

The Hello, World! page is all fun and games, but this is not really what we want. What we want to do is have a REST api which will take an image and returns a image classification for said image. Let’s call this a “Classification”.

Back in Xcode, we will start off by browsing to Sources > App > Controllers and adding a new file here. Call this file ClassificationController.swift and give it the following content:

import Vapor

struct ClassificationController: RouteCollection {
    func boot(routes: RoutesBuilder) throws {
        routes.on(.POST,
                  "classify",
                  body: .collect(maxSize: ByteCount(value: 2000*1024)),
                  use: classification
        )
    }

    func classification(req: Request) throws -> String {
        return "Success"
    }
}

Now we have added a routeCollection. There are multiple ways of handing routes, this is one of them. We have now create a way for us the gather all classification related routes to one controller called the “ClassificationController”. Right now it will handle one route, which is /classify for POST requests. It will also allow it to send in a body with a max size of ~2mb.

In order to get this route collection to work, we need to change the routes.swift file. Lets open the files routes.swift and exchange the func routes(_:) throws func to the following:

func routes(_ app: Application) throws {
    try app.register(collection: ClassificationController())
}

Now you can make a post request to http://localhost:8080/classify which will return you the text Success when finished.

5.1 Accepting a file

In order for us to classify an image, we need to actually be able to send one in. Lets create a folder in Sources > App called Models and add a new file called ClassifyRequest.swift to it. Give ClassifyRequest.swift the following content:

import Vapor

struct ClassifyRequest: Content {
    let image: File
}

Back in ClassificationController, add the following code to the classify route:

let classificationRequest = try req.content.decode(ClassificationRequest.self)
let image = classificationRequest.image
let data = Data(buffer: image.data)

Now we can get the Data from the file you have send in using curl.

6. Setting up the Image Classifier

Under Sources > App, add a new file called ImageClassifier.swift and give it the following content:

import Vapor
import CoreML
import Vision
import CoreImage

enum ImageClassifierError: Error {
    case nothingRecognised
    case unableToClassify
    case invalidImage
}

struct ClassificationResult: Content {
    let identifier: String
    let confidence: Float
}

class ImageClassifier {
    typealias classificationCompletion = ((Result<[ClassificationResult], ImageClassifierError>) -> Void)
    private var completionClosure: classificationCompletion?

    lazy var request: VNCoreMLRequest = {
        let config = MLModelConfiguration()
        config.computeUnits = .all

        do {
            let model = try VNCoreMLModel(for: SqueezeNet(configuration: config).model)
            let request = VNCoreMLRequest(model: model, completionHandler: handleClassifications)
            request.imageCropAndScaleOption = .centerCrop

            return request
        } catch {
            fatalError("Failed to load the model. Error: \(error.localizedDescription)")
        }
    }()

    func getClassification(forImageData imageData: Data, orientation: CGImagePropertyOrientation, completion: @escaping classificationCompletion) {
        guard let ciImage = CIImage(data: imageData) else {
            completion(.failure(.invalidImage))
            return
        }

        completionClosure = completion

        let handler = VNImageRequestHandler(ciImage: ciImage, orientation: orientation)
        do {
            try handler.perform([self.request])
        } catch {
            print("Failed to perform classification.\n\(error.localizedDescription)")
        }
    }
}

private extension ImageClassifier {
    func handleClassifications(forRequest request: VNRequest, error: Error?) {
        guard
            let results = request.results,
            let classifications = results as? [VNClassificationObservation]
        else {
            debugPrint("Unable to classify image.\n\(error!.localizedDescription)")
            completionClosure?(.failure(.unableToClassify))
            return
        }

        if classifications.isEmpty {
            completionClosure?(.failure(.nothingRecognised))
        } else {
            let topClassifications = classifications.prefix(2)
            let results = topClassifications.map { classification in
                ClassificationResult(identifier: classification.identifier, confidence: classification.confidence)
            }
            completionClosure?(.success(results))
        }
    }
}

I’m not going too much into detail about what this class does, there are great tutorials out there on Image Classification as well as Sample projects from Apple which you can download and checkout out; however the gist of this class is that it’ll take a CIImage with orientation and sends it in into our model for classification. It will then take out the top classifications and return those as an array.

This file will also define the struct ClassificationResult which we will use for the return data.

7. Returning the classification

Now that we have the image classifier class in place, we must update the route to actually call it. In order to do so, lets update our ClassificationController.swift’s route to the following:

func classification(req: Request) throws -> EventLoopFuture<[ClassificationResult]> {
    let eventLoop = req.eventLoop.makePromise(of: [ClassificationResult].self)

    let request = try req.content.decode(ClassifyRequest.self)
    let image = request.image
    let data = Data(buffer: image.data)
    guard let orientation = CGImagePropertyOrientation(rawValue: 0) else { throw Abort(.internalServerError) }

    imageClassifier.getClassification(forImageData: data, orientation: orientation) { result in
        switch result {
        case .success(let classificationResults):
            eventLoop.succeed(classificationResults)
        case .failure(let error):
            eventLoop.fail(error)
        }
    }

    return eventLoop.futureResult
}

The changes we made here is that we changed from a return value of String to an EventloopFuture, this will promise that the function will eventually return something of type [ClassificationResult], which in turn conforms to Content which is something Vapor will be able to translate to JSON. See Content as a Codable on iOS.

If you now run this project and go to the terminal and fire the same curl command as last time, you should see the following result for this picture:

$ curl --form image='@cheetah.png' http://localhost:8080/classify
[{"confidence":0.99956685304641724,"identifier":"cheetah, chetah, Acinonyx jubatus"},{"confidence":0.00034059779136441648,"identifier":"jaguar, panther, Panthera onca, Felis onca"}]

Voila! Now you have your vapor project return an CoreML classification!

8. Known issues

There are a few known issues. The ones I can come up with are listed here:

Orientation

As you might have noticed, we’re setting a hard-coded orientation. Since we don’t have support for UIImage on this platform (UIKit is not supported), we can’t get the image orientation from the image. Maybe this is possible in CIImage or CGImage, I haven’t checked (yet). Otherwise, if you can have the client send in an orientation which you map to CGImagePropertyOrientation.

JPEG support

Some JPG/JPEG images won’t work for me, especially if they are of a large size. Whenever I send a JPG image, I sometimes get the error:

HWJPEG not available on this platform

9. Sourcecode project

A tutorial like this wouldn’t be complete without the finished source. However, due to copyright reasons the CoreML model is not included. Download this from here and follow the steps mentioned above.

You can clone this project from my public repository here: https://github.com/ppeelen/SqueezeNetAPI

A simple network manager in Swift

Tue, 15 Jun 2021 17:30:00 +0000

the Quest for a simple network manager

Many, if not most, of the apps I’ve worked on require some sort of network manager and all those that do will connect to one and the same api; often a proxy between the app and several other backend services; either being it in-house at a client or for one of my personal apps.

There are many different ways of introducing network support in your app; there are third party libraries that you can use which offer loads of different options (one of those that come to mind is Alamofire) or you can make one yourself. It is easier than you think.

The network manager

In many cases the most common network requests are GET and POST requests; on top of that, some apps fetch images asynchronous as well. In this article we are going to focus on the former two. These requests don’t require a full blown network library (which by the way will add to your apps binary size and also increase the startup time of your app). So what should you use instead? Well, the answer is simple, URL Loading System. This is what most, if not all, of those 3rd party libraries use underneath.

If you are used to using e.g. Alamofire, using URLSession and URLRequests might frighten you a little but there is no reason for fear. To make a simple GET requests, all you need is a few lines of code. For the example below I’ve setup a mockAPI at https://mockapi.io so you can tryout the code directly in a playground.

import Foundation

/// This is the object we're looking to get from the endpoint
struct User: Codable {
    let id: String
    let createdAt: Date
    let name: String
    let avatar: URL
}

/// This is our network class, it will handle all our requests
class NetworkManager {

    /// These are the errors this class might return
    enum ManagerErrors: Error {
        case invalidResponse
        case invalidStatusCode(Int)
    }

    /// The request method you like to use
    enum HttpMethod: String {
        case get
        case post

        var method: String { rawValue.uppercased() }
    }

    /// Request data from an endpoint
    /// - Parameters:
    ///   - url: the URL
    ///   - httpMethod: The HTTP Method to use, either get or post in this case
    ///   - completion: The completion closure, returning a Result of either the generic type or an error
    func request<T: Decodable>(fromURL url: URL, httpMethod: HttpMethod = .get, completion: @escaping (Result<T, Error>) -> Void) {

        // Because URLSession returns on the queue it creates for the request, we need to make sure we return on one and the same queue.
        // You can do this by either create a queue in your class (NetworkManager) which you return on, or return on the main queue.
        let completionOnMain: (Result<T, Error>) -> Void = { result in
            DispatchQueue.main.async {
                completion(result)
            }
        }

        // Create the request. On the request you can define if it is a GET or POST request, add body and more.
        var request = URLRequest(url: url)
        request.httpMethod = httpMethod.method

        let urlSession = URLSession.shared.dataTask(with: request) { data, response, error in
            // First check if we got an error, if so we are not interested in the response or data.
            // Remember, and 404, 500, 501 http error code does not result in an error in URLSession, it
            // will only return an error here in case of e.g. Network timeout.
            if let error = error {
                completionOnMain(.failure(error))
                return
            }

            // Lets check the status code, we are only interested in results between 200 and 300 in statuscode. If the statuscode is anything
            // else we want to return the error with the statuscode that was returned. In this case, we do not care about the data.
            guard let urlResponse = response as? HTTPURLResponse else { return completionOnMain(.failure(ManagerErrors.invalidResponse)) }
            if !(200..<300).contains(urlResponse.statusCode) {
                return completionOnMain(.failure(ManagerErrors.invalidStatusCode(urlResponse.statusCode)))
            }

            // Now that all our prerequisites are fullfilled, we can take our data and try to translate it to our generic type of T.
            guard let data = data else { return }
            do {
                let users = try JSONDecoder().decode(T.self, from: data)
                completionOnMain(.success(users))
            } catch {
                debugPrint("Could not translate the data to the requested type. Reason: \(error.localizedDescription)")
                completionOnMain(.failure(error))
            }
        }

        // Start the request
        urlSession.resume()
    }
}

// Create the URL to fetch
guard let url = URL(string: "https://60c86ffcafc88600179f70e2.mockapi.io/api/getRequest") else { fatalError("Invalid URL") }

// Create the network manager
let networkManager = NetworkManager()

// Request data from the backend
networkManager.request(fromURL: url) { (result: Result<[User], Error>) in
    switch result {
    case .success(let users):
        debugPrint("We got a successful result with \(users.count) users.")
    case .failure(let error):
        debugPrint("We got a failure trying to get the users. The error we got was: \(error.localizedDescription)")
    }
 }

Most of the code above might seem like a lot, but it really is not, it is the documentation I’ve added that makes it look like there is a lot. So what does it do?

The code above will try to make a GET request towards the url https://60c86ffcafc88600179f70e2.mockapi.io/api/getRequest. If it succeeds it will return a Result with type [User], and if it fails it will return a Result with type Error. Yes, I added Result with capital R here.. this is because I am referencing a type of object that is returned, one that is really handy to use in Swift.

So what if you want to make a POST request? Just add the method parameter to the request type.

What if I just want Data?

This is easy too, you don’t need to create yet another request method… it works with the one you’ve already added. There are only 3 lines of code you need to add just after the guard let data = data part and before the Do / Catch block; those lines are the following:

if let data = data as? T {
    completionOnMain(.success(data))
    return
}

and then you can call your request like so:

// Request data from the backend
networkManager.request(fromURL: url) { (result: Result<Data, Error>) in
    switch result {
    case .success(let data):
        debugPrint("We got a successful result with data of \(data.count) bytes.")
    case .failure(let error):
        debugPrint("We got a failure trying to get the data. The error we got was: \(error.localizedDescription)")
    }
 }

So what did we do? Well, out of the box, Data already conforms to Decodable; however this requires the content of Data to be in a JSON format. However, since Data already conforms to Codable we do not have to function overload the request method with a different type.. we can just use the one with the T: Decodable generic type instead. However, before we decode we need to check if the result data we get back conforms to the type we actually are looking for (In this case Data), and since we’re just looking for Data and data will conform to Data, we can just return that object directly.

This is how simple it is to make GET or POST requests, without pulling in a whole network library. Keep it simple, and use the power of Swift with Generics, Result and URL Loading System.

Paul Peelen

OS Style settings view, Part 2

Introduction

OS Style Settings View, Part 1

MacOS setting

Sidebar

Updating the page

Details

Removing Sidebar toggle

Sidebar size

Code

OS Style settings view

Introduction

Old vs New

Adding Settings to your app

Updating the UI

Adding groups

Create a calendar view in SwiftUI

Introduction

Installation

Usage

Documentation

SwiftUI Multi data-type chart

Introduction

The basics

Axis labels

Merging the two

Fixing the messed up chart

Post notification to Slack from Xcode Cloud

Setup

Getting started with Xcode Cloud

Prerequisites

Changing the workflow

Connect slack

Result

Getting started with Xcode Cloud

Setup

Prerequisites

Setup bundle ID and app

Adding your workflow

Environment

Start condition

Actions

Post actions

Review

Grant access

Complete

Conclusion

Pros

Cons

Next up

Setup GitHub Actions Runner on M1 Mac

Intro

Background

Runners

Setting up your first CarPlay "app"

Intro

The evolution of CarPlay

The essentials of CarPlay

Getting started

SceneDelegate

1

2

3

4

5

6

7

Launch

End

Creating an API serving CoreML results

Using CoreML

Requirements

1. Installation

2. Setup new project

3. Adding and compiling the CoreML model

4. Adapting the CoreML file

5. Adding our first route

5.1 Accepting a file

6. Setting up the Image Classifier