More specifically, I’ll tell you how to install Apple’s new and first alpha version of its desktop operating system software, macOS Ventura 13.0, from a Mac that is most likely still on macOS Monterey — especially if you keep up with the Apple world. I’ll also tell you how to download installers for approximately every public macOS build number within the last two years.

We’ll be using the command line (Terminal)

I’m assuming that readers are familiar with Terminal.app, which allows people like you and me to execute commands and run utilities directly through the operating system “shell.” If you’re not, please look at one of the many, many great Terminal tutorials available on the web. You’ll figure it out in no time.

Before you do anything like upgrade your Mac’s operating system version, you should know what operating system version you’re currently running. It takes me more time to use my Mac’s user interface to find macOS details. I can get my macOS details much faster by entering this short Terminal command:

% sw_vers                
ProductName:	macOS
ProductVersion:	12.3.1
BuildVersion:	21E258

Note that the output from the shell command, sw_vers, is shown immediately after the command. This is the format I’ll use when displaying events in Terminal.

If I go to Apple > About This Mac, I have to click into the macOS version number to make the build number appear, and it’s just awkward, like so:

Finding out what macOS installers are available from Apple

Suppose I want to find out if I can 1) upgrade my current Monterey partition to Ventura or 2) install an older version of macOS, namely macOS Big Sur 11.6.6, on another partition from Ventura? To find out what macOS installers are currently available from Apple, enter the following command in Terminal:

% softwareupdate --list-full-installers

Finding available software
Software Update found the following full installers:
* Title: macOS Ventura beta, Version: 13.1, Size: 11548070KiB, Build: 22C5033e
* Title: macOS Ventura, Version: 13.0, Size: 11866804KiB, Build: 22A380
* Title: macOS Monterey, Version: 12.6.1, Size: 12108491KiB, Build: 21G217
* Title: macOS Monterey, Version: 12.6.1, Size: 12110530KiB, Build: 21G215
* Title: macOS Monterey, Version: 12.6, Size: 12104042KiB, Build: 21G115
* Title: macOS Monterey, Version: 12.5.1, Size: 12114929KiB, Build: 21G83
* Title: macOS Monterey, Version: 12.5, Size: 12112497KiB, Build: 21G72
* Title: macOS Big Sur, Version: 11.7.1, Size: 12119247KiB, Build: 20G918
* Title: macOS Big Sur, Version: 11.7, Size: 12118755KiB, Build: 20G817
* Title: macOS Big Sur, Version: 11.6.8, Size: 12118851KiB, Build: 20G730
* Title: macOS Big Sur, Version: 11.6.6, Size: 12121263KiB, Build: 20G624
* Title: macOS Big Sur, Version: 11.6.5, Size: 12121404KiB, Build: 20G527
* Title: macOS Big Sur, Version: 11.6.4, Size: 12147782KiB, Build: 20G417
* Title: macOS Big Sur, Version: 11.6.3, Size: 12143674KiB, Build: 20G415
* Title: macOS Big Sur, Version: 11.6.2, Size: 12141944KiB, Build: 20G314
* Title: macOS Big Sur, Version: 11.6.1, Size: 12137180KiB, Build: 20G224
* Title: macOS Big Sur, Version: 11.5.2, Size: 12149332KiB, Build: 20G95
* Title: macOS Ventura 13.1 Beta 2, Version: 13.1, Size: 10725858KiB, Build: (null)

Notice that I highlighted two lines of output from the softwareupdate command I just ran? These are the two installers I was looking for. Let’s find out how to download them, where they download to, and how to run the downloaded installers.

Downloading a macOS installer from Apple

First, let’s download the installer app for macOS Ventura 13.0 (22A380) from Monterey. The installer was listed as available in the last Terminal code snippet I just showed you. When using this tool in the future, you always want to make sure that you’re downloading the installer with the right build number. I won’t go into details today but, trust me, I’ve verified that we want macOS build 22A380 to install the one and only publicly-released alpha build of Ventura. Let’s start downloading the installer app:

% softwareupdate --fetch-full-installer --full-installer-version 13.0

This commands requires you to enter the Mac’s administrator password, and it’ll prompt you for that password:

% softwareupdate --fetch-full-installer --full-installer-version 13.0
Password:

After talking with the Apple server for a few seconds, the command will tell you what it’s doing:

% softwareupdate --fetch-full-installer --full-installer-version 13.0
Password:
Scanning for 13.0 installer

Once the softwareupdate command starts downloading the installer app to your /Applications folder, it shows you progress in the command line:

% softwareupdate --fetch-full-installer --full-installer-version 13.0
Password:
Scanning for 13.0 installer
Installing: 12.0%

IMPORTANT: Even though softwareupdate says it’s “Installing,” it’s NOT installing an operating system. It is only downloading a macOS installer app that has to be specifically run to install anything.

When the softwareupdate command finishes downloading the installer app to your /Applications folder, it tells you everything went well in the command line:

% softwareupdate --fetch-full-installer --full-installer-version 13.0
Password:
Scanning for 13.0 installer
Install finished successfully

Use Finder to look in the /Applications folder and you’ll see that the macOS Ventura 13.0 installer app is waiting for you to use.

When you’re ready to install or upgrade to Ventura, grab a Finder window, go to the /Applications folder, and run Install macOS Ventura.app. The normal Apple installer will run for Ventura:

Downloading other macOS installers

Remember that I also wanted to download macOS Big Sur 11.6.6 (20G624). Let’s do that on Ventura. I’m dealing with a service ticket wherein a specific app always crashes when certain features are used in Big Sur 11.6.6. I’ve got a partition ready. I just need the installer so I can recreate my customer’s environment. As you’ll see, the process for getting a Big Sur 11.6.6 installer app is the same as it was for getting the Ventura installer app. I can download as many macOS installers as I want.

I look up the macOS version I need, then download its installer app if available…

% softwareupdate --fetch-full-installer --full-installer-version 11.6.6
Password:
Scanning for 11.6.6 installer
Install finished successfully

… Then I look in /Applications a find my installer app. I can run this anytime I want:

Conclusion

A great reason to use the softwareupdate command in Terminal is, obviously, that you can upgrade to Ventura using a safe and reliable tool. Another great reason to use softwareupdate is to always have access to as many of Apple’s older macOS versions as possible.

I have customers whose commitment to quality is par excellence. They’re willing to reproduce bug’s in their software that are specific to a particular macOS build, like macOS Big Sur 11.6.6. All’s they need is to look through their list of installers and run the one found, targeting some freshly-formatted partition. One customer I have has installers going back to macOS 10.6. Another keeps active macOS partitions installed and ready to be booted.

You may just find yourself one day with a piece of software that stopped being supported after a certain macOS build was forgotten by Apple’s memory, but you REALLY like the way your software worked. You can now get that app version back up and running.

You’ll have to do some regular book-keeping and check for and download macOS installer builds as they come and go. Apple is always on the move and you’ll only have a certain window of time to download and archive those macOS installers if you want good version coverage. Check often, download, and make backups.

I hope you enjoyed today’s session. Check back soon as this site is soon to be a hub of activity. We’ll be publishing more tutorials — but we’ll be adding videos and a new line of books that you can purchase to make you into the best of the best Apple developers.

As long as all developers involved in creating apps meant to be part of an app group can securely share a Team ID from an Apple Developer portal account, they can write apps that can transcend sandboxing. A company may carefully decide to share its Team ID with a trusted partner company, not just with different teams within its own organizational structure.

Member apps of an app group share access to a special group container, a shared folder structure, whose root folder has the same name as the app group ID. In the macOS sample app that accompanies this tutorial, several apps share a preference stored in a .plist file that lives in the special group container. The preference is the background color to be used by app group apps’ UIView instances. If one app sets (writes) this shared background color preference to, say, the color green, other app group members read this preference and can change their view layer backgroundColor property to NSColor.green.cgColor. By starting an app group, I’ve created the beginnings of a group of related apps sharing — centralizing — settings like view color scheme, even if all the apps are sandboxed.

You can already imagine the possibilities: shared preferences, shared licensing, shared caches, and/or shared databases. Apple says this capability “allows the apps within the group to share Mach and POSIX semaphores and to use certain other IPC [interprocess communication] mechanisms among the group’s members.” So, for example, you can have member apps performing thread-safe operations on shared resources.

Today, I’ll walk you through the configuration and encoding of a macOS app group whose members communicate through a shared instance of UserDefaults, more commonly known as user preferences. One app allows me (and my users) to pick a view background color — like a theme color — and write it to my shared UserDefaults. The other app can read that same shared preference and update its view’s background color to the currently saved value. This process is dynamic. As I change the theme color in one app, the other app can update its view’s background color immediately. We’ll build these apps and app group together in this tutorial. You can download the sample apps here. Here’s a video of my two sample apps coordinating together:

Probably one of the most intriguing aspects of app groups is that their commonly shared container, a mini folder and file system, transcends sandboxing. To highlight the flexibility of app groups on macOS, one of my sample apps is sandboxed while the other is not. On iOS, remember that all your apps are sandboxed.

App groups are a great feature, but unfortunately they’re not well-documented and therefore generally not well understood. For example, Apple has a section in it’s macOS developer documentation called “Adding an App to an App Group” which strongly implies that all you have to do is add an entitlement to your app’s project. In another developer document, Apple states “You control the groups that your app belongs to by manipulating its entitlements.” No mention is made of a very crucial step: registering your app group ID under your account on the Apple Developer portal.

For awhile, adding an app group identifier to an Xcode project’s entitlements was sufficient in macOS to create and join an app group. Only iOS required that developers have an account with Apple and that they register the app group ID on the Apple Developer portal. That requirement now applies to macOS app groups, too.

If you have a number of related apps, especially ones you sell as part of an App Store bundle, then app groups might be for you. Keep in mind that apps can be members of more than one app group, too.

Let’s walk though all the required steps to create two macOS apps that demonstrate app groups — and note that almost all the content herein applies to iOS app groups.

Registering your app group’s ID

The first thing to do when creating an app group is to register an app group ID. Have a copy of your Apple Developer account’s Team ID ready, like copied into your clipboard. In the screenshots shown below, you’ll substitute your own Team ID where I’ve redacted my own. Let’s get started:

1. Login to your Apple Developer account;
2. Select Certificates, IDs & Profiles from the left sidebar or the center of the screen;
3. You’ll land on the Certificates screen by default, but select Identifiers from the left sidebar;
4. Click the dropdown labelled App IDs, like so:

5. Select the App Groups option from the dropdown;
6. Now that you’re on the Identifiers for App Groups page, click the plus-sign-inside-the-circle button;
7. On the Register a New Identifier page that comes up, select the App Groups radio button, like this:

8. Click the big, blue Continue button on the upper right-hand side of the same page;
9. You’ll land on the Register an App Group page where you’ll get ready to fill in the Description and Identifier fields;
10. Type in a meaningful Description and type/paste your Team ID into the Identifier field;
11. Notice that “group.” is prepended to the Identifier, and that I added some meaningful text, following Apple’s suggestion, like this:

12. Click the big, blue Continue button;
13. You can review your new app group ID, are given the chance to click Back to make changes, but we’ll select the Register button; and,
14. Now back on the Identifiers for App Groups page, you’ll see that you’ve created a new app group.

The app group’s shared container

By definition, an app group is a collection of two or more apps. Whichever app that is a member of the app group, and runs before any of the other member apps run, creates what’s called the group’s “shared container.” It does this once unless someone deletes the container, in which case macOS recreates the container when it is next referenced by one of the group’s member apps. That container is a mini folder/file system like those that macOS provides for sandboxed apps. It’s a bit like the folder system that macOS builds for each user on a Mac or MacBook. Every shared container is stored in the macOS file system in a folder that has the same name as the app group ID, like group.TEAM_ID.com.domain.MyAppSuite. That folder is always stored in the macOS file system in ~/Library/Group Containers/. So the full container path is ~/Library/Group Containers/group.TEAM_ID.com.domain.MyAppSuite. Here’s what the shared container looks like right after it’s created, including the preferences .plist:

The app group has its own user preferences data store, accessible via a special instance of UserDefaults. These preferences are stored in a .plist file just like they are for all macOS apps. In this tutorial, those preferences are stored in the file at this path:

~/Library/Group Containers/group.YOUR_TEAM_ID.com.domain.MyAppSuite/Library/Preferences/group.YOUR_TEAM_ID.com.domain.MyAppSuite.plist

All apps in the app group have read and write access to the shared container, including access to the shared preferences.

A word about my sample code

My code is semantically clear and well commented — but simple. You shouldn’t have any trouble reading it and understanding it. Remember that my code and this accompanying article are pedantic in nature. We’re talking about app groups, not about using MVC, robust error handling, testing, etc.

