notes from /dev/null - macos

F16 F17 F18

2025-12-30T15:00:00-08:00

A significant user interface improvement I made to my desktop experience on macOS this past year has been to globally bind the function keys above the number pad on a full-sized keyboard to window management commands, in particular to move a window either to the center, left, or right of a large monitor. On reflection, this seemingly modest change has surprisingly transformed how I manage windows now. If this seems interesting, please read on.

My usual work environment is setup like this:

Laptop in clamshell mode, connected to a single monitor, keyboard, and mouse.
I have the setting “Use F1, F2, etc. keys as standard function keys” turned on.
For my keyboard, I use a stock Apple USB full sized keyboard (A1243) that has the row of function keys F16-F19 on the top row of the number pad as shown in the image below.

The following table specifies the bindings I use for these number pad function keys.

Key	Command
F16	Move to top left, without resizing
F17	Center
F18	Move to top right, without resizing

These bindings can be implemented using a 3rd party app like ‎BetterSnapTool or by configuring a keyboard shortcut via the macOS Settings app. As a happy BetterSnapTool user, I’ve configured it as shown below:

Users wanting to use what is built into macOS (Sequoia 15 or greater) can go to System Settings… › Keyboard › Keyboard Shortcuts… › Windows to customize the bindings to their preference.

Closing Thoughts

If you’ve followed my work on Casual you'll know that I’m not a fan of long key bindings that take up three or more keys to be pressed. Dedicating function keys to do basic window management has been far simpler to adopt in my interactions with a computer. It seems obvious with 20/20 hindsight, but simply centering a window with a single key press has done wonders for my ergonomics.

I acknowledge that this post is bespoke to me. If you don’t have a lot of function keys to spare, you'll likely find little of value here. But if you do have three spare function keys, I highly recommend binding them to window management commands. Give it a try - I think you’ll be pleasantly surprised.

Capturing an Org note via macOS Shortcuts

2025-07-02T14:30:00-07:00

With a new update of Scrim v1.1.0 on the App Store, it seems an opportune time to show a nice macOS Shortcut integration with it.

The use case is this: You're on your Mac, working on something else other than Emacs (it happens!) and you want to make a quick note in an Org file without having to context switch to Emacs.

You can accomplish this with a macOS Shortcut. Shortcuts is an Apple tool that lets you orchestrate different apps to achieve a custom workflow.

Shown below is the shortcut named “Make Note Entry” to accomplish the above use case. It will:

Prompt the user to enter text.
Run a Python script on that text and construct an Org protocol capture request with it using the template named "note".
Issue (open) the Org protocol request.

If the shortcut is configured so that “Pin in Menu Bar” is turned on, you will see some variant of its entry in the Shortcuts bar icon menu.

Running the shortcut “Make Note Entry” will prompt you with a dialog where you can enter your note:

Pressing the “Done” button will result in the entry being inserted at the top of the file “~/org/notes.org” as shown below. Note however that Emacs is not raised with this shortcut. The screenshot below is only shown to illustrate that the entry is there.

Installation

Want to try this out? Here’s what to do:

1. Understand Org protocol

If you don’t already then read up about it at org-protocol.el – Trigger actions in Emacs via a custom URL scheme.

2. Have Scrim installed and configured

Learn more about Scrim at http://yummymelon.com/scrim.

3. Add the capture template “note”

On the Emacs side, add the following template entry to org-capture-templates. This template named “note” defines an entry with a heading that has an inactive Org timestamp (“%U”) and the body containing the entered text (“%i”). The destination of this note entry is in the file “~/org/notes.org”

("note"
 "Note (Org Protocol)"
 entry
 (file "~/org/notes.org")
 (function (lambda ()
             (string-join
              '("* %U"
                "%i")
              "\n")))
 :prepend t
 :immediate-finish t
 :empty-lines-after 1)

Observe that this template uses the keys :immediate-finish to not make the entry interactive and :prepend to insert the entry at the top of the file.

4. Add the Shortcut “Make Note Entry”

Download the shortcut file Make Note Entry.shortcut and double-click on it to install. It should now be in your Shortcuts collection.

5. Run “Make Note Entry”

On the first run of this shortcut, you will be prompted twice to give it permissions: 1) to run the shortcut and 2) to open Scrim. Inspect that its contents correspond with its screenshot above and grant them.

