DEV Community: TrozWare

Moving from Process to Subprocess

TrozWare — Thu, 27 Nov 2025 23:07:22 +0000

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 result 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.

macOS Apps Step by Step 4.0

TrozWare — Wed, 05 Nov 2025 23:44:23 +0000

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.

SwiftUI WebView

TrozWare — Fri, 15 Aug 2025 11:11:18 +0000

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 my Contact page. And if you found this article useful, please buy me a coffee.

SwiftUI for Mac 2025

TrozWare — Thu, 31 Jul 2025 16:20:00 +0000

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.

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

App icons
New look controls
Web view
Rich text
Long lists
Menu item icons
Concurrency
Toolbars

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.

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.

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 my Contact page. And if you found this useful, please buy me a coffee.

Apple Developer Relations

TrozWare — Tue, 20 May 2025 23:53:52 +0000

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 my Contact page. And if you found this article interesting, please buy me a coffee.

Swift Measurements

TrozWare — Wed, 16 Apr 2025 09:47:17 +0000

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 via my Contact page. And if you found this useful, please buy me a coffee.

Moving to Eleventy

TrozWare — Wed, 19 Mar 2025 04:15:33 +0000

I have been running my blog at troz.net 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

TrozWare — Thu, 06 Mar 2025 11:22:21 +0000

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.

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 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.

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.

The Mac Menubar and SwiftUI

TrozWare — Mon, 17 Feb 2025 07:16:34 +0000

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 its 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

TrozWare — Mon, 23 Dec 2024 04:22:15 +0000

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

TrozWare — Wed, 06 Nov 2024 06:29:20 +0000

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 theswift-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 the Contact page on my site. And if you found this, or any of my articles useful, please buy me a coffee.

App Permissions on macOS Sequoia

TrozWare — Wed, 02 Oct 2024 01:33:26 +0000

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 the Contact page on my site. And if you found this article useful, please buy me a coffee.