Let talk about the numbering of my comments, mainly the fact that I’ve shown them out of sequence, starting at “3a)” and not with “1)”. Let me explain: I’m introducing the code in the order I feel best for my tutorial’s flow, especially regarding what code I want to explain first, what to explain second, all the way to what to explain last.

So initially, please read the code, ignoring the comment numbers until you’ve read the whole article. Once you’ve got your Team ID, your app group ID, and you’ve got both apps configured with the app group ID, you can build and run them.

Then read the code with comments in numeric sequence starting with “1)” all the way through “4g)”. You’ll see that the sequencing of the comment numbers makes sense in terms of the overall flow of the way my two apps work together.

“FirstApp” – Creating an app that is part of an app group

Let’s walk through building my app group’s first app, ingeniously named “FirstApp.” It reads from and writes to the shared container. My FirstApp writes a color to the shared container’s preferences so that my “SecondApp” can read that preference, and thus we have interprocess communication.

Open up Xcode (I’m using 13.2.1) and create a new application based on the macOS App template.

Follow these steps in TARGETS -> Signing & Capabilities:

1. Tick the Automatically manage signing checkbox and then set the Team and Bundle Identifier appropriately;
2. Make sure to that you have the App Sandbox and Hardened Runtime capabilities;
3. Click the + button next to Capability and add the App Groups capability by dragging it in from the Library, like this:

4. Add your app group ID to the App Groups slot. Where it says Add containers here, press the + button and add your app group ID:

Remember that your app group ID should look like this:

group.YOUR_TEAM_ID.com.domain.MyAppSuite

Your app group ID is actually an array element in the .entitlements file.

Note that I specifically sandboxed this app to show you that an app group app can read the shared container, which is outside of this app’s sandbox.

Everything you need to see is in the ViewController.swift file. Let’s briefly walk through the most important code in FirstApp — a few selected snippets.

Let’s examine how I write user-selected color values from my app’s NSComboBox to the app group’s shared preferences. The interprocess communication comes into play when my SecondApp, described below, reads that color preference. Notice that I’m getting a special type of reference to UserDefaults by calling its init(suiteName:) initializer, where the full definition is init?(suiteName suitename: String?), and note the optional return value. I pass my app group ID to the argument labelled suiteName. I access the user preferences associated with my app group by initializing UserDefaults specific to my app group’s ID, stored in the shared container. Then I can set a key/value specific to that app group:

...
/** 3a) Write user preference to shared container. */
func setPreferenceValue(_ value: Any?, forKey key: String, in appGroup: String) {

    // 3b) If we can access preferences to our app group...
    if let groupUserDefaults = UserDefaults(suiteName: appGroup) {

        // 3c) Write the value for the given key
        // to our shared container.
        groupUserDefaults.set(value, forKey: key)
        print("Wrote to shared user defaults.")

    }

} // end func setPreferenceValue
...

If you’re going to do something with your app group like store common files or maintain a shared cache, you’ll need to be able to get a valid macOS file system path to read from, and possibly write to, files/folders in the shared container. To get a URL to the root folder of your shared container, you use the containerURL(forSecurityApplicationGroupIdentifier:) instance method of FileManager, passing it your app group ID. Notice that instead of testing to see if a file exists first before reading from it, I proactively read from it using NSData and then check for a return value:

...
/** 4a) If you're going to manage and access common resources
 or assets in the shared container, remember that "It’s far better to
 attempt an operation (such as loading a file or creating a directory),
 check for errors, and handle those errors gracefully than it is to try
 to figure out ahead of time whether the operation will succeed."

 - returns: True if plist exists; false if it doesn't exist
*/
func sharedPreferencesPlistExists() -> Bool {

    var containerExists = false

    let sharedFileManager = FileManager.default

    /* 4b) "In macOS, a URL of the expected form is always returned, even if the app group is invalid, so be sure to test that you can access the underlying directory before attempting to use it." */
    let sharedContainerFolderURL = sharedFileManager.containerURL(forSecurityApplicationGroupIdentifier: appGroupID)
    // 4c) Now we build a standard path ("Library/Preferences/")
    // to the preferences data store file (plist). Note
    // the format of the plist's name.
    let sharedContainerPrefsPlistURL = (sharedContainerFolderURL?.appendingPathComponent("Library/Preferences/group.YOUR_TEAM_ID.com.domain.MyAppSuite.plist"))!
    // 4d) Try to read data from the preferences
    // plist file.
    let sharedContainerPrefsPlistData = NSData(contentsOf: sharedContainerPrefsPlistURL)
    // 4e) If the file exists...
    if let fileData = sharedContainerPrefsPlistData {

        // 4f) if the plist file has contents (bytes)...
        if fileData.length > 0 {

            // 4g) We know that the plist is valid.
            print(".plist file size: \(fileData.length)")
            containerExists = true

        }

    }

    return containerExists

} // func sharedContainerExists()
...

Upon clicking the “Check for .plist” button in FirstApp, the console shows:

.plist file size: 90
Shared plist created.

“SecondApp” – Creating another app so we have an app group

To restate what I would hope is now the obvious, “an app group is a collection of two or more apps.” SecondApp is, well, the other app that makes up my little app group. SecondApp reads a preference from the shared container. That preference for color is written by FirstApp. SecondApp sets its view controller’s NSView background color to the shared container’s preference and thus we have interprocess communication.

Open up Xcode (I’m using 13.2.1) and create a new application based on the macOS App template.

Follow these steps in TARGETS -> Signing & Capabilities:

1. Tick the Automatically manage signing checkbox and then set the Team and Bundle Identifier appropriately;
2. In this case, make sure to remove the App Sandbox capability;
3. Make sure the app has the Hardened Runtime capability;
4. Click the + button next to Capability and add the App Groups capability by dragging it in from the Library, like this:

5. Add your app group ID to the App Groups slot. Where it says Add containers here, press the + button and add your app group ID:

Remember that your app group ID should look like this:

group.YOUR_TEAM_ID.com.domain.MyAppSuite

The app group ID is actually an array element in the .entitlements file.

Everything you need to see is in the ViewController.swift file. Let’s briefly walk through the most important code in SecondApp — just one selected snippet. Again, I’m getting a special type of reference to UserDefaults by calling its init(suiteName:) initializer with my app group’s ID as an argument. This is how I read the user preference for the color that was set in FirstApp. I then change my main window’s view background color to the preferred color. Here’s the code:

...
func setViewBackgroundColor() {

    // 1) Get a reference to the shared user defaults for the
    // app group we created.
    if let groupUserDefaults = UserDefaults(suiteName: appGroupID) {

        // 2) Read the value for the "BackgroundColor" key stored
        // in our app group shared container's preferences
        // (user defaults).
        if let backgroundColor = (groupUserDefaults.object(forKey: "BackgroundColor")) as? String {

            // 3) Set the background color of our NSView to
            // the value we read from the our shared container's
            // preferences.
            self.view.wantsLayer = true

            self.view.needsDisplay = true

            if backgroundColor == "Red" {
                self.view.layer?.backgroundColor = NSColor.red.cgColor
            }
            else if backgroundColor == "Green" {
                self.view.layer?.backgroundColor = NSColor.green.cgColor
            }
            else if backgroundColor == "Blue" {
                self.view.layer?.backgroundColor = NSColor.blue.cgColor
            }
            else {
                self.view.layer?.backgroundColor = NSColor.gray.cgColor
            }

            print("Read background color, \(backgroundColor), from shared user defaults.")

        } // end if let backgroundColor =...

    } // end if let groupUserDefaults =...

} // end func setViewBackgroundColor()
...

Note that I specifically didn’t sandbox this app to show you that macOS apps don’t necessarily need to be sandboxed (especially those distributed via 3rd party signing) and that non-sandboxed apps can access their app group’s shared container.

Installing and distributing your macOS apps

Remember that if you want to install and/or distribute macOS apps like the ones I discussed here, you have two choices. You can go the 3rd party route and sign and notarize your apps outside of the Mac App Store or you can submit your apps for review by staying within the Mac App Store. macOS apps are more flexible in terms of distribution than iOS apps. I’ll be publishing a book on Amazon Kindle on how to distribute macOS apps outside of the Mac App Store. I’ll also be offering iOS courses on Udemy. Come back to look for it soon!

Conclusion

I hope you see the benefits that can be gained by use of app groups, whether it be in iOS or macOS. You can control and update your apps more easily by centralizing shared resources. You can eliminate redundancies. And you can get really advanced by using technologies like shared memory (as long as you remember to keep things thread safe). I could go on and on about the benefits of app groups, but I hope you’ll see that, for a relatively small price, you can get a high return on investment.

Since widgets display content with SwiftUI views, they are generally easy to create and portable across Apple’s devices, like iPhones and Macs. Each of your apps can provide multiple widgets, multiple instances of the same or different widgets, and three different sizes of the same widgets.

Let’s talk about at an example of design considerations for building a widget, from my sample project. You should click that link and download my project to follow along with this article. I used Xcode 13.1 to write this sample app and iOS 15.0 on the Simulator and on an iPhone 12 to test.

My “Events” app has a widget that shows the important events that occur during a workday along with the times at which they occur. Look at the following two images. The first highlights my widget showing the events of the day in fast motion, because we wouldn’t want to wait to watch the widget over a 15-hour period. The widget simply shows the nearest-occurring event and its time; information that can be seen at a glance. The second image shows what happens when you tap on the widget: the app opens showing all the events of the day including the one that was being shown in the widget at the time of the tap. Remember that this app is a proof of concept highlighting WidgetKit and SwiftUI, and is not fully-functional.

It should be apparent to you by now that, because of a widget’s limited amount of space, it should only display information that users see as most valuable in your app. Don’t clutter things up. Design for simplicity, ease of use, and elegance.

Because widgets are portable between iOS and macOS, are pretty small, and should convey concise, glanceable information, SwiftUI is the perfect tool to use for building their user interfaces. Indeed, WidgetKit requires that you use SwiftUI views to design and render widgets’ content.

A word about my sample app

The sample app that we’ll walk through in this article is very simple and not fully functional on purpose. I want you to get a basic understanding of SwiftUI and WidgetKit without getting bogged down in a bunch of implementation details about how a daily to-do list app would be written. My app implements just enough of a to-do list to introduce you to SwiftUI and WidgetKit; the rest is a facade.

So, if fully functional, my app would allow a user to define 5 to 6 essential life events in a day, assign times to those events, and, at any time, glance at the widget to see the nearest approaching event, based on some type of timing algorithm. If the app was completed, tapping on the widget would take a user to a detail screen for the nearest event where one could, say, make some notes, set a reminder or alarm, add contacts, add directions, then go back to the main summary screen showing a list of all the day’s events and times, and edit another event. Since my app is still a prototype, when the user taps on the widget (or opens the app itself), he or she is sent directly to a screen to see a read-only list of events and times.

Creating the base app

Let’s walk through the steps I went through to develop my sample “Events” app. I made it a SwiftUI-based app. Open Xcode 13.x and go to:

– New > Project…
– On the Choose a template for your new project: screen, select iOS and App, then click _Next

– On the Choose options for your new project: screen, fill in Product Name: with “Events,” select your own Team:, set your own Organization Identifier:, set the Interface: to “SwiftUI,” set the “Language:” to “Swift,” then click Next

– Select the new project location and click Create

The new app will have two code files, “EventsApp.swift” and “ContentView.swift.” We’ll leave “EventsApp.swift” alone. It’s custom App protocol conformer, EventsApp, provides the entry point into the app and will render the simple user interface defined in “ContentView.swift.” From herein to the end of this article, I’ll show you a piece of code and then explain it immediately afterwards.

Take a look at “ContentView.swift.” I wrote a simple declarative SwiftUI user interface (UI) using the struct named ContentView. The app’s entire UI is in the body member of the ContentView:

...
import SwiftUI

let events = ["Wake up", "Breakfast", "Go to work", "Lunch", "Come home", "Go to sleep"]
let eventTimes = ["7:00 AM", "8:00 AM", "8:30 AM", "12:00 PM", "5:00 PM", "11:00 PM"]

struct ContentView: View {

    var body: some View {

        // Screen title
        Text("Daily Events").bold().italic().padding()

        // List of daily events with times
        Form {
            ForEach(0..<events.count) { event in
                Text("- \(events[event]) [ \(eventTimes[event]) ]")
            }
        }.padding().border(Color.blue)

    } // end body

} // end ContentView
...

First, I used a Text view to give my list of events a title, using some view modifiers to highlight that title (.bold().italic().padding()). Then I used a Form view as the main container for the app’s list of events because, in real life, I’d allow editing of my events here. Right now, the app only displays the events and their times read-only, but always think ahead. The ForEach writes out the events and their respective times as Text views, one per line, for all to-do list items that I’ve stored in arrays. The Form has a colored border and some padding around it. There’s a reason I used 2 arrays and it has to do with widgets auto-updating, but that’s beyond the scope of this article.