Closing Thoughts

Readers are invited to take these ideas and customize them for their own purposes.

Migrating MacPorts in 2024

2024-09-17T15:30:00-07:00

At long last, MacPorts has built-in migration support for whenever there’s a major macOS upgrade. I learned of this today thanks to Harry Sintonen’s Mastodon post. You’ll need to be running a version of port that is ≥ 2.10.0.

Migration now (at least on paper) is much simpler. After updating your version of the Xcode command line tools, you just run:

1	`$ sudo port migrate`

Before 2.10.0, migration required a lot more hand-holding. It was easily one of my least favorite sys-admin things to do.

Staying true to my general policy of migrating, I’m waiting until the release of macOS Sequoia 15.1 before migrating MacPorts. I've elaborated more about this in an earlier post which I highly recommend for those new to MacPorts.

My most heartfelt thanks to all who are shaking things out to get the MacPorts ecosystem stable until then.

References

Administering MacPorts

An accidental lock-in feature of the Apple ecosystem

2024-06-12T01:25:00-07:00

It’s WWDC week, when Apple shines their spotlight on its developer ecosystem every June. Given the moment, I’d like take this opportunity to give all the flowers to the unsung developers who have built and maintained a feature in Apple products that I hold quite dear: the Emacs keybindings in Apple UI frameworks.

If you don’t know, when using a macOS native app like Notes, OmniGraffle, or Safari, you can use the following keybindings in any text field:

C-a - move cursor to beginning of line
C-e - move cursor to end of line
C-f - move cursor forward one character
C-b - move cursor backward one character
C-k - kill text to end of line
C-y - yank killed text (mostly, more on this later)

It can not be overstated how extraordinarily convenient this feature is to Emacs users. Even more astonishing is how this set of bindings has continued to be maintained (since 2001!) across the different OS variants Apple ships (macOS, iOS, iPadOS, tvOS).

Backstory

My anecdotal understanding of this feature’s history is that it started with the NextStep OS back in 1988. The developers of NextStep used Emacs and so whenever they typed in the text widgets of the NextStep UI, they naturally wanted to use Emacs bindings. It was unlikely that this was ever an exec-level requirement. But the developers wanted it, so they made it happen.

Fast forward in time, NeXT effectively acquires Apple and in doing so repackages the NextStep frameworks to ship Mac OS X (now called macOS). This decision fatefully keeps NextStep’s text system and its conventions intact in the UI framework called AppKit as part of family of frameworks called Cocoa. Fast-forward to 2007, the iPhone becomes a thing. Apple makes another fateful decision to build iPhone OS (now called iOS) off of Cocoa but create a new touch-based UI framework called UIKit. UIKit’s text system is heavily influenced by Cocoa where it too carries over the Emacs keybindings. Variants of iOS in the form of iPadOS and tvOS come to be, further propagating these keybindings. In 2019, a declarative UI framework called SwiftUI is created where its text system too adopts the Emacs keybindings.

Configuring Keybindings in macOS

Wonderfully enough, you can still configure the keybindings in AppKit-based apps on macOS using the NextStep style configuration as shown in the Text System Defaults and Key Bindings document. There it provides guidance on adding more Emacs-style keybindings.

Of note is that macOS has always supported an alternate clipboard to emulate the Emacs kill-ring. This works independent of the system clipboard, and requires a bit of configuration to get working. There are two steps to this:

Redefine the keybinding C-y to yankAndSelect:

In the file $HOME/Library/KeyBindings/DefaultKeyBinding.dict (for details see the link above), add the following line in the body between the braces.

"^y" = "yankAndSelect:";

Use the command line utility defaults to set the variable NSTextKillRingSize.

This variable controls the size of the kill ring. Here we will set it to 5.

$ defaults write NSGlobalDomain NSTextKillRingSize 5

You can confirm the value in NSTextKillRingSize as follows.

$ defaults read -g NSTextKillRingSize

Refer to man defaults for more information on it.

At this point, you will need to log out and back in for the new keybindings to take effect.

Caveats

You can’t have everything though as not all apps are built with AppKit. Focusing on only the default Emacs bindings, here’s a survey of the different levels of support for them from the different UI frameworks.

