SonicBlog

With GlowWorm 1.3, we’re excited to add support for Apple Shortcuts! One of the cool things this enables is integration with physical control decks like the Loupedeck and Stream Deck. In the SonicBunny Labs, we’ve got a Loupedeck for testing, so let’s see how to set up a simple button to activate a scene.

Create a new Apple Shortcut. We’ll call ours ‘Turn on Waves’ because we want to activate a scene called ‘Waves’. (That turns on a rainbow wave on the Labs' Litra Beam LX.) Search for the GlowWorm app in the library sidebar on the right and drag the ‘Activate Scene’ action into the shortcut. Click the ‘Scene’ placeholder and select the scene you’d like to activate. And we’re done with Step 1! You can hit the run button to test the scene.

In the LoupedeckConfig tool, you’re going to add a new Custom entry. From the ‘Custom’ list, select ‘Run Command’. In the ‘Paste path here’ box, you’re going to add the following command:

1/usr/bin/shortcuts || run "Turn on Waves" 

That runs the command line tool shortcuts with the arguments run "Turn on Waves". Loupedeck uses the || to separate the command and the arguments, so don’t leave those out. Remember, ‘Turn on Waves’ is the name of our shortcut in the Shortcuts app, so if you named yours differently, be sure to adjust. You can also run the command /usr/bin/shortcuts list in the terminal to get a list of the name of all your shortcuts.

To finish setting up your new ‘Run Command Action’, pick a name and set the icon. Once you save all that, you can drag it onto a Loupedeck button and you’re ready to go.

In just two simple steps, we can build a shortcut and assign it to a Loupedeck button. Now any GlowWorm scene is ready at the touch of a button. You can use that to bring up your standard lights as Zoom joins a meeting or you can cycle between scenes to highlight extra drama on your Twitch stream.

Let us know if you’ve got feedback or suggestions for better integration between GlowWorm and Apple Shortcuts!

We’re excited to announce GlowWorm 1.3 — the “Take a Shortcut” release!

GlowWorm is now fully Shortcuts enabled! Once GlowWorm 1.3 is installed, you’ll see a new suite of GlowWorm actions in your Apple Shortcuts library. From a shortcut, you can activate a scene or control an individual light. Now you can make a ‘video call’ workflow that pauses your music, activates your ‘Professional’ GlowWorm scene and starts up Zoom.

GlowWorm actions in Shortcuts are fantastic for integrating physical control decks like the Loupedeck or a Stream Deck. Via Shortcuts, you can tie an action to a button and run that action in the background with quick tap. Now you can use GlowWorm to switch scenes on the fly in the middle of your live stream!

GlowWorm actions also let you get a list of your available scenes and lights for even more intricate Shortcuts. Turn on a random light instead of flipping a coin. Make a shortcut to cycle through all your scenes to see which one makes that new sweater really pop! We’re so excited to hear what wild things you come up with.

Enjoy and let us know what you think!

Get it on the Mac App Store!




We’re excited to announce GlowWorm 1.2 — the “Make a Scene” release!

A GlowWorm scene saves all the settings for your lights and lets you restore settings those with a click. Now you can make a scene for work meetings in Zoom that’s very professional and polished but create another scene for Twitch streaming with rainbow colors and wave effects.

We’ve made it really easy to switch scenes too. Of course you can switch from the main GlowWorm interface, but you can also right click on the dock icon to get a list of scenes or enable the new menu bar helper so your GlowWorm scene is only a few clicks away.

With scenes available, we’ve started adding support for automations. Each scene has a URL that you can use to activate it from another app or workflow. For instance, you can assign a scene URL to a Loupedeck button or use it in a script. This is just the beginning for automation, so stay tuned!

The new version also has a few ‘nice to have’ features like the camera preview. You can switch on the camera preview and see how you look with the lighting setup. Using that, you can tweak the settings so they’re just right when it comes time to be on camera for real. We’ve also got a new setting to sync your lights to your Mac’s display so when the Mac goes to sleep, so do the lights. When the Mac wakes up, they’ll pop right back on too. Great for us forgetful types that wander off with the all the gear on.

Enjoy and let us know what you think!

Get it on the Mac App Store!




We’re continuing our look at unit testing with SwiftUI. In Part One, we looked back at how we tested UIKit and what approach makes sense to validate our SwiftUI projects.

For unit testing, test coverage is an important metric. How much of your code base are you exercising during unit tests? Xcode is, unfortunately, not too bright when it comes to measuring coverage. It doesn’t have the intelligence to know if you’re “testing” a line of code, just that the line of code was executed. This is a problem right off the bat.

I’ve got a new app project in Xcode. The app doesn’t do much yet and I want to start adding tests before it gets too big. So I add a unit test target and Xcode plops in some empty tests. I run the unit tests, and they all pass since they’re empty. I check the coverage and it’s at 36%! How can that be, I didn’t test anything?

Xcode, the blissful idiot, is really reporting that 36% of the code was executed while running the unit tests. Usually, when an app starts up, it does some bootstrapping. You might set up your persistent storage, draw a couple of Views on screen, and maybe talk to the network. Xcode counts all that as “testing” because it ran during a unit test.

To make the test coverage more accurate, we need to do as little as possible outside of our actual unit tests. Jon Reid has a write-up of how to do this with a UIKit app by swapping out the app delegate during tests. But SwiftUI introduces a whole new startup sequence so we need a new approach for SwiftUI’s new app lifecycle.

After some futzing around, turns out it’s easy!

 1struct TestApp: App {					// 1
 2    var body: some Scene {
 3        WindowGroup {
 4            Text("I'm running tests!")
 5        }
 6    }
 7}
 8
 9@main										// 2
10struct TestDriver {
11    static func main() {
12        if NSClassFromString("XCTestCase") != nil {    // 3
13            TestApp.main()
14        } else {
15            MyRealApp.main()
16        }
17    }
18}

There are three key points that make this work:

1. We need a dummy `App` struct to use instead of the real app. This simple stand-in circumvents all your usual app startup machinery. Instead of all the normal bootstrapping, we'll just get a window with the text "I'm running tests!".
2. Remove the `@main` from your `App` implementation and add it here to `TestDriver`. Swift uses `@main` to figure out how to start your app. The `App` protocol provides a default implementation that, according to the docs, 'manages the launch process in a platform-appropriate way'. But by inserting our own wrapper layer here around, we can control _which_ `main()` is called.
3. That brings us to the final point, use the good old `NSClassFromString` to decide if the testing bundle has been injected into our process. `XCTestCase` is only available during testing, so this is a reliable way to decide if unit testing is underway. Based on that, we can call the `main` method of either our real app or our testing stand-in. It turns out that the default implementation of `main` knows to use its parent struct to bootstrap the SwiftUI app.

Now when I run unit tests, my coverage is at 0.8%! That’s more like it. In order to boost my test coverage, I now have to actually test code. And the code coverage metric really starts to mean something.

Follow us on Mastodon and LinkedIn for more info Swift, SwiftUI and software testability. And if you’re interested in help with testing your existing app or building a whole new app, don’t hesitate to get in touch. We’d love to hear from you.

SonicBunny Software is thrilled to announce the first update of our new app – GlowWorm 1.1!

GlowWorm for your Mac allows you to control your Logitech Litra streaming key lights. GlowWorm is a light weight, fully native Mac utility that makes it quick and easy to configure your lights just the way you need.

The 1.1 update supports all available lights in the Litra family, including:

• Logitech Glow
• Logitech Beam
• Logitech Beam LX light

New features coming soon include:

• Elgato key lights
• Scenes
• Apple Shortcuts and Siri

We’re very excited to make GlowWorm a fast and flexible tool to control your streaming lighting.

Get it on the Mac App Store!




Apple released SwiftUI (checks notes) in 2019. Wait what? It’s been 5 years?! Wow. In the beginning, the framework was a bit… sparse, but Apple has refined and improved it so now SwiftUI is worth considering for app development. But an important part of any framework we want to include in our apps is testability. How testable is SwiftUI? What are some of the hurdles we need to overcome in order to quickly and accurately test our SwiftUI interface and make testing an integral part of our development workflow?

SwiftUI aims to replace UIKit on iOS, so that’s the benchmark in terms of testing. Ideally, SwiftUI should be at least as good as UIKit in this respect. The key to testing with UIKit is getting a view controller to execute its lifecycle. In a blog post lost to the inevitable bit rot of the Internet, NatashaTheRobot showed that if you instantiate a view controller and access it’s view attribute, the system’s runtime would cause the whole lifecycle to execute. Using a Storyboard, the code for that looks something like this:

1let storyBoard = UIStoryboard(name: "MyStoryboard", bundle: nil)
2let viewController = sBoard.instantiateInitialViewController() as? MyViewController
3XCTAssertNotNil(viewController.view)
4

By accessing view, we trigger a whole slew of Apple magic to bootstrap the viewController’s lifecycle including things like viewDidLoad(), viewDidAppear() and deserializing any components from the storyboard. After that, we’re free to poke and prod the VC and thoroughly unit test everything. UIKit has really set the bar pretty high in terms of testability. But trail blazers in the dev community have had many years to work all this out. After five years of SwiftUI, how does it stack up?

Well, that’s where it gets tricky. With UIKit, we’re able to actually create the view controller in a test and interact with it directly. In SwiftUI, our View structs aren’t the actual interface, but a description of the interface. The SwiftUI framework takes that description and creates real interfaces with UIKit on iOS or AppKit on the Mac. So how do we test that? We need help. Ideally, Apple would provide that, but they don’t, so we need to look elsewhere. After five years, ViewInspector has become the de facto standard for filling that role. Honestly, I’m not sure the voodoo that’s involved with ViewInspector, but tl;dr, it lets us create a view, inspect the view hierarchy and interact with controls. Given that this is a third party, open source, community effort, ViewInspector is fantastic! While they cover most of the SwiftUI API, you can see on the readiness list, that some corners of the framework aren’t supported. And because our View structs are just descriptions of the UI and not the actual UI, I’ve found it quite fragile to work with anything but the most basic code in the non-UI parts of the View struct. But a View can often need to be quite complicated, so how do we deal with that? One word – plastics! – I mean ViewModel! Or is that two words?

Using a ViewModel, we talk all the logic (and I mean all the logic) out of the View and put it into a class we’ll call ViewModel. Even a simple if statement in the View moves to a computed property of the ViewModel. We’ll store an instance of ViewModel on the View and mark it as a @State variable. Testability of this configuration turns out to be quite high. In testing the View itself, we can easily build a fake subclass of the ViewModel and check that the view responds correctly to different states in the view model and calls the right methods with we interact with it via ViewInspector. The ViewModel on the other hand, is just a class with no SwiftUI magic at all, so we can test that in the traditional ways with fakes, mocks, etc.

Problem solved! Almost. While this works great in theory, in practice there are some potholes. Most of the problems we encounter are related to incomplete coverage of the SwiftUI API by ViewInspector. Again, the folks working on ViewInspector have done an enormous service to the community with all their hard work. But they are chasing a moving target, with new API released by Apple every year, some of which is difficult or even impossible for a third party tool to work with. But in the end, while this solution is not 100%, it’s robust enough to provide a comfortably high degree of testing. We’ve been using it successfully with GlowWorm for a while now.

Follow us on Mastodon and LinkedIn for more info Swift, SwiftUI and software testability. And if you’re interested in help with testing your existing app or building a whole new app, don’t hesitate to get in touch. We’d love to hear from you.

If you’re not keeping up with the play-by-play on the Apple Vision Pro (AVP), when you make a FaceTime call, the AVP represents you with an avatar thing called a Persona. The Persona is a three dimensional, virtual version of you based on a scan of your actual face. Your Persona changes to reflect the movements of your face, so people on your FaceTime call see the avatar smiling, frowning or (like me) looking vaguely confused. When AVP first launched, lots of reviews complained that Personas came straight out of the uncanny valley. With the VisionOS 1.1 release, Apple thankfully turned down the creep factor.

The big news last week is that Apple released Spatial Peronas to Vision Pro users. Now your Persona breaks out of its little phantom zone prison and inhabits the 3D space with other Personas on your call. Jason Snell has a nice writeup of the first hand experience with the Spatial Personas and is worth a read. The bottom line for me? Spatial Personas plus SharePlay lay the foundation to make the AVP a fantastic tool for telepresence and collaboration! That’s in stark contrast to early worries that AVP would make us all lonely.

But the point I really want to highlight is Apple’s long tradition of planning years (and years) ahead with their technology frameworks. As Uli pointed out, they did this with the FrontRow software, which lead to the AppleTV hardware. HealthKit was released in the Fall of 2014 along with Apple Pay, two tent pole technologies of Apple Watch which would be released the next year. Side Car for macOS, released in 2019, paved the way for Mac Virtual Display on Vision Pro in 2024. And of course one of their longest running projects is Apple Silicon. In 2010, Apple shipped the A4 chip in the first generation iPad. 10 years later, Apple Silicon made the jump to Macs with the M1 and blew everyone away with unheard of performance and efficiency.

So many of Apple’s really stunning achievements turn out like a good murder mystery movie. When you go back and watch the film again, you see clues along the way that hint at the ending. Go back and look at the evolution of Apple’s tech stack and you’ll pieces of technology that eventually culminate in an amazing new feature. At the time, I just assumed that SharePlay was a response to the pandemic to let isolated folks watch movies together. That’s cool, but it seemed like a really niche application. But pair that with AVP and it completely transforms this very single user device to an immersive and connected experience that lets you collaborate with everyone. I was a little lukewarm on the AVP initially, but Spatial Personas and SharePlay have opened up my line of thinking and… maybe it’s fantastic! Now we just need SharePlay for Xcode please. Counting down to WWDC 24!

This tip is a simple one, but I’m surprised to find people aren’t aware of the many ways to select text on your Mac. If you’re working on your Mac, you’re probably dealing with text. That means making selections for formatting, copying, pasting, and so on. This is basic stuff – click on the start of the text and drag to the end. Everyone who can ‘use a computer’ knows that, but on a Mac there are a few more ways to select.

• Double click a word to select the whole word. This usually goes from whitespace to whitespace around the word and its a great way quickly select a word when need to grab a name out of an email or a variable out of some code.

• Triple click to select a whole paragraph. Say you’re researching something online and come across the salient point on a web page. Just triple click the paragraph and you zip that off your team.

• Shift click to select a range. This one is good for selecting a lot of text that doesn’t fit on the screen, like a long web page or a big Word doc. Just click on the start point, scroll, scroll, scroll and shift click on the end point. Voila! The whole thing is selected.

• Extend the selection with shift click. If you have some text selected and shift-click again, the selection will extend to the point you’ve clicked. Sometimes you might not get all the text in the first swipe, so by shift clicking, you can extend the selection and get those missed letters.

Mac features like these selection tricks are the sorts of things that sometimes fall through the cracks. Long time Mac users have these actions embedded in muscle memory and can’t really say where they learned them. But they’re not very discoverable, so new users sometimes miss out on these deeper features. So spread the word! Tell your friends! Triple click all the things!

We got our first Mac in late 1999, around the time Jeff Goldblum was explaining that there is no step three. Fedex brought us a purple iMac DV, a gumdrop of a computer from a future with no floppy disks. That Mac was fantastic. I’ve lost count of the Macs that have come and gone since then, but they’ve all been magical in their own way. One thing I wanted to do with this blog is to explore some of the lesser known features of the Mac and show how they can make using a Mac even more efficient and delightful.

There are a lot of names given to apps on the Mac that really embrace the system. Some call them ‘Mac good citizens’ and some to say they’re Mac-assed Mac apps. With SonicBunny’s Mac apps, that’s the goal – to make a Mac-assed Mac app that feels right at home. And maybe just a little bit magical.

So let’s dig right in. I’ll start with a feature that I’ve used a number of times writing this post and that’s the word ‘look up’ feature. You can access this by right clicking on a word and choosing ‘Look up’ in the context menu. If you’re using a track pad, you can force click on a word to look it up. For example, if I ‘look up’ the word ‘marvels’, I get this pop up.

You get immediate access to the dictionary definition of the word as well as synonyms and antonyms. For me, this is incredibly useful in writing. Sometimes it’s helpful to double check the meaning of a word, but more commonly, I need help from the thesaurus when I’ve used the word ‘reliable’ three times in as many sentences. macOS has supported ‘look up’ for dictionary and thesaurus for a very long time, but in recent editions, Apple has added Siri Suggestions. In the case of ‘marvels’, I get extra tabs along the bottom for TV shows, images, and websites. Other search link to the Wikipedia and Apple Music. ‘Look up’ is also great reading the web in Safari. You can quickly look up a word or phrase without leaving the current page.

So that’s our first Pro Tip – use your track pad’s ‘force click’ to look up words quickly as you read and write on your Mac.

SonicBunny Software is thrilled to announce the initial release of our new app – GlowWorm!

GlowWorm for your Mac allows you to control your Logitech Litra streaming key lights. GlowWorm is a light weight, fully native Mac utility that makes it quick and easy to configure your lights just the way you need.

Our initial release supports the Logitech Glow and Logitech Beam lights. New features coming soon include:

• Logitech Beam LX light
• Elgato key lights
• Scenes
• Apple Shortcuts and Siri

We’re very excited to make GlowWorm a fast and flexible tool to control your streaming lighting.

Get it on the Mac App Store!