Running the “Events” app now shows this screen:

For those of you following along, test your “Events” app and make sure it looks like the previous picture.

Adding the WidgetKit extension

Widget functionality can be added to the SwiftUI “Events” app I started up above. All’s I have to do is to add a new target — a WidgetKit extension — to my existing app. Head back to Xcode 13.x and go to:

– File > New > Target…
– On the Choose a template for your new target: screen, select iOS and Widget Extension, then click Next

– On the Choose options for your new target: screen, fill in Product Name: with “EventTimes,” select your own Team:, set your own Organization Identifier: (same as “Events” app), do not set the Include Configuration Intent, make sure that “Project:” and “Embed in Application:” are both set to “Events,” and then click Finish

– You’ll be prompted to activate your new “EventTimesExtension” scheme; make sure you press the “Activate” button now:

A few items have been added to your “Events” app project, most notably, the “EventTimes.swift” WidgetKit code and the WidgetKit.framework. We’ll spend most of the rest of the article discussing “EventTimes.swift.”

Data sharing between the app and widget?

Notice that I’ve defined the same data model (2 arrays) at the top of the extension’s “EventTimes.swift” that I already defined in the containing app’s “ContentView.swift”:

...
let events = ["Wake up", "Breakfast", "Go to work", "Lunch", "Come home", "Go to sleep"]
let eventTimes = ["7:00 AM", "8:00 AM", "8:30 AM", "12:00 PM", "5:00 PM", "11:00 PM"]
...

Remember that “Even though an app extension bundle is nested within its containing app’s bundle, the running app extension and containing app have no direct access to each other’s containers.” In other words, the 2 arrays defined in just the containing app are not accessible to the extension and vice versa. One solution would be to define an app group to which both the “Events” app and “EventTimesExtension” extension belong. The app group would let the extension and containing app intercommunicate. They could then share the same data model. But that is way beyond the scope of this article — and I already wrote a tutorial on app groups which I urge you to read: “Using App Groups for communication between macOS/iOS apps from the Same Vendor”.

How WidgetKit works

Widgets are driven by, like many other aspects of our reality, time. With my “Events” app and widget, we have a relatively fixed list of events that occur throughout the day. What drives the updating of the widget to show the next nearest coming-up event is that event’s time. Think of the iPhone weather widget. It also is driven by time, probably polling a server every 30 seconds so it can update the current conditions, the current temperature, and the day’s current high and low.

Let’s go through the code in the WidgetKit extension’s “EventTimes.swift” file from top to bottom, even though that might not may be the most logical order. But if I jump around, you’re likely to get confused — plus I urge you to compare my version of the file to the template version as first generated when you created the WidgetKit extension.

Let’s start at the top of the file:

...
import WidgetKit
import SwiftUI

let events = ["Wake up", "Breakfast", "Go to work", "Lunch", "Come home", "Go to sleep"]
let eventTimes = ["7:00 AM", "8:00 AM", "8:30 AM", "12:00 PM", "5:00 PM", "11:00 PM"]
var currentEvent = 0

struct Provider: TimelineProvider {
    func placeholder(in context: Context) -> SimpleEntry {
        SimpleEntry(date: Date(), eventName: "Daily event", eventTime: "N/A")
    }
...

From the first struct we encounter, of type TimelineProvider, you can see why I said that widgets are driven by time. The placeholder function “displays a generic representation of your widget, giving the user a general idea of what the widget shows”. It is called if your widget is displayed but no real data is ready to be displayed, perhaps because the containing app hasn’t been configured or established network connections yet. SimpleEntry is the struct that holds instances of data that are shown one at a time in your widget. To be specific, this SimpleEntry reference is the struct constructor that returns an instance.

...
    func getSnapshot(in context: Context, completion: @escaping (SimpleEntry) -> ()) {
        let entry = SimpleEntry(date: Date(), eventName: events[currentEvent], eventTime: eventTimes[currentEvent])
        completion(entry)
    }
...

The getSnapshot function provides an app timeline entry for the current time (and perhaps state) of the widget. For my “Events” app, this would be the nearest event in time in your daily schedule about to occur.

...
    func getTimeline(in context: Context, completion: @escaping (Timeline) -> ()) {
        var entries: [SimpleEntry] = []

        // Generate a timeline consisting of six entries an second apart, starting from the current time.
        let currentDate = Date()

        for timeOffset in 0 ..< events.count {
            let entryDate = Calendar.current.date(byAdding: .second, value: timeOffset, to: currentDate)!
            let entry = SimpleEntry(date: entryDate, eventName: events[timeOffset], eventTime: eventTimes[timeOffset])
            entries.append(entry)
        }
        currentEvent = 0

        let timeline = Timeline(entries: entries, policy: .atEnd)
        completion(timeline)
    } // end getTimeline
...

For a static prototype like my sample “Events” app, the getTimeline function can build the entire timeline to be displayed in my widget. Because of the policy: .atEnd, the timeline is created over and over, so I create an event (entry) every second so you can see my to-do list in fast motion. I already explained why a **real** version of my “Events” app would need a more sophisticated algorithm to calculate a timeline of the “next, nearest” event relative to the current point in time. If you were building a weather app, some type of polling algorithm could be used to make network requests to get the current conditions for the current times throughout the day. At least you could pull the current weather conditions whenever the user looks at the app and then start polling.

...
    struct SimpleEntry: TimelineEntry {
        let date: Date
        let eventName: String
        let eventTime: String
    }
...

As I mentioned above, the SimpleEntry is the struct that holds instances of data that are shown one at a time in your widget. Note that the date is essential to a timeline.

...
struct EventTimesEntryView : View {
    var entry: Provider.Entry

    var body: some View {
        VStack {
            Text(entry.eventTime)
            Text(entry.eventName)
        }
    }
} // end EventTimesEntryView
...

This is the SwiftUI I used to display the widget. Do I even need to explain what I’m drawing here? Just look at my widget. I show the event’s time on the top line and the event’s name right below. It just amazes me how I can write such short, simple, and elegant code to get a UI. The declarative UI is here!

...
@main
struct EventTimes: Widget {
    let kind: String = "EventTimes"