Binding	AppKit/SwiftUI (macOS)	UIKit/SwiftUI (iOS, iPadOS)	Mac Catalyst
`C-a`	Y	Y	Y
`C-e`	Y	Y	Y
`C-f`	Y	Y	Y
`C-b`	Y	Y	Y
`C-k`	Y	Y	Y
`C-y`	Y	N	N

Unsurprisingly, UIKit chose to not support a kill ring, so effectively C-k is a delete function and yanking is not supported. The column for Mac Catalyst is a category of apps built to work for both iPadOS and macOS based largely on UIKit. Such apps include Messages and Stocks.

Closing Thoughts

I’ll never take for granted the repeated decision over the years by the Apple text system developers to keep supporting the Emacs keybindings. While perhaps not intended, this feature quite seriously is an ecosystem lock-in factor for me. It is a gift and to some extent, a secret handshake, that I’ll always be grateful for. To whoever was, is, or will be involved with keeping this feature alive, thank you.

Administering MacPorts

2024-01-31T16:00:00-08:00

When it comes to package managers for macOS, I’ve started with¹ and continue to use MacPorts whenever I can. The reasons for this are largely in line with what Saagar Jha captured in his blog post from 2019 and little since then has changed to convince me otherwise. Over the past two decades (!) I’ve come to some learnings about administering MacPorts, which I’ve captured in this post.

It is not enough to have Xcode installed. You should also install the separate command line tools before installing MacPorts.

In particular, Apple puts certain headers and libraries required by some open-source software into the command line tools package, not in Xcode*.xip. More often than not you’ll want to install software that requires said headers and libraries. Save yourself the guesswork and install the command line tools anyways.

You can do this by running xcode-select in the Terminal.

1	`$ xcode-select --install`

At its core, MacPorts is a 90’s-style solution to package management.

The design of MacPorts is heavily influenced by the Ports system from FreeBSD. Ports was designed to solve a 90’s-style problem in package management: How do you distribute for many different Unix variants either from different vendors or different OS versions? Ports took this tack: Download the source, configure for the local environment, and build. That said, since 2011 MacPorts can ship binaries to speed things up but only under certain conditions, particularly with regards to CPU architecture, OS version, and licensing.

Probably the biggest benefit of local building from source is the higher likelihood that you will be running an executable that is tuned to your system (CPU architecture and OS version). On older versions of macOS, MacPorts will likely let you build and run the latest version of an open-source tool. For years I had a 2010 iMac with macOS 10.13.6 High Sierra that could still run the latest versions of open-source tools, extending its useful lifetime as a development system.

Probably the biggest frustration of building from source is dealing with package dependencies. Installing a package with many dependencies (looking at you ffmpeg) can feel like MacPorts is building all the things, because it is.

OS upgrading is a deep operation in MacPorts.

Because MacPorts tries to tune itself to a particular CPU and OS version, whenever there is a macOS upgrade, the recommended guidance is to migrate your install of MacPorts. Effectively this means reinstalling your packages for every OS upgrade.

Pragmatically there are a couple of gotchas with this.

At the time of the macOS release, not necessarily all the software packages have been updated to support it. More often than not, rebuilding the package will break.
You will need to upgrade Xcode and the command line tools that go along with the OS upgrade before MacPorts migration.
There are a lot of steps involved with MacPorts migration. For users (particularly those used to primarily GUI driven flows) this can be both cumbersome and error-prone. (Why this step has not yet been automated still bewilders me.)
If you use a shell provided by MacPorts (configured using chsh) then you must remember to revert back to the default macOS installed shell (typically /bin/zsh) before MacPorts migration.

Being burned multiple times over the years with the above has led me to this guidance: Only upgrade the OS and migrate MacPorts when the .1 OS release comes out. While by no means bulletproof, this strategy gives you a higher likelihood of success in migrating MacPorts to the upgraded OS. Admittedly there are years when you must upgrade the OS and Xcode before the .1, particularly if you are an iOS developer. Under such circumstances, you can defer the migration until the .1 OS release as everything in /opt/local/bin should still work.

Addendum: 17 September 2024

MacPorts finally has built-in migration support!

Reporting Broken Ports

In the event you find a port to be broken, by all means report it. Over the years I’ve found MacPorts maintainers to be attentive and I am grateful for it.

MacPorts was meant to be run by a system administrator.

