TrozWare

In Praise of SwiftUI

2026-05-26T15:00:00Z

Recently, I have seen multiple posts on Mastodon suggesting that SwiftUI is a failure, that nobody is using it, and that Apple should have focused on improving or replacing AppKit and UIKit instead of wasting everyone's time with SwiftUI. While I have great respect for some of the people saying these things, I disagree. I love using SwiftUI, I think a large number of developers are using it, and I want to explain what I find so great about it.

Perhaps one problem was the name. Yes, it allows you to define your user interface in Swift, but so do AppKit and UIKit. For me, the part that I miss most when going back to work on an older project is the data flow and the reactive nature of SwiftUI, and that's not reflected in the name at all.

Data Flow

I have written several articles about SwiftUI's data flow. The most recent one was in 2023 and it's still valid today: SwiftUI Data Flow 2023. I won't repeat all the details here, but SwiftUI gives us features that allow for concise and logical data control, while making it clear which view owns the data and provides the single source of truth.

The reactive aspect of SwiftUI feels like magic! It allows me to have something like a stored setting with a default value, connected to a menu item with a checkmark, a toggle in a settings window, a button in the toolbar, and a switch on the main interface. SwiftUI keeps these all in sync without any effort on my part. This sort of flexibility was a lot of work in AppKit and UIKit, and it was easy to end up with sections of the UI out of sync with the data. In AppKit apps, you could use Cocoa Bindings, but these were tricky to set up, not good with source control and totally opaque to any developer new to the project.

User Interface

Let's go deeper into the UI part. AppKit and UIKit have two options for creating user interfaces. You can either build graphically in Xcode's Interface Builder, or write all the interface in code. The "interface-in-code" lobby has always been very vocal and while I only ever did this for small sub-views, I can see part of the appeal. It's definitely better for source control as the interface is saved as text instead of in Xcode's strange XML that changes frequently for no apparent reason. But it's also a lot of code to write, and it doesn't give the interface positioning guidelines and the easy access to interface element properties that Interface Builder provides. However, unlike SwiftUI, both these methods give you pixel perfect control over the positioning, even if AutoLayout frequently drove me to distraction.

SwiftUI takes a very different approach and to some extent, it takes the power away from the developer and insists that Apple knows best. This means that when designing apps for different platforms, you don't have to remember the differences between the AppKit and UIKit versions of a control and you don't have to apply the different interface guidelines. SwiftUI applies styling and behavior for each platform, but this doesn't always give the result that people want and expect.

Paulo Andrade wrote an article recently titled Using SwiftUI to build a Mac-assed App in 2026. He thoughtfully detailed several ways in which SwiftUI fails to create the Mac experience that we have learned to expect. A lot of his points were to do with how the app indicated selections, but he also covered toolbars, drag & drop and keyboard shortcuts. While I understand what he's saying, and agree that SwiftUI and AppKit provide different experiences, I would argue that the Mac experience has changed many times and in lots of ways over the years. We developers are familiar with the small details and notice the changes, but to most users, this is just how Mac software is now. I got my first Mac in 1985, so I may have a broader perspective on this than most people. I do agree with his point that the Mac doesn't seem to matter inside Apple these days, but I also think it's part of the general trend of Apple rushing to release the big yearly OS updates and not taking the time to test and polish them, which lowers the quality of all their software, not just macOS or SwiftUI.

AI

Critics of SwiftUI are using AI as an excuse to go back to AppKit or UIKit. There is no doubt that these older frameworks require a lot more boilerplate code, especially if you're designing the interfaces in code. The AI proponents argue that if AI is writing all this verbose code, then there is no need for the more concise SwiftUI. While I have started using AI to write some code, I still review every line and the more the AI writes, the harder this becomes and the more likely it is that there will be un-detected bugs.

There's no doubt that right now, the various LLMs have had access to a lot more AppKit and UIKit code than they have SwiftUI code. This is purely a factor of the ages of the frameworks. But that doesn't mean that they can't write SwiftUI. You need to provide guidance, but that's true for any code generation.

SwiftUI Problems

I don't want to imply that I think SwiftUI is perfect. I have struggled with various aspects of it, and I have had to find workarounds for some things that I want to do. Partly, this is due to the buggy nature of Apple software at the moment, but as someone who primarily works with Mac apps, I am feeling the pain of the lack of attention to the Mac. Again, this is not a SwiftUI problem, but a general Apple problem.

As an example, I have had to recommend that people building Mac apps avoid NavigationSplitView completely. It is very buggy and doesn't work well with multi-window apps. My numerous feedbacks have been ignored except for one response telling me that I shouldn't assemble all my feedbacks on the topic into a single report!

There are still some performance issues, particularly with long lists, but these can be worked around by dropping back to AppKit or UIKit. The ability to mix and match SwiftUI with UIKit and AppKit is a great feature, and it allows for gradual adoption of SwiftUI as well as filling in the gaps with AppKit or UIKit when needed.

My Plans

SwiftUI started off missing a lot of features that had to be added using UIKit or AppKit. This was a sensible approach as it allowed Apple to release it before it was fully featured, however with the addition of the SwiftUI web view last year, there are very few things that you can't do in SwiftUI now.

My current strategy is ALWAYS to start with SwiftUI. I find it much easier to write, read and maintain, and really appreciate the ease of passing data around the app.

If I come across a bug in a SwiftUI component, I will try to work around it or see if I can use an alternative SwiftUI approach. If that doesn't work, I will drop back to AppKit or UIKit for that part of the app.

For long lists, again I'll start using SwiftUI, but if I find performance issues, I'll drop back to AppKit for that part of the app.

I can't see myself ever basing an app on AppKit or UIKit again, but I will continue to use them as needed to fill in the gaps and work around SwiftUI bugs.

I ❤️ SwiftUI!

If you have any feedback about this article, please contact me using one of the links below or through the Contact page. And if you found this useful, please buy me a coffee.

macOS Apprentice: 3rd Edition

2026-05-13T11:18:04Z

The third edition of macOS Apprentice has been released!

If you're a beginner or near-beginner who wants to start learning Swift, SwiftUI and AppKit for building Mac apps, then this is the book for you.

This edition has been updated for Swift 6, macOS 26 and Xcode 26. It now includes details on using the new Icon Generator as well as major changes in the chapter that deals with embedding an AppKit view in a SwiftUI app. All the code and screenshots have been updated to reflect changes in Xcode, Swift, SwiftUI and macOS.

macOS Apprentice is a series of multi-chapter tutorials where you'll learn about developing native macOS apps in Swift, using both SwiftUI — Apple's newest user interface technology — and AppKit — the venerable UI framework. Along the way, you'll learn several ways to execute Swift code and you'll build two fully featured apps from scratch.

If you're new to macOS and Swift, or to programming in general, learning how to write an app can seem incredibly overwhelming.

That's why you need a guide that:

Shows you how to write an app step-by-step.
Uses tons of illustrations and screenshots to make everything clear.
Guides you in a fun and easy-going manner.

You'll start at the very beginning. The first section assumes you have little to no knowledge of programming in Swift. It walks you through installing Xcode and then teaches you the basics of the Swift programming language. Along the way, you'll explore several different ways to run Swift code, taking advantage of the fact that you're developing natively on macOS.

macOS Apprentice doesn't cover every single feature of macOS; it focuses on the absolutely essential ones. Instead of just covering a list of features, macOS Apprentice does something much more important: It explains how all the building blocks fit together and what is involved in building real apps. You're not going to create quick example programs that demonstrate how to accomplish a single feature. Instead, you'll develop complete, fully-formed apps, while exploring many of the complexities and joys of programming macOS.

The book consists of four sections:

Section 1: Install Xcode and learn the basics of programming in Swift. Experiment with several different ways to execute Swift code on your Mac.

Section 2: Use SwiftUI to develop a word-guessing game called Snowman. Learn about data flow in SwiftUI, managing multiple windows, using charts and adding macOS-specific features such as toolbars and menus.

Section 3: There are still a number of tasks where AppKit works better than SwiftUI. In this section, build an AppKit app to browse movie data from IMDb, the online movie database.

Section 4: Add AppKit to your SwiftUI app and add SwiftUI to your AppKit app in order to add some finishing touches to both of the apps from the previous sections.

You can read more details of the book contents in the Introduction.

If you are a more experienced iOS developer who wants to branch out into macOS development, then my previous book - macOS Apps Step by step - might be a better fit, although I think you could still learn a lot of Mac app tips and tricks from this one.

Where Can You Find the Resources?

You can read the book online at kodeco.com as part of a Kodeco subscription. The introduction and the first chapter are free to read.

All the code and extra materials for the book can be downloaded or cloned from GitHub.

For support, to ask questions or to report any errors, please go to the forum.

Thanks to...

This book was made possible by an awesome team. There were a lot of people involved, but I want to give special thanks to:

Richard Critz, the wonderful editor who had the unenviable task of fixing my grammar.
Audrey Tam and Ehab Amer were the amazing tech editors who had to make sure that it all worked. Audrey also contributed the first chapter on installing and setting up Xcode.

The whole team at Kodeco was great, so a huge thanks to them all. I hope they enjoyed working on the book as much as I did! It's wonderful to have such a supportive group working to make my content as good as it can be.

Feedback

I would love to hear from anyone who read the book, loved it, hated it, found an error or just wanted to say hello.

You can contact me directly using any of the contact links at the bottom of this page or through the Contact page.

Playing in the Mac App Sandbox

2026-03-23T14:57:12Z

Every app running on any Apple device, including a Mac, runs inside a sandbox by default. This keeps the app's data and settings isolated from other parts of the system so they cannot interfere with each other. As a Mac app developer, this is usually what you want, but sometimes the default sandbox settings do not allow your app to operate the way you need. In many cases you can work around this by adjusting the sandbox, but for some apps, you have to turn off sandboxing.

In this article, I want to walk through what the sandbox does by default, how you can configure its settings for various tasks, when you need to turn it off, and why it's actually a good idea.

What does the Mac App Sandbox do?

In Xcode, create a new macOS app project that uses Swift and SwiftUI. Add a button that calls this function:

func saveTestString() {
  let docsUrl = URL.documentsDirectory
  let fileUrl = docsUrl.appendingPathComponent("save_test.txt")

  let saveString = """
    This is a test.
    Where do you think it will save?
    """

  try? saveString
    .write(
      to: fileUrl,
      atomically: true,
      encoding: .utf8
    )
}

The first two lines construct a URL based on the Documents directory. The function then tries to write a test string to this URL.

So the question is: where does this file end up? If you were expecting it to be in your Documents folder, you'd be disappointed.

Run the app or refresh the SwiftUI Preview and click the button. Now let's go and find the file...

In Finder, hold down Option and open the Go menu. Select Library and when the window opens, locate and open the Containers folder. My app is called Sandbox, so in Containers, I see a folder called Sandbox that has a single folder called Data. And here's where things get interesting:

The folders where the icons have a small black arrow at the bottom left are aliases to your actual Desktop, Downloads etc. The folders with the standard folder icon are specific to this app and they are stored inside the container so that the app can't over-write any other app's data. The default sandbox settings allow your app to read and write any files here.

You should write any app data to these folders. Your app stores its settings in the Library/Preferences folder inside this Data folder.

App Sandbox Settings

To see the available settings for your app's sandbox, go back to Xcode and select the project at the top of the Project navigator (press Command-1 if this isn't visible). Next, click on the app target and select Signing & Capabilities along the top to see several sections, including the one for the App Sandbox:

There are four groups of settings, so let's step through them:

Network

You'll almost never need to change the Incoming Connections (Server) option. This is for running a server that needs to accept connections from other devices.

The Outgoing Connections (Client) option is one you'll probably use a lot. As you would expect, if your app connects to the internet in any way, you need to enable this. But there is another use case that might surprise you.

If your app contains a web view of any kind, you need to enable this option, even if the web view is only used to display local content from inside your app.

I added a WebView and WebPage to a new tab in my sample app and asked it to load a static HTML string. When I ran the app, nothing appeared in the web view and the console showed these unhelpful warnings:

I think the one I have highlighted is the relevant one. When I enabled Outgoing Connections (Client) and tried again, I got even more warnings but this time, the web view showed my content.

Hardware

The hardware section lets you enable any extra hardware features that your app needs access to. The only one I've ever used is Printing. The USB option does not need to be checked to allow standard peripherals like keyboards and mice to work, but if your app needs to communicate with a USB device directly, then enable this.

Similarly, for your app to record audio, take photos or connect to any Bluetooth devices directly, you need to enable the relevant options here.

If you enable any of these, click the + Capability button and search for a new capability for the name that you can use to explain to the user why the app needs this access.

App Data

Similar to the hardware settings, if your app needs to access the user's contacts, calendars or location, you need to enable that here.

In an iOS app, this is done using Privacy settings in the Info.plist where you have to give a reason for why your app wants access. For a Mac app, you enable the relevant option in the sandbox settings and the system will prompt the user for permission when needed. As with the hardware settings, look for a new capability that can tell the user why you need this access.

File Access

Now we get to the really interesting section. Ignoring the first option for now, the other four options give access to specific folders on the users system. You can choose to give your app no access by selecting None (the default), Read Only access, or Read/Write access to any of these folders.

The top entry is the User Selected File option. This lets your app access any files and folders that the user has specifically selected using a file dialog. Again, you can select Read Only or Read/Write access. But there are some oddities about this that need more explanation.

Leaving this at the default of Read Only, I'm going to add to my sample app. I added another tab which has its own view – OpenFilesDemo. This contains an AsyncImage that loads an image from an optional URL and two buttons:

Using NSOpenPanel

The first button uses AppKit to show a file dialog and uses the result to populate the image URL. Here's the function that it calls:

func selectAppKit() {
  let panel = NSOpenPanel()
  panel.allowedContentTypes = [.image]
  panel.message = "Select any image file…"

  imageUrl = nil

  panel.begin { response in
    if response == .OK, let url = panel.url {
      imageUrl = url
    }
  }
}

This uses AppKit's NSOpenPanel configured to allow only image files to be selected. When the user selects a file, the URL is stored in imageUrl. This optional URL is already connected to the AsyncImage, so when it is set, the image will load. It's cleared before showing the panel to make sure that the image does a complete refresh, even if there's been an error or the same image is selected again. This method works perfectly and the selected image appears.

Using fileImporter

Now on to the SwiftUI technique that uses a fileImporter modifier. First, set up a Boolean to toggle the visibility of the file importer:

@State private var showFileImporter = false

The second of the buttons clears imageUrl and sets this Boolean to true so that the file importer sheet appears. To create and configure the importer, I added this modifier to the view:

.fileImporter(
  isPresented: $showFileImporter,
  allowedContentTypes: [.image]
) { result in
  switch result {
  case .success(let url):
    imageUrl = url
  case .failure(let error):
    print("Image import failed: \(error.localizedDescription)")
  }
}

As with the NSOpenPanel, this restricts the user to selecting image files. The completion handler receives a Result with the selected URL if successful or an error if something went wrong. Again, I assigned the selected URL to imageUrl so that the image will load into the AsyncImage. But this time, when I run the app and select an image, nothing appears. The console shows this error:

As with so many Xcode warnings, this doesn't really help but the docs for fileImporter are more useful. It turns out that NSOpenPanel returns a usable URL but when you use fileImporter inside a sandboxed app, it gives you a security-scoped bookmark which you cannot use before requesting access from the system.

I updated the .success case to this:

case .success(let url):
  let gotAccess = url.startAccessingSecurityScopedResource()
  if gotAccess {
    imageUrl = url
  }

And now the image appears when using either button. However the Xcode docs are very insistent that every call to startAccessingSecurityScopedResource() must be balanced with a call to stopAccessingSecurityScopedResource() or your app will leak kernel resources. I'm not sure what effect that will have but it sounds bad...

Because I'm using an AsyncImage, I can't stop the access immediately after setting the URL because the image will not have finished loading and that would mean the URL became unavailable before it had been used. Instead, I added an onAppear modifier to the Image inside the AsyncImage:

.onAppear {
  imageUrl?.stopAccessingSecurityScopedResource()
}

Because the imageUrl property is cleared every time, this runs whenever a new image appears. It doesn't matter whether the URL is security-scoped or not – this works either way.

Saving URLs

Before moving on from this topic, there is one more issue that effects URLs no matter how they are selected and that's if you want to save them for re-use next time the app runs. Let's say we want to store the selected image URL and re-display that image when the app is launched again.

In a non-sandboxed app, this is easy – change the imageURL property from using @State to @AppStorage and it just works.

// @State private var imageUrl: URL?
@AppStorage("imageUrl") var imageUrl: URL?

But with the sandbox in the way, this becomes a whole lot more complicated, so I reverted this change, re-sandboxed the app and tried again.

You have to create a security-scoped bookmark from the URL and save that instead of saving the URL itself. First, I added an @AppStorage property to hold the bookmark, which is Data and not a URL:

@AppStorage("storedBookmark") private var storedBookmark: Data?

Then I added a method to convert the URL to a bookmark and save it:

func saveBookmarkData(for url: URL) {
  if let bookmarkData = try? url.bookmarkData(options: .withSecurityScope) {
    storedBookmark = bookmarkData
  }
}

This uses a URL method to convert the URL into bookmark data with the .withSecurityScope option. If this succeeds, I store the bookmark data in storedBookmark which is saved in AppStorage. In a production app, I'd put this inside a do/catch block and handle any errors that might occur, but I'm trying to keep the demo code as concise as possible.

To use this, I amended the onAppear for the Image inside the AsyncImage:

.onAppear {
  if let imageUrl {
    saveBookmarkData(for: imageUrl)
    imageUrl.stopAccessingSecurityScopedResource()
  }
}

This checks for a valid imageUrl and if found, saves the bookmark data and only then stops accessing the resource.

The strange thing about this is that it only works if the sandbox setting for User Selected File is set to Read/Write instead of Read Only. I don't see why this should be so, but it is.

With this in place, I added a method to re-load the image from this stored bookmark:

func loadImageUrlFromBookmark() {
  guard let storedBookmark else {
    return
  }

  var isStale = false
  guard let url = try? URL(
    resolvingBookmarkData: storedBookmark,
    options: [.withSecurityScope],
    relativeTo: nil,
    bookmarkDataIsStale: &isStale
  ) else {
    return
  }

  let gotAccess = url.startAccessingSecurityScopedResource()
  if !gotAccess {
    return
  }

  imageUrl = url
  if isStale {
    saveBookmarkData(for: url)
  }
}

This is rather more complicated than the saving method!

First, check for data in storedBookmark and return if there isn't any. Then try to resolve this data back into a URL, using the security scope option that was used when saving the bookmark. The resolvingBookmarkData method reports if the URL is stale meaning that the file has moved or been deleted since you saved it. And again, this should be in a do/catch block with error handling.

If there is a URL, it's security scoped so try to start accessing it and if that fails, return. If it succeeds, assign the URL to imageUrl so that the image will load. Finally, if the bookmark was stale, create a new bookmark from the updated URL and save it.

To call this, I added a modifier to the VStack:

.onAppear(perform: loadImageUrlFromBookmark)

So now we have a technique that saves and loads URLs in a sandboxed app – hurray!

If you want to test the isStale part, run the app and select an image. Then quit the app and move the image file to a different folder. When you run the app again, it will load the image from the new location which is pretty amazing, in my opinion.

Temporary Entitlements

So far, I've covered the standard features that you can enable as required inside the sandbox. There is another category called temporary entitlements, which you can request in an entitlements file. Although these are listed as temporary, I think that's just so that Apple can feel free to shut them down at any time. They do not expire and have to be renewed.

There's a rather old page in Apple's developer documentation that describes these: AppSandboxTemporaryExceptionEntitlements.html. The most common one (and the only one I have ever used) is the one that requests file access to a particular folder. In my Man Reader app, I search for man pages in the /opt/ and /usr/ folders so I request read-only access to those two paths.

To demonstrate this, I added another tab to the sample app with buttons that try to read from these folders using this method:

func readFiles(in folder: String) {
  let fileManager = FileManager.default

  do {
    let contents = try fileManager.contentsOfDirectory(atPath: folder)
    filesList = contents
  } catch {
    print(error)
  }
}

This time I am using a do/catch so that I can see the errors, and when I test using the current sandbox settings, I get this:

So now we need to add an entitlements file to the project.

Apple has made this more difficult over the years. Previously, Xcode created an entitlements file for every project so it was there to be edited. Now it doesn't exist so you have to create it manually which is a multi-stage process.

First, we have to add a new file to the project. Select the Sandbox folder in the Xcode project navigator – this is the second entry from the top and selecting it ensures your entitlements file will be where it should be. Use Command-N to open the file template chooser and search for property to find the Property List template:

Click Next and change the name of the file to Sandbox.entitlements – make sure you change the file extension from the default .plist to .entitlements. Un-check the target – this file will not be part of the target app bundle, it's used by Xcode when building the app:

Now that the entitlements file has been created, we need to add the temporary exception for file access. Open the file and add a new array with the name com.apple.security.temporary-exception.files.absolute-path.read-only. Then add two String items to this array with the values /usr/ and /opt/.

In Property List edit mode, it will look like this:

If you want to check this or prefer to edit as text, right-click on the file in the Project navigator and select Open As > Source Code to see the XML:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.temporary-exception.files.absolute-path.read-only</key>
	<array>
		<string>/usr/</string>
		<string>/opt/</string>
	</array>
</dict>
</plist>

The final stage is to tell Xcode to use this entitlements file. Select the project at the top of the Project navigator, then select the app target and go to Build Settings. Select All at the top and then search for entitlements to find the Code Signing Entitlements entry.

Double-click to the right of this entry to popup an edit box and type in Sandbox/Sandbox.entitlements – this is the path to the entitlements file that we just created, relative to the project folder:

The edit box doesn't show a cursor or any indication that you can edit it, but start typing and it will work. Press Return to apply your change.

Finally, run the app again, try to read the contents of the /usr/ or /opt/ folders and it works!

I used the folders I needed access to as examples. You would need to specify exactly what temporary entitlements you need for your app. Also, when submitting to App Store review, tell them why you need these and the reviewers will be more likely to approve your app.

When You Must Turn Off the Sandbox

So far, I've shown how to make the sandbox work for you, by adjusting settings and using entitlements. But there are some cases where you just have to turn it off.

To do this, go to Signing & Capabilities and click the trash button at the top right of the App Sandbox section. You can always add it back using the + Capability button if you change your mind later.

In my experience, I have only had to turn off the sandbox when I needed to use command-line tools that are reading or writing files outside the sandbox. For example, in my macOS Apps Step by Step book, one of the apps uses the sips command-line tool to edit image files. sips needs to read and write files as specified by the user, but because it's operating outside the app, it doesn't inherit the sandbox permissions that the app has. In this case, I had to turn off sandboxing for the app.

Your experience will differ but sometimes this is the only way to allow your app to do what you need.

Why Use the Sandbox At All?

So after nearly 3,000 words on how to work around all the sandbox limitations, you're probably wondering if it's worth the effort. Why not just turn it off and make everything easier?

There are two main reasons to use the sandbox, even if it causes some extra work:

Only sandboxed apps can be distributed through the Mac App Store. This is not a deal-breaker because Mac apps can be distributed outside the App Store, but it's something to consider.
Sandboxing is a security feature that protects your app and your users. With your data and settings confined to their own container, there is little chance of any interference between your app, the system, and any other apps, including any malware.

Apple is tightening the restrictions on what apps can be installed and run on a Mac by default. Even if you decide not to sandbox your app, I strongly recommend that you sign it and get Apple to notarize it, so that your users can install and run it without having to put up with scary warnings and obscure activation steps. This doesn't require sandboxing but does require an Apple Developer account and the app's Signing & Capabilities settings must include the Hardened Runtime capability.

My recommendation is to start every project with the sandbox enabled and using all the default settings. Enable extra permissions only as you need them. Add entitlements if the settings do not allow what you need. Only turn off sandboxing if there is no other way to make your app work.

If you have any feedback about this article, please contact me using one of the links below or through the Contact page. And if you found this useful, please buy me a coffee.

All the sample code from this article is on GitHub so download it and you'll see the rest of the code that was too long to fit in the article. Thanks to Stewart Lynch for his Icon Composer Lite app which I used to create the sample app icon.

NSTableView scroll bug in macOS Tahoe

2026-01-31T09:39:37Z

Recently. I was working with an AppKit app that uses an NSTableView to display long list of items. While testing the app on macOS Tahoe, I noticed a bug in the scrolling behavior: when I scrolled down from the top, the content rows would scroll into the header, making the top messy and unreadable. This sort of overlapping and unreadable text is a feature of the various OS 26s, but in this case, there wasn't a hint of transparency, so it looked like a bug to me.

I did a lot of searching online, but couldn't find any references to this specific issue, so once I worked out the cause and a workaround, I thought I'd share it here, for anyone else who encounters this issue.

The Problem

First, let me show you what happens. This is from the MovieTables app for an upcoming update to the macOS Apprentice book.

When the table is scrolled to the top you can see the headers:

After scrolling, it's a mess:

This exact layout worked fine on earlier versions of macOS, but as is often the case with all the OS 26s, things that used to work no longer do.

Investigating the Problem

I tried many things to fix this: adjusting all the various settings for the table view, its clip view, the enclosing scroll view and the header view but nothing worked. I adjusted content offsets, turned on or off various clip settings and so on. I even tried manually adding constraints to pin the content inside the safe area. And as I already mentioned, I couldn't find anyone online who had encountered this problem.

Finally, I decided to request code-level support using my Apple Developer account. Before starting that, I needed to create a stripped down sample app that demonstrated the problem. After using AI to generate a JSON file containing 500 sample data points (one thing AI is really good at), I added all the boilerplate code and setup needed to display data in an NSTableView using a data source and delegate. I ran the app and ... it worked perfectly, with no overlapping text!

WHAT!!!

Once I calmed down a bit, I realized that at least this meant that there had to be a solution. Now I had to find the difference between my main app and the sample app that was causing the problem.

Finding the Solution

It looked like nearly everything was identical in both tables. The only obvious difference was that my main app's table had 3 columns and the sample app only had 2. I modified the sample app to add another column and that changed nothing.

Then I stopped looking at the table itself and considered the overall layout of the window. In the sample app, the table was the only view in the window's content view, so I set its Auto Layout constraints to make it fill the window completely. In my main app, I had left space for other views below and to the right of the table view. Could this be significant?

Acting on the principal of only changing one experimental variable at a time, I added space on the right and set a background color for the view to make the table positioning clear. No change - the table still scrolled perfectly, with the content disappearing under the headers as expected:

I reversed that change and then added space below the table view. Bingo! ... The problem appeared!

So that was the bug. If a table doesn't stretch from top to bottom of its view controller's content view, in macOS Tahoe, the content will scroll into the header.

Note: When you add an NSTableView to a storyboard, it arrives wrapped in an NSClipView which is itself wrapped in an NSScrollView. The NSScrollView is the view that actually gets positioned and sized using Auto Layout. That's the view that has to fill the entire height of the content view.

So now I had identified what caused the problem, but how to fix it? One possibility was to work out a different location for the view I wanted to add to the bottom of the window, so that the table could fill the view vertically, but I didn't want to do that. I wanted a workaround that would allow me to keep my existing layout.

What if I added space above the table view as well as below it? I tried that, and it worked! The table scrolled correctly, with the content disappearing under the headers as expected.

I ended up spacing the table view 1 point down from the top and 1 point in from the left of its enclosing view. The left spacing is not required but it makes the layout look more symmetrical. This prevents the bug from occurring and allows me to add the content I want underneath the table:

I don't think it looks as neat and clean as the original layout, but at least it works.

Conclusion

If you're using an NSTableView in an AppKit app running on macOS Tahoe, and you notice that the content scrolls into the header view, check the layout constraints of the NSScrollView that contains the table. If it doesn't fill the entire height of its enclosing view, add a small amount of spacing above it to fix the problem.

I discovered later that another option is to turn off the border for the NSScrollView, but I prefer the spacing solution as I think the table looks better with a border.

If anyone from Apple is reading this, I filed a feedback report about this and included a sample project for testing (FB21850950).

If you have any feedback about this article, please contact me using one of the links below or through the Contact page. And if you found this useful, please buy me a coffee.

Moving from Process to Subprocess

2025-11-27T00:12:50Z

For many years, I've used Process to call Terminal commands from my macOS apps. Process is an old technology, formerly known as NSTask. It works, but it's complicated to set up and it can have issues. The Swift language team have now published a modern alternative called Subprocess. Since I'm currently using Process in my Man Reader app and in my macOS Apps Step by Step book, I thought it was time to assess the new option and see if I should swap to it.

I started by creating a sample project using the macOS App template. Then I added the package dependency by searching for https://github.com/swiftlang/swift-subprocess. This also adds swift-system which the ReadMe says provides idiomatic interfaces to system calls and low-level currency types. Next, I removed the App Sandbox in Target -> Signing & Capabilities. Man Reader gets round the sandbox restrictions using temporary entitlements and security-scoped bookmarks, but I didn't want to complicate my tests with those. I set up my sample app with two tabs so I could directly compare Subprocess and Process. Each tab has the same buttons that run the same Terminal commands, but using the two different methods. I also switched the build settings to use Swift 6 as I am gradually adopting this in all my projects.

The first step was to try a simple command with no parameters. In SubprocessView.swift, I imported the Subprocess library, and set the whoami button to call this method using a Task:

func runWhoami() async {
  let output = try? await run(
    .name("whoami"),
    output: .string(limit: 4096)
  )
  print(output ?? "no result from whoami")
}

This is based on the first example in the Subprocess ReadMe. It uses ls but I used whoami in my book, so I changed to that. I resumed the Live Preview, clicked the button, and the Canvas console showed this, which I've split on to two lines here for readability:

CollectedResult, DiscardedOutput>(processIdentifier: 14711,
terminationStatus: exited(0), standardOutput: Optional("sarah\n"), standardError: ())

There are immediate benefits to using Subprocess. I didn't have to specify the full path to the whoami command, and I didn't have to set up a pipe and a file handle to see the result. The type of output is a CollectedResult which contains the processIdentifier, terminationStatus, standardOutput and standardError. A terminationStatus of 0 means the command completed successfully.

NOTE: If I had wanted to use a particular version of whoami, I could have specified the full path like this:
let output = try? await run(
  .path("/usr/bin/whoami"),
  output: .string(limit: 4096)
)
This option requires import System in order to have access to the FilePath type.

To get the output I wanted into a String, I added:

let result = output?.standardOutput ?? "unknown"
print("whoami: \(result)")

Next I wanted to test sending arguments. I added a new ping button and set it to call this method:

func runPing() async {
  let commandName = "ping"
  let arguments = ["-c", "5", "apple.com"]

  let output = try? await run(
    .name(commandName),
    arguments: arguments,
    output: .string(limit: 4096)
  )
  print(output?.standardOutput ?? "no result from ping")
}

That's when I found out that arguments must be an array of Arguments, not Strings. This was solved by changing the second setup line to:

let arguments = Arguments(["-c", "5", "apple.com"])

This worked, but there was no output for about 5 seconds, then it all appeared. Reading further down the Subprocess ReadMe I saw a way to stream the output as an AsyncSequence, so after a bit of experimentation and some help from ChatGPT, I arrived at this runPing method:

func runPing() async {
  let commandName = "ping"
  let arguments = Arguments(["-c", "5", "apple.com"])

  async let pingResult = run(
    .name(commandName),
    arguments: arguments
  ) { execution, standardOutput in
    for try await line in standardOutput.lines() {
      print(line.trimmingCharacters(in: .whitespacesAndNewlines))
    }
  }
  if let result = try? await pingResult {
    print("Ping result = \(result)")
  } else {
    print("No result from ping")
  }
}

It's essential to await pingResult or the method ends before any data arrives.

This worked, but I was still getting the complete output at the end, and not seeing each line as it arrived. To help in my research, I selected Build Documentation from the Product menu which gave me the docs for Subprocess in Xcode's Developer Documentation. There are a lot of custom types, but only one function - run - which has 14 different versions. Seven of these variants expect an Executable, which is what I've been using when I specify a .name. The others expect a Configuration which is a way of combining an executable and its arguments plus other configuration details, into a single object.

I also discovered that the versions that streamed data had a preferredBufferSize setting. The docs say:

Larger buffer sizes may improve performance for subprocesses that produce large amounts of output, while smaller buffer sizes may reduce memory usage and improve responsiveness for interactive applications.

I set the preferredBufferSize to 32 and watched the lines come in one by one. It would be great if there was an option to buffer until a line feed, but this is workable.

This basically covers how I use Process in macOS Apps Step by Step, so now on to what Man Reader needs. It uses find to search for man pages, man with a -w argument to find the path to a man page, and mandoc with col to get the formatted page data. This adds two new challenges: find will return a lot of data and mandoc needs to pipe its output to col.

Starting with find, Man Reader searches the /opt and /usr directories by default. On my system, /opt contains 32504 man pages and /usr has 2979. For both of these, I was able to use the basic form of run, but I set the output string limit to Int.max. This is way more than necessary, but better to be safe.

func findManPages(in directory: String) async {
  let commandName = "find"
  let arguments = Arguments([directory, "-path", "*/man/*.*"])

  let config = Configuration(.name(commandName), arguments: arguments)
  let output = try? await run(config, output: .string(limit: Int.max))

  if let result = output?.standardOutput {
    let pages = result.components(separatedBy: .newlines)
    print("found \(pages.count) man pages in \(directory)")
    print("string length = \(result.count)")
  } else {
    print("error finding man pages in \(directory)")
  }
}

This time, I used a Configuration to assemble the command and its arguments, then passed that to the appropriate version of run.

I tested streaming the results, but that was more CPU intensive, even when using the default preferredBufferSize. I added some timing routines so I could compare it to the Process version. On my Mac, searching /usr takes between 400 and 500 milliseconds, and searching /opt takes between 1.2 and 2.5 seconds. Since this is all async code, the app remains totally responsive during this time.

The last problem I needed to solve was how to pipe the output from one command to another. When using Process, this is surprisingly easy - you create a pipe and set it as the standardOutput for the first command. Then you set the same pipe as the standardInput for the second command.

Checking the run options, I can see that some variants have an input parameter. So if I get the output from the first command, I can set it as the input for the second. The command I want to run is:

mandoc -T ascii /usr/share/man/man1/ls.1 | col -b

Here's what I came up with. This has the page to the ls man page hard-coded for testing:

func runPipedCommands() async {
  let manPagePath = "/usr/share/man/man1/ls.1"

  let commandName1 = "mandoc"
  let arguments1 = Arguments(["-T", "ascii", manPagePath])

  let commandName2 = "col"
  let arguments2 = Arguments(["-b"])

  let output1 = try? await run(
    .name(commandName1),
    arguments: arguments1,
    output: .string(limit: 100_000)
  )

  guard let outputString = output1?.standardOutput else {
    print("no output from \(commandName1)")
    return
  }

  // Uncomment the next two lines to see what happens without `col`
  //    print(outputString)
  //    return

  let output2 = try? await run(
    .name(commandName2),
    arguments: arguments2,
    input: .string(outputString),
    output: .string(limit: 100_000)
  )

  if let result = output2?.standardOutput {
    print(result)
  } else {
    print("no output from \(commandName2)")
  }
}

If you want to see why the col -b part is essential, uncomment the two marked lines and you'll see a result that starts like this:

The second tab has the same buttons with the same commands, but they run using Process. For the find command, the times are much the same, but I have to stream the incoming data as I did with pipe. Without this, the app freezes and the process never completes.

After these experiments, I will be moving to Subprocess in both the book and the app. Over the years I have added many tweaks, fail-safes, and workarounds to handle all the things that can go wrong with Process, but it will be great to use a more modern API without these issues. Sadly, I can't use it everywhere. I have a client app that uses Process but it has to support systems back to macOS 11 and it looks likeSubprocess only goes back to macOS 13.

My sample app is available on GitHub: https://github.com/trozware/subprocess-tests.

If you have any feedback about this article, please contact me using one of the links below or through the Contact page. And if you found this useful, please buy me a coffee.

Black Friday Sale

2025-11-23T22:08:15Z

For Black Friday 2025, my self-published books: macOS Apps Step by Step and Escape from Tutorial Hell are on sale for 30% off, from now until December 1st.

If you're looking for a discount on macOS Apprentice, check it out the Kodeco web site when their Black Friday sale is live.

macOS Apps Step by Step

If you're an iOS developer who wants to branch out into creating native macOS apps, this is the book for you!

Click the book cover from more information, and if you'd like to check out the start of the book including the table of contents and the first chapter, you can read it online at macOS Apps Step by Step Sample.

For anyone who previously bought the book from Kodeco when it was still called macOS by Tutorials, please email me for a 50% discount code.

Escape from Tutorial Hell

I wrote this book for people who have done some tutorials, read books, watched videos, and who know some Swift and SwiftUI but are finding it difficult to make the leap from there to working on their own apps. It's also for more experienced developers who want to learn how to design and structure their projects to make them easier to maintain.

Click the book cover from more information, or read the start of the book including the table of contents and the first chapter at Escape from Tutorial Hell Sample.

macOS Apps Step by Step 4.0

2025-11-05T23:44:23Z

macOS by Tutorials has a new name and a new edition!

The book is available for purchase or update at Gumroad.

macOS Apps Step by Step was previously titled macOS by Tutorials and was released in 2022 by Kodeco. Since they transferred the rights to me, I have released two updates under the same name, but now it feels like time to move on from the Kodeco naming convention and give it a name that is more part of my brand. After considering several options, I put a poll on Mastodon and macOS Apps Step by Step was the winner.

If you bought the first edition of macOS by Tutorials from either Kodeco or Amazon, please email me for a 50% discount code.

If you bought a previous edition of macOS by Tutorials from me via Gumroad, version 4 is a free update that you can download from your Gumroad library.

Click the image for more details, and if you’d like to check out the start of the book including the table of contents and the first chapter, you can read it online at macOS Apps Step by Step Sample.

The major changes in this fourth edition include:

A new title!
All projects updated to include new features introduced in macOS 26 Tahoe and Xcode 26.
All projects use Swift 5 or 6 with Approachable Concurrency. Swift 5 is still the default in Xcode but I switched all the projects to Swift 6 and made sure that all the code works for both versions.
The On This Day app has been re-designed to use a more stable HSplitView instead of the problematic NavigationSplitView.
Icons are created using Apple's Icon Composer app.
The MarkWriter app uses SwiftUI's WebView to display HTML content and adds the ability to work with and edit selected text.

If you already own the book and have enjoyed it or found it useful, I'd really appreciate it if you could leave a rating or review at the book's page in your Gumroad library.

Apple Has Two Problems

2025-10-28T02:01:52Z

Over the last few years, Apple Inc. has come in for its fair share of criticism. In my opinion, this boils down to two main problems: politics and software quality.

The company has lost its way several times over the years but it has always kept going and eventually bounced back. Now it's a massive company with more money than any human can imagine, and it's losing its way again. What can they do to bounce back this time?

The reason I care is because I love using Apple's products. I fell in love with the very first Macintosh, way back in 1984. It was many years before I was able to afford one, but I always admired them. The Mac is the computer I use every day and it's the computer I want to keep using. The iPhone is my principal communication device and the iPad is my entertainment center. I want to see Apple get back to being a company that I can feel good about buying from, with products that I want to use and that work as expected.

Politics

The first and most obvious problem is Tim Cook's personal and corporate funding and encouragement of the current US administration. This started with Cook's contribution to the inauguration and has continued through various cringe-making events to the stage where Apple is paying to assist in the legally suspect demolition of a piece of America's heritage.

Apologists say that Cook is doing this to avoid tariffs on Apple products, but what is the point in being one of the richest companies in the world if you don't use this power to stand up to bullies? People with $40 frog costumes can do it - why can't Apple?

As everyone who has ever been bullied knows, giving the bully what they want is only ever a temporary solution. They respect you even less for giving in and will just keep asking for more. At some point, one has to wonder if Tim Cook is doing this reluctantly because he feels it best for Apple, or if he really is a full-on MAGA supporter.

The second part of the political problem is the way Apple deals with the EU. The company has been very quick to cooperate with authoritarian governments around the world and at home. If you want a good list (which makes for very depressing reading) check out Jesse Squires' recent post: Apple's cooperation with authoritarian governments. But when the democratically elected European Parliament passes a law requiring Apple to do anything, they suddenly descend into petulant toddler mode and lie on the floor screaming. When eventually forced to comply, they do it with extremely bad grace and as poorly as possible, so as to give the worst possible result.

While I understand that a lot of politicians are not well enough informed about tech matters to legislate well, has it occurred to anyone at Apple to act like an adult and negotiate honestly and in good faith?

The Solution

The solution to this problem is that Tim Cook must go. I don't know how far down the rot goes and how many other Apple execs also need to go, but ditching Cook is an essential first step. I haven't any suggestions as to who should replace him, but I would suggest looking for an external hire - maybe even one from outside the US who doesn't believe that companies have the same rights as people.

Software Quality

The ever decreasing quality of Apple software is more of an existential threat to Apple. Cook will eventually go, and presumably democracy will return to the US, but if Apple software becomes more difficult to use and more buggy than Windows or Linux, they will lose customers who will then not want to risk coming back.

Apple Silicon is incredible. They appear to be designing and making the best chips in the world right now. I haven't seen any real-world benchmarks for the new M5 chip, but I'm sure it's another huge advance.

Apple hardware is pretty good. They make some odd design choices, like the power button underneath the Mac mini and the iPhone Air, but the overall quality is good. Even the Apple Vision Pro is a great piece of hardware. Like many others, I tested it in the local Apple Store and was blown away. If it was half the price, I might have actually spent a few minutes considering buying, but at that price, for what is essentially a media watching device, it is way too expensive for me.

It's the software that lets down the hardware and the quality has been going downhill for some years now. We are way out of the "it just works" phase of using Apple products. I consider myself an expert and I have great trouble accomplishing some tasks.

The latest versions of all the operating systems seem particularly buggy, even if one ignores the obvious readability problems of Liquid Glass. Apple is a company that has always prided itself on its commitment to accessibility, so how they got this so wrong is a mystery. It seems like they wanted a major redesign just for the sake of it, and were prepared to put up with a huge reduction in usability in order to look different.

Then we get to the fiasco of Apple Intelligence which is sounding more like an oxymoron every day. First, Apple showed us vapor-ware at WWDC 24. Then they used this mythical system to advertise the iPhone 16 - at least at first. Finally, they did a partial implementation which is embarrassingly bad. It sounds like a great idea to have Mail and Messages show summaries, but when the summaries make stuff up or reverse the meaning, this is much worse than no summary. And when you can't trust the summary, it becomes totally pointless.

In the developer world, we were promised a two stage roll-out. First predictive code completion in Xcode and second, Swift Assist. The predictive code completion has been released, but I've had to turn it off. I don't know what language it was trained on, but it obviously wasn't Swift! Despite having all the docs and APIs there in Xcode, it suggests functions that just don't exist. Or if they exist, it suggests incorrect parameters. This has been incredibly disappointing. Apple has a captive audience using Xcode and with all their resources, it could have been great.

Swift Assist never appeared. Apple gave up on this and instead integrated ChatGPT into Xcode. I've tried it a few times and once or twice it has even worked. The biggest problem is that Swift is still a rapidly developing language and ChatGPT is not up-to-date with the latest changes. So it's not much use for Swift development - at least not yet.

The Solution

Unlike the first problem, this one has a multi-stage solution:

Move Craig Federighi from software to marketing. He seems like a really nice person and he makes great videos, but he is not managing the software teams.
Fire Alan Dye and hire a team of UI, UX and accessibility experts to fix OS26.
Instead of penalizing engineers for spending time on tests and QA instead of new features, insist that they do.
Give up on the yearly OS release cycle and give the Apple engineers time to fix things.
Use the developer community which is full of people who want to help, but are sick of being treated like the enemy. I've written before about Apple's developer relations and nothing has changed since then.

So there it is - my opinion of what is wrong at Apple and what needs to be done to fix it. If you have any other ideas or comments, I'd love to hear them. Please contact me using one of the links below or through the Contact page. And if you found this article interesting, please buy me a coffee.

SwiftUI WebView

2025-08-15T11:11:18Z

At WWDC 2025, Apple announced that SwiftUI would now have its own WebView. I touched on this briefly in my SwiftUI for Mac 2025 article, but this view has a lot of features that I wanted to explore and document.

My primary source was the WWDC video: Meet WebKit for SwiftUI but as usual, there is a lot of detail hidden in the video and some of the sample code doesn't work in the later betas. I'm currently using macOS Tahoe 26 beta 7 and Xcode 26 beta 6.

I've written a sample app demonstrating various aspects of the new WebView, which you can download from GitHub. This will let you follow along with my descriptions below. The numbered sections in this article correspond to the files in the WebView Samples folder of the project.

1. WebURLView

The simplest way to use a WebView is to provide it with a URL:

WebView(url: URL(string: "https://www.swift.org"))

The URL is optional, so there's no need to force-unwrap it.

This is easy to use but doesn't allow any progress tracking or customization so I think I would rarely choose this option.

2. WebPageLoad

In the next example, I created a WebPage and used it to populate the WebView.

Toolbar buttons switch between loading an online page:

var request = URLRequest(url: URL(string: "https://troz.net")!)
request.attribution = .user
page.load(request)

Or loading a local HTML string:

page.load(html: html, baseURL: Bundle.main.resourceURL!)

In Apple's examples, they always use URL(string: "about:blank")! for the baseURL, but using Bundle.main.resourceURL! lets me include a link to a stylesheet that's inside the app bundle:

3. TrackLoad

In the WWDC video, they demonstrated how to track the navigation events. The code in the video does not work - it doesn't even compile. But after some trial and error, I worked out how to track these events.

When the view first appears, a task starts monitoring the events:

.task {
  await startObservingEvents()
}

My event tracker method uses the new Observations sequence to read an async stream of page navigation events:

func startObservingEvents() async {
  let eventStream = Observations { page.navigations }

  for await observation in eventStream {
    do {
      for try await event in observation {
        switch event {
        case .startedProvisionalNavigation:
          statusText = "Started provisional navigation for \(page.url?.absoluteString ?? "unknown URL")\n"
        case .receivedServerRedirect:
          statusText += "Received server redirect\n"
        case .committed:
          statusText += "Committed\n"
        case .finished:
          statusText += "Finished\n"
        @unknown default:
          statusText += "Unknown navigation event\n"
        }
      }
    } catch WebPage.NavigationError.failedProvisionalNavigation(let error) {
      statusText += "Error: Failed provisional navigation: \(error.localizedDescription)\n"
    } catch WebPage.NavigationError.pageClosed {
      statusText += "Error: Page closed\n"
    } catch WebPage.NavigationError.webContentProcessTerminated {
      statusText += "Error: Web content process terminated\n"
    } catch {
      statusText += "Unknown error: \(error.localizedDescription)\n"
    }
  }
}

This detects the WebPage.NavigationEvent types: startedProvisionalNavigation, receivedServerRedirect, committed and finished. Each of the possible thrown WebPage.NavigationError events is also monitored.

This seems like overkill for most use cases, but this code shows how to set it up. The key is that page.navigations is an AsyncSequence<WebPage.NavigationEvent, any Error>.

As an added extra, this example uses the value of page.isLoading to show or hide a ProgressView. This is what I'll mostly use for tracking loads and providing user feedback during a load. If you want to get fancy, you can provide the ProgressView with a value:

if page.isLoading {
  ProgressView(value: page.estimatedProgress)
}

This changes it from an indeterminate spinner to a progress bar.

4. CustomScheme

If you want your WebView to load custom pages, create a custom scheme. In my Man Reader app, I use a custom scheme to load HTML versions of man pages, so I decided to try something similar here.

First, you create your scheme and then a scheme handler that actually provides the data for the web view to display. The web page's configuration ties these two together.

let scheme = URLScheme("manpage")!
let handler = ManPageSchemeHandler()
var configuration = WebPage.Configuration()
configuration.urlSchemeHandlers[scheme] = handler

page = WebPage(
  configuration: configuration
)

My scheme handler struct conforms to URLSchemeHandler and has the required reply(for:) method to process the request. It tries to read the relevant file from the app bundle and if the file exists, uses its data to create a URLResponse and then to emit the response and the file data or any error in an AsyncSequence.

struct ManPageSchemeHandler: URLSchemeHandler {
  func reply(
    for request: URLRequest
  ) -> some AsyncSequence<URLSchemeTaskResult, any Error> {
    AsyncThrowingStream { continuation in
      guard
        let bundleURL = Bundle.main.url(forResource: request.url?.host, withExtension: nil),
        let pageData = try? Data(contentsOf: bundleURL)
      else {
        continuation.finish(throwing: URLError(.badURL))
        return
      }
      let response = URLResponse(
        url: request.url!,
        mimeType: "text/html",
        expectedContentLength: pageData.count,
        textEncodingName: "utf-8"
      )
      continuation.yield(.response(response))
      continuation.yield(.data(pageData))
      continuation.finish()
    }
  }
}

For example, when I try to open manpage://cal.html, this reads the cal.html file from the bundle, uses it's URL and length to create a URLResponse and then yields the response and the file data before finishing the stream.

If there's a problem with the file, the stream finishes by throwing an error.

This example also uses WebPage.NavigationDeciding to work out what to do with other schemes. Back in the initial setup phase, I created a decider and provided it to the WebPage, along with the configuration.

let navigationDecider = NavigationDecider()

page = WebPage(
  configuration: configuration,
  navigationDecider: navigationDecider
)

My decider class conforms to WebPage.NavigationDeciding and has a decidePolicy method that checks the supplied URL and works out what to do with it:

class NavigationDecider: WebPage.NavigationDeciding {
  func decidePolicy(
    for action: WebPage.NavigationAction, 
    preferences: inout WebPage.NavigationPreferences
  ) async -> WKNavigationActionPolicy {
    guard let url = action.request.url else {
      print("No URL supplied for decision")
      return .cancel
    }

    if url.scheme == "manpage" {
      print("Opening man page for \(url)")
      return .allow
    }

    print("Opening \(url) in default browser")
    NSWorkspace.shared.open(url)
    return .cancel
  }
}

As you can see, I first check that the WebPage.NavigationAction has a request with a URL. I can't imagine when this would ever be nil, but it's optional, so I check and cancel the navigation if it's missing. Then I test for my custom scheme and allow those pages to load. In this example, all other URLs open in the default browser so I return cancel to stop them opening in the WebView. To test this, open one of the man pages using a toolbar button and scroll to the end of the page where I added an external link.

Note: In macOS Tahoe 26 beta 7 and Xcode 26 beta 6, this external navigation prints what appears to be a crash log in the console, but the app does not crash.

This example demonstrates two other WebView features:

By default, a WebView allows bouncing so the page appears to scroll sideways even though it all fits. This is really obvious is you use a track pad and swipe sideways. To turn off this behavior, add this:

.scrollBounceBehavior(.basedOnSize, axes: [.horizontal])

Vertical scrolling still works and bounces, but horizontal does not, unless the content doesn't fit.

The other feature is searching in the page. Presenting the find interface works much like presenting a sheet - add a Boolean and connect it up:

@State private var findNavigatorIsPresented = false

// ...

WebView(page)
  .replaceDisabled(true)  // doesn't work yet
  .findNavigator(isPresented: $findNavigatorIsPresented)

I added a toolbar button to toggle findNavigatorIsPresented for showing and hiding the interface. I have included the replaceDisabled(true) modifier but it doesn't work in a WebView. The modifier doesn't stop the replace interface from appearing, but replacing doesn't actually work:

Interestingly, in a TextEditor, it is possible to hide the replace button by adding the replaceDisabled(true) modifier, but the number of matches doesn't appear.

5. JavaScripting

SwiftUI's WebView provides an asynchronous method for calling Javascript on the page. In this example, I load a page from my web site and once it's loaded, I send a JavaScript command to gather all the H3 headers so I can make them into a navigation menu in the toolbar.

While I could use navigation event tracking to detect when the page has finished loading, instead I use a loop containing Task.sleep to wait until page.isLoading becomes false:

func loadPage() {
  Task {
    sections = []
    let url = URL(string: pageAddress)!
    page.load(URLRequest(url: url))

    while page.isLoading {
      try? await Task.sleep(for: .milliseconds(100))
    }
    listHeaders()
  }
}

Once I have the list of headers, I add them to a toolbar menu for jumping around the page:

In the WWDC video, the presenter demonstrated a similar technique, although without sharing the actual JavaScript. When testing, I found it easier to write and debug my JavaScript functions directly in the browser, so the project repo includes my jsTests.js file.

The methods that use JavaScript are gathered into an extension on the JavaScripting view. I start by using multi-line strings to create the scripts, interpolating data from the view as needed. Then a Task uses try await page.callJavaScript(js) to call the JavaScript and get the result.

The result is of type Any? so then I try to cast it into the type I want. Here's the full method for listing the section headers:

func listHeaders() {
  let js = """
    const headers = document.querySelectorAll("\(headerElement)")
    return [...headers].map(header => ({
      id: header.textContent.replaceAll(" ", "-").toLowerCase(),
      title: header.textContent
    }))
    """

  Task {
    do {
      let jsResult = try await page.callJavaScript(js)
      if let headers = jsResult as? [[String: Any]] {
        let pageSections = headers.map {
          SectionLink(jsEntry: $0)
        }
        await MainActor.run {
          sections = pageSections
        }
      }
    } catch {
      print(error)
    }
  }
}

SectionLink is a struct that contains the section title and ID and has a custom init that takes a [String: Any] dictionary.

In this case, I interpolated headerElement directly into the JavaScript string, but you can also pass it to callJavaScript using the arguments parameter. Here's how I pass in a title for working out how to scroll to its section:

let result = try await page.callJavaScript(
  js,
  arguments: ["sectionTitle": section.title]
)

The JavaScript now has access to the sectionTitle variable, which contains the title of the section to scroll to. This returns the vertical offset of the section, which I then use to scroll the web view to that position.

Managing the web view's scrolling has several components. First, an @State property holds a ScrollPosition.

@State private var currentScroll = ScrollPosition()

Next, bind this property to the WebView using webViewScrollPosition:

WebView(page)
  .webViewScrollPosition($currentScroll)

Finally, when the JavaScript returns a value for the section offset, use this property to adjust the scroll:

withAnimation(.easeInOut(duration: 0.25)) {
  currentScroll.scrollTo(y: offset)
}

The animation makes the scroll look better, instead of jumping suddenly to the new location.

Another interesting part of the WWDC demo was detecting the scroll and setting the selected section to match. I had started by putting the sections into a Picker with a selection parameter. When the selected section changed, I scrolled the web view to that section.

That worked fine until I started detecting the scroll, which also set the selected section, which reset the scroll to the top of the current section every time. To get around this, I made the toolbar item into a menu with a set of buttons with scroll actions. They did not set the selected section, but their titles showed a leading checkmark for the selected section. The scroll detector worked out the visible section and set the selected section without altering the scroll.

To monitor the scroll position, I added this modifier to the WebView:

.webViewOnScrollGeometryChange(for: CGFloat.self, of: \.contentOffset.y) { _, newValue in
  adjustSelectionTo(scrollPosition: newValue)
}

The adjustSelectionTo(scrollPosition:) method uses another chunk of JavaScript to work out which section is now visible and the result of this is used to update the selected section property.

I had an issue with the longer section names which were truncated when another section was checked. This was fixed by using string interpolation instead of the string itself when showing the title without the checkmark. I'm not sure why this works, but I assume string interpolation forces the view to re-calculate its width each time.

6. Browser

The final example attempts to emulate a browser. There is a URL entry TextField at the top and a WebView below it.

The new part here is tracking the browser history and adding back and forward buttons. These use the page.backForwardList to create their menus with a primary action that goes back one or forward one.

At first, I assumed that page.load() required a URL or a URLRequest, but then I realized that I could also ask it to load a WebPage.BackForwardList.Item directly.

I had a problem with the back and forward menus which made me think that the history was not updating correctly. After temporarily re-purposing the refresh button to list the history items, I worked out that history list was correct but the menus were not being updated when the list changed.

To solve this, I added an id to each menu that would trigger an update when its value changed. I needed something hashable that changed on every load, so I chose page.isLoading. I realize that this is updating the menus twice as often as needed, but it works and I don't think it is too inefficient.

The other feature here is the refresh button. If you've done any web dev, you'll be familiar with the technique of reloading from origin so that you get all the latest files instead of any cached versions. Hold down the Option key to switch the refresh button to reload from origin mode.

The only issue that I haven't tackled is opening links in new tabs or windows. On this site, all external links are set to open in a new tab and they just fail to load. I wonder is this something that a navigation decider could handle?

Summary

After waiting several years for this view to arrive, I am not disappointed. The SwiftUI team have done a great job of integrating SwiftUI and WebKit with some modernizations that WebKit is still missing.

For my personal use, I'll be updating Man Reader to use this web view. The find-in-page, custom scheme handling and scroll detection will be great. I also have to re-write the sections in my books that use WKWebView but that will be part of the general macOS/Xcode 26 update cycle.

All the sample code from this article is on GitHub so I encourage you to download it and see how it works. Make changes, and please let me know if you find any errors or can suggest improvements using one of the links below or through the Contact page. And if you found this article useful, please buy me a coffee.

SwiftUI for Mac 2025

2025-08-08T13:15:00Z

Almost every year, I write an article and a sample app, exploring the new features of SwiftUI, with particular emphasis on Mac app development. This year, it feels like the operating systems are becoming more uniform, so there is not a lot that's Mac-specific, but there are several new features that I am keen to explore.

Usually, I write an app that downloads images from HTTP Cats as well as demonstrating other features. This year, navigation hasn't really changed, so the HTTP Cats app didn't seem relevant. Instead, I've created a sample app that features some of the new aspects of SwiftUI for macOS 26.

Right now, I'm using Beta 4: macOS 26.0 Beta (25A5316i) and Xcode 26.0 beta 4 (17A5285i). And by the way, I love the new year numbering system so that all the operating systems are easily identifiable and even Xcode is in line with everything else.

UPDATES for Beta 5: 8th August 2025:

The new icon format is now fully backwards compatible. I've tested going back to macOS 11 and it still shows the new Icon Composer icon, even though I have an old-style icon in Assets.xcassets.
The glassProminent button no longer has a graphical glitch.
In the menus and main toolbar, I'm now using buttons with titles and system images instead of labels.

Here is a list of the topics I'm going to cover:

App icons

When you create a new project in Xcode 26, the old Assets.xcassets folder is still there and it still contains an AppIcon entry, but this is no longer the only way to create an app icon. The new icon format applies to all platforms, but this is an area where macOS has lagged behind iOS, so it's great to see all the systems using the same tool and format now.

Right-click on the Xcode icon in your Dock and choose Open Developer Tool → Icon Composer from the popup menu. This opens a new app for creating icon files. Create a new document and start by using the Document tab in the inspector to turn off watchOS and select macOS only:

Then switch back to the paint brush inspector to set the background. The app supplies a few fill options, so play around with them to see what you like. After that, the recommendation is to add one or two layers using SVGs.

Being graphically challenged, I searched for a free cat icon in SVG format and found this: https://iconscout.com/icon/cat-9608559. I dragged the file on to my icon and started playing around with it. The most useful controls in the main portion of the app are the one at the top for toggling on the grid - you can use the dropdown button on the right to switch between light and dark modes - and the three preview options at the bottom for toggling between default, dark and mono modes.

In the sidebar, select Icon to edit the background and select your image to change its properties. When working with the image, you can select whether options apply to all the versions or just the currently selected variant. This is useful as I found that the Liquid Glass effect looked great in dark mode but not in default mode with my gradient. I wasn't pleased with the mono version, but I'll see how it looks in real life. I can't imagine myself ever using mono icons on my Mac, but maybe that's just me.

Anyway, with my icon composed, I saved it as Cat.icon and then dragged it in to the project folder, copying it to my app target. Then, in General settings for the app target, I set App Icon to Cat without the extension. After running the app, I right-clicked on its icon in the Dock and selected Options → Show in Finder so I could see the icon fully. It looked pretty good in default mode, but when I used System Settings → Appearance to alter the icon style, it was clear that some of the options would require more work. But still, this was a good start.

If you want to support older systems and have an AppIcon set in Assets.xcassets, set the name of your Icon Composer file to AppIcon and your app will use the new one and fall back to the old one if required.

UPDATE: It appears that the new icon format is now fully backwards compatible. I've tested going back to macOS 11 and it still shows the new Icon Composer icon, even though I have an old-style icon in Assets.xcassets.

One nice touch is that if you select the icon file in the Xcode Project navigator, you get a button under the preview for opening the file in Icon Composer directly.

New look controls

With the introduction of Liquid Glass, many controls have a new look. In the sample app, I added a TabView to group the controls I wanted to test. Tabs have a title and an icon, as they did last year. The default style groups them in the toolbar, although since Beta 3, there is not a lot of transparency:

Notice how this has hidden the window title too.

Setting the tabViewStyle to sidebarAdaptable moved the tabs to a sidebar overlay and displays the window title. This looks much more like a standard sidebar and shows the tab icons too. I didn't like the way this looked last year, but I think it fits well with the new UI design. It's like a navigation sidebar but for a static list.

Not only does this style display the window title, but it also allows for a window subtitle using the navigationSubtitle modifier. And it displays a sidebar toggle button. There is a way to remove the sidebar toggle button if it's part of a navigation view, but that technique didn't work here. Despite the style name indicating that this style is adaptable, it only adapts to suit the window size in an iPad app.

Buttons

The main change for buttons is the two new options for buttonStyle: glass and glassProminent. Both styles can have a tint applied. I found that with certain tints, the glassProminent style button doesn't show the mouse down effect very distinctly. By default, the glassProminent style is tinted using the accentColor or the user's preferred theme color if chosen.

Toggles have a slightly new look. The button style gives a much more prominent indicator of the selected state, and the switch style uses the new Liquid Glass style which you can really see if you drag the switch instead of clicking on it.

In this screenshot, I've added a background to the view and tinted the glassProminent button. The background looks great with the tab sidebar but the title bar looks a bit jarring:

I wrapped the VStack containing the sample buttons in a ScrollView and that made the title bar transparent and allowed the content to scroll up behind the title bar. Toggle the background on and shrink the window to see this clearly:

~~Sometimes, this caused a graphical glitch in the glassProminent button, but I expect this is a beta issue.~~ This is fixed in beta 5.

Numbers

For entering numbers, I tested the Slider and Stepper controls. The Slider has the new Liquid Glass style thumb and a cute little bounce of the icons when you reach either end. The step parameter displays tick marks along the slider.

For the stepper, the up and down arrows are larger, which I think is a good idea - they were very small before. There's also a format parameter which has probably been there for years but I've never used it. What I like about it is that it displays the selected value in the format you specify and it's editable! I'm using percent in this example:

One slight oddity of the stepper showing an editable value is that it lets you enter a value that doesn't match the step size or is inside the range. In this example, I set the step size to 0.05 (5%) and then entered 13%. The arrow buttons still go up and down in 5% increments, so I got 18% or 8% depending on which way I clicked. Also, you can enter a non-numeric value, but it is ignored: tabbing out of the entry resets it, and the arrow buttons operate on your previous entry.

I added a view to test the various Picker styles, but they seem to be the same as last year, so for fun, I added two Text views with glass effects applied:

HStack {
  Text("Glass Effect - regular")
    .padding()
    .glassEffect(.regular.tint(colorForTint))

  Text("Glass Effect - clear")
    .padding()
    .glassEffect(.clear.tint(colorForTint))
}

They take their tint color from the picker selection. The clear style is slightly more translucent than the default regular style but doesn't have as glassy a border. Neither are as glassy as I expected, so I added a ZStack to apply a background of the same color only much less opaque and with a backgroundExtensionEffect to bring the color under the side tab bar:

ZStack {
  colorForTint.opacity(0.2)
    .backgroundExtensionEffect()

  VStack(spacing: 30) {
    // ...
  }
}

I expect it would look even more obvious with an image behind it. Actually, leaving it un-tinted on a color background is a probably the best way to see the effect:

And if you really want to see something unusual, put the app into the background. The three glass effects are all very different.

Web view

One of the most exciting additions for me was the new WebView. So many apps need to display web content, and until now, the only option has been to use NSViewRepresentable or UIViewRepresentable to bring in a WKWebView. The SwiftUI team has exceed my expectations with the features in the new WebView and it's going to need its own article, but I'll cover the two main ways to use it here.

Before working with any web view in a Mac app, you first need to turn on Outgoing Connections (Client) in the Signing & Capabilities for the target. Also, any SwiftUI view that needs to use WebView must import WebKit.

With those in place, here's my code for displaying my web site in a SwiftUI WebView:

import SwiftUI
import WebKit

struct WebDemo: View {
  let myPage = URL(string: "https://troz.net")!
  
  var body: some View {
    WebView(url: myPage)
  }
}

I have found that the only way to create an invalid URL from a string is to provide an empty string, so I am now happy to force-unwrap URLs. After that, I added a WebView and set its url to myPage:

As you can see, a contextual menu offers basic navigation options. So to display any web page off the internet, all you need is the URL.

To gain more control, initialize a WebView with a WebPage:

struct WebDemo: View {
  @State private var page = WebPage()
  let blank = URL(string: "about:blank")!

  var body: some View {
    WebView(page)
      .onAppear {
        page.load(html: html, baseURL: blank)
      }
  }

  let html = """
      HTML goes here (truncated for reading)
    """
}

I added a Picker to the toolbar for switching between the two web view sources. Here's the one showing a local HTML string:

Using a WebPage gives a lot of different options, but this shows the basic idea. I will tend to use a WebPage as that lets me track the loading state so I can show a progress indicator.

Rich text

When I'm asked if I recommend starting a Mac app with SwiftUI or with AppKit, I used to say SwiftUI unless your app uses lists with thousands of entries or long form text editing. SwiftUI lists have improved a lot in macOS this year, but I'm still not sure about that, however it looks like text editing can come off my AppKit list.

The key is to use a TextEditor but to link it to an AttributedString instead of a plain String.

@State private var text: AttributedString = ""

var body: some View {
  TextEditor(text: $text)
}

With an AttributedString, you get a lot of formatting options, although not as many as I expected. Setting bold, italic or underline is easy and so is changing the font size. I have not yet worked out how to change the font, except by pasting in text in a different font. At that point, the newly pasted font becomes one of the document's styles and can be applied to other portions of the text, but this can't be the only way. There is a Show Fonts menu item in Format → Font, but it is always disabled. Spell checking is also a bit erratic - it works really well if you open the spell checker dialog, but it doesn't work as you type.

I added TextEditingCommands and TextFormattingCommands to the menus, but they all seemed to be available through the contextual menu anyway. The Apple Intelligence Writing Tools are also available either through the Edit menu or the contextual menu.

For saving and loading the formatted text, I realized that AttributedString is a Codable type, so I used JSONEncoder and JSONDecoder to save and load as the view appears and disappears. This worked really well, whether I closed the editor window manually or just quit the app. This is just a quick hack for a single editor, but it could be the basis for a more complex app.

I think there will be more to discover with this, but it's already a lot better than before. And I haven't even started to get into tracking the selection or adding custom formatting.

Long lists

SwiftUI lists on iOS have always performed better than on macOS but this year, macOS is catching up. I added a List Demo window to test out various lengths of list. Before, I found that more than about 3,000 items in a list would cause performance issues, but now I can have 10,000 items and it still feels snappy, both for drawing, scrolling and selecting. With 50,000 items, it's still usable but selection is a bit slow. Interestingly, clearing the list is a big performance hit, but I'm not sure why. 500,000 items takes a very long time to draw. Scrolling is not too bad but selecting a new item takes several seconds. Clearing a list this big takes more than a minute.

I'm still not convinced that SwiftUI lists are the best way to display long lists, but I'm glad to see some performance improvements. I think my limit would be around 20,000 items, but I'd need to test on various machines.

Menu item icons

A new thing in macOS 26 and iPadOS 26 is icons attached to menu items. Most of the default menu items have icons, but what about my own?

Starting with the Window menu, I see the entries for my three demo windows and the main window:

Interestingly, the main window shows the title and its subtitle. I can't see how to add an icon to any of my windows in this menu, but the standard system items all have icons.

What about a menu with items to mimic the tab and toolbar buttons? I added a new Show menu and used a Picker to switch between the main window tab and buttons to open the demo windows. For each one, I used a Label instead of a Text view or a plain title. This let me assign an system image to each. I realize that this means the demo windows each have two menu items, but I wanted to experiment. And anyway, Xcode has two menu items to open the docs.

For the Picker items, I set the pickerStyle to inline and set labelIsHidden to true. I like this style as it gives me a picker at the top level of the menu, instead of in a submenu. For passing the selection to the window, I used @AppStorage which is not a great choice as it makes the choice apply to every open instance of the main window, but I didn't want to get bogged down here. If you're interested in a more complete solution, check out my article on The Mac Menubar and SwiftUI .

As you can see, I was able to show icons, check marks and keyboard shortcuts. I like this, but it can be over done. The WWDC video on the topic said that if you have related menu items like multiple New or Open options, you should only add an icon to the first.

On a side note, the + button for opening the Library has disappeared from Xcode's toolbar. I'm not sure if this is a bug or a feature but you have to use the View menu now, or the Shift-Command-L shortcut.

Concurrency

This is another thing that is not Mac-specific, but I feel it is important.

Last year, I sat out the change to Swift 6 and its strict concurrency checking. While I could get it to work by following Xcode's suggestions, I was left feeling that I was adding code to make the compiler happy, instead of code that actually made my apps better. This year, things are different. For starters, a new Xcode project has Approachable Concurrency turned on and has Default Actor Isolation set to MainActor. This means that everything is isolated to the main thread by default, but you can step out into a background thread if required.

The default Swift version is still set to 5, but I changed it to 6 for this sample app and had no compile-time warnings or errors. I did use @concurrent when generating the items for the list demo, but it turned out that it was the UI updates on the main thread that were slowing things down, not the data generation. Even so, I prefer the new approach and I'll probably be using Swift 6 from now on.

Toolbars

As you will have seen in the screenshots, I added a toolbar to ContentView with buttons for navigating to various demo windows. I wanted to try out the new floating toolbar features with spacers, so I copied the format from Apple's Landmarks app. This didn't work - all the toolbar items were still grouped together. This turned out to be a feature of using the sidebarAdaptable tab style. When I reverted to a standard tab style, the toolbar appeared with multiple groups as I expected:

There was no logical reason for separating these buttons, but I wanted to test using ToolbarSpacer(.fixed) and ToolbarSpacer(.flexible).

There are a lot of new toolbar positioning options that are not available in macOS. It used to be possible to identify a Catalyst app from its missing Settings menu item. I think that in the future, we'll identify them from toolbars floating in unexpected places!

Looking back at the screenshots from the web view section, the window without a toolbar already looks old-fashioned. Adding the toolbar made it look more modern.

Summary

The big thing this year is Liquid Glass. I have always advocated using default controls wherever possible and for apps that did this, most of the new look will be applied by re-compiling in Xcode 26. I'm not convinced that having content blurring behind a toolbar or title bar is a good idea - it ends up looking like a layout error much of the time. Of the new features, I'm most excited about the WebView so expect a separate article on that soon.

The sample app is available on GitHub: https://github.com/trozware/swiftui-mac-2025.

If you have any feedback about this article, please contact me using one of the links below or through the Contact page. And if you found this useful, please buy me a coffee.

WWDC 2025

2025-06-23T00:00:00Z

Apple's Worldwide Developers Conference is over for another year. As I wrote in an earlier post, I am not happy about Apple's management and their attitude to third-party developers, but there is no doubt that their own developers are doing some amazing work. I've been away and was then busy launching my new book, so I have not caught up with all the new announcements yet, but here are my initial impressions...

Version Numbering

This is great! Now I can finally tell how old a system is without having to look it up. iOS has always had numerical versioning but macOS, with its clever names picked by the crack marketing team, has been impossible to remember. And with Xcode adding a slightly different number, it was all just too confusing.

As regards using next year as the number, we developers need to remember that we live in a bubble of pre-releases. Most people won't get these systems until late in 2025 and they need to feel like they are getting a new system, not one that's already nearly out-of-date.

Liquid Glass

I've installed the first versions of the beta operating systems on a Mac and an iPad and so far, I'm really enjoying the new look. There are some accessibility issues that need fixing, but Apple has a good track record on accessibility, so I am sure they'll get there. Once we get used to the new look, I think we will find the look of old apps and icons jarring, but once they have all been updated, our screens will become more cohesive.

It's obvious that Apple is trying to make all their operating systems look and feel similar, and despite its lack of traction, visionOS has exerted a huge influence on the new design.

Xcode

Apart from the fact that ALL my screenshots are now wrong, I like the new look for Xcode. I'm a bit confused by the tabbing system and I haven't discovered a fast way to open two files side by side yet, but I'm sure I'll get used to it. As regards the new Settings window, I don't have a problem with it becoming more like the System Settings app - this seems a logical extension of Apple's increasingly uniform design. The only pane I find difficult to use is the Themes pane, which only shows 4.5 lines of samples, regardless of the height of the window.

I love the new #Playground feature! It gives a much clearer view of the data than an actual playground and seems to run faster. It's making me re-think how I'll approach some of my books and projects where I often start with experiments in a playground before creating the project itself. I was surprised when Xcode removed the Create New Playground option from the Welcome window a couple of versions ago, but now I see why.

I haven't explored the Coding Assistant much yet. Basically, Apple is admitting that their models are not good enough, so they've given us the ability to connect external models into Xcode. I'll have to see how well this works and how far I can get without yet another subscription. I'm not sure how much I'll use it, but it's nice to have some AI facilities incorporated into Xcode.

SwiftUI

There weren't a huge number of changes in SwiftUI, but there were some really good ones. I have been expecting a SwiftUI web view for years now, and it has finally arrived. After watching the video, I am very impressed and can't wait to start using it in several of my projects. They've done a great job of making a very complete and powerful web view.

Whenever I've been asked if I would recommend basing a Mac app on SwiftUI or AppKit, I always said SwiftUI unless you need long form text editing or have to display long lists. It looks like the text editing is now much better, although I haven't tried it yet. It was good to see acknowledgement of the fact that lists in macOS SwiftUI have not been as performant as in iOS SwiftUI and they appear to have improved this a lot. My initial tests were promising, but I need to do more in a real project to be sure.

Swift

Last year, Swift 6 introduced strict concurrency checking. I tried it out, but I felt like I was making changes that I didn't really understand in order to make the compiler happy. This is not a good way to produce code, so I dropped back to Swift 5 mode - which was still Xcode's default - and waited. It appears that concurrency is better implemented this year. I'm waiting to see how this pans out in the later betas, but this may be the year that I finally adopt Swift 6.

I'm also excited to try the new Foundation Models framework which gives us on-device AI that we can call in our apps.

App Icons

The new Icon Composer is fun to play with and it's going to be great not to have to make so many different sizes of icon. As someone who is artistically challenged, I now need to find a simple editor that will allow me to create simple shapes as SVGs for adding to the icons.

iPad Windowing

I'm still getting used to this. I have a smaller iPad so I don't tend to open more than one window at a time. I also prefer to use my iPad in portrait mode most of the time, which I don't think is what Apple's designers expect. Several apps end up with a series of skinny columns in this mode and Safari shows the iPhone version of web pages when I have the sidebar open. In Safari, I'm confused as to the best way to close the last tab. There used to be an X button that closed the tab and took me back to my Start Page. Now I either pull down the menu bar and select Close Tab or I open the sidebar, expand the Tabs entry and tap the weirdly offset X beside my tab name. Neither is as convenient as the old way, but maybe I'm missing something.

Developer Relations

Without doing anything to improve matters, it appears that Apple paid some attention to the dissatisfaction in the developer community. In the week before WWDC, they published two articles: one reporting how much money they give to developers and the other saying how safe the App Store keeps us.

This meant that they didn't start WWDC with the usual rave about how much they love their developers, which would have rung hollow this year. I also note that Tim Cook played a very minor role in the keynote, before handing it over to Craig Federighi. Is this a passing of the baton? Will we see Cook's resignation and Federighi's promotion in the near future?

Then we had the refusal of any Apple execs to be part of John Gruber's Talk Show Live. At first I assumed it was because they didn't want to have to face any questions about Tim Cook's political decisions or about Apple's AI failures. But then the execs did interviews with people who are far more likely to be hostile than Gruber, so it became apparent that this was just spite to punish Gruber for his single Apple-critical article in a sea of positive articles. This is petty and should be beneath them. I would be fascinated to know who made this decision.

Conclusion

I think there are exciting times ahead for us as developers. We need to adopt the new interface design - a task that is simpler for apps that use standard controls instead of custom views. Then there are new APIs to explore and further tests of AI coding to be done. As we progress through the beta cycle, I will experiment more and report on my findings.

If you have any feedback about this article, please contact me using one of the links below or through the Contact page. And if you found this useful, please buy me a coffee.

New Book: Escape from Tutorial Hell

2025-06-18T10:30:00Z

I've written a new book, and this one is quite different from my previous books. Instead of being a coding guide, this one is a guide to designing, building, shipping and maintaining real apps. It does include some coding, but the emphasis is on the process, not the code. As usual, I concentrate on macOS but the core principles apply to all Apple platforms.

You can buy the book from Gumroad and you can read the introduction and first chapter for free at Escape from Tutorial Hell Sample.

Go Beyond Coding: Build, Ship, and Maintain Real Apps

When learning to code, everyone hits a block at a certain point. You've read books and articles, watched videos, done tutorials and courses. You feel like you know what's being taught - the code is familiar and you can write small functions when told what the functions should do, but now what? How do you take that knowledge and use it to write a complete app? You're stuck in tutorial hell so how do you escape?

This book aims to fill in that gap and take you from a person who knows the basics of Swift and SwiftUI to a developer with an app that's designed, built, shipped and ready to be maintained.

Section I: Configuring Your Tools

Set up Xcode
Set up Git & GitHub

Section II: Designing the App

What will we build together?
Explore MapKit
Use test data to layout the UI
Include some Mac-specific features: icons, about, help

Section III: Setting up the Data Flow

Use a playground to test the API
Work out the data models
Import the models into the project

Section IV: Working With Xcode

Structure the project
Format the files consistently
Documentation
Debugging
Using a 3rd party library
Testing

Section V: Coding with AI

Code completion
Using AI chat

Section VI: Distributing the App

Distribution - App Store
Distribution - external

All the code and extra materials for the book can be downloaded from GitHub.

Thanks to...

Peter, my Language Engineer. Despite being in the middle of a huge move, he has managed to squeeze in the time to fix my commas and other grammatical blunders.

And of course, Tim, my constant source of support, advice, inspiration and many, many cups of tea and coffee.

Feedback

I would love to hear from anyone who has read the book, loved it, hated it, found an error or just wanted to say hi.

If you find any errors in the code, please let me know by opening an issue at the GitHub page.

You can contact me directly using any of the contact links at the bottom of this page or through the Contact page.

Apple Developer Relations

2025-05-20T23:53:52Z

Apple's Worldwide Developer Conference is just weeks away, but I'm sensing a lot of apathy in the community. The company's relationship with third-party developers is at a low point.

We all know that Tim Cook and his senior people will stand up at WWDC and say how much they value their developers and boast about how much money they've paid out to them. Being so enthusiastic about the money is very strange - it's like a rent collector bragging about how much money he has given to the landlord when all he's doing is collecting the rent and taking his cut. And it's difficult to take Apple's apparent enthusiasm for their developers seriously given their behavior over the rest of the year.

Trust is a hard thing to gain. Apple used to have the developers' trust but now they've lost it. It's much more difficult to regain lost trust than it is to gain it in the first place. I have read many reports of talented developers leaving the Apple ecosystem because they can't take it any more. This is bad for all of us, but particularly bad for Apple.

I don't imagine that anyone at Apple reads my blog, but I have thought of some things I think they could do to improve their relationship with their developers.

1. Open up iOS and all other systems to be like macOS

macOS has the Gatekeeper system which allows you to run apps from the App Store and from known developers. If you want to distribute a macOS app outside the App Store, you submit your app to Apple for notarization. This is not app review by a person, but an automated check for malware.

Apple states that iOS needs to be kept locked down to protect us, but macOS is not full of viruses and malware despite it's greater openness. Apple also states that the App Store and its review process protects users, but the most cursory glance through the iOS App Store shows that it's full of scam apps, copycat apps and apps with fake reviews.

If Apple were to open up iOS in the same way that macOS is open, it would immediately end a vast array of court cases against them, as well as avoiding the constant stream of fines from the EU which does not take kindly to Apple's habit of malicious compliance with their regulations. As a side-note, isn't it odd how Apple fights the regulations enacted by the democratically elected EU parliament, but falls over itself to comply instantly with the orders of the Russian and Chinese governments?

2. Give registered developers access to feedback reports

Every year, Apple releases betas of their operating systems to registered developers. They ask for all bugs to be reported using the Feedback Assistant app. This is a time-consuming process for developers and we are becoming increasingly reluctant to provide Apple with unpaid quality control services.

When you encounter a bug, first you have to make sure it's not in your code. You analyze it and then try to create a stripped down project that demonstrates it. Next, you file a report with as much detail as you can. This usually includes a system log, which used to be fine but now shows a dialog saying that although this may contain confidential information, it will be used to train AI! So much for confidential.

Once you submit the bug, the usual response is nothing. Even if the bug is fixed, you get no acknowledgement. It seems to be your responsibility to keep testing and close the bug once you can prove it's fixed. Very occasionally, you get a response. Sometimes, this is asking for more information. Other times, it's saying that the bug is closed as a duplicate of some other bug. The problem is that you have no access to the other bug, so now you're cut out of the loop entirely. Only once, in all my years of filing bugs, have I received a real human response. Filing bug reports feels like a giant waste of my time.

Now imagine that the bug database was open to all registered developers. When you encounter a bug, you could immediately search to see if anyone else had reported it. If so, you could mark it as "I see this too" and maybe add more information. This would be much faster and more efficient.

From Apple's point of view, it would also be vastly more efficient. Instead of having to correlate many reports about the same issue but worded and tagged differently, they could have a much smaller and more manageable database of reported bugs, with a better indication of how widespread each bug was.

To me, this seems like a win-win situation. I have trouble coming up with a reason for Apple to keep the bug reports secret. Do they think the sheer number of them is embarrassing? Are they afraid of people exploiting the bugs? Either way, having a more efficient system would be better.

3. Improve the app review process

This has got to be the most frustrating part of an Apple developer's life. Apple's app review process is a capricious mess and every time you click Submit for Review, it feels like spinning a roulette wheel. Even apps that have been on the App Store for years are not immune to this. Some apps get blocked for the most bizarre reasons, but the same app will be approved without issue for a different platform or on a different day.

I think the app review team is probably under-staffed and without clear guidelines. It also appears that the larger development companies are allowed more latitude than the independent developers.

I would suggest that app review be mainly a check for malware and to confirm that the app doesn't crash on various hardware and software combinations. After that, there should be checks to see if the app is a scam or an obvious copycat.

Apple's reviewers are not familiar with everything that can be done on an iPhone, iPad or Mac and I don't expect them to be. The problem is when they reject apps purely because they don't understand them.

And while I'm on the topic of app review, how about some validation of App Store reviews before they go online? It wouldn't take a very sophisticated system to detect when an app suddenly receives hundreds of reviews, all virtually identical.

I could go on and on, but these are my top three suggestions for Apple to improve developer relations. What are yours? If you could speak to the Apple board for one meeting, what would you say?

Let me know using one of the links below or through the Contact page. And if you found this article interesting, please buy me a coffee.

Man Reader 2.1

2025-04-28T23:23:53Z

I've just released Man Reader 2.1. Visually, this is very similar to the previous version, but there are a lot of quality of life improvements under the hood.

The most important feature of this release is that the app no longer crashes when typing fast into the search field. Sorry it took me so long to fix this, which was due to the way the app communicated between the AppKit list in the sidebar and the SwiftUI search field. SwiftUI lists have become a lot more performant, so I put a lot of effort into trying to make the entire app SwiftUI but in the end, it was just too sluggish so I reverted to AppKit, but with added traps to avoid crashing.

Here is a list of the other improvements:

Use Command-L to focus on the man page list at any time. Shift-Tab will focus on the main search field. Tab cycles through everything including the man page itself, so if it looks like nothing has focus, you can use the arrow keys to scroll the page.
The menus correctly identify and target the front most window and tab - tabs were not always correctly identified before.
Pages with Notes is a new category in the Sections menus.
The full path to the selected man page is displayed in the bottom status bar.
In-page searching is more efficient and searches for 2 characters instead of waiting for 3.
Accessibility support is improved with more complete VoiceOver descriptions of controls.
The selected section for each window or tab is now remembered between launches.
The app quits when the last window is closed. I'm not sure if I should make this an option, so if you have strong feelings about this, please contact me.
Pages from non-standard locations now have the correct bookmarked scopes to appear.
The man page display loads faster and no longer scrolls sideways or flickers.
The list of man pages has the option to use alternating row backgrounds.

My experiments with using SwiftUI lists were interesting. They have definitely improved a lot over the last year, but they still can't compete with AppKit lists once you get more than about 5,000 entries. Maybe this years updates will change that as I love the simplicity of using SwiftUI.

Swift Measurements

2025-04-16T09:47:17Z

Recently, I was working with units and unit conversions in Swift. After a while, I then remembered that Swift has a built-in structure for doing this: Measurement. This article is an introduction to the power and usage of Measurement.

To use a Measurement, you initialize it with a value and a unit type. The value must be a Double and the unit type specifies the type of measurement and the scale of the units. Here's an example of specifying a length in centimeters:

let length = 1234.56
let lengthMeasurement = Measurement(value: length, unit: UnitLength.centimeters)

There are many supported unit types. They all begin with Unit, so start typing and see what you get. Once you have the unit type, enter a period and code completion will suggest all the possible units for that type. There's a huge range, including some very obscure ones:

I'm running this in a playground and when I print lengthMeasurement I get 1234.56 cm as you'd expect.

The magic happens when you start formatting the Measurement.

let formattedLength = lengthMeasurement.formatted()
print(formattedLength)

Running this code gave me 12 m which is a much more readable version.

Playing around with larger and smaller values, I got it to show cm, m or km. It even added in the thousands separator when I went to a really big number. Strangely, I couldn't get it to use a smaller unit than the one I started with. Even with 0.00001 cm, it still didn't use mm, so I guess the lesson there is to start with the smallest units you want to show.

Now for the super cool bit. I went into System Settings -> General -> Language & Region and changed Measurement system from Metric to US. Running the playground now, my original value of 1234.56 cm gave a formatted value of 41 ft! A larger value gave me mi (miles) and a smaller one showed in (inches). So the formatting uses the system setting to choose what units to show. There's no need to convert measurements to suit your user's locale - a formatted Measurement does that for you!

Converting

But what if you want to show the conversion? I like to cook and most recipes online assume the everyone uses Fahrenheit for their ovens. My thanks to all the recipe writers who show Celsius as well, it's greatly appreciated.

As you can imagine, I spend some time in the kitchen talking to my wrist so that my Apple Watch and Siri can do the conversion for me:

In this screenshot, the result of my query shows both Fahrenheit and Celsius. Let's try that in the playground.

Firstly, Measurement can do conversions, like this:

let fahrenheit = 400.0
let fahrenheitMeasurement = Measurement(
  value: fahrenheit,
  unit: UnitTemperature.fahrenheit
)
print(fahrenheitMeasurement)

let celsiusMeasurement = fahrenheitMeasurement.converted(to: .celsius)
print(celsiusMeasurement)

This prints 400.0 °F and 204.44444444444832 °C. If you need to access the numeric result of the conversion, you can get the Double using celsiusMeasurement.value.

But as you'd expect, if you use formatted, both versions are shown in Celsius because that's my system setting:

print("\(fahrenheitMeasurement.formatted()) = \(celsiusMeasurement.formatted())")

This prints 204.444444°C = 204.444444°C which while factually indisputable, is not at all helpful. And it shows far too many decimal places - my oven is not that accurate!.

Here's where we can use a MeasurementFormatter which allows us to specify several parameters:

let formatter = MeasurementFormatter()
formatter.unitOptions = .providedUnit
formatter.numberFormatter.maximumFractionDigits = 0
formatter.unitStyle = .medium

With this in place, I tried:

let formattedFahrenheit = formatter.string(from: fahrenheitMeasurement)
let formattedCelsius = formatter.string(from: celsiusMeasurement)

print("\(formattedFahrenheit) = \(formattedCelsius)")

And got 400°F = 204°C which is even more useful for cooking than the display my watch showed.

The key for showing both temperatures was to set the unitOptions to providedUnit which made it use the unit specified in the Measurement. After that, numberFormatter is a standard NumberFormatter with all its options. unitStyle can be short, medium or long. The default is medium but I specified it so I could experiment with the different styles.

So any time you find yourself working with units and conversions, give Measurement a try. It handles localization, conversion and formatting for you.

If you have any feedback about this article, please contact me using one of the links below or through the Contact page. And if you found this useful, please buy me a coffee.

Moving to Eleventy

2025-03-19T04:15:33Z

I have been running this blog since 2014 and it's seen several major changes along the way. I started with WordPress but it felt slow and clumsy, so in 2015 I entered the world of static site generators and transferred to Jekyll. That worked for a couple of years until Jekyll was updated from version 2 to version 3 which broke my setup. At that point I converted to Hugo which has worked fine for more than six years.

But as with Jekyll, updates broke my site and I didn't know enough about how it all worked to fix it. As a temporary measure, I reverted to an old version of Hugo which got everything working again, but this was not a long term solution.

After considering a number of options, I decided to try Eleventy and that's what you're looking at right now.

What Were My Criteria?

My requirements for the site haven't changed much over the years. I still want a simple, lightweight site that is easy to maintain and easy to update:

Responsive
Fast with minimal client-side Javascript
Blog style:
- front page with recent posts
- tags
- archives
Searching within the site
Written using Markdown
Static pages for books and apps
Contact form
Syntax highlighting
Light and dark themes
Social links
JSON Feeds

Why Did I Choose Eleventy?

At first, I was looking for an option like Jekyll or Hugo that provided themes that I could plug my content into. After a while, I realized that this was what had caused my problems with the previous generators: they were black boxes, written and configured in languages that I didn't know, so I didn't know how to fix them when things went wrong.

While I was daunted by the prospect of having to create my own theme, I was very attracted by the idea of using a generator that I understood, with a site structure that I could control completely.

Given my language preferences, I was looking for a generator that used Swift, Python or Javascript. I asked for advice on Mastodon and got a number of recommendations, but in the end I decided to try Eleventy for several reasons:

It's written in JavaScript, which is a language that I'm familiar with.
It has a large and active community, with lots of articles, tutorials and videos available.
There are a lot of plugins available both from Eleventy and from third parties.
I can deploy it automatically from Github using CloudFlare Pages, just like I did with Hugo.

How Did I Learn Eleventy?

I started on the Eleventy website and then watched the Build an 11ty Site in 3 Minutes video for a quick start guide. This was a bit like the tutorials on how to draw an owl: draw a circle, add another circle, now draw the rest of the owl.

After that, I found a great guide at Learn Eleventy. I got stuck at lesson 18 when I couldn't get gulp to work, but by that stage I had learned enough to be able to set up my site, configure the folders and files and use the templates to create the pages that I needed.

The key for me was to accept that my first draft was going to be HTML only, with no styling. This was completely different to Jekyll or Hugo where you start by choosing a theme and then adding your content, so it felt a bit strange at first, but following the example at Learn Eleventy, my first goal was to get my content appearing with my preferred navigation structure.

Here's how my files and folders are organized:

At the top level, I have these folders and files:

node_modules: where npm stores all the required modules, including eleventy and all of its dependencies.
public: where the generated files are stored.
scripts: where I keep my custom Python scripts for bulk edits and configuration.
src: where the source files are stored - posts, scripts, images, etc.
notes.md: a file to help me remember what I still need to do.
package-lock.json: a file that records the exact versions of installed modules.
package.json: the configuration file for npm.
README.md: for display on the GitHub page.

The main action is in the src folder, where I have these folders:

_data: JSON files with data to fill in the navigation menu, footer links, books and apps pages.
_includes:
- layouts: Nunjucks templates that are used to create the pages.
- partials: Nunjucks templates that are used for sections of the pages.
apps: Markdown files for each app page.
books: Markdown files for book pages and samples.
feeds: Nunjucks templates for the RSS feeds: XML, Atom and JSON.
filters: Javascript helper functions.
images: all the images except the favicon.
js: client-side Javascript files.
post: Markdown files for each post, with a subfolder for each year.
scss: the SCSS files, which are compiled to CSS.
styles: the CSS files, generated from the SCSS files.

The src directory contains a Markdown file or Nunjucks template for each page, the favicon images and the invisible .eleventy.js file that ties everything together. The Markdown files contain nothing but front matter that points to the relevant layout and adds pagination information if required. Eleventy can use many different templating engines, but the tutorial I followed used Nunjucks and having used Handlebars for another project, this was reasonably familiar territory.

One key concept for me was to realize that a filter in eleventy is not the same as the filter function in Javascript or Swift. It's easier to think of it as a formatter that takes data and returns all or part of it in a different format. For example, the info at the top of each post shows the date, the number of words and an estimated reading time. That's all produced by a filter written in JavaScript.

Collections are an incredibly powerful feature of Eleventy, especially when combined with pagination. I'm still learning how to use them effectively, but they allow me to assemble the posts for the main page and for the archives, as well as the list of unique tags for the tags page.

I'm particularly pleased with the Archives page where I wanted to add a year as the header for each year's posts. In the template, I set a variable to hold the year, then use a filter to get the year of each post. If the year is different from the previous post, I add a new header to the list.

I'm not so thrilled with the Tags page, but hopefully I can improve it. The problem is that Eleventy is excellent at collections, but not at collections of collections. I wanted a collection of tags, then a collection of posts for each tag. I haven't worked out how to do this yet, but I have an interim solution that works.

Plugins

I've used a few plugins although I tried to keep the number down and use my own JavaScript where possible.

@11ty/eleventy-plugin-syntaxhighlight to highlight the code using Prism.js
@aloskutov/eleventy-plugin-external-links to make external links open in a new tab.
@11ty/eleventy-plugin-rss to generate the RSS feeds.
pagefind to add search to the site.

If anyone uses an RSS reader for this site, I'd love to know if the formatting works for you. The various links are in the footer.

What Do I Miss From Hugo?

In Hugo, I could run the command to add a new post and it would fill in the template for me, with the basic front matter, a header and a  marker to separate the summary from the full post. For Eleventy, I wrote a Python script to create a new post. For displaying the first few paragraphs of a post on the home page, I wrote a filter that looks for the  marker and displays the text up to that point. If there is no marker, it displays the first few paragraphs, up to a certain word count.

Tags were better handled in Hugo, but I haven't finished exploring different ways to do them in Eleventy.

Hugo has a draft server mode that includes posts marked as draft. My collections exclude draft posts so I have to toggle this setting when writing, but I expect I can get around this using environment settings.

It was easy to generate a table of contents for a post in Hugo as it automatically made all headers into anchor links. I had to fix this manually for the existing posts with a ToC.

My Tips for Eleventy Beginners

If things don't appear to be working, stop the eleventy development server and re-start it. I think if you make too many mistakes, it gets lost and gives up reporting them. When it is showing errors, they are usually quite helpful, pointing to the exact line of code that is causing the problem.

Don't be afraid to trash the output folder and start again at any time. This is especially important if you've deleted or moved any files as Eleventy will not automatically delete the files in the output folder.

If you're using SASS or SCSS, compile the CSS into a folder inside the src folder and then use addPassthroughCopy to copy these files to the output folder. I made the mistake of compiling the SCSS files directly into the output folder, but when I uploaded the site to CloudFlare, it ran the eleventy command to re-generate the site but didn't re-compile the SCSS files.

Sometimes, the live server refresh doesn't update the styles, so refresh the page manually before panicking.

The Plain HTML Site

With the structure in place, and all my old posts imported, here's what the home page looked like:

And here's what a post looked like, using Prism.js for syntax highlighting:

But now I was stuck. I'm not a complete beginner when it comes to CSS and I knew the sort of look that I wanted, but I knew it would take a lot of my time and effort to get there. However, I use Cursor - The AI Code Editor as my editor so I decided to see how its integrated AI could help me.

Styling With AI

Here was my first prompt:

Create a responsive css theme with light and dark modes. It should have a header with the navigation and a footer with links and copyright notices. The home page has a list of blog posts summaries and each post has its own page. The site is mainly text with some images. Use a sans serif font and a maximum width.

As context, I pointed it at the entire src folder and I added web search to help it find the right information.

This was amazingly successful, although it took a lot of tweaks and edits. What I liked was that the AI - claude-3.5-sonnet - told me what it was doing at each step. At the beginning, it listed some web sites that it had consulted about responsive design and then it generated a lot of SCSS. Then it told me what it had done and what I needed to do to finish the job.

One of the tasks listed was:

Navigation should use the nav element with proper structure

I didn't know what the proper structure was, so I asked the AI to do it.

After that, I spent 3 - 4 hours talking to the AI, tweaking the styles and getting the layout just right. It was fascinating. I felt like a designer leaning over the shoulder of a CSS expert, although a real-life expert would have become quickly exasperated by my demands!

At times, I would ask it to revert the previous change and try something different. Other times I would accept the changes but ask for a modification.

At one point it got a bit cheeky about my existing code:

I'll modify the apps.njk template to match the side-by-side layout style we created for books. I'll also fix the unclosed </li> tags in the current file.

Once I had the basic styling, here are some examples of the more interesting things I asked the AI to do:

Create a capsule shape for the tag buttons.
Generate Prism.js styles for the code blocks, so that they looked similar to Xcode's default dark and light themes.
Add a rotation effect to the dark/light toggle with animation.
Implement a copy button for the code blocks.

Importantly, I was able to understand all the SCSS the AI generated.

Context is really important. In order to get the best results out of any AI, you have to tell it where it should start. As an example, I got my books page styled in a way that I liked, and then gave the AI the books page layout file and the app page layout file and asked it to apply a similar style to the apps page.

Also, in many cases, it was faster and easier for me to edit the SCSS manually, than to ask the AI.

I'm sure that I'll continue to refine the styles over time, but I'm very happy with what I have right now. Using AI to generate the styles was a lot of fun and really demonstrated to me how I can use AI to help me with my work.

The Result

You're probably reading this page on my site, so you can see how it looks now. If you're at dev.to or some other location, you can see my version at https://troz.net.

I used Lighthouse Metrics to check the performance of both the old site and the new site. Here are the results:

For the old site, I got the following scores:

Performance: 69%
Accessibility: 95%
Best Practices: 96%
SEO: 100%

For the new site, I got these scores:

Performance: 100%
Accessibility: 100%
Best Practices: 96%
SEO: 100%

The Best Practices score is less than 100% because apparently some errors are being logged to the console, but I'm not seeing them so I'm not sure what's causing that.

But I am thrilled with the improvement in every other metric.

Deploying to Cloudflare is also faster - about 35 seconds compared to 48 seconds for Hugo. I think this is probably due to having to download two repos for Hugo - mine and the theme's.

One aspect that I'm really pleased with is the site search. Eleventy uses Pagefind so I started there and found it easy to set up. This is much better than the custom DuckDuckGo search I had embedded on the old site. I'm using the default Pagefind styling for the search results, but I may change that later.

If you find any bugs or any styling errors, please let me know. And if you would like any further information about how I built the site, please ask. You can contact me using one of the links below or through the Contact page.

macOS Apprentice Update

2025-03-06T11:22:21Z

The second edition of macOS Apprentice has been released!

If you're a beginner or near-beginner who wants to start learning Swift, SwiftUI and AppKit for building Mac apps, then this is the book for you.

This edition has been updated for Swift 5.9, macOS 15 and Xcode 16.2.

If you're new to macOS and Swift, or to programming in general, learning how to write an app can seem incredibly overwhelming.

That's why you need a guide that:

Shows you how to write an app step-by-step.
Uses tons of illustrations and screenshots to make everything clear.
Guides you in a fun and easy-going manner.

The book consists of four sections:

Section 1: Install Xcode and learn the basics of programming in Swift. Experiment with several different ways to execute Swift code on your Mac.

Section 3: There are still a number of tasks where AppKit works better than SwiftUI. In this section, build an AppKit app to browse movie data from IMDb, the online movie database.

Section 4: Add AppKit to your SwiftUI app and add SwiftUI to your AppKit app in order to add some finishing touches to both of the apps from the previous sections.

You can read more details of the book contents in the Introduction.

If you are a more experienced iOS developer who wants to branch out into macOS development, then my previous book - macOS by Tutorials - might be a better fit, although I think you could still learn a lot of Mac app tips and tricks from this one.

Where Can You Find the Resources?

You can read the book online at kodeco.com as part of a Kodeco subscription. The introduction and the first chapter are free to read.

All the code and extra materials for the book can be downloaded or cloned from GitHub.

For support, to ask questions or to report any errors, please go to the forum.

Thanks to...

This book was made possible by an awesome team. There were a lot of people involved, but I want to give special thanks to:

Richard Critz, the wonderful editor who had the unenviable task of fixing my grammar.
Audrey Tam and Ehab Amer were the amazing tech editors who had to make sure that it all worked. Audrey also contributed the first chapter on installing and setting up Xcode.

Feedback

I would love to hear from anyone who read the book, loved it, hated it, found an error or just wanted to say hello.

You can contact me directly using any of the contact links at the bottom of this page or through the Contact page.

The Mac Menubar and SwiftUI

2025-02-17T07:16:34Z

When you create a Mac app using SwiftUI, you get the standard Mac menubar by default. The commands modifier lets you customize the menu bar, either by adding, replacing or removing items and menus. You can even add some presets which give a consistent way to add groups of common items.

The problem comes when you want to communicate back to the SwiftUI views from the menubar. How can you direct your menubar commands to the correct destination? AppKit uses the responder chain, so it effectively broadcasts any menubar message until something handles it. This might be an edit field, a view, a window or even the app itself. SwiftUI doesn't work like this, but I've explored multiple possibilities for passing messages from the menubar to the active window.

My usual approach is to use NotificationCenter to send messages. This takes a few steps to set up.

NotificationCenter

Start by defining a name for your custom notification, like this:

extension Notification.Name {
  static let menuSelected = Notification.Name("menuSelected")
}

Then, in your menu item's action, post the notification like this:

NotificationCenter.default.post(name: .menuSelected, object: nil)

Add an object if you want the notification to be more specific. This allows you to combine several menu items into a single notification name.

Now, you need to add a listener as a property of your SwiftUI view, receiving it on the main run loop so that UI updates are handled correctly:

let menuSelectedNotification = NotificationCenter.default
  .publisher(for: .menuSelected)
  .receive(on: RunLoop.main)

Finally, add an onReceive modifier to your view, with a closure to process the notification:

.onReceive(menuSelectedNotification) { notification in
  // process the notification, checking for the object if you added one
  if let stringObject = notification.object as? String {
    // do something with the string
  } else {
    // do something else
  }
}

The main issue with this is that it broadcasts the message to all instances of the view, so if you have multiple windows open and displaying this view, they'll all receive and process the notification. There are cases where this will be valid - maybe changing the theme of the complete app or setting something else which effects every open window. But mostly, you only want to send the message to the active window.

You can improve this by using the appearsActive environment value to see if the current view is active. Truncated for ease of reading, ContentView now looks like this:

struct ContentView: View {
  @Environment(\.appearsActive) private var appearsActive

  let menuSelectedNotification = NotificationCenter.default
    .publisher(for: .menuSelected)
    .receive(on: RunLoop.main)

  var body: some View {
    // UI defined here

    .onReceive(menuSelectedNotification) { notification in
      guard appearsActive else { return }
      
      if let stringObject = notification.object as? String {
        // process the new string
      }
    }
  }
}

The onReceive closure starts with a guard to check that the view is active. If it's not, the closure returns immediately.

Note: You may have used controlActiveState for this in the past, but it has been deprecated in favor of appearsActive which is easier to use as it's a Boolean instead of an enum.

This looks like exactly what we need, but there's a problem. If you merge multiple windows into tabs, the appearsActive property will be the same for all the tabs in the window.

So basically, this only works if you disallow tabbing for your windows, so it's not a complete solution.

Failed Attempts

My next attempt was to step into AppKit and have NSApp send a selector through the responder chain. This looked like it should work, but I could never get it to, and it looked clunky

Looking though an Apple tutorial, it appears that they prefer to use @FocusedBinding and focusedValue. This worked in their sample app, but there was something different about my data structure that meant it never worked for me, even after extracting my data into a separate data type.

Then I came across focusedSceneObject. This required me to create an @ObservableObject data type, but then it worked perfectly, even in tabbed windows. But this is not viable going forward, as I have switched to using Observation. However the docs did point me in the right direction.

Success at Last

After a bit of research and a lot of testing, I finally came up with a complete solution, using @FocusedBinding and focusedSceneValue.

First, you need a data object to handle your menu messages. This can be a struct or an observable class. My sample app has both in Symbol.swift with one commented out, so you can test this. The data model has properties for an icon and a color and you can also have it choose a random icon and color. For convenience, it has two static arrays to provide the names and colors for the menus and pickers.

struct Symbol {
  var name = "globe"
  var color = Color.blue

  mutating func chooseRandomSymbolAndColor() {
    // choose random values
  }
}

Or as a class:

@Observable
class Symbol {
  var name = "globe"
  var color = Color.blue

  func chooseRandomSymbolAndColor() {
    // choose random values
  }
}

Next, you need to extend FocusedValues so it has a key to your data type. This has become a lot less verbose with the new @Entry macro. The binding must be to an optional:

extension FocusedValues {
  @Entry var selectedSymbol: Binding<Symbol>?
}

In your ContentView (or wherever you're using this property), set the data property as the focusedSceneValue for this key:

struct ContentView: View {
  @State private var symbol = Symbol()

  var body: some View {
    VStack {
      // UI defined here
    }
    .focusedSceneValue(\.selectedSymbol, $symbol)
  }
}

The last step is to use this in the menu (again, truncated for brevity):

@main
struct MenuDataApp: App {
  @FocusedBinding(\.selectedSymbol) var selectedSymbol

  var body: some Scene {
    WindowGroup {
      ContentView()
    }
    .commands {
      CommandMenu("Symbol") {
        Menu("Symbol") {
          ForEach(Symbol.names, id: \.self) { name in
            Button(name == selectedSymbol?.name ? "✔︎ \(name)" : name) {
              selectedSymbol?.name = name
            }
          }
        }
        .disabled(selectedSymbol == nil)

        Button("Random") {
          selectedSymbol?.chooseRandomSymbolAndColor()
        }
        .keyboardShortcut("r")
        .disabled(selectedSymbol == nil)
      }
    }
  }
}

The important features here are the @FocusedBinding property at the top and the fact that the menu items use optional chaining to access this property if it exists. If you have no open windows, this will be nil, otherwise it will point to the instance of the data property in the active window.

To improve the user experience, I added a disabled modifier to the menus and the button so that the menus are not active unless there's a valid selectedSymbol. Unfortunately, you can't disable an entire CommandMenu.

The wonderful part of this is that it works with windows and tabbed windows. Hurray!

Showing the Current Selections in the Menu

The ugly part is that the menu item indicating the current choice is set to show a check mark manually, instead of using the standard menu checkmark. But you can't bind a @FocusedBinding property to a Picker as it's selection.

My solution was to use a Picker with a local state property. Then I track for changes to the @FocusedBinding property and to the local property. When either changes, the other is set to match, remembering that the @FocusedBinding property may be nil: It was important to add the onChange modifiers to the ContentView. I tried them on the Picker first, but they only got updated as the menu opened.

I've updated the project, thanks to Malcolm Hall who added this comment:

onChange is just for external actions. For linking states its Binding and it has an init that handles conversion from optional, that allows you to access the keypath binding to the symbol's colour and name you were missing.

Now, the picker code looks like this (I omitted the color picker to make for a shorter and more readable code block):

if let selectedSymbol = Binding($selectedSymbol) {
  Picker("Symbol", selection: selectedSymbol.name) {
    ForEach(Symbol.names, id: \.self) { name in
      Text(name)
        .tag(name)
    }
  }
  .pickerStyle(.inline)
} else {
  Text("Symbol")
}

I also made the pickers inline for better visibility. With this version, I really like the way the menus use a Text view to display the header with no possible selections, when there's no selectedSymbol.

So this is my new technique for communications between the menubar and SwiftUI. It takes a bit of setting up, but then it works really well. For a more complex app, I might need more bindings, or I could merge the relevant data objects in a larger struct or class.

Going back to Apple's example which used @FocusedBinding and focusedValue, I think this worked because they had a NavigationSplitView and the focused value was the selected item, so there was an object to focus on. From the Apple's docs for focusedSceneValue:

Use this method instead of focusedValue(::) for values that must be visible regardless of where focus is located in the active scene.

This is what solved it for me because there was no real focus element in my view. I was able to go back to the Apple sample app and get it working using focusedSceneValue instead of focusedValue, so I think this is a solid technique.

I'm sure there are other ways to do this, so if you have an alternative method or can suggest any improvements to my technique, I'd love to hear about it.

The Code

The sample project is available on GitHub. Check out the main branch for the final version of the code, but explore the other branches to see my experiments along the way.

Here they are, in order of progress:

basic_ui: The starter version of the app with the UI set up for selecting an icon and a color.
menu: Menus added but not working.
notifications: Using NotificationCenter to send menu messages.
focusedSceneObject: Works but only with @ObservableObject data types.
main: The technique I've settled on with @FocusedBinding and focusedSceneValue

You can contact me using one of the links below or through the Contact page. And if you found this article useful, please buy me a coffee.

macOS by Tutorials 3.0

2024-12-23T04:22:15Z

macOS by Tutorials Edition 3.0 is now available!

The book is available for purchase or update at Gumroad.

If you previously bought the first edition of this book from either Kodeco or Amazon, please email me for a 50% discount code.

If you already bought the second edition from me via Gumroad, this is a free update that you can download from your Gumroad library.

Click the image for more details, and if you’d like to check out the start of the book including the table of contents and the first chapter, you can read it online at macOS by Tutorials Sample.

The major changes in this edition include:

Updated projects to include new features introduced in macOS 15 Sequoia and Xcode 16.
More granular chapter organization. The table of contents is now more of an index so you can find the sections you need, with each chapter being more focussed on a single topic.
All projects use Xcode's folder structure.
Tabs use the new syntax.
Previews use the new @Previewable macro.
Tracking the active window uses the @Entry macro.
The app in section 4 demonstrates the new windowing options.

If you already own the book and have enjoyed it or found it useful, I'd really appreciate it if you could leave a rating or review at the book's page in your Gumroad library.

Swift Format in Xcode

2024-11-06T06:29:20Z

In Xcode 16, Apple quietly introduced the ability to format your Swift files using Swift Format. I'm a long-time user of SwiftLint, but having such a tool built into Xcode would be a great convenience, so I decided to give it a try. Here is my description of why I use such a tool, how well it works compared to the alternatives, and how I configured it for my own purposes.

Why Format Your Code?

I have always been a big fan of consistent code formatting. As I wrote years ago in Consistent Swift Style, we read code far more often than we write it, so anything that improves readability is great for productivity, even for a solo developer. If you work as part of a team, consistency is even more important as you don't want other people to have to spend their valuable time trying to understand your code, or the other way round.

I have been an editor and writer for Kodeco (formerly raywenderlich.com) for many years and with so many different authors on the team, it was crucial for there to be a consistent style. This is why I always use SwiftLint in my Kodeco projects, using the configuration file found here: Kodeco Swift Style Guide. For my own projects, I vary this configuration slightly, but I always use SwiftLint. Similarly, when doing web development, I always use Prettier which integrates beautifully with Visual Studio Code so that my files are automatically prettified on save.

Swift Format

The name Apple chose is logical but confusing. I had experimented with Nick Lockwood's SwiftFormat a few years ago, but found that I preferred SwiftLint, so I stuck with the latter. When I saw that Xcode included Swift Format, I assumed that they had acquired Nick's formatter but it appears to be a different tool, officially called swift-format. It's downloaded as part of the toolchain when you install Xcode 16, so no further installation is required.

Test Code

I created a test project in Xcode 16 and wrote a chunk of Swift and SwiftUI for testing. I deliberately formatted it badly so as to see which formatter did what to it, so don't hate me for this nonsensical code:

import SwiftUI

struct ContentView: View {
  @State var data = [String]()

    var body: some View {
      NavigationSplitView(sidebar: {
        List(data, id: \.self) { row in
          Text(row)
        }
      }, detail: {
        Text(someComputedProperty)
      })
        .onAppear(perform: createTestData)
    }

  func createTestData() {
    data = Array(0 ..< 1000).map { "Row #\($0)" }


  }

  func downloadData() {
    let address = "https://zenquotes.io/api/quotes"
    let url = URL(string: address)!
    let task = URLSession.shared.dataTask(with: url) { data, response, error in

      if let data = data,let string = String(data: data, encoding: .utf8) {
          print(string)
        }
      }

    task.resume()
  }

  var someComputedProperty: String {
    """
    This is a multiline string,
    that is a computed property which can be tricky to format.

    It has nothing to do with the list on the side, but I wanted to see how swift-format would handle it.
    """
  }

  func longFunctionNameThatDoesSomething() {
    print("This is a long function name that does something")
    FunctionwithLotsOfArguments(arg1: 1, arg2: 2, arg3: 3, arg4: 4, arg5: 5, arg6: 6, arg7: 7, arg8: 8, arg9: 9, arg10: 10)
  }

  // Yes, this deliberately starts with an uppercase letter
  func FunctionwithLotsOfArguments(arg1: Int, arg2: Int, arg3: Int, arg4: Int, arg5: Int, arg6: Int, arg7: Int, arg8: Int, arg9: Int, arg10: Int) {
    print("This is a function with a lot of arguments")
  }
}

#Preview {
    ContentView()
}

Some comments on this code:

I use 2 space indentation, but Xcode creates files with 4 spaces, so indentation is a mess.
The NavigationSplitView is not using multiple trailing closure syntax.
I've left unnecessary blank lines in the code.
The networking code is not what I would write, but it was suggested by GitHub Copilot.
Multi-line strings are often difficult to format.
The two functions at the end really need to spread over more lines and the last one should start with a lowercase letter.

Using Other Formatters

Before checking out Xcode's swift-format, I want to try SwiftLint and Prettier. I have SwiftLint installed already, so I can run it from the Terminal. After I used cd to step into the project's code folder, I ran:

swiftlint ContentView.swift

This is using the default SwiftLint configuration and gave this result (I deleted the folder path but you'll still have to scroll sideways to read this.):

Linting Swift files at paths ContentView.swift
Linting 'ContentView.swift' (1/1)
ContentView.swift:28:25: warning: Comma Spacing Violation: There should be no space before and one after any comma (comma)
ContentView.swift:51:3: error: Function Parameter Count Violation: Function should have 5 parameters or less: it currently has 10 (function_parameter_count)
ContentView.swift:51:8: error: Identifier Name Violation: Function name 'FunctionwithLotsOfArguments(arg1:arg2:arg3:arg4:arg5:arg6:arg7:arg8:arg9:arg10:)' should start with a lowercase character (identifier_name)
ContentView.swift:47:1: warning: Line Length Violation: Line should be 120 characters or less; currently it has 123 characters (line_length)
ContentView.swift:51:1: warning: Line Length Violation: Line should be 120 characters or less; currently it has 147 characters (line_length)
ContentView.swift:28:39: warning: Non-Optional String <-> Data Conversion Violation: Prefer using UTF-8 encoded strings when converting between `String` and `Data` (non_optional_string_data_conversion)
ContentView.swift:59:1: warning: Trailing Newline Violation: Files should have a single trailing newline (trailing_newline)
ContentView.swift:40:1: warning: Trailing Whitespace Violation: Lines should not have trailing whitespace (trailing_whitespace)
ContentView.swift:26:62: warning: Unused Closure Parameter Violation: Unused parameter in a closure should be replaced with _ (unused_closure_parameter)
ContentView.swift:26:72: warning: Unused Closure Parameter Violation: Unused parameter in a closure should be replaced with _ (unused_closure_parameter)
ContentView.swift:20:1: warning: Vertical Whitespace Violation: Limit vertical whitespace to a single empty line; currently 2 (vertical_whitespace)
Done linting! Found 11 violations, 2 serious in 1 file.

SwiftLint has the ability to fix some issues, so I ran:

swiftlint --fix ContentView.swift

The result was:

Correcting Swift files at paths ContentView.swift
Correcting 'ContentView.swift' (1/1)
ContentView.swift:28:25 Corrected Comma Spacing
ContentView.swift:58:1 Corrected Trailing Newline
ContentView.swift:40:1 Corrected Trailing Whitespace
ContentView.swift:26:62 Corrected Unused Closure Parameter
ContentView.swift:26:72 Corrected Unused Closure Parameter
ContentView.swift:19:1 Corrected Vertical Whitespace
Done correcting 1 file!

This reduced the number of problems to 5, with 2 serious. What it fixed was mostly whitespace issues, but it also removed the two used parameters from the networking closure. It did not fix the indentation.

Next on my list was Prettier, so I reverted to the badly formatted code and opened the project folder in Visual Studio Code. I had already installed the Swift and Prettier extensions, so I opened and re-saved the file to make Prettier do its thing. This did a slightly better job than SwiftLint: it fixed the indentation and spread the long function call and definition over three lines. It also removed the two parameters from the networking closure and added some line feeds to make the code more readable.

swift-format

Finally, it was time to see what swift-format can do. After reverting to the original code again, I chose Editor -> Structure -> Format File with 'swift-format':

This fixed the indentation and the whitespace issues. Interestingly, it split the long function call and definition over multiple lines, but still with more than one argument per line. It did not remove the two parameters from the networking closure. I think I may be running into the difference between a formatter and a linter.

While I was impressed overall, I disliked the way it removed spaces around the range operator. I prefer:

data = Array(0 ..< 1000).map { "Row #\($0)" }

But after using swift-format, it was:

data = Array(0..<1000).map { "Row #\($0)" }

Configuring swift-format

The swift-format tool is installed as part of the Xcode toolchain, so the first step in configuring it was to locate it, using the instructions found here under Included in the Swift Toolchain. In Terminal, I used:

xcrun --find swift-format

Which gave me: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-format

Using this path, I was able to export the default configuration file (I included the full path to the tool in the command, but faked it here for ease of reading):

path-to/swift-format dump-configuration > swift-format-default-config.json

Opening the file, it has a bunch of settings and a long list of rules. I'm not going to go through them, but the file is in the project folder, so you can see it if you download the project from GitHub and switch to the swift-format branch.

The indentation is set to use 2 spaces. I assume that was picked up from my Xcode settings, since it's different to the default. The setting I want to change is:

"spacesAroundRangeFormationOperators" : false

Before making any changes, I need to save the file in a location and with a name that swift-format can find. In my tests, I found that saving it as .swift-format in my home directory meant that it applied to every Xcode project. To do this, I followed this sequence in Finder:

Open my Home directory.
Press Command-Shift-Period to show hidden files.
Option-drag swift-format-default-config.json to the Home directory.
Rename the file to .swift-format agreeing to the warning about making it invisible.

Then I edited it, changing the setting to:

"spacesAroundRangeFormationOperators" : true

Back in Xcode, I pressed Shift-Control-I to reformat the file. This time, the range operator was formatted with spaces as I wanted.

To make future configuration changes easier, I created an alias to .swift-format in my Home folder and called it swift-format alias.json. This gives me a visible link that will open in a JSON editor. With that in place, I pressed Shift-Command-Period again to hide invisible files.

swift-format has a lint option, so in Terminal, I ran:

swift-format lint ContentView.swift

Which reported:

ContentView.swift:55:8: warning: [AlwaysUseLowerCamelCase] rename the function 'FunctionwithLotsOfArguments' using lowerCamelCase

If I was going to do this on a regular basis, I would want to add the path to the swift-format tool to my PATH variable or create an alias to it in my .zshrc file, but it was valid information.

One extra tip: use Editor -> Structure -> Format to Multiple Lines or Control-M to split long lines into multiples. This is a much more consistent way of spreading out long function calls and definitions. You'd think that Editor -> Structure -> Reformat to Width would do the opposite, but in my tests, it did either nothing, or the same thing as Format to Multiple Lines.

Conclusion

I am going to use swift-format in my projects from now on. It's less intrusive than SwiftLint and I like that it's built into the Xcode toolchain. I am going to assign a different keyboard shortcut as Shift-Control-I is an awkward combination to reach on my Ergodox Moonlander keyboard.

Conveniently, the command applies to the entire active file, regardless of selection. I'm used to using Command-A -> Control-I to fix indentation issues, but this method only requires a single key command.

For future reference, be aware of this note from the swift-format GitHub page:

NOTE: No default Swift code style guidelines have yet been proposed. The style that is currently applied by swift-format is just one possibility, and the code is provided so that it can be tested on real-world code and experiments can be made by modifying it.

I am hoping that Apple or the Swift team does develop a style guide while still allowing for customization, but in the meantime, I will continue to tweak the settings to suit myself. I presume that if I include a .swift-format file in my project, it will override any other settings. This would be great for distributing tutorial projects with a consistent style. I'd also love to be able to set the formatter to run on save, like Prettier does in Visual Studio Code.

The test project is on GitHub at trozware/swift-format-tests if you want to try it out for yourself. There's a separate branch for each formatter, with main holding the original, badly formatted code.

If you have any other thoughts or suggestions, I'd love to hear them. You can contact me using one of the links below or through the Contact page. And if you found this, or any of my articles useful, please buy me a coffee.

App Permissions on macOS Sequoia

2024-10-02T01:33:26Z

In 2012, with OS X Mountain Lion, Apple added a feature called Gatekeeper. It had been available earlier as a command line utility, but this was the first time they made it accessible through System Preferences. Gatekeeper allowed users to control which apps could be installed on their Macs by offering three options: allow apps from App Store, App Store and identified developers or Anywhere. This was the start of Apple trying to lock Macs down, similarly to how iOS devices are locked down, but it allowed power users to install any apps they wanted.

In macOS Sierra (2019), the Anywhere option was removed. It was still possible to open any app by right-clicking and selecting Open. You had to get past a couple of warning dialogs, but it worked. Now, in macOS Sequoia, even that has gone. So how can you open an app that isn't signed by an identified developer?

TL;DR: You can still run unsigned apps, but it's a bit more difficult. After trying once, you have to go to System Settings -> Privacy & Security, scroll to the end and click Open Anyway for that app.

Testing on my Computer

I created a test app called UnsignedApp, and made sure to leave the developer team set to None so the app could not be code signed. I archived the app in Xcode and clicked Distribute App in the Organizer window. Instead of selecting one of the standard options, I chose Custom and clicked Next.

Then I selected Copy App as it was the only option that wasn't going to sign the app.

I saved the app to my desktop and opened it without any problems. Next, I moved it into my Applications folder and tried again. Still no problems. So presumably, even though it was unsigned, it was OK because I had created it. Next, I tried running it when logged in as a different user on my computer. This still worked, rather to my surprise. So I assume that my computer is registered to my developer account and any apps I create are allowed to run on it, regardless of user.

Testing on Someone Else's Computer

The problems started when I tried running the app on someone else's Mac. This dialog appeared (presumably the default button says Move to Trash where appropriate):

I clicked Done to close the dialog and tried the old right-click and Open trick. No good - this showed the identical dialog.

Finally, I remembered reading something about this on Mastodon. I forget who posted it, so if it was you, thank you very much because Apple certainly wasn't helping here. I opened System Settings and went to Privacy & Security. After scrolling all the way down to the end, past the sign marked Beware of the Leopard (with apologies to the late, great Douglas Adams), I found this:

There is the Gatekeeper setting with the remaining two options, but added on is a message about my app being blocked. I clicked Open Anyway and got this dialog:

At least this gave me an option to proceed. I clicked Open Anyway and got this scary (and badly written) message:

I authenticated and finally, the app ran. But there's one more interesting twist. The app has the ability to show its running location. When I ran the app from the Applications folder, it was in /Applications as expected, but when I deleted it from there and tried running it from the Downloads folder, macOS moved it into a hidden AppTranslocation folder and ran it from there:

Using Terminal

The spctl command line utility used to allow full manual control of Gatekeeper. In macOS Sequoia, it has lost most of its power, but you can still use it to re-enable the Anywhere option in System Settings -> Privacy & Security -> Allow applications from using this command:

spctl --global-disable

If you're already in System Settings -> Privacy & Security, go to a different settings page and back again to see the change.

If you choose Anywhere, you have to authenticate, but then you can run any app. I wouldn't bet on this staying around forever, but for the moment, it's nice to see it's still there. The extra choice disappears after about 8 minutes if you don't select it.

Conclusion

You can work around this limitation, but proceed with caution. There are bad Mac apps out there, so don't use these workarounds unless you're confident of the source. Be particularly wary of any app that asks you to authenticate.

Apple has always been very keen to keep iOS devices locked down. They maintain that this is essential for security but given some of the scams in the App Store, that is a debatable point. The Mac has historically always been open and allowed users to do what they wanted. Over the past few years we have seen Apple gradually closing down the Mac to bring it more in line with the other devices.

With my tech support hat on I can see the benefits of this, but as a power user, I want to have the tools to work around it if necessary.

As a developer, I realize that it is now virtually impossible to release any Mac apps without having a developer account. Mac apps must be notarized by Apple so that they fall into the Known Developers category, regardless of whether they are distributed through the App Store or by other means.

If you have any thoughts or suggestions about this, contact me using one of the links below or through the Contact page. And if you found this article useful, please buy me a coffee.

Xcode Folders & Groups

2024-09-17T04:12:42Z

In Xcode 16, project files and folders are arranged differently in the Project navigator. What used to be a group is now a folder, and this simple change has some interesting effects. At first, I was against the new scheme - in fact in my SwiftUI for Mac 2024 article, I specifically recommended reverting back to the old group method. But after doing some more reading and testing, I think the answer is not so clear cut.

Since Xcode 15 doesn't work on macOS Sequoia, now's my last chance to create sample apps with both Xcode 15 and Xcode 16 in macOS Sonoma, and compare the two.

Using Xcode 15.4 and Xcode 16.0, I created a macOS app using Swift and SwiftUI. Both projects were placed under git control - you'll see why this is important soon. Both projects have identical files with identical contents, but take a look at the Project navigators:

At a first glance, there are two differences: the order of the files & folders and the color of the folder icons. A less obvious difference is that in Xcode 15, I can drag files around to arrange them in the order I prefer. In Xcode 16, I can't do that. I can drag files into or out of folders, but I can't move them around at the same level.

I like my Project navigator to be organized in a certain way, so I have to confess that I do find this annoying, especially since the folders at the top are ones I use infrequently. I did wonder whether the folders sorting to the top was due to the fact that I have that option turned on for Finder, but when I turned it off in Finder and made a new project, it was still the same.

Adding a new file

What happens when you add a new file? There are many different ways to do this in Xcode 16, but I'll stick to the same old method that works for both. With ContentView.swift selected, press Command-N to open the file template chooser, select a new SwiftUI View file, and click Next. Name it DetailView.swift and click Create.

This is why I created git repositories for both projects - I wanted to see what source control changes were detected. In Xcode 16, the new DetailView.swift file is marked with the A that indicates an added file. But the top item in the Project navigator - the project itself - has no change marker. Going to the Source Control navigator confirms that there is only one change in the repository: the new file.

In Xcode 15, the new DetailView.swift file is marked with the A, but the project file is also marked with an M for a modified file. The Changes tab in the Source control navigator shows a lot of unreadable changes to the project.pbxproj file, which is one of the files hidden inside the .xcodeproj bundle:

This points out the fundamental difference between the two approaches: groups are an artificial construct that is stored in the project files. Usually, this mirrors the file and folder structure in Finder, but it doesn't have to. When you use folders, Xcode is reading the file and folder structure directly from the Finder.

One other difference: in Xcode 15, the new file is added to the Project navigator directly after the selected file. In Xcode 16, there appears to be a preset sort order, the logic of which escapes me for now. If I add a file with no other file selected, it's added to the root of the project, outside the main folder. Otherwise, it's added after ContentView.swift, no matter which file was selected.

Importing files

So how does this affect importing files? For both projects, I used Integrate -> Discard All Changes... to revert them to their original states. Then in Xcode 15, I dragged my folder of sample files into the Project navigator, selecting where I wanted it to appear:

This led to the dialog that I've always found slightly confusing and far too large, but I chose my standard settings.

The source control markers showed three added files and a modified project file. Checking the project folder in Finder, I could see the new folder and its files in the correct place.

With Xcode 16, I wasn't able to select a precise location for the dropped folder, but I was able to choose the destination folder:

The import dialog was less confusing - the only real option was whether to copy the files or move them.

The Utilities folder appeared below the Preview Content folder, the three files in it got the A marker, and the project file showed no changes.

But since Xcode is reading the file and folder structure directly from the Finder, I can add and move files in Finder as well as in Xcode. Still in Xcode 16, I discarded all changes again to revert to the starting app, then I right-clicked on ContentView.swift and selected Show in Finder. Then I dragged my Utilities folder into the project folder in Finder:

Back in Xcode, there was the folder and its files, but with no A markers on the files. The Source Control navigator showed only the addition of the Utilities folder and not the files inside it. I made a change in ContentView.swift, then went to Source Control navigator -> Changes and clicked Stage All. This added the three new files to the commit. So that worked, just not very smoothly, but again, there were no changes to the project file.

Changing the Folder Structure

What else can I do in Finder that Xcode 16 will pick up? For my next test, I dragged a SwiftUI view file into the project folder in Finder. Then, still in Finder, I selected both the ...View.swift files, right-clicked, and selected New Folder with Selection. I named the folder Views and sure enough, Xcode picked up the changes. The folders in the project appear to sort alphabetically, so the Views folder appeared after the Utilities folder. So I guess that while I don't have total control over the arrangement of the files in the Project navigator, I can organize the files into folders to suit.

Then I got to thinking about assets - can I add them to Assets.xcassets using Finder? The assets I add most frequently are images and app icons. I tried dragging an image into the Assets.xcassets folder but it didn't appear in Xcode - I had to import the image as usual which creates an imageset folder with the image and a Contents.json file. If I took an imageset folder from another project and added it using Finder, that worked as expected. Similarly, if I dragged an AppIcon.appiconset folder from another project into Assets.xcassets, that worked too, with Finder offering to merge or replace the existing folder. I chose replace, and my icon was there.

Conclusion

Which style will I use going forward? With groups, I get the total flexibility that I'm used to, so I can arrange my files and folders exactly as I like. But with folders, I can use Finder to import and organize my files and folders. The big difference is in source control, especially if you're working with other people. When every file addition, deletion or move also changes the project file, you have a much greater chance of getting a merge conflict.

Finally, Apple has obviously decided that folders are the way to go - they are the default for new projects in Xcode. Over the years, I have seen Apple make many changes which seemed nonsensical or irritating at first, but nearly every time, it turned out that these changes were the precursor to more significant changes and if you had accepted the initial changes, you were in much better shape to handle the larger changes down the track.

Finally, as an educator, I try to stick to the defaults as much as possible. I don't want to confuse anyone by requiring them to make changes to their setup to match me. So I'll be using folders from now on.

But remember, if you hate it, or if you want to upgrade an older project, you can always swap. Right-click on the project folder in the Project navigator (the second item), and select Convert to Group or Convert to Folder.

What do you think? Will you go with the flow and use folders, or do you intend to stick with groups? If you have any other thoughts, ideas, suggestions or questions, I'd love to hear from you.

You can contact me using one of the links below or through the Contact page. And if you found this article useful, please buy me a coffee.

Converting an App from Obj-C

2024-09-12T00:28:24Z

A couple of months ago, I got a message from App Store Connect pointing out that one of my iPhone apps - Berio’s Sequenza VII - had not been updated in 3 years and so would be removed from the App Store unless I updated it within 90 days. I disagree with this policy, but small developers like me can't fight Apple. Since I want the app to remain available, I then had to consider how to update it. Once I opened the app project, I realized that the app was written in Objective-C, so I decided to take the plunge and convert it to Swift and SwiftUI.

The app in question is a highly specialized app with an extremely small market - professional musicians or university-level music students who play the oboe. My eldest son fits this category and in 2013, he started to learn a piece called Sequenza VII by Luciano Berio. This is a very strange piece because it doesn't have a standard time signature. Instead each line has 13 bars (measures) with each bar being allocated a certain time span in actual seconds. This means that it's impossible to practice it with a metronome, so I wrote an iPhone app that counted each bar and played a sound or flashed the screen at the appropriate times for each bar. I allowed for slowing the whole thing down for practice, and since the performance is supposed to be accompanied by a constant drone playing in the background, I added that too. I can't say it sells well, but every time someone buys it, I get a warm glow of satisfaction.

I dislike Apple's policy of removing old apps, just because they are old. After all, the piece of music that this app supports was written in 1969 and Berio hasn't updated it since!

There are valid reasons for removing apps from the App Store:

The app doesn't run on the latest hardware or operating system.
The app is a scam.
The app is an obvious clone of another app.

But basing a removal purely on age is an easy thing to automate, so Apple can convince themselves that they are keeping the App Store safe, without actually doing anything to make it safe. In fact, the last time I got one of these notices, I updated the version and build numbers and re-submitted the identical app to the App Store. It was accepted and the notice went away. I fail to see how this did anything except waste my time and the App Store reviewer's time.

Anyway, this time I considered doing the same again, but when I realized the app was still in Objective-C, which I am rapidly forgetting, I decided now was the time to convert it. So I opened up Xcode and created a new project using Swift and SwiftUI. Don't you love the smell of a fresh Xcode project?

There are four main aspects to the app:

The main screen that shows the bar length and allows control.
The settings screens that configure the app - there are a lot of options.
Playing the drone if required.
The timing functions that work in the background and update the UI as the bars proceed.

Main Screen

For the main screen, the UI was quite simple and I was able to recreate it in SwiftUI with no problems. The only issue I had was with Text views that are only visible in certain circumstances. I tried hiding them by adjusting opacity which I expected to work, but it didn't, presumably because there wasn't always any text content. I could have solved this using fixed heights, but I didn't want to do that for accessibility reasons. I ended up keeping the views always visible but clearing or setting the text content. By using Spacers and VStacks I was able to keep the layout looking the way I wanted it at all times.

As is my usual habit, I populated the UI with local variables at this stage. This lets me adjust the preview data quickly to make sure the UI works with a range of different values, without having to worry about the actual data flow. Then I plugged in real data later. For the SwiftUI preview, I selected the iPhone SE 3rd generation as the standard device. This is the smallest screen size so everything has to fit on it. Later, I used the iPhone 15 Pro Max to confirm that it all looks good on a large screen too.

The only other trick was to use a .monospacedDigit() for the large counter in the middle of the screen. This stops the numbers jumping around as they change.

Settings

Now on to the settings which take up two screens. In the Objective-C app, I used storyboards. The main screen segued to a tab view with three tabs: two for settings and one for the about screen. The settings views used lots of nested stack views and many, many constraints.

Getting the basic UI elements into SwiftUI was relatively easy, but I wanted them to look good on large or small iPhones. I didn't want something that looked good on an SE being all crammed into the top half of a 15 Pro, but that ended up being more-or-less what I got.

I tried various techniques using nested stacks, spacers, forms, groups and so on. Nothing I tried gave me quite the result I wanted, but I ended up with nested VStacks which allowed me to group related settings. In hindsight, I probably should have swallowed my GeometryReader aversion and used it to adjust the layout spacing, based on the screen size. I'll probably go back and do that later.

But the most important thing about the setting screens is the settings themselves and here is where SwiftUI really shone. The two view controllers for these pages had masses of code for handling the settings. First, they had to read them in from UserDefaults, providing logical defaults if needed. Then they had to update the UI to reflect the settings. Since several of the settings depended on other settings, monitoring changes meant potentially adjusting other settings and then saving them all back to UserDefaults as well as adjusting all the UI elements manually. And finally, reverting the settings to the standard defaults required even more code and UI updates.

With SwiftUI, I used @AppStorage extensively. Not only did this remove all the hassle of reading and writing to UserDefaults, but it also automatically updated the UI when the settings changed. And by setting up disabled modifiers, the connections between the linked settings were automatic. I was able to remove a lot of code and make the settings screens much simpler and easier to understand. And this flowed on to the main screen when I was adding its data as it used the same @AppStorage properties.

Counting the lines of code using scc, I found the following:

View	Obj-C	Swift	Reduction
Settings	173 (13)	101 (0)	72 (42%)
Bar & Sounds	166 (18)	124 (8)	42 (25%)

The numbers in brackets after the line count are the complexity ratings. The bar & sounds view is more complex because it has to be able to flash the screen.

Which reminds me of another thing: in the original, I used a background image with a gradient that stretched to fill whatever screen size was in use. In the new version, SwiftUI makes the background gradient itself. I added the start and end colors to the Assets catalog, and now use a LinearGradient which I can change programmatically if the user wants the screen to flash at the start of each new bar.

The Drone

The drone plays a B4 constantly. But some oboists like to adjust the frequency of their basic A from the standard of 440 Hz, so I had to allow for that and adjust the B4 to match.

I am not a sound expert, so in the original app, I imported some third-party code to do this. It's very much C code even though it's written in Objective-C and I do not possess the expertise to convert it to Swift. So in this case, I added the DronePlayer.h and DronePlayer.m files to my new project. When I did this, Xcode kindly offered to create a bridging header for me, which was great because it's been so long since I did this, that I would not have remembered how to do it manually. I did need to check an older project to remember what to put into the bridging header. The format is:

#import "DronePlayer.h"

You import the header file (.h), and don't forget the leading # or the import won't work.

After that, I created a Swift class to act as the intermediary between SwiftUI and this Objective-C class and it works very well. I am concerned that this is very old code that may not always work, but hopefully by the time Apple deprecates it, there will be Swift alternatives I can use.

Timing

Finally we get to the most crucial part of the app: timing the bars.

In the original, I used a custom thread with a high priority. While running the main loop, it would compute the time until the next bar and sleep until then. Then it would proceed to the next bar and update the UI. This worked well and when I logged some timing tests, it was accurate to within about 0.01 of a second.

But it all felt very complicated and perhaps unnecessarily accurate, so I started experimenting with using a Timer. That didn't work very reliably, but my next attempt used DispatchQueue.main.asyncAfter and that worked. At the start of the main loop function, I calculate when the next bar should start and call asyncAfter with that time. Then I update the UI so that this never slows down the loop.

This worked quite well but my timing tests showed that the first two bars were always out by about 0.1 seconds. The later bars were more accurate. I can't explain why the longer bars at the beginning of each line were less accurate than the shorter ones, but maybe the internal code that asyncAfter uses to schedule the call is inherently less accurate for longer times.

I decided to have some fun with this inaccuracy and I added routines to track the error of each bar and store that for adjusting the call time the next time round. For example, bar 1 should last 3 seconds. If it took 3.1 seconds, then next time, I apply that 0.1 second error and call it after only 2.9 seconds. After two complete loops, the timings were as accurate as the original, with the added bonus that they would self-adjust to suit if the user's device was busy doing something else in the background.

I used OSLog to track the timings. This takes a bit more effort to set up than print, but it makes it much easier to filter out the logs you're interested in. And since Xcode seems to have got more verbose over the years, being able to filter is very useful.

At the top of my ContentView.swift file, I added:

import OSLog

Then, where I was declaring properties, I created a logger:

private let logger = Logger(subsystem: "Berio", category: "ContentView")

It seems to be a standard to set the subsystem to an app identifier and the category to the class you're logging. You can use these labels when filtering.

To log my timings, I used:

logger.info("Bar \(runState.barCounter) - Elapsed time: \(elapsedTime), Error = \(error)")

Even though I could run the app in the live preview, that didn't produce any log entries, but in the simulator, they appeared. I filtered them to show only the ContentView category and then I was able to track all the timings:

Conclusion

This was an interesting exercise. It is extremely impressive that 11 year old Objective-C code can still build and run with the current Xcode and on current devices. In the Swift world, we do not have such a luxury, but I still feel more comfortable moving forward with Swift. I'm left with the drone code being in Objective-C, but that's a good reminder to me that it is still possible to mix the two languages.

The remaining items on my to-do list are to implement a better layout for the settings pages so that they fill the screen no matter what the screen size. And to keep an eye out for a Swift way of playing a drone at a set frequency with a particular waveform.

Anyway, this has got Apple off my back for another 3 years, at least as far as this app is concerned :-)

And always, I'd love to hear from you if you have any suggestions, corrections or improvements. If you are an oboe student, let me know which music school you are at and I'll send you a discount code for the app.

You can contact me using one of the links below or through the Contact page. And if you found this article useful, I'd love you to buy me a coffee.

SwiftUI for Mac 2024

2024-08-22T07:21:54Z

Over the years, I have written articles and sample apps to demonstrate the new features of each year's SwiftUI updates with particular emphasis on macOS app development. Last year, the major update to SwiftUI was the new data flow system using the Observation framework. I covered that in my article SwiftUI Data Flow 2023 but I didn't feel there were sufficient UI changes to warrant an update to my usual sample app.

This year, the HTTP Cats app is back! And I'll cover new features from both WWDC 2023 and WWDC 2024.

It's currently August 2024 and I am running macOS Sequoia 15.1 Beta (24B5024e) with Xcode 16.1 beta (16B5001e).

Download the project from GitHub and, if you're running the correct versions of macOS and Xcode, you can run the app and follow along. If not, you can still look at the code, but it won't build.

Warning: there's a bug right now that crashes the app in macOS 15.1. If you scroll down the list in the sidebar and then select a status that is more than 8 or 9 rows below the previous selection, the app crashes with this error: Row index -1 out of row range (numberOfRows: 60). I've tested this with Xcode 16.0 beta 6 and Xcode 16.1 and they both act the same. But on a computer running macOS 15.0 beta 7 and Xcode 16.0 beta 6, it works perfectly. So this is a bug in macOS 15.1.

Here are the areas that I'm going to discuss:

Xcode

When you create a new project in Xcode 16.1, the second item in the project navigator is now a folder instead of a group. This sounds trivial, since it really is a folder in Finder but I find it really annoying because it doesn't allow me to arrange my other files and folders as I want them. To fix this, right-click on the folder and select Convert to Group. The icon switches from blue to gray and you can once again drag files and folders to re-order them.

The advantage to the folder option is that your project is read directly from the file system, so you can use Finder to move files around and Xcode will reflect the changes. To import a file into the project, you can drag it into the project's Finder window and Xcode will see it. Similarly, to delete a file, you can use Finder directly. With the group option, you have to import files into the Xcode Project navigator, and when you do, source control marks the .xcodeproj file as modified, making source control messier. Using the folder option, only the new file itself gets marked as a change. So use which option works for you, but I much prefer the clarity of being able to organize my files in the Project navigator.

The next thing to look at in Xcode is Predictive Code Completion. While the Xcode betas run on macOS Sonoma, predictive code completion requires Sequoia and I think it also requires a minimum of 16GB of memory. We don't yet have the promised Swift Assist which will allow for a more detailed way of asking Xcode to write code, but the code completion is supposed to be much better.

I've used GitHub Copilot for writing JavaScript for a couple of years now and overall, it works well. I use it as a form of super autocomplete and targeted search rather than asking it to write large chunks of code for me, and that's what I'm hoping to get for Swift now. Xcode has a way to go to catch up yet. Surprisingly, it suffers from one of the same problems as Copilot - it appears to have been trained on old code!

I know some people are very negative about using any form of AI to write parts of your code, but I see it as just another tool to help us be more efficient. For example, I bet you've written code to download and process JSON many, many times. Why not let Xcode write that for you? You still have to do the thinking. What's the URL? Which properties do I need? How am I going to use the data? But you don't have to write the boilerplate. It's no different to using a library or a pre-built function.

I put predictive code completion to the test by creating a new Swift file called Networker.swift. I set up a Networker class and gave it a web address. Then I started to write a function to fetch the data:

The faded text is the suggestion. I had only typed func fet. It used the address to deduce that I was downloading quotes - not unreasonable. I pressed Tab to accept and got the next chunk:

After pressing Tab a few more times, I ended up with this:

This doesn't build and it uses old-style completion handlers instead of async/await. The biggest problem I see is that it's fallen into the usual URLSession trap and not called resume on the task. So this was never going to download anything.

I started to define a NetworkError enum and it filled in the cases it had used, so that was really good. When I started to define a Quote struct, it also added some reasonable properties, as well as marking it as conforming to Codable - bonus points there.

When I tried to build, I got sensible warnings pointing out that I had not used either task or data. This would have reminded me to call resume if I hadn't already noticed. I also got a Swift 6 concurrency warning about the completion handler.

So overall, not great yet. Old technology and a flawed implementation. One of the points Apple people made at WWDC 2024 was that these code tools would be trained on the latest Apple APIs. This is not the case here, but I'm still running a beta, so I'll give them the benefit of the doubt for now. I'll definitely be keeping an eye on this feature and hope to be able to make good use of it in the future.

Before I move on from Xcode, there's one more feature I want to mention and that's the new options for creating a new file. If you press Command-N, you get the file template chooser, just as before. But now there are other possibilities. You can use the File menu or right-click in the Project navigator to add a new empty file, but the one I like best is the ability to make new files from the clipboard. I don't know about you, but when I'm working on a SwiftUI project, I'll often have more than one view in a file, especially if I've created views by extracting subviews. Later on, I'll want the view to have its own file.

I had a view called MeshBackground which didn't have its own file, so I selected the entire struct and pressed Command-X to cut it out. Then both the contextual menu and the File -> New menu offered New "Meshbackground.swift" from Clipboard. When I selected this, it added the file, named it and pasted in my struct. The only thing I had to do was to add the import SwiftUI statement at the top of the new file. I think it could have been smart enough to work this one out, but maybe later.

This is a great time-saver and will really encourage me to keep my code well-structured.

In minor Xcode updates over the last two years, my favorite feature is using Control-M to split long lines of code over multiple lines.

Previews

Last year, we got the #Preview macro which made SwiftUI previews a lot neater. We went from:

struct SidebarRowView_Previews: PreviewProvider {
  static var previews: some View {
    SidebarRowView(code: "418", title: "I'm a teapot")
  }
}

To this:

#Preview {
  SidebarRowView(code: "418", title: "I'm a teapot")
}

Xcode 15 has a converter you could use to switch to the new format, and Xcode 16.0 still has it but Xcode 16.1 does not. I'm not sure why they removed it, but it's not a big deal to do it manually.

The new thing this year in previews is the @Previewable macro which lets us provide data to a preview. This is especially useful for binding properties. In SidebarView.swift in the sample app, I show the old style commented out:

SidebarView(httpSections: HttpSection.localData, selectedStatus: .constant(nil))

selectedStatus is a Binding, so I can't just pass in nil. I had to use .constant to create a Binding set to nil. With @Previewable, I can do this:

@Previewable @State var selectedStatus: HttpStatus? = nil
SidebarView(httpSections: HttpSection.localData, selectedStatus: $selectedStatus)

I expected to be able to supply an actual HttpStatus here and have it start as the selected item in the list, but although it compiled fine, it didn't show up as selected in the preview initially. But I am now able to change the selection in the preview.

Windows

The first window feature I want to address is not new, but I've been asked about it a few times. How do you make a single window app and get SwiftUI to remove the File -> New Window menu item?

When you create a new SwiftUI app, the ...App.swift file contains something like this:

@main
struct NewApp: App {
  var body: some Scene {
    WindowGroup {
      ContentView()
    }
  }
}

This defines the main scene of the app as a window group which allows for multiple identical but independent windows. You get a File menu with a New Window item and a Close item. If you want a single window app, you need to change the WindowGroup to a Window, supplying the window title and an id string:

@main
struct NewApp: App {
  var body: some Scene {
    Window("New App", id: "mainWindow") {
      ContentView()
    }
  }
}

The id can be anything so long as you don't use it for any other window in your app. In the default state, this removes the File menu completely. It also changes the app behavior so that closing the window quits the app completely. If you add any new commands to the File menu, you'll get the Close item back, but using it will still quit the app. You can still open secondary windows in this style of app, but you can't duplicate the initial window.

I covered how to open new windows in my previous article SwiftUI for Mac 2022. The code is still present in this year's sample app for reference, but commented out.

There is a new window scene called UtilityWindow. This is primarily intended for floating palettes and toolbars. I've used it for the UI Samples window just because that was a window I wanted to show, but it's not really the right design choice for this sort of informational window.

In SwiftUI_Mac_2024App.swift, here's how I set up the utility window:

UtilityWindow("UI Samples", id: "ui_samples") {
  SamplesView()
}
.keyboardShortcut("u")

Similarly to Window, it needs a window title and an id. The view to show in the window is in the closure and I've added an optional keyboard shortcut.

If you add a Window scene that's not the initial window, it appears in the Window menu and you can open it from there with an optional keyboard shortcut. A UtilityWindow gets a Show/Hide menu item in the View menu instead, and the keyboard shortcut toggles it.

A utility window has a few other differences:

It's a floating window that appears above your other windows.
It doesn't get focus by default when opened, you have to click in it to make it active.
When focused, you can close it with the Escape key.
It's hidden when your app is no longer the active app.
It cannot be minimized, so the orange button in the title bar is disabled.

These windows can be opened programmatically in exactly the same way as other windows, using openWindow. Check out the code in ToolbarView.swift to see how I do this.

The other window features I want to explore relate to style, initial position, and dragging. In one of the WWDC 2024 videos, the presenters created a custom About window for their app, so I decided to try to do the same.

First I made a SwiftUI view called AboutView. I added some titles and buttons, including one to close the window. I also added a mesh gradient background to make it look a bit more interesting. See the Colors and gradients section below for more info on that.

With the view created, now I had to work out how to show it instead of the default About window. I started by adding a new window scene to SwiftUI_Mac_2024App.swift:

Window("About", id: "about") {
  AboutView()
}

Then in MenuView.swift, I added a new CommandGroup, replacing the existing appInfo command:

CommandGroup(replacing: .appInfo) {
  Button("About SwiftUI Mac 2024") {
    openWindow(id: "about")
  }
}

When testing this, there were two problems:

The window was too large for my content.
There was now an About menu item in the Window menu as well as About SwiftUI Mac 2024 in the app menu.

To fix these issues, I added modifiers to the window scene:

.windowResizability(.contentSize)
.commandsRemoved()

Now my content filled the window although the sizing could still be too small or too big. But the Window -> About menu item was gone, so I was making progress.

Next up is the new defaultWindowPlacement modifier, which lets you set the initial position and size of a window. I added this to the About window scene:

.defaultWindowPlacement { content, context in
  let displayBounds = context.defaultDisplay.bounds
  let contentSize = content.sizeThatFits(.unspecified)
  let position = CGPoint(
    x: displayBounds.midX - (contentSize.width / 2),
    y: displayBounds.midY - (contentSize.height / 2)
  )
  return WindowPlacement(position, size: contentSize)
}

The context is a WindowPlacementContext that provides the display where the window will appear. I'm using its bounds to determine the screen size.

The content is a WindowLayoutRoot that gives the sizeThatFits for the proposed content allowing for various proposed view sizes. I'm using the unspecified size to get the ideal size for the content.

With these two pieces of data, I can calculate the position for the top left of the window so that the center of the window will be at the center of the screen, and combine this with the size into a WindowPlacement.

Now when I run the app and open the About box, it's in the center of the screen and the right size for the content. But if I move the window, then the next time I run the app, it's where I put it instead of in the center. This is the correct behavior for most windows, but not for the About window. I want it to be centered every time.

Time for another modifier:

.restorationBehavior(.disabled)

This stops the window from remembering where it was put when the app re-launches. It remembers inside a single launch, but not on the next launch. If your window still remembers where it was because you moved it before adding this modifier, you may need to delete the app's container folder in the Library/Containers folder to reset it.

One thing I noticed was that this always put the About box on my primary monitor, even if the app was running on a secondary monitor. If I re-enable the restoration behavior, the window appears on the correct monitor, but then it doesn't center.

Now I have two more requirements: I want the About window to have no title bar and I want to be able to drag it around the screen by clicking anywhere in the window. The first part is accomplished with yet another modifier:

.windowStyle(.plain)

Now the window has no title bar. Good thing I added a Close button! One annoying bug is that I added a keyboard shortcut to the Close button so I could use Escape to close the window. With a plain window style, it no longer works. The console shows this: Warning: -[NSWindow makeKeyWindow] called on SwiftUI.AppKitWindow 0x139365800 which returned NO from -[NSWindow canBecomeKeyWindow], so I guess the plain styled window is unable to become the key window and so cannot detect keyboard events.

For the dragging, open AboutView.swift itself. The simplest way to achieve the required result is to add this modifier to the main VStack:

.gesture(WindowDragGesture())

Now I can drag the window around by pressing and dragging from anywhere in the window. But I want more! I want to be able to track when the window is being dragged so I can change it visually. WindowDragGesture is new but it conforms to the Gesture protocol so I can use it to detect the state of the drag. I added an @GestureState property to AboutView to track it:

@GestureState var isDraggingWindow = false

Then I created a new WindowDragGesture with an updating closure to set the gesture state to true during a drag operation:

var dragWindow: some Gesture {
  WindowDragGesture()
    .updating($isDraggingWindow) { _, state, _ in
      state = true
    }
}

Finally, I changed the gesture modifier to use this:

.gesture(dragWindow)

Now that I have a property to track the dragging, I added a modifier to the VStack to change the opacity while the window is being dragged:

.opacity(isDraggingWindow ? 0.8 : 1)

And after all this, I finally had what I wanted:

One final tweak would be to show an appropriate cursor when the window is being dragged. I tried adding to the dragWindow gesture, but in the end I switched to using an onChange modifier:

.onChange(of: isDraggingWindow) {
  if isDraggingWindow {
    NSCursor.closedHand.push()
  } else {
    NSCursor.pop()
  }
}

Tabs

The syntax for defining tabs got what appears to be quite a minor upgrade, but it feels so much better. Here's the old syntax:

TabView {
  ChartSamplesView().tabItem {
    Text("Chart")
  }
  FormSamplesView().tabItem {
    Text("Form")
  }
}

This always felt backwards to me. The label of the tab is in the closure and the view that's inside the tab comes first, with a tabItem modifier.

The same tab view now looks like this:

TabView {
  Tab("Chart", systemImage: "chart.bar.doc.horizontal") {
    ChartSamplesView()
  }
  Tab("Form", systemImage: "list.bullet.clipboard") {
    FormSamplesView()
  }
}

This suits my brain much better. I define a tab first and then use the closure to say what it will show. The only issue I have with this is that it has not considered Mac tabs which are mostly text only. You must specify an image for the tab, even when it won't appear. In an app's Settings view, the tabs are styled differently and will show an image, but not in a conventional Mac window.

Ok, the image can appear in a conventional Mac window if you style the tab view differently. If you add a .tabViewStyle modifier to a tab view, you can set it to either automatic, grouped, sidebarAdaptable or tabBarOnly. The default is automatic, which is tabBarOnly on macOS. The grouped option is marked as being in beta, but it looks very familiar. It moves the tabs down so they are more like part of the content. The new one is sidebarAdaptable which moves the tabs to the sidebar and shows the images. I can't see myself using this in a Mac app, I think it's designed more for the other OSes. It would only be useful if you had a long list of tabs that wouldn't fit horizontally.

In the sample app, open SamplesView.swift and test the different tab styles to see what you think. I've added the two non-standard options there commented out so you can try them in the preview.

Charts

Last year, Swift Charts got a pie or donut option. This year, the charts team added vector and function plotting. In ChartSamplesView.swift, I have three different charts: a bar chart as before, a pie chart and a line chart that plots various sine waves. My understanding is that the various plot types are great for functions or for large data sets but for more comprehensive information, check out the WWDC presentation: Swift Charts: Vectorized and function plots.

In my samples, I have a separate computed property for each of the three chart types, with a @ViewBuilder property to return the correct chart. I've also updated the chart image export to use SwiftUI's fileExporter instead of the AppKit's NSSave. I had a slight issue with fileExporter. I started off by including the image content type when configuring the exporter. This gave generic error when I tried to save - not the most helpful of messages. I removed the content type and it worked fine. I'm not sure if this is a bug or a feature.

Colors and gradients

When you specify a Color in SwiftUI, you have the ability to add a standard gradient:

Capsule()
  .fill(.orange.gradient)

This is a great modifier as it gives us a very simple way to improve the look of a flat block of color.

This year, we also get the ability to mix colors, like this:

Capsule()
  .fill(
    selectedColor
      .mix(with: mixColor, by: mixPercent)
      .gradient
  )

Open the UI Samples window and go to the Form tab to test out some color mixes. This not only allows us to create our own colors, but it also gives us a way to change colors programmatically like I do with the slider in the example. You can even chain mix modifiers for more variability.

The other big new thing is mesh gradients. As you saw in the Windows section above, I used a mesh gradient to create a background for the About window. The basic technique for creating a mesh gradient is to make a grid of points and assign a color to each point. The points are defined as SIMD2<Float> so you initialize each point with SIMD2(x, y). Then you supply an array of colors for each point. The colors expand out from each point, meshing with their neighbors.

In my example, I set most of the colors to white but changed the top left, middle and bottom right points to different colors so that I got a diagonal gradient. I also used even spacing for the points, which is not necessary. Check out the code in MeshBackground.swift to see how I did this.

If you want to know more about mesh gradients, I highly recommend Stewart Lynch's video: MeshGradients in iOS 18 and Xcode 15. Although the title says iOS 18, it's all valid for macOS 15 too.

SF Symbols

My final topic is the ability to add animated effects to SF Symbols. You can test this in the FormSamplesView.swift preview, which only works because I used @Previewable to add the menu selection to the preview. Before that, the preview worked but ignored any menu changes. The demo is a bit strange because it will often show the previous animation before using the new one, but this is not the way I would use these effects in an app and it does allow you to see what's happening. Just keep clicking Show Effect to see your selected animation.

I wasn't able to get the appear or scale effects to work, but maybe that's an Xcode beta issue. They work in the SF Symbols app. The syntax for applying an effect looks like this:

Image(systemName: "rainbow")
  .font(.system(size: 50))
  .symbolEffect(.bounce, value: showEffect)

Specify a symbol as usual, sizing it as needed. Then add the symbolEffect modifier with the effect you want and a value. The effect is triggered whenever the value changes.

Conclusion

So those are my favorite SwiftUI additions from WWDC 2024. As we have seen in recent years, Apple is gradually converging the OSes, especially with SwiftUI, which means that a lot of code is no longer platform-specific. But as developers, we still have the responsibility to make our apps look, feel and behave in a way that suits the platform, whatever it is.

One other point is that a lot of resources will state that they are for iOS, but many of them are totally valid for macOS too. Don't skip an article or video just because it doesn't label itself as specifically for macOS.

If you want more Mac-specific content, check out my recently updated book: macOS by Tutorials. It's designed to help iOS developers extend into macOS development.

The project from this article is available on GitHub. And as usual, I'd be thrilled to hear any suggestions, corrections or improvements. Please contact me using one of the links below or through the Contact page. And if you found this article useful, I'd love you to buy me a coffee.

Book Building

2024-08-06T01:29:44Z

I started writing books for Kodeco when I was asked to contribute some Mac content to SwiftUI by Tutorials. I quickly learned that I really enjoyed long form technical writing but I wanted to create more Mac-specific content. After some negotiations, Kodeco agreed to my plan to write macOS by Tutorials and the first edition was published in April 2022.

As I have written elsewhere, Kodeco has pivoted away from books and into providing multi-modal courses. They agreed to transfer the rights of the macOS by Tutorials book to me as it was out-of-catalog and since then, I have released an update.

When writing for Kodeco, all I had to do was write the text and the accompanying code and images. The people at Kodeco took care of the rest. Many thanks to all involved - I greatly underestimated the work that this entailed! Now that I am self-publishing, I have had to learn how to create the various formats myself. This post is a summary of how I did that.

Introduction

Since I always used Markdown when writing for Kodeco, that's where I started. I wanted to produce the book as an ePub and a PDF, so I needed to convert the Markdown to those formats. I also wanted to produce a web version, so that required a Markdown to HTML conversion. After some research, I started off with pandoc. This is a command-line tool that can convert between many different formats, so it seemed like a good choice.

I found it very difficult to use and to configure to give the results I wanted. While looking for examples online, I discovered Pro Git. This looked like it was doing what I was trying to do, but even after following their examples, I was still having problems. Then I discovered that Pro Git 2nd Edition was written in AsciiDoc, not Markdown. I had never heard of AsciiDoc but it looked like it might make generating various book formats easier, so I decided to give it a try.

AsciiDoc is a markup language very similar to Markdown. This quick reference guide shows the syntax: AsciiDoc Syntax Quick Reference. The secret sauce was using AsciiDoctor to convert AsciiDoc files into HTML, ePub and PDF. This was much easier to use than pandoc but it took a bit of tweaking to get the results I wanted for each format.

Project Structure

I started by copying the file and folder structure used for Pro Git. I've since modified it to suit my needs but the basic structure is much the same. In the root folder, I have the following:

Rakefile: The Ruby file that contains the commands to generate the various formats.
Gemfile & Gemfile.lock: These files handle the Ruby libraries used to create the various formats.
book.adoc: The main file that assembles the contents of the book and is used for the PDFs and ePub versions.
book-html.adoc: The same as book.adoc but with an added image, since the HTML version doesn't have a cover.
theme folder: The files used to style the different versions.
images folder: All the images used in the book.
fonts folder: The custom fonts used in the book.
components folder: The adoc files referenced by book.adoc.
book folder: The adoc files for each chapter as well as preface, introduction, conclusion etc.

AsciiDoc files can import other AsciiDoc files, so I have a separate file for each chapter in the book as well as files for the non-chapter content. The book.adoc file includes components/headers.adoc, a link to the cover image and components/contents.adoc. book-html.adoc is the same except for including the cover as an image file.

The headers.adoc file is where AsciiDoctor reads the metadata for the book:

= macOS by Tutorials
Sarah Reichelt
:doctype: book
:doctitle: macOS by Tutorials
:notitle:
:toc: macro
:toclevels: 2
:figure-caption!:
:description: macOS App Development for iOS Developers
:author: Sarah Reichelt
:copyright: (C) 2024 Sarah Reichelt. All rights reserved.
:epub3-stylesdir: theme

Some of these are self-explanatory, but there are some oddities:

:doctype: book: Set the type of this document to a book. AsciiDoctor uses different formatting and allows different header levels for different types of documents.
:notitle: : Turn off default title page. I wanted to customise my title page.
:toc: macro: Setting this to macro allows me to specify the location for the table of contents, instead of using the default placement.
:toclevels: 2: Set the number of header levels to include in the table of contents.
:figure-caption!:: Tell AsciiDoctor not to add 'Figure #' to all image captions.
:epub3-stylesdir: theme: The folder containing the styles for the ePub version.

The next file in components is content.adoc. This is where I include the title page, the table of contents, the introductory pages, the sections and the conclusion. Each section file has a header, an introduction and links to the chapter files.

With the folder structure in place, I copied the matching Markdown files from the original book. Then I used various tools to convert these files into AsciiDoc. The Kramdown AsciiDoc converter did most of the work to translate Markdown to AsciiDoc. The image links needed special handling, especially when it came to adding captions and sizes. I used Python scripts for this. Python is always my go-to tool for text and file manipulation. I also used Python to strip out the Markdown metadata at the start of every chapter and add the AsciiDoc metadata.

I am not artistic, so I used Keynote to create the cover image. This allowed me to do object-oriented design with images, shapes and text. I then exported it as a PNG file for use in the book.

Finally, I had all the files in the right places and in the correct formats. Now to generate and style the various versions.

This involved using Ruby to run the various AsciiDoctor commands. My Mac had Ruby installed but only an old version, so I used Homebrew to update to Ruby 3.3. I'm not familiar with Ruby, so I had to learn how to install and update the required gems. With them in place, I used the commands in the Rakefile to create the various formats.

Formatting

The Pro Git Rakefile started by defining some parameters that could be passed to the AsciiDoctor commands for all the formats. In their case, params included two attributes: revnumber and revdate. I also wanted to specify the syntax highlighter and its style. Working out what to use for the syntax highlighter was a bit tricky as I wanted the code blocks to look like they would in Xcode, but I eventually found the right combination using pygments and its xcode style:

My parameters used by all the different formats ended up like

version_string = '2.0'
date_string = Time.now.strftime('%Y-%m-%d')

params = "--attribute revnumber='#{version_string}' --attribute revdate='#{date_string}'"
syntax_params = "--attribute source-highlighter=pygments --attribute pygments-style=xcode"

Then I had to work out how to style each format.

HTML

Pro Git uses this command for generating the HTML, which gave me my starting point:

sh "bundle exec asciidoctor #{params} -a data-uri progit.asc"

I had already added a second set of params for the syntax highlighter, but the next thing was to add my own style sheet. The Pro Git repo had a theme folder with sub-folders for each format. I tried editing theme/html/html.css but that didn't work. I eventually found that I needed to create a new file called docinfo.html in the theme folder and then add more attributes to access it. This changed my command to:

book_title = 'macOS_by_Tutorials_v2.0.html'
style_sheet = '-a docinfodir=theme -a docinfo=shared'

sh "bundle exec asciidoctor #{params} #{syntax_params} #{style_sheet} -a data-uri -o #{book_title} book-html.adoc"

This meant that I could add my own CSS or JavaScript to the theme/docinfo.html file and it would be included in the HTML output. The data-uri attribute tells AsciiDoctor to embed the images in the HTML output. I didn't want to have to give people a folder of images to go with the HTML file, I wanted a single file that could be opened in a browser and would include everything.

I generated an HTML file using the default styling, then copied the default CSS into a style block in this file. I then edited it to my satisfaction.

One refinement for the HTML version was to add a copy button on the code blocks. I used clipboard.js for this and tweaked the style and position of the copy button to match my style. I also added JavaScript to make the copy operation ignore the numbered comment lines that are used to mark explanation points throughout the code.

PDF

The PDF was the most difficult to format as it doesn't use CSS but includes some other formatting options in a YML file, perhaps based on Postscript? I used AsciiDoctor to export the default PDF theme so I could see the format. Then I created my own PDF theme file, extending the default theme. This involved quite a bit of trial and error as I had to work out what the various styles were called and how to override them. I also wanted to create a dark mode version of the PDF, so I made a second theme file for that.

The two theme files are called pdf-theme.yml and pdfdark-theme.yml. They are both inside the theme folder. I used these in the Rakefile like this:

pdf_params = '-a pdf-theme=pdf -a pdf-themesdir=theme -a pdf-fontsdir=.'
output_name = book_title + '_v' + version_string + '.pdf'

sh "bundle exec asciidoctor-pdf #{pdf_params} #{syntax_params} #{params} -o #{output_name} book.adoc"

And:

pdf_params = '-a pdf-theme=pdfdark -a pdf-themesdir=theme -a pdf-fontsdir=.'
syntax_params = "--attribute source-highlighter=pygments --attribute pygments-style=github-dark"
output_name = book_title + '_v' + version_string + '_dark.pdf'

sh "bundle exec asciidoctor-pdf #{pdf_params} #{syntax_params} #{params} -o #{output_name} book.adoc"

As you can see, the -theme.yml part of the file name is not included in the command, just the base name. The pdf-themesdir attribute is used to point to the theme folder and the pdf-fontsdir attribute is used to point to the root folder. This worked because I had the font files in a fonts folder and included the folder path in the font specifications of the YML files.

For the PDF versions, I also added a header to every page with the book title and the chapter title using the YML files.

ePub

Finally, the ePub version. To my surprise, an ePub is actually a zip file. The contents are XHTML files, images and styles. The secret here was again to have files with the correct name in the correct location. In this case, I needed epub3.scss and epub3-css3-only.css in the theme folder. I left epub3.scss empty, but it still had to be there. The epub3-css3-only.css file had styles for where I wanted to override the defaults. It wasn't always easy to know what classes to apply the styles to, but I opened one of the XHTML files in my browser and used the web inspector to find them.

Writing Tools

The editor I used was Visual Studio Code. While it's not a native Mac app, it's a very powerful editor and has a fantastic array of extensions. I installed the AsciiDoc extension which allowed me to preview the AsciiDoc files in the editor.

There was a problem with previewing because of the image paths. The book.adoc file specifies the path to the images folder, but when previewing an individual chapter file, this was not applied. I had to add a line to the metadata at top of each chapter file to include the path to the images folder. I also added a header to show a table of contents to make it easier to jump around the file while editing. When building the entire book, these headers had to go - the image path over-rode the one in the book.adoc file and meant that book.adoc couldn't find any images, and a table of contents was included in every chapter. I ended up turning to Python again and wrote a script to add and remove these headers as needed.

I use GitHub to store the book files and to collaborate with my editor, or language engineer as he prefers to be called.

The other important extension is Code Spell Checker. Of course there will still be typos in the final book, but this extension helps to catch some of them. A big advantage of this spell checker is that it defaults to US English spelling. I normally write UK/Australian English, but I prefer to use US English for my books to avoid things like Create an NSColor is store the selected colour :-). Another big plus is that the custom dictionary is a JSON file stored in the project. That way my editor gets the same spell checking as I do, and I can easily edit the file if I want to delete or change a custom spelling.

All the code is written in Xcode using the default settings and theme as much as possible.

Screenshots are taken with CleanShot X and edited in Preview, which usually just involves cropping.

For hardware, my main computer is a 24" M3 iMac, my keyboard is an Ergodox Moonlander and my mouse is a Logitech MX Vertical. I also have a 13" M1 MacBook Pro for when I need to work in a different location.

Conclusion

AsciiDoc is just as easy to write as Markdown, but makes creating books vastly easier.

While creating all the files to format the first book took a lot of time and effort, I now have a template and subsequent books will start from that, making the process much less complicated. I imagine that I will keep tweaking the configuration and design as I go to make each format look better, but I now have the basic structure in place.

If anyone is interested, I am happy to share the template and the scripts I have written. Contact me using one of the links below or through the Contact page.

macOS by Tutorials

2024-07-23T09:49:12Z

In April 2022, Kodeco published the first edition of macOS by Tutorials. Nothing stays the same in the world of Apple development, so I started to plan an update after WWDC 2023. At around that time, Kodceo was going through a transformation from being like a library to being more of an educational institution. Their focus is now on multi-modal courses and they are no longer interested in publishing books.

Kodeco agreed to transfer the rights of the macOS by Tutorials book to me, since it was out-of-catalog and since then, I have been working on an update which is almost ready for release. I had hoped to have it out before WWDC 2024, but real-life has a habit of getting in the way, and that was not possible.

The book is now available at Gumroad.

If you previously bought the book from either Kodeco or Amazon, please email me for a 50% discount code. I am unable to provide a free update for the Kodeco version, but I will provide free updates subsequently for the self-published version.

Every project in this book has been updated to macOS 14 Sonoma and Xcode 15. They have also been tested using Xcode 16 beta 3.

The major changes in this edition include:

The On This Day app uses NavigationSplitView instead of the older NavigationView.
On This Day implements the new Observation framework for its data.
The Time-ato app no longer imports the external LaunchAtLogin package but now uses Apple's ServiceManagement library.
Creating an app intent in ImageSipper uses the new code-based system.
The workflow for distributing your app has been updated to reflect the changes in App Store Connect and Xcode.

As I am now a self-publisher, I will be able to release more timely and incremental updates and will incorporate the latest changes to macOS, Xcode Swift and SwiftUI as they are released.

To keep up-to-date with my books and other projects, please read my introduction and subscribe to my Gumroad newsletter. It will be very low volume, mainly about my own books.

Man Reader 2

2023-10-13T05:46:38Z

Several years after I started planning it, Man Reader version 2 is now available. This is a major update with a completely new, modern, user interface and it’s available from the Mac App Store.

Man Reader is a utility app for reading macOS's man pages. Man Reader allows quick, convenient and easy access to the man pages on your system, useful for programmers, system administrators and tweakers.

Complete re-write for modern versions of macOS.
Only runs on macOS Sonoma 14.0 or later.
Support for tabs and multiple windows.

Read all the details at the Man Reader support page.

Development Notes

Version 1.0 of Man Reader was released in 2012. It was written in Objective-C and it suffered from the MVC - Massive View Controller - problem, but it kept going.

Over the years, I added new features and fixed bugs, but as macOS evolved, it started looking its age.

I've been planning a major update for a long time, but I've been busy with other things so in 2021 I released an interim update to keep the app working and readable on the latest macOS.

This year, I finally got a decent break in my usual schedule and I was able to get to work.

The new version was always going to be in Swift. After writing Swift for years now, I am very comfortable with it and I write better and safer code in Swift than I can in Objective-C.

The difficult question was whether to use SwiftUI or AppKit as the basis for the app, understanding that whichever way I went, I could add in components from the other framework. This required several iterations to find the best solution.

I prefer working in SwiftUI so I started there first, but as I have written elsewhere, SwiftUI Lists, especially on macOS, do not handle large numbers of rows. This has improved a lot in macOS Sonoma but it's still not great. On my system, I have more than 10,000 man pages and that rises to over 25,000 if I include all of Xcode's commands. I tried a number of different approaches to make a SwiftUI List work, but then decided I'd have to use AppKit as the starting point for the app.

This solved the performance issue but caused others. I've got so used to SwiftUI's reactive data flow that I found it difficult to work with pure AppKit. There were also things that SwiftUI is just better at, like support for multiple windows.

So I went back to a SwiftUI base and embedded an AppKit NSTableView to handle the long list in the sidebar. This was interesting because I dislike creating an NSTableView via code - there are just too many components and settings that storyboards make simple. So for the first time, I embedded a Storyboard view into a SwiftUI view. I did this by adding an NSViewController with a xib file and then using that in an NSViewControllerRepresentable struct. This worked well and the published app has a SwiftUI base and an AppKit sidebar.

One feature that I was very keen to maximise was keyboard support. To a large extent, you can operate Man Reader without the mouse. The menus show most of the available shortcuts, but you can also press Tab or Shift-Tab to get to the two search fields. The sidebar is a table so you can use the arrow keys to navigate but you can also use type-select if there is no active cursor. Start typing to select the first page with a name starting with those characters.

One other design decision was to support the latest version of macOS only. The old version of Man Reader is still available for anyone on older systems, but I wanted to learn and use all the latest features of Swift and SwiftUI.

If you have any ideas for future versions or encounter any bugs, please email me or get in touch through the Contact page.

SwiftUI Data Flow 2023

2023-07-09T23:22:54Z

SwiftUI is a reactive framework where the data drives the UI. In 2019, I wrote a post detailing how I manage the various forms of data flow through a SwiftUI app, and with the help of others in the community, I iterated over this until I had a good understanding of the concepts and which methods you should use when. In 2021, I updated the post to cover the minor changes, but there have been no major modifications since then.

At WWDC 2023, things changed a lot! With the introduction of Swift macros, the SwiftUI team was able to reduce the number of property wrappers need to send data around, and remove a lot of boilerplate code.

For this article, I have re-written my sample app as a Mac app and updated it to use the new data macros.

Updated 10th July 2023 to cover changes in version 3 of all the betas.

With the release of all the version 3 betas, I have added these sections:

Observation

In the WWDC talk on Discover Observation in SwiftUI, Apple showed the following flow chart:

This is a good starting point, but I feel that it leaves out a few cases, so I've made my own:

Apart from adding some details to the decisions points, there are really only two additions to my chart:

If a property doesn't need to change, it can be a let.
@Bindable only works for classes. The equivalent for structs or primitive data types is still @Binding.

The new macros system removes this protocol and property wrappers:

ObservableObject
@ObservedObject
@EnvironmentObject
@Published

That's a lot of typing we don't have to do any more!

UPDATE 1:

I didn't make it clear originally, but all these property wrappers still work, and you can still use @Binding for classes, so you can adapt to the new Observation code incrementally. The Apple developer site has a very useful article on migrating from ObservableObject.

Sample app

My sample app demonstrates the following data flow options:

The code is available on GitHub and I recommend you download the project and follow along. It requires macOS 14 and Xcode 15. Currently I'm using macOS 14.0 beta 3 (23A5286g) and Xcode 15.0 beta 3 (15A5195k), but I will update this article with any changes as we work through the beta cycle.

Because Xcode 15 now supports live previews for Mac apps, you can test all the options from inside Xcode. In the Project navigator, expand the numbered groups and preview the first file in each group to view and interact with that data flow type.

Or go to the Bookmarks navigator where I've used the new bookmaking system to provide quick links to each one. You can even check off each one as you finish that section.

In the code snippets below, I include the essentials, but strip out most display modifiers and some similar views to keep the code short. The project contains the complete code.

Property

The first option is using a static property. We get so caught up in property wrappers that it's easy to forget that SwiftUI doesn't always need them. Using static text from a constant may seem like a simplistic and obvious example, but separating it out allows for localization or re-usability as well as making the view body neater and easier to read.

struct Property: View {
  // static property that never changes
  let greeting = "Hello from SwiftUI!"

  var body: some View {
    // Using the property directly in a View
    Text(greeting)
  }
}

My flow chart shows two use cases for let. This covers the first one where the view owns the property. The second is when a parent supplies the property to a view but the child view never changes the property. You'll see an example of this later on in this article.

A parent view may have some dynamic data that it uses to set properties in a subview where the subview only needs to display the data statically. This data will still change as the parent view changes but the subview will not be able to change the data itself or in the parent view.

If a view owns a property or gets it from a parent but doesn't need to change it, use let.

@State

This is where things start to get interesting in the SwiftUI world. SwiftUI views are contained in structs, so are non-mutable. Also, views are re-created every time the data changes, so any properties are re-created then too. By marking a property with the @State property wrapper, you are telling SwiftUI that you want it to keep this data in a separate portion of memory, allow it to be mutated, and preserve the current value during view refreshes.

struct UsingState: View {
  // Using @State as this view owns and can mutate the property
  @State private var counter = 0

  var body: some View {
    // Displaying and editing @State property
    VStack {
      Text("Counter = \(counter)")

      Button(action: {
        counter += 1
      }, label: {
        Image(systemName: "plus.circle")
      })
    }
  }
}

In this example, the counter property uses @State. The text view displays it and the Button view can change it. The button's action changes the counter which causes the view to redraw in order to display the new value, but the value of the @State property does not get reset to 0 every time.

Whenever a view owns the property and that property is mutable, declare it using the @State property wrapper.

@Binding

The Apple flow chart mentioned @Bindable but that only works with observable classes. For connecting structures or primitive data types to subviews, use @Binding. Apple does this internally for controls like Toggle and TextField.

A problem with building SwiftUI views is that it is very easy to end up with a gigantic Pyramid of Doom as you embed views within views within views. Extracting subviews is a great solution, but then you need a way to pass the data to a subview in a way that allows the subview to edit that property and have the edits flow back to the parent.

This is where @Binding and @Bindable come into play.

The Binding 1 example uses a primitive data type - in this case an Int. The parent Numbers view declares it using @State because it owns the property, and it displays the value. The Numbers view passes the property to the NumberChooser subview as an @Binding property by using the $ prefix.

struct Numbers: View {
  // Using @State as this view owns and can mutate the property
  @State private var stepperValue = 0

  var body: some View {
    VStack {
      // Display @State property
      Text("Parent view value = \(stepperValue)")

      // Pass to subview as a Binding ($) for two-way editing
      NumberChooser(stepperValue: $stepperValue)
    }
  }
}

The NumberChooser subview has this property marked with @Binding. It has no initial value as this view expects to receive the value from its parent view. NumberChooser has a Stepper for changing the value of the property. It displays the value after each change and you can see that the value displayed in the parent view also changes as the change flows back.

struct NumberChooser: View {
  // Using value from parent with 2-way binding
  @Binding var stepperValue: Int

  var body: some View {
    VStack {
      // Using bound state from parent with 2-way binding
      Stepper(value: $stepperValue, in: 0...20) {
        Text("Value in child = \(stepperValue)")
      }

      // Using bound state from parent as property
      // this view cannot change the value
      NumberBlock(stepperValue: stepperValue)
    }
  }
}

NumberChooser has its own subview - NumberBlock. This is purely a display view that never edits the value. NumberChooser passes it the value and it stores it as a let. Whenever the value changes, SwiftUI redraws the view with the new value, and the display updates. This demonstrates the second use of let that I talked about in the property section. There is no need to make this a var because it doesn't change - it gets re-created with every update.

struct NumberBlock: View {
  // As this view never changes the value, there is no need to bind it
  let stepperValue: Int

  var body: some View {
    Image(systemName: "\(stepperValue).square")
  }
}

@Binding for a Structure

The previous example showed how to use @Binding for a primitive data type like Int, String etc. But bindings also work for any value type, including structures, and that's what you can see in Binding 2.

While this is not very common, I enjoyed writing this example for a couple of reasons. Firstly, it shows how to draw the UI based on the different cases in an enum. Check out Pizza.swift which has three enums. Each of the picker views loops through one of these enums to draw the view.

Secondly, it demonstrates how you can pass portions of the data model to a subview, instead of sending everything everywhere.

PizzaView has a Pizza property declared using @State because this view owns the data. It draws a Form containing three different pickers. Each picker gets a binding to one of the properties of the pizza. A Text view shows the assembled data to confirm that the parent knows about any changes.

struct PizzaView: View {
  // Using @State for a struct
  @State private var pizza = Pizza()

  var body: some View {
    VStack {
      Form {
        // Using 2-way binding but each component
        // only needs 1 property from the struct
        PizzaNamePicker(selectedPizzaName: $pizza.name)
        PizzaSizePicker(selectedPizzaSize: $pizza.size)
        PizzaCrustPicker(selectedPizzaCrust: $pizza.crust)
      }

      // Text representation to prove that the
      // subviews are modifying the parent struct
      Text(pizza.pizzaSelection)
    }
  }
}

I won't show the code for all of the pickers, but here's the one to select the size:

struct PizzaSizePicker: View {
  // A single property of the Pizza struct is passed hare.
  // It's a Binding so data flows 2 ways.
  @Binding var selectedPizzaSize: PizzaSize

  var body: some View {
    Section(header: Text("Select your size:").font(.headline)) {
      Picker("", selection: $selectedPizzaSize) {
        ForEach(PizzaSize.allCases, id: \.self) { pizzaSize in
          Text(pizzaSize.rawValue.capitalized)
        }
      }
      .pickerStyle(.segmented)
    }
  }
}

If you're passing a primitive data type or a struct to a subview, and the subview can change the value of this property, use @Binding in the subview and pass the property with a $ prefix.

@Observable and @Bindable

So far, the examples have been largely the same as before. Now the new property wrappers appear. The first big change is in the model class: ColorSet.

import SwiftUI
import Observation

@Observable class ColorSet {
  // Observable class
  // The color components are not private so any changes
  // get published to the views that are observing

  var foregroundRed = 0.0
  var foregroundGreen = 0.0
  var foregroundBlue = 0.0

  // Computed variables to create the RGB colors from the components
  var foregroundColor: Color {
    return Color(red: foregroundRed, green: foregroundGreen, blue: foregroundBlue)
  }
}

The first thing to notice is the new import: Observation. This is the library that supports the new @Observable macro. Previously, ColorSet conformed to the ObservableObject protocol and the properties that needed to be observed were marked with the @Published property wrapper.

Now the class uses the @Observable macro and any property that isn't private, is automatically published. This is only available for classes, not structures.

UPDATE 2:

~~The properties must all have an initial value - setting them in an init is not sufficient and will not build.~~

In beta 3, observed properties no longer require an initial value. For this class, I actually want to specify initial values, but in the next section, I do not.

If you want a look at what's happening inside the macro, right-click on @Observable and select Expand Macro. When you've finished, right -click again and choose Hide Macro Expansion.

While this is not something I can read comfortably, it shows how macros are regular Swift code that saves a lot of typing, but are not doing magical things invisibly in the background.

Now that the model uses the new macro, how do we use it?

Again, the owning view declares it using @State.

struct ColorSetView: View {
  // Using an Observable for reference-based data (classes)
  @State private var colorSet = ColorSet()

  // ...
}

The ColorSetView uses the data to add color modifiers to the view background and to a system image of a cat.

But the next change is when sending the data to the ColorChooser view. This needs two-way binding so the current values can be passed to the chooser and any changes can be passed back. But with the new Observation methods, this uses @Bindable and not @Binding.

First, the ColorChooser gets the colorSet property, but this doesn't need the $ prefix.

ColorChooser(colorSet: colorSet)

The ColorChooser view receives it as @Bindable and can in turn, pass it down to its subviews, again using the @Bindable technique which requires no $ prefixes.

struct ColorChooser: View {
  @Bindable var colorSet: ColorSet

  var body: some View {
    // The chooser subview also get passed the Observed
    ForeColorChooser(colorSet: colorSet)
  }
}

There is one oddity to beware of. When declaring the original colorSet property, I use @State but if I declare it as a simple var, the app still works. Don't do this!

If you remember the older code style, the owning view initialized an ObservableObject using @StateObject. Subsequent views declared the same property using @ObservedObject but it was very important for the owning view to use @StateObject to avoid strange and difficult to trace bugs. The app worked if you used @ObservedObject instead of @StateObject for the original declaration, but then odd things could happen.

I think this is the same, and it's just as important for the owning view to declare the original property using @State.

@Observable and @Bindable List

In the original post, this was the section that gave me the most trouble - having a list of data objects where each one could be edited and updating the original list to show the edits.

This is now a lot easier, although it took me some time to realize this.

I have a sample data file and a Person model class using @Observable. The PersonListModel class holds an array of these Person objects and it also uses @Observable.

I wanted to make the selection of the list point directly to a Person instead of going through an id, so I added this extension to Person:

extension Person: Hashable, Equatable {
  func hash(into hasher: inout Hasher) {
    hasher.combine(id)
  }

  static func ==(lhs: Person, rhs: Person) -> Bool {
    lhs.id == rhs.id
  }
}

Then I was able to set up a List to display the names of the people, with the list's selection bound to an optional Person. I had to add a tag to the person, I presume the tag is set to the id by default.

List(selection: $selectedPerson) {
  ForEach($personList.persons) { $person in
    Text(person.fullName)
      .tag(person)
  }
}

Two important things to see in this code snippet:

The contents of the ForEach is a binding as you can see from the $ prefix
The argument passed in to each entry in the list is also a binding.

These two bindings make the list respond to edits.

With this in place, it was time to think about an editor and I decided to try out the new inspector. Unfortunately, unlike with sheets, you can only trigger an inspector with a Boolean so I added an event listener to set the inspector trigger:

.onChange(of: selectedPerson, { oldValue, newValue in
  shouldShowInspector = newValue != nil
})

After that, I added this inspector modifier:

.inspector(isPresented: $shouldShowInspector) {
  if let selectedPerson {
    PersonEditView(person: selectedPerson)
  }
}

Even though shouldShowInspector is only true when there is a valid selectedPerson, force unwrapping causes a crash as it appears that the inspector tries to draw itself off-screen on launch.

The PersonEditView in the inspector receives the person as @Bindable and populates the fields on a form. And editing the data flows right back to the list.

This took a lot less code than the previous version. Part of the improvement was the ability to use bindings in a list, which we got last year, but another big part was using the Person directly as the selection. This needs the Hashable and Equatable conformance, which I think should be a standard part of Identifiable, but once that's in place, all the data flows smoothly.

If I was using a sheet for the editor, it would be even neater as I could tie the sheet's appearance to selectedPerson.

When you have a model class and you want changes to be published, declare the class with the @Observable macro. The owning view declares the model using @State and can pass it to editing subviews using @Bindable or to display subviews as let.

@Environment

The last section is Environment, which again, has changed a lot. The benefit of using Environment is that the data flow doesn't have to be unbroken. In the sample app, the parent view (NestedViews) uses the Environment property and so does the GrandChildView, but the ChildView in the middle doesn't.

Setting up a property for Environment is the same as for Observable.

import Observation

// An Environment class is just like any Observable class
@Observable class UserSettings {
  var isLoggedIn: Bool = false
}

The difference is in the way that you use it. When creating the first view that needs this environment value, use an environment modifier to inject the initial value. In the sample app, this happens in DataLink.swift which displays the view for each example.

NestedViews()
  .environment(UserSettings())

To access this property, declare an Environment property with a key path, which is its type, in this case UserSettings.self.

struct NestedViews: View {
  // The injected environment property is accessed by type and assigned a name
  @Environment(UserSettings.self) private var userSettings

  var body: some View {
    // ...
  }
}

This is similar the way we use built-in environment values like colorScheme, openWindow and so on. Use this same declaration in any view that needs access.

Previews need to get access too, like this:

#Preview {
  // The environment object must be injected into the preview too.
  NestedViews()
    .environment(UserSettings())
}

And even though ChildView doesn't use the environment object, because its preview contains GrandChildView that does, it also needs the environment modifier in its preview, but not in the main view code.

In the sample app, the various nested views are brightly colored to show which is which. Using the Log In or Log Out buttons works on either the outer view or the inner view with the data being synced between them.

If you have a class that is global to your app, like UserSettings in this example, declare the class with the @Observable macro. Inject it into your view hierarchy using .environment and then use @Enviroment to access it.

UPDATE 3:

There is one aspect of using @Enviroment where things get tricky, and that's if you need to use any properties of the environment object as bindings for other controls.

I added a Toggle to GrandChildView and wanted to connect it to the same userSettings.isLoggedIn Boolean. A toggle takes a binding, so normally, I'd do this by adding the $ prefix to the property to bind.

With @Environment, this gives an error:

The solution is to create an intermediary @Bindable property from the @Environment property and bind it to the toggle (or any control that needs a binding).

Stripping out a lot of what was there, the code becomes:

struct GrandChildView: View {
  @Environment(UserSettings.self) var userSettings

  var body: some View {
    @Bindable var userSettingsBindable = userSettings

    Toggle(isOn: $userSettingsBindable.isLoggedIn, label: {
      Text("Log In Status")
    })
  }
}

You declare the @Environment property as usual, then inside the body, declare an @Bindable property with the value from the @Environment property. You have to do this inside the body because doing it outside gives an error.

Surprisingly, I didn't have to add a return before the Toggle, even though it was no longer the only statement in the body.

Thanks to Stewart Lynch for suggesting I add this. Hopefully it will be fixed soon but until then, this is the workaround.

Wrapping Up

There are two issues I want to discuss before ending.

First is the use of private for view properties. Apple recommends marking every @State property as private. It seems a bit strange as you then pass them around and sometimes the subviews change the data, but it means that no object can edit the value unless the view has expressly given permission. I presume there are security and performance benefits to this.

Similarly, @Enviroment properties can (and I presume, should) be private. The two binding property wrappers do not allow their properties to be private.

And lastly, in @Observable classes, everything that is NOT private is published. This is the opposite to what we had before where you had to explicItly state which properties were published. So mark properties as private if they should not be published.

The other issue is to do with using var on its own i.e. without any property wrapper. The Apple flow chart suggests doing this if you get to the end of the flow without making any other decision, but I think you should use let in this case. The only time I use a plain var in a view is for computed properties, otherwise I use let.

In my flow chart, I left the appropriate end point showing var or let, to better match Apple's, but I recommend using let and only changing to var if Xcode complains. This is a good rule for any Swift code, not just SwiftUI.

This article may get several updates before we exit this years beta cycle, but I thought other people might find it useful. Writing it certainly helped clarify the new options in my head.

If you have any suggestions, ideas or corrections, please contact me using one of the links below or through the Contact page. And if you found this article useful, I'd love you to buy me a coffee.

macOS Apprentice

2023-06-28T23:48:37Z

I've written another book! This one is for people who want to get started in macOS development and here it is: macOS Apprentice, published by kodeco.com (formerly raywenderlich.com).

If you’re a beginner or near-beginner who wants to start learning Swift, SwiftUI and AppKit for building Mac apps, then this is the book for you.

The book consists of four sections:

Section 1: Install Xcode and learn the basics of programming in Swift. Experiment with several different ways to execute Swift code on your Mac.

Section 3: There are still a number of tasks where AppKit works better than SwiftUI. In this section, build an AppKit app to browse movie data from IMDb, the online movie database.

Section 4: Add AppKit to your SwiftUI app and add SwiftUI to your AppKit app in order to add some finishing touches to both of the apps from the previous sections.

You can read more details of the book contents in the Introduction.

Where can you read the book?

You can read it online at kodeco.com as part of a Kodeco subscription.
You can download an ebook (ePub or pdf) at the same page if you have a subscription or buy one there if you don't.
The paperback is available at Amazon.

All the code and extra materials for the book can be downloaded or cloned from GitHub.

For support, to ask questions or to report any errors, please go to the forum.

Thanks to...

This book was made possible by an awesome team. There were a lot of people involved, but I want to give special thanks to:

Richard Critz, the wonderful editor who had the unenviable task of fixing my grammar.
Audrey Tam and Ehab Amer were the amazing tech editors who had to make sure that it all worked. Audrey also contributed the first chapter on installing and setting up Xcode.

Feedback

I would love to hear from anyone who read the book, loved it, hated it, found an error or just wanted to say hello.

You can contact me directly using any of the contact links at the bottom of this page or through the Contact page.

Sparkle

2023-04-11T01:48:38Z

Last month, I posted about writing my new todo app called To-Day: why I wrote it and how I wrote it. At the time, I mentioned that I had set it up to install updates using Sparkle but there was too much detail to include in the initial post. So here, as promised, is the article about implementing Sparkle.

One of the great conveniences of App Store distribution is the update handling. When (or if) an update passes the app review process, Apple does the rest, propagating updates through the App Store app. If you're distributing your apps externally, you need an alternative method.

Sparkle is an open-source update framework for macOS. It's very popular and I'm sure you will have seen it used, even if you didn't recognise it. But setting it up isn't totally straight-forward, at least I didn't find it so, which I why I'm using this post to document the process.

The Sparkle documentation is excellent and contains everything you need to know, but they allow for a wide range of use cases and configurations, which makes it difficult to follow at times. For this app, I have the following requirements:

SwiftUI app
Sandboxed
Install framework using Swift Package Manager
Distribution as a disk image

This guide deals with those requirements only.

Installation

Open your app in Xcode and select the project at the top of the project navigator. Click on the project itself in the next sidebar and then choose Package Dependencies from the tabs across the top.

Click the + at the bottom of the list to add a new package. Enter this URL into the search field and when the package appears, click Add Package.

https://github.com/sparkle-project/Sparkle

Xcode will download the package and then show another dialog with the Sparkle library checked. Click Add Package again to attach it to your project.

Adding a Public Key to your App

The next step depends on whether you've used Sparkle before. You need to create a private and public key pair for security reasons, but you can then use the same keys for all of your apps (I think).

Checking for a Existing Key

To check if you already have a key, open the Keychain Access app from Applications/Utilities. Search for sparkle and if you have a key, you'll see it listed. If you don't find anything, skip ahead to the next section to create a new one.

Double-click the key to show its details which conveniently includes the public key in the comments.

Select and copy the public key, then jump to Installing the Public Key.

Creating a New Key

If you don't already have a key pair, you'll use one of Sparkle's tools to create it.

Back in Xcode, right-click on Sparkle in the project navigator and select Show in Finder which opens a folder buried deep in your Library. Press Command-3 to show the folder in Columns mode and then click the artifacts folder that's one level above the Sparkle folder.

From there, navigate through sparkle to Sparkle where you'll see a bin folder:

Open your preferred Terminal app and type cd followed by a space. Drag in the Sparkle folder with the uppercase S.

Then enter and run this command:

./bin/generate_keys

This generates the keys, saves them to your keychain and displays the public key. Copy the public key for use in the next section.

Installing the Public Key

To insert the key into your app, go back to Xcode and select the project and target. Choose Info from the tabs at the top. Click the + blob that appears beside the last entry when you mouse over it, and type in the key name:

SUPublicEDKey

The type is String (which should be the default) and the value is the public key you just copied:

Sandboxing

Mac apps are sandboxed by default, which quarantines their data into their own container and protects the rest of your system. Adding Sparkle to a sandboxed app requires some more steps, but if your app is not sandboxed, move on to the next section.

First, you need to give your app access to the internet, so it can retrieve the update information and download any updates.

In the app's target settings, select Signing and Capabilities and turn on Outgoing Connections (Client):

Next, add another setting to the target's Info:

Key: SUEnableInstallerLauncherService
Type: Boolean
Value: YES

The next settings go into the <Your-App-Name>.entitlements file which you'll find in the project navigator. Right-click the entitlements file and select Open As > Source Code which makes it possible to paste in the next chunk.

Just before the last </dict>, add a new line and insert:

  <key>com.apple.security.temporary-exception.mach-lookup.global-name</key>
  <array>
    <string>$(PRODUCT_BUNDLE_IDENTIFIER)-spks</string>
    <string>$(PRODUCT_BUNDLE_IDENTIFIER)-spki</string>
  </array>

Now the app is configured to allow Sparkle to work with the Mac sandbox.

Locating the Updates

You need to have an online location for the app and its update information. Since my To-Day app is on GitHub, I decided to use GitHub for distribution too, but I could have used this web site, AWS or any other online service. It's best if it's coming from an https server.

Open my GitHub repo and look at the file structure. The Releases folder has a disk image (dmg) containing the app and an XML file generated by Sparkle with the update information.

Work out where you're going to put these two files for your app and find the exact URL for the appcast.xml file.

This gives you the last piece of data that your app needs. Add another setting to your target's Info:

Key: SUFeedURL
Type: String
Value: https://url-to-your-appcast.xml

If you're using GitHub, upload a fake file so you can get the URL, remembering to get the URL for the raw file, not its GitHub page.

Coding the Update Check

You've done all the setup work now, but there's nothing to trigger a check in the app. I copied and pasted most of the suggested code from the Sparkle docs.

First, I created a new file called Updater.swift which contains:

import SwiftUI
import Sparkle

// This view model class publishes when new updates can be checked by the user
final class CheckForUpdatesViewModel: ObservableObject {
  @Published var canCheckForUpdates = false

  init(updater: SPUUpdater) {
    updater.publisher(for: \.canCheckForUpdates)
      .assign(to: &$canCheckForUpdates)
  }
}

// This is the view for the Check for Updates menu item
// Note this intermediate view is necessary for the disabled state on the menu item to work properly before Monterey.
// See https://stackoverflow.com/questions/68553092/menu-not-updating-swiftui-bug for more info
struct CheckForUpdatesView: View {
  @ObservedObject private var checkForUpdatesViewModel: CheckForUpdatesViewModel
  private let updater: SPUUpdater

  init(updater: SPUUpdater) {
    self.updater = updater

    // Create our view model for our CheckForUpdatesView
    self.checkForUpdatesViewModel = CheckForUpdatesViewModel(updater: updater)
  }

  var body: some View {
    Button("Check for Updates…", action: updater.checkForUpdates)
      .disabled(!checkForUpdatesViewModel.canCheckForUpdates)
  }
}

The comments are from the Sparkle team.

In my To-Day app, I have an AppGroup view to provide the SwiftUI view for the last section of the menu that controls the app itself.

Inside this view, I added an updaterController property:

private let updaterController = SPUStandardUpdaterController(
  startingUpdater: true,
  updaterDelegate: nil,
  userDriverDelegate: nil
)

This required another import Sparkle line at the top of this file.

To trigger the update checker, I added CheckForUpdatesView as one of the views in the menu, providing it with this controller's updater:

CheckForUpdatesView(updater: updaterController.updater)

Exporting the App

Now that the app is coded, you need to export it from Xcode, signing it with your Developer ID and getting it notarised by Apple. This assumes that you have an Apple Developer account.

In Xcode, select Archive from the Product menu. This builds the app and opens the Organiser window. Click Distribute App, check Developer ID and click Next.

Make sure Upload is selected and click Next again. Choose Automatically manage signing and click Next again. When the next dialog appears, click Upload.

This sends the app off to Apple's servers to be checked for malicious code. It's not doing any app review, just checking for viruses etc.

It may take a few minutes, but the app should then be notarised. You may have to go to another display in the Organiser and back again to force a display refresh so you can see this. If there is an error, click Show Status Log to see what went wrong.

Assuming all went well, click Export Notarised App and save it somewhere convenient.

If you don't have an Apple Developer account, select Copy App from the distribution dialog and save a folder containing the app. If a user has the default Gatekeeper settings on their Mac, they'll need to right-click the app and select Open to run it, after getting past a couple of warnings.

Making a Disk Image

The next step is to create the disk image for distribution. You can use a zip file or a disk image, but I prefer a disk image because it gives you a way to guide users to install the app in their Applications folder.

The process for this is:

Make a writeable disk image.
Add the app and a link to Applications.
Set the view options, including a background image.
Convert the image into a read-only copy.

Open Disk Utility from Applications/Utilities. Select New Image > Blank Image… from the File menu. Set its name in two places and its size. The size should be about 2 x the size of your app to allow for future updates.

Double-click the image to open it and drag your exported app into the disk image window. Command-Option-drag your Applications folder in. You'll know you're holding down the right modifiers if you see a curved black arrow at the bottom left of the icon. This adds an alias to the current Applications folder, rather than a copy of yours.

Now configure the disk image window using Finder's View menu and View Options. I turn off all the extra views: toolbar, path bar, status bar etc. then I set the view options like this:

Setting a background image takes a few steps. First, find an image you like. Not being graphically minded, I used a rectangle filled with a gradient and added a curved arrow that pointed from the app to the Applications folder. My file is a png, but I think a jpg will work fine. You can click this link if you want to see my sample background image.

Drag the image file into your disk image. Don't worry about positioning it - you're about to make the file invisible. With Finder active, press Shift-Command-. to show invisible files. Now, rename the background image file to .background.png. The leading period makes this an invisible file, but you can see it at the moment. Open the View Options again and select Picture for the Background. Drag your image file into the well. This may show that you need to re-position the arrow, so repeat the process until you get an image that looks right. Then press Shift-Command-. again to hide invisible files. Re-position the visible icons to suit and adjust the size of the window to what you want to show.

Now that the disk image is configured, eject it. Back in Disk Utility, select Images > Convert… and choose your dmg. On the next dialog, change Image Format to read-only and click Convert. This is the disk image that goes into your Releases folder, so change its name to match your app and move it. Keep the read-write disk image too - it's much easier to edit it when updating instead of going through this process every time.

Open the read-only image and check that it's set up the way your want. I have found that sometimes the background image doesn't stick. If this happens to you, eject and trash the read-only image. Mount the read-write image again, confirm its settings and re-convert.

Generating the appcast.xml

Now to create the file that Sparkle uses to see if there is an update.

Use the method from when you generated a key to open a Terminal at the Sparkle directory. Type in:

./bin/generate_appcast /path/to/your/Releases/folder

Once you're typed the command and a space, you can drag your Releases folder in to get its path. Press Return and wait while Sparkle generates the appcast.xml file.

And finally, you're ready to release. Upload your Releases folder to wherever you decided to put it, making sure that the URL for the appcast.xml file is the same as in your app's info.

Testing

Move the notarised app into your applications folder and run it. If all has worked, you should be able to check for updates and see that you have the latest version.

If you get an error, check back through all the setup phases. I know I made every mistake possible when setting it up first, so check the sandbox setting, the info and the entitlements. Use a web browser to confirm that the appcast.xml file is where you said it would be.

Testing an update requires a new version, so make some small, visible change to your app. Increment the version and build numbers, then archive, notarise and export as before. Find the read-write disk image and mount it. Replace the app there with your new version and then eject the disk image. Create a new read-only disk image and replace the copy in your Releases folder with it.

Run the ./bin/generate_appcast again and it will add a new entry to your appcast.xml file with the new version data.

If you want to add some release notes, open appcast.xml in a text editor. The top entry is the latest. You can include a description tag and if you use the <![CDATA[ ... ]]> wrapper, you can add HTML:

Upload the Releases folder as before and then run your first version of the app. Check for updates and see what happens.

If it doesn't work, check the Console app and see if you can see any errors there that might point you in the right direction.

This can be a frustrating process, but once you have it all set up correctly, it works very well. I added a ReadMe to my project listing the steps I need to follow when publishing an update, so that I don't have to remember them every time. I recommend this or something similar.

Summary

Sparkle is a great tool and once you have everything configured, it works really well. Configuring it can be tricky, especially as their docs cover so many different use cases.

Check out the GitHub repo for my To-Day app to see how I've configured it.

If you have any suggestions or if you run into any problems following this guide, please contact me using one of the links below or through the Contact page. And if you found this article useful, I'd love you to buy me a coffee.

To-Day

2023-03-08T04:58:01Z

When I sit down at my computer at the start of a work day, I typically like to plan out the broad outline of my work. This is the three or four major tasks for my day. I don't want a minute-by-minute plan, just a list of the major items, so that I can check them off as I work, and get to the end of the day without feeling like I've forgotten anything.

There are a ton of todo apps and web services available, but they all provide much more than I need. When I factored in how I wanted to learn about writing a Mac menubar app in SwiftUI, the solution was obvious - write my own.

First things first: the project is open-source and on GitHub so feel free to download it, fork it, edit it, create pull requests, file issues or whatever you like. If you just want to install the app, you can download the disk image. It requires macOS 13.0 or later.

I'm not going to go through the entire app in detail. You can download the project and check out the code to see it all. I'm just going to give some details about the app structure and architecture as well as mentioning some code that I found new or interesting.

The App

I've written menu bar apps using AppKit but this is my first serious look at SwiftUI's MenuBarExtra. Configuring the app to be a menu bar app has three steps:

Remove the WindowGroup from your app body.
Add a MenuBarExtra to your app body with some views to show in the menu.
Insert an entry into Target - Info, setting Application is agent (UIElement) to YES.

You can then delete ContentView.swift from the project since nothing uses it.

Looking at the first screenshot, you can see that I've split the menu into four sections. The first one displays the actual todos and handles checking them off. This view is provided by the main data object.

The other sections are static and deal with editing the todos, configuring the app settings and managing the app itself. Each of these is split off into a separate view file to keep the main app body as uncluttered as possible. The files for these three sections are in the Menu Views group in the Xcode project.

Editing the todos caused the most issues with the app and took several iterations, but I'm pleased with this version:

I tried lots of ways of tracking the focus and adding keyboard commands to move items up and down the list but in the end, I went for simplicity. The editing is embedded in a Form. This means that I get the standard tabbing behaviour by default, but I also get the small toggle switches, which I really like.

The main view for this is EditView and it, with its subviews, are in the Edit Views project group.

I'll discuss the Models group and the data flow in a minute, but to finish describing the app structure, the AboutView tells you more about the app. I love being able to use basic Markdown styling in Text views. And I learnt a good lesson: if you're having trouble with truncated text, check out the fixedSize modifier.

Finally, Updater is a class to handle using the Sparkle updater, which deserves its own post. I must have made every possible mistake when implementing this, so I think a guide would be useful, for future me if for nobody else.

The Data

I like to use the VOODO pattern, which stands for View - ObservableObject - DataObject. Working backwards through this, the DataObject is a struct that contains the properties for a single Todo item. The ObservableObject is a class called AppState that contains a published array of todo items as well as a DataStore struct for saving and loading. The View is the menu itself.

AppState also contains a bunch of computed properties to make life easier and methods for adding, deleting and checking. It also has a computed property to generate the view for the todos at the top of the menu.

When you have an ObservableObject, you can pass it around the app in two ways: as an ObservedObject or as an EnvironmentObject. Both work fine, but with the ObservedObject, there has to be an unbroken chain of data passing from view to subview to sub-subview and so on. EnvironmentObject makes it easier because once you insert it into a view hierarchy, any view in that hierarchy can access it.

It might seem like EnvironmentObject is less efficient, but I've read recent reports of it using less memory, perhaps because intermediate views that don't need it, don't access it.

I decided to use EnvironmentObject so in the App struct, I initialised it as a StateObject. MenuBarExtra can't take an environmentObject, so I grouped the menu view sections and assigned the environmentObject to the Group. This let the views in the menu access it using @EnvironmentObject var appState: AppState.

Windows

Even though this is a menu bar app, I wanted to be able to open two windows: one for editing the todos and one for showing some info about the app.

For each of these, I added a Window scene to the app. A Window scene differs from a WindowGroup in that it only opens one copy of the window. If you try to to open it a second time, it activates the original rather than opening another.

Back of these windows has a title and an id. The id is used by the openWindow Environment value to show the window and the title is the window title. The contents of the scene is the view that appears in the window.

The Edit window also gets the EnvironmentObject so it can access the data. Both have a defaultSize - this only applies to the first opening - after that, the app uses whatever you set. The About window also gets a defaultPosition (which I am not sure works) and a windowResizability modifier to make sure that the window can't be bigger than the size needed to show the content.

Launch on Login

Getting an app to launch when the user logins in used to be a lot of work. Thankfully, we now have access to SMAppService which makes it much easier. And that's why the app is only for macOS 13 or higher.

To tell whether an app is set to launch on login, import the ServiceManagement library and run this code:

SMAppService.mainApp.status == .enabled

And to change the setting, use:

try SMAppService.mainApp.register()

Or:

try SMAppService.mainApp.unregister()

The really neat thing about this is that people can now see what apps will launch on login, unlike with the previous system where this data was hidden deep in the Library folder. Go to System Settings - General - Login Items to check it out.

Saving Changes

I wanted to save the todos whenever the user made a change, but with a debounce so it didn't save after every keystroke.

After a bit of research, this is what I used:

var saveTask: DispatchWorkItem?

func debouncedSave() {
  self.saveTask?.cancel()

  let task = DispatchWorkItem { [weak self] in
    DispatchQueue.global(qos: .background).async { [weak self] in
      if let self {
        self.dataStore.saveTodos(todos: self.todos)
      }
    }
  }

  self.saveTask = task
  DispatchQueue.main.asyncAfter(deadline: DispatchTime.now() + 0.5, execute: task)
}

I added a didSet property observer to the todos array, which calls this function after every change. This cancels any existing task, creates a new one and schedules it for half a second later. If no other changes occur in that half-second, the app saves, using a background queue.

The DataStore struct saves and loads the data as JSON, storing it in the Documents folder inside the app's Container.

Distribution

Typically, I use the App Store to distribute my apps. Apple handles all the business side of things and it makes distributing updates easy.

But lately, it seems that the App Store review process has become even more capricious, blocking good apps for spurious reasons, while utterly failing in their stated mission of "keeping us safe" from obvious scams, copycat apps and fake reviews.

So for this app, I have decided not to charge for it and to distribute it myself. I'm using GitHub both as the open-source repository, and as the app distribution source.

If you enjoy using the app, I'd love to hear from you. There are contact details at the bottom of the page. And if you really want to contribute, please buy me a coffee.

Updating is the missing piece in this puzzle, but that is a sufficiently large topic that I intend to write a follow-up post detailing how I set up Sparkle and eventually got it to work.

Conclusion

So, how does this compare with writing a Mac menu bar app in AppKit? A lot of things are easier in SwiftUI, but one thing I miss is being able to set up a menu delegate to track when the menu is opened or closed. There doesn't appear to be any way to do this for a MenuBarExtra - it can't have an onAppear or onDisappear modifier and scenePhase detects nothing.

For this app, it's not really a problem, but I have used other apps where it would be a real showstopper.

And what's next for this app? I'll use it in my daily routine for a while and see what I like, what I hate and what extra features I'd like. One possibility is to add some global shortcuts. This requires hooking into the Accessibility settings, which I am reluctant to do, so I'll need to think about this.

If you have any ideas or feature requests, create an issue on GitHub, or fork and edit the project and then create a pull request.

New Links

2022-12-16T22:47:35Z

As we round out the year, there are several new addresses I'd like people to use to contact me or get my book.

First, raywenderlich.com has re-branded to Kodeco. Still the same great content created by terrific people, but with a fresh new design that makes it easier to follow the learning path that you prefer.

If you want to read my macOS by Tutorials book, it's now at kodeco.com/books/macos-by-tutorials.

As we all know, Twitter is in meltdown and I no longer use it. I'd love it if you came over to Mastodon. People on Mastodon are friendly and sharing. It feels much more like a community.

Movetodon is a great tool for finding your Twitter friends on Mastodon and Fedi.tips is a useful site for learning how to use Mastodon effectively.

My suggestions are:

Be nice!
Don't stress about choosing a server, you can follow anyone from any server and you can transfer your account to a different server if you change your mind.
Follow hashtags as well as people, and add hashtags to your posts.
Use Favorite to tell people you liked their post and Boost to share with your followers.
Add hashtags using UpperCamelCase to assist screen readers e.g. #AdventOfCode, not #adventofcode.
Follow me: @troz@mastodon.social

I look forward to seeing you there.

I've added a Mastodon link to my web footer, but I also created a LinkTree to gather all my links into one place.

And finally, if you want to support my work, please buy me a coffee.

SwiftUI for Mac 2022

2022-06-17T04:18:32Z

In December 2019, I wrote a series of articles about using SwiftUI to build a Mac app. And in July 2020, I re-visited the sample app to apply the new SwiftUI features made available in macOS BigSur. Now that macOS Ventura and Xcode 14 are in beta, it's time to build the app again while learning how to incorporate the new APIs.

Right now, it's June 2022 and I'm using macOS Ventura 13 beta 2 (22A5286j) with Xcode 14 beta 2 (14A5229c). There will undoubtedly be changes before release, but I'll try to update this article or add notes to point out any major differences.

I don't intend to cover features that haven't changed much, but here are the new APIs that I am interested in:

Note: In Xcode 14 beta 2, the SwiftUI Previews are crashing unless I go to Project > Target > Signing & Capabilities and select my developer team and set Signing Certificate to Development. So if you can't see the Previews, make these changes, or run the app directly.

Navigation

The first version of this app used a two pane layout with a sectioned list in the sidebar leading to a detail view in the main area. With the Big Sur version, I switched to a three pane layout because the sections were not displaying neatly. This time, I've reverted to two panes with sections. As before, I'm using HTTP Cats which is a site that serves up a cat image to match almost every HTTP status code.

Previous versions used NavigationLinks inside a NavigationView. NavigationView is now deprecated and we should use either NavigationStackView or NavigationSplitView. NavigationStackView is better suited to a small screen where each view is pushed on to a stack and can be popped off to navigate back. I am going to use NavigationSplitView which works well for bigger displays with all the panes visible at once.

My data model is exactly the same as I developed originally and consists of an array of HttpSections, each containing an array of HttpStatuses. So I was able to render my navigation like this:

NavigationSplitView {
  List(httpSections, selection: $selectedStatus) { section in
    Section(header: Text("\(section.headerCode) - \(section.headerText)")) {
      ForEach(section.statuses) { status in
        SidebarRowView(code: status.code, title: status.title)
          .tag(status)
      }
    }
    .font(.headline)
  }
  .frame(minWidth: 250)
} detail: {
  DetailView(sectionTitle: sectionHeader, httpStatus: selectedStatus)
}

The NavigationSplitView takes various parameters, depending on the result you want. In this case, the first parameter lays out the sidebar, which is a List. The detail parameter contains the detail view. For the List, I loop through the sections, adding a section header for each one and a custom SidebarRowView to display the individual status entries. The List selection is bound to an optional HttpStatus. The key here is to give each row a tag that maps to the status displayed in that row. If you omit the tag, the sidebar draws but none of the entries are selectable.

Interestingly, when you create a navigation setup like this, Xcode automatically adds a toolbar with a button to toggle the sidebar. This has always been essential as there is a long-standing bug where a hidden sidebar cannot be dragged back into view. But adding it manually meant digging into AppKit to find a method to call.

Not so interestingly, the sidebar is often hidden on app launch. I tried giving NavigationStackView its optional columnVisibility parameter, but no setting made it appear consistently.

With the detail, right now there is a bug where you cannot unwrap a conditional and show a view based on that. One workaround is to wrap the entire detail in a ZStack, but in the interest of keeping my ContentView code simple and as short as possible, I added an intermediary view. DetailView takes optional parameters and it decides whether to show the StatusView or a placeholder. Note: the bug may have gone in beta 2, but as I want to display other UI elements in the detail view anyway, this is still a neater approach.

There is nothing much new in either of these views, except where StatusView downloads the selected cat image. I tried using AsyncImage which worked really well except for one problem. When I selected a new status, the old image stayed in place until the new one arrived. I was unable to work out how to clear or reset an AsyncImage so it would show its placeholder again.

Update: Thanks to @ramzesenok who pointed out that this is another case where I could use an id to force a refresh. So now, the app uses AsyncImage which makes for a lot less code.

AsyncImage(url: httpStatus.imageUrl) { img in
  CatImageView(catImage: img, statusCode: httpStatus.code)
} placeholder: {
  ProgressView()
}
.id(httpStatus)   // this resets the AsyncImage whenever httpStatus changes

If anyone is still interested in the async/await version, check out this earlier commit on GitHub. It does appear to have better/faster caching, but a beta is not the right place to make speed assessments.

~~However I did switch to using async/await to download the image.~~

Updating this was also slightly complicated. I downloaded the first selected image using a task modifier and downloaded subsequent selections using an onChange modifier. Both of these were required to show the image every time.

~~Thanks to @davbeck, @malhal and @chriseidhof for pointing out that if I gave the task an id, it would be called whenever the id property changed.~~

~~The previous image is first set to nil, so that the progress indicator appears.~~

With all this in place, I had the basis of the app and the navigation was complete:

Detecting the Active Window

macOS apps can have multiple windows open at once, and in previous iterations of SwiftUI, it has been difficult to detect the active one. Last year, we got @FocusedBinding but it didn't really work. This year it works, but we also have a new EnvironmentValue called controlActiveState.

As I did last time, I set up some menus by adding a commands modifier to my WindowGroup in the main _App.swift file. First, I added the pre-built SidebarCommands() which added a menu item and keyboard shortcut for toggling the sidebar. Next, I added a menu item for flipping the image:

CommandGroup(after: .textEditing) {
  Button("Flip Image") {
    NotificationCenter.default.post(name: .flipImage, object: nil)
  }
  .keyboardShortcut("f")
}

This new item appears in the Edit menu, after the standard items. It has a shortcut of Command-F. The Command key is the default shortcut modifier, so if you only specify a letter, it automatically uses Command. All this menu item does is to broadcast a notification.

The image is shown in a subview called CatImageView which now includes the following properties:

@Environment(\.controlActiveState) private var controlActiveState

private let flipImageMenuItemSelected = NotificationCenter.default
  .publisher(for: .flipImage)
  .receive(on: RunLoop.main)

@State private var imageIsFlipped = false

The image has a rotation3Deffect modifier with the angle set to either 0 degrees, or 180 degrees, depending on the value of imageIsFlipped.

The view subscribes to the flipImage notification and receives it like this:

.onReceive(flipImageMenuItemSelected) { _ in
  if controlActiveState == .key || controlActiveState == .active {
    imageIsFlipped.toggle()
  }
}

When the notification arrives, the code checks the value of controlActiveState. In my tests, this was always either key or inactive, but I saw that active was an option and added it too, in case it becomes relevant later. If the CatImageView is in the active window, it flips the image and if not, this notification is ignored.

As you can see from the text in the images, only the front window image is flipped.

Opening New Windows

In early versions of SwiftUI, opening a secondary window was a very complex process. Read part 2 of the original series to see how I struggled with this. Later, we got an easy way to open a Preferences window, using a Settings scene. Preferences are now called Settings, which makes this nomenclature more logical.

Last year, we got the ability to use a NavigationLink as a SwiftUI menu item and this will open the destination view in a new window.

This year, we have a new method that uses another new EnvironmentValue called openWindow. First, in the _App.swift file, I added another new scene to the body - this time a second WindowGroup. A WindowGroup can be passed an id, a data object of a specific type, or both. In this case, I didn't want to pass any data, so I gave it an id:

WindowGroup(id: "ui_samples") {
  SamplesView()
}

I want to display a window with a view demonstrating some UI elements. The view is called SamplesView, so I set this as the content of the WindowGroup.

To use it, I added a property to DetailView:

@Environment(\.openWindow) private var openWindow

And inserted a Button to call it:

Button("Show UI Samples") {
  openWindow(id: "ui_samples")
}

This opens a new window with the appropriate id. This can open multiple copies of the same window. If I had passed a data object to the window, it would have brought the window containing that data object to the front instead of opening a new window. To test this behavior, I changed the WindowGroup to this:

WindowGroup(for: String.self) { _ in
  SamplesView()
}

And changed the Button to:

Button("Show UI Samples") {
  openWindow(value: "samples")
}

Now the WindowGroup expects a String. When you pass a String that has already been attached to a window, that window is brought to the front. If you pass a different String, you get a new window.

After that, I realized that there was another scene type I could use. If you create a Window scene instead of a WindowGroup, not only does this become a single presentation window, but you get a menu item for it in the Window menu without any extra work. You can add a keyboard shortcut to the Window scene too. Supposedly, you can add default sizing and positioning, but they don't appear to work yet.

Window("Samples", id: "ui_samples") {
  SamplesView()
}
.keyboardShortcut("u")
.defaultPosition(.topLeading)  // doesn't work yet
.defaultSize(width: 600, height: 600)  // doesn't work yet

Charts

One of the signature features of SwiftUI at WWDC 2022 was the new Charts API. I have struggled with charts in the past, so this was very interesting. I need to learn more, but I added a simple bar chart to the samples window:

This charts the number of entries in each category of HTTP status. I drew a line across at the 8 value because drawing a marker line is a feature I have often needed in charts.

Creating the chart was smooth:

Chart {
  ForEach(chartData.keys.sorted(), id: \.self) { key in
    BarMark(
      x: .value("Category", key),
      y: .value("Count", chartData[key] ?? 0)
    )
    .foregroundStyle(by: .value("Color", key))
  }

  RuleMark(y: .value("Threshold", 8))
    .foregroundStyle(.gray)
}

Having assembled a dictionary of category codes and counts, I looped through the keys, setting an x and y value for each in its own BarMark. The line used a RuleMark.

To get the different colors, I added this modifier to the Chart:

.chartForegroundStyleScale([
  "1xx": .green,
  "2xx": .purple,
  "3xx": .blue,
  "4xx": .yellow,
  "5xx": .red
])

which was used by foregroundStyle to assign a different color to each of the categories.

Next, I wanted to add the ability to switch between vertical and horizontal bars. This requires swapping the x and y data so that y has the category and x has the count. After testing this manually, I added a Boolean to specify the orientation, and a method for returning the appropriate BarMark:

func barMark(for key: String) -> BarMark {
  if drawHorizontal {
    return BarMark(
      x: .value("Count", chartData[key] ?? 0),
      y: .value("Category", key)
    )
  } else {
    return BarMark(
      x: .value("Category", key),
      y: .value("Count", chartData[key] ?? 0)
    )
  }
}

A similar method provided the RuleMark as either a vertical or horizontal line.

A segmented picker switches between the two and the only thing now was to animate the change. There is an animation modifier added last year that allows you to connect an animation to a property, so that when the property changes, the animation is triggered.

.animation(.easeInOut, value: drawHorizontal)

I added Text views for the title of the chart and for the axes, inside a VStack and an HStack, rotating the text for vertical axis. Maybe there is a chart setting that I'm missing for adding these labels automatically using the Chart library.

Image Rendering

While investigating charts, I experimented with another new SwiftUI feature: ImageRenderer. When I have made charts, I've often wanted to export them as images for upload. ImageRenderer allows us to convert a SwiftUI view into an image: on macOS, either NSImage or CGImage.

The first step was to convert the chart view plus its labels, into a variable (modifiers and RuleMark omitted from this code snippet for brevity):

let chartView = Group {
  Text("Status codes by category")
    .font(.title3).bold()
    .padding()

  HStack {
    Text(drawHorizontal ? "Category" : "Count").bold()
      .rotationEffect(.degrees(270))

    Chart {
      ForEach(chartData.keys.sorted(), id: \.self) { key in
        barMark(for: key)
      }
    }
  }

  Text(drawHorizontal ? "Count" : "Category").bold()
}

Then I displayed the view using the variable:

VStack {
  chartView

  // Picker & Button
}

This left the display unchanged, but allowed me to use this variable to create a view for rendering, omitting the controls that should not be part of the image:

Button("Save Chart as Image") {
  let view = chartView
    .padding()
    .frame(width: 1200, height: 800)

  let renderer = ImageRenderer(content: view)
  if let exportImage = renderer.nsImage {
    saveImage(exportImage)
  }
}

I added padding and frame modifiers to the view variable as it came out very small without this. Then I created an ImageRenderer using this view and converted it into an NSImage. The saveImage method uses an NSSavePanel to get a URL and then convert the NSImage to JPG data before writing it out. I used the same technique in part 3 of the original series but that only exported the downloaded image. This creates an image from a complete SwiftUI view.

I would be interested to try the SwiftUI fileExporter, but that's for another day.

I also tried to use the new ShareLink to share this image, but couldn't get that to work. The ImageRenderer seems to work asynchronously so that didn't work well with ShareLink. Again, that's for another day.

Forms

SwiftUI has always had a Form object, but the new System Settings app (previously System Preferences) has taken this to a new level. So I added some UI elements to a second tab in the UI Samples window.

There are a few interesting things here. Firstly, I achieved something I was unable to do last time and that is to make the text edit field have focus when the view opens. This was a three part operation:

Firstly, I added this property to the view:

@FocusState private var emailFieldHasFocus: Bool

Then, I added this modifier to the edit field:

TextField("Enter your email address", text: $email)
  .focused($emailFieldHasFocus)

And finally, I set the Boolean property in the onAppear modifier:

.onAppear {
  emailFieldHasFocus = true
}

With this in place, the email text entry field had the focus whenever this view appeared.

The date picker is slightly confused. It can't seem to decide whether it's a graphical picker or a numeric picker, but it works. I haven't tried the new date range picker yet.

With the check marks, I was trying to emulate the toggles in System Settings, where they are very small switches. I set the toggleStyle to switch which gave the right shape but it was big, like on an iPhone or iPad. The outermost form is set to use the columns formStyle. This lines up the labels and controls very neatly. But when I put the Toggles and Picker into an inner form with a style of grouped, I got the exact System Settings look I was going for.

As an aside, I love the way you can now apply control-specific modifiers to a container view and every appropriate view inside the container will use that setting. For example, I added .toggleStyle(.switch) to the Form view and it was applied to every Toggle inside it.

The final item in the form is a color picker. It opens up the standard macOS color picker and uses the selected color to fill the capsule beside it. The interesting thing is that the color has a gradient modifier. So you can see the faint gradient that is automatically applied to the shape.

Menu Bar Apps

Writing a menu bar app has previously required using AppKit to create a NSStatusItem. Now, we can add a MenuBarExtra scene to the app body to create a menu bar app component.

MenuBarExtra("HTTP Status Code", systemImage: "number.circle", isInserted: $showMenuBar) {
  MenuBarView(httpSections: $httpSections)
}

Setting the title without a systemImage shows the text as the menu bar title. when you specify a systemImage, the text is not displayed and the menu bar only shows the image.

MenuBarExtra takes an isInserted parameter, so you can turn it off and on. I added this to the app's settings and stored it using @AppStorage.

I set up a new SwiftUI view that looped through the HTTP Status data and created a submenu for each category and set this as the MenuBarExtra view. This works and my menu bar component was functional. Selecting a status uses NSWorkspace to open the relevant documentation page at MDN.

Conclusion

2022 is an exciting year to be a SwiftUI programmer. Apple has made it very clear that this is the way forward and as early adopters, we have the ability to influence how the framework develops, so keep filing those feedback reports! There have been some great new features this year: navigation is better than ever, the platforms are unifying and macOS is not getting left behind.

Writing Setup

2022-06-17T04:08:46Z

If you read my blog or tweets, you will have detected that I recently wrote a book called macOS by Tutorials, published by raywenderlich.com. in this post, I'm going to show you what hardware and software I used to write it.

Hardware

I use an 24 inch M1 iMac - yellow. I've always loved the form factor of the iMacs. They offer a superb monitor attached to a very good computer and the price is reasonable. My previous iMac used to make a noise like a kettle boiling when Xcode really got going, but this one is totally silent no matter what I do.

I'm a recent convert to a dual-monitor rig. I've always been content to use Spaces which provides virtual screens, and I still do that. But having the luxury of a second screen is great when you're writing and previewing. My second screen is a Samsung C24F390 - a curved 24 inch display. The resolution isn't anything like as good as the iMac, but I tweaked its settings to give as good a result as possible and I can't imagine going back to a single monitor now.

My keyboard is an Ergodox Moonlander which I love. This is my first mechanical keyboard and I wasn't sure if I'd like it, since I appreciated the low travel on my standard Apple keyboard. But I chose the Kailh Silver key switches which have the lowest travel and are the least clicky. It's still quite noisy, but the travel was not an issue. The configuration options are amazing. It took several iterations, but I now have a keyboard layout that works really well for me. And I keep my Apple keyboard tucked under my monitor stand so the Touch ID button is in easy reach.

For a pointing device, I have the Logitech MX Vertical Ergonomic Mouse which is very comfortable to use and charges via USB-C. Just don't install the Logitech Options utility software which is buggy and causes system problems. Use BetterTouchTool instead if you want to customize the buttons.

Software

App Development

For writing sample apps and code, I use Xcode set up in a completely standard way, using the default light scheme. This is so that my screenshots are consistent with what people will see if they are just getting started.

I wrote an article about Consistent Swift Style some years ago. The concepts are still valid but the way you integrate it with Xcode has changed. Add a build phase to your project, move it to before the Compile Scripts phase and set it to this:

export PATH="$PATH:/opt/homebrew/bin"
if which swiftlint > /dev/null; then
  swiftlint
else
  echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

This will use the default SwiftLint config which you can change in Terminal.

If you've saved a custom config file, use something like this:

PATH=/opt/homebrew/bin:$PATH
if [ -f path/to/your-config-file.yml ]; then
  if which swiftlint >/dev/null; then
    swiftlint --no-cache --config path-to/your-config-file.yml
  fi
fi

To make SwiftLint fix what it can automatically, duplicate the swiftlint line and add --fix as another parameter to the first copy. This will run SwiftLint twice: once to auto-fix what it can, and a second time to supply the warnings and errors about what it couldn't fix.

Writing

The text of the book was written in Markdown which is great for producing formatted text in a totally open and transferable format. I'm always on the lookout for a new Markdown editor and there are a lot of them around. In Section 3 of the book, I talk you through creating a Markdown editor for yourself, but it isn't quite ready for full-time use yet. I wrote this book using FoldingText which I was quite happy with. While the folding part was not something I used, I appreciated the outline view. Editing text inside links and image links was difficult and the spell checker sometimes got confused and marked an entire sentence or paragraph as incorrect. But the formatting was good and easy to use with plenty of keyboard shortcuts. Code formatting was also excellent, which is a must.

I have a bad habit of using the passive voice, which is not good when trying to teach. I use Hemingway Editor to help me detect this, so that the passive voice can be eradicated... (Passive voice joke there.) You can use it online, but I prefer to use the app.

Screen shots

If you've read the book, you'll know that it includes a lot of screen shots. There are a lot of third-party utilities for doing this, but the built-in facility gives me everything I need. It's important to memorise the keyboard shortcuts to make this easier:

Shift-Command-3: screen shot the entire screen.
Shift-Command-4: bring up crosshairs to allow selection of an area:
- When in this mode:
  - Escape exits without action.
  - Press Space to enter window mode. The window under the pointer is selected and will be screen shotted.
  - Hold down Command to select a dialog box instead of the complete window.
  - Hold down Option to turn off the default shadow.
Shift-Command-5: bring up the interface where you set options, take screen recordings and set a delay.
- I find this useful when I want to show the custom cursor during a drag operation. I turn on Show Mouse Pointer, set a 5 second delay and then start dragging before the timer runs out.

Once I have the image, I use Preview to crop and resize as needed.

And...

Finally, there's my support crew who watch every word I type and listen carefully as I explain my code.

WWDC 2022 Wishlist

2022-04-25T09:00:36Z

Apple has announced that their 2022 World Wide Developers Conference will again be an online event from June 7 to 11. The poster shows a very dark Swift logo in a coloured circle. While I have long since given up trying the read the tea leaves of Apple's graphics to work out what they will announce, I always enjoy speculating. But this year, I thought that instead of trying to guess what Apple will have for us, I'd think about what I would like them to announce, with my main focus being the Mac.

Hardware

The Apple hardware teams have been doing amazingly well over the last couple of years. The transition of the Mac lineup to Apple Silicon is almost complete and I would guess that they will complete it at WWDC with a new Mac Pro, but that is outside my budget and requirements.

While I was glad to see them offer a more reasonably priced monitor with the Studio Display, it's still a bit pricey for me. The desk lamp iMac was one of my all time favourite Mac designs so it was great to see the option for the tilt & height adjustable stand, although the extra price for that option was rather eye-popping.

I have long thought that the desktop iMac was terrific value because it attaches a stunningly good monitor to a reasonable computer. I wish Apple would supply an iMac monitor using the exact same design, but without the computer. Imagine how great that would look as a second monitor - two coloured machines side by side.

But really, I'm not looking for any new hardware right now.

Services

iCloud needs a lot of love, especially on the Mac side. I was trying to collaborate with a colleague so they shared a folder on iCloud. I was able to access their small set of files (24K total) after about 30 minutes, but my edits never uploaded. In the Finder sidebar, I have a perpetual progress indicator beside my iCloud folder and uploads never complete. The only solution is to reboot my computer, which does a complete sync once. We switched to sharing on our iPads and it all worked immediately, so the problem is not iCloud itself, but the macOS integration.

CloudKit has always looked like a great solution for use in apps. It allows public and private data, it syncs between devices, and it doesn't have the potential for unexpected and huge data fees like some other options. But like many developers, I've tried and failed to get it to work reliably. It appears that the simpler mechanisms work well, but not the more complex options.

And while I'm talking about iCloud sync issues, some apps (Notes, Reminders etc) sync - albeit very slowly, but Messages operates as if it is only partially connected. If I delete a conversation on my iPhone or iPad, I get a warning telling me that this will remove the conversation from my other devices, which is what I would expect. This deletion flows through to my Mac and the conversation is gone everywhere. On my Mac, deleting a conversation only deletes it locally and I have to delete it again on my iPhone or iPad to get it to disappear completely. What is the logic of that?

Software

There are two parts to Apple's software: the operating systems and their own apps. iOS, iPadOS and watchOS seem quite solid in their latest versions. I don't have any particular requests or complaints.

With macOS, apart from the iCloud problems that I mentioned above, my main complaint is with notifications. The user experience is terrible. Notifications popup at the top corner, and then disappear quickly. If they have action buttons, you have to mouse over the notification to see them, and this obscures the text. I have tried using System Preferences to change the way notifications are displayed, but this seems to have no effect. And trying to explain this system to a newcomer is impossible.

Apart from that, I like macOS 12 (Monterey). I would prefer Apple to go back to using numbers instead of names. Trying to work out what system people are using by the name is very confusing.

The other aspect of software is Apple's in-house apps. Sadly, Apple has decided to use Catalyst to port a lot of apps from the iPad to macOS. For a small software house with very limited resources, I can see the attraction of Catalyst although, in my opinion, it results in a greatly inferior product that gives Mac users an inferior experience. However this is hardly a valid excuse for a company the size of Apple.

As a developer, one of my main tools is Xcode. This is an amazing app and over the past few years it has got a lot of new features that allow it to integrate better with source control and with the app distribution system. But I would love to see Apple open up the extension ecosystem again. For web development, I use Microsoft's Visual Studio Code. Even though this is a cross-platform Electron-based web app, it is a great tool. It doesn't look like a native Mac app but it performs well. But it's major advantage is the huge number and variety of extensions so you can make VSC look and work the way you want. Apple has deliberately closed Xcode off from this sort of community involvement which is great shame.

Apple will tell you that they do allow Xcode extensions. But these are limited in scope, difficult to install and opaque to use. Xcode extensions used to be great - please bring them back again.

Developer Relations

This is where things get nasty. We all know that Tim Cook will bounce on to the WWDC stage saying how much they love their developers and how many billions they've paid out, but this is really just a smoke screen. Most of the money goes to a few large software houses who basically blackmail users into paying over and over again to make their apps (mostly games) usable. The race to the bottom has resulted in app stores where charging up front for an app is virtually impossible, although the Mac App Store is slightly better in this regard.

The big issue is Apple's extremely erratic policing of the app stores. They allow behaviour in some apps and ban it is others. Big players get different treatment to small. Despite claiming that the app stores are the safe place to buy apps, Apple makes almost no effort to weed out scam apps, copyright infringements or fake reviews even when they are completely obvious to the most casual search.

I don't mind paying Apple a cut of my app revenue. They do a lot of work that I would find tedious or difficult to set up for myself. I don't even mind their restrictions. What I mind very deeply is the inconsistent way this is handled. I would love it if the App Stores lived up to Apple's claim as being the safe place to buy apps, but in reality, app buyers are being fooled by purchased reviews, tricked into in-app purchases, and cannot assume that the rules designed to keep them safe have been applied to all apps.

Summary

So what would I really like to see at WWDC 2022?

iCloud syncing that works on all Apple platforms.
Real Xcode extensions.
New App Store rules to weed out copycat apps and fake reviews and that apply equally to all developers.
Better notifications for macOS - preferably the type we used to have.

macOS Book

2022-04-09T00:53:43Z

I can finally reveal the reason I have not been blogging. I have been busy writing a book. It's finally out, so here it is: macOS by Tutorials, published by kodeco.com (formerly raywenderlich.com).

Anyone who reads my posts or tweets will know that I am a passionate advocate for building real native macOS apps. This book is aimed at iOS developers who know some Swift and SwiftUI but don't yet know all the tips and tricks needed to convert that knowledge into a great Mac experience.

You don't need to be a highly experienced developer, but some basic Swift will be useful.

The book consists of five sections. In each of the first four sections, I'll walk you through developing a complete app. Each one is a different type of app using different techniques and different frameworks.

Section 1: Use SwiftUI to build a multi-paned window app. Learn how to manage windows, menus and toolbars.

Section 2: Build a menu-bar app using AppKit with a bit of SwiftUI.

Section 3: Back to SwiftUI to create a document-based app, with a bit of AppKit.

Section 4: Use your new skills to make an app that communicates with the macOS Terminal.

The final section deals with app distribution, covering both inside and outside the Mac App Store.

You can read more details of the book contents and why I wanted to write it in the Introduction which is a free section.

Thanks to...

I call this my book, but of course, it was only made possible by an awesome team. There were a lot of people involved, but I want to give special thanks to:

Ray Wenderlich who always has time for my Mac obsession and who let me write the book I wanted to write.
Manda Frederick was the book team lead when we started and was a huge source of encouragement.
Richard Critz, the wonderful editor who had the unenviable task of fixing my grammar. He was very supportive and helped me to convince everyone of the merits of this approach.
Audrey Tam and Ehab Amer were the amazing tech editors who had to make sure the instructions all worked and made sense. They took what I wrote and made it a lot better.

The whole team at Kodeco / Ray Wenderlich was great, so a huge thanks to them all. And I hope they enjoyed working on the book half as much as I did, because I had the best time!

Where can you read the book?

You can read it online at kodeco.com as part of a Kodeco subscription.
You can download an ebook (ePub or pdf) at the same page if you have a subscription or buy one there if you don't.
The paperback is available at Amazon.

All the code and extra materials for the book can be downloaded or cloned from GitHub.

Feedback

I would love to hear from anyone who read the book, loved it, hated it, found an error or just wanted to say hello.

You can contact me directly using any of the contact links at the bottom of this page or through the Contact page. There is also an official forum for the book where you can ask questions and tell us about any errors you find.

Site Search

2021-10-24T23:57:12Z

Not much action on the site lately as I work on other projects. But I have finally got around to adding a search option to the site.

I use Hugo as a static site generator, which is great but Hugo doesn't come with any search facility.

Today, I read an article by Jesse Squires on Replacing Google Search with DuckDuckGo and while I had already switched to using DuckDuckGo for my own web searching, I had not considered it for my site search.

It isn't as good as an in-built search page, which I have considered setting up using Algolia, but that requires a lot of setup and I never got round to it. This search takes you out of my site and into a DuckDuckGo page, but it limits the search options to the troz.net domain.

To access the search, go to either the Archives or the Tags page, and use the search field at the top of the page.

As a side note, if you are using DuckDuckGo as your regular search engine, read up about their !bangs. These are quick and easy ways to target your search. you can prefix your search with !so to search Stack Overflow, or !i to search for images. Search the !bangs page to find the ones that are useful to you.

The Apple DTK Gamble

2021-02-04T08:57:21Z

So I gambled…

I hoped Apple would do the right thing by developers who paid for access to the Developer Transition Kit (DTK) to get the first Apple Silicon Macs, but I was wrong and I lost.

UPDATE - 6 Feb 2020: Apple has responded to feedback from me and other disgruntled developers and so I didn't lose as much as I thought. Apple is now giving US $500 credit, which is what developers in the US paid for the DTK, and they are extending the time limit to the end of the year. I am quite certain they will release a desktop M1 Mac before then, so I will get credit for most of the cost of the DTK (after exchange rate losses) and I will be able to use the credit towards a Mac that I want.

Thanks Apple for listening and reacting.

I paid Apple AU $779 for a year’s lease on a DTK which was effectively a Mac mini with an iPad CPU. I also had to buy a monitor to use with it.

That was in June 2020.

In November 2020, the M1 was released which made the A14Z based DTK totally irrelevant for testing or development, so the lease effectively only lasted for 5 months. At that I was luckier than many devs as a lot of these DTK machines started failing at around the 4 month mark.

I kept Apple’s secrets.
I tested their hardware and software.
I filed bug reports, a couple of which even got acknowledged.

And in return, I get asked to send back the DTK some months early for which I will get the princely reward of US $200 credit.

When Apple switched over to Intel CPUs, they gave the DTK buyers a free computer when they returned the DTK, but of course Apple wasn't a trillion dollar company back then so they could afford to be generous. (How does one indicate heavy sarcasm in text?)

I don’t want a laptop, I want a desktop Mac, so there is nothing to spend my $200 credit on yet, but as a final sting in the tail, Apple has decreed that the credit expires at the end of May 2021. There is no guarantee that there will be desktop Mac to buy before then. Only Apple knows that and they have made me cynical enough to consider that they might decide not to release any new Macs until after these credits expire.

I realize that Apple made no commitment to do anything after the DTK program was over, but history indicated they would.

The smallness of the credit and the short time limit on it seem unnecessarily petty and punitive, especially when the people they are punishing are the ones that add so much value to the Apple platforms.

Assuming I have to get a laptop, I will want a high-powered one as it will have to be able to run Xcode. Apple's flagship developer tool is famously demanding.

In the US, the one I want costs US $1,899
Here in Australia, it is AU $2,899 - 1.53 times the US price.

The US$200 credit will use the exchange rate at 23 December 2020, which for USD - AUD was 1.3218 which is significantly lower than the ratio in Apple’s pricing between the two countries.

This means that I will get AU $264.36 for my credit, which is 9% of the cost of the computer to replace it, even though that is not the computer I actually want.

Financially, I would have been much better off waiting until the M1s were released. But Apple needed the early machines tested, so they suckered us in and then slapped us in the face.

I wonder how Tim Cook and the others can stand up again and again and say that they value their developers. Does that not make them feel ashamed? Or maybe they struggle not to laugh while saying it?

Thanks Apple.

And good luck finding suckers to test your next round of new hardware.

SwifUI Mac Menus

2021-01-24T05:24:17Z

With the option to create apps using the SwiftUI App life cycle, we get a new way to set up menus in Mac apps. This post will explore some of the ways to do this as well as look at the default menu groups that Apple gives us.

When you create a new Mac app, the standard menu items are included for you. Using the commands modifier on the WindowGroup allows you to add new menus, add new menu items and to replace or remove existing menu items.

Adding a New Menu

To add a completely new menu, you can use CommandMenu, supplying it with a title and the contents to display.

After starting this process, the App.swift file looks like this:

@main
struct MenuSamplesApp: App {
	var body: some Scene {
		WindowGroup {
			ContentView()
		}
		.commands {
			CommandMenu("Custom Menu") {
				// no contents yet
			}
		}
	}
}

So what can be put inside the menu? We are used to only being allowed to use NSMenuItems but with SwiftUI there are no such things. It turns out that you can put quite a few SwiftUI views into a menu.

The most obvious is a Button with an action which appears like any standard menu item.

CommandMenu("Custom Menu") {
	Button(action: {
		print("Menu Button selected")
	}, label: {
		Text("Menu Button")
	})
}

I have found that the easiest way to pass this selection on to other views is via a notification. Buttons can be disabled and enabled just as usual.

The contents of the button will usually be a Text view, but it can include an Image view if you want to use an SFSymbol or any other image in the menu.

Button(action: {}, label: {
	Image(systemName: "clock")
	Text("Date & Time")
})

Apart from Buttons, there are several other SwiftUI Views that work in a menu. A very common use case in a menu is to have a switchable boolean setting that is displayed with a leading check mark if it is on.

This can be done using a Toggle view.

Toggle(isOn: $toggleSetting, label: {
	Text("Toggle")
})

I created a variable to hold the setting using @State but @AppStorage would be better if this setting needed to persist between launches. To respond to changes, you can use an onChange modifier.

This demonstrates one of the huge strengths of SwiftUI's declarative approach. You tell the compile you want a Toggle and it is automatically structured to fit the place and platform where it is being used.

A Picker is a good choice for allowing a single selection from multiple options. This makes a sub menu with check marks.

Picker("Appearance", selection: $pickerChoice) {
	Text("Dark").tag("dark")
	Text("Light").tag("light")
	Text("System").tag("system")
}

To make a sub-menu with standard menu items like buttons, use Menu.

Menu("Sub Menu") {
	Button(action: {}, label: {
		Text("Sub Item 1")
	})
	Button(action: {}, label: {
		Text("Sub Item 2")
	})
	Button(action: {}, label: {
		Text("Sub Item 3")
	})
}

Menu items are often best split up with a separator and this is done in SwiftUI by adding a Divider().

If you try a UI element in a menu and it doesn't work, it tends to show as disabled text and doesn't break the menu, so experiment. I was surprised to find that Link does not work in a menu.

Editing Existing Menus

I have covered creating a new menu, but what about adding new items to an existing menu?

In this case, use CommandGroup instead of CommandMenu. The difference is that instead of setting a title for the menu, you give it a placement option with a reference to an existing standard menu item.

Still inside the commands contents, start typing CommandGroup to see three options:

CommandGroup(after:, addition:)
CommandGroup(before:, addition:)
CommandGroup(replacing:, addition:)

In each case, the first parameter is a CommandGroupPlacement that specifies one of a limited range of standard menu items.

The options for the menu items inside a CommandGroup are just the same as when creating your own menu.

Removing a Standard Menu Item

If you really want to get rid of one of the default menu items (or groups of items), you can use CommandGroupPlacement and replace the existing one with an EmptyView(). This is probably not a great idea as regards the Human Interface Guidelines but it is an option if you need it.

CommandGroup(replacing: CommandGroupPlacement.appVisibility) {
	EmptyView()
}

You can also replace an existing menu item with your own version if you want to be able to respond to it in a more custom way. I can imagine doing this for the Help menu item as I do not like using Apple's Help system and prefer to direct users elsewhere.

Preset Menu Groups

If you watched my Back to the Mac talk called Build a Mac app inside 30 minutes using nothing but SwiftUI, you will have seen who I used a rather clunky function to dive into AppKit in order to stop the sidebar disappearing completely and permanently.

If you haven't watched it yet, go and take a look - I'll wait… If you made it this far, I assume you are a Mac app fan like me and I think you will enjoy the talk as it demonstrated a lot of SwiftUI Mac app techniques.

Since I recorded that video, I found out that Apple provides preset menu groups for dealing with certain things and one of them is for sidebars. My clunky solution is still useful if you want to have a toolbar button, but I think I would include the menu group as well.

There are five present Commands groups provided by Apple, four of which are useful and the fifth has a purpose that escapes me.

SidebarCommands()
ToolbarCommands()

Inserting both these into your commands will expand the default View menu, so that it goes from this:

To this:

You do not need to include both, but it was easier to show in one screen shot instead of two.

If your app allows any serious text editing, you are going to want to use:

TextEditingCommands()

Which changes the default Edit menu from this:

To this:

And if you need your users to be able to format text, including:

TextFormattingCommands()

adds in a Format menu.

And finally, there is EmptyCommands() which does nothing and has no obvious use.

These are used like this:

.commands {
	SidebarCommands()
	ToolbarCommands()
	TextEditingCommands()
	TextFormattingCommands()
}

Using a Separate File

If you are adding a lot of menus, you are probably starting to feel that your App.swift file is getting a bit crowded. You can separate out these menu commands into one or more separate files, so long as they are contained in a struct that conforms to the Commands protocol and which has a body that also conforms to Commands.

struct MenuCommands: Commands {
	@Binding var toggleSetting: Bool

	var body: some Commands {
		CommandMenu("Custom Menu") {
			Button(action: {
				print("Menu Button selected")
			}, label: {
				Text("Menu Button")
			})

			Divider()

			Toggle(isOn: $toggleSetting, label: {
				Text("Toggle")
			})
		}
	}
}

This struct cannot have its own data or you will get lots of warnings, but it can have bindings to data from its parent. Insert a call to this struct, and any others you have created, in the commands modifier, just like for the Apple presets.

@State private var toggleSetting = true

// ...

.commands {
	MenuCommands(toggleSetting: $toggleSetting)
	SidebarCommands()
}

Bonus: Credits

Every Mac app has an "About …" menu item which brings up a simple dialog box with basic app information: icon, app name and version number. These will always appear but there is an easy way to add more information underneath this info and it can include formatted text and links.

Create a new file called Credits.rtf - the New File dialog has a Rich Text File option. Anything in a file with this exact name will be shown below the standard information in the About box.

Xcode's RTF editor is not great, but it is good enough for this. There are some basic formatting tools above the text editor, but you can also right-click on text to get more options, including Font and Color panels.

To insert a web link, go to the Editor menu and select Add Link…

Well that's it. A quick round-up of the ways to use menus in your SwiftIU Mac apps. I hope you found it useful. If you have any suggestions, comments, corrections or improvements, please contact me using one of the links below or through the Contact page.

SwiftUI Data Flow

2021-01-24T05:17:14Z

SwiftUI gives us a completely new way to lay out out user interfaces, in a declarative and responsive way. Your data dictates what is displayed. But this leads to a new problem - how should the data models be constructed and how can they be passed around between the various views that make up your app?

In this post, I intend to discuss the possibilities with examples.

Update - January 2021: I think the information in this post is still all valid except for one change. When you are initializing an ObservableObject, you should use @StateObject instead of @ObservedObject. Your views can receive objects that are owned by other views as @ObservedObject or @EnvironmentObject but the owner of the data should always create the data object with @StateObject.

For a great diagram showing what data object type to use where, check out this image from Chris Edihof - thanks Chris!

If you read this article before November 18th 2019, please check out ObservableObject & @ObservedObject - Part 2 again as it has gone through several iterations, which are all shown for comparison.

At WWDC 2019, some Apple engineers gave a great presentation on Data Flow Through SwiftUI and I strongly recommend watching the video. But you need to watch it twice. First watch it so that you can get started, and then, when you feel that this is all way too complicated, watch it again and it will start to click into place. The only real difference between then and now is that BindableObject has become ObservableObject.

I guess I could stop there, but I will be illustrating my ideas with code examples, which I hope will make things clearer. Some of the examples are rather contrived in order to make a point, but the sample code is also sprinkled with other SwiftUI examples which I hope will prove useful.

Download the sample project from GitHub and open it in Xcode. Go to ContentView.swift and make sure the Canvas is open. Click Resume to make the view appear. Then click the Live Preview button and wait for the view to become active. I recommend clicking the Pin button at the bottom left of the Canvas so that you can investigate the code samples, while still working in the main navigation.

Data Flow Options

There are 5 ways to specify data in SwiftUI:

Property
@State
@Binding
ObservableObject & @ObservedObject
@EnvironmentObject

Property

struct Property: View {
    // Property
    let greeting = "Hello from SwiftUI!"

    var body: some View {
        // Using property directly
         Text(greeting)
             .font(.title)
    }
}

In this example, the greeting property is used in the view. greeting is static, so the view does not need to monitor it for changes. This may seem like a simplistic and obvious example, but separating it out allows for localization or re-usability.

The property could also have been supplied by a parent view and this is a really useful feature of properties. A parent view can have some dynamic data that it can use to set properties in a subview where the subview only needs to display the data statically. This data will change as the parent view changes but the subview will not be able to change the data in the parent view.

And it is important to remember that not everything needs to be set up with one of these new property wrappers.

@State

This is where things start to get very interesting in the SwiftUI world. SwiftUI views are contained in structs, so are non-mutable. Also, the views are re-created every time the data changes, so any properties are re-created then too. By marking a property with the @State property wrapper, you are telling SwiftUI that you want it to keep this data in a separate portion of memory, allow it to be mutated, and preserve the current value during the view refresh.

struct UsingState: View {
    @State private var toggleValue = true

    var body: some View {
        // Using state with 2-way binding
         Toggle(isOn: $toggleValue) {
             Text("Toggle is \(self.toggleValue ? "ON" : "OFF")")
         }
         .padding(50)
    }
}

In this example, toggleValue is declared as a Bool with a property wrapper of @State. Inside the Toggle, the isOn value is bound to toggleValue by the leading $. This allows the variable to set the toggle and the toggle to set the variable - 2-way binding.

@State variables are always value types and are usually local to their view, so Apple recommends marking them as private.

And unlike properties, @State variables allow you to have data that is dynamic but it can still be passed to subviews as properties for display.

@Binding

One problem with building SwiftUI views is that it is very easy to end up with a gigantic Pyramid of Doom as you embed views within views within views. The solution is to extract subviews, but then you need a way to pass the data to the subview.

This is where @Binding comes in as it allows you to tell a view that the data for a property is actually coming from a parent but that the subview is allowed to change that property and that change will flow back to the parent's data.

struct Numbers: View {
    @State private var stepperValue = 0

    var body: some View {
        NumberChooser(stepperValue: $stepperValue)
    }
}

struct NumberChooser: View {
    // Using state from parent with 2-way binding
    @Binding var stepperValue: Int

    var body: some View {
        ZStack {
            VStack {
                Stepper(value: $stepperValue, in: 0...20) {
                    Text("Value = \(stepperValue)")
                }

                NumberBlock(stepperValue: stepperValue)
            }
        }
    }
}

struct NumberBlock: View {
    // As this view never changes the value, there is no need to bind it
    var stepperValue: Int

    var body: some View {
        Image(systemName: "\(stepperValue).square")
    }
}

In this example, I have declared a stepperValue property and marked it with @State.

The interface has been extracted into a subview called NumberChooser and a Binding to the stepperValue property has been passed to NumberChooser using the $ prefix, which will ensure that changes to the value can come back. Inside NumberChooser this property is wrapped in the @Binding property wrapper to indicate that it is coming from another source and that changes will be returned.

NumberChooser itself has a subview called NumberBlock but it is a display view only and never mutates the value itself, so stepperValue is passed to this subview as a property only, without the $ prefix. It will still be updated every time the data changes as it is contained by the view with the @State property.

@State & @Binding - Part 2

So far, the examples have used primitive data types for the @State properties, but given that @State properties are value types, any struct can be used. In the next example, I use a struct to hold the properties of a pizza order and use a SwiftUI Form to allow selections.

struct PizzaView: View {
    // Using @State for a struct
    @State private var pizza = Pizza()

    var body: some View {
            VStack {
                Form {
                    // Using 2-way binding but each component
                    // only needs 1 property from the struct
                    PizzaNamePicker(selectedPizzaName: $pizza.name)
                    PizzaSizePicker(selectedPizzaSize: $pizza.size)
                    PizzaCrustPicker(selectedPizzaCrust: $pizza.crust)
                }

                // Text representation to prove that the
                // subviews are modifying the parent struct
                Text(pizza.pizzaSelection)
             }
            .navigationBarTitle("Choose Your Pizza")
    }
}

Each subview gets the property it needs using @Binding:

struct PizzaNamePicker: View {
    @Binding var selectedPizzaName: PizzaName

    var body: some View {
      // see the GitHub project for more details
    }

The form consists of 3 subviews - one each for selecting the pizza, size and crust. The Pizza struct holds all three properties, but each subview only needs a Binding to the single property that it controls. The Text view after the Form is to prove that all the selections come back to the parent.

ObservableObject & @ObservedObject - Part 1

These are used if your data model is a class and you want to use reference-based data instead of the struct's value-based system.

To set up a data model to be Observable, it must conform to the ObservableObject protocol and any property that needs to be observed should have the @Published property wrapper. This makes sure that any time this property changes, all the Views that are observing the instance of this data model will be notified to perform the UI updates.

For this example, I have a ColorSet class with six color components that are used to assemble two RGB colors.

class ColorSet: ObservableObject {
    // ObservableObject
    // The 6 color components are marked as @Published so any changes
    // get published to the views that are observing

    @Published var foregroundRed = 0.0
    @Published var foregroundGreen = 0.0
    @Published var foregroundBlue = 0.0

    @Published var backgroundRed = 1.0
    @Published var backgroundGreen = 1.0
    @Published var backgroundBlue = 1.0
}

In the primary view, I set up an instance of this class as an @ObservedObject.

struct ColorSetView: View {
    @ObservedObject private var colorSet = ColorSet()
}

The background of the view and the foreground of a system image are set using these colors. A button presents a sheet with sliders to allow editing these colors. The colorSet is passed to the sheet like this:

  .sheet(isPresented: $showChooser) {
      // notice that this does not use $ as the ColorChooser
      // will get a reference to the ColorSet object
      ColorChooser(colorSet: self.colorSet)
  }

struct ColorChooser: View {
    @ObservedObject var colorSet: ColorSet

    var body: some View {
        // ...
    }
}

A sheet is not the ideal way of presenting a view that uses sliders for editing, but I wanted to demonstrate that changing the sliders instantly changes the value of the @ObservedObject for the parent view as well as for the subview. Editing the background color components shows the new background color in the back at the top of the sheet.

The ColorChooser itself uses 2 subviews and they get a reference to the ColorSet in the same manner.

ObservableObject & @ObservedObject - Part 2

This section was that one that caused me the most trouble when writing the example app. I wanted to display a list of data and have each entry link to an editable detail view with the edits flowing back to the parent list.

The initial display of data in a List was straight-forward and I was then able to have the list rows navigate to a detailed view for each entry. The problem was getting the edited data back to the parent List.

The basic data model was an ObservableObject that publishes an array of PersonViewModel objects.

class PersonListModel: ObservableObject {
    @Published var persons: [PersonViewModel] = []

    func fetchData() {
        // get data from web ...

        DispatchQueue.main.async {
            self.persons = newData
        }
    }
}

Since this data is going to trigger a UI update after a background network call, it is important that changes to the @Published property get switched to the main thread.

The PersonViewModel also needs to be Observable with the editable properties marked as @Published.

class PersonViewModel: Identifiable, ObservableObject {
    // Even though this is not observed directly,
    // it must be an ObservableObject for the data flow to work

    var id = UUID()
    @Published var first: String = ""
    @Published var last: String = ""
    @Published var phone: String = ""
}

The odd thing was the way that I had to pass the data to the detail view. This is what I tried initially:

  List {
      ForEach(personList.persons) { person in
          NavigationLink(destination:
              PersonDetailView(person: person)
          ) {
              Text("\(person.first) \(person.last)")
          }
      }
  }

And in PersonDetailView:

    @ObservedObject var person: PersonViewModel

This almost worked. The correct data was passed to the detail view, and the data edits changed the data, but the parent list was never re-drawn. If I changed a record's first name then went back to the list, the change was not displayed. But if I then returned to the detail view for the same record, my edits were there, so I could tell that the data was changing correctly. The problem was how to change it in such a way that the parent view was notified of the change.

Trying to bind person with PersonDetailView(person: $person) gave the error Use of unresolved identifier '$person', so the ForEach enumeration did not provide a direct connection to the personList object.

The solution I came up with was to switch to enumerating by index in the ForEach and passing a direct member of the parent list's data to the detail view. And switching the PersonDetailView to use @Binding var person: PersonViewModel.

ForEach(0 ..< personList.persons.count, id: \.self) { index in
    NavigationLink(destination:
        PersonDetailView(person: self.$personList.persons[index])
    ) {
        Text("\(self.personList.persons[index].first)") +
          Text(" \(self.personList.persons[index].last)")
    }
}

This works but as well as being hard to read, it has one major flaw. The rows in the table are identified by their row number, rather than by anything in the data like the person.id. This can really mess with how SwiftUI handles the List and how it knows which rows have changed and need to be re-rendered. It is important to identify rows by something unique to the data in each row so that SwiftUI knows that you have deleted the row with the ID "abcd-1234" and not row #7. Because if you delete row ID "abcd-1234" there is no longer a row ID "abcd-1234" but if you delete row #7, there is now a different row #7 and anything could happen.

Update 1: @StewartLynch contacted me to suggest a much neater way to pass the person data to the PersonDetailView by using a function to get a Binding<PersonViewModel> for each person being displayed. This worked perfectly and made for a much cleaner looking bit of code. Thanks Stewart.

ForEach(personList.persons) { person in
    NavigationLink(destination:
        PersonDetailView(person: self.selectedPerson(id: person.id))
    ) {
        Text("\(person.first) \(person.last)")
    }
}

And outside the body declaration:

func selectedPerson(id: UUID) -> Binding<PersonViewModel> {
    guard let index = self.personList.persons.firstIndex(where: { $0.id == id }) else {
        fatalError("This person does not exist.")
    }
    return self.$personList.persons[index]
}

If you want to have a look at Stewart's solution, check out this commit on GitHub.

Update 2: @vadimshpakovski says that creating a binding for every person object is inefficient and that the function to create this binding will slow things down. He suggests using onReceive to react to changes to person and trigger an update of personList. In this case, PersonDetailView uses @ObservedObject var person: PersonViewModel. This also works perfectly.

  ForEach(personList.persons) { person in
      NavigationLink(destination:
          PersonDetailView(person: person)
              .onReceive(person.objectWillChange) { _ in
                  self.personList.objectWillChange.send()
              }
      ) {
          Text("\(person.first) \(person.last)")
      }
  }

If you want to have a look at Vadim's's solution, check out this commit on GitHub.

Update 3: More suggestions have come in from the community (thanks to everyone who contributed) and it has been pointed out to me that while Vadim's solution does solve a lot of the issues, it means that the entire ForEach has to be recalculated to check for changes every time a single Person is edited. And it also inserts model management code into the view code, which is not great.

So my next attempt goes back to using @Binding var person: PersonViewModel in PersonDetailView but instead of PersonListModel having an array of PersonViewModels, it has an array of UUIDs and a dictionary of UUID: PersonListModel. The benefit of this is that the UUIDs can be used in the ForEach as they are unique to each row, and the dictionary can be used to provide a Binding to the person for each UUID.

This removes the problem of my original solution by identifying each row uniquely, it goes back to Stewart's solution but eliminates the potential slow function to create a binding for the matching person, and eliminates the issue of complete redraws and model management inside views from Vadim's suggestion.

But it was not entirely straight-forward as getting a value from a dictionary by key returns an optional. At first I thought I could use the new default syntax for dictionaries to get a non-optional value for binding but for some reason that couldn't be used to create a Binding.

The answer was to write an extension on Dictionary with a subscript function that returns a non-optional value or gives a fatal error. Since I am in control of the data and set up every UUID with a matching PersonViewModel, this is not dangerous.

So here is what we have now:

class PersonListModel: ObservableObject {
    // Main list view model
    // ObservableObject so that updates are detected

    @Published var ids: [UUID] = []
    @Published var persons: [UUID : PersonViewModel] = [:]

    func fetchData() {
        // get data from web ...

        DispatchQueue.main.async {
          let personViewModels = dataArray.map { PersonViewModel(with: $0) }.sorted() {
              $0.last + $0.first < $1.last + $1.first
          }
          self.ids = personViewModels.map { $0.id }
          self.persons = Dictionary(
              uniqueKeysWithValues: personViewModels.map { ($0.id, $0) }
          )
        }
 }

The incoming data is mapped to a sorted array of PersonViewModels before extracting the UUIDs and creating the dictionary. This means that the UUIDs array is in the correct sort order for use in the ForEach.

Here is the Dictionary extension:

extension Dictionary where Key == UUID, Value == PersonViewModel {
    subscript(unchecked key: Key) -> Value {
        get {
            guard let result = self[key] else {
                fatalError("This person does not exist.")
            }
            return result
        }
        set {
            self[key] = newValue
        }
    }
}

And these go together to allow this:

ForEach(personList.ids, id: \.self) { id in
    NavigationLink(
        destination: PersonDetailView(person: self.$personList.persons[unchecked: id])
    ) {
        Text("\(self.personList.persons[unchecked: id].first)") +
            Text(" \(self.personList.persons[unchecked: id].last)")
    }
}

This ended up a bit more complicated than my original idea, but I think it is now good SwiftUI, avoiding several problems from the earlier solutions.

Thanks to JSON Generator for the sample data. And if anyone has any other solutions to this problem, I would love to hear it. You can contact me using any of the buttons at the end of this article.

@EnvironmentObject

Think of the EnvironmentObject a piece of state that can be used by any view or any descendent of the view once it has been introduced. People who have used React or any of the similar web development technologies will be familiar with the concept of global state and this is similar to that, although not truely global.

You set up a class as an EnvironmentObject model exactly as you would set up an ObservableObject with the same protocol conformance and using the @Published property wrapper to mark properties whose changes will trigger UI updates. Here is a very simple example with just one property.

class UserSettings: ObservableObject {
    @Published var isLoggedIn: Bool = false
}

In this example, the yellow view is the parent view - the different views have different brightly colored backgrounds to make them easy to distinguish. The yellow view has access to the UserSettings like this:

struct NestingViews: View {
    @EnvironmentObject var userSettings: UserSettings

    var body: some View {
        ZStack {
            Color.yellow.edgesIgnoringSafeArea(.all)

            VStack {
                // UI omitted for space reasons

                // display first nested view
                ChildView()
            }
        }
    }
}

The ChildView contained in this parent - the green view - has no need to access this data and so gets no @EnvironmentObject property. But ChildView contains another subview - the blue one. And this GrandChildView does need access to the UserSettings so it has the exact same @EnvironmentObject var userSettings: UserSettings property as the parent view.

If this was using @ObservedObject the data would have to be passed through every view in an un-broken chain, even though ChildView did not need this data. By using @EnvironmentObject the chain can be broken, but any view that needs to, can access and mutate this data. In the example, both the yellow and the blue views display and edit the same data with updates happening in both when either button is pressed.

One key thing to remember about previewing @EnvironmentObject in the Canvas is that every view that uses it, or that contains a view that uses it, needs to be supplied with the ObservableObject in the preview using .environmentObject().

struct NestingViews_Previews: PreviewProvider {
    static var previews: some View {
        NestingViews()
            .environmentObject(UserSettings())
    }
}

In the app itself, only the first view to access the @EnvironmentObject needs it set. In this example, it is done in the NavigationLink that goes to the NestingViews example. The .environmentObject can be provided to the root view in the SceneDelegate if the root view needs it.

    NavigationLink(destination: NestingViews().environmentObject(UserSettings())) {
        ListContents(title: "@EnvironmentObject", imageNumber: 6)
    }

Summary

Or What Should I Use When?

For value-based data models or data primitives, use @State.
For reference-based data use ObservableObject.
For data needed by a lot of views in your app, use @EnvironmentObject.
Use @Binding or @ObservedObject to pass data to a view that can mutate it.

And one final tip: while creating a view from scratch, use @State with sample, hard-coded data. Once you have the interface you want, then change it to use real data.

I am sure people will develop their own theories and their own ways of using SwiftUI, but those are the guidelines that I intend to follow for now. If you have different views and would like to discuss them, please contact me.

Crossfix

2020-11-22T22:59:45Z

I have just released Crossfix and Crossfix Lite for iPhone. They are both the same anagram assistant solver for crosswords, particularly cryptic crosswords. The Lite version is free but limits you to three solves per day. The full version is unlimited with no ads, no recurring subscriptions and works with family sharing.

For more details, check out the app page at https://troz/net/crossfix/.

And if you are interested in the back story and the development process, have a look at Name This App. Thanks to everyone who suggested a name, and special thanks to Jerry who came up with the winning entry.

This is the first app that I have published that is 100% SwiftUI, although as I started it several months ago, it still uses the old App Delegate life cycle.

SwiftUI for Mac on Big Sur

2020-07-08T09:40:16Z

In December 2019, I wrote a series of articles about using SwiftUI to build a Mac app. At WWDC 2020, Apple announced macOS 11 Big Sur along with Xcode 12 and a heap of new features for SwiftUI, so I decided to try creating my test app again and seeing how much had changed.

You can read the earlier articles and if you are interested, download the previous project from GitHub. Usually, when revisiting an old app, I would update the existing project, but this time I want to use the new SwiftUI App so I am going to start from scratch with a new app project, copying in code as required. And I plan to follow the same basic thread as I did in the previous articles. Who knows haw many parts this one will have!

For reference, I am running the beta of macOS 11 Big Sur (20A4299v) and the beta of Xcode 12 (12A6159) on a rather aged MacBook with a dodgy battery. I do not have Xcode 12 installed on my Catalina Mac, so I have no way of telling whether some of the oddities are due to Xcode or Big Sur but I will try to keep this article updated as the new betas improve things.

Update: I have downloaded macOS Big Sur beta 2 (20A4300b) and Xcode 12 beta 2, oddly labelled in the About box as 11.5 (11E608c). I have only found one thing that needs to be changed. I had set the deployment target to 11.0 but the new Xcode does not allow this as an option and the app fails to build. Change the deployment target to 10.16 to make it work.

It looks like Apple is having some problems with consistency in the new version numbers in both macOS and Xcode.

The New Project

As before, the first step was to create a new project in Xcode. I chose the macOS App template although the Multiplatform option was intriguing. When setting the options for the new app, I chose SwiftUI for the Interface, SwiftUI App for the Life Cycle and Swift (of course) for the language.

Once I had selected a save location and the project was open, I checked out the file structure. The main difference here was that there is no AppDelegate.swift file. Instead there is a file called "SwiftUI_Mac_11App.swift" where "SwiftUI_Mac_11" is the name of my app. This file is vastly simpler than the old AppDelegate but it sets up the app, the scene and the window group, with the expected ContentView as the main content.

ContentView.swift had a change too. Instead of setting the maxWidth and maxHeight of the view to .infinity, this Content View only adds some padding to the standard Text view. Time to see what happens when I run...

The first run took longer than I expected (I told you it was an old MacBook) but then a very small window appeared, just big enough to show the "Hello world!" text with its padding. The app has all the expected menus although I have no idea where they are set up.

Closing the app and using the Canvas preview worked much as before, although the canvas now has additional controls including a button to add another preview and a menu to configure each preview. Oddly, running the preview and clicking "Bring Forward" displayed two app windows. I presume this is an Xcode 12 beta "feature".

I used the attributes Inspector to edit the Text view, setting text, font style and weight and color. I had read that Xcode 12 had much better auto-formatting, but when adding modifiers this way, they all ended up on a single line which was not pretty. Manually adding line feeds before each dot did give a very neat structure, so typing in modifiers will be my preferred method.

Editing the Layout

Now on to my own layout. As I did last time, I used a static list to make a NavigationView for preliminary testing.

struct ContentView: View {
    var body: some View {
        NavigationView {
             List {
                 ForEach(1 ... 10, id: \.self) { index in
                     NavigationLink(destination: Text("\(index)")) {
                         Text("Link \(index)")
                     }
                 }
             }
        }
    }
}

When I ran the app or looked at it in the Canvas it looked great, but when I clicked a link in the sidebar, the window shrunk to an unusably small size. So I added a frame modifier to the destination view. And I also set the ListStyle to SidebarListStyle() which gave the new macOS 11 full height sidebar look.

But here is where I encountered the first major difference. When I selected an item in the sidebar, the app correctly showed the detail view. But if I put the app into the background, this detail view disappeared. It literally disappeared because I was able to track that it was calling its onDisappear modifier.

After a lot of testing, several days of frustration and help from Jordan Singer with his mail-swiftui-sample project, I was finally able to work this out. The difference is that the initial view has to specify what comes next as well as what it is displaying. So in the initial NavigationView, I had a List, but I also needed some view to show that I was going to show another view in another column. This second column view has to reserve the space for the detail view to come.

I have no idea how Jordan worked this out, but I am very grateful. What I ended up with was this:

struct ContentView: View {
    var body: some View {
        NavigationView {
            List {
                ForEach(1 ... 10, id: \.self) { index in
                    NavigationLink(destination:
                                    Text("\(index)")
                                    .frame(maxWidth: .infinity, maxHeight: .infinity)
                    ) {
                        Text("Link \(index)")
                    }
                }
            }
            .listStyle(SidebarListStyle())

            Text("Select a link...")
                .frame(maxWidth: .infinity, maxHeight: .infinity)
        }
        .frame(maxWidth: .infinity, maxHeight: .infinity)
    }
}

The "Select a link..." text is shown when there is no destination view to display. And when I click one of the entries in the sidebar, its content replaces that Text view but keeps its frame.

Displaying Data

As with the previous app, I am displaying data from HTTP Cats. This part remains the same, so check back to the original article if you want to see how I did this. I did get warnings about the Decodable data structs I was using. My normal pattern when I want data to be Identifiable is to use something like this:

struct HttpSection: Identifiable, Decodable {
    let id = UUID()
    let headerCode: String
    let headerText: String
    let statuses: [HttpStatus]
}

But with Xcode 12, this gives an error. The error messages seem much more useful than before and they offered two suggestions. I tried what appeared to be the easier one of making the id mutable, but that stopped the decoding from working, so I added a CodingKeys enum to each struct to restrict the keys that would be included.

enum CodingKeys: String, CodingKey {
    case headerCode
    case headerText
    case statuses
}

When the app ran, I had a sidebar with collapsible sections. I wasn't that happy with the default look of the section headers and the disclosure marker for the first header was positioned beside the text instead of at the right, but I do like the selected item lozenge look. I set a frame height for the section header view and that made the spacing better but the disclosure mark for the first header was still incorrectly positioned.

The Detail view to be displayed when a status is selected had no major changes, so I dropped in the file from the previous app, without the extra bits to do with notifications and preferences. However since SwiftUI now includes a ProgressView, I swapped out my "Loading..." text for a indeterminate progress twirly.

Three Column Layout

Since the collapsible sidebar wasn't looking good, I decide to try for a three column layout with the categories in the first column, the codes for the selected category in the second column and the detail view in the third column.

The way I implemented this was to have the first list only show the section headers with NavigationLinks to a sub menu. To reserve the column layout, I had an empty submenu after the main list.

In the second column, I showed the sub-headers with NavigationLinks to the DetailView. This view reserved the space for the third column with a Text view that changed its text depending on whether that submenu was displaying anything or not.

I expanded the menu items to be big and chunky, which I feel fits the new style. The only remaining problem was that with the primary list set to use SidebarListStyle(), it only ever showed the first item. I had to change this to InsetListStyle() to see all the items! This lost the full height sidebar effect, but I assume this is a temporary bug.

Menus

Now I had the layout equivalent to what I ended up with after part 1 of my original series, so it was time to explore menus, which are very different. In the old style SwiftUI apps which were wrapped in AppKit, the menus were in a storyboard that you could edit. Now you add commands to the app's WindowGroup to alter the menus.

The easiest way is to add a completely new menu, but it is also possible to insert new menu items after or before certain standard menu items.

Here is how to add a new Utilities menu with three items:

@main
struct SwiftUI_Mac_11App: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .commands {
            CommandMenu("Utilities") {
                Button(action: {}) {
                    Text("Dark mode")
                }

                Button(action: {}) {
                    Text("Light mode")
                }

                Button(action: {}) {
                    Text("System mode")
                }
            }
        }
    }
}

A CommandMenu adds a new menu and it is always positioned between the standard View and Window menus. To add items to an existing menu, you need to use a CommandGroup and tell it where to appear. It can be after or before various standard menu items. Look up the docs for CommandGroupPlacement to see which items you can use as positional markers. I used after .windowArrangement.

Weirdly, the font, color and spacing of these menu items was different to the standard menu items. I can only assume this is a bug which will be fixed. I faked the proper look with modifiers, but it didn't feel right. This screen shot shows the default look with the three mode items being my additions to the standard Window menu.

I tried using Labels to add an icon to the menu item. As I was switching between view modes, I wanted to have a checkmark before the selected menu item. This worked when first drawn, but the menus did not refresh when the data changed, so that was no use.

I also tested using Divider() to get a menu separator. It worked, but the look didn't match the standard dividers. So menus need a lot of work still...

I kept the technique of having menu items publish notifications that other views could pick up. This seems to work well. I would have liked to have certain menus or menu items only appear conditionally or perhaps enable/disable conditionally, but I could not see how to do that. Since menus do not appear to update when data changes, this may not be possible right now.

Preferences

There was one place where the new app architecture was amazingly good and that was to do with preferences. In my previous attempt at this app, I had a Preferences window and it was a major exercise to stop it opening more than once. This time, it was super easy. In the App.swift file, beside the WindowGroup, I added Settings which contained a view which had the UI for my app's preferences.

This caused a few errors at first, but I added a @SceneBuilder property wrapper to the App's body and that fixed the errors.

@main
struct SwiftUI_Mac_11App: App {
    @SceneBuilder var body: some Scene {
        WindowGroup {
            ContentView()
        }

        Settings {
            SettingsView()
        }
    }
}

These three lines of code added a Preferences menu item and hooked it up to my SettingsView. This view opens in a new window when the Preferences menu item or keyboard shortcut is used and only one copy of this window ever appears.

Then on to the second brilliant thing about preferences: @AppStorage. In the previous version, I used a custom property wrapper to wrap settings that I wanted saved into UserDefaults. This is now built into SwiftUI and this was all I had to do:

    @AppStorage("showCopyright") var showCopyright: Bool = false

Now any time that variable was accessed, it was read from UserDefaults and every time it was changed, it was written back into UserDefaults. Instant preferences in a single line!

To pass this setting to a different view, all I had to do was give that view this same declaration. And it just worked!

Opening Another Window

Last time, I tried lots of different ways using hosting controllers, storyboards etc. to open secondary windows. This time I decided to stick to using sheet since it seems to be what works best for SwiftUI apps. So I added my User Interface Elements sample window as a sheet.

The view itself was reasonably similar except that last time, I used an NSViewRepresentable to embed an AppKit color well into the view. This time I was able to use the new SwiftUI ColorPicker which made it much easier to get the color back into the main view. I also added the new date and time pickers.

The color picker worked really well except that there is an option to specify whether the picker should support opacity or not. I found that no matter what I chose here, I never got the option to chose a color with opacity.

The date picker was good. It showed the date numerically using my local format - DD/MM/YYY. Clicking on any of the elements popped up a calendar view. The time picker was not so easy to use. Again, it showed the time in my format e.g. 7:53 pm. But there was no graphical entry, you click on an element (hour, minute or am/pm) and type. This would be OK except that every time you type, the focus jumps back to the hour. I found this confusing.

One big improvement is the ability to apply a keyboard shortcut to a button. When I set the keyboard shortcut for the Close button to .defaultAction, the button got the default appearance and was triggered by pressing the Return key.

    Button(action: {}) {
        Text("Close")
    }
    .keyboardShortcut(.defaultAction)

I was still unable to work out how to set the focus to a TextField. There are two new property wrappers to do with focus, but I understand they are not yet operational.

Dialogs

I have already used a sheet to display the UI elements and ActionSheets are not available on macOS, so that just leaves Alerts and file dialogs. File dialogs work identically in the app although they look quite different on Big Sur. Alerts look quite different but I think they are nice. Since the app icon is a prominent part of the dialog, I added one to make it look good. I understand that different numbers of buttons will get arranged in different ways.

Other Improvements

Self

Do a search for "self." and get rid of them all. Your code will be much cleaner and easier to read and SwiftUI now understands what you mean. If you want to read more details about this change, check out swift-evolution proposal SE-0269.

Navigation Titles

iOS had the concept of setting a navigation title but it didn't really work in macOS. Now you can set the navigationTitle of a view and this will be the window title.

Toolbars

This was an aspect of macOS apps that I referred to but didn't explore last time mainly because I assumed it would be done through the storyboard, just as with an AppKit app. Now we can add a .toolbar modifier to a view and have it include ToolbarItems. For the first time, we can now use SF Symbols in a macOS app, so that made it easy to add good looking toolbar items.

I would like to vary the toolbar according to what is being displayed, and the toolbar is also used to show the navigation title, but perhaps that is a topic for another day. There is certainly a lot to explore there.

Pyramid of Doom

With menus and toolbars, there is a heap of extra code added to certain views. I would love to be able to extract that into its own function or view modifier. I was able to extract the toolbar, but I am not sure how to do this with menus yet. I imagine it will need some specific sort of ViewBuilder but I think this is very necessary. Perhaps the topic for yet another article...

The project is available on GitHub. As always, if you have any comments, suggestions or ideas, I would love to hear from you. Please contact me using one of the links below or through my Contact page. Thanks for reading.

Thanks to Sungbin Jo (조성빈) for proof-reading and suggestions.

SwiftUI Snapshot Testing

2020-05-17T08:50:09Z

Snapshot testing is a technique that has been very popular in the web development world and it seems like a great way to test SwiftUI user interfaces. I read about snapshot tests in a recent blog post and was intrigued, but I had some difficulty getting it to work, so when I finally succeeded, I decided to share my experiences in the hope that others will find them useful.

What is Snapshot Testing

Unit testing checks that when you call various functions or methods with certain inputs, you get the output you expect. I use unit tests for testing my models and the methods that change them. But this only tests the logic behind the app, it does nothing to test whether the app is displaying what it should, or whether it is responding correctly to the user's actions.

UI testing emulates user actions by faking taps, clicks, text entry and so on and checks that labels, buttons etc are showing the correct information after these fake interactions.

Snapshot testing is in between these two as it effectively takes a picture of the interface. The first time you run the test it will store an image and all subsequent test runs will check that the current interface matches this stored image. If there are any differences, the test will fail so you can decide whether to keep the new version or revert to what you had before.

How did I get started?

I first read about the idea of using snapshot testing for SwiftUI in a blog post by Vadim Bulavin. He made a very good argument for this, but I found his instructions assumed more knowledge of the topic than I had at the time and so I discarded the idea after an initial attempt.

But he was suggesting using a snapshotting library published by Point-Free and I later discovered a link to one of their videos where they discuss this exact thing: SwiftUI Snapshot Testing. This was enough to get me going with attempt #2.

Setting up an app for snapshot testing

Since the blog post and video were talking about iOS apps, I decided to start there, but you know me, I will get to macOS apps later...

First off, I created a single view iOS app using SwiftUI making sure to check "Include Unit Tests", but not "Include UI Tests". I created a simple view so I had something to test.

If you want to use this on an app that does not already have a unit tests target, go to the project settings, click the + button to add a new target and choose a Unit Testing Bundle.

Next step was to import the snapshot testing library using Swift Package Manager. Go to File > Swift Packages > Add Package Dependency. Paste in the URL below and click Next.

https://github.com/pointfreeco/swift-snapshot-testing

I accepted the default versioning suggestions on the next pane.

On the final pane, it is important to select the correct target for this package. Select the app's test target, not the app itself and not the UI test target if you have one. I made this mistake on my first try as I assumed that snapshot testing would be part of UI testing but it is actually part of unit testing.

Writing a Snapshot Test

Now I added a new Unit Test Case Class file to the tests target in my app. I had to import SwiftUI and SnapshotTesting into this test file as well as declaring the app as a testable import. The easiest way to do this is to copy the @testable import heading from the sample test file to make sure it is exactly right. The import needs to match the name of your app module.

Finally it's time to write the first snapshot test:

import XCTest
import SnapshotTesting
import SwiftUI
@testable import Snapshots

class SnapshotsTests: XCTestCase {

    func testDefaultAppearance() {
        let contentView = ContentView()
        assertSnapshot(matching: contentView, as: .image)
    }

}

This uses the snapshot library's assertSnapshot method to save the content view as an image. But unfortunately, this doesn't work. The problem is that the second parameter is a Snapshotting strategy that can convert various UI elements into some form of data or image. But the library doesn't know what a SwiftUI View is, so it needs a way to convert the view into something that can be recognized by the snapshotter.

I added this extension to SwiftUI's View that wraps the SwiftUI View in a UIHostingController. It returns this as a UIViewController which is a valid input for a snapshotter and can be converted to an image.

extension SwiftUI.View {
    func toVC() -> UIViewController {
        let vc = UIHostingController(rootView: self)
        vc.view.frame = UIScreen.main.bounds
        return vc
    }
}

Now my first test became:

    func testDefaultAppearance() {
        let contentView = ContentView()
        assertSnapshot(matching: contentView.toVC(), as: .image)
    }

And it worked. Or rather it failed as expected because there was no image to compare it with.

Checking the error message, I was able to see where it had created the snapshot image file which I could look at. And the second time I ran the test, it passed.

If you ever get an error message saying "No such module 'SnapshotTesting'" use Shift-Command-U to re-build for testing. This usually only happens after you have cleaned your build folder.

Testing a Change

Now that I had a passing test, the next thing was to check what happens if the UI changes. This may be due to a deliberate change or because the cat just walked across your keyboard (a not infrequent occurrence around here).

Where I originally had a button with the label "Save", I decided to change this to "OK" (rejecting the cat's suggestion of "q2eegrnh").

Running the test again produced this result:

And I was then able to compare the 2 images, using the path to the failing image from the error message.

Once I had confirmed that the new image was what I wanted and not a result of error, either feline or human, I set the test to record a new result so that the new version became the official test version.

    func testDefaultAppearance() {
        let contentView = ContentView()

        record = true
        assertSnapshot(matching: contentView.toVC(), as: .image)
    }

This caused a failing test again as the new version was written to the Snapshots folder, but after removing the record = true line and re-running the test, it passed again, with my new button label now an accepted part of the test.

Using Snapshots with State

In SwiftUI, the UI displayed is a function of state, so changing state properties changes the UI. This is what makes snapshot testing really good for SwiftUI apps as you can change the state programmatically and confirm that this is reflected in the UI.

So having proved that the snapshot tests worked, I decided to move on and test it with my new anagram assistant app. This is quite a simple app that has a single AppState class that holds all the program data.

So I was able to write a suite of tests that changed the state in various ways and then snap-shotted the UI with that state. Here are a couple of examples:

    func testEmptyContentView() {
        let contentView = ContentView()
        assertSnapshot(matching: contentView.toVC(), as: .image)
    }

    func testAfterLocking() {
        var contentView = ContentView()

        let appState = AppState.sampleState()
        appState.availableLetters.sort()
        appState.selectedLetterIndex = 1
        appState.placeSelectedLetter(at: 3)
        appState.toggleLockedState()
        appState.availableLetters.sort()

        contentView.appState = appState
        assertSnapshot(matching: contentView.toVC(), as: .image)
    }

This worked really well with only one slight problem. As the state arranges the availableLetters array randomly for display, I had to add a sort to make sure they always displayed in the same order and made the tests repeatable.

And as a bonus, I was able to test a screen in dark mode with this test which sets the colorScheme:

    func testDarkMode() {
        var contentView = ContentView()
        contentView.appState = sampleAppState()

        assertSnapshot(
            matching: contentView.colorScheme(.dark).toVC(),
            as: .image)
    }

Accessibility Tests

iOS supports dynamic type and if your app uses standard font styles, it will adopt these dynamic sizes automatically. I can't find the link right now, but I remember reading an article that said nearly half of all iPhone users change the default text size, setting it either smaller or larger.

With snapshot testing, it is quick and easy to get a view of how you app looks with different font sizes. Here is my test function for taking a snapshot of every possible font size variation.

    func testDynamicFonts() {
        var contentView = ContentView()
        contentView.appState = sampleAppState()

        for contentSize in ContentSizeCategory.allCases {
            assertSnapshot(matching: contentView.environment(\.sizeCategory, contentSize).toVC(),
                           as: .image,
                           named: "\(contentSize)")
        }
    }

For the settings screen, I decided that smaller fonts were not a problem, but I wanted to check the two largest options, so I used this test function:

    func testSettingsScreen() {
        let settingsView = SettingsView()
        assertSnapshot(matching: settingsView.toVC(), as: .image)

        assertSnapshot(
            matching: settingsView.environment(
                \.sizeCategory, ContentSizeCategory.accessibilityExtraExtraExtraLarge
            ).toVC(),
            as: .image,
            named: "AccessibilityXXXL")

        assertSnapshot(
            matching: settingsView.environment(
                \.sizeCategory, ContentSizeCategory.extraExtraExtraLarge
            ).toVC(),
            as: .image,
            named: "XXXL")
    }

This let me quickly see where the problems were and what I needed to adjust.

Snapshot Test for Mac Apps

You knew you weren't going to get through this without me going on about Mac apps...

Snapshot tests for a Mac app work well, with one caveat.

First I had to change the Swift.View extension so that it returned an NSViewController instead of a UIViewController.

extension SwiftUI.View {
    func toVC() -> NSViewController {
        let vc = NSHostingController(rootView: self)
        vc.view.frame = CGRect(x: 0, y: 0, width: 1024, height: 768)
        return vc
    }
}

I chose an arbitrary size for the snapshot, you just need to make sure your UI will fit into whatever size you select.

The real problem was with sand-boxing. The snapshot library was blocked from writing the image files to the project directory if the app was sand-boxed. This seems really peculiar, since Xcode is running the tests and Xcode writes to the project directory all the time!

I found two ways around this:

Turn off sand-box mode temporarily while testing.
Make a non-sand-boxed target and use it for testing against.

Neither of these are particularly great. Option 1 is tedious, although I think it can work if the snapshots remain the same, it only fails if there is a change that it needs to write to disk.

Option 2 is tedious to set up (contact me if you would like more details) but is more seamless after that.

The best solution would be for Xcode to allow you to turn off sand-boxing for a test target. Maybe Xcode 12...

Limitations of Snapshot Testing

Ignoring the Mac and concentrating only on iOS apps for the moment, there were a few issues:

You have to run your tests against the same simulator every time, or at least against a simulator with the same screen dimensions. I decided to to use the iPhone SE (2nd generation) as it has a small screen and I find smaller screens to be more of a problem than large ones. You also need to make sure it is always using the same appearance: light or dark, unless you want to specify this for every test.

I ended up with this setup function that ran before my snapshot test suite:

    static override func setUp() {
        let device = UIDevice.current.name
        if device != "iPhone SE (2nd generation)" {
            fatalError("Switch to using iPhone SE (2nd generation) for these tests.")
        }

        UIView.setAnimationsEnabled(false)
        UIApplication.shared.windows.first?.layer.speed = 100

        record = false
    }

This uses a couple of tricks that are supposed to speed up tests and has a record setting that I could set for the entire suite if I wished, and it throws a fatalError if I select the wrong device or simulator.

It would be neater if Xcode allowed you to select a simulator in the test target build settings, but I think you can only do this if you run tests from the command line.

Snapshot tests confirm that the UI matches the state, but they do not check to see if the state changes in response to user input. That is the missing link that UI testing provides, but even without that, I believe that snapshot testing is a very useful tool and much better than having no form of UI testing at all.
You need to look at your snapshots. This may sound obvious but the snapshot library creates a set of images. These images are then set as the goal for future tests. If you don't check that they are correct, then every test could be confirming that the UI is wrong but unchanged. If the tests report a difference, look at both copies and see which one is right. For the same reason, the snapshot images need to be included in your version control repository.

Summary

Will I use snapshot tests for my SwiftUI apps? Yes, definitely. I use unit tests for my model classes but mostly avoid UI tests as they are too clumsy to write and time-consuming to run. Snapshot tests are better for SwiftUI, and very fast.

Huge thanks to Vadim Bualvin for the original inspiration for this article. Go and read his blog post for a more detailed look. And thanks to Brandon Williams & Stephen Celis at Point-Free for getting me going after my initial discarding of the idea. Any mistakes or errors are mine and not theirs.

If you want to learn about UI testing for SwiftUI apps, I recommend watching azamsharp's YouTube video: User Interface Testing for SwiftUI Applications.

As always, if you have any comments, suggestions or ideas, I would love to hear from you. Please contact me using one of the links below or through my Contact page.

Name This App

2020-05-09T01:26:21Z

My current work in progress is an iPhone app designed to make it easier to solve crossword anagrams by emulating and improving upon an ability that was there when we used to do crosswords on paper, but is missing for digital crosswords.

But I cannot think of a clever name for the app, so please read the story and contact me with your name suggestions or if you would like to test the pre-release version of this app.

Cryptic Crosswords

Programmers are basically puzzlers, and programming is the world's best type of puzzle, but I like to start my day with a cryptic crossword. Like programming, cryptic crossword clues have their own syntax and what seems like gibberish on a first glance, can be parsed into logical parts to take you to the answer. But there are aspects of solving crosswords that were easier with pencil and paper, so I decided to write an app to help fill one of those gaps.

My crossword of choice is the Crosaire crossword from The Irish Times. A lot of newspapers have a cryptic crossword and most of them need a subscription, but the Irish Times has a crossword only subscription that I really like. Crosswords also tend to require some local knowledge, but for the Crosaire, if you remember that the Abbey and the Gate are both theatres and that Down is a county, you will have most of what you need. And as an added bonus, the crossword creator later blogs the solutions with explanations so you can learn how the clues were constructed if you are totally mystified.

Anagrams

Anagrams are a very popular clue type but they can be tricky to solve because our brains are too good at discerning patterns. We can recognize words using only the first and last letters if they have the correct number of letters inside. This means that asking our brains to scramble these letters into a completely different word is very difficult. In the olden days, when I used to do crosswords in the newspaper, the best method was to find a space in the margin and write the letters out in a circle which forced my brain to reconsider the options.

Here is an example from a recent Crosaire:

Users rip off revelation (8)

The word "off" is a hint that this is an anagram, "Users rip" has the right number of letters, so the overall clue must be "revelation". This is not a very long anagram and I think having two words makes it easier, but lets take a look at how I would solve this the old-fashioned way. (And I knew the "I" was the third last letter.)

If you watch this gif and then look at it when it stops repeating, hopefully you will be able to see that the answer is "SURPRISE". Refresh the page if you want to start the gif looping again.

But I do crosswords on my iPad now and while I could use a notes app and my Apple Pencil to draw the letters out like I did in the GIF above, I don't always have the Pencil with me and I want to keep looking at the crossword. So I decided that a companion iPhone app was the way that would work best for me.

There are sites and apps that offer anagram solvers, but they are just looking through a dictionary and showing you all the possibilities. To me, this feels like cheating, but I don't have a problem with using an app to emulate the techniques I used to use with pencil and paper.

App Design

So I planned out the basic features of the app:

enter a word
display the letters in a circle
shuffle these letters if needed
place letters in a possible solution

Arranging the letters in a circle was made relatively easy by using SwiftUI. I placed the letters in a ZStack so they were all piled on the one spot. Then I calculated the X & Y offsets needed to move each letter to the edge of a circle. This involving digging out some long-forgotten trigonometry to convert from polar coordinates to rectangular coordinates. I could calculate the radius of the letter circle based on the screen size and the angle between each letter was 360 degrees divided by the number of letters. So some quick calculations converted these two numbers into X & Y coordinates for each letter, and then I had my circle.

    var radiansBetweenLetters: Double {
        let degrees = 360.0 / Double(anagramLetters.count)
        let radians = degrees * .pi / 180
        return radians
    }

    var radiusForCircle: Double {
        let screenWidth = UIScreen.main.bounds.width
        return Double(screenWidth * 0.35)
    }

    func XoffsetForLetterAt(index: Int) -> CGFloat {
        // x = R cos t
        let totalRadians = radiansBetweenLetters * Double(index)
        let x = radiusForCircle * sin(totalRadians)
        return CGFloat(x)
    }

    func YoffsetForLetterAt(index: Int) -> CGFloat {
        // y = R sin t
        let totalRadians = radiansBetweenLetters * Double(index)
        let y = radiusForCircle * cos(totalRadians)
        return CGFloat(y)
    }

The original word was converted into an array for display, so re-arranging the letters was a matter of calling shuffle() on the array which automatically triggered a SwiftUI redraw.

And here is version 1 of the interface running in the SwiftUI Canvas:

Refresh the page to see the gif play, if it has stopped.

A Different Type of Anagram

Now we come to a variation of the anagram clue that is very popular with the author of the Crosaire crossword. I don't know if there is an official name, but I call them "subtraction anagrams".

Here is an example:

Creationist has no taste for what's sarcastic (6)

The idea here is to remove the letters in "taste" from the letters in "Creationist" and then unscramble the remaining letters to find a word that means "sarcastic". My first attempt at this used a Trash can button that removed the letter and shortened the space for the solution, but then I decided to have a discard tray at the bottom of the screen to show what had been removed and allow replacing any letters discarded by mistake.

After this, I added a bit of style to make it look nicer and then moved on to the next feature. If I knew some of the cross letters already, I wanted to be able to place them in the solution squares and then lock them in place. This would allow me to shuffle in letters to test and remove all the unlocked ones with a button click. So here is what the app looked like after those changes:

Refresh the page to see the gif play, if it has stopped.

Drag & Drop

My next experiment was with drag & drop to place or discard letters. I waited until iOS 13.4 brought drag & drop to SwiftUI but I was not happy with the result. Firstly, there is a big lag on dragging. You have to hold your finger down on a letter for quite a while before it becomes draggable. This was so counter-intuitive that I thought it wasn't working, but occasionally it did work and so I eventually deduced that it was a timing issue.

The second problem was solved thanks to a suggestion by Luis Ramos on Twitter. When I dragged a letter, the drag preview image was the shuffle button from the middle of the ZStack instead of the selected letter. This was solved by moving the onDrag modifier to BEFORE the offset modifier (not AFTER like I said in my original response to Luis). But I was still not happy with it, so I decided to discard this idea and stick to tapping.

There was one side-effect: I wasn't able to get the drag preview to be round - it was a square with opaque corners. As a work-around, I changed the letters to be inside squares and then decided this was a better look anyway, since it was more like what you see in a crossword.

Further UI Enhancements

I installed a custom font so that it looked more like hand-writing. I wrote about installing custom fonts in a separate article, so if you are interested check that out for details on the multiple steps that you need to take to get them to work. I went through a few different fonts until I found one that I thought worked well and clearly for all the upper case letters but I settled on Oregano. And then I made the app work in dark mode too:

The clue for this one is "Consumables minus bacon and shellfish (6)"

Animations

SwiftUI has animation built in, so I was able to add an animation modifier to the various views to make the transitions look smooth. I particularly liked the way the letters re-arranged themselves around the circle when I removed or replaced a letter.

But to add something extra, I thought it would be fun if the letters all started in the middle and moved outwards to their places on the circle. The way I did this was by using a Boolean to store whether the letters had had their first draw. If not, the radius of the circle was zero, so they all piled in the middle. After a delay, this Boolean was toggled so the radius was changed to the full size and the animation modifier already applied, made the letters smoothly expand outwards.

For the letter shuffle, I did the reverse, moving the letters in, shuffling, then moving them out again.

Refresh the page to see the gif play, if it has stopped.

I also added sound effects and a slide-up sheet view with settings and help. I enjoyed using Apple's SF Symbols to show icons for each paragraph of the help, although I may change the colour of these icons as they look at bit too much like buttons right now.

Next Steps

Well, I am hoping that someone will come up with a good name. I thought of "Anagram Assistant" but that doesn't fit underneath the home screen icon and it was shortened to "Anagram". I don't want people to see it and think it is just one of those dictionary lookup anagram finders, so I would like something more descriptive while still being short, or at least having a short variant.

In honour of P.G.Wodehouse's favourite crossword clue, I thought of calling it "E blank U" but that isn't an anagram, so it doesn't really work. For people not familiar with that reference, Wodehouse's less quick-witted characters always get stuck on "Large flightless Australian bird, 3 letters. E blank U".

A clever name would be good - perhaps an anagram itself? If you think of anything, please let me know on Twitter, by using the email link below or through the Contact page. The namer will get full credit in the app. And use one of those methods to contact me if you would like to test the app before it is released.

Once I have a name, I can get to work on the usual secondary tasks which take so much time: App Store set up, screen shots, a support page and so on.

I haven't tried an iPad version yet. I got stung once by testing an iPad version of an app, deciding it didn't work well and then running into Apple's ban on dropping a platform from a published app. This has discouraged me from iPad apps ever since, which I doubt was their intention.

And if you are curious about the solutions to the clues I used in the examples:

Users rip off revelation (8) = SURPRISE
Creationist has no taste for what's sarcastic (6) = IRONIC
Consumables minus bacon and shellfish (6) = MUSSEL

SwiftUI Color

2020-05-09T01:26:08Z

As developers, we are used to thinking of color as a numeric way to specify a particular tint. But in SwiftUI, Color - like almost everything else - is actually a View in its own right. This leads us to two very interesting questions: how do we use a view to specify a color and how can we use the fact that Color is View?

Specifying a Color

To start my investigations of Color, I created a new iOS single view app in Xcode. Regular followers will know that I am a passionate advocate of macOS programming, but when experimenting with SwiftUI, I prefer to use an iPhone app as the preview canvas fits very neatly into the main Xcode window.

The default ContentView contains a single Text view. To change the color of the text in this view, I added a modifier:

  Text("Hello, World!")
      .foregroundColor(.red)

The foregroundColor modifier expects a Color so there was no need to tell it that the parameter is a Color and I was able to use the short way of describing one of the standard colors.

Adding a background color is a bit different because a background can be any view, not just a color. So the modifier needs to specify that this is a Color view, as well as setting the actual color.

    Text("Hello, World!")
        .padding()
        .foregroundColor(.red)
        .background(Color.yellow)

I added the padding to make the overall size bigger so that the background color was more obvious.

Command-click on .red or .yellow in the code and select "Jump to Definition". This lists the available pre-defined colors. As well a set of basic colors and a clear option, there are two extra entries: primary & secondary. And if you scroll back up the page a bit, you will see another one: accentColor.

Choosing one of the preset options is the easiest way to select a color. But try this:

In your code, type let uiColor = UIColor. and have a look at the auto-complete suggestions that appear after you type the period. Scrolling past the various init methods, you will see that UIColor has a lot more options than Color. There are a bunch of colors, a section of system colors and a lot of semantic colors like placeholderText, secondarySystemBackground.

Why does UIColor get these other useful looking options and Color does not?

Well, I don't have an answer to that except that I hope they will appear over time. But in the meantime, it is easy enough to create a SwiftUI Color from a UIColor.

    let backgroundColor = Color(UIColor.secondarySystemBackground)

    var body: some View {
      VStack {
        Text("Hello, World!")
      }
      .background(backgroundColor)
    }

If you know the RGB values of the color you want to use, it is possible to create a Color directly by various methods like this one for setting the color using the RGB values.

    let rgbColor = Color(red: 1.0, green: 0.5, blue: 0.5)

But when you get to this stage, I strongly suggest that you start using color assets instead.

Using Color Assets

Go to Assets.xcassets and click the plus button at the bottom of the list of assets. Select "New Color Set" and you will get a new asset called "Color". You can double-click the name to edit it to something that makes sense to you.

While naming it after the color may seem logical, I prefer to think about the use cases for this color and set the name to something like "cardBackground" or "alertText".

By default, your new color set will contains a single color block. Click in the color block itself and then you will be able to edit the color in the Attributes Inspector. If you click the "Content" popup, you will get access to all the system colors, and you can also select any color space and create a custom color using that color space. Click "Color Panel" to access a standard color picker if you need it. And change the input method to whatever suits the color information you have.

Modern apps need to be able to handle light and dark modes, and this is where using a color set really shines. Set the color to what you want to use for light mode and then choose "Any, Dark" from the Appearances popup menu in the Attributes Inspector.

Now your color set has two blocks and you can change the Dark one to whatever color this should be in dark mode. This feature of Color Sets is a very strong argument for using them instead of defining colors using their RGB values.

And now for the really neat part. To use any of these color sets in your code, add a modifier like foregroundColor just the same as usual, but when the placeholder for the color is selected, press Shift-Command-L to bring up the Library palette and choose the Color icon at the right. You will see all your color sets there and you can insert them easily and accurately.

Here is the code for my AlertView using two color sets.

Some people may object to using "magic strings" to specify the color sets but I feel that so long as the Library is used to insert the color names automatically, there is very little chance of error. But you could always make an enum or struct of color name constants and use these instead.

struct AlertView: View {
    var alertText = "Something went wrong!"

    var body: some View {
        Text(alertText)
            .padding()
            .background(Color(UIColor.secondarySystemBackground))
            .cornerRadius(15)
            .shadow(color: Color("alertShadow"), radius: 5, x: 1, y: 1)
            .foregroundColor(Color("alertText"))
    }
}

struct AlertView_Previews: PreviewProvider {
    static var previews: some View {
        Group {
            AlertView().preferredColorScheme(.light)
            AlertView().preferredColorScheme(.dark)
        }
        .previewLayout(.sizeThatFits)
    }
}

And here is a composite image showing the two versions of the alert with the colors specified by two color sets:

Light & Dark Mode System Colors

Color's preset colors adapt automatically to the environment so that they work with dark mode or light mode just like your own Color Sets can.

I wrote a test view to loop through all the preset colors (except clear) and display their descriptions in their own color.

struct ContentView: View {
    let standardColors: [Color] = [
        .black, .white, .gray, .red, .green, .blue, .orange,
        .yellow, .pink, .purple, .primary, .secondary, .accentColor
    ]

    var body: some View {
        VStack(alignment: .leading) {
            ForEach(standardColors, id: \.self) { color in
                Text(color.description)
                    .bold()
                    .foregroundColor(color)
            }
            .font(.title)
        }
        .padding()
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        Group {
            ContentView().preferredColorScheme(.light)
            ContentView().preferredColorScheme(.dark)
        }
    }
}

The canvas shows two previews: one for light mode and one for dark mode.

If you have a color picker app (I use Colorpicker), you can detect the RGB values in the two previews. I made the font bold to make this easier. Red is rgb(232, 77, 61) in light mode but rgb(233, 85, 69) in dark mode. And the others have similar modifications to make them look their best in each environment.

Take particular note of the three at the bottom of the list: primary, secondary and accentColor. These are incredibly useful when making a layout that works in both light and dark modes.

When choosing a UIColor or NSColor, it is best to use the system versions, so .systemBlue instead of .blue as this gives the dark/light variants that we just saw. And the other semantic colors like UIColor.secondarySystemBackground also have dark/light variants automatically.

Color as a View

Now let's consider the effect of Color being a view and not just a description of a tint. Imagine you wanted to draw a colored box on the screen. Using UIKit, you would probably think of using a UIView. With AppKit, maybe an NSBox. Or perhaps you would have jumped straight to a Bezier path.

Create a new SwiftUI view and replace the default Text with a Color, like this:

struct BoxView: View {
    var body: some View {
        Color.blue
    }
}

Resume the canvas preview and you will see the color fill the preview iPhone screen, except for the safe areas top and bottom.

To make this into a box, add a frame modifier with the required height and width. And now you have a box, far more easily than you could in either UIKit or AppKit.

To be honest, in SwiftUI, you would probably use a Rectangle instead of a plain Color if you wanted a box of a set size but it is interesting to consider how Color could be made to work.

A more valuable use of Color is to set the background.

struct BackgroundView: View {
    var body: some View {
        ZStack {
            Color.green

            Text("Hello, green background")
        }
    }
}

This makes the entire background green and shows the text centered on it.

And to make the color extend into the safe areas:

  Color.green.edgesIgnoringSafeArea(.all)

I prefer to put the edgesIgnoringSafeArea modifier on the Color only and not on the entire ZStack. That way the other contents of the ZStack will all stay inside the safe area.

So in summary, use preset colors or color assets to set your colors. And use the Color view to set a background color for a view.

I hope you found this article useful, and if you have any suggestions, corrections or improvements, please contact me using one of the links below or through the Contact page.

Custom Fonts in iOS & macOS apps

2020-04-01T00:27:59Z

As a rule, I prefer to use fonts that come pre-installed with the system. That means that your interface is already familiar to users, you get dynamic font sizing and if Apple updates the fonts, you get the updates without doing anything.

But sometimes, you really need to use a different font in your apps, and as the process of getting a custom font to display in your app can be confusing and tedious, I thought I would go through the steps for both iOS and macOS apps.

I probably should have published this on a different day, but it is not a joke.... really.

Getting a Font File

The first thing is to find a suitable font and make sure that the license for that font matches your use. I wanted a font that looked like it was hand-written, so I went to fontspace and searched the hand-writing category there.

Since I wanted to use this in a paid app, I checked the "Commercial-use" button to limit the search. The one I chose was called "Painting With Chocolate" by "Make mooze"

I downloaded the font and un-zipped the file which gave me a single file called "Paintingwithchocolate-K5mo.ttf". You can use either ".ttf" or ".otf" font files.

Using the Font in an iOS App

Now to use the font, first in an iOS app. Boot up Xcode and create a new SwiftUI project for iOS.

Once the project is open, drag the font file into the Project Navigator. At this stage there are 2 crucial settings:

Check "Copy files if needed".
Check your app in the "Add to targets" section.

In one of my tests, the file stayed in the Downloads folder even after checking "Copy files", so I deleted the reference, manually moved the font file to my project folder and added it again.

Now the font file is in the project but there is still more work to do.

Select the font file in the Project Navigator. Press Return as if you are going to edit the name. Select the complete file name, including the file extension and copy it.

Now go to the Info.plist file. Right-click in the blank space below the existing entries and select "Add Row" from the popup menu. In the box that appears, start typing "Font" using an upper-case "F". When you see "Fonts provided by application", select that.

This entry is an array. Click the disclosure triangle to the left and you should see "Item 0" appear. Paste the name of your font file, including the file extension, into the value for "Item 0".

Your app now has a font file and knows to make it available. But you aren't finished yet.

To use a custom font, you need to know its exact name. In SwiftUI, the code will be something like this:

  Text("Hello, World!")
      .font(.custom("Font-Name-Goes-Here", size: 14))

But the exact name is not always obvious and is rarely the file name. So the best thing to do is to ask the app what fonts it now has available. This will also act as confirmation that the font file is being included correctly in your project.

To get the app to list all its fonts, I used this:

struct ContentView: View {
    var body: some View {
        Text("Hello, World!")
            .onAppear { self.listInstalledFonts() }
    }

    func listInstalledFonts() {
        let fontFamilies = UIFont.familyNames.sorted()
        for family in fontFamilies {
            print(family)
            for font in UIFont.fontNames(forFamilyName: family).sorted() {
                print("\t\(font)")
            }
        }
    }
}

You can run the app in the Simulator or use "Debug Preview" to make this show up in the console, but once you have the list, scroll through in until you find the font you just added. The headers are the names of font families and the indented entries are the font names themselves.

This time I found that the name of the font was quite obvious: "PaintingWithChocolate" but this is not always the case. And if the font has any variants, you will need to use the complete name e.g. "Optima-ExtraBlack"

With the name of the font, you are finally able to use it in the app, like this:

struct ContentView: View {
    var body: some View {
        Text("Hello, World!")
            .font(.custom("PaintingWithChocolate", size: 40))
    }
}

Using the Font in a Mac App

The process for a Mac app is mostly the same.

Install the font file in your project as before, making sure to copy the file into the project and to add it to the app target.

For a Mac app, you do not need to specify the font file name in your Info.plist file. Instead, you have to tell the Info.plist where to look for custom fonts in your project directory.

Open your Info.plist, right-click in the blank space below the existing entries and select "Add Row" from the popup menu. Start typing "Application" using an upper-case "A". When you see "Application fonts resource path", select that and enter a period as the value. A period or full-stop tells Xcode that you mean the current directory but even if you have your fonts in a sub-directory, this seems to work.

You do not need to set "Fonts provided by application" for a Mac app, although if I had a problem, I would set it as I feel that this is something that Apple may add at some stage.

While I was using the same font for both apps and so already had the exact name, you may still need to check the list of installed fonts in a Mac app. The function for doing that is quite different:

  func listInstalledFonts() {
      let fontFamilies = NSFontManager.shared.availableFontFamilies.sorted()
      for family in fontFamilies {
          print(family)
          let familyFonts = NSFontManager.shared.availableMembers(ofFontFamily: family)
          if let fonts = familyFonts {
              for font in fonts {
                print("\t\(font)")
              }
          }
      }
  }

The format of the print-out is different too, but you can see where I have selected the exact name to use.

Then the SwiftUI code for using the font was just the same:

struct ContentView: View {
    var body: some View {
        Text("Hello, World!")
            .font(.custom("PaintingWithChocolate", size: 60))
            .frame(maxWidth: .infinity, maxHeight: .infinity)
    }
}

Storyboard apps

The examples above were both SwiftUI projects, but these techniques work much the same in a storyboard project.

Follow the same steps to install the font and configure the Info.plist file and use the same functions to list the installed files.

To use the fonts, if you are using a storyboard in an iOS project, select "Custom" in the font picker and then you will be able to see your custom font listed if it is installed correctly. I could not work out how to get the custom font appearing in this menu for a macOS app.

To apply the font programmatically, you can use something like this:

    // iOS
    fontLabel.font = UIFont(name: "PaintingWithChocolate", size: 36)

    // macOS
    fontLabel.font = NSFont(name: "PaintingWithChocolate", size: 24)

Trouble-shooting

If you have gone through these steps and the font still isn't working, here are a few things to check:

Is the font file's target membership set to the app?
Is the font file being included in the "Copy Bundle Resources" build phase? If not, drag it in manually from the Project Navigator.
iOS Info.plist - is there a typo in the "Fonts provided by application" setting? Copy the file name and paste it in directly rather than trying to re-type it.
macOS Info.plist- have you put a single period "." in the "Application fonts resource path" setting?
Run the font name listing utility - does the font show up there?
Have you used the font name EXACTLY as shown in the font listing? Copy & paste it from the font list.

Having struggled with various of these steps myself recently, I thought it was worth documenting it. I am sure that future me will be grateful, but hopefully others will find it useful also.

If you have any suggestions, corrections or improvements, please contact me using one of the links below or though the Contact page.

SwiftUI for Mac Extras

2020-01-27T01:32:57Z

Last year, I wrote a 3 part series of articles on using SwiftUI to build a Mac app. I would like to thank everyone who contacted me about this series. It was received very well and revealed that there is still a large amount of interest in programming for the Mac.

Some of the responses I got were pointing out different or better ways to do things, so I am going to list them here, adding to this post as I get new information. The relevant sections in the original posts will have links to the fixes suggested here, but I decided it was easier to list the changes in a separate post, rather than asking people to re-read the whole series looking for modifications.

Dismissing sheets

I just read your series on writing Mac apps with SwiftUI. Great stuff! Just wanted to add that in part 2 when dismissing sheets there are two ways to do that, one of them is the one that you figured out and the other is to have the view dismiss itself by grabbing its PresentationMode from the environment. This way you don’t need to pass presentation bindings to your sheet views.

Paul Hudson of Hacking with Swift explains how to use both methods very clearly in his article on How to make a view dismiss itself.

My original technique passed the Boolean that triggered the sheet to appear, as a Binding to the sheet view. The sheet view could then toggle this to make the parent view dismiss it.

  .sheet(isPresented: $sheetIsShowing) {
      SheetView(isVisible: self.$sheetIsShowing)
  }

struct SheetView: View {
    @Binding var isVisible: Bool

    var body: some View {
        VStack {
            Text("This is a sheet.")
            Button("OK") {
                self.isVisible = false
            }
        }
        .frame(width: 300, height: 150)
    }
}

The presentation mode method leaves it up to the sheet to dismiss itself. The parent view shows the sheet but does not pass any binding.

  .sheet(isPresented: $sheetIsShowing) {
      SheetView()
  }

The sheet view gets an environment property that it can use to change its presentation mode, dismissing itself that way.

struct SheetView: View {
    @Environment(\.presentationMode) var presentationMode

    var body: some View {
        VStack {
            Text("This is a sheet.")
            Button("OK") {
                self.presentationMode.wrappedValue.dismiss()
            }
        }
        .frame(width: 300, height: 150)
    }
}

I guess the presentation mode method is slightly easier to understand and it leaves the caller of the sheet view less cluttered which is a good thing. But the two methods are functionally identical, so use whichever you prefer. The sample project now contains both methods, with one commented out, so you can swap the comments to test.

Subscribing on the Main Thread

In part 2 of this series, I created a menu item caused the downloaded image to be flipped. Selecting the menu item posted a notification:

    @IBAction func flipImage(_ sender: Any) {
        NotificationCenter.default.post(name: .flipImage, object: nil)
    }

which the view showing the image was listening for.

    private let flipImageMenuItemSelected = NotificationCenter.default
        .publisher(for: .flipImage)

The outermost component of the view's body used an onReceive modifier to get this notification and react accordingly.

  var body: some View {
      VStack {
        // layout omitted for brevity
      }
      .onReceive(flipImageMenuItemSelected) { _ in
          DispatchQueue.main.async {
              self.imageIsFlipped.toggle()
          }
      }
    }

Since the notification was triggering a change to the UI, I made sure that this happened on the main thread.

But it was pointed out to me that it would be easier to make sure that the publisher was set up to use the main thread all the time, instead of having to specify the main queue when processing the notification.

So now the publisher is defined like this:

  private let flipImageMenuItemSelected = NotificationCenter.default
      .publisher(for: .flipImage)
      .receive(on: RunLoop.main)

And the onReceive modifier can toggle the imageIsFlipped flag directly, without having to worry about the thread.

This seems to me a much better solution as it sets the correct thread once when the publisher is created and makes using it much cleaner and easier.

Passing data back from AppKit

The previous two changes have been more a matter of style, but this one is a real error that would stop an app working as it should.

In the User Interface Elements section of the series, I used NSViewRepresentable to embed a standard NSColorWell in a SwiftUI view. I thought this was working properly, but then I got this email:

I noticed that the selectedColor in the EmbeddedColorWell is not being mutated and is not being used in a two-way manner. The selectedColor is initialized to NSColor.blue and used to set the color in the NSColorWell view. When the NSColorWell color is changed, it does change the color of the EmbeddedColorWell view. However, the actual @State var selectedColor value is never mutated in this process beyond the initialized value of NSColor.blue.

This is in the Form tab of the UI Samples window. As suggested to me, I added a background modifier to set the background of a portion of the view to the selected color. And although the NSColorWell showed newly selected colors, the background remained stubbornly blue.

The solution was to add a Coordinator to the NSViewRepresentable and have it subscribe to any changes in the color and update the embedded view's selected color as needed. I would not have come up with this by myself, so many thanks to the person who sent it to me.

Here is the full code for the EmbeddedColorWell struct:

struct EmbeddedColorWell: NSViewRepresentable {
    @Binding var selectedColor: NSColor
    
    class Coordinator: NSObject {
        var embedded: EmbeddedColorWell
        var subscription: AnyCancellable?

        init(_ embedded: EmbeddedColorWell) {
            self.embedded = embedded
        }
        
        // Observe KVO compliant color property on NSColorWell object.
        // Update the selectedColor property on EmbeddedColorWell as needed.
        func changeColor(colorWell: NSColorWell) {
            subscription = colorWell
                .publisher(for: \.color, options: .new)
                .sink { color in
                    DispatchQueue.main.async {
                        self.embedded.selectedColor = color
                    }
            }
        }
    }
    
    func makeCoordinator() -> EmbeddedColorWell.Coordinator {
        Coordinator(self)
    }
    
    func makeNSView(context: Context) -> NSColorWell {
        let colorWell = NSColorWell(frame: .zero)
        context.coordinator.changeColor(colorWell: colorWell)
        return colorWell
    }
    
    func updateNSView(_ nsView: NSColorWell, context: Context) {
        nsView.color = selectedColor
    }
}

In the previous section, I changed the publisher to use the main RunLoop so as to avoid having the use DispatchQueue.main.async. In this instance, that did not work so well. It only updated the selected color after the mouse had been released. But using DispatchQueue.main.async made the update live.

As I explained at the start of these articles, I was documenting my explorations in using SwiftUI for a Mac app and while I hoped there would be some useful examples, this was not intended to be a definitive guide. So I am very grateful to everyone who has contributed to these updates.

If you have anything more that you would like to be included, please contact me using one of the contact buttons below or through the Contact page on this site.

The edited project is available on GitHub.

SwiftUI for Mac - Part 3

2019-12-15T07:28:20Z

In part 1 of this series, I created a Mac app using SwiftUI. The app uses a Master-Detail design to list entries in an outline on the left and show details about the selected entry in the detail view on the right. In part 2 I explored using menus, adding all the expected user interface elements and opening secondary windows.

In this third and final part, I want to look at the various ways to present dialogs to the user.

There are four different types of dialog that I want to explore:

Alert
Action
Sheet
File dialogs (open & save)

So the first thing to do is add a footer to the DetailView to trigger each of these. I am going to separate this out into a new subview for neatness.

Alert

To make an Alert, I need an @State Bool which sets whether the alert is visible or not. All the button has to do is toggle that Bool. Stripping out the extra code and views, this is what I have.

struct DialogsView: View {
    @State private var alertIsShowing = false
    @State private var dialogResult = "Click the buttons above to test the dialogs."

    var body: some View {
        Button("Alert") { self.alertIsShowing.toggle() }
    }
}

To configure the alert itself, I added an alert modifier to the outmost view in this view. The dialogResult string is a diagnostic that I can use to confirm that the results of the various dialogs get passed back to the parent view.

  Alert(title: Text("Alert"),
        message: Text("This is an alert!"),
        dismissButton: .default(Text("OK")) {
          self.dialogResult = "OK clicked in Alert"
      })

There were a few things that tripped me up in this relatively short chunk of code. Firstly, both title and message must be Text views, not strings. If you get an error message that says "Cannot convert value of type 'String' to expected argument type 'Text'", then you have forgotten to use a Text view.

Then there is the button which auto-suggest tells me is of type Alert.Button. I couldn't find any documentation for this, but delving into the definition for Alert, I see that there are three pre-defined button types: default, cancel or destructive. Cancel actually has two variants and will use a label appropriate to the user's locale if no label is supplied.

Again, these buttons need a Text view as the label (if supplied) and can take an action closure, which I used to update my dialogResult string.

This version showed a single dismissButton but I saw that there was a variation of Alert with primary and secondary buttons. It was not obvious that these would also dismiss the alert dialog, but I tried anyway.

  Alert(title: Text("Alert"),
        message: Text("This is an alert!"),
        primaryButton: .default(Text("OK"), action: {
          self.dialogResult = "OK clicked in Alert"
        }), secondaryButton: .cancel({
          self.dialogResult = "Cancel clicked in Alert"
        }))

This worked very nicely and the Esc and Return keys triggered the two buttons as you would expect with both of them closing the dialog.

I tried using the destructive button type, but there was no difference to either the appearance or behavior of the button.

So Alert is a great choice for a text-based dialog, either for informational use or to allow two choices of action.

Action

Very short section here - 'ActionSheet' is unavailable in macOS! I probably should have researched that before I started this section. So use Alerts, I guess or a custom sheet.

Sheets

While Alerts have a very fixed structure, sheets allow us to put any SwiftUI view into a sheet dialog.

So I added another Bool for the Sheet button to toggle, and added this sheet modifier. SheetView right now is simply a TextView.

  .sheet(isPresented: $sheetIsShowing) {
      SheetView()
  }

This didn't work so well. It showed the sheet, but the sheet was tiny - only the size of the Text view it contained. And I had no way of dismissing it...

The size problem was solved by setting a frame on the Text view in SheetView.

The trick to dismissing the sheet is to pass it a Binding to the Bool that triggered it to open in the first place. If a button in the sheet sets this Bool back to false, the parent view will hide the sheet. That sounds confusing, but it works.

  .sheet(isPresented: $sheetIsShowing) {
      SheetView(isVisible: self.$sheetIsShowing)
  }

struct SheetView: View {
    @Binding var isVisible: Bool

    var body: some View {
        VStack {
            Text("This is a sheet.")
            Button("OK") {
                self.isVisible = false
            }
        }
        .frame(width: 300, height: 150)
    }
}

Here is a very bad diagram that tries to explain what is happening:

The parent view has an @State Boolean variable called sheetIsShowing. This is bound to the alert's isPresented so it dictates whenever the sheet is visible. When the Sheet button is clicked, this variable is set to true and the sheet opens. But at the same time, a Binding to this variable is passed to the sheet. I deliberately gave this a different name, so as to make it clear which View was changing what variable.

When the sheet wants to close, it does not close itself. Instead it sets this variable to false. Because it is a Binding, this sets the original sheetIsShowing variable on the parent view to false and the parent view then closes the sheet.

UPDATE: Look at Dismissing sheets in my post of extras & changes to this series for an alternative way to dismiss a sheet.

Sheets & Data

With this in place, I had the sheet opening and closing perfectly, but I was not yet passing data back & forth between the sheet and its parent view. I decide to put a TextField in the SheetView and bind its contents to the dialogResult property in the DetailView so that any edits appeared immediately in the DetailView. And while I am there, I might as well add some more decorations to the SheetView since it is a full View and not a restricted Alert.

Calling the SheetView changed to this:

  .sheet(isPresented: $sheetIsShowing) {
      SheetView(isVisible: self.$sheetIsShowing, enteredText: self.$dialogResult)
  }

And the SheetView itself (not all the interface is listed here for brevity):

struct SheetView: View {
    @Binding var isVisible: Bool
    @Binding var enteredText: String

    var body: some View {
        VStack {
            Text("Enter some text below…")
                .font(.headline)
                .multilineTextAlignment(.center)

            TextField("Enter the result of the dialog here…", text: $enteredText)
                 .padding()

            HStack {
                Button("Cancel") {
                    self.isVisible = false
                    self.enteredText = "Cancel clicked in Sheet"
                }
                Spacer()
                Button("OK") {
                    self.isVisible = false
                    self.enteredText = "OK: \(self.enteredText)"
                }
            }
        }
        .frame(width: 300, height: 200)
        .padding()
    }
}

I only had two issues with this now. I was not able to get the focus into the TextField automatically when the sheet opened and I was not able to assign keyboard shortcuts to the Cancel and OK buttons so that they could be operated without a mouse. And as I mentioned in the previous part, I was not able to make the OK button take on the default styling.

One useful technique that I developed: the SheetView is in the DialogsView.swift file instead of in its own SwiftUI file. It would probably be a good idea to separate it out but I didn't which meant that it had no Canvas preview to look at while I was laying it out.

So I edited the PreviewProvider like this, so that I could change the comments to switch it between showing the DialogsView and showing the SheetView.

struct DialogsView_Previews: PreviewProvider {
    static var previews: some View {
        // DialogsView()
        SheetView(isVisible: .constant(true), enteredText: .constant(""))
    }
}

Files

AppKit provides NSOpenPanel for selecting a file and NSSavePanel for saving. I will try to implement NSSavePanel to allow saving the current cat image.

Since this is an AppKit control rather than a SwiftUI control, I assumed that I would need to use NSViewRepresentable like I did for the NSColorWell in part 2. But while NSColorWell is a descendent of NSView, NSSavePanel is not. So I need a new idea.

Rather naively, I thought maybe I could just create an NSSavePanel in a function inside DialogsView and see what happened.

  func saveImage() {
      let panel = NSSavePanel()
      panel.nameFieldLabel = "Save cat image as:"
      panel.nameFieldStringValue = "cat.jpg"
      panel.canCreateDirectories = true
      panel.begin { response in
          if response == NSApplication.ModalResponse.OK, let fileUrl = panel.url {
              print(fileUrl)
          }
      }
  }

Crash & burn... so what if I made the NSSavePanel an @State property of the View? No, that crashed even faster. Maybe SwiftUI Views don't like this sort of thing, but how about if I get the Application Delegate to handle it? What if I moved the saveImage method to the App Delegate and changed the calling function to access it there?

Still crashed. At this stage I am beginning to wonder if I know how to use an NSSavePanel. Time to create a simple test app without SwiftUI and see what happens. Well it appears that I no longer know how to use an NSSavePanel. Code from an older project that works fine, will not work in my new sample project!

Guess what - it was another macOS Catalina security issue which I would have realised faster I had opened the Console. Back to the Signing & Capabilities section of the target settings and this time I set File Access for User Selected File to Read/Write.

Now the NSSavePanel opens when called from DialogsView and prints the selected file URL if one is chosen.

But this is all happening in DialogsView, which is a subview of DetailView. And DetailView is the view that holds the image, not DialogsView. So how can I save the image? Do I pass the URL to DetailView or pass the image to DialogsView? Or do something clever with Notifications and Subscriptions?

I really don't know what is best, but I have decided to post a Notification with the URL as its object. DetailView can receive this Notification and save the image whenever it is received.

So I replaced the print line in the saveImage() method with:

  NotificationCenter.default.post(name: .saveImage, object: fileUrl)

And in DetailView, I set up the publisher:

    private let saveImageUrlSelected = NotificationCenter.default
         .publisher(for: .saveImage)

    var body: some View {
        VStack {
          // view code removed for brevity
        }
        .onReceive(saveImageUrlSelected) { publisher in
            if let saveUrl = publisher.object as? URL,
                let imageData = self.catImage?.tiffRepresentation {
                if let imageRep = NSBitmapImageRep(data: imageData) {
                    if let saveData = imageRep.representation(using: .jpeg,
                                                              properties: [:]) {
                        try? saveData.write(to: saveUrl)
                    }
                }
            }
        }
    }

And there we have it. Three types of dialogs demonstrated in a SwiftUI for Mac app:

Alerts: good for simply text-only dialogs
Sheets: good for more complex dialogs
Panels: AppKit dialogs that can be called from a SwiftUI View.

I think this time I really am finished. This article has already expanded out into a 3-part monster, so I think it is way past time that I stopped typing. I hope you have enjoyed this series. Please use any of the buttons below to contact me or use the Contact page on this site. I would love to hear from anyone who found this series useful or who had any suggestions or corrections to make.

The final project is available on GitHub if you would like to download it and take a look.

SwiftUI for Mac - Part 2

2019-12-15T07:28:10Z

Now it is time to explore some more of the features of a Mac app with SwiftUI.

Menus

I had already discovered that the menu bar is configured in the Main.storyboard file. As an experiment, I will add new menu items that allows the user to select between dark mode, light mode or the system mode.

Looking at the possibilities along the top that I could send the menu command to, the App Delegate looks like the best option, especially since these menus will change the entire app.

I opened AppDelegate.swift in the Assistant Editor and Control-dragged from each of the new menu items to create the 3 IBActions and added the code to set the mode.

    @IBAction func darkModeSelected(_ sender: Any) {
        NSApp.appearance = NSAppearance(named: .darkAqua)
    }

    @IBAction func lightModeSelected(_ sender: Any) {
        NSApp.appearance = NSAppearance(named: .aqua)
    }

    @IBAction func systemModeSelected(_ sender: Any) {
        NSApp.appearance = nil
    }

And since I realized that I would want to check or un-check these based on the current settings, I added IBOutlets for each of these menu items too. As a side note, I love how Xcode is now clever enough to decide whether to add an IBOutlet or an IBAction depending on where in the file you Control-drag to.

Using a Property Wrapper

Changing mode worked perfectly in the Xcode Preview and in the built app, but the app was not storing this or displaying the current selection with a check mark in the menu.

For storing the selection, I decided to try another new thing and use a UserDefaults property wrapper, based on this post by Antoine van der Lee.

I configured a UserDefault wrapped variable for the mode, set it whenever the menu items changed it and added a function to read it in and apply it on startup.

    @UserDefault("system_mode", defaultValue: "system")
    var systemMode: String

It would be neater to use an enum here instead of strings, but that would have required fiddling with rawValues to save the data, so for this first test, I stuck to strings.

The code to toggle the checkmarks in the menu items is standard stuff and nothing particularly SwiftUI related, so I won't detail it here, but it is in the GitHub project if you are interested.

Passing menu data to a View

This worked fine and the app worked equally as well in dark or light modes, but I wanted to test how to communicate data back from the menus to the SwiftUI views.

As a totally pointless but possibly amusing feature, I decided to add a menu item to flip the cat image and then work out how I could send that to the ContentView.

I added the new menu item to the Format menu and as a first attempt, I tried to Control-drag from there into the ContentView. It didn't take, so I guess I need to send the message to the AppDelegate as before and then pass it on to the ContentView. I feel like this might be a good place to use a Publisher although so far I have only used the built-in ObservableObject type publishers.

In this case, it would make more sense to have the DetailView respond to the menu, since it contains the image. But trying to add an @IBAction to a SwiftUI View struct gives this error: Only instance methods can be declared @IBAction so I am using the App Delegate instead. I feel like this is a problem I need to solve, or the AppDelegate is going to end up filled with @IBActions, but for now, let's keep going.

In AppDelegate.swift, I added the IBAction for the Flip Image menu item and had it issue a Notification, after setting up an extension on Notification.Name to de-stringify the name of the notification.

    @IBAction func flipImage(_ sender: Any) {
        NotificationCenter.default.post(name: .flipImage, object: nil)
    }

In DetailView.swift, I set up a Boolean @State property to store whether the image was flipped or not and added an onReceive handler to toggle it. Since this is updating the UI, I made sure that it happened on the main thread, but I am not sure whether this is necessary, or whether onReceive uses the main thread automatically.

UPDATE: Check out Subscribing on the Main Thread in my post of extras & changes to this series for an alternative way to make sure the updates happen on the correct thread.

    @State private var imageIsFlipped = false

    // ...

  .onReceive(flipImageMenuItemSelected) { _ in
    DispatchQueue.main.async {
        self.imageIsFlipped.toggle()
    }
  }

Once I had that Boolean property, I added two more modifiers to the image. Don't hate me for the force un-wrapping. I tried using if-let but it wouldn't compile so I check for catImage != nil before using this force-unwrap.

  Image(nsImage: catImage!)
      .resizable()
      .aspectRatio(contentMode: .fit)
      .rotation3DEffect(Angle(degrees: imageIsFlipped ? 180 : 0),
                        axis: (x: 0, y: 1, z: 0))
      .animation(.default)

Now the image can be flipped from the menu item or even by using the keyboard shortcut. And with a smooth animation (smoother in the app than in this gif).

Opening another window

For my next challenge, I want to open a second window that I can use to show samples of various UI elements. As I want to open it from a menu command, my first thought was to add a Window Controller to the Main storyboard and open it that way. I replaced the default View Controller with a Hosting Controller so that I could insert my SwiftUI View into it.

I had great trouble finding any documentation or examples of how to implement this, but after a lot of trial and error, here is what I got to work:

Drag a Hosting View Controller into the storyboard and connect it to the menu item with a segue.
Set the Presentation property for the window controller to Single so that multiple copies of the window are not created.
Create a new Swift file and subclass NSHostingController. Don't bother using a Cocoa class file - the template doesn't work. Use the code below, replacing SamplesView with the name of the SwiftUI view you want to display.

import SwiftUI

class SamplesHostingController: NSHostingController<PrefsView> {
      @objc required dynamic init?(coder: NSCoder) {
          super.init(coder: coder, rootView: SamplesView())
      }
}

Back in the storyboard, set the class of the HostingController to this sub-class: SamplesHostingController in my case.
Set a minimum size for the new Window Controller, otherwise it shrinks to a very small stripe on the screen.
Add the .frame(maxWidth: .infinity, maxHeight: .infinity) modifier to the root view in the view you are displaying - my SamplesView.

With all these in place, I was able to open and close a Samples window that was displaying my SwiftUI content.

User Interface Elements

Not all the expected user interface elements are available in SwiftUI and some of the ones that are implemented are using different names. Again this is a point at which iOS development has got all the attention, so there are conversion tables out there listing UIKit elements and their SwiftUI equivalents, but I was not able to find a similar listing for AppKit. If you find one, please let me know.

Anyway, I experimented and got most of what I wanted as you can see below. The sample app on GitHub shows the SwiftUI code for these samples, but the main advice I would give is firstly to use the Object Browser to look for what is available and then to check out the styles that can be applied to the element you have chosen.

Mostly, I managed to achieve what I wanted but there were a few exceptions.

Buttons were a bit odd as there are multiple button styles listed, but I found that they either all looked the same or they disappeared completely. I was not able to style a button with an image and text which is now easy to do in iOS. And I was not able to set a button as the default button and I could not work out how to set a keyboard equivalent for a button. (Setting the keyboard equivalent to Return or Enter might set it to the default style automatically.)

Of the other UI elements that I wanted to use, a color picker was the main one missing. So I decided to embed an NSColorWell from AppKit into my SwiftUI view.

The process for embedding a UIKit view is quite well documented elsewhere and the AppKit equivalent was not significantly different. Replace every "UI" with "NS" and you are nearly there.

First I made a struct that conformed to NSViewRepresentable and had the required two functions: makeNSView(context:) and updateNSView(_:context:). I supplied an @Binding variable to hold the selected color as an NSColor since that is what the NSColorWell uses.

struct EmbeddedColorWell: NSViewRepresentable {
    @Binding var selectedColor: NSColor

    func makeNSView(context: Context) -> NSColorWell {
        NSColorWell(frame: .zero)
    }

    func updateNSView(_ nsView: NSColorWell, context: Context) {
        nsView.color = selectedColor
    }
}

Back in my SwiftUI view, I was then able to use EmbeddedColorWell just like any other SwiftUI view, passing it a binding to an @State variable to set and get the selected color.

  EmbeddedColorWell(selectedColor: $selectedColor)

UPDATE: Be sure to read Passing data back from AppKit in my post of extras & changes to this series. This is an important fix that is needed to make this embedded control pass data back properly.

The other stumbling block that I encountered was that I had no way to close the window programmatically, in response to a button click or some other interaction. Maybe this was not the best way to open a fully SwifUI window, but it was still an interesting experiment.

One thing I learned while working on this project was that SwiftUI can be a bit too clever about working out what needs to be redrawn in the previews. If you edit something in an separate file to the View, you may need to force a re-build to get the updates to show.

Communicating Between Windows

The last feature that I need to explore is transferring data between two windows. I tested using a .sheet modifier to open a dialog and that worked exactly as it would in an iOS app - I was able to pass an @Binding variable to the sheet window and any changes made to that in the sheet window flowed back to the calling view.

But I want to set up a Preferences window which will be opened from the menu bar and not directly from the ContentView or any of its sub-views.

I started out by using the same technique as before with a Hosting View Controller. And here is where I came mightily unstuck as I could not make a data connection. I had hoped an EnvironmentObject would work, but I could not get an EnvironmentObject through to the HostingController as it was not in the same view hierarchy.

So instead of trying to use the storyboard, I decide to see if I could use something similar to the initial window creation and call that new window from my ContentView so that it was part of the view and therefore the data hierarchy.

As usual, there was a lot of trial and error involved here, but I came up with a workable solution.

struct PrefsView: View {
    var body: some View {
        Text("Hello, Prefs!")
            .frame(maxWidth: .infinity, maxHeight: .infinity)
    }

    var window: NSWindow!
    init() {
        window = NSWindow.createStandardWindow(withTitle: "Preferences",
                                               width: 300,
                                               height: 100)
        window.contentView = NSHostingView(rootView: self)
        window.makeKeyAndOrderFront(nil)
    }
}

For convenience and reusability, I made an extension on NSWindow that created a window with the basic properties configured, much like they are in AppDelegate. I temporarily added a Button to ContentView like this:

  Button("Prefs") {
      let _ = PrefsView()
  }

This opened the window perfectly, but it had a problem: repeatedly clicking the button kept opening a new window instead of bringing the existing one to the front.

After a lot more trial and error, this is what I ended up with for my PrefsView struct:

struct PrefsView: View {
    @State var prefsWindowDelegate = PrefsWindowDelegate()

    var body: some View {
        Text("Hello, Prefs!")
          .frame(maxWidth: .infinity, maxHeight: .infinity)
    }

    var window: NSWindow!
    init() {
        window = NSWindow.createStandardWindow(withTitle: "Preferences",
                                               width: 300,
                                               height: 100)
        window.contentView = NSHostingView(rootView: self)
        window.delegate = prefsWindowDelegate
        prefsWindowDelegate.windowIsOpen = true
        window.makeKeyAndOrderFront(nil)
    }

    class PrefsWindowDelegate: NSObject, NSWindowDelegate {
        var windowIsOpen = false

        func windowWillClose(_ notification: Notification) {
            windowIsOpen = false
        }
    }
}

So my PrefsView opens its own window and sets a window delegate that records when the window is closed.

I removed my temporary button and back in AppDelegate.swift, I added an IBAction called by the Preferences menu item:

    var prefsView: PrefsView?

    @IBAction func openPrefsWindow(_ sender: Any) {
        if let prefsView = prefsView, prefsView.prefsWindowDelegate.windowIsOpen {
            prefsView.window.makeKeyAndOrderFront(self)
        } else {
            prefsView = PrefsView()
        }
    }

And this gave me what I was after - a view that opened from a menu item but that knew itself whether it still had a window so could decide whether to open a new one or bring the existing one to the front. This looks a bit convoluted, but it doesn't appear to cause any memory leaks and the responsibility for the window rests on the view that uses it, which feels right to me.

After I had this working, getting the data passing around was quite simple. I created a Prefs class to store the preference data. I wanted this data stored in UserDefaults, but since I also wanted to use an ObservableObject with the @Published property wrapper, I was not able to use the @UserDefaults property wrapper that I had used for the app mode.

So instead I used @Published with a didSet that saved the changed data to UserDefaults. Thanks to @azamsharp for this technique.

class Prefs: ObservableObject {
    @Published
    var showCopyright: Bool = UserDefaults.standard.bool(forKey: "showCopyright") {
        didSet {
            UserDefaults.standard.set(self.showCopyright, forKey: "showCopyright")
        }
    }
}

This preference will dictate whether a copyright notice is shown on every cat image, so it needs to be available to DetailView and to PrefsView. Since I did not want to pass it through every view on the way to DetailView, I decided to use an EnvironmentObject. But I was not able to work out how to set the environmentObject for the PrefsView as I created it, so I ended up sending an @ObservedObject to PrefsView but using an @EnvironmentObject for DetailView. (Actually for CatImageView as I had extracted the image from DetailView as a subview.)

In AppDelegate.swift:

    let prefs = Prefs()

    // and in the openPrefsWindow IBAction:
    prefsView = PrefsView(prefs: prefs)

In PrefsView.swift:

    @ObservedObject var prefs: Prefs

In CatImageView (a subview of DetailView):

struct CatImageView: View {
    @EnvironmentObject var prefs: Prefs

    let catImage: NSImage
    let imageIsFlipped: Bool

    var body: some View {
        Image(nsImage: catImage)
          // modifiers as before

         .overlay(
             Text(prefs.showCopyright ? "Copyright © https://http.cat" : "")
                 .padding(6)
                 .font(.caption)
                 .foregroundColor(.white)
                 .shadow(radius: 5)
             ,alignment: .bottomTrailing)
    }
}

And that is that! I have shown how it is possible to create an entire Mac app using SwiftUI.

I am sure that there are numerous ways that this could be improved, so if you have any ideas or suggestions, please use one of the buttons below to contact me.

If you want to check out the project at this stage, here is a link to the relevant GitHub commit. Or if you would prefer, here is a link to the final version of the project.

Moving on to an unplanned part 3 of this series, I am going to experiment with various forms of dialog.

SwiftUI for Mac - Part 1

2019-12-15T07:28:00Z

So far, nearly all the articles I have seen about SwiftUI show it being used for iOS, more particularly for iPhone. But SwiftUI works on all Apple's platforms, and as I am primarily a Mac developer, I decided to try out a Mac app and see what happened.

Setup

I opened up Xcode and created a new project selecting the macOS App template. The project opened at the usual ContentView.swift but there were a few differences in the project structure as well as one in the ContentView struct.

The first thing to notice is that the default "Hello, World!" Text view has a frame set:

  .frame(maxWidth: .infinity, maxHeight: .infinity)

If I removed this frame modifier, the preview display in the Canvas changed so that the view was only the size of the text instead of being a standard window size. I guess an iOS device always knows what size it is, but a Mac window can be any size, so you have to be more explicit to stop SwiftUI shrinking the container view to the minimum size possible.

The next thing is to look at the files that are included in the project. There is no SceneDelegate.swift as you would see in an iOS project. And to my surprise, there was still a Main.storyboard file! And going to the General settings for the app target, I could see that this storyboard was selected as the Main Interface.

Opening it up reveals that this is where the application menu is configured. I had wondered where the menus were configured in Mac SwiftUI apps.

The AppDelegate was the next thing I looked at and here I found some of the code that I would have expected to find in a SceneDelegate. The applicationDidFinishLaunching(_:) method creates an instance of ContentView, creates an NSWindow and uses an NSHostingView to display the ContentView inside the window. At this stage, running the app gives me what I would expect: a fully-fledged Mac app with a window and a menu, both with all the functions you would expect in any standard Mac app.

The Canvas

I was not expecting the Canvas to be much use when it came to previewing a Mac app. It works so well with an iPhone app because the iPhone is tall and thin and fits neatly into one side of the code window. But a Mac view is likely to be much bigger, so it would have to be scaled down a lot to avoid talking up too much precious space in my Xcode window.

But it works as expected, and even scaled down, you get a good idea of the layout while still getting the live reloading that is part of what makes developing in SwiftUI so much fun.

But here is where I got my first real surprise, with a feature that I had not seen yet in any SwiftUI tutorial or article. Click the Live Preview button and see what happens...

Of course I clicked "Bring Forward" and there was my app running in a window called "Xcode Preview". There was an app in my Dock and when I chose "Show in Finder", I found that the app is buried deep in DerivedData. Positioning my windows so I could type in Xcode while watching this preview window, I saw that it instantly updated my view as I typed, just like an iPhone in the Canvas.

If I changed the structure of the view, the app closed and re-opened immediately with the new content. This is amazing and shows that the Xcode & SwiftUI teams really thought about how to use these new features in Mac apps as well as iOS.

In Xcode 11.3, I found that I was having trouble with the previews. They would not display and above the Canvas, I got the super helpful message "Cannot preview in this file --- SwiftUI-Mac.app may have crashed.". It turned out that this was a signing issue. If you go to the app target and look in the Signing and Capabilities section, check that Signing Certificate is not set to "Sign to Run Locally". If it is, switch to "Development" and the previews will start working again.

Laying out the View

Now that I have the project and I know how to preview it, it's time to work out what to display in the app. The next real app I want to work on will use a master-detail layout, so that is what I decided to try here.

Before worrying about the data, I decided to try populating the master view with a static list and using that to navigate to a detail view that was simply a Text view.

struct ContentView: View {
    var body: some View {
        NavigationView {
             List {
                 ForEach(1 ... 10, id: \.self) { index in
                     NavigationLink(destination: Text("\(index)")) {
                         Text("Link \(index)")
                     }
                 }
             }
        }
    }
}

This worked, except that the left column was only about 20 pixels wide. But I was able to use the mouse to drag it wider and there were my List entries. Clicking on one did indeed show the detail I wanted, but it shrunk the window to one line high!

The first thing I did was to apply a listStyle modifier to make it show the semi-transparent Mac sidebar. This fixed the width of the sidebar. But the whole window still shrunk when I selected an item.

  .listStyle(SidebarListStyle())

I tried applying the frame modifier to the NavigationView and that made the window stay the same size, but the content still shrunk into a tiny section in the middle. It looks like I need to apply that frame modifier to the detail view as well.

  .frame(maxWidth: .infinity, maxHeight: .infinity)

And as you can see from this gif, I then had a full functional master-detail view with a collapsible and expandable semi-transparent sidebar.

Adding Data

After some scouting around for a free API that I could hook into, I came across HTTP Cats which is a site that serves up a cat image to match almost every HTTP status code.

This sounded ideal: I can list the codes in the master view on the left and display the image in the detail view on the right.

First I created a JSON file to list all the HTTP status codes so that I could put them into a List view. This was a very simple array with each entry having a code and a title:

[
  {
    "code": "100",
    "title": "Continue"
  },
  {
    "code": "101",
    "title": "Switching Protocols"
  },
  ...
]

I created an HttpStatus struct with these 2 properties and I borrowed Paul Hudson's excellent Helper Bundle extension to decode the JSON file. For a first attempt, I used the numeric codes to build the list and showed the title of the selected one in the detail view. But one of the best things about SwiftUI is that it makes it so easy to configure table rows, so it is time to create a new View to do this.

After some experimentation, I had a TableRowView that I liked the look of, but the default sidebar width was too narrow and truncated the status code titles, so I added a frame modifier to the List to set a minimum and maximum width for the sidebar.

Outline List

At this point I decided that it would be more useful to have a outline list with the status codes grouped by their category.

So I re-did the JSON file to show this, added an HttpSection struct and a SectionHeaderView and modified the data loading method and @State variable.

[
  {
    "headerCode": "1xx",
    "headerText": "Informational",
    "statuses": [
      {
        "code": "100",
        "title": "Continue"
      },
      {
        "code": "101",
        "title": "Switching Protocols"
      }
    ]
  },
  {
    "headerCode": "2xx",
    "headerText": "Success",
    "statuses": [
      {
        "code": "200",
        "title": "OK"
      },

This worked really well and I was thrilled to find that the sections automatically had Show/Hide toggles!

Detail View

Up until now, I had been using a standard Text view as the destination for my navigation. This is a really useful technique as you can build the interface gradually but have it work from the beginning. But now it was time to create a new view for the details.

I set up the view and added a method that would download the correct cat image when the view appeared but there was no image. After some digging, I realised that sand-boxed Mac apps do not allow network access by default. I went to the Signing & Capabilities section of the target settings and turned on "Outgoing Connections (Client)". And then I had my cat pictures.

It really should have a loading image to display while the cat image is being downloaded, but to my disappointment, I found that the SF Symbols are not available to a Mac app! But I added a Text view to say "Loading...".

Now that I have a functioning Mac app with a Master-Detail view, the next thing is to explore some more of the challenges that will need to be solved before I can write a Mac app completely using SwiftUI.

If you want to check out the project at this stage, here is a link to the relevant GitHub commit. Or if you would prefer, here is a link to the final version of the project.

In part 2 of this series, I will look into:

how to interact with the menus
how to open a secondary window
more user interface controls
how to pass data around between windows

SwiftUI First Thoughts

2019-08-18T05:00:05Z

At WWDC 2019, Apple surprised us all by announcing a completely new declarative UI framework called SwiftUI. Quoting snippets from the Apple announcements, "SwiftUI is an innovative, exceptionally simple way to build user interfaces across all Apple platforms with the power of Swift" and "SwiftUI uses a declarative syntax so you can simply state what your user interface should do." But what does this mean and should we all adopt it now?

Swift

Before discussing whether to adopt SwiftUI, we need to consider Swift itself, since you cannot use SwiftUI without Swift.

The announcement of Swift at WWDC 2014 was a complete bombshell. Here in Australia, I watch the keynote every year while half asleep since it starts at 3 am. That announcement had me wide awake and bouncing out of my seat with excitement. I was an early adopter and have never regretted that decision.

Many well-respected developers have decided to ignore Swift and they have their various reasons, so let's go through the ones I have heard:

1. I'm very comfortable and productive in Objective-C

This is not a bad reason and for many people, their employer may insist on the language anyway, but this argument doesn't work for me. Firstly, I think that there is never going to be the One Perfect Language (with apologies to Chris Lattner) so I am always open to new ideas. And personally, I love learning new languages even if I am never going to use them in production. I feel that this makes me a better programmer overall. And there are vast benefits to Swift - it is a much safer language to write it, it is easier to read and more concise to write, it is just a much more modern language.

2. Swift is too new and changes too much between versions

Swift was new. It is now 5 years old and we are into version 5.2. Undeniably, there have been a lot of changes since 1.0 and many of them have been breaking changes. Swift 3 was especially bad in this respect. But this came with advantages too. As early adopters, we were able to influence the direction of the language. And Xcode was always pretty good about providing a converter to the next version. But either way, since Swift 4, there are supposed to be no more breaking changes, so this is an argument whose time has passed.

3. No ABI stability

ABI stability was a crutch that many people clung to as an excuse to avoid Swift. But unless you were building frameworks for distribution, I don't see that it was ever a complete deal-breaker. The Swift ABI Stability Manifesto has a good review of what ABI stability is and what it will allow. As app developers, the main advantage is that the Swift libraries will no longer need to be bundled with each app. This will decrease app sizes dramatically. But either way, we now have ABI stability, so again, this argument is finished.

4. Apple may not be serious about Swift and it may not last

I think there was a certain amount of wishful thinking here. The main data behind this theory seemed to be that very few of the Apple apps included any Swift. And in the beginning this was true. I expect Apple's apps have a rather longer development time-frame than apps produced by independents. However over the last few years, more and more of Apple's own apps have started to use Swift, either completely or partially. And any doubt about Apple's commitment to Swift should have been permanently laid to rest by the announcement of SwiftUI.

5. It's too complicated

OK, this one has some validity, but then again, if Swift is to rule the world, it needs to be able to do a lot of things. I love Swift, I love writing in it and I am very productive when using it. But then I see a chunk of code sprinkled with generics and unsafe pointers and I can't make head nor tail of it. However, I think that if you are writing any standard, non-arcade-game app, you can write very good Swift using just the basics.

Why did Apple make SwiftUI?

Having demolished the arguments against using Swift, it's time to move on to SwiftUI. Let's start with the reasons why something like this had to happen.

Apple now has 5 or possibly 6 user platforms: macOS, iOS, iPadOS, tvOS, watchOS and maybe CarPlay. (I've never considered any CarPlay development so I have no idea how it works.) The screen sizes range from 38mm for the smallest watch to over 75" to large screen TVs (apologies for mixing my units there, but it seems that TVs have not gone metric yet). As far as user interface frameworks go, we have had AppKit, UIKit and WatchKit. AppKit is the venerable old member of this team, descended from NextStep (which is why every element name has the NS prefix) and is used to make macOS apps. UIKit was built from scratch for the iPhone and so is a lot newer and neater than AppKit, but at the same time it is more limited. It has never had to deal with the vast variability and complexity of a Mac app's interface. WatchKit is an even more slimmed down framework with a relatively small number of interface elements.

Now imagine that you are trying to write a multi-platform app. You have to learn at least 3 different ways of doing everything. And there are differences that always catch me out. For example, in AppKit, to set the text in a text field, you set the field's stringValue but in iOS, you can set the field's text property. And in WatchKit, you call the setText() method.

Want to change the background color of a view? UIView - no problem, set backgroundColor. NSView - nope - do something weird with layers. I forget what, I have to look it up every time.

These inconsistencies are annoying, time-consuming and a huge barrier to cross-platform development. It really annoys me when I read articles or tweets that assume Swift programming = iOS programming when it is so much more. But before SwiftUI, it was not easy to jump between the platforms.

Catalyst, previously code-named Marzipan, was supposed to be the answer. And it is a partial answer. It allows iPad apps to be ported to the Mac and that's great for iPad developers who want to expand their reach. But it isn't the answer for everybody.

Interface Builder

Before I go further into what I think is so great about SwiftUI, I would like to take a moment to discuss Interface Builder. Xcode is a brilliant tool that gets better with every release, but its weak point has always been Interface Builder. I am old enough to remember when Interface Builder was a separate app (not that we called them "apps" in those days) and although it has been folded into Xcode for many years now, the connection between interface and code has always been clunky and un-intuitive. Control-dragging from interface to code and then remembering to switch between Action and Outlet so that you don't end up naming your button "doneButtonWasTapped". And if you get the modifier key wrong, who knows what weird stuff will happen.

And then came Auto Layout... It was vastly more flexible than the old school springs & struts and with the ever increasing number of iPhone & iPad models something had to be done, but if you have never ended up swearing at Auto Layout and reverting to a previous commit or mashing Undo repeatedly, then you can't have used Auto Layout very much!

WatchKit had an entirely different approach to layout and it was easy, intuitive and very refreshing. You drag in objects, they go one under another. You can group them horizontally or vertically, you can make them into table cells. WatchKit has a much more limited set of interface elements and a much more limited set of device sizes to deal with, but I think we can clearly see the origins of SwiftUI in the way it worked. Even if you still had to use Interface Builder to do it.

Interface Builder's quirks lead to a category of programmers who felt the need to write all their interface in code. To my way of thinking, this is a huge waste of time and you still had to wrestle with Auto Layout, but without the visual clues! But if it makes them happy...

What Is SwiftUI?

A "declarative UI framework" - what does that mean? Basically, declarative programming is a way of specifying what a program should do, rather than specifying how to do it. A common example is making a sandwich. If you want a sandwich, you say to the sandwich maker, "Please can I have a ham, cheese and tomato sandwich". You don't say "Get two pieces of bread, butter both of them, cut 3 slices of ham and 2 slices of cheese...". They know how to make a sandwich so you only have to ask for what you want.

Back in the Apple UI world, what if you want a button? Is it for an iPhone app? Then you need an UIButton with a certain type. Set its title, size, location, layout constraints. What are the default sizes for an iPhone button? What is the default font? What color should the text be? Now make a button for a tvOS app? That has to be huge! And what other settings does it have? But the thing is, iOS, macOS, tvOS etc. already KNOW what their buttons should look like. So why not just tell the system "I want a button"? Let the system work out the details and you can get on with the cool app ideas.

I'm not going to turn this post into a SwiftUI tutorial, but I would like to thank and recommend the people that have really helped me get to grips with it, especially Paul Hudson of Hacking with Swift with his Learn SwiftUI tutorials, Mohammad Azam's great YouTube series, and Meng To's SwiftUI course at Design+Code.

The other great benefit of SwiftUI is that when used with the Combine framework, it gives you a reactive interface. There have been various third-party libraries for doing this: RxSwift, ReactiveSwift, ReactiveCocoa, Bond etc, but with Combine, Apple is baking this into the ecosystem, which makes it a lot easier to set up and means that it will stay up-to-date with the operating systems. A reactive interface is one where you can bind a UI element to a piece of data and then when the data changes, the user interface updates automatically. You can even bind both ways so that the user interface updates the data without you having to do a thing. Imagine how much boiler-plate code that can eliminate?

The Good, The Bad and The Ugly

1. The Good

You get a lot of interface for very little code. Making tables is a joy without the masses of boilerplate code needed to set up data sources and delegates. The instant preview in the canvas makes iteration much easier. Being able to create something like a Picker and having SwiftUI render it in one of multiple different styles depending on the platform is magical.

2. The Bad

It's early days yet and SwiftUI has some quirks and bugs. Sometimes the canvas just stops responding, switching into live mode in the canvas can take a while and of course it is still in beta, so there will be breaking changes to come.

3. The Ugly

It is very easy to build up the Pyramid of Doom where you have multiple levels of nesting leading to the end of your code being a seemingly endless stream of closing curly braces. In SwiftUI, one tends to build from the inside out: make a Text view, embed it in a VStack so you can add another one, embed that stack in an HStack so you can add an Image and so on... But there is an answer: Command-click on one of your outer layers and select "Extract Subview".

Coding the Layout

Earlier in the article, I spoke about programmers ignoring Interface Builder and laying out the interface in code. I don't think this is a good approach, so how is SwiftUI different? Firstly, you get immediate feedback of the UI you are coding, so you are not losing that visual benefit of using Interface Builder. Secondly, SwiftUI does much of the layout for you, so you are not hand-coding auto layouts or every last detail of every UI element. So as far as SwiftUI is concerned, I am a convert to programmatic layouts. But if not using SwiftUI, I would still stick to Interface Builder.

Another point to consider here is that developers have long argued that if Apple wants the iPad to be seen as a "Pro" device, there should be a version of Xcode for iPad. One of the problems with this was Interface Builder - it is difficult to see how it could be made to work with a touch interface. But with SwiftUI and iPadOS, is it possible that Apple can make an iPad version of Xcode?

Should you use SwiftUI?

I hope that from my previous paragraphs, you have come away with a good feeling for why Apple made SwiftUI and why it is good for us as developers. Personally, I find it a joy to use even in these early beta stages, but some of the arguments against using Swift, can now be applied again to SwiftUI.

That SwiftUI is very new cannot be debated. It is extremely new and even in the handful of betas released since WWDC, we have seen some breaking changes. It feels quite buggy still but as I am running it in a beta operating system with a beta version of Xcode, it would be unfair to blame all the instability on SwiftUI.

SwiftUI is not yet a complete replacement for UIKit/AppKit/WatchKit etc. There are SwiftUI equivalents for many of the interface elements and I recommend the Gosh Darn SwiftUI site which maintains a list of UIKit equivalents as well as really useful snippets of SwiftUI code. But even when SwiftUI does not have the UI element you want, there are two easy options: use UIKit/AppKit or build your own. Apple has made sure that there is no problem about mixing and matching UIKIt/AppKit code with SwiftUI. And maybe the SwiftUI tools would allow you to build your own version of the missing element. I needed a progress bar and I built one myself with not much code and ended up with what I think is a better look than the standard one.

Click the image for a link to the GitHub repository.

For years, Apple has been telling us to use standard interface elements in our apps and if we did this, when system updates changed the look and feel, we mostly got that change for free. Now they are giving us even more for free by saying effectively, tell us what UI element you want and we will do all the work of configuring it for the platform and for the user's settings.

But with this, Apple has given us a lot of modifiers we can apply to elements as well as a great animation suite, so I expect to see a lot of more interesting design choices being made in apps, while they are still adhering to all the standard human interface guidelines for the various platforms.

Apple does not promote SwiftUI as "write once, run everywhere" but as "learn once, apply everywhere" and that is an important distinction. It seems at first glance that we can write once but only on a basic level. You are still going to need to design the appropriate UI for a platform, but it will be able to re-use components from the other versions of the same app.

Do I intend to use SwiftUI in my next app - YES. If I was writing code for NASA, I wouldn't, but my apps are rarely mission-critical, so I can indulge myself and learn as I go. It will be frustrating when there are breaking changes, but at the same time, my bug reports are going to make it better.

One caveat is that SwiftUI apps will require the latest operating systems, iOS 13 and macOS 10.15 so if your app has to support older versions of the systems, you will have to wait until next year. But there is nothing to stop you building some test components and starting the learning process.

Learning Swift - Tuples

2019-02-03T09:48:51Z

I sometimes like to focus on aspects of the Swift language that get less publicity, but that I think are really useful without adding a lot of complexity. This time I am looking at tuples.

There are many different ways of collecting data together in Swift, but for small amounts of transitory data, I find tuples to be an extremely convenient data structure.

What is a Tuple?

A tuple is basically an array with a pre-determined length and unlike normal Swift arrays, it can hold a mix of data types.

Here are some examples:

let pair = ("Jessie", "Woody")
let coords = (0, 4, -6)
let pet = (type: "cat", trained: false, age: 5)

To define a tuple, you enclose the data elements in parentheses - normal brackets, not curly or square. Optionally, the elements can have a label attached as shown in the pet example.

Tuples can have any number of components, but if they get too long, a struct might be a better option. SwiftLint will complain if you use tuples with more than 3 elements and usually I go along with that.

There are various ways to access the parts of a tuple. The first way is using index numbers which works but isn't very intuitive and could be hard to decipher when you come back to a project after some time.

print(pair.0)
print(pair.1)

The next way is if the tuple has used labels for the elements as in the pet example above:

print(pet.type)
print(pet.trained)
print(pet.age)

But the way I prefer to use them is by deconstructing the parts into separate variables in a single statement:

let (x, y, z) = coords
print(x, y, z)

The elements of a tuple can be of different types but once a tuple has been defined, that type of each element is fixed, so you still get all the benefits of Swift's type safety.

Option-clicking on the variable name shows the inferred type of the tuple:

Trying to re-assign the tuple or any elements of the tuple will only work if the new assignments match the initial types for each element:

Where could you use a tuple and why?

Let's imagine you have a function that checks a database or web service and comes back with the title of a movie and its rating.

func getMovieInfo() {
  var movieTitle: String
  var rating: Int

  // get the data from somewhere
  // now return both movieTitle and rating
}

Having got the data, this function needs to return two pieces of data: movieTitle and rating - one String and one Int. How could this be done?

Array: since there are 2 different data types, the array would have to be of type [Any] or the Int could be converted to a String before returning. Neither of these are good options. Using Any removes the protection of Swift's type safety and converting the Int to and from a String may fail, so then you have to deal with optionals.
Dictionary: the same arguments hold true. The dictionary would have to be of type [String: Any] or the rating would have to be converted to a String.
Struct or Class: either of these would be fine but unless this is a data structure that is going to be re-used, it seems like overkill.
Tuple: this would get my vote, so let's see how that would work.

func getMovieInfo() -> (String, Int) {
  var movieTitle: String
  var rating: Int

  // get the data from somewhere

  return (movieTitle, rating)
}

Two main things to notice here:

The return type of the function lists the data types of both the elements being returned, enclosed in parentheses.
The returning tuple is created by wrapping the elements inside parentheses, just like in the examples above.

And then in the calling function, you can access the parts of the returned data like this:

let (returnedMovieTitle, returnedRating) = getMovieInfo()

The tuple is being returned and immediately deconstructed to give 2 new variables so accessing the parts of the tuple is easy and type-safe.

A function returning a tuple can also be configured to use named elements by specifying the names in the return type declaration.

func getMovieInfo() -> (name: String, score: Int) {
    var movieTitle: String
    var rating: Int

    // get the data from somewhere

    return (movieTitle, rating)
}

let result = getMovieInfo()
let returnedMovieTitle = result.name
let returnedRating = result.score

My feeling is that once a tuple is complex enough to need names, you should really consider using a class or a struct, but for returning 2 or 3 chunks of data from a function, this is a very useful technique, espeicialy if the data types are different.

Looping through tuples

If you have an array of tuples, looping through the tuples is made very convenient if you use the deconstruction method of accessing the parts.

As an example, suppose you are dealing with some 3D coordinate system and you want to perform an operation on each location.

let coords_array = [
    (0, 0, 0),
    (0, 1, -3),
    (1, 4, 2),
    (-2, 0, 5),
    (5, 2, 4)
]

for (x, y, z) in coords_array {
    let distanceFromOrigin = abs(x) + abs(y) + abs(z)
    print(distanceForOrigin)
}

You can deconstruct the tuple each time through the loop, assigning temporary variables so you can act on them.

Wrapping Up

So those are the basics of tuples: how to create them, how to use them and where they might be useful. My main use is as a light-weight alternative to a struct for returning multi-part data from a function. But hopefully after reading this article, they have become another tool in your Swift tool belt that you can consider using in certain circumstances.

That leaves only one important question: how do you pronounce 'tuple'?

I have heard two variations: 'toople' using a long U as in universe or 'tupple' using a short U as in cup. There does not appear to be any strict geographical differentiation, so take your pick. I prefer 'toople' myself, but if somebody says 'tupple', I know what they mean.

The End of Pic-a-POD

2018-10-05T23:38:20Z

I think I wrote the first version of Pic-a-POD in 2003 and have been updating and maintaining it ever since, but the time has come to shut it down.

I haven't been able to find a picture of the original version, but here is one from 2005:

And here it is today:

It was written originally as a convenient way to download the daily picture-of-the-day from National Geographic and use it to set the Mac's Desktop Picture automatically. From there is just grew with more sites added (9 at the moment although I think there have been up to 12 at certain times).

The main issue was keeping up with the site changes of the various sources. Early versions had each copy of the app interrogate the sites directly which meant that any change to the site broke the app until an update could be released. And without the App Store making updates easy to distribute, this was a problem. Later I switched to having PHP scripts on my server do the data retrieval and store the results in a database. The app then just had to request the data from my server. That way if there was a change, I could react quickly and a fix to the server-side scripts allowed all users to get the new data.

As my first Objective-C app and my first app on the Mac App Store, Pic-a-POD has always held a place in my affections, and until last week, it was the one app that was always running on my Mac. So what changed? macOS Mojave's dynamic desktops! I turned off Pic-a-POD, and set the Desktop picture to change dynamically through the day and I loved it.

On the server, I have kept Pic-a-POD updated regularly, adding and removing sites, fixing the scripts to accommodate changes and so on. But the desktop app has languished and has needed an update for many years now. It's networking is primitive and I know so much more about programming for the Mac now that looking at the code is positiviely embarrassing! But it has never been a big seller so a re-write is definitely not economically viable, it would only be for my satisfaction. And if even I am not using it any more, what is the point?

So I have made the sad decision to shut it down. But what does this mean for users of Pic-a-POD right now?

Firstly, it is not going away immediately. I will remove it from the App Store, but existing copies are still going to work. If any of the source sites change their data structure, I will not be monitoring this and I will not update the server-side scripts - just turn off that source and carry on with whatever still works. And finally, when the picapod.com domain name expires in 2021, I will not renew it and the app will cease to operate.

What can you use instead? The default dynamic desktops in Mojave are great although there are only two of them, but I have bought myself an app called 24 Hour Wallpaper which includes a great range of dynamic desktop pictures.

So thank you to everyone who has used Pic-a-POD over the years and especially those of you who took the time and trouble to contact me. It has been a fun journey, but there are other apps in my future now.

Moving to the Dark Side - Part 2

2018-10-05T22:29:35Z

Now that most of my Mac apps have been updated to support macOS Mojave's dark mode, it was time to turn my attention to this web site.

I build this site using Hugo and up until recently I used a theme called Even which I had been able to modify to suit my requirements. The story of how I switched to Hugo, what I wanted in a theme and how I went about, is in a post from last year.

But Evan is a theme with a white background and dark text, which looked great in light mode, but rather glaring in dark mode. So it was time to head for the Hugo Themes page to look for an alternative.

But which way to go? In my opinion, dark themes look better in Mojave's light mode than light themes look in dark mode, so I decided to go with a dark theme. But to my delight, I found a theme that allowed users to switch between light and dark modes: Hello Friend by panr. Click the light bulb icon in the top right and the web site instantly toggles between modes.

With the spread of dark mode, I would expect more web sites and themes to implement this sort of switching in the future. Thanks to panr for being an early adopter.

As I said in my previous post, I have already updated several of my macOS apps to support dark mode. But after reading some comments on Twitter, I have updated Icon Builder and Dice Pass to allow the user to decide which mode to use. Make your choice in the Window menu as to whether these apps use whatever mode is set for the system, or select your preferred mode.

Moving to the Dark Side

2018-09-26T06:49:43Z

With the release of macOS Mojave on 24th September 2018, I have started updating my Mac apps, mainly to enable support for dark mode if appropriate.

And now I have updated this site too. Click the light bulb icon at the top right of the page to toggle between light and dark modes for this site.

And with my apps, so far (1 st October 2018), I have updated Icon Builder, World Time in Words, Dice Pass and A Knight's Move.

For A Knight's Move, I wanted to make sure the wood-look background didn't change, so I actually disabled dark mode. For any developers looking for the way to do that, I added the following chunk to the applicationDidFinishLaunching(_:) method:

    if #available(OSX 10.14, *) {
        NSApp.appearance = NSAppearance(named: .aqua)
    }

Similar code could presumably be used to change the appearance of a running app. I may add the ability to switch to my apps later.

Swift Strings Helper

2018-06-21T04:45:59Z

Hands up everyone who can remember how to work with Swift strings, especially when it comes to substrings and ranges? ....

Nobody?

Me neither. So I decided that I would work it out once and create myself a library to make it easy for myself in the future. And then I thought that other people might like it too. So I have created my first open sourced project.

Strings in Swift

Swift's string handling is amazing. It is truly Unicode-compliant, so a Swift String doesn't care whether your string is made up of basic alphanumerics, accented characters, or emojis that might be composed of several different emojis joined together.

But this power comes at a price, and every version of Swift has changed the way we interact with strings, seemingly making it more and more confusing for the poor programmers trying to stay current. I have got to the stage where each year I read up on the new String features and then promptly forget them. For every use, I have to go back and search how to do what should be simple.

The Problems

To my mind, there are two main problems: indexes and substrings.

In most languages, you can get the n-th character of a string, but not in Swift. In Swift, you have to ask the string for its startIndex (or endIndex), then use an offset to adjust that index by a certain number to give you a String.Index. Do much the same to get a second index and then you can grab the string between those two indices.

To get a sub-string from the 7th up to the 11th character of a string, this is what you have to do:

let str = "Hello, playground"

let subStart = str.index(str.startIndex, offsetBy: 7)
let subEnd = str.index(str.startIndex, offsetBy: 11)

let subStr = str[subStart ..< subEnd]       // "play"

Splitting the lines up like that at least helps to show what is happening, but then you see abominations like this:

let sub = str[str.index(str.startIndex, offsetBy: 7)..<str.index(str.startIndex, offsetBy: 11)]

And how anyone is supposed to read that, I really do not know.

And now here is the kicker: the results (subStr and sub in the examples above) are not of type String! They are of type Substring so when you go to use them, they don't work as expected.

I guess there are cases for using Substring but I always just end up casting to String to solve this, but only after the compiler has choked on what I thought was a String all along.

The Solution

To make my life easier, I worked out all the ways that I wanted to be able to split up strings. Basically just two ways: by character number or by substring. Swift already has a substring method but it uses String.Index as shown above. To avoid confusion, I named my functions all sub.

But now I can do the following to split strings by character number:

let subStr = startingString.sub(from: 9)
let subStr = startingString.sub(from: -3)

let subStr = startingString.sub(upTo: 4)
let subStr = startingString.sub(upTo: -3)

let subStr = startingString.sub(from: 3, upTo: 7)
let subStr = startingString.sub(from: 3, upTo: -5)

Negative numbers count back from the end of the string. And they all return String objects!

Or to split strings by their own sub-strings, I can do this:

let subStr = startingString.sub(from: "abc")

let subStr = startingString.sub(upTo: "xyz")

let subStr = startingString.sub(from: "abc", upTo: "xyz")

Extras

Once I had created a string helper library, I started thinking about all the other string utilities that would be useful. So I started adding all sorts of facilities:

Computed properties:
- length (why should the length of a string be called count - that makes no sense)
- words
- lines
- word count
- line count
- title case
Encoding:
- URL encoding & decoding for queries or forms
- base64 encoding & decoding
Trim:
- trim
- trim left
- trim right
- trim using extra characters
Pad:
- pad left
- pad right
- with default space or specified other character

That's as far as I have got so far, but I am hoping for some community involvement that will expand or edit this library to make it more broadly applicable.

Open Source

I have never created an open source project before and I have rarely contributed to open source. But I have now published this library on GitHub under an MIT license. Please check it out at https://github.com/trozware/swift-strings-helper. The GitHub repo contains an Xcode project with all the source files, plus the targets to build frameworks for macOS or iOS, and a playground as documentation and to test it all out.

I would love to get as many stars as possible and it would be fantastic if anyone wanted to log an issue or contribute directly. As someone who finds the whole open source world rather intimidating, I would like to assure everyone that there will be no flaming and no shooting down of ANY ideas. I look forward to hearing from you.

I am sure there are other Swift libraries out there dedicated to solving the same problems, but I hope that mine can prove useful to some. And if you just want to use it without contributing, feel free. The usage instructions are all in the ReadMe on the GitHub page.

Functional Programming in Swift

2018-06-14T04:18:53Z

What is Functional Programming and how can we use it in Swift?

Search online for any definition of functional programming and you will find many different definitions, few of which are practically helpful. I have no claim to be an expert, but as a Swift enthusiast, this is what I have distilled out of the morass.

What is Functional Programming?

Without providing a concrete definition, here are what I see as the 3 main goals of functional programming:

use pure functions where possible
avoid mutability where possible
use functions as the basic building blocks

So let's go through those one by one and see how they fit into the Swift language.

Functional Programming in Swift

You can download a playground containing all these examples from GitHub.

Pure functions

A function is considered pure if it will always produce the same result for the same input, regardless of where it is and what calls it.

Imagine you are writing a role-playing game and for a given fight, you need to be able to calculate the damage per second caused by a character.

class DamageDealer {

    var damageDone: Int = 0
    var timeTaken: TimeInterval = 0

    func damagePerSecond() -> Double {
        if timeTaken == 0 {
            return 0
        }
        let dps = Double(damageDone) / timeTaken
        if dps < 0 {
            return 0
        }
        return dps
    }

}

let mage = DamageDealer()
mage.damageDone = 32
mage.timeTaken = 10

mage.damagePerSecond()

The damagePerSecond function takes no parameters but uses the properties of its containing object. This works in this class, but there are 3 big problems:

The function is not transportable - you cannot copy it into another class as it is totally dependent on the structure of the properties in the containing class.
When calling the function, it is not clear what data it is going to use.
This function is difficult to test as calling the function with the same parameters (none) will produce different results depending on the setup.

So for a version that uses a pure function, we could replace damagePerSecond() with this:

func damagePerSecondPure(damage: Int, time: TimeInterval) -> Double {
    if time == 0 {
        return 0
    }
    let dps = Double(damage) / time
    if dps < 0 {
        return 0
    }
    return dps
}

mage.damagePerSecondPure(damage: mage.damageDone, time: mage.timeTaken)

Calling the function is now more verbose, but reading the call gives you much more information about what is going to happen. Testing is easy, and the function is completely self-contained so can be copied into any class or struct.

Avoid mutability

This one has become the poster child of Swift Functional Programming as Swift provides some very convenient ways to avoid mutability.

The first is let versus var. My rule is always to start defining any variable/constant with let and only changing to var if the compiler raises an error. In the current versions of Xcode, it will give a warning if you use var unnecessarily which is great, but I still stick to using let first.

The most powerful way Swift lets us avoid mutability with Functional Programming is with map, filter and reduce.

Filter

Consider this function that checks possible player names:

func checkPlayerNames(names: [String]) -> [String] {
    var validNames: [String] = []

    for name in names {
        if name.count > 3 && !name.contains(" ") {
            validNames.append(name)
        }
    }

    return validNames
}

let allNames = [ "Woody", "Rex", "Slinky", "Buzz Lightyear", "Hamm" ]
let checkedNames = checkPlayerNames(names: allNames)

Only names with more than 3 characters and no spaces are considered valid. So this function creates an empty array and then loops through each member of the supplied array and appends any valid names to the new array before returning it.

This function is a pure function and it works as expected. But the validNames array is mutable and there is no need for it to be.

Converting this to avoid mutability, we get:

func checkPlayerNamesUsingFilter(names: [String]) -> [String] {
    let validNames = names.filter { name in
        name.count > 3 && !name.contains(" ")
    }
    return validNames
}

Inside the filter closure delimited by the curly braces after the word filter, (more about closures below), the element in the array being evaluated is stored in the name constant. The checks are done and this implicitly returns a Bool - true if the checks pass, false if they do not. If the closure returns true, the name is valid and will be part of the validNames array.

And if you really want to be concise:

func checkPlayerNamesUsingFilterShort(names: [String]) -> [String] {
    return names.filter { $0.count > 3 && !$0.contains(" ") }
}

I recommend the first method even if it is a bit more verbose. Storing the result in a constant before returning it makes debugging much easier. Using $0 instead of using a named parameter is convenient, but I prefer not to do this unless the closure is very simple.

Map

filter takes an array of objects and returns a sub-array containing every element which returned true for the checks inside the filter body.

map changes the elements in an array and can return an array of the same type or an array of different types.

Here is a function to square every integer in an array in the old style, using a mutable array to accumulate the result:

func squareNumbers(_ numbers: [Int]) -> [Int] {
    var squares: [Int] = []

    for number in numbers {
        squares.append(number * number)
    }

    return squares
}

let numbers = [ 1, 2, 3, 4, 5, 6 ]
squareNumbers(numbers)

And doing the same thing using map:

func squareNumbersUsingMap(_ numbers: [Int]) -> [Int] {
    let squares = numbers.map { $0 * $0 }
    return squares
}

In this case, the type of the data did not change: integers went in, integers came out. But map can change the type as well.

func squareRoots(_ numbers: [Int]) -> [Double] {
    let roots = numbers.map { number in
        sqrt(Double(number))
    }
    return roots
}

squareRoots(numbers)

And there is a final twist to map that used to be called flatMap but is now called compactMap and that allows us to get rid of optionals as we map through an array.

func convertStringsToInts(_ strings: [String]) -> [Int] {
    let ints = strings.compactMap { return Int($0) }
    return ints
}

let strings = [ "1", "two", "", "0.34", "65", "-93", "4e8" ]
convertStringsToInts(strings)

The conversion of String to Int may fail and so returns an optional. If this function had used map instead of compactMap, the result would have been an array of optional Ints: [Int?]. By using compactMap, every nil value was dropped and only valid integers are included.

Reduce

The final tool in the immutability toolbox is reduce and this is one that took me a while to wrap my head around.

Imagine that you wanted to add up all the integers in an array. Here is a way to do it using a mutable variable and a loop:

func sumNumbers(_ numbers: [Int]) -> Int {
    var total = 0

    for num in numbers {
        total += num
    }

    return total
}

let numbers = [ 1, 2, 3, 4, 5, 6 ]
sumNumbers(numbers)

I can't use filter or map here because I want to end up with a single value after applying some logic to every item in the array. So here is where I use reduce.

func sumNumbersUsingReduce(_ numbers: [Int]) -> Int {

    let total = numbers.reduce(0) { (cumulativeTotal, nextValue) in
        return cumulativeTotal + nextValue
    }
    return total
}

sumNumbersUsingReduce(numbers)

The reduce function takes 2 parameters. The first is the starting value - in this case it is zero. The second paramter is a function (I am using a closure) this in turn takes 2 parameters and here is where it gets complicated. Inside the closure function, the 2 parameters are the current result and the next value from the loop. And what you return from this closure is going to be the new cumulative value which will either be fed back into the loop, or returned as the final result. The first time through the loop, the first parameter will be the initial value as set in the reduce function call.

To see how this happens, here is a version sprinkled with print statements showing what happens each time through the loop:

func sumNumbersReduceDebug(_ numbers: [Int]) -> Int {
    let total = numbers.reduce(0) { (cumulativeTotal, nextValue) in
        print("cumulativeTotal = \(cumulativeTotal)")
        print("nextValue = \(nextValue)")
        print("about to return \(cumulativeTotal) + \(nextValue) = \(cumulativeTotal + nextValue) which will become the next culmulative or the final value")

        return cumulativeTotal + nextValue
    }
    print("final result = \(total)")
    return total
}

let shortNumbers = [ 5, 3, 8 ]

sumNumbersReduceDebug(shortNumbers)

This produces a log showing:

cumulativeTotal = 0
nextValue = 5
about to return 0 + 5 = 5 which will become the next culmulative or the final value
cumulativeTotal = 5
nextValue = 3
about to return 5 + 3 = 8 which will become the next culmulative or the final value
cumulativeTotal = 8
nextValue = 8
about to return 8 + 8 = 16 which will become the next culmulative or the final value
final result = 16

Using functions as building blocks

This one is more a matter of style than of any particular programming technique. Basically, keep each function small and break your code into small chunks with obvious naming. This makes your code easier to read, test and debug and it beomes vastly more reusable.

Consider this totally made-up function:

func configureDisplay(for userId: String?) {
    guard let userId = userId else {
        showLoginScreen()
        return
    }

    displayUserData(for: userId)
    let userType = getPermissions(for: userId)

    populateMenus(for: userType)
    loadInitialData(for: userId)

    playSound(.welcome)
}

configureDisplay(for: "abc123")
configureDisplay(for: nil)

Is it easy to read? Can you work out what it does? Now imagine all that functionality in a single huge function - would that be as good to use?

As a way of encouraging shorter functions, which leads inevitably to this sort of structured code, I strongly recommend using SwiftLint to check your code. I wrote a post about this a while ago which you might find useful.

Naming

The other key thing to mention and it is a point that Apple makes very strongly, is to name your functions and their parameters so as to make them as readable as possible from the calling site. You write a function once, but you most likely call it multiple times, so it is the calling site that needs to be really easy to read.

Returning to the game example, here is a dummy function to show damage caused to a target:

func displayDamage(damage: Int, target: String) {}

displayDamage(damage: 31, target: "Ogre")

There is nothing really wrong with the function, but calling it is a bit clunky and doesn't read well with the repeated use of the word 'damage'.

What about this version?

func display(damage: Int, doneTo target: String) {}

display(damage: 42, doneTo: "Wolf")

There are no repeated words in the caller and by using two labels for the second parameter, the calling site can read almost like a sentence, but inside the function, target is still a more logical name.

A third alternative is to use an un-named parameter if the naming logic is implicit in the function name itself:

func displayDamage(_ damage: Int, doneTo target: String) {}

displayDamage(12, doneTo: "Orc")

Closures

As promised above, a very quick explanation of closures, which really deserve their own post...

In Swift, as in many languages, functions can be passed as parameters to other functions. As an example, I have set up 2 functions to perform a simple calculation on a given integer:

func cube(_ number: Int) -> Int {
    return number * number * number
}
cube(3)

func square(_ number: Int) -> Int {
    return number * number
}
square(3)

Now imagine that you wanted to create a more general function that could call either one of these functions with any number:

func doCalculation(_ number: Int, calculation: (Int) -> Int) -> Int {
    return calculation(number)
}

doCalculation takes 2 parameters. The first one is easy - it is just an integer. The second one is weird! For every parameter of a function, you have to supply the type of that parameter. Usually this is quite straight-forward: Int, String, MyCustomClass etc. But what is the type of a function? Option-clicking on the word cube in my function definition, I see this:

And ignoring the parameter labels, this basically provides the function type: Int inside parentheses for the input, then the arrow, then Int again for the return type. So the type definition for the cube function is (Int) -> Int. And when I define the type for the calculation parameter in the doCalculation function, this is exactly what I put. The last part of the function definition is specifiying the overall return type as an Int.

Using the cube and square functions inside doCalculation works like this:

doCalculation(7, calculation: square)
doCalculation(4, calculation: cube)

But what if I didn't want to define all the functions I might call in advance? Then I can send the function body to the doCalculation function instead of using a pre-built function. This way of using a function inside another function is referred to as a closure.

doCalculation(6, calculation: { number in
    return number * 12
})

The doCalculation function in unchanged, but instead of passing it a reference to a function, I am directly passing it the instructions it should use to get the result. As with any function, the instructions are contained within a set of curly braces. The input to this function is listed after the opening curly brace followed by the keyword in. Then the function body does whatever it needs to and returns the result.

You may have heard the term trailing closure. This refers to a function where the last parameter is a function. If that function is called using a closure, there is a short-hand way of writing this, omitting the closure's parameter name and moving the closing parenthesis to before the opening curly brace.

doCalculation(16) { number in
    return number % 3
}

With the filter, map and reduce functions I showed above, this is the way their logic was supplied but here is how the filter example would look without using a closure:

func checkName(_ name: String) -> Bool {
    return name.count > 3 && !name.contains(" ")
}

func checkPlayerNamesUsingFunction(names: [String]) -> [String] {
    let validNames = names.filter(checkName)
    return validNames
}

let allNames = [ "Woody", "Rex", "Slinky", "Buzz Lightyear", "Hamm" ]
let checkedNames = checkPlayerNamesUsingFunction(names: allNames)

Which methods you use are up to you - they all work. If you have a function that will be called in many different places, maybe it makes more sense to define it once and pass around a reference to that function. If not, a closure has the advantage that it keeps everything together. There is more to closures, particularly to do with variable scope, but I think this post has gone on long enough already.... maybe next time.

World Time In Words iOS Update

2018-06-14T00:41:46Z

Its been a long time since the last update to Time In Words for iOS but after prompting by Apple (update or we will remove it from the App Store), I finally did it. I was never really happy with the last design of Time in Words for iOS, particularly for the iPad, so this was a good opportunity to do a complete re-design, bringing the app more into alignment with its Mac counterpart. And it got a new name to match its new direction and is now called World Time in Words.

World Time in Words v 5.0 is available from the App Store.

In 2015, I released Time In Words v 4.0 for iOS. This was a big change as I had dropped the original QlockTwo concept and switched the emphasis to world time conversions that would be easy to read and understand. This bit worked out well, but the paging interface was not a great success - it made it too tedious to find the zone you were interested in.

The Mac version is a menu bar app that shows the selected time zones as separate menu items. iOS apps don't have menus, but the closest thing to this is a table, so that is what I went with.

As before, you can add, remove or re-order the time zones and the top three zones can be shown in your Today widgets.

But the feature that I use most in the Mac app is "What time will it be when...". In the iOS app, for reasons of space, the button is labelled "What time will it be?" but the functionality is the same: drag the slider to adjust the hour in your local time zone and see what that hour will be in your selected world zones. This is incredibly useful when you have family, friends and colleagues all over the world and really don't want to call them at the wrong time of day.

The iPad version of the app is identical at this stage, but I am thinking of adjusting the interface so as to take advantage of the increased real estate. If other work doesn't get in the way, this may happen...

Privacy Policy

2018-05-25T23:51:56Z

TL;DR: I don't track you either on my web site or through my apps. If you want to contact me, please do so but I will not initiate any contacts.

As anyone who gets email would realise by now, the EU has introduced a General Data Protection Regulation designed to enhance online privacy. You will have been getting lots of emails announcing new privacy policies or asking you to opt-in to existing arrangements.

So here is my version of those emails (which you will not get by email because I do not store any user data):

None of my apps store data off your device.
I do not have any user data except for data specifically sent to me via web forms, direct email or in-app email.
If you have signed up to beta test one of my apps, you did give me your email address. No tests are currently on-going, but please contact me if you would rather I removed you from any future beta tests.
My web sites are now totally free of trackers and analytics software.

Most of my apps have a "Contact the Developer" button that creates an email that I will answer. If you do not want me to have your name and email address, do not use these buttons.

My web site has a contact page - if you use it, I will see your name and email address and I will respond. Again, if you do not want me to have this data, do not use this page.

Since I no longer have any analytics, I would really appreciate hearing if you find any of my posts useful or interesting.

App Updates

2018-05-25T23:22:57Z

Just a quick post to let you know about some recent app updates...

Man Reader

Man Reader v 1.10 was released on 11 May 2018.

I had to update Man Reader in November 2017 because of a really strange "feature" that arrived with macOS High Sierra. Man Reader displays the man pages as HTML which allows the tabs and internal links to work using anchor tags. These had worked for years, but under High Sierra, they just stopped working.

I eventually discovered that it was because I was loading the text directly into the WebView using:

[self.web.mainFrame loadHTMLString:manText baseURL:nil];

With no baseURL, the anchor links were all defaulting to about:blank and going nowhere. The solution was to save the text to a temporary file and then load using:

NSURLRequest *request = [NSURLRequest requestWithURL: tempFile];
[self.web.mainFrame loadRequest: request];

Needless to say, this took me ages to work out, including a lengthy excursion into using WKWebView to see if the more modern web view would solve the problem.

The second update (May 2018) was in response to a crash report from a user. I had great difficulty tracking this one down and even now, I cannot see how it can have happened, but it was in relation to the utility apps that are displayed in the toolbar.

For each app, Man Reader checks to see if the app bundle exists, then it checks for a bundle identifier. It appears that this can come back as nil which I had not realised. And trying to insert an item with a identifier of nil into the toolbar caused a crash.

As you can see from the code, ManReader is written in Objective-C. Going back to Objective-C from Swift is painful! And I know that this crash could not have happened if the app had been written in Swift as the identifier would have been an optional and I would have been forced to check that it was not nil before using.

On the plus side, Objective-C apps are tiny in comparison to Swift apps. And the Mac App Store review process set a new record for me. I submitted the app at 10:58 am and it was on sale at 12:03 pm the same day - 66 minutes from start to finish.

Sequenza VII

The other app that I updated recently is Sequenza VII. Version 1.2 was released on 23 April 2018.

This is an app with a very limited audience - specifically oboe players who want to learn to play Berio's weird music. However Apple sent me a notice saying that as it hadn't been updated for ages, it would be removed from the store within 30 days unless I did something.

Updating it to use the iPhone X display was surprisingly difficult. I set the minimum system version to 11.0 and changed the storyboards to use the latest Xcode but the horns on either side of the notch were still being left blank. In the end, the trick I found was to create a new Launch storyboard - that seemed to fool the system into re-considering all the layouts.

Consistent Swift Style

2018-03-30T23:35:21Z

Why is important to style your code?
How do you decide on a style?
Is there a way to enforce this style automatically?

What is style in Swift?

Style applies to writing in any programming language and refers to the way you structure your code.

For example, how to you arrange braces?

if theValue < 10 {
    // do one thing
} else {
    // do the other thing
}

if theValue < 10
{
    // do one thing
}
else
{
    // do the other thing
}

or anything in between?

Do you use camelCase or snake_case?

Do you always start class names with an uppercase letter?

And of course there is the Great Debate: tabs or spaces? And how many?

Why is important to style your code?

You only write code once, but you & others will read it many times.

As I tell students, in six months time some poor sucker is going to have to read this code, and worse still, that poor sucker might be you, so make it readable.

There is a cognitive load involved in reading code but you can lighten that load by using consistent patterns that your brain can recognise quickly without having to re-analyse them each time.

How do you decide on a style?

Do a search online for Swift style guide and you will get numerous results, although you do have to dodge the sites dedicated to Taylor Swift's dress sense! I like the Ray Wenderlich guide although its emphasis is on styles that read well in print and in web pages. The LinkedIn guide is also good. GitHub also has a style guide but it hasn't been updated recently. However it contains some good general advice.

But in the end, you have to decide your own style. The important thing then is to be consistent. I don't care whether you use camelCase or snake_case, tabs or spaces, but if you use a mixture your code will be harder to read, so pick a style and stick to it.

Is there a way to enforce this style automatically?

This is where SwiftLint comes into the picture. SwiftLint is a tool that can check your code and look for style violations. While it comes with a default set of rules, you can configure these rules to suit your own style.

Installing and Running SwiftLint

To install SwiftLint, I recommend using HomeBrew. Once you have HomeBrew installed, open Terminal and type brew install swiftlint. You can update it any time using brew upgrade swiftlint.

You can run SwiftLint directly from the Terminal. cd to the folder containing your Xcode project and type swiftlint. For a brand new iOS project, you will probably get a result similar to this:

Linting Swift files in current working directory
Linting 'ViewController.swift' (1/2)
Linting 'AppDelegate.swift' (2/2)
ViewController.swift:23: warning: Vertical Whitespace Violation: Limit vertical whitespace to a single empty line. Currently 2. (vertical_whitespace)
ViewController.swift:25: warning: Trailing Newline Violation: Files should have a single trailing newline. (trailing_newline)
AppDelegate.swift:16: warning: Vertical Whitespace Violation: Limit vertical whitespace to a single empty line. Currently 2. (vertical_whitespace)
AppDelegate.swift:44: warning: Vertical Whitespace Violation: Limit vertical whitespace to a single empty line. Currently 2. (vertical_whitespace)
AppDelegate.swift:46: warning: Trailing Newline Violation: Files should have a single trailing newline. (trailing_newline)
AppDelegate.swift:17: warning: Line Length Violation: Line should be 120 characters or less: currently 144 characters (line_length)
AppDelegate.swift:23: error: Line Length Violation: Line should be 120 characters or less: currently 285 characters (line_length)
AppDelegate.swift:24: warning: Line Length Violation: Line should be 120 characters or less: currently 159 characters (line_length)
AppDelegate.swift:28: error: Line Length Violation: Line should be 120 characters or less: currently 218 characters (line_length)
AppDelegate.swift:29: warning: Line Length Violation: Line should be 120 characters or less: currently 141 characters (line_length)
AppDelegate.swift:33: warning: Line Length Violation: Line should be 120 characters or less: currently 155 characters (line_length)
AppDelegate.swift:37: warning: Line Length Violation: Line should be 120 characters or less: currently 194 characters (line_length)
AppDelegate.swift:41: warning: Line Length Violation: Line should be 120 characters or less: currently 128 characters (line_length)
Done linting! Found 13 violations, 2 serious in 2 files.

I have removed the full path that will be listed for each file just to make this fit better.

These reports show the file and line number, whether this is an error or a warning, a description of the error and the name of the SwiftLint rule that caused the warning or error.

You could now go through and fix each of these but there are 2 solutions to make things easier: Try entering this in the Terminal window: swiftlint autocorrect.

Correcting Swift files in current working directory
Correcting 'ViewController.swift' (1/2)
Correcting 'AppDelegate.swift' (2/2)
ViewController.swift:22:1 Corrected Vertical Whitespace
ViewController.swift:23 Corrected Trailing Newline
AppDelegate.swift:15:1 Corrected Vertical Whitespace
AppDelegate.swift:43:1 Corrected Vertical Whitespace
AppDelegate.swift:43 Corrected Trailing Newline
Done correcting 2 files!

And now if you run swiftlint again you will only get Done linting! Found 8 violations, 2 serious in 2 files. and all the remaining issues are for Line Length Violation This shows that autocorrect cannot fix everything and while it is good on spacing, it has trouble with more complex issues. But it is still worth doing as it can do a lot of the tedious fixes that creep into Xcode projects.

Incorporating SwiftLint into Xcode

The next thing to do to make your life easier is to add SwiftLint to your Xcode project so that it can run automatically whenever you do a build.

Open your project in Xcode and select the project itself at the top of the Navigator on the left. Select the target for the main app and click the Build Phases tab along the top. Click the + button at the top left of the existing build phases and choose 'New Run Script Phase'. Expand the newly added phase and paste in the following script:

if which swiftlint >/dev/null; then
  swiftlint autocorrect
  swiftlint
else
  echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi

Your Xcode window should look something like this:

If you think this looks like it is running SwiftLint twice, you are correct. The first time through it corrects what it can and the second pass reports all remaining issues. This is still faster than manually correcting the easy stuff. So now you will see any violations in the Xcode issue navigator when you do a build and you can click the entry to go directly to the code.

Configuring SwiftLint

Now you are all set to SwiftLint all your code, but how do you decide what styles SwiftLint should enforce? Go back to Terminal, make the Terminal window as wide as possible and run swiftlint rules which will return a table like this (click to see full-sized image):

For details on what each rule does, check out the entries in Rules.md

As an example, look at the rules for line_length:

+------------------------------------------+--------+-------------+------------------------+-------------+---------------------+
| identifier                               | opt-in | correctable | enabled in your config | kind        | configuration       |
+------------------------------------------+--------+-------------+------------------------+-------------+---------------------+
| line_length                              | no     | no          | yes                    | metrics     | warning: 120, er... |
+------------------------------------------+--------+-------------+------------------------+-------------+---------------------+

And by making my Terminal window full width, I can see the configuration column contains warning: 120, error: 200, ignores urls: false, ignores function declarations: false, ignores comments: false.

The rule name (identifier) is line_length - this is what appears in the issue navigator or Terminal.
It is not an opt-in rule, meaning that it is enabled by default.
It is not correctable by autocorrect.
It is enabled in this configuration.
And then comes the configuration:
- a line of more than 120 characters will generate a warning
- a line with more than 200 characters will generate an error and stop the build
- this rule will not ignore URLs, function declarations or comments

To set your own configurations, you need to create a .swiftlint.yml file in the same folder as your Xcode project. The leading period makes the file invisible, so you will need to create and edit it using Terminal.

In the Terminal, cd to the folder containing your Xcode project file and run touch .swiftlint.yml to create the invisible file. You can edit the file in Terminal using nano, vim or whatever you prefer, but you can also open it in any text editor. I prefer to use Atom so I open the file by running this command: atom .swiftlint.yml.

The SwiftLint ReadMe has a section about configuration which shows the format and the various general headings you can use, as well as how to configure an individual rule.

Here is my .swiftlint.yml file:

disabled_rules: # rule identifiers to exclude from running
included: # paths to include during linting. `--path` is ignored if present. takes precendence over `excluded`.
excluded: # paths to ignore during linting. overridden by `included`.
  - Carthage
  - Pods
opt_in_rules:
  - closure_end_indentation
  - closure_spacing
  - contains_over_first_not_nil
  - empty_count
  - explicit_init
  - fatal_error_message
  - force_unwrapping
  - literal_expression_end_indentation
  - multiline_arguments
  - multiline_parameters
  - operator_usage_whitespace
  - overridden_super_call
  - private_outlet
  - prohibited_super_call
  - trailing_closure
  - unneeded_parentheses_in_closure_argument
function_body_length:
  - 60 # warning
  - 100 # error
line_length:
  - 150 # warning
  - 200 # error
cyclomatic_complexity:
  ignores_case_statements: true

No rules are disabled by default.
included is blank which means it checks every folder...
... except for the ones listed in the excluded section.
opt-in-rules: I went through the list of rules with opt-in equal to yes and enabled all I thought useful.
function_body_length - the default warning length is 40 but I allow myself 60 as that fits on my screen so I can always see the entire function without scrolling.
line_length - with a bigger screen, I lengthen both the warning and error lengths.
cyclomatic_complexity checks for functions that are getting so complex that the compiler might run into trouble. I have this on with the default warning & error limits, but I set it to ignore case statements as they can often trigger this without really being too complex.

Now that my .swiftlint.yml file is edited, doing a build uses those settings and for a new iOS project, I am now down to 2 errors and 3 warnings, all due to long lines in AppDelegate.swift.

The other main way to configure SwiftLint is by disabling specific rules in my code.

As an example, I have an enum for direction:

enum Direction {
  case up, down, left, right
}

When I build this, SwiftLint gives a warning: Identifier Name Violation: Enum element name should be between 3 and 40 characters long: 'up' (identifier_name)

This tells me that up is too short a word to use as an identifier according to the identifier_name rule. In this case, up is the obvious identifier to use, so I want SwiftLint to let it pass. But I don't want to check my configuration file, because I want it to catch other short identifier names.

The solution is to add this comment to my code, before the case line:

// swiftlint:disable next identifier_name

This tells SwiftLint to ignore the next identifier_name warning or error it sees and now my code builds without error.

Rules can also be disabled or enabled by file. Check out the Disable rules in code section of the SwiftLint ReadMe for more details.

What are the benefits?

For me, SwiftLint enforces a number of good habits:

Files are kept relatively short.
Functions are always small enough to fit on a single screen.
Variable names & function names cannot be too short and non-descriptive.
Braces, indentation and white-space are always consistent.

And sometimes the warnings make me think of a better way to do things.

Icon Builder 5

2018-02-18T00:19:18Z

Icon Builder 5.0 is now available from the Mac App Store. This is a complete re-write for better compatibility with Apple's latest icon requirements. Read on to see what I have fixed and how...

Problems

When I came to create a new iOS app recently, I found out that Icon Builder had fallen behind Apple's requirements in three ways:

The 1024 x 1024 marketing icon is now supposed to be inside the app's icon set.
Icon files must have their color profile set to sRGB (P3 is also valid for iOS apps).
iOS icon files must have no transparent pixels and the alpha channel must be removed from the files.

When I set to work fixing these problems I soon ran into issues with the existing version of Icon Builder which was created 6 years ago.

It was written in Objective-C which I am increasingly finding difficult and un-safe to write.
The app was written when I was very much a beginner in Mac apps and this is obvious from the code...
There was a lot of legacy code left over from previous changes and extensions.

So I decided that the most interesting thing to do would be to start almost from scratch and re-write the app in Swift using better techniques.

The Re-write

Now instead of the Massive View Controller, I have a larger set of small files, each with their own responsibility. Enums and structs dictate the various requirements for the different devices or app types. Other structs deal with creating the images, the folder management and writing out the files. An NSImage extension handles the resizing and reformatting of the images. This is now an app that I would not be ashamed to show anyone, except perhaps for the need to add more unit tests.

Adding a color profile

But then we get to the new features needed. Adding the 1024x1024 icon to the app icon set was easy, especially after the re-factoring. But what about the color profile?

This was not as easy as I expected - there is no built in command to apply a profile but here is the solution that I finally found:

extension NSImage {

  func convertImageTo_sRGB() throws -> Data {
      guard let colorSpace = CGColorSpace(name: CGColorSpace.sRGB),
          let cgi = self.cgImage(forProposedRect: nil,
                                 context: nil,
                                 hints: nil) else {
                                  throw ImageError.cantMakeCgImage
      }

      let ci = CIImage(cgImage: cgi)

      guard let pngData = CIContext().pngRepresentation(of: ci,
                                                        format: kCIFormatRGBA8,
                                                        colorSpace: colorSpace) else {
          throw ImageError.cantConvertToPng
      }
      return pngData
  }

}

This takes the NSImage and converts it to a CGImage, first checking that the appropriate color space exists.
Then it uses the Core Graphics CGImage to create a Core Image CIImage.
There is a new API in macOS 10.13 to extract the png data from a CIImage while assigning a color profile.
This Data can then be written directly to a file and there you have a PNG with an attached color profile.

Transparency

Now problems 1 & 2 have been solved. Problem 3 was the most difficult. It turned out to be a two-part problem because an image file can have no transparent pixels but still have an alpha channel in the file data.

At first, I thought maybe I could just circumvent the whole problem by converting the images to JPEGs which have no transparency or alpha channel. Using the code above, I just changed it to getting the jpegRepresentation instead and saving with a .jpg file extension.

While this solved the alpha channel problem, the transparent parts of the icon just went black which was a not a good look.

For anyone horrified at my use of force-unwrapping, I never do this in a production app but in a playground, it makes the code shorter and it doesn't really matter if I get a crash there.

Converting transparent pixels to white

So the first step must be to set the transparent parts of the image to another color. Searching for solutions online, most of the ones I came up with were very slow (processing each pixel) or so complicated that I didn't understand them, and I hate just copy-pasting code that I don't understand at all.

But eventually I found something that I morphed into this:

extension NSImage {

    func makeAlphaWhite() -> NSImage {
        guard let imageData = self.tiffRepresentation,
            let imageRep = NSBitmapImageRep(data: imageData),
            let jpegData = imageRep.representation(using: .jpeg, properties: [
                NSBitmapImageRep.PropertyKey.compressionFactor: NSNumber(value: 1.0)
                ]),
            let jpegImage = NSImage(data: jpegData) else {
                return image
        }
        return jpegImage
    }

}

It used basically the same trick of converting the image into a JPEG but doing it this way via NSBitmapImageRep turned the transparent pixels white instead of black. And as you can see, this gave a much better looking image:

Now I was able to continue with my plans to have JPEGs rule the world! This worked really well in my early tests but then I came to try a Stickers app and the icons didn’t work. I couldn't even drag them in manually! Back to the Apple docs and I see that icons must be PNGs.

When I changed the transparent pixels to white, added the color space and then saved the PNG data, I got an image that looked correct but the file still contained an alpha channel. So I had to come up with a method that re-wrote the PNG data in such a way that it never contained any alpha data at all.

Removing the alpha channel

Graphics experts are probably groaning aloud by now, but I did eventually arrive at a solution, however hacky:

extension NSImage {

    func convertImageTo_sRGB_noAlpha() throws -> Data {
        guard let colorSpace = CGColorSpace(name: CGColorSpace.sRGB),
            let cgi = self.cgImage(forProposedRect: nil,
                                   context: nil,
                                   hints: nil) else {
                                    throw ImageError.cantMakeCgImage
        }

        let ci = CIImage(cgImage: cgi)
        guard let jpgData = CIContext().jpegRepresentation(of: ci,
                                                           colorSpace: colorSpace) else {
            throw ImageError.cantConvertToJpg
        }
        guard let jpegImage = NSImage(data: jpgData) else {
            throw ImageError.cantConvertToJpgImage
        }
        let pngData = try jpegImage.convertImageTo_sRGB()
        return pngData
    }

}

Take the image after changing the transparent pixels to white.
Convert it to JPEG data with the required color space.
Convert the JPEG data back to an image - this will contain NO alpha data.
Use the original routine to convert this JPEG into PNG data with the correct color space.

Running this in the playground looks like this:

And as you can see from the file info, it results in a file with the correctly assigned color profile and no alpha channel:

The double shuffle sounds time-consuming and in-efficient but it really doesn't take long. In my tests, by far the longest part of creating an icon set is opening the file dialog.

Future plans

Add more unit tests.
Work out how to replace the transparent pixels with a selected color.
Offer better cropping and image positioning options.

References

For resizing and cropping images, I use Matt Gemmell's NSImage+MGCropExtensions and for further reading, I recommend Apple's Human Interface Guidelines concerning app icons for iOS and macOS.

Note: here is Australia we use the spelling colour but for consistency with the code samples, I have used color throughout the text.

NCSS 2018

2018-01-05T01:33:35Z

I gave a Masterclass on Swift at the NCSS Summer School 2018 in the University of Sydney on 9th January 2018. This post contains useful links for use in relation to the material covered during my class.

Online Sandboxes

Resources

Gist of Code Samples

Slides from Presentation

Contact Details

Email: sarah@troz.net
Twitter: @trozware

Useful Links

Mark Time

2017-12-11T23:14:07Z

Mark Time is an application for Celestial Navigation that solves the problem of how to take an accurate time reading to go with each sextant sighting. Here is how it was developed...

A day in the life of a software developer - "it would be great if there was an app that did..."

One of the family is learning celestial navigation and was struggling with the problem that you either need a partner or more than 2 hands. The key factor is that you need to record the exact time at the moment when you take your sighting. And this time has to be in UTC to make your subsequent calculations work.

Since this is a very simple app, I decided it would be fun to describe the development process from first specifications to release in the App Store.

The Basic Specs

tap anywhere on the screen to record the time
convert the time to Universal Time (UT)
display that time in a specific format: DD:HH:MM:SS
store the last 5 tap times

A UITapGestureRecognizer over the entire view solved the first requirement. The native Date object handles time zone conversions perfectly, and then it was a matter of configuring a DateFormatter with a custom format string to provide the required date display.

The last 5 times are stored in UserDefaults and displayed in reverse order so the most recent is always at the top.

UI considerations

colour scheme must work in bright sunlight
text should use dynamic sizing so it works if people adjust the text size on their iPhones
the UI elements must be out of the way of the new iPhone X system gestures.
while it will most likely be used on iPhones, allow for iPads as well

I had done extensive tests of colour schemes when developing my golf scoring app, so I already had the answer to the colours question: dark grey background with white text.

Allowing for dynamic type should have been easy - choose a font style e.g. body, headline, title 1 and set it to adjust automatically. But with a display that is mainly numeric, the display looked terrible because the numbers in the default San Francisco are non-proportional. So I switched to Helvetica Neue and watched for dynamic font size changes manually.

The iPhone X should be fine since I used the new safe area layout guides.

For iPad, I didn't make a lot of UI changes since I don't expect it to be used much, but the display is bigger and probably easier to read.

Refinements

As always, once the first few iterations have been through the testing process, there were a few things that needed changing and then feature creep set in...

change the date format to be more readable
change the basic tap gesture so that it triggers on tap down, not tap up
add a button to clear all the stored data
display the current time in UTC and in the same format
cheat mode - record latitude and longitude for each time so the calculations can be checked
change the format for showing the latitude and longitude
sound & haptics to provide feedback
settings

The date format was DD:HH:MM:SS so for 12th December at 1:01:46 pm, this would show 12:13:01:46 which we decided was a bit confusing. One tended to assume the first section was actually the hours. Under the new scheme, that same date displays as 12d 13h 01m 46.654s. The extra precision on the seconds was to show that the time really was changing if you tapped multiple times quickly.

To make the time record immediately, I removed the UITapGestureRecognizer and placed UIButtons covering all the relevant active areas. They respond on Touch Down for a much faster reaction.

Usually, I make a separate View Controller for preferences. This time, because the app needed access to the standard Settings app for Location services, I decided to add the app's preferences to the app's page in the Settings app. This worked really well, and made the app itself smaller and simpler.

In cheat mode, the location is recorded at every tap and then the info button beside each time shows the details. This needed to handle the permissions required for accessing the user's location. The latitude and longitude are shown in decimal format and at first, I also showed them in DMS (degrees, minutes, seconds) format. I found out that for navigation calculations, they prefer to see degrees and decimal minutes, no seconds. And rather oddly, this is displayed something like this: 153° 22'.84 E

Sounds and haptics were added, configurable through Settings. The sound was a nice loud double-beep designed to be clearly audible to tell you when you had recorded a time.

Release

After numerous rounds of TestFlight, I was ready to release. The app was submitted to iTunes Connect and ready for review on Dec 9, 2017 at 7:36 PM. It moved into review on Dec 11, 2017 at 8:07 AM and was ready for sale on Dec 11, 2017 at 10:19 AM. So less than 39 hours from start to finish of the review process for a new app - things have certainly changed!

The app is free - you can get it from the iTunes App Store.

Moving to Hugo

2017-11-29T07:42:57Z

Yesterday, I came to update my blog: I had a new post in draft form and I wanted to update the Swift code to version 4. However installing High Sierra had removed Jekyll which is the site generator that I had been using. I re-installed Jekyll but found that it had been updated from version 2 to version 3.

Jekyll Problems

Then my problems started: missing dependencies due to the basic Jekyll install no longer including certain features, and then syntax errors due to changes in the way things are done, particularly to do with pagination.

I tried to fix this myself, then thought that maybe the theme I was using had already solved these issues so I tried re-installing that. It wanted to add about 25 more gems and then failed to install - sigh - spend some time rolling that back...

At this point I decided that if Jekyll was going to cause me a lot of trouble, it might be worth looking at an alternative.

My main criteria were the ability to import my Jekyll site and the ability to host on GitHub Pages. After checking out the options, I decided to have a look at Hugo.

Moving to Hugo

One of the most lauded features of Hugo is speed. I had found with Jekyll that when I saved an edited page, it took about 5 seconds before the edits could be reloaded into the browser. Hugo is supposedly fast and does auto reloads.

Following the Quick Start guide, I installed Hugo. Importing my Jekyll site worked easily and so fast I wasn't sure anything had happened, transferring my posts to contents/posts and my other files (status pages, images etc.) to static.

Then the main exercise appeared to be choosing a theme which would provide not only the visuals but the capabilities of the site.

So I drew up a list of demands for any theme I chose:

Must Have Features

Responsive
Blog style:
- front page with recent posts
- tags
- archive page
Written using Markdown
Static pages for apps listing, about, contact etc.
Syntax highlighting
Social links
Google Analytics

Would Be Nice Features

Disqus commenting
Twitter cards
JSON Feed
Searching within the site

The Hugo themes page https://themes.gohugo.io has themes listed by capabilities, but no way that I could see to combine a selection of capabilities.

Some of the features like Google Analytics or Disqus comments, I could probably add myself using templates from theme that did include them, if the template I chose did not.

Conveniently, nearly all these seem to come with an exampleSite folder that contains the configuration info.

Configuring a Theme

After testing out several alternatives, I decided to go with Even - at least to start with. I installed the theme and copied the contents of the example config.toml to my own config.toml file and started configuring.

I wasn't happy with some of the fonts, but soon worked out how to change the CSS in the theme and then re-build it to apply the changes. And I changed the theme colour from the default red to "Cobalt Blue".

Most of the other changes were done using the config.toml file. I was able to set up menus, configure the social media links I wanted to show, set date formats, set the number of items to show per page and so on.

I had a couple of more static pages that I wanted to show, so I added their Markdown files to the content folder.

One nice feature which I had missed in Jekyll (or at least the way I had it set up) was the ability to separate blog posts from more static web pages. Each of my apps has an information/support page that does not accept comments and doesn't need to be listed in the Archives. By moving these Markdown files from contents/posts to contents/pages, I was able to achieve this.

Adding Google Analytics and Disqus commenting was as easy as entering my IDs in the relevant places in the config.toml file.

I had to do some editing of my imported posts from Jekyll - mainly getting rid of references to https://troz.net so that images and internal links would work. And sometimes I just needed to re-save a file to make Hugo re-evaluate it (there is probably a command to force a complete re-build if I looked for it.)

Working out the Structure

One thing that I was puzzled by was what templates the various pages are generated from.

The main page is easy enough as the theme folder has a layouts folder with an index.html file containing the templating. When a post is displayed, that looks like it comes from layouts/posts/single.html while layouts/posts/summary.html contains the templating for each entry in the index page.

But clicking on the Archives link in the me takes me to https://troz.net/post/ and there is no post.html file in layouts. There is a post folder, but it contains the single.html & summary.html files described already.

Delving ever deeper, layouts/_default/section.html appears to contains the Archives page template. But how does that relate to the https://troz.net/post/ link? And the Tags template is in layouts/_default/terms.html but appears in https://troz.net/tags/. Checking the Hugo documentation for creating a theme, I find the information I need. Hugo has a selection of file paths that it checks for such templates, and these file paths match some of those. So now I know where to go to customise further.

One feature that I really like about the Even theme is the ability to have a table of contents displayed beside each blog post if your page is wide enough. It takes the headers in the post and uses them to make the table. I may need to add or edit the headers in some posts, but I really like this feature.

And if you want a laugh, test out the 404 page - here is a bad link - which generates a random text emoji each time!

Publishing

I wanted to use my existing GitHub Pages setup, so I replaced the site files in my local repository with the new Hugo site files. I generated the static site files using hugo in Terminal, then pushed the pages to GitHub. All I had to do then was change the settings so that GitHub Pages knew my site was coming from the docs folder and I was live with the new site.

Final Thoughts

So how am I going with my check list?

Responsive - ALMOST, not Hugo's fault
Blog style - YES
Written using Markdown - YES
Static pages for apps listing, about, contact etc. - YES
Syntax highlighting - YES
Social links - YES
Google Analytics - YES
Disqus commenting - YES
Twitter cards - NO
JSON Feed - NO
Searching within the site - NO

The Hugo generated pages are all responsive and look great on my iPhone, but my old static page for listing my apps does not look good, so I need to re-design that.

Twitter cards - I have found some articles on how to set that up, so it is possible, but I haven't done it yet.

JSON Feed is not working. There are themes that apparently have this, but I haven't yet worked out how to implement it - hopefully later.

In-site search - this was something I was able to get in my old WordPress site, but not in Jekyll. There are Hugo themes listed that support search, but they seem to just give a link to Google or DuckDuckGo. Maybe this can be edited to restrict it to the site, but I dislike using such searches, so I will not add a search unless it works internally. One theme I found uses Algolia to search the site, so I will investigate that.

Overall, I am impressed. The transition was relatively easy, especially considering that I didn't take the time to learn anything about Hugo first, but just blundered in and tried to work it out on the fly.

The speed of generating pages and the live reload while developing make Hugo a pleasure to work with. Now all I have to do is write some interesting posts...

And I want to tidy up the URLs, headers and tags for the older pages as well as investigating Twitter cards, search & JSON Feed.

JSON Parsing in Swift 4

2017-06-18T00:00:00Z

Updated: 3rd September 2017.

Checked syntax using Xcode 9.0 beta 6.
Added section on allowing for nulls.

Since JSON has become the de facto standard for data transfers around the internet, there has always been a lot of interest in Swift libraries to parse JSON into Swift classes or structs. Searching for "swift json library" on GitHub discovers 77 86 repositories. So why are there so many? And what has Swift 4 done to sherlock them all?

The problem has always been converting loosely typed JSON to strictly typed Swift which involves a lot of type casting, checking, optionals etc. Swift has always provided access to the Objective-C methods for converting JSON to and from NSData, NSDictionary and NSArray. (These are now called Data, Dictionary and Array, but those labels are so universal, that I sometimes feel a more specific nomenclature would be useful. Have you tried doing a search for 'Data'?)

For sample data, I am using https://jsonplaceholder.typicode.com/users which returns 10 user objects in this format:

{
  "id": 1,
  "name": "Leanne Graham",
  "username": "Bret",
  "email": "Sincere@april.biz",
  "address": {
    "street": "Kulas Light",
    "suite": "Apt. 556",
    "city": "Gwenborough",
    "zipcode": "92998-3874",
    "geo": {
      "lat": "-37.3159",
      "lng": "81.1496"
    }
  },
  "phone": "1-770-736-8031 x56442",
  "website": "hildegard.org",
  "company": {
    "name": "Romaguera-Crona",
    "catchPhrase": "Multi-layered client-server neural-net",
    "bs": "harness real-time e-markets"
  }
}

The goal will be to convert this to an instance of this matching Swift struct:

struct User {
    let id: Int
    let name: String
    let username: String
    let email: String
    let phone: String
    let website: String
    let address: Address
    let company: Company

    struct Address {
        let street: String
        let suite: String
        let city: String
        let zipcode: String
        let geo: Coordinates

        struct Coordinates {
            let lat: Double
            let lng: Double
        }
    }

    struct Company {
        let name: String
        let catchPhrase: String
        let bs: String
    }
}

The first thing to note is that the Swift struct (and its embedded structs) use multiple different types: Int, String, Double, Address, Coordinates, Company. The JSON data only has strings and numbers and even then, some of the numbers are really strings - look at the lat & lng entries. So converting from JSON to a struct and back again has always been problematic, but let's give it a go using built-in Swift 3 processing with no external libraries.

Decoding in Swift 3

You can insert this into a playground or download my playground and check out the Swift 3 JSON page:

import Foundation

let sampleDataAddress = "https://jsonplaceholder.typicode.com/users"
let url = URL(string: sampleDataAddress)!
let jsonData = try! Data(contentsOf: url)

struct User {
    let id: Int
    let name: String
    let username: String
    let email: String
    let phone: String
    let website: String
    let address: Address
    let company: Company

    init?(dict: [String: Any]) {
        guard
            let id = dict["id"] as? Int,
            let name = dict["name"] as? String,
            let username = dict["username"] as? String,
            let email = dict["email"] as? String,
            let phone = dict["phone"] as? String,
            let website = dict["website"] as? String,
            let addressDict = dict["address"] as? [String: Any],
            let address = Address(dict: addressDict),
            let companyDict = dict["company"] as? [String: Any],
            let company = Company(dict: companyDict)
            else {
                return nil
        }

        self.id = id
        self.name = name
        self.username = username
        self.email = email
        self.phone = phone
        self.website = website
        self.address = address
        self.company = company
    }

    struct Address {
        let street: String
        let suite: String
        let city: String
        let zipcode: String
        let geo: Coordinates

        init?(dict: [String: Any]) {
            guard
                let street = dict["street"] as? String,
                let suite = dict["suite"] as? String,
                let city = dict["city"] as? String,
                let zipcode = dict["zipcode"] as? String,
                let geoDict = dict["geo"] as? [String: Any],
                let geo = Coordinates(dict: geoDict) else {
                    return nil
            }

            self.street = street
            self.suite = suite
            self.city = city
            self.zipcode = zipcode
            self.geo = geo
        }

        struct Coordinates {
            let lat: Double
            let lng: Double

            init?(dict: [String: Any]) {
                guard
                    let latString = dict["lat"] as? String,
                    let lat = Double(latString),
                    let lngString = dict["lng"] as? String,
                    let lng = Double(lngString) else {
                        return nil
                }
                self.lat = lat
                self.lng = lng
            }
        }
    }

    struct Company {
        let name: String
        let catchPhrase: String
        let bs: String

        init?(dict: [String: Any]) {
            guard
                let name = dict["name"] as? String,
                let catchPhrase = dict["catchPhrase"] as? String,
                let bs = dict["bs"] as? String else {
                    return nil
            }

            self.name = name
            self.catchPhrase = catchPhrase
            self.bs = bs
        }
    }
}

if let json = try? JSONSerialization.jsonObject(with: jsonData, options: []) {
    if let jsonArray = json as? [[String: Any]] {
        let users = jsonArray.flatMap {
            User(dict: $0)
        }
        users.count
        dump(users.first)
    }
}

I don't actually expect you to go through all this code in detail, but I included it here to make it obvious how verbose this method is.

The first 3 lines get the data, and I have force-unwrapped the URL and the Data which I would not do in a production app but which is OK while testing in a playground. Then there is a declaration of the Users struct with all its sub structs. Each one has a failable init that tries to parse the JSON dictionary and returns nil if the data doesn't match, by way of a lengthy set of guard statements. The basic layout of each struct is the same but it is very verbose. And as an extra step, the lat and lng properties need to be converted from Strings to Doubles.

I have to confess that it took quite come time to get this right ... lots of guard statements to check that the data can be converted to the required types which meant that any typos produced an empty array. The sub-structs have to be extracted from the JSON as Dictionaries and then initialised by themselves.

Decoding in Swift 4

So this works, and I get an array of Users objects. But it isn't pretty and it takes a lot of code to do the processing. So now I am going to move on to doing this in Swift 4. I am using Xcode 9.0 beta 6 (9M214v) so if you have a later version, you may need to adapt to any changes.

struct User: Codable {
    let id: Int
    let name: String
    let username: String
    let email: String
    let phone: String
    let website: String
    let address: Address
    let company: Company

    struct Address: Codable {
        let street: String
        let suite: String
        let city: String
        let zipcode: String
        let geo: Coordinates

        struct Coordinates: Codable {
            let lat: String
            let lng: String
        }
    }

    struct Company: Codable {
        let name: String
        let catchPhrase: String
        let bs: String
    }
}

let jsonDecoder = JSONDecoder()
let users = try? jsonDecoder.decode(Array<User>.self,
                                    from: jsonData)

Ignoring the complexities of converting latitude and longitude to Doubles, I get vastly simpler code. I declare all the structs as conforming to the Codable protocol and then I can remove all the init methods and just let JSONDecoder do its magic. I just have to tell it what data type to expect - in this case an Array of Users. I don't have to worry about the initial conversion of the JSON data to a Dictionary or looping through the elements using flatMap.

In the playground, I used a do...catch structure to check the result of the decode function, but I have used try? here to keep the code short.

Changing data types

The lat & lng coordinates are stored in the JSON as Strings, but need to be converted to Doubles for the Swift struct.

This requires a custom init method for the Coordinates struct to do the conversion from String to Double.

So here is the complete code for Swift 4 - again, if you don't want to create your own playground, you can use mine, this time looking at the Swift 4 JSON page:

import Foundation

let sampleDataAddress = "https://jsonplaceholder.typicode.com/users"
let url = URL(string: sampleDataAddress)!
let jsonData = try! Data(contentsOf: url)

struct User: Codable {
    let id: Int
    let name: String
    let username: String
    let email: String
    let phone: String
    let website: String
    let address: Address
    let company: Company

    struct Address: Codable {
        let street: String
        let suite: String
        let city: String
        let zipcode: String
        let geo: Coordinates

        struct Coordinates: Codable {
            let lat: Double
            let lng: Double

            init(from decoder: Decoder) throws {
                let values = try decoder.container(keyedBy: CodingKeys.self)
                let latString = try values.decode(String.self, forKey: .lat)
                let lngString = try values.decode(String.self, forKey: .lng)
                lat = Double(latString) ?? 0
                lng = Double(lngString) ?? 0
            }
        }
    }

    struct Company: Codable {
        let name: String
        let catchPhrase: String
        let bs: String
    }
}

let jsonDecoder = JSONDecoder()
let users = try? jsonDecoder.decode(Array<User>.self, from: jsonData)

users?.count
dump(users?.first)

For comparative purposes, I counted the lines of code in each, removing the common boiler plate of the top of each and the two lines for displaying the results in the playground. I also removed the blank lines which I always use a lot in my code for readability but which are not relevant when comparing code efficiency:

Version	Lines	Lines if lat & lng are Strings
Swift 3	95	93
Swift 4	35	28

Encoding

Encoding back to JSON is very similar. In the Swift 3 version, I would have written a method for each struct that created a Dictionary and then used JSONSerialization to convert the Dictionary back to JSON. This is very verbose and tedious to write so I am not going to bother to demonstrate it here.

But in Swift 4, this is even easier than decoding. Add this code to the end of your Swift 4 JSON playground or playground page:

if let users = users {
    let jsonEncoder = JSONEncoder()
    jsonEncoder.outputFormatting = .prettyPrinted

    if let backToJson = try? jsonEncoder.encode(users) {
        if let jsonString = String(data: backToJson, encoding: .utf8) {
            print(jsonString)
        }
    }
}

The JSONEncoder returns Data and I have converted that to a String for checking. I set JSONEncoder's outputFormatting property to .prettyPrinted get a more readable String.

Notice how the encoded data is not quite the same as I received because the lat & lng properties are now Doubles. In a production app, if I needed to be able to convert back to JSON, I probably would have left them as Strings so as to enable data transfer in both directions. I would add computed properties to the struct to convert these Strings to Doubles as I needed them.

Advanced Decoding

Now that we have the basics, I want to look at three more features: changing property names, date handling and allowing for nulls.

Changing Property Names

In these examples I used exactly the same names for the properties as were used in the JSON. In the Swift 3 version, it would have been easy to change the property names, since the data for each property was being extracted manually. In Swift 4, if you want the decoder to change names, you have to tell it what you want.

Make a new playground or playground page and replace the contents with this - or go to the Swift 4 Extras page on my playground:

import Foundation

let jsonString = """
{
"name1": "Jane",
"name2": "Smith"
}
"""
let jsonData = jsonString.data(using: .utf8)!

struct Person: Codable {
    let firstName: String
    let lastName: String
}

let jsonDecoder = JSONDecoder()
let person = try? jsonDecoder.decode(Person.self, from: jsonData)
dump(person)

This uses the new multi-line literals in Swift 4 to assemble the JSON string which is amazingly useful as it allows quotes to be embedded in the string without having to escape them. As you can see, the JSON property names are not very helpful, so I want to change them in my Person struct. At the moment, person is nil because I have not given the decoder any clues to help it translate the names. To do that, I have to add a CodingKeys enum to the Person struct and it tells the decoder what names in the JSON match up to what properties in the struct.

struct Person: Codable {
    let firstName: String
    let lastName: String

    enum CodingKeys: String, CodingKey {
        case firstName = "name1"
        case lastName = "name2"
    }
}

And that's all I have to do. Now the JSON is correctly converted to a Person. As an exercise, use JSONEncoder to get back to JSON from the Person. You will see that the JSON correctly names the elements using "name1" and "name2".

Date Handling

Next let's look at dates - add this code to the playground:

let jsonString2 = """
{
"name": "My New Project",
"created": "2017-06-18T06:28:25Z"
}
"""
let jsonData2 = jsonString2.data(using: .utf8)!

struct Project: Codable {
    let name: String
    let created: Date
}

let jsonDecoder2 = JSONDecoder()
let project = try? jsonDecoder2.decode(Project.self, from: jsonData2)

dump(project)

When this runs, project is nil because the decoder has no idea how to get from the String "2017-06-18T06:28:25Z" to a Date object. Add this line after creating jsonDecoder2:

jsonDecoder2.dateDecodingStrategy = .iso8601

Now the date can be converted and an instance of the Project struct will be created.

And to get back to the JSON, converting the Date back to ISO8601 format:

let jsonEncoder = JSONEncoder()
jsonEncoder.dateEncodingStrategy = .iso8601

if let backToJson = try? jsonEncoder.encode(project) {
    if let jsonString = String(data: backToJson, encoding: .utf8) {
        print(jsonString)
    }
}

Allowing For Nulls

JSON data will often include null where there is no value for a particular property name. When using JSONDecoder or JSONEncoder, this can be allowed for by using Optionals. If you are not clear about Optionals, have a look at my previous article: Learning Swift - Optionals.

The crucial step is to declare the properties of the Swift object as optionals if you think they could get a null value.

struct Role: Codable {
    let firstName: String
    let lastName: String
    let nickName: String?
}

let jsonStringWithNulls = """
[
    {
        "firstName": "Sally",
        "lastName": "Sparrow",
        "nickName": null
    },
    {
        "firstName": "Doctor",
        "lastName": "Who",
        "nickName": "The Doctor"
    }
]
"""
let jsonDataWithNulls = jsonStringWithNulls.data(using: .utf8)!

let jsonDecoder3 = JSONDecoder()
let roles = try? jsonDecoder3.decode(Array<Role>.self, from: jsonDataWithNulls)
dump(roles)

In this example (which you can find in the Swift 4 Extras page on my playground), I have declared a struct called Role with 3 String properties. The 3rd String - nickName - is an Optional so it may be a String or it may be nil.

The JSON contains 2 elements - one has a nickName value and the other has it as null. Because the matching property in the Swift struct is an optional, this works as expected and the nickName property for Sally Sparrow is decoded as nil. If you remove the question mark to make nickName non-optional, the decoding will fail.

Going back to JSON from a Swift object with optionals works much the same except that it does not specifically mark items as null, it just leaves them out.

let jsonEncoder2 = JSONEncoder()
jsonEncoder2.outputFormatting = .prettyPrinted

if let backToJsonWithNulls = try? jsonEncoder2.encode(roles) {
    if let jsonString = String(data: backToJsonWithNulls, encoding: .utf8) {
        print(jsonString)
    }
}

Property Lists

As well as JSONDecoder and JSONEncoder, Swift 4 has introduced PropertyListDecoder and PropertyListEncoder, so let's take a quick look at that.

Add this to the bottom of the last playground as it uses the Project struct and data:

let plistEncoder = PropertyListEncoder()
plistEncoder.outputFormat = .xml
if let plist = try? plistEncoder.encode(project) {
    if let plistString = String(data: plist, encoding: .utf8) {
        print(plistString)
    }

    let plistDecoder = PropertyListDecoder()
    let project2 = try? plistDecoder.decode(Project.self, from: plist)

    dump(project2)
}

I don't see this is being quite as useful as the JSON Encoding & Decoding, but I mention it here for completeness.

Codable

In all the Swift 4 examples above, I set the structs to conform to Codable. Reading Apple's docs, I see that Codable is actually a typealias referring to 2 separate protocols:

typealias Codable = Decodable & Encodable

If you only need to convert data one way, it will be more efficient to set your struct or class as confirming to only one of these protocols. For example, if you download JSON data from an API but never need to send it back, just conform to Decodable to transform the JSON data into your data structure.

Much more information can be found in the Apple documentation.

Posting from my new iPad

2017-06-17T00:00:00Z

Last week I got a 10.5” iPad Pro. I have had an iPad ever since the original release, but I have to confess to mainly using it for content consumption rather than creation. Since I am usually close to a Mac anyway, there didn’t seem a lot of point. But now that iOS 11 is really addressing the issue of making the iPad a "pro" device, I decided to give it a try.

So here I am, sitting in an armchair with my iPad on my lap, writing this post and working out the details as I go. Any typos are due to the cat trying to compete with the iPad for space on my lap!

iPad

As already mentioned, I have a new iPad Pro. I also have an Apple Pencil which I use for taking notes. I do not have a keyboard, so I am using the on-screen keyboard right now.

I don’t usually install beta versions of operating systems, but iOS 11 is a huge part of making the iPad more professional, so I have installed it. As you would expect, there are a few issues (apps quitting, layout issues especially when rotating) but so far I am loving it.

Writing

My site is published on GitHub Pages using Jekyll with all the posts and pages written in Markdown. One key feature is that every post or page requires a chunk of "front matter" that must be formatted correctly for the Jekyll parser to interpret it and create the static content. After a bit of research, it looked like Editorial was going to be the best option for an editor app. I moved my site files to Dropbox, linked my Dropbox account to Editorial and I was ready to start writing.

I didn’t want to create the front matter manually for each post. On my Mac I have a text expander snippet that handles that but copying from Matt Gemell’s post on the topic, I created an Editorial workflow to create a new post. As a side-note, Matt has a series of posts on using an iPad which I have found very useful and inspirational.

Text entry and editing is a task that I have always felt was too difficult in iOS, particularly when it came to selecting text and moving the cursor. However there are now several improvements. As with iOS 10, a two-fingered press on the keyboard transforms it into a trackpad for moving the cursor. If you already have text selected, this moves the selection handles. The new iOS 11 keyboard has a really nice feature for entering non-alphabetic characters. The keys now show a small grey character above the main character. Drag down on the key to move the small character into the main key and type it. For example, drag down on the h key to type (.

Editorial has its own editing helpers. There is an additional toolbar above the keyboard with a tab key as well as frequently used Markdown modifiers. And swiping across this toolbar moves the cursor. This is a much slower move than when using the keyboard as a trackpad so might be better for more precise movements.

Adding Links:

I have referenced a few sites now, so I guess it is time to work out how to link to them. I always use Markdown’s referenced link method, with the links collected at the foot of the document, so that is what I plan to do here. To set text as a link, I selected it and used the Editorial toolbar to type an opening square bracket which surrounded the selection in square brackets. Then I moved the cursor to after the closing bracket and typed another opening square bracket. This auto-closed and I was able to type a number which will be the reference.

Next step is to find the relevant URLs - drag & drop with multi-tasking to the rescue! Swipe up from the bottom of the screen to see the new Dock. This also makes the keyboard disappear. Hold down on the Safari icon until you grab it, then drag it up into the Editorial window. Now it is open as an overlay.

At this point, I have several options:

Swiping from the left or right of the overlay window lets me position it to the right or left of the screen, still as an overlay.
Dragging from the bar at the top of the overlap allows me to convert to split screen mode, and I can then drag the divider to adjust the ratios.
Swiping all the way to the right disappears the overlay, but swiping back from the right edge returns it. Since I want to copy and paste some links, this looks like the best option right now.

This swiping conflicts slightly with Editorial's swiping from the side to see a preview. Swipe from off the edge for the overlap and from well inside the edge for preview.

And here my plans come crashing down. I can drag from Safari's address bar into the Editorial document, but the drop doesn’t take. I guess I need an update to Editorial for this to work. But I can still use the old style copy and paste to get the links.

Images

So now I have my links, but I want to insert a few images. I used iOS 11’s new screen shot abilities. Press the usual home button & power button combination to take a screen shot and it appears as a small picture in the bottom left of the screen. Tap it to start editing: markup, crop etc. Then I used the sharing button to save the picture to Dropbox, putting it inside the images folder in my web site folder.

I want to insert an image link but I have just worked out that I saved this Markdown file in the root folder instead of the _posts folder. I can’t see a way to move it from inside Editorial, so I will swap to the Dropbox app to move the file - be right back... (I see now how I could have done this in Editorial.)

Ok, this file is in the right place and the images are in the right folder, so how to add an image link? Checking back at previous posts, I see that the format I use for inserting an image is: ![Alt text][#] and the reference at the foot of the page is like[#]: /images/2017/image_name.jpg but I don’t want to have to remember that every time, so I think it is time for some snippets. Tapping the lightning icon on the Editorial keyboard lets me edit and create snippets, so I have made one for the image link and one for the image reference. Time to scroll back up the page and try them out.

I opened the Dropbox app in an overlay so that I could find the file names for the images I just saved, then I created the links. The images don’t appear in the preview but that is expected because Jekyll has not parsed the addresses. Looking at the information about the images in Dropbox, I see that they are far too big. I need a way to resize them. The screen shot editor doesn’t have a way to resize apart from cropping, at least not in this beta.

Workflow is another Pro level app that I have never really used, but it seems that it might do the job. I tried a few workflows to edit the size of an image from a Dropbox file and save it back, but they although they appeared to complete, the image file remained the same size. So then I went to the Workflow Gallery and found a workflow called Quick Resize Screenshot. When editing a screen shot, I can use the sharing button to run the workflow and then I can save the smaller images to Dropbox for use in the page. For the large images that I have already saved, I will resize them on my Mac before publishing.

Publishing

This brings me to the final step - publishing the changes to GitHub Pages. Jekyll is a system that creates static web pages from the Markdown and other files. on my Mac, I run the jekyll build command in Terminal and the pages are created or re-generated as required. Then I use git to commit my changes and push them to GitHub which serves them.

There appear to be Editorial workflows written in Python that use the GitHub APIs to upload files, but this wouldn’t work well for me. Because of the structure of my site, many different pages need to be re-generated when I publish a new post, so I will keep the publishing phase on my Mac. However there is no need to make it any more difficult than necessary, so I have written a shell script to do the work.

The script takes an optional commit message parameter, builds the site, commits changes and pushes then to GitHub. I have only tested this when no files had changed, so this post will be the first real test. Shell scripting is outside my comfort zone, so we will have to see how that works.

Summary

So now I have a workflow on my iPad that uses Editorial, Dropbox and Workflow. This allows me to do 100% of the writing task. Then I have a single shell script on my Mac that does the publishing part. I can edit and create posts anywhere. I can easily use split screen or screen overlays to add links. iOS 11 makes creating and annotating screen shots very easy.

I am hoping for an update to Editorial that will allow it to accept drag & drop. The ability to resize screen shots before saving them would also be really useful.

Sometimes my posts are more code-based and need access to Xcode and in those cases, I will stick to my Mac, especially considering Xcode’s new ability to connect directly to GitHub which will make it great for publishing Swift playgrounds. But for more narrative-style posts like this one, I will use my iPad and see how I can improve my workflow and expand my tool set.

It feels good to be using the iPad as a content creation device at last.

Extra Notes from a Mac:

Since this was my first time writing a blog post using an iPad and this workflow, I decided that I should test the results before publishing, so I switched back to the Mac and in Terminal, ran jekyll serve so that I could see the results. There were a few issues mainly to do with the formatting of the front matter. The three dashes at the top & bottom of the front matter had become munged into an emdash plus a dash, so that didn’t work. Jekyll is also fussy about the spaces in the tag & summary lines and it doesn't handle non-alphanumerics in the summary text.

I also used the Mac to shrink some of the images that I had saved before working out how to reduce the size of screen shots.

So I need to check the structure of the front matter workflow before next time, but this post is ready to go with only minor editing on the Mac side. Now to test my shell script...

JSON Feed for TrozWare

2017-05-20T00:00:00Z

jsonfeed.org has announced a new format for web site feeds, designed as an alternative to RSS. TrozWare has had an XML RSS feed for years, but I don't think anyone ever uses it (I certainly don't), so today I have replaced it with a JSON feed, which you can access through the button at the top of every page.

I am sure many JSON Feed viewers will appear soon, but the only one I know about so far is at http://json-feed-viewer.herokuapp.com. As soon as this update to my site goes live, I will apply to have TrozWare added to the list of sites on this page. Meanwhile, you can paste in the URL: https://troz.net/feed.json.

This site is constructed using Jekyll, so I am very grateful to Niclas Darville for his very easy to follow guide. However it is still well worth reading through the official specs to see what else you want to add, or if you want to remove anything. I had to tweak a few settings to make it work for my configuration, and I added some more objects, but Niclas got me off to a flying start.

Two things to watch out for:

Make sure your feed is producing valid JSON (I had an extra comma that was breaking it...).
As third-party apps & sites may be displaying your content, you need to make sure that you are not using relative URLs for images and internal links. I was using relative image URLs like /images/WorkHelp1.png but that showed a broken link in the feed viewer, so I have changed all such links to /images/WorkHelp1.png. Hopefully that will work correctly on my local test server as well as when published.

JSON Feed offers a nice icon which I would have liked to use, but I could not work out a way to make it play nicely with the existing icons on my pages which all use Font Awesome icons. So I ended up just using the existing Feed icon. Hopefully Font Awesome will soon add a JSON Feed icon to their already impressive list.

If anyone still wants to use the RSS feed, it is no longer linked to the buttons at the top of the pages, but you can access it manually.

Blackmail Marketing

2017-03-08T00:00:00Z

I use my iPad to play games as a form of relaxation. Nearly all the games I play are puzzle apps with levels that can be played in a few minutes. Nearly all of them are free to install. So how do they make money?

Now I would be the last person you should consult about marketing but it has always seemed to me that the best way to market your product is to convince people that it offers something they want so that they are prepared to pay for it.

This is not the currently favored approach for mobile apps - at least certainly not for games. No, the theory at the moment is to cause so much frustration and annoyance that people give you money to make it stop. Blackmail marketing.

A frequently used method is showing ads, sometimes just banner ads but more often full screen video ads that run for up to 30 seconds. If you interrupt the ad, you don't get the reward.

Every goal reached triggers an ad.
Quitting and resuming the app triggers an ad.
Wanting to play another level triggers an ad.

The theory is that you get so annoyed with this that you pay money to disable the ads.

The other common tactic is the delay. A tower defence game needs you to build a tower? OK, that will take 12 hours real time and you can't proceed until it's finished. Or you can spend 12 gems which are sold as an in-app purchase. Maybe you can only play 3 levels and then you need to recharge: again, pay up or wait. You keep dying on that level? You're out of lives. Pay up or wait until tomorrow. These delays are completely artificial. They have nothing to do with game play but are solely designed to infuriate you enough to get you to pay.

So when, and perhaps more importantly why, did mobile app marketing become so negative? What happened to making your customers happy? Do unhappy customers spend more?

Financially, it appears that irritating your users is a successful strategy. Nearly all the top grossing games in the App Store are "free to play" in that the initial download costs nothing. But these big studios are raking in enormous sums of money, so many people are persuaded to spend significant money by these infuriating schemes.

A large part of this must be due to the various App Stores driving prices to the bottom. Gone are the days when the price of a mobile app was other than risible. So app developers have four choices:

Do it as a hobby or learning exercise.
Distribute apps as a form of self–promotion for other work.
Work for someone who pays you a real wage to develop apps.
Join the blackmailers.

So how does this relate to indy developers like me? I care about my users and want them to be happy.

I have tried several different approaches to app distribution:

Totally free gets by far the most downloads but is economically ridiculous unless the app adds value to your business in some other way.
A tip jar gets you nothing.
In-app purchases (in my limited experience) make less than selling the app up-front for a small price.
Banner ads with no method of forcing people to watch them generate almost no revenue.

So that leaves me with where I am today - selling apps for a few dollars and nothing more. Happily, I have found that Mac users are more prepared to pay a few dollars for an app, so I have shut down many of my iOS apps and am concentrating on the Mac app market.

Am I letting my principles stand in the way of mobile app profits? Should I just join the gang and start blackmailing my customers? If so, what form should this take?

At the moment, I am considering banner ads on the screen with an in-app purchase to disable them entirely. I read a suggestion for a less invasive method of doing this by creating your own ads for your other apps. This might be what I end up doing.

I would welcome any suggestions, advice or comments. Please join the discussion below or contact me using one of the links at the top of the page.

NCSS 2017

2017-01-06T00:00:00Z

I gave a Masterclass on Swift at the NCSS Summer School 2017 in Sydney on 8th January 2017. This post contains useful links for use during and after my class.

IBM Swift Sandbox

Sandbox Code Samples

Contact Details:

Useful Links:

Looking for beta testers

2016-11-17T00:00:00Z

I am looking for beta testers for my latest Mac app: Work.

Work is a project organizer app for developers, designers, students or any professional who works with multiple projects involving files & folders, web pages, email addresses and lists of tasks. Click the link above for more information and help for getting started.

Work requires macOS 10.12 or OS X 10.11.

If you would like to test this app, please contact me, giving details of your Mac and operating system. The easiest way to do this is to select About This Mac in the Apple menu and send me a screen shot of the window that appears.

All beta testers will receive a free license to Work when it is released. If you report a legitimate bug or provide valuable feed-back, you will also receive a free license to your choice of one of my other apps.

Another Man Reader Update...

2016-11-05T00:00:00Z

A quick update to Man Reader to version 1.8 is now available through the Mac App Store.

The main reason for this version was that Man Reader was not previously detecting man pages installed by third-party IDEs in the Applications folder. There was also an issue with Man Reader failing to display the text of the previously selected man page on app launch.

More complete search for man pages, including in third-party IDEs.
Fix for glitch when displaying previously selected page on launch.

Man Reader Update

2016-10-12T00:00:00Z

Man Reader has just been updated to version 1.7 and is available through the Mac App Store.

The main reason for this update was to make the app work well with macOS Sierra, as I found that version 1.6 was sometimes crashing on launch. While doing this, the update was rejected by the App Store reviewers because it crashed on OS X 10.10. Since I no longer have a Mac running 10.10, I decided to set the minimum supported system version to OS X 10.11. If you need support for older versions, you should still be able to download version 1.6 which will work back to 10.7.

I also took the opportunity to fix some graphical issues, dealing with different color schemes:

The man page list now shows alternating colors even when not using the default scheme.
When scrolling the man pages past the top or the bottom with a non-white background, you should no longer see white blocks top & bottom.

Podcasting

2016-10-11T00:00:00Z

I have recently started what I hope will be a weekly podcast with my friend and colleague, Jerry Daniels. Each podcast will be about 30 minutes in length.

We will discuss Macs, iPhones, iPads, macOS, iOS, programming and anything tech-related that we find interesting. I hope you will find it entertaining and informative, so please join us.

We are using ZCast which has an iPhone app that makes it super easy to get together and record our chats. It doesn't allow any post-processing, but really lowers the barrier to entry into the world of podcasting.

If you get the ZCast app for iPhone, go to the ZCasters tab and search for "Trozware" or "Jerry Daniels" to find all our podcasts. Or use these links to listen in your browser.

Since the first one was recorded using my name instead of my @trozware Twitter account, I will embed it here as it will not show up if you search for "Trozware".

Dice Pass Updated

2016-09-17T00:00:00Z

Dice Pass 1.1 is now available from the Mac App Store.

What does Dice Pass do?

Dice Pass is a utility to app to generate random passphrases based on the Diceware system. Diceware uses a table of pre-defined words, each assigned a 5 digit code number containing the digits 1 to 6. The official way to generate a phrase is to roll 5 dice for each word you want in your passphrase and then consult the words table to find the matching word.

The resulting phrase uses real words or common abbreviations so it is easier to remember than a random collection of characters. At the same time, the random selection of words makes the generated passphrase much more secure as it avoids the human tendency to pick words with personal meaning.

Dice Pass allows you to select the number of words in your passphrase, re-generate the entire passphrase any time, re-roll a single word in your passphrase or set the dice rolls manually for maximum security and randomness.

What's New in Version 1.1:

You can now select from three word lists in the Word Lists menu:

original Diceware list
Beale list (fewer Americanisms and obscure words)
Diceware 8k list (a list of words that is a whole power of two in length)

You can also import your own word list if you prefer.

Dice Pass 1.1 is compatible with macOS Sierra.

How much work does Icon Builder save you?

2016-09-17T00:00:00Z

Icon Builder is a Mac app that takes a single image file and creates all the different image sizes that you need to make a set of icons for your app: Mac, iPhone, iPad, iOS Universal or Apple Watch.

Version 4, released 16 September 2016 is available through the Mac App Store.

What's New in Version 4:

Added support for iMessage apps and Sticker Pack apps.
Added support for creating Mac .icns files.
Better removal of alpha channel for Apple Watch icons.
Clearer usage instructions in ReadMe files.
iTunes Artwork folders will no longer be over-written with the latest image files.
Supports macOS Sierra and Xcode 8

While working on version 4 and accommodating all these new icon sets (and wishing I had the time to re-write the app in Swift...), I counted up all the icon files that Icon Builder makes for each app type:

App Type	Number of Icons
Mac	10
iPhone	8
iPhone supporting pre iOS 7	11
iPad	9
iPad supporting pre iOS 7	13
iOS Universal	14
iOS Universal supporting pre iOS 7	20
Apple Watch (also requires iOS app icons)	8
Sticker Pack app	11
iMessages app	14
iMessages app Messages extension	9

So as you can see, Icon Builder is doing a lot of work for you. It also names all the icon files using the expected format, stores them in an concept folder, creates the JSON file that identifies them all to Xcode and optionally installs them in your Xcode project automatically. That’s a lot of value for dragging in an icon and clicking a button!

So next time your designer sends you the twentieth tweaked icon for the day, don't get mad. Just drop it into Icon Builder and sit back while it does all the work. (No need to tell the designer that...)

Retiring old apps

2016-09-15T00:00:00Z

With the release of iOS 10 and the need to update iOS apps to suit, I have decided it is time to retire some of my lesser-performing apps as it is not worth the effort required to maintain them.

At the moment, the following iOS apps are no longer available:

A Knight's Move
Dice Pass
Pic-a-POD
Quick Score - Tennis

For the first three listed there, the Mac versions are still available:

If you bought any of these apps and would like a promo code for the Mac version, send me a screen shot of the app running on your iPhone or iPad and I will send you a code.

Man Reader updated to 1.6

2016-07-16T00:00:00Z

Man Reader has been updated to version 1.6 with the permissions needed for finding all available man pages and a fix for search terms being over-written after a background update.

Man Reader 1.6 is now available through the Mac App Store.

Change Log:

Permissions fix when searching for available man pages.
Fixed error with new search term being over-written.
Sand-boxed version now works just as well as the non-sand-boxed so please switch back to this version.

This version fixes a problem with sand-boxing permissions potentially not allowing access to all the installed man pages on your system. This should now be fixed but if you discover any man pages that are available through Terminal but not through Man Read, please email me the details and help me make Man Reader better.

There was also an issue with a previous search being restored after a background update, even if a new search term had been entered. This has been fixed.

If you previously had downloaded the Man Reader (no SB) version of the app from this site, please revert to the App Store version which you would have needed to have bought in order to use the downloaded app. If you bought the app from Paddle, contact me and I will transfer you to the App Store version. Neither of these other versions will be supported or updated any more.

Dice Pass Mac Update

2016-07-03T00:00:00Z

I recently got an email from someone who had purchased Dice Pass for Mac from the Mac App Store but had been unable to get it to run. This person was using OS X 10.9.3.

I checked the App Store specifications and it showed that 10.9 was the minimum system requirement, so it should have worked. But going back to my Xcode project, I found that it was set to a minimum of OS X 10.10.

I tried to re-compile for OS X 10.9 but this failed as the app uses several features that are not available prior to 10.10.

The minimum system version as displayed in the App Store is supposedly deduced automatically by the App Store servers from the app's binary. Somehow this was incorrect in the App Store, so some people may have bought that app and found that it did not work despite them having what was listed as a compatible system.

If you bought Dice Pass for OS X 10.9 and are unable to run it, I have two possible solutions for you:

Upgrade your operating system to at least 10.10.
Ask Apple for a refund since it was their error that caused you to buy an app that you cannot run.

I have updated the app in the App Store changing nothing but the version number and it is now showing the correct minimum system requirement. My apologies if you have been inconvenienced by this error.

Learning Swift - Sets

2016-05-28T00:00:00Z

Sets are the forgotten collection type in many languages, including Swift. I think most developers use Arrays without really considering the advantages of using a Set but they have some amazingly useful features that should make them a part of any programmer's toolkit.

If you want to follow along with a playground, you can download it here.

What is a Set?

A Set is an un-ordered collection of unique items. That's it - nothing more than that. So it is very similar to an Array, but it is not indexed like an Array and it cannot contain more than one of each entry.

Creating a Set

Creating a Set is as easy as creating an Array:

var myArray = ["dog", "cat", "hamster", "dog"]
var mySet: Set = ["dog", "cat", "hamster", "dog"]

If you are running these commands in a playground, notice that the differences between the 2 results:

["dog", "cat", "hamster", "dog"]    // myArray
{"hamster", "cat", "dog"}           // mySet

The Array is shown wrapped in square brackets, the Set is shown wrapped in curly braces. This is just a visual clue and doesn't really mean anything. You cannot initialize a set using curly braces.
All the supplied elements of the Array are listed, but the Set has removed the duplicate "dog" element. This did not cause an error or warning, it just happened quietly.

When initializing a Set, you must add : Set to distinguish it from an array initialization. In the example above, I did not specify the data type of the elements in the Set as the Swift compiler was able to infer this from the contents. But if initializing an empty array, the data type must be specified. To check how to do this, I option-clicked on mySet to see what the Swift compiler thought it was.

So mySet is actually Set<String>. This means that to create an empty Set, you need to use something like this:

var emptySetOfStrings: Set<String> = [] var
emptySetOfInts: Set<Int> = []

Adding and removing elements

If you have been using an Array to store unique values, then you have probably written code like this:

if !myArray.contains("cat") {
  myArray.append("cat")
}

With Sets, you don't have to care. Just use insert() and let the Set work out whether to add the item or not.

mySet.insert("goldfish")
// goldfish added: {"hamster", "cat", "dog", "goldfish"}
mySet.insert("dog")
// dog already there: {"hamster", "cat", "dog", "goldfish"}

Removing elements is also easier than in Arrays. For an Array, you first have to find the index of the element and remove it by index:

// myArray.remove("hamster") // will not compile
if let index = myArray.index(of: "hamster") {
  myArray.remove(at: index)
}

But in a Set, you can remove any element easily and trying to remove an element that doesn't exist will fail without an error.

mySet.remove("hamster")   // returns "hamster"
mySet.remove("canary")    // returns nil

Converting between Sets and Arrays

Sometimes you need to be able to switch between the two. My most recent example was when I wanted to store data from a Set in a plist. Sets are not property list types but Arrays are, so I converted the Set to an Array before storing it in the plist. When reading the data in from the plist, I converted it back to a Set.

let myArrayAsSet = Set(myArray)
let mySetAsArray = Array(mySet)

One useful side-effect of these easy conversions is the ability to 'unique' an Array in a single line. This may be inefficient for large arrays, but works very well for small ones. Just be careful if the order of the elements is important as you cannot guarantee the order of elements in a Set.

let myArrayUniqued = Array(Set(myArray))
// ["cat", "dog"]

Iterating over elements in a Set

As with an Array, you can use a for element in set structure, or you can use enumerated(). But you cannot subscript a Set.

for animal in mySet {
  print(animal)
}

for (index, animal) in mySet.enumerated() {
  print("\(index) = \(animal)")
}

// will not compile
// for index in 0 ..< mySet.count {
//   print("\(index) = \(mySet[index])")
// }

Where Sets get really interesting

Remember in school when you learnt about Venn diagrams with pretty interlocking circles? Sets can do the same things, although you will have to do your own pretty drawings :-)

let set1: Set = ["dog", "cat", "pig"]
let set2: Set = ["cow", "horse", "pig"]

let intersect = set1.intersection(set2)
// {"pig"}

let subtract = set1.subtracting(set2)
// {"cat", "dog"}

let union = set1.union(set2)
// {"pig", "cat", "dog", "cow" "horse"}

let xor = set1.symmetricDifference(set2)
// {"cat", "dog", "cow", "horse"}

In the code example above, we have two Sets of animals, with one animal in common.

intersection() lists the elements in common.
subtracting() lists the elements in one Set after removing all elements that are in the other.
union() joins all the elements without duplicates.
symmetricDifference() lists the elements that are in one or other of the Sets but not in both. (Swift 3 renamed this function from exclusiveOr())

Here is my best attempt at a pretty drawing to show how these go together:

The next fun trick is working out sub-sets, super-sets and disjoint sets.

let set1: Set = ["dog", "cat", "pig"]
let set2: Set = ["cow", "horse", "pig"]

let smallSet: Set = ["pig", "cow"]

smallSet.isSubset(of: set1)   // false
smallSet.isSubset(of: set2)   // true

smallSet is not a subset of set1 because it contains an element that is not in set1. smallSet is a subset of set2 because every element in smallSet is also in set2.

If you want to get technical, a Set should not be considered a subset of an identical Set. The default isSubset(of:) allows this, but you can use isStrictSubset(of:) if you prefer.

set1.isSubset(of: set1)         // true
set1.isStrictSubset(of: set1)   // false

Superset works just the same but in reverse so the diagram above explains it too:

let set1: Set = ["dog", "cat", "pig"]
let set2: Set = ["cow", "horse", "pig"]

let smallSet: Set = ["pig", "cow"]

set1.isSuperset(of: smallSet)       // false
set2.isSuperset(of: smallSet)       // true

set1.isSuperset(of: set1)           // true
set1.isStrictSuperset(of: set1)     // false

set1 is not a superset of smallSet because it does not contain every element in smallSet. set2 is a superset of smallSet because every element in smallSet is also in set2.

The isSuperset(of:) and isStrictSuperset(of:) functions allow or reject identical sets.

The final comparison tool that might be useful is isDisjoint(with:) which returns true only if the two Sets have no elements in common i.e. if there is no overlap in the circles.

let set1: Set = ["dog", "cat", "pig"]
let set2: Set = ["cow", "horse", "pig"]

let otherSet: Set = ["duck", "chicken"]

set1.isDisjoint(with: set2)       // false
set1.isDisjoint(with: otherSet)   // true

"pig" occurs in both set1 and set2 so they are not disjoint. otherSet and set1 have no matching entries so they are disjoint.

When should you use a Set?

If you want the elements to be unique.
If you want easy methods of comparing the contents of different collections.
If you want to be able to remove elements easily.

When should you not use a Set?

If you need the collection to be able to hold multiples of an element.
If the order of the collection is important.

For more details on Sets, check out SwiftDoc.org.

19th Hole Golf Scorer 3.1

2016-05-07T00:00:00Z

One of the problems with using 19th Hole on the Apple Watch is making the app show every time you raise your wrist. My solution to this was to go into Settings (either on my iPhone through the Watch app, or directly on the watch) and change it to "Resume Last Activity" on wrist raise. This worked fine but as I usually prefer the watch face to show on wrist raise, I had to keep setting and re-setting this which was a pain.

But last week I noticed the fine print when changing this setting. In this screen shot from the Watch app on my iPhone, you can see that "session-based apps" and "some third-party workout apps" will over-ride the "Show Watch Face" setting.

I started to research this and found that if an app starts a "workout session", then it will become the active app until the session is ended or some other app starts a session. So I got to work and added a workout session to the 19th Hole's Apple Watch app.

When you start scoring a round on the Apple Watch, you will see this dialog asking if you would like to start a workout:

The workout will be stopped automatically when you have scored the last hole. You can also use a force-press on the scoring screen to turn the workout off or on at any time.

This should make the app much more usable as an Apple Watch app, so happy golfing :-)

My Year With Apple Watch

2016-04-28T00:00:00Z

As the Apple Watch hits its first birthday, there seems to be in increasing number of bloggers complaining about it. One (which I refuse to link to) titled "My Year of Hell With the Apple Watch". I think the article has since been re-published with a slightly less inflammatory title, but really! Did somebody rivet the watch to his wrist? If it was so awful, why not just stop using it?

I am a watch nerd and have always loved watches and having one on me. I liked watches with features and even had a calculator watch at one point although as a woman with skinny wrists, I found it constantly annoying that watch makers put all the gadgets into man-sized watches so I was left with the choice of no features or a watch that looked stupidly large on my wrist.

A few years ago I stopped wearing a watch. I can't remember now why I did it - maybe my watch strap broke and it wasn't important enough to get a new one. I always had my iPhone to give me the time.

But I ordered three Apple Watches as soon as they were available and myself, husband and eldest son have been using them ever since.

Here are what I consider to be the best features of the Apple Watch:

Accuracy: It is a fantastically accurate time-piece. Not enough people give this credit, but we have always been used to clocks and watches that were inherently inaccurate. Having a device on my wrist that I know to be perfectly accurate is an amazing thing.
Notifications: this takes a bit of work to get right and with every new app, you need to assess whether to have its notifications appear on your wrist. But the wonderful thing is knowing that you haven't missed anything and being able to glance at your wrist when a notification arrives and tell - unobtrusively - whether this is something that needs immediate attention. And the ability to respond instantly to messages and emails with just a couple of taps is amazingly useful.
Customisable watch faces: depending on what I am doing, I need quick access to different pieces of information. When travelling, I can set up a watch face with multiple time zones. When working, I need a timer. When on holiday, I prefer one of the more relaxing but less detailed watch faces.
Activity: I am not the world's most active person so I find the three rings to be a really good motivator. In fact I just had to stop typing and run up & down the stairs to get another notch to the blue ring. The goals are not out of my reach, so I like trying to fill in the rings every day.
Voice commands: being able to send a text message completely by voice when driving or when my hands are busy is fantastic. Starting a timer, doing unit conversions and navigating are things I do frequently by voice.
Excellent battery life: I started off having the battery life complication always visible, but it very quickly became apparent that this was unnecessary. Right now I have been wearing the watch for about 11 hours and the battery is at 74%. And charging is so fast that if I did run it down, a 30 minute charge would get me through most of a day.
The Milanese Loop: best watch band ever.

There are other good features, but I think those are my favourites.

So what don't I like?

Third-party apps are still a problem. I know. I have published three myself and sometimes they just doesn't happen. However this appears to vary a lot. Some people say they can never get apps to run, even Apple's apps. Others say they work but with a long delay. My watch seems to be better than the average but it is still an issue.
Sketches don't always get through or can take ages. We thought it would be a lot of fun to send each other little sketches and so it is, despite our total lack of any artistic skills. But it loses a bit of impact when you have to send a message 20 minutes later asking if the sketch has arrived.
The exercise tracking seems to be a bit erratic. If my husband and I go for a walk together, he comes back with 25 minutes of exercise and I only have 7 minutes. Am I not going fast enough? Are my arms not swinging enough? If it is very hot and my wrist gets sweaty, I seem to get better numbers - is this because my heart is beating faster or the capillaries closer to the surface have expanded? Or is the watch picking up a better signal that way? Either way, I still like the activity circles, but the green ring frustrates me a bit.

And what would I like to see in Watch 2 / watchOS 3?

Some sort of always-on display of the time.
A speaker to allow Siri to talk back to me and to play audio.
FaceTime audio calls.
Better support for third-party apps - perhaps open up some private APIs?
Allow developers to create watch faces or apps that told the time.
Allow developers to say that an app should stay as the frontmost app once opened.

Will I buy Watch 2?

At this stage I would say no. We bought the bottom-of-the-line Sport models because with version 1.0 of anything, you don't want to spend so much that upgrading is ruled out. However these watches are still going great and a lot of the improvements I am looking for will be in software not hardware.

But 14 months ago, I was waiting for Apple to announce the iWatch as we all thought it would be called, and saying that I didn't think I would get one. The feature list convinced me and I have been delighted with it. So if Watch 2 comes up with some killer feature that matters to me, then I might have to re-consider...

How To Confuse TestFlight

2016-04-24T00:00:00Z

I ran into an unusual problem when testing my latest app: "What Is My Speed?". It is now available from the iTunes App Store, but getting there was a struggle.

TL;DR

Xcode is terrible at renaming projects, so it is a really good idea to have worked out your app's name before starting. I would even recommend creating an app ID in your Apple Developer account and registering the app name in iTunes Connect. Only once you get to iTunes Connect will the name be checked for uniqueness. Searching the App Stores is not enough as it does not cover un-released apps or apps that are not available in your country.

So I set up my app. I was hoping for "What's My Speed?" but was happy with "What Is My Speed?".

Next step was to create the project in Xcode which I did using the app name and manually entering the bundle identifier that I had registered at Apple Developer. Xcode accepted the name without any warnings and created the default targets using that name.

In the default unit testing file, the module was defined like this:

@testable import What*Is_My_Speed*

which made me think that Xcode was quite happy to have parsed the app name as required to replace any unwanted characters to suit.

The app was built, passed all unit tests, profiled, analyzed, tested on real devices as well as the simulators and uploaded to TestFlight.

BARRRPPPP!

What?

(I forgot to take a screenshot but found a similar one online. Thanks Simple Techs)

I have had experience with TestFlight's oddities in the past, so I incremented the build number and tried again, thinking that maybe there had been a processing issue. Same result.

This started a very frustrating 24 hours as I ran through all the possibilities I could think of or find suggested on the net. Due to disastrous Australian internet speeds, especially uploads, each attempt took from 40 - 120 minutes. About 5 minutes to implement the next idea, 25 minutes upload time, then the rest waiting for Apple to process the app so I could try again.

Here is what I tried:

Uploaded a fresh build.
Removed Bitcode.
Fixed the code signing identity which was set to iOS Developer for some reason.
Manually specified the provisioning profiles for all three components (iPhone app, WatchKit app, WatchKit Extension).
Manually selected the code signing identity for the provisioning profiles.
Uploaded using Application Loader instead of Xcode.
Removed third-party framework.
Removed WatchKit app.
Revoked my distribution profile, re-created it and updated all provisioning profiles.
Created a completely blank project with same app name and bundle identifier.

As you can see from this list, I thought it was a code signing or profile error. Using Apple Configurator 2 (the modern version of iPhone Configuration Utility), I was able to get the logs from my iPhone and entries like the following seemed to confirm this:

installd.staging/temp.2LWJ2h/extracted/Payload/What Is My Speed?.app : 0xe8008017 (A signed resource has been added, modified, or deleted.)}```

But when I got to the stage of a completely blank app still failing, I suddenly thought of the question mark. With the benefit of my preamble to this post, you all probably got there long before I did, but I got there in the end.

The solution was to remove the question mark from the names of the targets in Xcode. I had to fix up the module names in my unit testing files, but apart from that, there were no changes. After this I was able to upload the complete app to TestFlight and install it on my iPhone.

It is possible that it was the Product Names that were the issue, rather than the target name as in Build Settings, Product Name is set to be $(TARGET_NAME) by default but I didn't test that. Maybe next time...

TL;DR Do not put any unusual characters in your target names. Alphanumerics and spaces are OK, but I am not sure about anything else.

Road Trip Apps

2016-04-07T00:00:00Z

Over the past few months, we have done two long road trips: one approximately 4,000 km and the other about 1,800 km. These gave us the chance to try out various apps for navigation and travel information. We live in Queensland, Australia and some of these comments may be country-specific.

Navigation

The basic navigation came down to three apps:

Apple Maps
Google Maps
Metroview (Australia and New Zealand only)

Each has their strengths and weaknesses:

Apple Maps is by far the most beautiful and easy to read. It integrates perfectly with Contacts (as you would expect). Turn-by-turn directions were mostly excellent. The biggest downside is that it does not allow you to specify a route avoiding tolls.
Google Maps allows you to plot a route avoiding tolls... if you can find the setting. Its traffic reporting is by far the best and it would offer suggested changes of routes during the trip to get around traffic. The interface is confusing at times. Turn-by-turn directions were good, although I would have preferred an Australian voice option.
Metroview has all the maps downloaded which saves on data connection costs and handles bad connectivity areas better. Its best feature is notification of speed limits and alerts if you go over the limit, although it gets confused when on over or under-passes. Another very useful feature is the display of lanes when approaching highway exits, so you could tell which lane to be in. Apparently the voice guidance is now more natural but we didn't try this. The display is messy and cluttered compared to the others.

We ended up with the following sequence:

Apple Maps for the bulk of the trip.
Google Maps & Metroview (on 2 separate iPhones) in the metropolitan areas and when about to take a highway exit.

Even then it was amusing to see the apps panic when you took a new road and the apps assumed you had left the road and were heading through the bush! And at one point there was a large and official sign saying "Ignore GPS - do not take this turn" and sure enough, both Apple Maps and Google Maps wanted us to turn down a little country lane instead of keeping to the highway.

Speed Display:

Apart from the basic navigation apps, we tried a couple of speed display apps. There are a lot of HUD speed apps out there that project the data on the the windscreen but they had two problems:

They only worked when it was dark. As soon as the sun got up, they became invisible.
They required you to place your iPhone flat on the dashboard so even if they had worked during the day, the iPhone would have got far too hot and shut-down. (We have a mount that holds our iPhones in front of the air vents to avoid this over-heating problem. Any mount that sticks to the windscreen itself leaves the iPhone too exposed to the sun.)

One we stuck with (in non-HUD mode) was Speedometer + HUD. This had a clear display with a few flaws:

When moving from 99 kph to 100 kph, the display was not re-arranged for 3 digits. Moving from 101 down to 100 fixed it, but as 100 kph is the standard speed limit, this was a frequent annoyance.
Adjusting the speed limit was too fiddly and difficult even for the passenger. It would have been impossible for the driver.
It only works in landscape mode which does not always suit the car mounts - we ended up perching the 2nd iPhone on the unused ashtray.

We also tried Talking HUD but didn't like it. It worked solely in HUD mode, so was only useful at night or very early morning. It had voice prompts to tell you when to change gear but in an automatic car, they were just a distraction and it was not obvious how to turn them off.

But overall, we found having a speed display app as well as a navigation app to be the best combination. The audible alerts when you went over speed were very useful when over-taking or getting up to speed as you could get the information without having to take your eyes off the road.

Future App Plans:

Having determined that a speed display app is really useful, but not finding one that suited us perfectly, the obvious next step was to design my own. I wanted it to have the following features:

clean display, visible in all light conditions
easily settable speed limit
audible and visual over-speed warnings
no HUD mode
Apple Watch component for when you only had a single iPhone and it was navigating but you still wanted a speed display

So watch this space for further news of my up-coming app...

Update

"What Is My Speed?" is available now from the iTunes App Store for iPhone and Apple Watch.

Structs vs Classes

2016-03-30T00:00:00Z

One of the big debates among Swift developers is when to use structs and when to use classes.

Classes are the building blocks of object-oriented programming but structs as provided by Swift are newly powerful. Structs have been around in C-based languages for a long time, but Swift has made them more powerful and given them more features so that they are almost indistinguishable from classes. So what are the differences and which one should you use?

Where they are the same?

both can define initializers
both can define properties
both can define methods
both can conform to protocols

Where they are different?

classes can inherit from other classes
structs cannot inherit from other structs
classes are reference types
structs are value types

The reference type vs value type difference is where things really get interesting. Have a look at this example of a class with a single property:

class PersonClass {
    var name: String

    init(name: String) {
        self.name = name
    }
}

var personA = PersonClass(name: "Woody")
personA.name // Woody

var personB = personA
personB.name = "Buzz"
personB.name // Buzz

That looks like standard stuff, but what do you think personA's name is now? If you guessed "Buzz" then you win a prize! (No, not a real prize - pat yourself on the back.)

This is because when we created the personB variable and assigned personA to it, we did not assign the VALUE of personA, we assigned a REFERENCE to personA - actually the address in memory of personA rather than the data inside.

So now we have two objects and they are both looking at the same spot in memory for their data. This means that changing the name of personB changed the name of personA as well.

Let's try the same thing with a struct:

struct PersonStruct {
  var name: String
}

var personC = PersonStruct(name: "Rex")
personC.name // Rex

var personD = personC
personD.name = "Hamm"
personD.name // Hamm

personC.name // Rex

This time, because we are using a struct, when we assign personC to the new personD variable, we are actually making a copy of personC and setting the values of personD to this new copy. So now we can change personD without messing with personC.

Note that I did not have a define an init for the struct because it creates one automatically. You can still add one yourself if you want to do anything different, but you do not have to.

At first glance, you may think that you should now use structs all the time to avoid these unintended consequences, but it isn't quite as simple as that. Sometimes a class is still the best thing to use.

The inheritance capabilities of classes can make your decision simple: if you need to create a button and want to start by sub-classing UIButton or NSButton, then your button must be a class, not a struct. This will apply to most user interface objects.

Apple really wants us to use structs and in the Swift standard libraries, a very high percentage of the objects are structs. But structs are especially well suited to a certain subset of objects.

The best explanation that I have found of when to use a struct is the Jeff Trick. Reduced down, the rule is:

If you can overload == to compare two instances of your object, use a struct.
If this doesn't make sense, use a class.

So use structs for your things: Person, Shape, Brick, Cat.
Use classes for everything else.

I would add one caveat: don't fight the compiler. If using a struct is giving lots of errors and warnings, change to a class.

A logical consequence of this is that all structs should conform to the Equatable protocol.

Extending PersonStruct to make it conform just requires a single function:

extension PersonStruct: Equatable {
  static func == (lhs: PersonStruct, rhs: PersonStruct) -> Bool {
    return lhs.name == rhs.name
  }
}

Since this struct only has one property, we can say that two instances of this struct are equal if the names are equal.

Testing this, we can see:

var personC = PersonStruct(name: "Rex")
var personD = personC
personD.name = "Hamm"

personC == personD // false

let personE = PersonStruct(name: "Rex")
personC == personE // true
personC != personE // false

Conveniently, providing an == function effectively gives us a != function for free as you can see from the last example.

There is one final point I would like to make about struct and that concerns mutating functions. Look at what happens if we include a function that changes the name property in the struct:

Fix-it is very helpfully pointing out that the method needs to be marked as mutating for this to work and is showing where this should go. Accepting the suggestion will get rid of the error and then the name can be changed using this method.

struct PersonStruct: Equatable {
    var name: String

    mutating func changeName(to newName: String) {
        if !newName.isEmpty {
            name = newName
        }
    }
}

var personC = PersonStruct(name: "Woody")
personC.name // Woody

personC.changeName(to: "Sid")
personC.name // Sid

There is no problem about using mutating and it will not have the unintended consequences of using classes. Despite the scary name, a mutating function actually returns a new copy of the struct.

The problem arises if you have many nested structs and the mutating has to spread through the list. So don't nest your structs - at least not more than two deep!

Learning Swift - Optionals

2016-03-12T04:24:00Z

Today I plan to discuss optionals since they were a feature of Swift that I found difficult to grasp at first.

What is an optional in Swift?

An optional is a variable of a specified type that can also be nil.

Why does this matter?

In Objective-C, any object type could be nil. If you declared a variable like this:

NSString *myString;

then myString was set to nil by default.

But this could cause issues, especially as Objective-C does not complain if you send a message to nil. This could lead to bugs that were very difficult to track down.

The other big use for nil is when returning from a function which has found no appropriate data to return. The classic example is when looking for the index of an element in an array. What should be returned if the element is not found in the array?

Some languages return -1, Objective-C uses NSNotFound, but you have to know what each language is going to do. The more logical answer is nil. However if your function is expected to return an integer, then it cannot return nil because nil is not an integer.

This is where optionals come in: if the function is expected to return an optional integer, it can return with an integer with the index of the matching element, or it can return nil if the element was not found. This is much clearer and less prone to error.

How does Swift handle optionals?

One of the first things that struck me about Swift was how clean the code looked, without so many non-alphanumeric characters scattered around. Gone were all the:

* ; [ ]

But instead, Swift code sprouted:

! ?

What were these?

The key to understanding optionals is to realise that when you declare an optional variable of a certain type, you are actually declaring a box that can hold a variable of that type or can hold nil.

Once you grasp that concept, it all becomes much more obvious.

var optionalInteger: Int?

The ? indicates that this is an optional variable. It does not have to be initialised as it is already set to nil which is valid for an optional variable. Without the ? this would require initialisation as it would not be valid for it to be nil.

Setting an optional

Setting the value of an optional variable is just the same as any other variable:

optionalInteger = 3
optionalInteger = 42

Getting an optional

The difference arises when you need to get the data out of the optional variable in order to use it. This process is called un-wrapping and it means to get the variable value out of the 'box' it is stored it.

The most obvious way is to use !

let newInteger = optionalInteger!

DO NOT DO THIS!

This is called forced-unwrapping and assumes that the optional variable is not nil. If the optional is nil, this will crash. In Xcode, when you connect interface elements from your storyboard to a Swift file, Xcode will use ! like this:

@IBOutlet weak var startButton: UIButton!

I have to assume Xcode knows what it is doing and the button will be available when needed, but you should not use ! - it is un-safe. By using it, you are vowing to the compiler that when it gets to that point, the optional value will not be nil. There are much better and safer ways of doing that.

Use 'if let'

func doubleNumber(_ optionalInteger: Int?) -> Int? {
    if let integerValue = optionalInteger {
        // integerValue is not an optional
        // and is guaranteed to contain an Int
        return integerValue * 2
    }

    // no integer found in the optional,
    // so return nil to indicate failure
    return nil
}

Use guard

func doubleNumber(_ optionalInteger: Int?) -> Int? {
    guard let integerValue = optionalInteger else {
        // get out quickly,
        // returning nil to indicate failure
        return nil
    }

    // integerValue is not an optional
    // and is guaranteed to contain an Int
    return integerValue * 2
}

These two alternatives (if let & guard) do the same job but in opposite ways. In both cases, they perform a conditional un-wrapping that may or may not give a valid result. if let checks if it is OK to proceed. guard checks to see if it is NOT OK to proceed. Which you use is really a matter of personal preference and working out what is more logical in each case.

The guard statement is really good for checking data early in a process and making a quick exit it something is wrong. The if let construct encloses your success code inside a block and can sometimes leave the failure code a long way from the check which can make it less obvious. The other potential issue with if let is the "pyramid of doom" common in early Swift code as demonstrated in this rather contrived example:

func isValidAddressBookEntry(firstName: String?,
                             lastName: String?,
                             emailAddress: String?,
                             phoneNumber: String?) -> Bool {
        if let validFirstName = firstName {
            if let validLastName = lastName {
                if let validEmail = emailAddress {
                    if let validPhone = phoneNumber {
                        return true
                    }
                }
            }
        }
        return false
}

Thankfully, Swift now allows us to chain both if let and guard statements. Here is the previous example re-factored to use if let:

func isValidAddressBookEntrySwift2(firstName: String?,
                                   lastName: String?,
                                   emailAddress: String?,
                                   phoneNumber: String?) -> Bool {
      if let validFirstName = firstName,
          let validLastName = lastName,
          let validEmail = emailAddress,
          let validPhone = phoneNumber {
          return true
      }
      return false
}

And here is the same function but using guard which allows the inputs to be checked immediately and the function exited if the u=inputs are not valid. For a short function like this, the change is not really significant, but if the function does a lot of processing of the input data, checking first and getting out as soon as possible is more efficient.

func isValidAddressBookEntryUsingGuard(firstName: String?,
                                       lastName: String?,
                                       emailAddress: String?,
                                       phoneNumber: String?) -> Bool {
    guard
        let validFirstName = firstName,
        let validLastName = lastName,
        let validEmail = emailAddress,
        let validPhone = phoneNumber else {
            return false
    }

    return true
}

Use optional chaining

The final way to deal with optionals safely is to use optional chaining:

struct SocialMediaAccounts {
    var facebook: Person?
    var twitter: Person?
}

struct Person {
    var firstName: String?
    var lastName: String?
    var handle: String?
}

var socialMedia: SocialMediaAccounts?
socialMedia = SocialMediaAccounts()
var twitterAccount = Person()

socialMedia?.twitter = twitterAccount
let twitterHandle = socialMedia?.twitter?.handle

In this example, we have defined a SocialMediaAccounts struct that holds optional Person structs for the various social media outlets. The socialMedia variable is defined as an optional and then created. A twitterAccount variable of type Person is also created but contains no data at the moment.

When assigning the twitterAccount to the socialMedia.twitter property, a ? is inserted which checks to see that socialMedia is not nil. If it is nil, then execution of that line stops at the ? and nothing bad will happen.

In the same way, when trying to read back the twitter handle, we chained together 2 optionals with ?'s. If either socialMedia or socialMedia.twitter is nil, that line will not complete. Again this is perfectly safe and the app will not crash.

All the examples in this article are available in a Swift playground which has been updated to Swift 4 syntax.

Learning Swift - For-Loops

2016-03-12T00:00:00Z

Loops are a fundamental building block of any program. Doing repetitive tasks fast and accurately is what computers are really good at and what we humans get very bored doing. Swift offers several different ways to perform loops, but today we are going to concentrate on for-loops.

The most basic form of loop is the for-in loop. There are two ways this can be used: looping over the numbers in a range or looping over the elements in an array or dictionary.

Firstly, the range:

for x in 0 ..< 5 { printWithSpace(x) }
// prints: 0 1 2 3 4

I am using a custom print function that allows me to print the results on a single line for convenience.

This for-in loop uses a half-open range and it is effectively saying:

start with x at 0 print x with a space add 1 to x is x still less than 5? yes - go back to the print stage no - stop

If we wanted to go all the way to 5 instead of stopping before 5, we would use a closed range by replacing ..< with ...

for x in 0 ... 5 { printWithSpace(x) }
// prints: 0 1 2 3 4 5

These methods work fine if we want to loop through a range of numbers one at a time but what if we want a different increment? There are several ways to vary the step.

stride(from:to:by:)
stride(from:through:by:)
where

for x in stride(from: 0, to: 10, by: 2) {
  printWithSpace(x)
}
// prints: 0 2 4 6 8

for x in stride(from: 0, through: 10, by: 2) {
  printWithSpace(x)
}
// prints: 0 2 4 6 8 10

The 2 variations of stride are analogous to the 2 ways of expressing the range in the the for-in loop.

stride(from:to:by:) starts with the number in the from parameter and each time through the loop, increments that number by the amount of the by parameter. If the incremented number is less than the to parameter, the loop continues.

stride(from:through:by:) works the same way but continues until the incremented number is greater than or equal to the through parameter.

Using a negative value for by allows counting backwards:

for x in stride(from: 10, through: 0, by: -2) {
  printWithSpace(x)
}
// prints: 10 8 6 4 2 0

Stride can also be used for floating point loops although the result may contain some unexpected changes in precision e.g 0.7000000000000001 instead of the expected 0.7

let startingNumber = 0.1
for x in stride(from: startingNumber, through: 1.0, by: 0.2) {
  printWithSpace(x)
}
// prints: 0.1 0.3 0.5 0.7000000000000001 0.9

Note that the result does not contain the through parameter as the next iteration would have produced 1.1 which is greater than it. And also startingNumber did not have to be a variable as it is never actually changed.

Using where makes it possible to step through a loop while conforming to some conditional:

for x in 0 ... 10 where x % 3 == 0 {
  printWithSpace(x)
}
// prints: 0 3 6 9

The other main use for for-in loops is for iterating through the elements of an array or dictionary:

let arrayOfInts = [ 1, 2, 3, 4, 5, 6 ]
for x in arrayOfInts {
  printWithSpace(x * 2)
}
// prints: 2 4 6 8 10 12

let myDict = [ 1: "one", 2: "two", 3: "three" ]
for (key, value) in myDict {
  print("\(key) = \(value)")
}
// prints:
// 2 = two
// 3 = three
// 1 = one

As a dictionary is un-sorted, the order of the items may vary.

If you want to loop through an array while also monitoring the index of each element, you can use enumerated()

let arrayOfNames = [ "Andy", "Buzz", "Woody" ]
for (index, element) in arrayOfNames.enumerated() {
  print("The name at index \(index) is \(element)")
}
// prints:
// The name at index 0 is Andy
// The name at index 1 is Buzz
// The name at index 2 is Woody

If your array contains optionals, you can use for case let to test each value:

let arrayWithOptionals: [String?] = [ "Woody", nil, "Buzz", nil, "Rex" ]
for case let name? in arrayWithOptionals {
  printWithSpace(name)
}
// prints: Woody Buzz Rex

The name variable is un-wrapped each time through the loop so can be used safely.

Any of these loop styles can be combined with where to perform checks on each iteration:

let arrayWithOptionals: [String?] = [ "Woody", nil, "Buzz", nil, "Rex" ]
for case let name? in arrayWithOptionals where name.count < 5 {
  printWithSpace(name)
}
// prints: Buzz Rex

Some of you may be wondering what happened to the old C-style loops like this:

for var x = 0; x < 5; x++ { print(x, terminator: " ") }

This does not work in Swift 3+: the ++ and -- operators and this style of loop declaration have been removed from the language. For further details, check out the relevant proposals at Swift Evolution:

All the examples in this article are available in a Swift playground now updated to Swift 4 syntax.

Learning Swift - Generics

2016-02-29T00:00:00Z

One of the nice things about Swift is how clean your code looks. A lot of the weird characters that pepper the code of other languages has been eliminated: No more semi-colons, asterisks etc.

But then you are reading somebody else's code and you find these angle brackets all over the place and they don't seem to make sense.

What does this mean?

func mid<T: Comparable>(array: [T]) -> T

It looks like it is a function to find the middle element in an array, but what is <T: Comparable> or [T] or even just T? They are describing Generic data types.

Using the dictionary, I find the following definition for generic:

characteristic of or relating to a class or group of things; not specific.

And that really provides quite a good definition for Swift's generics too. They allow you to assign a non-specific data type to a function so that function can be used for many different data types.

But enough of the theory: by far the best way to understand generics is to encounter the problem they are meant to solve and then to solve it.

The other day I was processing data to feed to a charting library. I ended up with an array of CGFloats, but there were too many of them, so I wrote a function to give me the last x elements of an array of CGFloats:

func endOf(array: [CGFloat], numberOfElementsToInclude: Int) -> [CGFloat] {
  if numberOfElementsToInclude > array.count { return array }

  let startingElement = array.count - numberOfElementsToInclude
  let endOfArray = Array(array[startingElement ..< array.count])
  return endOfArray
}

let largeArray: [CGFloat] = [1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0]
let smallArray = endOf(array: largeArray, numberOfElementsToInclude: 3)
//smallArray now equals [8.0, 9.0, 10.0]

OK, so largeArray isn't actually the largest array you have ever seen, but it works for demo purposes. In my code, I had over 20,000 entries in the large array and only wanted the last 5,000.

I was completely happy with that until I found another data source where the data was an array of Ints. Still perfectly chartable using my charting library, but I could not get the end of the array using my nice function. First thought was to replicate the function:

func endOf(array: [Int], numberOfElementsToInclude: Int) -> [Int] {
  if numberOfElementsToInclude > array.count { return array }

  let startingElement = array.count - numberOfElementsToInclude
  let endOfArray = Array(array[startingElement ..< array.count])
  return endOfArray
}

let largeArrayInt = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ] // type inferred to be Int
let smallArrayInt = endOf(array: largeArrayInt, numberOfElementsToInclude: 7)
// smallArrayInt now equals [4, 5, 6, 7, 8, 9, 10]

A quick glance will reveal that the declaration line was the only thing that changed. I didn't have to give the function a new name because the compiler worked out which of the two functions to use based on the types supplied. So all I was doing was replacing CGFloat with Int in two places (the numberOfElementsToInclude parameter remains an Int in both cases).

As soon as you find yourself replicating code and only changing the types of the data, that is a sign that you need to use generics.

For my first attempt at creating a generic function, all I did was replace the word CGFloat with T where T indicates some type that will be specified when the function is called. The convention is to use single letters for generic types: T for Type, A for AnyObject, Z because you feel like it. The choice is up to you.

That produced this error:

Use of undeclared type 'T'. Well that seems fair enough... how is the compiler supposed to know what a T is?

It turns out that this is where the angle brackets come into play. You have to warn the compiler that this function is going to get a generic type and that the T is only a placeholder, not a real type. So this version compiles and works - notice the <T> between the function name and the opening bracket:

func endOf<T>(array: [T], numberOfElementsToInclude: Int) -> [T] {
  if numberOfElementsToInclude > array.count { return array }

  let startingElement = array.count - numberOfElementsToInclude
  let endOfArray = Array(array[startingElement ..< array.count])
  return endOfArray
}

Now I have no code duplication and if I ever get another data set that uses a different object type, my function will still work.

Now we know to use generics instead of replicating code that operates in the same way on different data types.

And we know how to construct a generic function.

Using it is identical to using the two functions I had before:

let largeArray: [CGFloat] = [ 1.0, 2.0, 3.0, 4.0, 5.0,6.0, 7.0, 8.0, 9.0, 10.0 ]
let smallArray = endOf(array: largeArray, numberOfElementsToInclude: 3)

let largeArrayInt = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ] // type inferred to be Int
let smallArrayInt = endOf(array: largeArrayInt, numberOfElementsToInclude: 7)

You do not have to specify what T is when calling the function, that will be inferred from the supplied data.

Moving on into more advanced use cases, we have two things to consider:

Functions where the generic parameters must conform to a protocol.
Functions that take generic parameters of different types.

The example function I started with (not mine but I forget where I got it... If it is yours, thanks you very much) used:

func mid <T: Comparable> (array: [T]) -> T

Instead of specifying the type as completely generic, it specified that it must conform to the Comparable protocol. This is because the function body used a sort() function so the generic function needed to be sure that the elements in the array could be compared. This technique can also be used to restrict the parameter types to sub-classes of a certain class.

For a function with more than one generic data type, you need to use more than one placeholder letter:

func genericWithTwoDifferentTypes<T, U>(param1: T, param2: U) -> Bool {
  // ...
}

And in exactly the same way, both T and U can be set to conform to a protocol or be members of a certain super-class.

Hopefully this has taken some of the mystery out of generics, but if you have any questions, please get in touch using the Contact page, comment below or contact me via Twitter: @trozware.

Singleton to Protocol

2016-02-26T00:00:00Z

I was driving through the town of Singleton the other day and of course, it got me thinking about using singletons in my apps. Singletons were a commonly used pattern in Objective-C programming and appear in many of Apple's own APIs, but seem to be increasingly frowned upon in the Swift world.

So what is a singleton?

A singleton is a class that only expects to have a single instance. Think of it as a global instance of a class. In some cases this makes perfect sense if there can only ever be one instance of a particular class or if there is a default variant that suits most cases e.g.

UIApplication.shared
UserDefaults.standard
NotificationCenter.default
FileManager.default
URLSession.shared

If you are using an object with a property name of "shared", "standard" or "default" you can be pretty sure it is an singleton.

And what's the problem with singletons?

There are probably many different opinions here but I have two thoughts about this:

They are effectively global variables and global variables can make your code messy and un-predictable.
If they can be accessed by multiple other objects, possibly at the same time, then you can get conflicts. These can be handled by clever use of background queues, but it isn't easy.

What to use instead?

As I drove, I mused on a singleton that I had implemented recently. It was a logging utility that allowed any object in my app (mostly view controllers) to save a new entry to a log file. The basic structure of the Logger class was this:

class Logger {
    static let sharedLogger = Logger()

    func addToLog(event: String) {
      // use private functions to find log file URL
      // append event text with time stamp
    }

}

Any object in my app could use the Logger like this:

Logger.sharedLogger.addToLog(event: newLogEvent)

When I got to think about how I was using this, I realised that instead of a Logger object that everything could use, what I really needed was a Loggable behaviour that I could apply & restrict to the few classes that actually needed to log events. For me, this was the break-through:

Create a behaviour, not an object.

As soon as I started thinking about this as a behaviour, a protocol became the obvious solution, so this is what I created:

protocol Loggable {
  // not declaring functions here
  // as they should NOT be over-written
}

extension Loggable {

    func addToLog(event: String) {
      // use private functions to find log file URL
      // append event text with time stamp
    }

}

We run immediately into one of the peculiarities of Swift protocol extensions which has been very well explained by Caesar Wirth. If I had declared addToLog(_:) in the protocol, then any class or struct conforming to this protocol would have been free to over-write this function and provide its own version. This is not what I wanted here - I wanted every object to use the same version. So I left the function declaration out of the protocol definition and only included it in the protocol extension.

To use this behaviour, a class or struct just has to be declared as conforming to the Loggable protocol:

class MyClass: Loggable {
  func doSomething() {
    addToLog(event: "I did something!")
  }
}

For my app, I knew that I would want all my NSViewControllers to be able to add log events, so instead of setting them all individually as conforming to the protocol, I used this shortcut which extends all NSViewControllers to conform to the protocol.

extension NSViewController: Loggable {}

I added this line to the Loggable.swift file where I declared the protocol and its extension, but outside both of them.

Protocol-oriented programming is a new technique to me, so it really helps when I can find a practical example of where it solves a problem.

If you are new to POP, I highly recommend the Crusty talk from WWDC 2015. And this article by Matthijs Hollemans was invaluable to me in demonstrating the problems with object inheritance that are solved by protocols.

Three Rules for Writing Better Swift

2016-02-24T00:00:00Z

Do not use !.
Use let, not var.
Allow the compiler to infer types.

Read on for more details...

1. Do not use !

Swift uses optionals for values that can be nil. To use an optional value, you need to "un-wrap" it first, which means getting the actual value out, assuming that the value exists and the optional is not actually nil.

Optionals are the subject of a complete post by themselves, but for now, I will just say this: When you use ! you are promising the compiler that you will make sure there is a real value in that optional by the time it is needed.

If this is not the case, your app will crash as shown in this playground:

Instead of using ! you should use optional chaining with ? or check the value with guard or if let before use.

One trap to beware of is with Xcode's attempts to be helpful and suggest fixes to problems. If you use an optional where it cannot work, Xcode will warn you that it is incorrect, but the suggested fix will be to insert !

When you see this, do not accept the suggested fix, but use it as a warning to show that you need to fix the problem properly.

2. Use let, not var

Using constants in C-based languages is a pain. I could never remember the Objective-C syntax for declaring a static constant, so used to fall back to using #define for global constants. Inside my objects, all instance properties were variables, not constants. Inside functions, it was the same.

It doesn't take much imagination to work out that your apps will perform better and more securely if values that do not need to change are allocated as constants instead of variables.

With Swift, this is easy as you just declare a constant using the let keyword and declare variables using var. The Swift compiler will now warn you if you have used var where let would do, but I prefer to declare everything using let and only change to var when this causes an error as shown in this playground example:

3. Allow the compiler to infer types

With Objective-C and many other languages, you have to tell the compiler exactly what each variable is going to be: a string, an integer, an object of a certain type.

With Swift, the compiler is clever enough to work this out for you, which can make your code much cleaner looking and easy to read.

There are a few exceptions to this rule which are shown in the playground below:

Lines 3 - 6 are allowing the Swift compiler to decide what the type is and it is choosing valid types: Int, Double, String and UIView.

Line 8 is a case where we do not want the default type, which would be Double so we need to tell the compiler that this one really should be a CGFloat.

Lines 10 & 11 both deal with an array of Ints. In line 10, the values are supplied so the type of the array can be inferred. In the second case, the array is initially empty, so the type needs to be specified in the declaration.

Lines 13 and 14 are the same but with dictionaries instead of arrays.

In each case, it would have been valid Swift to specify the type but why bother? The more text you enter , the more change of mistake and it leaves your code looking cluttered.

If you ever need to check what type has been assigned to a constant or variable, Option-click on it in Xcode and you willl get a popup telling you what it is.

This was going to be five rules, but then I got a bit too verbose so will add more rules in a separate post.

Configuring Xcode

2016-02-17T00:00:00Z

While not strictly a part of my Learning Swift series, today I thought I would discuss some of the ways to configure and use Xcode to be a more productive and comfortable programmer.

1. Editor color themes and fonts:

Step through the supplied themes and find the best one for you. Then click the '+' button at the bottom of the list and duplicate the selected theme. Now you can tweak it to suit you. Each text category can have its own font and size, but you can make multiple selections in order to do a bulk change. don't forget to check out the Console section too - I dislike the default bold text for many of the console reports, so always change that.

An editing font should be mono-spaced i.e. every character should take up exactly the same width on the screen. This makes your code look neater and neater code is easier to read when you come back to it. I also much prefer a sans-serif font, but that is a matter of preference.

Menlo is the font used by Xcode as a default, but there are many other options either in the default installation of OS X or as free downloads. I change every now and then just to keep things interesting, but my current selection is Fira Code. I love the way it merges two character symbols into a single character for faster comprehension.

My other favourites are:

Look for a font that makes it easy to distinguish the digit '1' from a lowercase 'l' and where the digit '0' is different to the 'O'.

To install and use a new font, download the files and then double-click a TTF or OTF font file to install it in FontBook. Once the font is installed, you may need to restart Xcode in order to make it available.

2. Add-ons:

Update: Xcode 8 has removed the ability to run any plugins or to use Alcatraz, so this section is no longer valid. Instead Apple is offering official support for Xcode Source Editor Extensions, so they are the way of the future.

3. Documentation:

Xcode has excellent documentation, but unless you specifically download it, this will all be accessed online. If you have a bad or non-existent connection, this can be annoying. Go to Xcode's Preferences -> Downloads and download all the document sets you are interested in. They are quite large, but having them local will be a big bonus.

The other tool I use for documentation is Dash. It supports many languages and is not just for use in Xcode. I found the Xcode integration plugin was not very useful as it conflicted with other useful behaviours. So I set up a global shortcut in System Preferences to search Dash for the selected text. This is much faster than Xcode's built-in documentation.

4. Other preferences:

Go through the preference panes in Xcode's preferences and tweak to suit your style or your group's preferred style.

General and Text Editing are important. Text Editing has a second tab for Indentation which is easy to miss. Indentation styles seem to cause a lot of heated debate, so make sure you check this out.

Accounts is vital if you are publishing to the App Stores and also makes it easy to transfer all your develop information from one computer to another.

Fonts & Colors and Downloads are discussed above.

I tend to leave the others set to the defaults.

How do I start to learn Swift?

2016-02-16T00:00:00Z

The first thing to do is to download the latest version of Apple's Swift Programming Language book from the iBooks Store.

You can just read this book, especially the first section: "A Swift Tour", but you will get more out of it if you follow along with the playground. There is a link to download the playground from the book which you can use directly if you are reading using iBooks on the Mac. If you are not, here is the download link.

You will also need to install Xcode from the Mac App Store. Xcode is Apple's IDE and is used for programming Mac, iPhones, iPads, Apple Watches and Apple TVs.

Swift introduced the playground to Xcode. A playground is a fantastic way to learn and experiment. You do not need to create a project, build, run a separate app, install on a device. Code typed into a playground is run immediately and you can see the results instantly, line by line.

Here is an example of a playground showing the code on the left and the result of each line appearing on the right.

Once you have gone through the Swift Tour, Apple's book becomes more of a reference guide to return to whenever you get stuck. The other way I use it is to check up on changes made when a new version of Swift is released. As the language is still rapidly evolving, these can be quite extensive. Once I have the latest version of the book, I go to the Revision History at the back and click the links to read about the features that have been added or changed.

Apart from Apple's documentation, there are a lot of great web sites, blogs and Twitter accounts out there. There are also useful newsletters that give a weekly summary of exciting developments.

Here are some of my favourites:

Natasha the Robot - my favourite Swift blogger - sign up for her newsletter and follow her on Twitter.
Apple's Swift Blog - not many posts, but good for learning about new features.
Erica Sadun - sometimes a bit too technical for me, but often contains some really useful snippets. Erica has the distinction of being the first person outside Apple to have had a Swift language proposal accepted as part of the open source development process.
Andy Bargh - detailed articles on various aspects of Swift, plus a weekly newsletter.
Ray Wenderlich tutorials - search for Swift and find heaps of tutorials covering many different aspects.
Swift Sandbox - weekly newsletter filled with interesting articles.
SwiftMonthly - useful newsletter with links to tutorials, videos and projects.
SwiftDoc.org - the documentation in Xcode is still heavily skewed towards Objective-C programmers and it can be difficult to find Swift-specific entries. This site makes it easy.

And I hope you will keep coming back to this site to see what new Swift-related articles are available.

Icon Builder 3.2 Released

2016-02-10T00:00:00Z

Icon Builder 3.2 is now available from the Mac App Store.

Icons for Apple Watch apps now have their alpha channel removed.
Tidier folder structure for related files (iTunes Artwork files and Read Me).
Updated to work with Xcode 7's Assets.xcassets folders.
Creates iPad Pro icons for Xcode 7.2 or later.
Fix for Retina Macs creating double-sized images.

Why is Swift so great?

2016-02-10T00:00:00Z

Firstly, I can give you the technical answer, as published by Apple:

Swift is a new programming language for iOS, OS X, watchOS, and tvOS apps that builds on the best of C and Objective-C, without the constraints of C compatibility. Swift adopts safe programming patterns and adds modern features to make programming easier, more flexible, and more fun. Swift’s clean slate, backed by the mature and much-loved Cocoa and Cocoa Touch frameworks, is an opportunity to reimagine how software development works.

Swift has been years in the making. Apple laid the foundation for Swift by advancing our existing compiler, debugger, and framework infrastructure. We simplified memory management with Automatic Reference Counting (ARC). Our framework stack, built on the solid base of Foundation and Cocoa, has been modernized and standardized throughout. Objective-C itself has evolved to support blocks, collection literals, and modules, enabling framework adoption of modern language technologies without disruption. Thanks to this groundwork, we can now introduce a new language for the future of Apple software development.”

Excerpt From: Apple Inc. “The Swift Programming Language (Swift 2.1).”

Now I can give you my opinion:

Swift makes for code that is easier & faster to write.
Swift makes for code that is easier & cleaner to read (much more important than ease of writing).
Swift code is safer code.
Swift breaks free from the out-dated conventions of C-based languages.

When Apple announced Swift at WWDC 2105, I was astounded. That such a major event could have been kept completely secret was amazing. Then I watched every video from WWDC 2015 that discussed Swift. Some were beyond me and others I absorbed. Looking back, I can see that the development of Objective-C over the past few years was all aimed at getting to this point, especially with the introduction of ARC and blocks.

At that time, I was deeply involved in an existing Objective-C project and not able to do much in Swift. But I went through the introduction at the start of the Swift Programming Language book in iBooks and was able to get some ideas about how the language worked.

Some months later, I was able to spend time on Swift. As a learning exercise, I converted an existing Objective-C iOS app to Swift. As might be expected, I really just wrote Objective-C code using Swift syntax. It took a lot more learning before I was able to write Swift-y code instead of just translated Objective-C. In future posts of this series, I hope to enable others to cross that divide faster than I did.

Now when I go back to an Objective-C app, I feel like I am walking a tight-rope. When I use an NSArray, NSSet or NSDictionary, I think "How can I tell what sort of objects are in that array?". When I use an object, I think "What if that object is nil?". All of a sudden, code that appeared stable now feels random.

One of the big things that people have latched onto with Swift is that it allows functional programming. I plan several detailed posts on functional programming in this series. But for now I would just recommend that you not worry about the distinction between procedural & functional programming. Both have their advocates and their detractors. Both have their advantages and disadvantages. Just do what ever works for you and we can worry about this later.

Learning Swift - An Introduction

2016-02-09T00:00:00Z

Welcome to Learning Swift.

This is the first post in what I hope will be an extensive series dealing with the Swift language. Here are some of the questions I hope to answer:

Should I learn Swift? Why?
Why is Swift so great?
How should I start learning Swift?
I already know Objective-C - how do I convert?

After that, I am planning a series of posts discussing the major differences of Swift from the view point of an Objective-C programmer and the aspects of Swift that I found difficult to grasp. Topics covered will include such things:

optionals
closures
functional programming
protocols
generics

I am coming from a background of Objective-C, so many of my posts will be dealing with aspects of Swift that are not familiar to Objective-C programmers. I will not assume any Objective-C programming experience, but some features of Swift that are new to me, will be familiar to people accustomed to other languages.

So let's start by answering the first question:

Should I learn Swift?

If you are writing or planning apps for any Apple platform - YES.
If not, wait until Swift is available for the platforms you need to support.

Why?

If you are already an iOS or Mac developer: YES

This is the new language and Apple is very committed to it. Objective-C is not going away any time soon, but Swift is where it is going to end up, so why not make the jump now while the language is still in development? You have to accept that fact that every release of Xcode is going to break your code, but the automatic re-factoring works very well. And by moving to Swift now, you get the chance to influence the direction of a new language. How often does that happen?

If you are starting to learn iOS or Mac development: YES

If you have no history with Objective-C, then do not waste your time learning it. There is still a lot of sample code out there in Objective-C, but increasing numbers of tutorial sites are using Swift and converting their existing tutorials to Swift. It will help if you know just enough Objective-C to read it, but you do not need to know enough to write it.

If you do NOT program for Mac or iOS: NOT YET

Swift went open source in late 2015. This is a big deal and Apple's plans for Swift are quite clear. They want Swift to be such a main-stream language that it is used instead of Java for basic computer science courses in universities. This was never going to happen unless the language was open-source and cross-platform. It is now open-source and available for Linux as well as Mac/iOS. While Apple has not yet released any further ports, I think there are more on the way for Raspberry Pi, Arduino and other embedded systems as well as server-side Swift libraries like Perfect. I expect that a version for Windows will not be far behind.

New Twitter account

2016-02-09T00:00:00Z

I have started a new Twitter account so that I can provide rapid support to users of my apps. Please contact me @trozware if you have any questions, suggestions, bug reports or would just like to chat.

I will also be using this account to promote my new Learning Swift series.

Possible issues with Icon Builder & Watch icons

2016-02-06T00:00:00Z

It has come to my attention that there are two possible issues with Icon Builder 3.0.1 when using icons created for an Apple Watch app. Once of them is something I can fix and the other appears to be a bug in Xcode 7.2

Update: Version 3.2 of Icon Builder is now available in the Mac App Store. This removes the alpha channel from icons for a watch app.

The first problem is that iTines Connect now requires that the icons for an Apple Watch app include no alpha channel. This is becoming an increasing trend with it first having applied to the large icon file you upload directly to iTunes Connect, then to screen shots. I expect it to extend to iOS app icons soon, but hopefully Mac app icons can continue to include transparency.

With Apple Watch icons, you are supposed to create a set of square icons and watchOS or iTunesConnect applies the rounding mask. Presumably this is more complicated if the icon contains an alpha channel even if there are no transparent pixels. If your Watch app icons contain an alpha channel, you will see errors like this after uploading your app to iTunes Connect:

Invalid Icon - The watch application 'AppName.app/Watch/AppName WatchKit App.app' contains an icon file 'AppName.app/Watch/AppName WatchKit App.app/AppIcon-Watch24x24@2x.png' with an alpha channel. Icons should not have an alpha channel.

You will probably get this error message for every icon size in the Watch app (8 in total). Until I release a new version of Icon Builder that allows for this this, I suggest you use this Alpha Channel Remover app.

In your Xcode project, go to WatchKit App Assets.xcassets, select the AppIcon set, right-click and choose "Show in Finder". A folder will open containing eight .png files and one .json file. Drag & drop the .png files into the Alpha Channel Remover window and click the "Remove Alpha Channel" button. This will replace all those image files with new versions without alpha channels. To confirm this, select any of the images and press Command-I to get info. In the More Info section, you will see "Alpha channel: No".

You can now submit your app again, but that only solves one of the issues.

The other problem is that you will get a warning about the 44x44@2x.png icon file.

Invalid Icon Name - The watch application 'AppName.app/Watch/AppName WatchKit App.app' contains an invalid icon file name 'AppName.app/Watch/AppName WatchKit App.app/AppIcon-Watch44x44@2x.png'. Make sure that icon file names follow the pattern
"*<dimension>@<scale>x.png" and they match the required dimensions. Please visit https://developer.apple.com/watchkit/ for more information.

As you can see in the error message, the icon name (which is set by Xcode) does conform to the required pattern, and the image is the correct size. This appears to be a bug in Xcode 7.2 but does not stop you from submitting your app as it is only a warning and not an error. Presumably this will be fixed in later version of Xcode. I am running Xcode 7.2.1 and still see this warning.

Man Reader 1.5

2016-01-31T00:00:00Z

Man Reader has been updated to version 1.5 with a major improvement in the way it looks for available man pages.

Man Reader 1.5 is now available through the Mac App Store.

Change Log:

Much improved searching for available man pages.
Sand-boxed version now works just as well as the non-sand-boxed.

The main feature of this version is that it solves the previous problems with the App Store version and sand-boxing. This was restricting the number of man pages listed in Man Reader so I had to release a non-sand-boxed version of the app to allow for full functionality.

However I discovered that although this gave better results, it was still missing a lot of man pages. Version 1.5 now queries the man page files in a completely different way which is listing many more man pages.

Using 19th Hole on the Apple Watch

2015-12-12T00:00:00Z

19th Hole for iPhone and Apple Watch version 3 is now available through the iTunes App Store. This version is a complete re-write to accommodate the changes in iOS 9 and watchOS2.

The major changes are to do with the way the iPhone and the Watch communicate. In watchOS1, all the brains of the app had to live in the iPhone, meaning that every single interaction on the Watch had to be referred back to the iPhone for processing and the result sent back to the Watch for display. This lead to communications delays and breakdowns which caused third-party apps to work sluggishly or not at all. In watchOS2, the brains of the watch part of the app can now operate inside the watch, greatly reducing the number of communications needed. As well as that, Apple has now provided us with multiple ways of getting data to and from the Watch which again improves performance and reliability.

With the 19th Hole, I made the decision to change the method of inputting scores. The previous version used a slider with plus and minus buttons to adjust scores. The problems with this were the small target area of the plus & minus buttons as well as the fact that a slider with more than about 3 divisions was not useful as a visual indicator.

When watchOS2 allowed developers access to the digital crown, I decided to switch to using that instead. Now you tap the score box of the player you wish to adjust and use the digital crown to select a number. I think this will be easier to use while wearing a glove and hope that it is still easy to read out doors.

The other suggestion is not to do with watchOS2 but is a general tip for using apps of this kind. By default, the Apple Watch will always show the watch face when you raise your wrist. Normally this is the most useful thing, but when scoring a round of golf, it would be easier if The 19th Hole app stayed at the front. To make this happen, you need to set to watch to show the last used app instead of the watch face. This can be set using the Apple Watch app on the phone or on the watch itself.

On the phone:

Open the Apple Watch app.
Select My Watch from the tabs at the bottom.
Tap "General" and then scroll down to tap "Wake Screen".
Make sure "Resume Last Activity" is checked.

On the watch:

Press the digital crown to see the app icons.
Find and tap the Settings icon.
Scroll down and tap "General".
Tap "Wake Screen" and scroll down to make sure that "Previous Activity" is checked in the "Resume To" section.

Dice Pass for Mac

2015-05-30T00:00:00Z

We live in a world of passwords and passphrases and there is a constant struggle between having a secure and a memorable password. As a result, many of us re-use passwords even though we know this is a bad idea.

XKCD had a wonderful comic that illustrated the theory of using a passphrase composed of words that are easy to remember but with a combination that made the passphrase very hard to guess. However even when deciding to use a passphrase like this, it is not easy for us humans to avoid using words that have meaning for us, particularly when it is something we really need to remember.

Diceware was developed to solve this problem. You have a set of 5 dice and a list of words assigned to each possible dice roll for 11111 to 66666. You roll the five dice and get the matching word from the list. Repeat this for the number of words you want to use in your passphrase and you have a random phrase that is hopefully still memorable.

But this sounds like a lot of effort and not something you are likely to do when faced by a password entry field on a web page. So Dice Pass was written to do the work for you quickly and easily.

Select the number of words you want in your passphrase and see the phrase immediately. Keep clicking the "Generate New Phrase" button until you get a phrase you like. If you feel that the computer is not to be trusted when generating a random number for the dice rolls, use your real dice and click the dice to change them to the roll you got. If you get a passphrase that is good except for one or two words, use the Re-Roll button beside those words to get a new roll for just that word.

Dice Pass is available from the Mac App Store now.

Apple Watch First Impressions

2015-04-29T00:00:00Z

I realise that every one has written one of these posts, but given that everyone looks for and notices different things, I think it is still valid.

My first impression was "Why does it come in such a large box?". The courier delivered two boxes - my 38mm Apple Watch Sport and Tim's 42mm Apple Watch Sport. They both came in long boxes, with the 42mm box significantly longer. And both boxes were heavy!

Un-boxing:

Opening them was a typical Apple experience: pull the tag to open the external cardboard box, lift out the white internal box. This opens to reveal the watch with the default strap attached (short for 38mm, long for 42mm). Lift the watch out and pull the tags to remove the plastic protective coating. (On a side note, it drives me crazy when people leave this coating on devices, but I can't see this happening on the watch.) Underneath there is a sleeve containing the other half watch strap so you can swap from long to short. My family tells me that this also includes a user guide, but I didn’t read that - typical Apple user... Under the sleeve is the power block and charging cable. The charging puck is larger than I expected and the cable is very long. Having removed all the components, the packaging is still quite heavy, so I guess Apple just wanted to make sure that no watches were damaged in transit and that it felt like a quality product.

Pairing

Pairing my watch to my iPhone was amazingly slick. After selecting my language, the watch displayed a sort of nebula pattern. On the iPhone, I launched the Apple Watch app, selected the pairing option and pointed the phone camera at the watch display. This did the pairing. Then I waited while all the relevant apps transferred their Apple Watch components to the watch and I was ready to start using it.

The Watch:

The watch comes with the modular watch face showing by default. This is a digital time read-out with various 'complications'. Force-touch the watch face to change it - this takes a surprisingly strong touch. Then you can swipe sideways to select a watch style. Once you have a style selected, some of them offer further customisations: select how much detail is shown, choose what extra information to display, adjust colors.

This is a lot of fun and I am still changing mine very frequently. The good thing is that your customisations are stored, so if you set up the utility watch face in a particular way, then swap to the modular and configure it, when you go back to utility, your previous settings are all still there.

The screen is gorgeous - very crisp and easy to read.

Twisting your wrist to show the time works well most of the time. There is a delay that I would estimate at about half a second, presumably to avoid false positives triggering unnecessary displays. If you are holding your wrist at an unusual angle e.g. showing the watch to someone, this twist will not always work, but tapping the screen will display the watch face instantly.

Tapping on a complication will take you to the relevant parent app e.g. tapping the current temperature will open the Weather app.

A minor quibble is that the phases of the moon are displayed from a northern hemisphere point of view and do not match what we actually see here in Australia.

Battery Life:

This is a complete non-issue. On my first day with the watch, the battery was at 70% when I first turned it on. As you can imagine, usage was very intense that first day and I got to 8%. Since then, the battery level has only got down to 40 -50% over a day and it recharges to 100% within 2 hours. Tim's 42mm model gets slightly better battery life as expected.

I started off having the battery indicator as one of the 'complications' on my watch face, but now I just ignore it.

And the battery life of my iPhone has improved remarkably due to so many quick transactions being done through the watch instead.

I did have a charging problem one night. I woke up and checked the time and realised that the watch was quite warm to the touch. I checked the battery level which was actually lower than when I had put it on the charger. I took it off the charger for a few hours, then put it back and all was well.

Notifications

Here is where you need to be careful. I had turned off most notifications on my phone before getting the watch, so I have not been inconvenienced, in fact I have been able to re-enable many notifications as they are no longer so intrusive.

At first we thought some notifications were not getting through to the watch, then we found out that if your iPhone is awake and un-locked, notifications are not passed on to the watch. So drop the time until sleep on your phone to the minimum which saves your phone battery and makes sure you receive most notifications on the watch.

If you want to stop any apps sending notifications through to the watch, this is easily set in the iPhone's Apple Watch app.

I have noticed there is a bit of a delay. I hear an email or message arriving on my phone and it can be half a minute before it gets to my watch.

Once you get a notification, you can tap it to go to the parent app, swipe up to process it in some way depending on the type of notification, or swipe to the left to see a button that will clear the notification. If you want to get rid of all your notifications at once, do a force-touch on the notifications screen to get the option to clear them all.

Glances

Glances are designed to be one screen indicators giving you important information as quickly as possible. From there, you can decide whether to go to the parent app or not. These are accessed by swiping up from the bottom of the screen when looking at the watch face.

I found that the most important thing here was to reduce the number of glances shown, since they are displayed sequentially. If you have 20 glances installed, you have to swipe at least 20 times to see them all. So go to the Apple Watch app on your iPhone and turn off the glances you do not find essential.

The first glance in the sequence is essential though as it allows you to toggle airplane mode, do not disturb and silent mode. It also has a button that can make your iPhone make a sound to help you locate it. Hold this button down to make the iPhone flash come on as well.

Activity

Here I have to confess to my first disappointment. The activity app tracks three things: Move, Exercise and Stand. When you first start the watch, you tell it your age, sex, weight and height. It computes a suggested daily move goal for you which you can adjust at any time. Then it tracks your daily activities and shows how well you are doing in relation to your goal. For exercise and standing the goals are 30 minutes exercise and standing for at least one minute in an hour 12 times though the day.

The move tracking seems to be fine. I am not sure what metrics it uses, but on more active days, the numbers go up.

The exercise one doesn't work for me. We went for a walk and when we returned, Tim's watch showed 25 minutes exercise and mine showed 1 minute. We had walked the same distance at the same speed, as confirmed by the pedometer. Subsequent tests revealed that I don't swing my arms enough when walking to trigger what ever sensor this is using. I can't quite see why it ignores the pedometer completely, but hopefully this can be fixed by a software update. For now, I just ignore this circle.

Standing is another issue since I use a standing desk, so I stand for many hours each day. Even when standing, I get my hourly reminders to stand. However I use this as a trigger to make me to move about for a minute, so I suppose that is still useful.

Communications

The various forms of communication are a real strength of the watch. With Tim & I both having watches, we can phone, message (audio or text) and use the new Digital Touch to send sketches, taps or heart beats. While it feels a bit weird to be talking to your wrist, this works really well and the sound quality is amazing for such a small device. If you need more privacy, it is very easy to transfer a phone call back to your phone.

Oddly, the watch does not appear to offer FaceTime but always uses standard phone calls.

Messages are where the watch excels. If you get a message with a question, the watch can suggest possible answers so you just have to tap a button. Even without this, there is a set of pre-defined answers which you can edit in the Apple Watch app on your iPhone. And you can also use dictation or the new animated emojis. Dictation seems a lot better on the watch than it ever was before on the phone. And even if dictation is not transcribed perfectly, you can send the message as an audio recording instead of text.

When recording, tap the Done button as soon as you have finished speaking. The inclination is to wait for the text to be processed, but the recording carries on, so stop the recording and let the text processing finish in its own time.

The animated emojis work when you send them to other devices as they appear as GIFs. You can choose from 3 sets: faces, hands and hearts. Once you have swiped to select a set, use the crown to scroll between the options. You can also swipe further to get to the standard emojis.

Digital Touch works between watches only. It is a fun gimmick and I can imagine us developing a set of key codes or sketches, but neither of us can draw very well, so the sketches are very rough. The heart beat is amusing, but the tapping is surprisingly effective as an attention-getter.

Summary

I think this is the start of a new way of interacting with our technology in a way that is both closer to us and less intrusive. I am loving the watch so far and can't wait to see where it goes from here.

Time In Words 4.0

2015-04-15T00:00:00Z

Time In Words for iOS started off as a fun gimmick, emulating the Qlocktwo type of time display where the relevant words are highlighted in some way to spell out the time as a sentence. This very quickly evolved into what I hoped would be more useful app, still showing the original display, but also providing the current time & date as complete sentences. Then I added time conversions and discovered the real power and utility of writing out times as words.

When it comes to converting times, I doubt there are many people in the world who haven't had problems.

Is that morning or afternoon for them?
Are they in tomorrow, today or yesterday?
What if they are using daylight-savings?

Having the time written out removes all ambiguity. As an example, Time In Words currently reports very clearly:

In Los Angeles, it is nine minutes to ten on Tuesday evening (daylight-savings time).

When writing Time In Words for Mac, I focussed immediately on the time zone conversion facilities, and provided a menu bar app that can display as many time zones as you like (although more than will show on a single screen would probably get annoying).

So when I decided to do a complete re-write of Time In Words for iOS, the obvious move was to emulate the Mac version and allow for as many time zones as the user wants, instead of the current 2 or 4 (iPhone or iPad). So I discarded the Qlocktwo display and the separate date display which used a similar mechanic. I kept the display that shows the current date and time, but every display after that shows the time in a different time zone. The time zones can be changed and re-ordered, so the ones you need most are the fastest to get to once the app opens.

One new feature (again taken from the Mac version), is the ability to calculate "What time will it be..."

You dial in your local date and time to see what time that will be in your selected zone. And if you want to calculate the other way around, tap the "Swap time zones" button.

The main impetus for a re-write was the Apple Watch. I thought this would be a perfect app for the watch as it could use the Apple Watch's superb time-keeping in conjunction with my text generation, to add a significant level of usability to the Apple Watch as regards time zone conversions.

Sadly, Apple disagrees…

I completed the app and submitted it to the App Store for review. The review process seems to be very fast at the moment and the app moved into review only one day later. And there it stuck for 3 days. This was very odd. My experience is that once an app gets into review, it only takes a few hours, if that. For 19th Hole - my other app with an Apple Watch component, the review process took 30 hours. But 3 days!

Then I got a phone call from Apple where a very polite person explained to me that although this was not mentioned in any of the documentation, the marketing people had decided that no apps were to be allowed on the watch if they told the time.

I offered to remove the initial screen telling the local time, so the app would not actually supply the current time but only the time conversions, but that was not acceptable either.

Then I tried appealing the rejection. My hopes were not high, but I didn't see any harm in asking. I again offered to remove the local time display and emphasised the accessibility advantages of displaying times in this manner. Another day, another phone call, another polite Apple person saying no.

So now I have re-submitted the app for review without the Apple Watch component, which is a shame. I am hoping that after some months they will review this policy and allow me to try again, but who knows.

So you can see what you are missing, here are a couple of screen shots from the watch app showing my local time, plus one time zone:

One more minor point. People who actually look at version numbers may wonder why I have gone from version 2.5 to version 4.0. When I was working on version 2.5, I considered making it version 3.0 and then changed my mind. However by that time I had already created a version 3.0 in iTunesConnect, so I was not able to use 3.0 again this time. This version was such a big change that I wanted it to be a .0 release, so that meant going to version 4.0

Apple Watch App - Rejected, then Accepted

2015-04-11T00:00:00Z

As described in a previous post, about 9 days ago I submitted my first Apple Watch app for review. The app was an extension of my golf scoring app: The 19th Hole.

I expected that App Store review times would go up dramatically once Apple had allowed developers to submit watch apps, but this proved to be incorrect. Three days after submission, the app was marked as "In Review". This seemed to happen last thing on a Saturday, so there was no further action for two days, at which point the app was rejected, with the following details (sic):

We noticed an issue in your app that contributes to a lower quality user experience than Apple users expect. Specifically,

while using the Apple Watch app with the phone app is in the background mode (display off), the new data entry on the Watch App does not refresh accordingly until the phone app is turn back on.

So it appeared that the communication between the watch and the phone, which worked perfectly on the simulators, did not work at all on the actual devices. This is the problem with developing for a device that you do not have.

After some research, it appears that the problem is with the phone not operating correctly in background mode. Apple provides for communications from the watch to the phone. The phone can respond, but only the watch can initiate a connection. I guess this makes sense since every watch will be paired with a phone but the reverse will not always be true.

To talk to the phone, the watch uses this function:

func openParentApplication(_ userInfo: [NSObject : AnyObject],
  reply reply: (([NSObject : AnyObject]!, NSError!) -> Void)?) -> Bool

The phone listens for messages in this event handler:

func application(_ application: UIApplication,
  handleWatchKitExtensionRequest userInfo: [NSObject : AnyObject]?,
  reply reply: (([NSObject : AnyObject]!) -> Void)!)

The name of the WatchKit function is slightly misleading as it does open the parent application, but only in the background. Then the parent app is supposed to do whatever tasks are called for in the handleWatchKitExtensionRequest function, and return any required data using the supplied reply() function.

So far, so good, and it all worked perfectly in the simulator. But it appears that although this call wakes the iPhone app, it does not stay awake long enough to do anything. Many thanks to Brian at Five Minute WatchKit who pointed out the way to make this work. Firstly, you create a dummy background task guaranteed to keep the iPhone app awake for 2 seconds. Then you perform your own work, using another background task. When that is finished, the phone can send the response and end the real background task. The dummy task will time out by itself after 2 seconds.

For my needs, I could probably reduce the 2 seconds considerably, but since this is a problem I am unable to test, I decided just to go with Brian's suggestion as it is.

I re-submitted the app the same day it was rejected, and two days later it was back in review. The review process took longer than usual, but about 30 hours later, the app was marked "Pending an Apple Release". I assumed this meant that Apple would release all WatchKit apps on 24th April when the watches shipped, but the following day the app was reported as "Pending Developer Release" (I had set it to release manually). Now I have told iTunesConnect to release the app and it is "Processing for App Store".

On a related note, the start of pre-ordering for the Apple Watch was scheduled for a very civilised 5:01 pm here in eastern Australia. I had three watches all lined up in my Favorites in the Apple Store app, ready for ordering. When the store became live (at about 5:03 pm), I could not work out how to order all three in a single operation, so had to place these orders one at a time. I got the first two ordered for the soonest possible delivery, but by the time I got to the third (about 3 minutes later), I had missed out and it will ship in 4 to 6 weeks!

My First Apple Watch App

2015-04-02T00:00:00Z

I have just submitted my first Apple Watch app to the iTunes App Store. This is a scary thing to do, since I have never seen, touched or used an Apple Watch and all I had to go on was the Simulator that Apple supplies with Xcode.

At the moment, Apple has only made a limited set of Apple Watch features available to developers, and all Apple Watch apps come tethered to an iOS app - presumably this will mainly be iPhone apps, but I wonder will we be able to connect Apple Watches to iPads? Anyway, it made sense to extend one of my existing apps to use the Apple Watch instead of starting from scratch.

Of my iOS apps, I decided that The 19th Hole, my golf scoring app, would be well suited to the Apple Watch. The problem with using the iPhone version to score is that you have to keep pulling your iPhone in and out of your golf bag, sometimes in the rain, sometimes in bright sunlight. Being able to enter the scores on your wrist sounds like a big improvement. We know that the Apple Watch is at least somewhat water-resistant, but we are yet to see how well it performs in bright sunlight, however I would expect that Apple has put considerable effort into this.

Once I decided to write an Apple Watch app, the first step was to learn how. I read all Apple's published documents to get a feel for what was possible and what user-interface objects would be available. I find online courses very helpful and by far the best Apple Watch course that I found was Ray Wenderlich's WatchKit video tutorial series. The instructors were very clear and explained how the layout and sizing of objects works on the Apple Watch, as well as how to set up and move between views and how to communicate from the Watch back to the iPhone. The layout section of the course was particularly valuable as no other course I found even mentioned this, although it is crucial to the interface design and allowing for the two sizes of watch.

I had released an update to The 19th Hole recently in preparation for this. I wanted to have squashed the bugs and updated the interface, so the only changes needed would be the WatchKit ones.

The first step in adding a WatchKit app to your existing app is to create a new target in the Xcode project. Choosing WatchKit actually adds two new targets: the WatchKit Extension which lives on the iPhone and supplies the code for the Watch, and the WatchKit App which lives on the Watch and provides the interface.

I decided to use a paged interface with one page per hole. Each of these pages has a table, with one row per player. A slider with plus & minus buttons lets you enter the score for each player and the total score for each player is also displayed.

Apart from this data entry view, I have a splash screen which shows you the current round as set up on the iPhone and a final summary screen showing everyone's totals.

These images are taken from the Apple Watch simulator running in 42mm mode.

The biggest programming problem was getting the communications working beween the two devices. The 19th Hole uses Core Data for all data storage. My first attempt shared this data between the two apps, allowing both to read and update the database. This almost worked, but if both apps were open, then changes in one device did not get across to the other. It seemed that the data was cached and I was unable to find a way to force either app to update every time.

My next attempt kept all the data in the iPhone app and had the WatchKit extension ask for whatever data it needed and send changes to the iPhone app. This worked much better and I was able to get live updates between the two devices.

The other issue is the fact that I have never seen, touched or used an Apple Watch. This means that I had to guess a lot of things:

how well will it perform?
will the icon look OK?
are the controls large enough to use?
will the text be large enough to read?

My main philosophy was to keep the Watch app as simple as possible and use the standard interface elements, font sizes etc. Hopefully that will work.

The final step was submitting the app to iTunes Connect for review. It was not clear to me how to do this, so I logged into iTunes Connect, created a new version and entered the meta-data. I couldn't see anywhere to say anything about the Watch. I archived the main iOS app as usual and validated it with the Store. I had a few things to fix up, but I got the build submitted.

Back to iTunes Connect and once the uploaded build had been processed, I was able to select it and click "Submit for Review". At this point, the page reported an error and showed me a new section where I could upload the Apple Watch icon and screen shots.

I had been unsure how the icon would look when made round, but it looks OK on the iTunes Connect page. How it will look on a tiny watch screen remains to be seen. Anyway, once I had my icon and screen shots uploaded, I was able to proceed to the next step. But then I got a message saying that the app could not be processed - no explanation. Thankfully, I had seen some developers on Twitter reporting this, and somebody said that the solution was to remove the alpha channel from your screen shots. Sorry for not giving credit here - I forget who said this, but it worked, so thank you whoever you are.

So now my app is waiting for review and who knows how long that will take. According to App Review Times, the current estimate is 8 days, but the trend is heading upwards. I would expect that to blow out in the next few weeks as developers try to get their apps ready for the Apple Watch release date of April 24th.

LiveCode stacks

2015-03-18T00:00:00Z

When I converted my site to Jekyll & GitHub, one of the things I left behind was a collection of LiveCode (Revolution) stacks. For many years I was active in the Revolution community before going in other directions and over that time, I built up a small library of stacks that I released into the public domain.

LiveCode is a cross-platform rapid development environment. There is an open source community edition available for anyone wishing to get started.

I had assumed that since I had not been an active LiveCode user for many years, these stacks would have become worthless. But in the last couple of days, I have received a couple of queries from people looking for them.

So I created a new GitHub repository and uploaded them all to here:
LiveCode stacks

None of these stacks have been updated recently, but feel free to use or adapt as you see fit. They have not been tested using recent versions of LiveCode, so may not work as expected. As stacks are provided as is. Use at your own risk.

Icon Builder 3.0.1

2015-03-17T00:00:00Z

So why an announcement for such a minor upgrade?

Version 3.0 got no announcement because it was not the release I wanted.

Having downloaded the Xcode 6.2 & 6.3 betas, I had worked out what icons were needed to a WatchKit app. This, combined with several other changes, made me bump the version number to 3.0.

Sadly, Apple rejected the update because it referred to pre-release products. So I pulled all mentions of WatchKit out of the interface and meta data and got 3.0 released.

After the Apple keynote on March 9th, I re-enabled the WatchKit portions of the app and re-submitted to the App Store, hoping that with the WatchKit SDK now part of the official Xcode release, Apple's reviewers would allow it to get through this time.

This worked - in fact the app was reviewed and accepted within 6 days - so now Icon Builder adds WatchKit to its list of supported platforms.

Actually, Apple may have done me a favour in rejecting the first one as they changed the specifications for the icons slightly between Xcode 6.2 beta and Xcode 6.2 release.

What’s New in version 3?

Support for WatchKit app icons (version 3.0.1)
Simplified interface: removed display of smaller icons.
Fix for @3x images not being saved when you selected iOS 6 support.
iTunesArtwork@2x file now saved as a JPG to avoid iTunes Connect errors.
Removed CarPlay icon - Xcode sometimes gave errors when this was included.

App Store Preview Videos

2015-03-16T00:00:00Z

Apple now allows app developers to add a video preview of their app when uploading to iTunes Connect. This video is shown to potential purchasers when they are looking at an app in the iTunes App Store, just like the screen shots.

I have been working on an update to 19th Hole and since it uses a custom method for data input, I decided that a video would be really useful in this case.

The first step was to work out how to record video from my iPhone. In OS X Yosemite (10.10), this can be done using QuickTime Player. Connect your device to your Mac using a Lightning cable (I think it has to be a Lightning cable - the old cables will not work). Open up QuickTime Player and choose "New Movie Recording" from the File menu. By default this shows input from the Mac's FaceTime camera, but just to the right of the red Record button, there is a down arrow that shows a popup menu. Click this and you can select your iPhone as the Camera. Since I wanted the sound effects included, I also selected my iPhone as the Microphone, but if you want to provide a voice-over or sound-track, you might want to change this.

That handles the technical side of recording, but I needed a way to show where I was tapping and pressing on the iPhone screen. After some searching, I found Touchpose which was exactly what I wanted. Since it requires changing the main.m file, as well as changes to the app delegate, I created a branch in my app's git repository so that I could apply these changes temporarily, but save them for next time. The only alternation I made to the default settings was to change the color of the cursor indicator to suit the color scheme of my app. And since this was a temporary change, I set it to show the cursor indicator all the time, not just when the screen was mirrored. All the details are shown in the sample project.

Next step was to actually record a session. After my first attempt (which lasted about 67 seconds), I checked the Apple specs and found that the video could not be longer than 30 seconds. So I re-thought what I wanted to include and tried again. It took a few tries to get what I wanted, but finally I ended up with a .mov file that was 26 seconds long.

On to iTunes Connect where I had the new version of the app set up already with its screen shots. Since I have an iPhone 6, the video was only suited for the 4.7 inch section. So I dragged it into the drop zone and waited. No good - the video frame rate was too high. It has to be 30 fps or less. QuickTime Player had made a video that was 50 fps.

The app I usually turn to for any video conversion needs is Handbrake. So I ran the app through Handbrake, specifying a frame rate of 30. This converted the video to .mp4 instead of .mov, but it was 30 fps. It wasn't until I tried to upload it to iTunes Connect that I realised Handbrake had cropped the video from 750 x 1334 to 750 x 1330. After searching through the settings, I found where I needed to turn on custom clipping and set it to 0 so that the original dimensions were preserved. But iTunes Connect still didn't like it, although this time the error message was un-informative.

Eventually, the brains trust on the other side of the room suggested iMovie. Not only that, but he found that once the original had been dragged into iMovie, the share options included an "App Preview" setting. This gave us a .mov file of the correct dimensions and the correct frame rate which iTunes Connect accepted.

iTunes Connect that allowed me to select the poster frame for the video and save the changes to the app meta data. At that point, it showed a notice saying that the app preview was being processed which could take up to 24 hours. It appears that the processing has been finished, as that notice has disappeared.

For the next stage, I ned to wait until the app gets reviewed and hopefully approved. Then it will be interesting to see how the video looks in the iTunes App Store.

As a reward for reading this post, here is a pre-release of the video, showing how to enter the score data for a hole of golf using 19th Hole:

Your browser does not support the video tag.

Testing automation

2015-03-12T00:00:00Z

Today I am experimenting with automating post generation.

Firstly, there is the structure of the post Markdown document, which really boils down to the file name and the header.

I have set up a macro in Typinator so that I just type the title of the post in a text document. I copy that title to the clipboard and type the shortcut. The header is then created with the title and the formatted permalink.

To save the document, I use another Typinator snippet to convert the title (still in the clipboard) to lower case and to replace the spaces in the title with dashes.

For starting the local Jekyll server, I have turned to an Alfred workflow. I have two actions in the workflow. One opens Terminal, cd's to my site folder and runs the command to start the local Jekyll server. The second opens my default browser to the local Jekyll test address.

Both these actions happen simultaneously so the browser usually fails until refreshed. The server is left running in Terminal so I can shut it down when finished testing.

After writing the post, the final stage is to publish, so I need to work out the commands for doing a git commit and push. Then I should be able to automate those tasks.

Testing the git commands using Terminal, I have come up with the following sequence:

git add . git commit -a -m "Commit message here" git push

The commit message could be the title of the post, so I need a way to construct the command and then execute it. Typinator is good at text manipulation, so I constructed another macro that takes the clipboard, uses it as the commit message and performs the git commands. This gave a good commit message, but the actual commit failed, so that was no use.

So then I went back to Alfred and created a workflow there with a series of Terminal commands to perform the actions above. This only allows a generic commit message, but it works as expected.

So there is still room for improvement, but with a set of macros, I can automate a lot of the standard text entry, which is always good for reducing errors.

The sequence now is:

Open the text editor and type the title of the post.
Cut this into the clipboard.
Run the Typinator macro to fill in the post header.
Save the post file, using the Typinator macro to construct the file name.
Write the post, then use an Alfred workflow to test it locally.
When ready, use an Alfred workflow to publish.

Workflow for writing a post

2015-03-10T00:00:00Z

So here is where I need to get used to Jekyll and how things are done. I will end up automating this when I am sure of the process, but for now, I am just going to work my way through it.

Start up the local Jekyll server:
- I opened Terminal and used cd to get to the folder containing my site.
- Next I started the Jekyll server locally using jekyll serve.
- This gave me the address of the local server - in my case http://127.0.0.1:4000/ - so I went there in my browser to see the default page.
My goal is to write a new blog post (this one in fact).
- For advice on creating a new post, I went to the Jekyll docs.
- Jekyll needs the file name to be a specific format which includes the date and title.
- Looking in the _posts folder of the site folder, I see the previous post file is titled 2015-03-08-new-site-for-trozware.md.
- As it is now 10th March 2015, I am saving this file as: 2015-03-10-workflow-for-writing-a-post.md.
- Saving at this point shows a Jekyll error in the Terminal, but the next stage will fix that.
Front matter:
- Jekyll specifies that each file must have a front matter block in a certain format.
- The header has certain essential parameters and then more optional ones.
- My site was imported from WordPress, so the older posts contain several header parameters that may not be necessary any more.
- Look at the screen shot below to see what I have in this post file:
- After saving, I see this entry in my Terminal:
- Regenerating: 1 file(s) changed at 2015-03-10 13:50:40 ...done in 0.421789 seconds.
- Now I can see the title and the start of the post on my first page and when clicking on it, I can see all the text.
Adding an image:
- This is not really necessary for this post, but I wanted to document it as part of the workflow.
- I wanted to show the front matter and start of this post, so I took a screen shot of the top of my editor window.
- Then I renamed the image file and moved it into the images folder of my site.
- Now to embed the image using this Markdown: ![Post header][2]
- As you can see, I prefer to group all links (images & URLs) at the end of the document and keep the body of the text as clean as possible.
Proofing:
- Now that I have the text of my post, I need to proof-read it from the local Jekyll server.
- The jekyll serve command running in Terminal keeps the pages up-to-date as you edit, but you will need to refresh your page in the browser manually to check your changes.
- And I have found that if you make a major change to the site e.g. a CSS file or a config file, then it is best to stop the Jekyll server and start it again to make it re-build all the files.
- To be completely sure, stop the server and run jekyll build in Terminal although this may only do what jekyll serve does on startup anyway.
Publishing:
- Now it is time to publish.
- As I am using GitHub Pages to host, the site files are all part of a single Git repository.
- And as I understand it, the data must be in the master branch.
- Opening up the GitHub client, I see that my repository has a bunch of changes: - the file I am working on - the image I inserted - feed.xml - index.html files for each page
- This is as expected, since all pages are pre-generated when using Jekyll, so pages of posts must be re-rendered when a new post is added to the top.
- Note that several of the files appear twice: once from where they are edited and once from the _site folder which serves them.
- Just two simple steps now, using the GitHub client: 1. Commit 2. Sync
- And that's it. My new post is online and ready for reading.
Summary:
- This was my first post after the one I wrote when setting up, so the first real post.
- While there appear to be a lot of steps, none of them are difficult.
- But I do have 4 apps running to do it: 1. TextWrangler for editing 1. Terminal to run the local Jekyll server 1. Safari to check the finished post 1. GitHub to commit and upload
- Automating this is an obvious next step, so stay tuned...

New Site for TrozWare

2015-03-08T00:00:00Z

Welcome to TrozWare's new site.

It appears that I am not alone in deciding to move away from WordPress. WordPress is great - easy to set up and with lots of cool themes to allow customisation of your site. But it is slow, especially if (like me) you are running on a low-cost shared server.

I had been reading about Jekyll, so I decide to give it a go and also host my site on GitHub, taking advantage of their faster servers.

I followed the advice given by Girlie Mac and performed the migration from my self-hosted WordPress site. I am using the Pixyll theme by John Otander with a few tweaks of my own. The site is much faster to load, and I am hoping that the easier editing will inspire me to write more posts.

Of course it wasn't all positive. WordPress did give me some features I liked, but I think overall the result is better.

WordPress

WordPress gave me a full LAMP stack, so I could run my own PHP scripts.
WordPress gave me a search function.
Commenting was built-in.

Jekyll

Jekyll builds the pages out as static HTML, so all pages are pre-generated for fast loading.
Writing for Jekyll is pure Markdown so it is easier to write and preview locally.
Some of the things I needed a plugin for in WordPress can be done natively in Jekyll: - tables - syntax-highlighting

For comments, I have switched to Disqus, but I am not sure about it yet. I will evaluate over the next few weeks. In WordPress, I used a plugin to handle the spam that inevitably arrived. I am hoping that Disqus will protect me from that, but I have to see how good a job it does and whether the few real comments are worth it. A better option might be to turn off comments completely and just have a contact form (which I have added using Formspree). Working in Markdown is great. I love how I can have a really clean look in my editor and still end up with well formatted HTML. I use Coda 2 on my Mac as my standard web editor, so that is what I am writing in now. I will probably experiment with other Markdown editors as I go. And for any Mac users out there working in Markdown, I highly recommend Brett Terpstra's Markdown Service Tools.

Man Reader 1.4 Now Available

2014-04-03T00:00:00Z

Man Reader 1.4 is now available through the Mac App Store.

The new features and fixes are:

Fix for plain text view not wrapping correctly for odd-sized fonts.
Fix for HTML text view over-riding font colors that may be invisible.
Search for missing entry (e.g. g++) no longer requires Enter or Return.
Better automatic selection of matching entries while searching.
Fix for animation warning message appearing in Console.
Status display shows when man page list is being updated.
Searching inside a page now allows a minimum of 2 characters (was 3), so flags
e.g. ‘-b’ do not need to be escaped.
Fixed path for Network Utility in tool bar (moved in OS X 10.9).
More information available about the effects of sand-boxing for this app.

Email clients for Mac and iOS

2014-03-25T00:00:00Z

Some people are moving away from email, but for me, it remains the best way to communicate online. I get to keep a record of conversations and the attached files are with the text so I can always see the context.

But I think everyone would agree that Apple have dropped the ball with Mail in OS X Mavericks, and to a lesser extent, in iOS 7.

So I have been on a campaign lately to find an email client that suits my needs. I don't feel that I have found the perfect answer yet, but I am getting there.

The first step was to work out what I really needed in an email client:

support for IMAP accounts and Gmail accounts
unified inbox - all accounts shown together
conversation threading
support for POP accounts (optional)

On the Mac, I have narrowed it down to two clients that I am swapping between every few days: Unibox and Airmail.

Unibox is different in the way it displays your emails. It is much more focussed on people and conversations, so the side bar shows all the people who you have sent emails to or received emails from, grouped by date. I really like the merging of incoming & outgoing emails, but it can be a bit weird if you delete the latest email from someone who then disappears from sight.

Emails are grouped by a single person, not by conversation. There is a button on appropriate emails to toggle conversation view for that particular thread, but it doesn't stick.

In order to show a conversation, they truncate emails in the main part of the window and show a "More" button at the bottom of the email to expand it. This was annoying, but in the latest beta, it performs much better, so you are not continually tapping this to see a long email.

Airmail has a more conventional display. Threading and the layout of threaded emails are both very nice. There are multiple view options, which I find can get a bit messy looking, so I prefer the "Minimized View" setting. Airmail also does POP accounts which is a plus.

The main reason I keep going back to Unibox is the unification. I have grown to like having sent and received messages all in the same window without having to go and find them somewhere else.

On the iPad, I am currently using Boxer and have tried numerous others. Molto was quite good and the interface was fun, but it would only use landscape mode and like to be able to swap. Boxer is not great in portrait mode, but it does work.

So the jury is still out for iPad email clients, but on the Mac, I am leaning towards Unibox.

TrozWare

In Praise of SwiftUI

Data Flow

User Interface

AI

SwiftUI Problems

My Plans

macOS Apprentice: 3rd Edition

Contents

Where Can You Find the Resources?

Thanks to...

Feedback

Playing in the Mac App Sandbox

Table of Contents

What does the Mac App Sandbox do?

App Sandbox Settings

Network

Hardware

App Data

File Access

Using NSOpenPanel

Using fileImporter

Saving URLs

Temporary Entitlements

When You Must Turn Off the Sandbox

Why Use the Sandbox At All?

NSTableView scroll bug in macOS Tahoe

The Problem

Investigating the Problem

Finding the Solution

Conclusion

Moving from Process to Subprocess

Black Friday Sale

macOS Apps Step by Step

Escape from Tutorial Hell

macOS Apps Step by Step 4.0

Apple Has Two Problems

Politics

The Solution

Software Quality

The Solution

SwiftUI WebView

1. WebURLView

2. WebPageLoad

3. TrackLoad

4. CustomScheme

5. JavaScripting

6. Browser

Summary

SwiftUI for Mac 2025

App icons

New look controls

Buttons

Numbers

Web view

Rich text

Long lists

Menu item icons

Concurrency

Toolbars

Summary

WWDC 2025

Version Numbering

Liquid Glass

Xcode

SwiftUI

Swift

App Icons

iPad Windowing

Developer Relations

Conclusion

New Book: Escape from Tutorial Hell

Go Beyond Coding: Build, Ship, and Maintain Real Apps

Contents

Section I: Configuring Your Tools

Section II: Designing the App

Section III: Setting up the Data Flow

Section IV: Working With Xcode

Section V: Coding with AI

Section VI: Distributing the App