    var body: some WidgetConfiguration {
        StaticConfiguration(kind: kind, provider: Provider()) { entry in
            EventTimesEntryView(entry: entry)
        }
        .configurationDisplayName("My Daily Events")
        .description("Shows my typical workday schedule.")
    }
} // end EventTimes
...

The @main attribute specifies the single entry point to my Widget extension. My widget is given a string tag for system identification purposes. I’m specifying the SwiftUI that my widget uses and I provide template text that people will see when they look up my widget so they can add it to my iPhone Home or Today View screens, as described in the next section.

Adding widgets after the app is installed

Once you install my sample app on an iPhone, you want to install one or more instances of its widget in one or more of the three available sizes. This ani-GIF shows you how to install a widget on the Home screen:

Note that I started the process by long-pressing on empty Home screen space. You can follow the same process on the Today View or, instead of starting by long-pressing, you can scroll down to the bottom of the page and tap the “Edit” button.

Static versus user-configurable widgets

Mainly because my “Events” app and widget are proofs of concept, they are static. While I’ve mentioned possibilities for editing the events and times, those values are currently fixed. But you can make your widget user-configurable. When the good folks who were writing the iPhone weather app added their widget extension, they ticked the Include Configuration Intent checkbox — that’s the checkbox we didn’t tick.

To make a long story short, you can configure the weather widget by long-tapping it until the context menu appears and selecting the “Edit Widget” item. The widget “flips over” to present an interface that allows you select from a list of nationwide locations that the widget will then show weather snapshots for.

Conclusion

Adding a widget to your app can add a whole lot of value to your app. You can make it so much more useful by allowing one glance to give users the gist of the main purpose of your app. Think of ways to make your apps **indispensable** to users — an essential part of their lives. Widgets are one of the best ways I’ve seen in recent years to accomplish this lofty goal.

The goal: readable asynchronous/parallel code

In designing the async/await construct, Apple is hoping to increase the readability, and thus maintainability, of implementing concurrency/parallelism in Swift. What I see in it are attempts:

• to make asynchronous/parallel code almost look like synchronous/sequential code; and,
• to make asynchronous/parallel code much more semantically clear (more readable, less verbose, compact, doing what it says).

These are laudable and ambitious goals, but I’d say Apple’s heading in the right direction. I’m glad because I write a lot of asynchronous code to keep my apps responsive — to create the best possible user experience for my customers. I have a feeling that most of you write a lot of concurrent code, too.

We’ll walk through how to use async/await in detail, but I will limit my discussion to it. You need to understand async/await before trying to use Swift’s other new concurrency features, like actors, continuations, the AsyncSequence protocol, the TaskGroup generic structure, task cancellation, and a few other concepts.

The Swift team has added hundreds of async (or “awaitable”) methods to the language, but I’d like you to focus on the pattern I use to implement most any call involving async/await, not on specific functions. To take an even broader view, I’ll compare using Swift’s async/await to using Swift’s Grand Central Dispatch (GCD) implementation. Both technologies offer “generic” support for parallelism. In other words, they both can support asynchronous/parallel code in a wide variety of applications, from long-running multi-step mathematical computations to large file downloads that all need to be run in the background. We’ll go over a common async/await beginner’s pitfall and finally end with some advice about where to go next with Swift concurrency.

Please note that async/await is not unique to Swift. Javascript, C++, Python, and C# are some examples of languages which support this construct. Also note that while async/await is nice to have, I wouldn’t want to give up access to GCD. It’s too powerful, despite its use of closures.

Please download my sample Xcode 13 beta project, written in Swift 5.5, essential for getting the most out of this tutorial. The Base SDK is iOS 15 beta and I used an iPhone 12 Pro Max for the base UI layout in my storyboard.

The heart of the problem

When faced with writing concurrent/asynchronous code, Swift developers are used to submitting a specific task, like downloading a big file, and then waiting for the download to finish in a completion handler or delegate callback. If you review an example of using Apple’s downloadTask(with:completionHandler:) SDK call that I used in another article right here on iosbrain.com, you’ll see that the code is a bit awkward, verbose, complex, hard to read, and spread out. Look at where I have to call task.resume() to start the download. Note that I defined the ImageDownloadCompletionClosure elsewhere in the code. It’s not super intuitive.

...
func download(completionHanlder: @escaping ImageDownloadCompletionClosure)
{

    let sessionConfig = URLSessionConfiguration.default
    let session = URLSession(configuration: sessionConfig)
    let request = URLRequest(url:imageURL)

    let task = session.downloadTask(with: request) { (tempLocalUrl, response, error) in

        if let tempLocalUrl = tempLocalUrl, error == nil {
            if let statusCode = (response as? HTTPURLResponse)?.statusCode {
                let rawImageData = NSData(contentsOf: tempLocalUrl)
                completionHanlder(rawImageData!)
                print("Successfully downloaded. Status code: \(statusCode)")
            }
        } else {
            print("Error took place while downloading a file. Error description: \(String(describing: error?.localizedDescription))")
        }
    } // end let task

    task.resume()

} // end func download
...

Apple, language architects, and many developers feel that the block–completion handler model is hard to read, especially when you’re nesting calls of this type. As Apple puts it:

…Even in [the] simple[st] case, because the code has to be written as a series of completion handlers, you end up writing nested closures. In this style, more complex code with deep nesting can quickly become unwieldy.

So, to nested completion handlers, add error checking, like guard, if let, do, try, catch, defer, throw, Error — even NSError, which also can be nastily nested, you truly get yourself into a major pyramid of doom. Note that my sample project has very little in the way of error checking, not to be sloppy, but so you can concentrate on the subject of this article without distraction.

Enter the Swift 5.5 async/await keywords, which by no means constitute all the new Swift concurrency features. I believe you should first learn about async/await before exploring the rest of Swift’s new concurrency model.

Good old GCD

Let’s start out talking about a tool that many of us have used in the past to perform long-running operations in the background, thus freeing our apps to do other things, and allowing the user interface (UI) to remain responsive. One common scenario is downloading a background image for an app’s login screen while not preventing user interaction (like typing their username and password). Most of you should know about GCD, but if you don’t, I’ve written an extremely in-depth article on using it with Swift. In fact, the sample code I discussed in that article is used right here.

Let’s first read through my downloadImageGCD method, part of this article’s companion project. We’ll talk about that function in just a minute:

...
// example of GCD asynchronous code; as
// soon as an image download is queued, control
// flows immediately onwards
func downloadImageGCD(for url: String, with index:Int) -> Void {

    DispatchQueue.global(qos: DispatchQoS.QoSClass.default).async {

        _ = self.isCodeOnMainThread(named: "start GCD image \(index) downloading...")
        let imageURL = URL(string: url)
        // this call blocks until the image data is downloaded,
        // BUT we're running in the background
        let imageData = NSData(contentsOf: imageURL!)
        // convert the data into an image
        let image = UIImage(data: imageData! as Data)

        DispatchQueue.main.async {
            self.imageViewStellar.image = image
            self.imageViewStellar.setNeedsDisplay()
            print("GCD image \(index) downloaded/displayed")
        }

    } // end DispatchQueue.global(qos: ...

} // end func downloadImageGCD
...

By wrapping my GCD code in a for loop, the downloading of 22 big image files are queued up, but the downloads occur in the background, so the UI remains responsive, and I can click any of my sample app’s buttons at any time and they do some concurrent work. The following for loop is called when you click the “Start GCD Downloading” button on the app’s main screen:

...
func startGCDAsyncImageDownload()
{
    for index in 0..<imageURLs.count
    {
        downloadImageGCD(for: imageURLs[index], with: index)
    }
} // end func startAsyncImageDownload()
...

Watch the video of my app working and check out my print statements to the console. Notice there’s a bit of stuttering when I click the “Increment” button, but that’s mainly due to updating the UIImageView on the main thread:

My downloadImageGCD function is intrinsically asynchronous. Given a URL, you schedule a task to download the data at that URL on a background thread. Then you specify a completion handler to display the downloaded data in a UIImageView and move on. Code flow whips right through this function. By the time the images start displaying in the UI, you can be off somewhere else in the app’s code. REMEMBER: As shown above, always update your UI on the main thread. See my updateImageView(with:) used throughout the sample project.

Since I’m running my code on a multi-core processor, calling downloadImageGCD demonstrates true parallelism. Concurrency/asynchrony involves a stochastic (random) element. Look at my console output to see the random queuing and completion of tasks — and go to Xcode’s Debug navigator -> CPU to see worker threads being created and eventually cleaned up:

start GCD image 0 downloading... ON BACKGROUND THREAD
start GCD image 1 downloading... ON BACKGROUND THREAD
start GCD image 2 downloading... ON BACKGROUND THREAD
start GCD image 4 downloading... ON BACKGROUND THREAD
start GCD image 3 downloading... ON BACKGROUND THREAD
start GCD image 5 downloading... ON BACKGROUND THREAD
...
GCD image 9 downloaded/displayed
GCD image 21 downloaded/displayed
GCD image 7 downloaded/displayed
GCD image 18 downloaded/displayed
GCD image 12 downloaded/displayed
GCD image 5 downloaded/displayed

I purposely used the init(contentsOf:) initializer of NSData to download image data because it is a synchronous, blocking call, a concept central to this article. Yes, it blocks until all data at the specified URL downloads, but I’m using that NSData initializer on a background thread. If you called that function on your main thread, your app would freeze until all URL data downloads. Remember that I submitted the synchronous download inside a block passed to the very asynchronous DispatchQueue...async {...}. Later, we’ll see that “blocking” or “suspending” have a different meaning in async/await.

The SDKs available to Swift have been populated with many, many calls that include completion handlers or delegate callbacks, not just DisptachQueue. I have a lot of good asynchronous code that’s already been written using the block–completion handler pattern. I’m certainly not going to go back and rewrite it all using the new Swift concurrency gimmicks. But looking forward, I will consider using constructs like async/await.

The Swift 5.5 async/await construct

Let’s define some terminology essential to understanding Swift’s new concurrency model.

async:

• add this keyword to a function signature (declaration) to denote that that method is asynchronous, i.e., can potentially run code in parallel with other code, and can be subject to suspension and later resumption
• suspension may occur, for example, to await the results of some long-running task
• suspension may occur, for example, for short-term tasks like updating the UI
• suspension may not occur at all
• functions marked async must themselves call await to be suspended (see below)
• when an async function suspends, it does not block its thread
• when an async function suspends, the operating system can queue and execute other processes on it’s thread

await:

• obviously marks a potential suspension point in your code, making that suspension point clear to people reading the code
• the code on the rest of the line following the await can be scheduled by the system for running a long task
• that long task can be suspended once or many times so the system can execute other work
• a shorter task might not be suspended at all and it can run to completion
• once its task finishes, the await line finishes, and execution continues on the next line
• when Swift suspends the current thread, other code is allowed to execute on that same thread

async-let:

• lets you call asynchronous functions when you don’t need the return value immediately
• you can start one or many tasks that can be run in parallel
• other code can run while your asynchronous functions process

async {...}:

• enables you to kick off asynchronous work from within regular, synchronous code, like from within a function not labelled async
• you call your asynchronous code between the “{” and “}”

How to write code with async/await

Now that we’ve defined the terms async and await at a theoretical level, let’s learn how to write code using these constructs. As an alternative to my downloadImageGCD method, which uses GCD with a completion handler, let’s write an async function that you call with an image URL and it returns the image data, kind of like a synchronous function would do so. But it doesn’t block, it possibly suspends for a relatively brief period while the image downloads, probably on a background thread, but that is not guaranteed as I understand the new Swift construct (see my definitions above).

...
func downloadImageAsync(for url: String, with index:Int) async throws -> UIImage {

    _ = isCodeOnMainThread(named: "start awaitable image \(index) downloading...")
    let request = URLRequest(url: URL(string: url)!)
    let (data, response) = try await URLSession.shared.data(for: request)
    guard (response as? HTTPURLResponse)?.statusCode == 200 else { throw HTTPError.withIdentifier((response as! HTTPURLResponse).statusCode) }
    let downloadedImage = UIImage(data: data)
    return downloadedImage!

} // end func downloadImageAsync
...

Notice that we place the async keyword just after the method signature’s parameter list but before the throws and the return type. Pause for a moment to review my async keyword definition up above.

The key to this method is this line:

let (data, response) = try await URLSession.shared.data(for: request)

Since URLSession.shared.data is async (“awaitable”), we must call it with await; it also throws. If an async function throws, you always put a try before the await, as we did here when calling the function. The lines of code both before and after data(for:) on the shared URLSession are synchronous. The code after this network download call is dependent on the data and response it returns, so it must suspend while the image data at url downloads. Here’s the magic: while this line (and its containing method) suspend, other work in the app can be done.

A great benefit of writing code with async/await is the enhanced readability. You can obviously see asynchronous code and potential suspension points. There’s also less clutter without the closure syntax.

Our first try at async/await

To prove to you that async/await works efficiently and allows other app work to be done simultaneously, let’s do an experiment with my code. I’ve got some code commented out, but don’t make any changes yet. Let’s review what you’ll do first. Here’s the code that my app’s “Start Proper Awaitable Downloading” button calls:

...
@IBAction func startProperAwaitableDownloadingButtonClicked(_ sender: Any) {

    counter = 0;
    counterTextField.text = "0"
    imageViewStellar.image = nil

    async {

        let image = try! await downloadImageAsync(for: imageAltURLs[0], with: 0)
        updateImageView(with: image)
        print("GIANT FILE FINALLY DOWNLOADED")
        //await startRightNewSimpleSyncImageDownload()
        //await startRightNewSimpleAsyncImageDownload()
        //await startExperimentAsyncImageDownload()
        //await startTaskGroupAsyncImageDownload()
    }

} // end startProperAwaitableDownloadingButtonClicked
...

While this @IBAction func is synchronous, note that you can call async code by wrapping it in the async{...} construct as defined above. The image at the URL in imageAltURLs[0] is gigantic and takes awhile to download. You already saw earlier that my downloadImageGCD function downloads and displays 22 large image files. Ready? Run my app and press the “Start Proper Awaitable Downloading” button, then quickly press the “Start GCD Downloading” button.

Your console output should be similar to that shown next, though not exactly the same. You’ll see the async call to download the huge file start up and suspend. Then you’ll see the GCD function simultaneously queuing and downloading 22 images. Most of the time, the async file will download later to last when considering all total 23 downloads, not because there’s anything wrong with async, but because it’s downloading a very large file.

start awaitable image 0 downloading... ON MAIN THREAD
start GCD image 0 downloading... ON BACKGROUND THREAD
start GCD image 1 downloading... ON BACKGROUND THREAD
start GCD image 2 downloading... ON BACKGROUND THREAD
start GCD image 3 downloading... ON BACKGROUND THREAD
...
start GCD image 19 downloading... ON BACKGROUND THREAD
start GCD image 21 downloading... ON BACKGROUND THREAD
start GCD image 20 downloading... ON BACKGROUND THREAD
GCD image 0 downloaded/displayed
GCD image 4 downloaded/displayed
GCD image 2 downloaded/displayed
...
GCD image 20 downloaded/displayed
GCD image 21 downloaded/displayed
GCD image 16 downloaded/displayed
GIANT FILE FINALLY DOWNLOADED

How NOT to use async/await

Unless you’re enforcing some specific order of execution because of certain interdependencies, I would advise you to avoid using a bunch of await calls in sequence. Let’s look at two examples from my project. Here’s a “manual” example:

...
// these downloads occur SEQUENTIALLY because we
// start each download with the "await" keyword
func startRightNewSimpleSyncImageDownload() async -> Void {

    let stellarImage0 = try! await downloadImageAsync(for: imageURLs[0], with: 0)
    let stellarImage1 = try! await downloadImageAsync(for: imageURLs[1], with: 1)
    let stellarImage2 = try! await downloadImageAsync(for: imageURLs[2], with: 2)

    _ = isCodeOnMainThread(named: "startRightNewAsyncImageDownload")

    // no await is needed
    updateImageView(with: stellarImage0)
    print("stellarImage0 with index 0 downloaded")
    updateImageView(with: stellarImage1)
    print("stellarImage1 with index 1 downloaded")
    updateImageView(with: stellarImage2)
    print("stellarImage2 with index 2 downloaded")

} // end func startRightNewSimpleSyncImageDownload
...

Here’s a “automated” example (I used a for loop):

...
// this method is a misguided attempt to
// call a bunch of blocking calls all at once
func startWrongNewAsyncImageDownload()
{

    async {

        for index in 0..<imageURLs.count {
            let url = imageURLs[index]
            let downloadedImage = try! await self.downloadImageAsync(for: url, with: index)
            imageViewStellar.image = downloadedImage
            print("awaitable image \(index) downloaded/displayed")
        }

    } // end async

} // end func startWrongNewAsyncImageDownload()
...

Why would I impose such a sequential ordering, especially if I were preparing an image gallery and/or the thumbnails for a UICollectionView? Even with concurrency involved, think of what would happen if each of the image downloads was in the order of 170 MB, as opposed to the ~30 MB files I’m downloading from my URL array’s addresses. Or suppose I had a long list of mathematically intense calculations? I’d have a lot of uninterruptible tasks that would make my app run sluggishly at best. Even if I were required to enforce a sequence of tasks, each dependent on the previous one, this wouldn’t be the most optimal way to encode my work. See the console output:

start awaitable image 0 downloading... ON MAIN THREAD
awaitable image 0 downloaded/displayed
start awaitable image 1 downloading... ON MAIN THREAD
awaitable image 1 downloaded/displayed
start awaitable image 2 downloading... ON MAIN THREAD
awaitable image 2 downloaded/displayed
start awaitable image 3 downloading... ON MAIN THREAD
awaitable image 3 downloaded/displayed
start awaitable image 4 downloading... ON MAIN THREAD
awaitable image 4 downloaded/displayed
start awaitable image 5 downloading... ON MAIN THREAD
awaitable image 5 downloaded/displayed
start awaitable image 6 downloading... ON MAIN THREAD
awaitable image 6 downloaded/displayed
start awaitable image 7 downloading... ON MAIN THREAD
awaitable image 7 downloaded/displayed
start awaitable image 8 downloading... ON MAIN THREAD
awaitable image 8 downloaded/displayed
start awaitable image 9 downloading... ON MAIN THREAD
awaitable image 9 downloaded/displayed
start awaitable image 10 downloading... ON MAIN THREAD
awaitable image 10 downloaded/displayed
start awaitable image 11 downloading... ON MAIN THREAD
awaitable image 11 downloaded/displayed
start awaitable image 12 downloading... ON MAIN THREAD
awaitable image 12 downloaded/displayed
start awaitable image 13 downloading... ON MAIN THREAD
awaitable image 13 downloaded/displayed
start awaitable image 14 downloading... ON MAIN THREAD
awaitable image 14 downloaded/displayed
start awaitable image 15 downloading... ON MAIN THREAD
awaitable image 15 downloaded/displayed
start awaitable image 16 downloading... ON MAIN THREAD
awaitable image 16 downloaded/displayed
start awaitable image 17 downloading... ON MAIN THREAD
awaitable image 17 downloaded/displayed
start awaitable image 18 downloading... ON MAIN THREAD
awaitable image 18 downloaded/displayed
start awaitable image 19 downloading... ON MAIN THREAD
awaitable image 19 downloaded/displayed
start awaitable image 20 downloading... ON MAIN THREAD
awaitable image 20 downloaded/displayed
start awaitable image 21 downloading... ON MAIN THREAD
awaitable image 21 downloaded/displayed

As we’ll see below, I can use async/await to download a whole bunch of images in parallel/simultaneously.

Running multiple parallel tasks with async/await

I always try to learn a new technology myself instead of waiting for someone else to figure it out and then doing copy and paste programming. I like to actually work through a practice test before looking at the answers in the back of the book. I want to figure out why I got some answers wrong.

Such was the case with figuring out how to run multiple parallel tasks with async/await. I was able to figure out how to manually use async-let. When I say “manually,” I mean I could start a fixed number of tasks, but couldn’t figure out how generalize my code for some varying number of tasks. I think the problem with async-let is that the construct has a let, implying a constant, not a variable.

Here’s my successful attempt at spawning 3 image downloads in parallel — and displaying the images from the downloaded data:

...
// each download occurs asynchronously -- even simultaneously
func startRightNewSimpleAsyncImageDownload() async -> Void {

    async let stellarImage0 = try! downloadImageAsync(for: imageURLs[0], with: 0)
    async let stellarImage1 = try! downloadImageAsync(for: imageURLs[1], with: 1)
    async let stellarImage2 = try! downloadImageAsync(for: imageURLs[2], with: 2)

    _ = isCodeOnMainThread(named: "startRightNewAsyncImageDownload")

    updateImageView(with: await stellarImage0)
    print("stellarImage0 with index 0 downloaded")
    updateImageView(with: await stellarImage1)
    print("stellarImage1 with index 1 downloaded")
    updateImageView(with: await stellarImage2)
    print("stellarImage2 with index 2 downloaded")

} // end func startRightNewSimpleAsyncImageDownload
...

OK, this works, but it is way too specific of a solution. What if I wanted to be able to download 2, 10, 30, or 60 images using some kind of repetitive language construct, like for or while? I tried to figure this repetitive thing out for awhile — without looking for somebody else’s solution. Look at my startExperimentAsyncImageDownload() function for evidence of my failed attempts.

Using a TaskGroup with async/await

In an effort to find a repetitive solution to downloading any number of images, I did some research. All’s I found was a brief section in some Swift documentation with a theoretical and not really usable solution. But I did get something working. Look at my sample code for a method named startTaskGroupAsyncImageDownload(), study it, run it, look at the console output, and watch my sample app’s screen while the function is working. Here’s the code:

...
// new Swift structured concurrency using
// tasks and task groups
func startTaskGroupAsyncImageDownload() async -> Void {

    _ = self.isCodeOnMainThread(named: "startRightNewAsyncImageDownload started")

    await withTaskGroup(of: UIImage.self) { taskGroup in

        for index in 0..<imageURLs.count {
            taskGroup.async {
                //_ = await self.isCodeOnMainThread(named: "task for image \(index) downloading started...")
                let downloadedImage = try! await self.downloadImageAsync(for: self.imageURLs[index], with: index)
                return downloadedImage
            }
        }

        // "To collect the results of tasks that
        // were added to the group, you can use
        // the following pattern:"
        for await image in taskGroup {
            _ = self.isCodeOnMainThread(named: "task awaited image downloaded")
            // notice I didn't have to jump
            // on the main queue to update the UI
            self.imageViewStellar.image = image
            print("task awaited image displayed")
            // DispatchQueue.main.async {
            //      self.imageViewStellar.image = downloadedImage
            // }
        }

    } // end withTaskGroup

} // end func startTaskGroupAsyncImageDownload()
...

Now this code acts truly concurrent. Hey, wait a minute. We’re using a closure. Hmmm…

I’m not going into a detailed explanation of this method as the main purpose of this article is introducing readers to async/await. But let me share one insight. See my comment above this line of code?

for await image in taskGroup {

This was key to figuring out how to make my experimental code work. I found this not on the Swift website, but in the Xcode context sensitive help when I clicked on the withTaskGroup keyword:

To collect the results of tasks that were added to the group, you can use the following pattern: …

Conclusion

Understanding Swift 5.5’s new concurrency features starts with async/await. I hope you learned a lot here today. I encourage you to practice using async/await with my sample code, study the links I’ve included in this article, and then to push forward through all the WWDC 2021 presentations on Swift’s other new concurrency features, like on actors, continuations, the AsyncSequence protocol, the TaskGroup generic structure, task cancellation, and a few other concepts. I especially recommend the WWDC 2021 sessions on “Explore structured concurrency in Swift”, “Protect mutable state with Swift actors”, and “Swift concurrency: Behind the scenes”.

One bit of homework: Look at my sample code’s isCodeOnMainThread(named:) function. Can you explain why the function prints “…ON MAIN THREAD” in some places while “…ON BACKGROUND THREAD” in others? I’m sure the Thread.isMainThread is working properly. I’ll respond to any comments left on my article regarding this question, or respond to any other comments you may have.

Enjoy!

Some people are yawning about WWDC 2021 because of its incremental — as opposed to quantum — leap forwards. If you look around the web for summaries of this year’s WWDC, you’ll find lots and lots of simple lists of new features, the implication being that this year is just about tossing customers a few new gadgets. In this article, I’m positing that Apple’s making a big jump in terms of its strategic long-term planning and direction.

WWDC 2021 is one of the most significant developer conferences in Apple’s history. The company refocused on the Mac and macOS. Apple is reinforcing its focus on iPad and iPadOS. The company is making the desktop and tablet platforms into the center of a business’s, family’s, or individual’s technology life blood: information and tools for accessing searching, organizing, analyzing and storing that information. Cook’s yearly sermon espoused three predominant themes:

1. having lots of high resolution screen space;
2. having the computing power to crunch large quantities of data in real time (CPU), and;
3. then taking that crunched CPU data, including changes made to it, and displaying it in real time on-screen (GPU).

By strategically focusing on the products and services that require enough room to spread your work out neatly, organized, and all at one time, Apple has recognized a much-overlooked reality: the mobile device has matured. Even though Apple is leading more than 200 detailed developer sessions to help coders create apps for the biggest app store in the world, at his initial keynote announcement, Tim Cook spent almost half of his time discussing his company’s great strides forwards on the three topics I listed above: raw computing horsepower, raw graphics horsepower, and enabling customers to work with their precious data on large crisp and clear screens driven by central and graphics processing units that show your data — especially changes made to that data — in real time. Apple didn’t just announce a new in-house CPU this year, they delivered it.

To emphasize the impact of the new M1 CPU, Cook noted that Xcode runs 85% faster than on Intel-based processors, while the GPU is 2 times faster, and machine learning is 3 times faster.

Yes, there are new versions of watchOS, iOS, and tvOS, and lots of new SDKs, respectively, but I still hold to this article’s core premise. I’m not diminishing Apple’s incremental changes to its various product lines; I’m trying to give you an idea of the strategic future direction of the company.

Over the next few days and weeks, please return to join me as I discuss WWDC 2021 development issues in detail. For now, I’ll show you how to prepare for learning about and implementing Apple’s cavalcade of new technologies. Take a look at the following list of links (below) that will enable you to download all the tools you need to try out the new technologies. I’ve also included links to resources that you can watch or read to help you with those tools. You can then start developing new apps using Apple’s developer sessions, new SDKs, and new tools.

NOTE: You need to be a member of the Apple Developer Program to access these resources (for an individual, like a single-member LLC, it’ll cost you $99/year). You’ll find all of this year’s beta downloads aggregated at this link (login required).

You should watch the 200+ detailed developer sessions in Apple’s new technologies to learn about implementing them. In the coming days and weeks, I’ll provide guidance into specific new/improved SDKs, which ones I feel are the most important, and provide tutorials to help you include new features in your apps.

New Developer Tools

• Xcode 13 Beta
  • Release notes
  • Download
• macOS Monterey 12 Beta
  • Release notes
  • Install profile
  • Installation tips
• iOS 15 Beta
  • Release notes
  • Install profile
  • Installation tips
• iPadOS 15 Beta
  • Release notes
  • Install profile
• watchOS 8 Beta
  • Release notes
  • Install profile
• tvOS 15 Beta
  • Release notes
  • Install profile
]]> https://iosbrain.com/blog/2020/02/09/using-the-plutil-utility-to-fix-improperly-formatted-xcode-plist-files/ Mon, 10 Feb 2020 05:13:41 +0000 https://iosbrain.com/?p=3209 Continue reading "Using the ‘plutil’ utility to fix improperly-formatted Xcode plist files"]]> How do you find typos (syntax errors) in an improperly formatted plist (property list) file, especially when Xcode provides absolutely no detail about badly formed XML? I often see plist files with a thousand or more lines of text! In this article, I’ll show you how to fix plist bugs — and do a few other things — by using the little-known plutil command line tool.