In the before-time, most deployed Unix systems were multi-user with the responsibilities of system administration given to a separate individual or organization. That system administrator could dedicate the time and resources to manage all of the above, leaving users the benefit of just using the tools installed. With individual ownership of macOS systems being predominant, such users who use MacPorts are forced to wear a sysadmin hat.

I’d observe that among macOS users, almost no one wants, much less cares to be a Unix sysadmin. That includes those who use Macs for Apple (iOS, macOS) development.

If you're going to use MacPorts, expect to be a sysadmin.

Why not use Homebrew?

Some readers might say, with all of the friction described above, why not use Homebrew? I would argue that Homebrew tends to sweep the details of OS upgrading and package migration under the rug. Homebrew tries too much to give you the illusion that installing open source tools is akin to installing a mobile app. But when things go invariably sideways, you are at the mercy of the policies of their package maintainers.

As a general rule, you trade-off control and optimization for convenience with Homebrew. With MacPorts, it’s the opposite. MacPorts doesn’t try to hide the responsibility of system administration from you; Homebrew does. For example, this blog post describes how Homebrew’s update policies created unpleasant surprise to the user when upgrading Python.

In the end, I prefer to have more control, despite the extra work it entails. MacPorts gives me this.

Closing Thoughts

My deepest thanks to the maintainers and contributors to MacPorts; this is software that I’ve been using for the past two decades strong. Hopefully my learnings will be of use to new MacPorts users and perhaps provide clarification for existing users as well.

Footnotes

¹ My first install of MacPorts goes all the way back to a 12” Powerbook G4 in 2003.

Using Emacs to make phone calls and lookup map places on macOS

2023-06-20T11:13:00-07:00

I admit, I do take a perverse delight in making phone calls from my computer. On macOS, this can be achieved via the iPhone Cellular Calls feature, which proxies your computer to your iPhone’s calling capability. Tied to this feature is the ability to select a phone number in a native macOS app text field and use it to dial that number direct. An example is shown below from the Safari app.

To dial a number, the app translates the human-formatted phone number into a tel: URL scheme that is then used to open the FaceTime app to make the call.

We can emulate this behavior in Emacs. This post will show you how.

Making a Phone Call

First off is parsing the human-formatted phone number. We can do this by writing some regexps. Since I live in North America, I’ve chosen to use regexps that conform to the North American Numbering Plan (NANP). NANP formats phone numbers into the form +1 (xxx) xxx-xxxx. I've also chosen to make regexps that also accepts spaces and “.” as separators.

(defvar cc/pat-nanp-international "^+1 \
[(]*\\([0-9]\\{3\\}\\)[)]*\
[\\. -]\\([0-9]\\{3\\}\\)[\\. -]\\([0-9]\\{4\\}\\)$"
  "Regexp for North American Numbering Plan phone number including +1.")

(defvar cc/pat-nanp "^[(]*\\([0-9]\\{3\\}\\)[)]*[\\. -]\
\\([0-9]\\{3\\}\\)[\\. -]\\([0-9]\\{4\\}\\)$"
  "Regexp for North American Numbering Plan phone number without +1.")

In the above I’ve defined two separate regexps with capture groups, one to handle numbers starting with +1 and the other for those without it.

From these regexps we can write the following function to convert a phone number to a tel: URL.

(defun cc/nanp-phone-number-to-url (phone)
  "Convert PHONE number string to url \"tel:\"."
  (cond
   ((string-match cc/pat-nanp-international phone)
    (replace-regexp-in-string cc/pat-nanp-international
                              "tel:+1-\\1-\\2-\\3" phone))
   ((string-match cc/pat-nanp phone)
    (replace-regexp-in-string cc/pat-nanp "tel:+1-\\1-\\2-\\3" phone))))

It is then straightforward to write an interactive function that takes a phone number as a selected region, converts it to a tel: URL, and opens it.

(defun cc/call-nanp-phone-number (&optional start end)
  "Phone call the selected number (region) bounded between START and END"
  (interactive "r")
  (let ((phone-buf (buffer-substring start end)))
    (browse-url (cc/nanp-phone-number-to-url phone-buf))))

Putting the above code to work, we can show the following example of selecting the phone number +1 (415) 867-5309 and dialing it from Emacs.

Looking a place up in Apple Maps