How many times have you seen the following error message, shown below in textual and graphical format, when doing a build?

: couldn't parse contents of '/path/to/project/projectName/projectName/Info.plist': The data couldn't be read because it isn't in the correct format.



Jump straight to the fix or take a minute to read a little background.

Background

When performing complex development with Xcode, it’s hard to avoid working with the plist file. When creating a new project, Xcode automatically creates one named “Info.plist” and makes it part of your physical folder structure and includes it very obviously in the Project Navigator. You can rename it to your own liking, and sometimes use multiple plist files, especially when you have multiple targets. While some people recommend only editing the contents of OS X or iOS project plist files using the Xcode user interface, I find that advice to be unrealistic.

One common scenario for custom usage of the plist file comes to mind:

• What if your app supports its own file format and your files have a unique extension?
• Say that your users want those files to automagically open in your app when they select one in the iOS Files app or macOS’s Finder?
• Say your users exchange your proprietary files using text messages or email.

When someone receives one of those files and wants to open it with your app, you’ll have to… Guess what? Add and configure the Document Types, Imported UTIs, and Exported UTIs sections of your app project’s plist file. Doing so is beyond the scope of this article, but I mention it to emphasize the importance of plist files. If you want to learn about associating files with your apps, I suggest you start by reading Apple’s “Technical Q&A QA1587 – Q: How do I get my application to show up in the “Open in…” menu on iOS for a specific document type?”

I was once working on an app that supported over 40 file type associations, all with different file extensions (i.e., filename.ext where ext is the extension). Once I created my first Document Types and Exported UTIs elements, I opened my plist in Source Code view and used copy and paste to configure the remaining 40+. To make sure my XML was formatted properly, I switched from Source Code view back to Property List view. Guess what happened when Xcode parsed my XML so it could show my plist as a Property List? Bang — useless error message. Watch:



All’s I get is a dialog box that says “The data couldn’t be read because it isn’t in the correct format.” I get the same message when building. So with Xcode, I have to go through possibly a thousand lines of code to find the error?

The fix: plutil

Before you start reading through a thousand lines of XML to find some minor syntax errors that are giving you major headaches, try the plutil command line utility, or as the OS X man page calls it, the “property list utility.” Open Terminal, change directory (cd) to the folder that contains the offending plist file, and enter the following command:

% plutil Info.plist

Of course, enter the name of your plist. You’ll get some very helpful output. It will help you fix your error(s). Here’s what plutil told me was the problem with my plist:

% plutil Info.plist
Info.plist: Encountered unexpected character / on line 37 while looking for open tag

Let’s look at line 37 of my plist and see exactly what’s wrong, in textual and graphical format:

...
	<true/>
	<key>NSSupportsSuddenTermination</key>
	<true/>
/dict>
</plist>



This could be an instance of where I copied and pasted, but missed a single character when copying, or I was typing XML and forgot the open bracket (“<") for a tag. Pretty simple, right?

Where to go next

I urge you to take a look at the documentation on plutil by bringing up its man page at Terminal's command prompt:

% man plist

There are quite a few interesting things you can do with plutil. You can print the contents of your plist in a very readable json format. I find this option very useful when troubleshooting. If you type plutil -help, you can get very detailed assistance in using this utility for converting your plist into binary, setting or replacing individual values, inserting new values, and printing individual elements. This is deep down in the weeds but, trust me, when troubleshooting some apps, like the one I discussed above with file associations, you’ll be glad you learned about plutil.

]]> https://iosbrain.com/blog/2019/03/28/were-still-here/ Fri, 29 Mar 2019 01:07:33 +0000 https://iosbrain.com/?p=3203 Continue reading "We’re still here…"]]> Some of you have been kind enough to ask why we haven’t been publishing for a few months. Thank you for your concern.

We’ve been busy, but be patient as you’ll soon be seeing us post articles again…

And we’ve got some big plans for the future, including books, online courses, and video tutorials, just to name a few.

Stay tuned. Thanks!

]]> https://iosbrain.com/blog/2018/11/24/using-xcode-instruments-time-profiler-template-to-optimize-swift-code/ Sat, 24 Nov 2018 14:46:38 +0000 https://iosbrain.com/?p=3179 Continue reading "Using Xcode 10 Instrument’s Time Profiler template to optimize Swift 4.2 code"]]> My original article — “How to Use Xcode Instrument to Optimize Your Swift Code” — was published on appcoda.com.

I still run across curmudgeons who flat out reject techniques like object-oriented programming (especially inheritance and polymorphism), protocols and protocol-oriented programming (especially composition), generics, and closures. On a conscious level, the curmudgeons usually reject these technique because of their supposed “massive” performance cost. On a subconscious level, the curmudgeons don’t understand these technologies. So do we give up all hope or do we accept the fact that compiler designers have come up with brilliant optimizations that ameliorate the use of such high-level technologies? We believe in Swift’s compiler designers. Do we realize that there are great tools like Xcode Instruments that help us find awkward implementations of these techniques and give us the opportunity to come up with our own optimizations? Yes.

There are costs to these high-level features, but I would argue that in most cases, language compiler optimizations, operating systems enhancements, and faster hardware (like solid state drives and multi-core processors), make up for the costs. Sure, once in a while you’ll have a use case where advanced code features don’t pay off, i.e., code is badly written or not used for the intended purpose.

Most of the time, these advanced features save software development boutiques enormous amounts of time and resources. Advanced language features usually let us do more by writing less and very expressive code. Time is saved because team members can easily read each other’s semantically clear code. Since the code is readable and logically organized, it can be extended, reused, debugged, and maintained easily.

But by goodness, nobody’s perfect, not even me ;-). Software keeps getting more and more complex. Users keep demanding more, better, and faster features. Problems will occur. Some apps are so slow that people just delete them.

Do we find out why our apps are so slow by using just print statements and breakpoints? I hope not, but I’ve seen more than a fair share of Stone Age “optimization” techniques. No. We turn to the darn good tools that already come bundled free with Xcode.

Using Instruments to identify performance problems

The Xcode Instruments’ Time Profiler template is the best template to start with when looking for app performance problems and/or determining how to improve performance. According to Apple, the Time Profiler template “Performs low-overhead time-based sampling of processes running on the system’s CPUs.”

We’re going to use the Time Profiler to analyze the performance of my sample app’s code. Please download it from GitHub. In simplest of terms, Time Profiler collects information about your app while it’s running, determines you how long each of your functions takes to run, and also figures out the percentage of CPU cycles each of your functions is using. It gathers the same data about iOS SDK functions. The percentage of CPU cycles from 0% to 100% at each sample point is shown over time on a graph called the “timeline” or “track.” There are multiple tracks. The top track aggregates all the data from all individual thread and CPU core tracks. The Time Profiler is a very powerful tool as it shows your app’s performance in real time, thus reflecting surges or lulls in CPU usage. We’ll walk through an example.

Your profiling environment

Before we begin, realize that, when profiling your code, especially when comparing two different approaches to the same problem, it’s imperative that you compare apples and apples, not apples and bananas. In other words, if you’re profiling an algorithm and trying to optimize it, you want to use the same device (or simulated device) with the same configuration.

When I compared the performance of functions showEmployee() and show() from my sample app in the demo below, I ran and profiled each method on the same iPhone 8, with the same configuration. When preparing my iPhone 8 for profiling, I first shut down all running apps. Since the code I was studying didn’t involve any type of connectivity, I shut down WiFi, Bluetooth, and cellular. Of course, if you’re profiling networking code, like communications with a REST API, you’ll need to have WiFi or cellular.

The key takeaway here is that you want to minimize, preferably eliminate, the number of (random) variables that may skew Time Profiler analysis and results. Imagine if you’re profiling an algorithm and your iPhone starts up Background App Refresh… Your analysis may be tainted — artificially skewed so that you believe your algorithm is slower that it really should be. Imagine if you profile one algorithm when nothing is running in the background on your iPhone, profile a similar algorithm while your iPhone performs a background refresh, and then compare the two results (data sets). Is this a meaningful comparison?

Using Instruments’ Time Profiler template

Let’s walk through the profiling of my “Optimizing Swift Code” sample project. Open the project in Xcode. Click and hold the Build and then run the current scheme button until you see the down arrow. Click the down arrow and then select the Profile option from the context menu, like so:



The Choose a profiling template for: dialog will open. Select the Time Profiler template and click the Choose button:



The Time Profiler template window will open, ready to sample and render performance data of my “Optimizing Swift Code” app. I’ll refer to the following image as the “map:”



I’ve numbered my annotations to correspond with the general sequence of the workflow you use to analyze app performance. I’ll also refer to these annotations in the following discussion.

To begin profiling, press the record toggle button — what I call the “1 – Start/Stop” (map) button. Watch, and be patient:



When you feel you’ve sampled enough data, press the “2 – Pause” button or “1 – Start/Stop” toggle (see map). Now it’s time to examine the profile (sample data collected). Since I’m running code in the background via GCD, I can scroll down to see activity per thread and per core:



Analyzing your profile

Now it’s time to analyze the recorded profile data. You generally start by clicking into an area of activity on the track/timeline or by highlighting a “slice” of the timeline. Remember that you can look at not just the top/aggregate track, but can inspect each thread or core:



When you click on a single time/data sample or highlight a slice, the corresponding code executing at that time of that selection is shown in what I annotated on my map as the “4 – Heaviest Stack Trace,” “5.1 – Stack trace of method names (tree),” and “5.2 – Measures of CPU used.” You all should know that functions are pushed on and popped off the stack, that functions calling other functions builds a stack trace, and that “Heaviest Stack Trace” means high CPU usage (cycles).

If you’ve found that there’s some bottleneck in your app, but you don’t know where exactly it resides in your code, look for: 1) functions in the “Heaviest Stack Trace” pane, and/or, 2) thick, high, and blue activity on the top track, or possibly in thread and core tracks.

I’m interested in two regions on the timeline. Why? because they show non-trivial CPU activity:



After I’ve selected a slice of the timeline, here “Region 1,” I first look at the “4 – Heaviest Stack Trace” pane (see map) for method names I recognize with a person icon next to them. The person icon indicates my code; other icons represent iOS calls. The “4 – Heaviest Stack Trace” pane shows me code with high CPU usage.

In this case, I also expected to see certain functions at startup; code that I wrote. I know my own code. I clicked on one of my method names in “4 – Heaviest Stack Trace” so that its stack trace and symbols (function/class/struct names) would be shown in the “5.1 – Stack trace of method names (tree)” and “5.2 – Measures of CPU used” pane (see map):



Notice all the detail. And notice that I can expand a symbol (function) name to see everything being called by it. If you go into my “Optimizing Swift Code” project, you can see how the Organization.createEmployees() method is called at app startup. Look in project file Organization.swift and you’ll find this code:

import Foundation

class Organization {
    
    var employees: [Employee] = []
    
    func createEmployees() {
        
        for count in 1...count {
            
            let employeeID = "employee" + String(count)
            let age = Int(arc4random_uniform(47)) + 18
            
            let employee = Employee(firstName: "first"+String(count), lastName: "last"+String(count), age: age, streetAddress: String(count)+" Main St", zip: "90210", employeeID: employeeID)
            
            employees.append(employee)
            
            print("Employee \(count) created.")
            
        } // end while
                
    } // end func createEmployees()
    
} // end class Organization

But… I don’t have to switch to Xcode to look at my code.

If I double-click on the symbol Organization.createEmployees() in the “5.1 – Stack trace of method names (tree)” and “5.2 – Measures of CPU used” pane, I jump right to source code:



You see that Instruments provides annotations (metrics) on performance (like the yellow arrow marked “47x”), but suppose you want serious detail, like assembly code. Click on the Show side-by-side source/disassembly view button:



Look at all that information. You can even see ARC memory management in action, like retain and release statements. Note that ARC has overhead, so when using classes (reference types), you may have to carefully architect your code — and possibly optimize it.

Now that you have an idea of how the Instruments’ Time Profiler template works, let’s look at optimizing some Swift code.

Optimizing Swift code

Those busy Swift compiler engineers have done a great job of making Swift fast and light-weight. Back in Swift 2.0, there were more opportunities for developers using the language to optimize their code. With the release of Swift 4.2, the compiler is pretty darn optimized — but that doesn’t prevent people from writing bad code. Still, developers need to legitimately optimize code, especially code in which there are complex relationships, mountains of data, and/or extensive calculations.

Dynamic dispatch

Let’s look at an example involving dynamic dispatch. I urge you to pause at some point while reading this article to take a look at an excellent Apple Developer blog post entitled “Increasing Performance by Reducing Dynamic Dispatch”. You should understand dynamic dispatch by now, even the Swifties, but especially if you used to develop in Objective-C.

While my sample code is not Earth-shatteringly innovative, it’s not supposed to be. I’m using a simple example so you can understand the language concepts and optimization tools.

Remember “Region 2” in my Time Profiler trace? Here’s a reminder:



Let’s look at what Instruments showed me when I selected a slice of this part of the timeline:



Hmmm… I see ViewController.startButtonTapped(_:), which is close, but I’m not seeing what I’m interested in. (That’s because this is a simple example, I’m running code in the background using GCD, and therefore iOS is using as many threads/cores as necessary to keep my app responsive.)

I’m comparing the performance of two methods, showEmployee() and show(). See file ViewController.swift in my “Optimizing Swift Code” sample project:

@IBAction func startButtonTapped(_ sender: Any) {
        
        while true {
            
            DispatchQueue.global(qos: DispatchQoS.QoSClass.default).async {
                
                for count in 0...count-1 { // 0...999999
                    
                        //let employeeInfo = self.organization.employees[count].showEmployee()
                        let employeeInfo = self.organization.employees[count].show()
                    
                        DispatchQueue.main.async {

                            self.newEmployeesTextView.text += employeeInfo
                            print("\(employeeInfo)\n")
                            
                        }
                    
                } // end for count in 0...count-1
                
            } // end DispatchQueue.global
            
        } // end while true

    } // end func startButtonTapped

Remember “6 – Find symbols” in my map? I ran multiple profiling sessions, several to investigate showEmployee() and several for show(). Hey, call me a stickler for details, but I don’t trust one data sample. I’ve got two math minors with an emphasis on statistics, so yes, I profiled multiple times to make sure my claims were substantiated. I’ll present two representative samples from my research (and yes, I switched out of dark mode because my eyes were getting tired).

Here’s what I found out about the performance of Employee.show():



Here’s what I found out about the performance of Employee.showEmployee():



What I found was that Employee.showEmployee() is conservatively about 2.5 times faster than Employee.show(). Yes, I know… Is saving less than a millisecond really an optimization? In this app, no. If you’re working on some app that repeats a call millions of times, maybe optimization by taking out dynamic dispatch would be worth your effort.

So why is Employee.showEmployee() faster? Let’s look at the code. First, look in file People.swift:

import Foundation

class Person {
    
    /*
     final var firstName: String
     final var lastName: String
     final var age: Int
     final var streetAddress: String
     final var zip: String
    */
    var firstName: String
    var lastName: String
    var age: Int
    var streetAddress: String
    var zip: String
    
    init(firstName: String,
         lastName: String,
         age: Int,
         streetAddress: String,
         zip: String) {
        
        self.firstName = firstName
        self.lastName = lastName
        self.age = age
        self.streetAddress = streetAddress
        self.zip = zip
        
    }
    
    func show() -> String {
        let line = """
        First name: \(firstName)
        Last name: \(lastName)
        Age: \(age)
        Street Address: \(streetAddress)
        Zip Code: \(zip)
        """
        
        return line
    }
    
} // end class Person

Notice method show() above. It is overriden in file Employees.swift, show here:

import Foundation

class Employee: Person {
    
    var employeeID: String
    var retirementAge: Int = 60
    
    init(firstName: String,
         lastName: String,
         age: Int,
         streetAddress: String,
         zip: String,
         employeeID: String) {
        
        self.employeeID = employeeID
        super.init(firstName: firstName, lastName: lastName, age: age, streetAddress: streetAddress, zip: zip)
    }
    
    func isRetirementReady() -> Bool {
        if age >= retirementAge {
            return true
        }
        else {
            return false
        }
    }
    
    override func show() -> String {
        var line = super.show()
        line += "Employee ID: \(employeeID)\n"
        line += "Retirement Age: \(retirementAge)"
        return line
    }
    
    final func showEmployee() -> String {
        let line = """
        First name: \(firstName)
        Last name: \(lastName)
        Age: \(age)
        Street Address: \(streetAddress)
        Zip Code: \(zip)
        Employee ID: \(employeeID)
        Zip Code: \(zip)
        """
        
        return line

    }
    
}  // end class Employee

Notice that I’ve indulged in some overkill here to make a point. Not only have I completely rewritten the show() methods in the form of showEmployee(), but I’ve marked showEmployee() as final which “allows the compiler to safely elide dynamic dispatch indirection.”

Whole Module Optimization