A similar exercise can be done with searching for a place in the Maps app, which is accessible via the maps: URL scheme. Unlike a phone number, we will forego trying to interpret the selected region beforehand and just pass the region as the query to the maps: URL.

(defun cc/open-region-in-apple-maps (&optional start end)
  "Open region from START to END in Apple Maps"
  (interactive "r")
  (let* ((query-buf (buffer-substring start end))
         (mapURL (concat "maps://?q=" (url-encode-url query-buf))))
    (message "Searching for %s" query-buf)
    (browse-url mapURL)))

The following function lets you interactively enter an arbitrary place to search in Apple Maps.

(defun cc/search-apple-maps (search)
  "Open SEARCH query in Apple Maps"
  (interactive "MMap Search: ")
  (let ((mapURL (concat "maps://?q=" (url-encode-url search))))
    (message "Searching for %s" search)
    (browse-url mapURL)))

Putting the above code to work, we can show the following example of finding "Harlan Records, SF" in the Maps app from Emacs.

Modifying the above to work with Google Maps is left as an exercise to reader.

Context Menus

Note that all of the above examples are keyboard driven. They are not necessarily so. In fact, driving much of the above work was the desire to be able to perform these actions via a context menu. And it is very much doable, however I'll elaborate on how I've done this in a forthcoming post. For now, here's some demo screenshots of my context menu implementation that supports making a phone call or searching a location.

References

Sometimes you just want the dang thing to pass butter. Introducing launchutil.

2023-06-15T18:28:00-07:00

There’s an old yet useful feature in macOS where you can get the time announced periodically, typically at the top of the hour.

One thing though: Turning this feature on means manually turning it on and having it repeatedly announce until you manually turn it off. This begs for automation, especially if you want the time announced only during working hours (say 9am to 5pm). Since macOS is my daily driver, this is where we talk about launchd, which since Mac OS X 10.4 has been the system process that manages daemons and agents. There’s plenty of posts describing it and how launchd works (see references below) so I won’t go over that here. What I will say though is that working with launchd via the launchctl command line utility is a PITA.

By and large my pain points in using launchctl are this:

Creating a launch script means you need to write it in XML, following a schema that I find impossible to remember.
Installing the launch script means you need to work with two different directories: 1) where you create the launch script and 2) where you need to install it (typically $HOME/Library/LaunchAgents).
Managing the launch script (that is starting, stopping, getting its status) using launchctl requires different references to the launch script/service which means different command line arguments to access the same thing. This makes the ergonomics of using launchctl punishing, especially when debugging the launch script.

Having worked with macOS for well over a decade, I’ve felt the woe of writing a number of launch scripts and encountering all of the pain points above. So I’ve decided to do something about it.

Introducing launchutil, a helper utility to support creating and running a simple macOS launchd service. It is written in Python and is expressly designed to have the following features:

Easy creation of a working XML file for daily scheduling that you can edit to taste.
Uses the launch script name as the reference to the job/service you want to run. (You can still use the service name though.)
Easy installation and removal of the launch script.

Let’s see launchutil at work: Imagine that you want to create a job that invokes the say command to say “hello there” at 14:00 (2pm) and 15:15 (3:15 pm) everyday. The command invocation would look like:

$ launchutil create --program /usr/bin/say --program-arguments hello there --daily 14:00 15:15 --execute com.yummymelon.sayhello

Alternately, you can use short arguments to achieve the same result.

$ launchutil create -p /usr/bin/say -a hello there -d 14:00 15:15 -x com.yummymelon.sayhello

Running the above generates the launch script named com.yummymelon.sayhello.plist whose contents are shown below:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>Label</key>
        <string>com.yummymelon.sayhello</string>
        <key>Program</key>
        <string>/usr/bin/say</string>
        <key>ProgramArguments</key>
        <array>
                <string>/usr/bin/say</string>
                <string>hello</string>
                <string>there</string>
        </array>
        <key>StartCalendarInterval</key>
        <array>
                <dict>
                        <key>Hour</key>
                        <integer>14</integer>
                        <key>Minute</key>
                        <integer>0</integer>
                </dict>
                <dict>
                        <key>Hour</key>
                        <integer>15</integer>
                        <key>Minute</key>
                        <integer>15</integer>
                </dict>
        </array>
</dict>
</plist>