Remember earlier that I said that the Swift compiler is getting really smart? As I understand it, the optimizations that I’ll discuss from here onwards are already turned on by default. Even so, I believe it’s instructive and helpful for you to understand what the Swift compiler is doing with your code.

Look at the default Xcode 10 Build Settings under Swift Compiler – Code Generation:



Notice that Compilation Mode is set to Incremental for Debug and that Optimization Level is set to No Optimization for Debug. These settings make for fast build times. It should be obvious why performing no optimizations is faster. Incremental building means only recompiling files that have changed since the last build, accounting for updated dependencies. Finally, the Swift compiler “can compile many files in parallel on multiple cores in your machine.”

Compilation Mode is set to Whole Module for Release. Optimization Level is set to Optimize for Speed for Release. That makes for fast apps that you publicly distribute.

I made it a point to break my code into as many logical modules as possible in my “Optimizing Swift Code” sample project:



I profiling of this project and many other projects for customers, I’ve seen Whole Module Optimization speed up my public releases. In fact, the changes I made to enhance performance in the previous section were done in Debug. When I removed the final keyword in Release, my profiling seemed to confirm that the Swift compiler inferred it as an optimization.

NOTE: You should still consider applying the final keyword to both class properties and methods when performance is critical. You can always use Instruments to determine if your “optimizations” are indeed optimizations.

There’s one language feature where Whole Module Optimization has an additive effective on another one. We’ll discuss this in the next section.

Generics

Think about a generic function like the one included with my sample app. You’ll find it in Generics.swift:

func exists<T: Equatable>(item:T, inArray:[T]) -> Bool {

    var index:Int = 0
    var found = false
    
    while (index < inArray.count && found == false)
    {
        if item == inArray[index]
        {
            found = true
        }
        else
        {
            index = index + 1
        }
    }
    
    if found
    {
        return true
    }
    else
    {
        return false
    }
    
} // func exists

The compiler looks at this function and realizes that “it must be able to handle any type T” that conforms to Equatable. Think about the complexities involved in generics. You’re writing code that ideally should be able to handle any type.

Swift already supports an optimization called generic specialization. It turns out that Whole Module Optimization also optimizes generics. Why?

I know this is a relatively old video, but you should watch the whole thing to find out.

I proved to myself that Whole Module Optimization sped up calls in my sample project to my exists generic function. I profiled the project with Whole Module Optimization on and then profiled it with the setting turned off. This is how you learn about powerful tools.

Simple optimizations

Say you’re designing a data-intensive app and you need to pick the fastest data structures to use in your code. Go to a site like this one, look at the Big-O complexity chart, review the data structures, and look at the time requirements of their operations. Then pick the data structures that balance your requirements with speed.

ARC memory management

ARC memory management management has overhead, but I’ve read multiple scientific and commercial journal articles that do not conclude that reference types and reference semantics are slower than value types and value semantics.

In my own work, I’ve never been able to prove that, in general, one was faster than the other, as long as sound best practices were used in development across the board.

While writing this article, I actually coded an entire Swift project that performs the same task by 1) entirely using reference types and semantics and 2) entirely using value types and semantics. After multiple sessions with the Time Profiler, I couldn’t find any significant difference between the two.

Nevertheless, I’ve seen scenarios in which ARC did degrade performance when misused, for example, creating too many references, or using large numbers of reference types when value types could be used instead. One has to strike a balance. For example, if we replace a bunch of references with values, what happens if we have to constantly change and copy those values?

Conclusion

I encourage you to play with with my project’s Swift code and its Swift Compiler – Code Generation settings — and then practice with the Time Profiler to analyze and possibly optimize the code. If not my code, use your own code. But practice, practice, practice with the Time Profiler.

You need to be able to find bottlenecks in your code and then be able to optimize them. You’ll feel a bit overwhelmed if you’ve never used Instruments before. I’ve been using its templates for years and still find it a bit overwhelming. But not using Instruments is a travesty. It offers so many ways to solve problems more easily than using brute force.

By brute force, I mean only fixing bugs and making optimizations by using print statements and maybe some breakpoints.

Please don’t give up on tools like object-oriented programming, protocols and protocol-oriented programming, generics, and closures just because you’ve had a few bad experiences or because your heard they have “high overhead.” When used right, these tools can actually reduce the amount of code you write and speed up your apps. They can certainly help with code maintainability, readability, and reusability.

You have excellent tools with Xcode. Use them.

]]> https://iosbrain.com/blog/2018/11/10/dividing-and-conquering-your-xcode-projects-with-targets/ Sat, 10 Nov 2018 17:08:55 +0000 https://iosbrain.com/?p=3144 Continue reading "Dividing and conquering your Xcode projects with targets"]]> My original article — “Dividing and Conquering Your Xcode Projects with Targets” — was published on appcoda.com.

In this tutorial, I’ll show you how to leverage Xcode targets to control the massive complexity involved in building iOS (and macOS, watchOS, and tvOS) apps. A lot of time can be saved when developers realize that not everything they’re required to do has to be done by writing software language code, like Swift. Integrated development environments (IDEs) like Xcode offer very powerful tools, like targets, that allow developers to decouple nitty-gritty tasks that used to be done in code (or manually) out into project configuration settings. I’ve found that, because of the sheer number of project settings, developers often take one look at say, Xcode’s long, long list of Build Settings, and want to curl up and pass out. When finished reading this tutorial, you’ll see that you can neatly organize code into one project that’s capable of producing binaries for iOS, macOS, watchOS, and tvOS.

If developers take the time to harness the power of Xcode’s features, they can spend most of their time doing what they should be doing: designing, writing, and organizing their code using tools like architectural design patterns (MVVM), tactical design patterns (factory method, facade, adapter), object-oriented techniques, protocol-oriented techniques, generics, delegation — all good, solid development concepts.

Developers should always be on the lookout for opportunities to logically organize and group related code and, conversely, logically separate unrelated code. Xcode targets can let you take related code, put it into one project, yet simultaneously target that code at each of Apple’s platforms: iOS, macOS, watchOS, and tvOS.

When it comes to the more mundane tasks, like changing an app’s name, version number, help bundle, app icon, or copyright text, programmers should be able to turn to Xcode’s tools. Developers shouldn’t be dealing with such tasks using hacks, pyramid-of-doom if statements, and hardcoding values and/or logic. Let’s decouple our coding from these usually boring but necessary responsibilities. Targets help here.

The protocol I’ll discuss herein is a mixture of using Xcode “targets” and “schemes.” I’m sure all sorts of people have all sorts of ways of doing things differently, but I’ve found that this works best for me. I’m not claiming this is the only way to do things.

I know I could’ve (possibly) made things even more generalized by using workspaces, but this is a tutorial. You need to grasp the basics of Xcode’s targets and schemes before building a better, newer, grander solution. There’s such a thing as being too generalized to be useful, too…

Introduction

When you create a new project in Xcode, one single target is created for you. For example, I created an Xcode project for iOS, based on the Single View App template, and named it “Xcode Targets.” You can download it from GitHub. Let’s get a quick overview of how project configuration settings/options are stored.

According to the Xcode docs, “By selecting the project name in the project navigator, you open the project editor.” Let’s do that and here’s what we’ll see:



A we forge ahead through this tutorial, keep two concepts from the Xcode docs in mind. First, consider that:

Build settings defined at the target level override any values assigned to those build settings at the project level. Therefore, target-level configurations take precedence over any project-level configurations.

Second, recognize that:

A target contains instructions–in the form of build settings and build phases–for building a product. A target inherits the project’s build settings. Although most developers seldom need to change these settings, you can override any of the project’s build settings by specifying different settings at the target level.

You’ll see that I generally disagree with the statement, “Although most developers seldom need to change these settings.” We’ll be changing settings. That’s a major concern in this tutorial.

A note about “configurations”

Apple notes that:

When you create a project, Xcode provides two standard project-level build configurations: debug and release. … These two build configurations are probably sufficient for your product development needs. Most developers never need to change the values of the vast majority of build settings.

I would add that you can change debug and release settings in each of your targets, not just at the project level. Perhaps because of the length of time that I’ve developed Apple apps, and the complexity of most of the apps with which I’ve worked, I find myself and coworkers often needing to change the values of Build Settings. I also find it very confusing and difficult to manage when almost every build setting at the project and target level have a Debug and Release option. See the following image — and remember that these are just a few of the available options:



So when faced with debug/release, debug/release, debug/release, debug/release… I see the opportunity for developers to start unwittingly — and easily — commingling debug and release options, or just plain setting conflicting options. As we’ll soon see, I’d rather keep all my release settings in one target and my debug settings in another.

Separating release settings from debug settings

Once I’ve created a project as described above, the first thing I do is to rename the default target as shown here:



Let me just briefly mention schemes. There are a variety of ways to approach organizing project settings, and I want to keep this tutorial simple. Let me just quote the Xcode documentation again:

When you open an existing project (or create a new one), Xcode automatically creates a scheme for each target. The default scheme is named after your project…

You can read up on schemes using the links I’ve provided. Since a default scheme was generated when I created the project, I’m going to rename it with the same name as I did my default target:



Notice that I’ve left the Autocreate schemes checkbox ticked.

Now let’s set “Xcode Targets – Release” scheme’s Build Configuration to Release to match it’s name. Go to the Set the active scheme control, just where we started in the last video, Edit Scheme…, and change Debug to Release as follows:



Of course, now we want to create a new target (and scheme) for debugging. Here’s how we create and rename a new target:



The Autocreate schemes checkbox had its intended effect, creating a new scheme — except it didn’t catch my renaming of my new target to “Xcode Targets – Debug.” Make sure to change the newly auto-created scheme from “Xcode Targets – Release copy” to “Xcode Targets – Debug” just like I showed you up above. Make sure to set “Xcode Targets – Debug” scheme’s Build Configuration to Debug. You may find that it already is Debug, but check anyway.

To switch between debug and release configurations, all you have to do is switch/set the active scheme. Very importantly, make sure you confine all your Release configurations in Build Settings to the “Xcode Targets – Release” target and confine all your Debug configurations in Build Settings to the “Xcode Targets – Debug” target. We’ll see how to do this below.

A note about Info.plist

When you Duplicate (create) a new target, Xcode creates a new Info.plist. It gives it a name you probably don’t want and puts the file where you probably don’t want it:



I like to use the $(SRCROOT) macro in my Xcode projects to standardize and organize my file locations. To keep things “Xcodey,” I set my Build Settings for my “Xcode Targets – Release” target’s Info.plist like so:



For my “Xcode Targets – Debug” target, I put my Info.plist here:

$(SRCROOT)/Xcode Targets/Debug/Info-Debug.plist

I highly recommend that you clean up your Project Navigator setup after making these changes. (I control-clicked on my “Xcode Targets” folder in the Project Navigator and used the Add Files to “Xcode Targets”… context menu command.) Look at the sample project and you’ll understand.

Release versus debug dependencies

I’ve supported quite a few iOS and macOS Xcode apps that consume C++ libraries. In order to provide optimized production code, I only include release versions of libraries when distributing apps to the public. When developing and debugging, I want debug versions of libraries with all symbols linked into my apps so I can set breakpoints and step through code.

For production, I switch to my “Xcode Targets – Release” target and drag release versions of libraries into Build Phases -> Link Binary With Libraries like this:



For debugging and development:



Remember that if I’m calling code from linked libraries, I’ll need the paths to the header files (.h, .hpp). I usually specify those in Build Settings -> Search Paths -> User Header Search Paths:



If I am responsible for the library code and maintain it in Xcode, I can use the same separation of concerns structure outlined in this tutorial in my library projects. We’ll see an example below.

Suppose I have release and debug versions of iOS frameworks. For release, I simply click on my “Xcode Targets – Release” target and drag the release framework version into General -> Embedded Binaries. For debug, I simply click on my “Xcode Targets – Debug” target and similarly drag the debug framework version into my target.

Release and debug dependencies are cleanly separated using my targets protocol. We’ll talk more about dependencies later.

Compilation conditions

Those of us who used and/or are still using Objective-C are accustomed to leveraging symbols like DEBUG defined in Xcode under Build Settings -> Apple LLVM 9.0 – Preprocessing -> Preprocessor Macros. If you want similar behavior in Swift, you need to use what Apple calls conditional compilation:

A conditional compilation block allows code to be conditionally compiled depending on the value of one or more compilation conditions.

You can use any of the symbols listed in this link, but I’ll talk about using custom symbols here. Swift still respects DEBUG, but if you want to use it, or the language’s built-in symbols, or custom symbols, you have to now define them in your Build Settings -> Swift Compiler – Custom Flags -> Active Compilation Conditions.

Let’s say I’m logging (LOG) in release to create an audit trail (i.e., I’m tracking logins). Here’s what’s in my “Xcode Targets – Release” target:



Let’s say I’m not worried about auditing during development. Here’s what’s in my “Xcode Targets – Debug” target:



I’ve supported quite a few iOS and macOS Xcode projects that consume C++ code that runs on multiple platforms, including Unix/Linux flavors, Microsoft Windows, and macOS. Sometimes things get tricky and, for example, I run into code that will only compile and run on Windows, but not on Mac, and vice versa. I try to minimize such situations, but sometimes things just need to get done. When necessary, I use preprocessor macros or, as Apple now says in Swift, compilation conditions, like WIN, MAC, LOG, and DEBUG.

When calling into my portable C++ code, something like MAC would be defined in both release and debug versions so that I can selectively compile, or not compile, portable or non-portable core code that can only build and run, or not build and run, successfully under macOS (or Windows). Remember that I can use logical operators like ! (not) with my compilation conditions.

I generally use DEBUG to report on and sometimes act upon error conditions. I generally use LOG when my code needs an audit trail (like when processing sensitive data).

If, for example, I have to deal with core code specific to Mac, and debugging and logging, I would use the following generalized though runnable ViewController.swift file:

class ViewController: UIViewController {
    
    var loginAttempts: Int = 0
    
    @IBAction func loginButtonPressed(</em> sender: Any) {
        
#if LOG
        print("Login button pressed")
        loginAttempts += 1
        if loginAttempts > 3 {
            print("HACK ATTEMPTED?")
            // CALL 911!
        }
#endif

    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view, typically from a nib.
        
#if WIN
        print("Use Windows code...")
#elseif MAC
        print("Use Mac code...")
#endif
        
    }

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
        
#if DEBUG
        print("ViewController::didReceiveMemoryWarning")
#endif
    }

} // end class ViewController

Let’s say I build and distribute my app using the “Xcode Targets – Release” target. Here’s the console output from the previous code snippet:

Use Mac code...
Login button pressed
Login button pressed
Login button pressed
Login button pressed
HACK ATTEMPTED?

The main takeaway here is that you can define as many or as few compilation conditions as you like and specify differing combinations of those conditions in different targets. While I generally frown upon conditionally compiling code, there a times when nothing else works in complex, realworld scenarios. I’m more comfortable with using compilation conditions for situations like turning logging (i.e., print statements) off and on.

Different app flavors/branding

What if you’ve licensed your code to partners/resellers who want their own branding, like custom logos/icons and specific product names, to be displayed by an app? In the iOS App Store, Apple generally frowns on a bunch of identical apps that only differ in their main icons… At least they say they do ;-). But you definitely can have multiple versions of the same app(s) differing in the sense of up-selling from free to intermediate to advanced features and functionality. Branding or “flavors” of iOS apps is much more flexible in an Apple Developer Enterprise Program environment. In macOS development, Apple allows you to build, brand, and distribute apps without going through the Mac App Store, and thus you’re afforded much more flexibility.

Do differing icons, graphics, text, and tiered features warrant multiple Xcode projects? Generally, no. Why not just use targets? I’ve supported apps that have 10 different flavors.

To show you how you can leverage targets to handle branding, I created an Xcode project for macOS, based on the Cocoa App template, and named it “Xcode Manage Config.” You can download it from GitHub.

My project shows you how you can abstract out and customize an app’s 1) help bundle, 2) name, 3) version number, 4) app icon, and 5) copyright text, all without hacking, i.e., without using if statements and hardcoding values. Reviewing the code and commentary in my sample project’s ViewController.swift file should give you a good idea of how I abstracted all details for the 5 tasks I just listed out of code and into targets:

import Cocoa

let reverseDomain = "us.microit."

class ViewController: NSViewController {
    
    @IBOutlet weak var logoImage: NSImageView!
    @IBOutlet weak var productName: NSTextField!
    @IBOutlet weak var copyright: NSTextField!
    @IBOutlet weak var version: NSTextField!
    
    var helpPath: String = ""
    
    override func viewDidLoad() {
        
        super.viewDidLoad()

        // Do any additional setup after loading the view.

        // Get the product name by stripping out the
        // reverse domain name.
        let bundleIdentifier = Bundle.main.bundleIdentifier?.replacingOccurrences(of: reverseDomain, with: "")
        
        // Display the product name.
        productName.stringValue = bundleIdentifier!
        
        // Build app icon set name using concatenation.
        let appIconSetName:String = bundleIdentifier! + "AppIcon"
        // Get and display the product logo.
        logoImage.image = NSImage(named: NSImage.Name(rawValue: appIconSetName))
        
        // Get the copyright statement.
        let copyrightString = Bundle.main.object(forInfoDictionaryKey: "NSHumanReadableCopyright")
        // Display the product copyright.
        copyright.stringValue = copyrightString! as! String
        
        // Get the product version.
        let versionString = Bundle.main.object(forInfoDictionaryKey: "CFBundleShortVersionString")
        // Display the version.
        version.stringValue = "Version: " + (versionString! as! String)
        
        // Build and save the path to help files.
        helpPath = Bundle.main.path(forResource: "index", ofType: "html", inDirectory: bundleIdentifier!)!
        
    } // end func viewDidLoad()
    
    @IBAction func invokeHelp(</em> sender: Any) {
        // Open help in default browser.
        NSWorkspace.shared.openFile(helpPath)
    }
    
    override var representedObject: Any? {
        didSet {
        // Update the view, if already loaded.
        }
    }

} // end class ViewController

Let’s build and run the code to see how targets can differentiate two licensors of the same software but with different branding. Let’s build and run the “Acme – Release” target:



Now let’s build and run the “Emca – Release” target:



Notice that nothing was hardcoded… well, except my reverse domain name, and that hasn’t changed since 1999. It could easily be abstracted into a plist. Please forgive my one, minor transgression. Notice that the official app icons for each target are recognized by macOS:



What if we click on the “Help” button in either target’s app? This is help customized to the “Acme – Release” target, running in Safari:



The “Emca – Release” target’s help is differentiated:



The help bundle
A help bundle is often just a directory containing HTML files/resources. I dragged help folders named “Emca” and “Acme” into the Project Navigator. I was prompted by Xcode both times. I’ll just show you the prompt for the “Acme” folder. Notice I only set the “Acme” folder to be a member of the “Acme – Release” target:



If you click on the “Emca” folder in Xcode’s Project Navigator, you’ll see its Target Membership is only ticked for the “Emca – Release” target:



I’ve seen multi-megabyte help bundles, so if you insist on including the actual help resources in your project, make sure you’re not including stuff that you don’t need, like don’t include Acme’s help in Emca and vice versa. On a side note, believe it or not, I’ve heard many customers insist that they get the actual help included in-situ in their products.

If you plan building, signing, and creating a signed installer for one or both of the “Xcode Manage Config” project’s targets, you need to take a few extra steps. For one thing, remember to go to Build Phases -> Copy Bundle Resources and add the “Acme” folder for copying in the “Acme – Release” target, and similarly add the “Emca” folder for copying in the “Emca – Release” target. Again, two products; two different targets.

The app name and version number
The app name and version number are distinct per target. You set them by selecting the target and then going to General -> Identity. I’ll just show you how I set the values for the “Emca – Release” target:



The app icon
Here, you can see that I’ve already set the app icon for “Acme – Release” and am about to create a new app icon set for “Emca – Release” — this is in the Asset Catalog which is shared by all targets:



Notice that in my code above, I get the code-independent Bundle Identifier and append “AppIcon” to it to get the app icon set appropriate to the current target.

The copyright text
I arranged the Info.plist files for the two targets in this project as I had discussed above in the first sample project. As you’d expect, there’s an Info-Acme.plist for the “Acme – Release” target and an Info-Emca.plist for the “Emca – Release” target. Changing the copyright text is code independent. You highlight the plist file in each target, click into the Copyright (human-readable) string value, and make your edits like so:



We just went through a whole slew of examples of how you can leverage targets for keeping your app code and resources centralized and giving you the flexibility to make changes, like generating multiple flavors of the same app, without using hacks like hardcoding, writing scripts, or writing pyramid-of-doom if statements.

Different dependencies for different app platforms

Over the years, I’ve designed, encoded, used, and accumulated a lot of good, solid C++ code. This code is meant for solving a wide range of problems, or modelling a major gamut of everyday scenarios, for example, messaging, statistical tests, data manipulation, etc. Over the years, I’ve learned to first look for existing code that I can reuse before spending hundreds of hours reinventing the wheel… again (and again). TIP: Remember that you can divide and conquer your Swift code too by breaking it into modules like frameworks.

What does this have to do with targets? I’m going to show you how you can reuse existing code in one Xcode project that has targets for macOS and iOS (and tvOS and watchOS if you put a little thought into it). So one project can allow you to build binaries and reuse them in four different Apple app types.

I could show you how to do this with frameworks, and that’s the direction to which you’ll want to head, but to keep this didactic, short, and simple, I’m just going to build libraries. You can download a library-based project I created named “Xcode Cocoa Library” from GitHub if you want to follow along.

Create a new Xcode project using these settings:



Click Next and configure thusly:



Click Next and save in a location of your choosing. In the Project Navigator, find the file Xcode_Cocoa_Library.m and rename it to Xcode_Cocoa_Library.mm to be sure that C++ and Objective-C++ are supported.

As we did earlier, Duplicate the “Xcode Cocoa Library” target, renaming the new target and associated scheme as “Xcode iOS Library.” At this point, your project should look like so:



Highlight the “Xcode Cocoa Library” target, go to Build Settings, and look at the Architectures section. You’ll note that the library is configured to be run under macOS on an Intel-based machine:



Notice the target builds successfully.

Highlight the “Xcode iOS Library” target, go to Build Settings, and look at the Architectures section. Change the Base SDK to the latest version of iOS, like so:



You should notice that the library is configured to be run under iOS on an ARM-based machine. Build the “Xcode iOS Library” target. Notice the target builds successfully.

Let’s add some code to the project just to be sure we can write C++ and Objective-C++. (Note that many times I’ve added rock-solid existing C++ .h and .cpp files, blended in some Objective-C and Objective-C++, and was able to reuse mountains of code in my macOS, watchOS, and iOS apps.)

Here’s file Xcode_Cocoa_Library.h:

#import <Foundation/Foundation.h>
#include <iostream>

@interface Xcode_Cocoa_Library : NSObject

- (void)helloWorld;

@end

class Parent {
public:
    virtual void soundOff() {
        std::cout << "This is the parent class" << std::endl;
    }
};

class Child: public Parent {
public:
    virtual void soundOff() {
        std::cout << "This is the child class" << std::endl;
    }
};

Here’s file Xcode_Cocoa_Library.mm:

#import "Xcode_Cocoa_Library.h"

@implementation Xcode_Cocoa_Library

- (void)helloWorld {
    
    Child child;
    child.soundOff();
    
    NSLog(@"Hello, world!");
    
}

@end

Build both targets with the new code added. Here’s the result (success):



These library names would be red if they failed to build.

I’m not going to show you how to consume this library in a Swift-based project, as it’s beyond the scope of this tutorial. Rest assured that I’ve incorporated such libraries (and static libs and frameworks) many times into Swift-based projects (generally using a wrapper, a bridging header, and of course, including the libraries’ header files).

The point I’m making here is that you can reuse code and organize it, without using hacks, build for multiple platforms, and get great maintainability and extensibility. How? By using targets.

Truly universal app code

Take a look at this image from the “Xcode Cocoa Library” project discussed in the last section:



I could create two new targets, one for tvOS and one for watchOS. If I organize code properly, keeping abstraction in mind, I can build, maintain, and extend functionality for macOS, iOS, tvOS, and watchOS all in one project.

Conclusion

In reality, I currently have libraries that allow me to reuse much of my over-the-years-accumulated C, C++, Objective-C, Objective-C++, and Swift code in macOS, iOS, tvOS, and watchOS apps. The reason I mention all these languages is that Xcode’s targets and schemes have enabled me to reuse a lot of code I’ve written in the past — and I’ve been able to reuse my legacy code on multiple Apple platforms, namely iOS, macOS, watchOS, and a bit of tvOS.

I’ve only been able to do that by planning, doing requirements analysis, designing first before coding, concentrating on abstraction — looking before leaping. I’ve been able to abstract so much code by implementing concepts and techniques like best practices for building classes, using architectural design patterns like MVVM, using tactical design patterns (here, here, and here), and, of course, using object-oriented and protocol-oriented programming techniques.

I’m waxing theoretical. You’ve got great tools available to you, like Xcode and its targets and schemes. Don’t be a just-get-it-done developer. Invest some time into reading up on the documentation provided with Xcode. Look at some third party books and videos. Join special interest groups. Join social media groups. Take the information you glean from your studying and put it to practice in your everyday work. Don’t be a stick in the mud. Try new things and constantly push the envelope.

If you take the time, you’ll find that tools like Xcode provide features beyond your wildest dreams.

]]>