Note that the launch script file name is built off the service name. launchutil relies on this convention to support the command-line ergonomics to infer the service name from the launch script file name and vice-versa.

Installing the launch script into the default directory $HOME/Library/LaunchAgents is achieved with the following command:

$ launchutil install com.yummymelon.sayhello.plist -x

To start the service:

$ launchutil start com.yummymelon.sayhello.plist -x

To get the status of the service:

$ launchutil status com.yummymelon.sayhello.plist -x

To stop the service:

$ launchutil stop com.yummymelon.sayhello.plist -x

To uninstall the service:

$ launchutil stop com.yummymelon.sayhello.plist -x

Note that in all the above commands:

No navigation or references to the installed directory.
Only reference the launch script file name (or service name).

Say Time at the Top of the Hour

So as promised at the start of this post, a launchutil example that will announce the time daily from 9am to 5pm can be found at https://github.com/kickingvegas/launchutil/tree/main/examples

Getting launchutil

If you’ve made all the way here and are still interested, you can get launchutil at https://github.com/kickingvegas/launchutil.

For the sake of simplicity, there is no pip · PyPI packaging; just install the single file Python 3 script into your bin directory. It has no dependencies to any packages outside of the basic macOS install.

If you have any feedback, please let me know at the GitHub discussion board for launchutil.

References

Automatically adjusting Emacs to macOS switches in appearance

2023-06-04T11:36:00-07:00

Count me among those who likes using the Auto setting when adjusting the appearance in macOS to either light or dark. Native macOS apps that are coded accordingly can automatically adjust as well, and it turns out that the Yamamoto Mitsuharu fork of Emacs (aka emacs-mac-app) can do this too. But with emacs-mac-app, just because it can detect the appearance change doesn’t mean that all the themes or faces will adjust accordingly too. As such it is typically up to the user to write a pair of custom light and dark mode functions to invoke when the appearance change happens.

For quite some time I’ve been calling these appearance mode functions manually like an animal. Then I recently learned that mac-effective-appearance-change-hook is a thing.

This hook gets invoked upon a macOS appearance change, so it becomes straightforward to write a hook function that tests for the :appearance property returned by
(mac-application-state).

(defun cc/reconfigure-nsappearance ()
  (let ((appearance (plist-get (mac-application-state) :appearance)))
    (if (string-equal appearance "NSAppearanceNameDarkAqua")
        (cc/dark-mode)
      (cc/light-mode))))

(add-hook 'mac-effective-appearance-change-hook 'cc/reconfigure-nsappearance)

A caveat though: the above code will only work with the Yamamoto fork of Emacs for macOS. As of now there seems to be no consensus on how to handle OS-level appearance changes by Emacs core. That said, if the above works for you, then no more manual appearance change calls!

References

Elisp code for cc/reconfigure-nsappearance
Where to get emacs-mac-app:
- MacPorts
- Homebrew

Captee available on the Mac App Store

2023-04-10T15:04:00-07:00

At long last, Captee is available on the Mac App Store.

Learn more about it at http://yummymelon.com/captee

Introducing Captee alpha, looking for testers

2023-03-10T14:31:00-08:00

This past February, I started building a macOS app to help me work with Org mode for Emacs It lets you share links and content from another app (typically Safari) via the macOS Share menu and format it in Org markup. It can also support Markdown links so you can work with other editors too. The app is called Captee and here’s a video that demonstrates it at work:

Note that Captee is very much in an alpha/proof-of-concept/bleeding-edge state of polish right now. You’ll get the best results for Captee if you use the macOS Yamamoto Mitsuharu port of Emacs (MacPorts, Homebrew). It supports Org Protocol out of the box, otherwise you will have to use the system clipboard to share content.

To capture selected text via org-protocol you’ll need to define a capture template on the Emacs side first before you use Captee. Here’s an example capture template that uses the placeholders described in the Org capture protocol.

(setq org-capture-templates
      '(
        ("a" "Captee Capture" entry
         (file+headline "~/org/captee.org" "Captee Captures")
         "* %:description\\n%:annotation\\n%i\n%?" :empty-lines 1)
        ))

Okay with all that said, I’m looking for testers. If you’re interested, you can get an alpha build of Captee via this TestFlight link. Please provide feedback via the TestFlight app. Also, I highly recommend you do a deep-read of the release notes before installing or using Captee.