swiftui

In lieu of a software update today – ScreenFloat v2.3.8 is taking me a bit longer than anticipated – I thought I’d share a fun 🙃 story about SwiftUI with you.

ScreenFloat offers widgets that give you quick access to different things.
Among others, you have the Capture widget which allows you to start a screen recording, capture your screen, import from your iPhone, etc.
And there’s the Recent Captures widget displays your recent shots so you can easily float them.
Or so I thought. But I’m getting ahead of myself.

The Capture widget
The Recent Captures widget

All the actions in these widgets (when a button or a shot in a widget is clicked) are powered by SwiftUI’s Link(), which opens my app with a custom URL that contains whatever information I need to perform the action the user requested.
For clicked shots, that would be floating them (such a custom URL could look like this: esssf2://widget.at?shotID=<someid>&action=float).

Now, some of these widgets are static (the capture utility widget, for example, can not be configured in any way by the user and always shows the same capture buttons), while others are dynamic (widgets that display shots can be configured to only show images, or only video recordings, for example).

Configuring the dynamic Recent Captures widget

That’s all lovely, but recently I discovered something puzzling.
While my static widgets worked just fine – each button in the Capture widget was individually clickable and did the correct thing in my app –, clicking a shot in a widget to float it would not open my app with the custom URL I specified, but with the dynamic widget’s configuration intent instead.
No matter which shot I clicked, it always did the same, wrong, thing.
(A configuration intent is what internally makes customizing widgets possible; and to make things even more confusing, ScreenFloat’s dynamic widgets are set up internally partially through a .intentdefinition file (Apple’s older way to make widgets configurable), and partially through AppIntents (Apple’s modern approach) ).
So instead of my app receiving the correct custom URL which tells it which shot to float, it receives info on how the widget is configured – information not exactly useful in this context.

So I figured it had to do with the widget’s dynamic nature – a logical assumption, given that my app received the configuration intent instead of my URL.

First, I thought perhaps the .intentdefinition file and the AppIntents somehow confused each other, so I temporarily removed the definition file, but the results were the same. Dead end. (Which is good. Otherwise I would have only been able to offer my widgets on macOS 14 “Sonoma” and later, leaving behind two earlier releases of macOS that ScreenFloat supports).

So I set out to test my assumption that the widget’s dynamic nature was at fault.
I tried yet another dynamic widget, the Folders widget.

The Folders widget

It can be configured to show all, only smart, or only “dumb” folders, and when clicked, ideally opens the clicked folder in ScreenFloat’s Shots Browser.

With a smirk on my face, confidently clicking on a folder in that widget, absolutely certain it would not result in the folder being opened in ScreenFloat’s Shots Browser, what did my tired, shocked eyes perceive?

The freaking folder opened in the freaking Shots Browser! The Link() with my custom URL worked!

 

But why!? I couldn’t make sense of it.
What was the difference between the Link() in my Recent Captures widget, and the Link() in my Folders widget?
Readers dabbling in the arts of SwiftUI might have already noticed that the first consists of Image()s, while the latter is made of Label()s. So I swiftly swapped out the Image() for a Label() to test that this was indeed the culprit, and lo and behold, the widget now worked.
A shot was finally floated correctly!

 

At this point, I was desperate. Close to tears of rage. Ready to rage-quit. Not only Xcode, but also my app’s development. My profession. Coding in general. I was done.
Perhaps Image()s in Link()s are just bugged and there’s nothing I can do about it?
The thing is, I knew it worked at some point, so I fired up my virtual machines in UTM and went back to see when it started to break.
macOS 12? Fine.
macOS 13? Fine.
macOS 14? Fine.
macOS 15? Bingo.

Something on macOS 15 and later broke my widget.

So the first thing I did was to remove all modifiers from my Image() and try again. If it still didn’t work then, I’d have to find a different way to make it work. Maybe hack my own Image() implementation together. Fun times ahead.
But I got lucky for once. Removing all modifiers from the Image() did the trick.
Now all that was left to do was to go through each modifier and see which one broke things.

“How many lines of code are there?”
“About two million…”

Ready?
.widgetAccentedRenderingMode(). It was .widgetAccentedRenderingMode() that messes with Link()s.
Only specific configurations, though: While .fullColor and .accented work fine, the other two (.desaturated and .accentedDesaturated) render the Link() defunct. Guess which ones I used.

Now why is this happening? Nobody knows. I doubt Apple knows. Or cares.
Is any of this documented? LOL.
How long has this bug been around for? Since macOS 15, so for about 2 years.

Now that I knew where the bug was, out of interest I googled it, and sure enough found others with the same issue. Not something I found before, because who’d think to google for that particular setup? Nobody, that’s who.

So, there you have it. A Link() containing an Image() with .widgetAccentedRenderingMode() set to .desaturated or .accentedDesaturated will render said Link() defunct 🤷‍♂️ .
I found two ways around this: Don’t use those two properties, or don’t embed the Image() in the Link(), but have the Link() be an .overlay() modifier of the Image(), like so:

var body: some View {
    Image(...)
        .overlay {
            Link(destination: ...) {
                Rectangle()
                    .foregroundStyle(.clear)
                    .frame(...)
            }
        }
}
The Shot floats when I click it in the widget!

A rdar’s been filed and is now ready to gather dust in the forgotten depths that is Apple’s Feedback Assistant, never to be looked at again, until some digital archaeologist far into the future stumbles upon it and finally marks it as “works as intended”.

I’ll go now and scream into a pillow some more.

Read more

I’m happy to announce a new app today: Citator for iPhone and iPad.
The brain-child of Clemens Bauer, Citator is a currently free app that lets you store, cherish and share memorable quotes.

Earlier this year, Clemens – whom I’ve known from the time we worked together on a local Apple Retailer’s customer loyalty app – approached me with an idea for an app to safe-keep quotes in.
Previous apps he had used for this appeared to become abandoned, and he desired a fresh, modern approach.

Features

  • A beautiful list you can filter or search to quickly find quotes you’ve stored before
  • Save Quotes from the app, or from any app using the Share- or Action sheet
  • In addition to the quote itself, you can specify the author of a quote, where and when it originated, and where you found it
  • Author’s images are automatically loaded from Wikipedia if available
  • Display a static quote you select on your Home- or Lock Screen (requires iOS 16) with a widget
  • Display a random quote (which can change in an interval of your choosing) on your Home- or Lock Screen (requires iOS 16) with a widget
  • Share quotes as text, or as beautifully rendered images
A quote shared as an image from Citator
Automatic loading author images from Wikipedia in action.

Pricing and Availability

Citator is currently free, available for iPhone and iPad on the App Store.
The app requires iOS 15 or newer and is currently localized in English and German.

TidBits and Fun Facts about the App and its Development

SwiftUI

The app is 100% SwiftUI, which, apart from a few SwiftUI widgets here and there for my other apps, marks my first fully-featured SwiftUI app.
I’ve always said that learning something new is always easiest on-the-go. That’s how I learned Objective-C many years back, it’s how I learned Swift, and now, it’s how I’m learning SwiftUI.
But It’s been a struggle for sure, and I don’t know yet what to think of it. I do like parts of it.
Yet I passionately hate that sometimes the simplest of things require workarounds upon workarounds. I’m not saying I know a lot about SwiftUI (I do not!), but as “the future of developing for Apple platforms” (paraphrasing here), it’s nowhere where it should be, in my opinion.
You want different code-paths for different iOS versions in your @ViewBuilder? You’re entering a world of pain.
You want to show a simple share sheet pre-iOS 16? Not available natively.
You want to show a popover for a specific row in a list? Yeah, right, virtually impossible.
There are a lot more like these, and it can be very frustrating.
And I admit, I don’t quite understand the premise of SwiftUI. Years and years were spent on creating graphical user interfaces, to the point where, in Xcode, for example, one could drag user interface elements for the app you’re working on where you want them to be and have an options interface to configure them to look the way you desire.
Now, the supposed future is going back to command-line-like interface programming for GUIs? Isn’t that a step back?
For now, I’d choose Xcode’s storyboards and auto-layout over SwiftUI any time.

It me.
List Row Backgrounds
A quote by Steve Wozniak, and a quote by an unknown author.

The background of a quote in Citator is a blurred, darkened (or lightened, in light mode) version of the author’s image.
However, sometimes, there is no author specified for a quote, or an image cannot be found, which would render that quote’s background solid black or white, making it stand out in an out-of-place fashion.
Luckily, I found an – in my opinion – elegant solution. I thought it would be neat to have a background image created from the quote text itself. I don’t know why, but the concept of the quote text itself creating its own, unique background felt fitting to me, especially for this app.

Colors can be represented as hexadecimal values (i.e., #FF0000 for red, #00FF00 for green, or #0000FF for blue). All I needed was to turn the quote text into a hexadecimal representation.
The hashing algorithm MD5 takes data and creates a hash value of it, which consists of characters from A-F and from 0-9, which is the same hex color values consist of.
So when no author image is available, Citator creates an MD5 hash of the quote text and a bit of “salt” for added randomness (the author and the date), splits it up into individual, 6-character/digit strings and uses those to create a blurred, darkened/lightened gradient background image.

Colorful quote backgrounds, created from the quotes themselves.
Customizable Widgets

I love how the widgets turned out.
You can have static ones, where a quote you select will be displayed until you change it, and you can have dynamic/random ones, where the quote changes in an interval you define, with rules you set up.

A Citator widget, displaying a quote by Joan Baez.
Options for a dynamic / random-quote widget.

I also adore the new Lock Screen widgets. Clemens in particular was very happy that widgets can now be displayed on the Lock Screen in iOS 16, and they are a perfect fit for Citator.

Two Citator widgets on the iOS 16 Lock Screen.

The quotes used in App Store promotional material

At first, I thought I’d use quotes from movies (like in the short video above, with quotes from the fictional characters Dr. Ellie Sattler, Dr. Ian Malcolm and Indiana Jones). But then I got worried about copyright issues and scrapped the idea.
After a while of thinking about it, my mind wandered to Apple’s Think Different campaign, and that’s when I had the solution to my problem.
All quotes featured in the App Store promotional screenshots are by personalities featured in Apple’s Think Different campaign, like Amelia Earheart, Orson Welles, Alfred Hitchcock, Joan Baez, Martha Graham and John Lennon.

Clemens and I hope you enjoy Citator.
There’s more cool stuff yet to come!

Read more

Yoink v3.6.5 re-introduces its clipboard history feature and the accompanying widget.
Here are a few details about its implementation for macOS Big Sur and newer.

The No-Button-Action Conundrum

Widgets on macOS Big Sur and up (and iOS, for that matter) can’t really react to a user’s click on them by themselves, so you cannot run any logic from a user’s input.
A click onto a widget will always bring you back to its containing app, where you can then run logic accordingly.
On iOS, that’s obvious, as it’ll open up the owning app and put it front and center.
On macOS, that can be a little more subtle, because macOS allows apps to run in the background (like Yoink does, mostly).

When you click on an item in Yoink’s widget, it’ll tell Yoink to run the logic to copy the clicked item (or pin it, or add it to Yoink, or reveal it in the browser, depending on the modifier key you pressed during the click).

But there’s a problem with that in the case of Yoink:

The Foreground Conundrum

No matter where you click on a widget (either the background of it, or a SwiftUI Link() object), it will bring its containing/owning app to the foreground.
For many apps, that will be fine. But Yoink is an app that runs in the background and only very rarely needs to actually become the active, keyboard-input-accepting app.

So I thought, perhaps I can have another application inside Yoink’s app bundle, which is LSBackgroundOnly, with a custom URL scheme that would be called from the widget using a SwiftUI Link() object. An app that has LSBackgroundOnly set to YES in its Info.plist cannot present any user interface, and cannot become “key”, even if the system tells it to.
But there’s another roadblock – even though only the secondary app inside Yoink’s app bundle should be able to open the custom URL scheme, the widget will send that Link() to its containing/owning app only, no matter the url scheme. In this case, the main Yoink app.

The point of the widget is to quickly re-copy something and then paste it somewhere right away.
Say you're editing text in TextEdit, then open the widget, click on it to re-copy something and then press command-v to paste it into TextEdit only to hear a beep because the app isn't active anymore (because Yoink is). So you have to click into the TextEdit document to make it active, and only then can you paste. That can (and will) become annoying very quickly.

In order to have Yoink never become the active app from a click on its widget, I’d have to move the widget plugin/appex bundle out of the Yoink app bundle’s PlugIns folder, into the secondary target one’s.
Only that way would the widget attempt to make the secondary target(and thus, not Yoink) frontmost – and fail because of LSBackgroundOnly, leaving the currently frontmost app active – and send the custom URL scheme link to it. The secondary target would then forward the link to the main Yoink app bundle.

Tada, it works. But that lead to yet another problem. (When did “it just works” turn into “it just won’t”? And while I’m at it, what’s with those widgets? They feel quite… neutered to me compared to what they were able to do before.)

The Widget Recognition Conundrum

So far, I managed to have Yoink not become active when an item in the widget is clicked.
But now, with the Yoink app containing the secondary target containing the widget, macOS was unwilling to recognize and show the widget in Notification Centre.
Interestingly, a double-click onto the secondary target in Finder would make it show right away.
Infuriatingly, launching the secondary target quietly from within Yoink at launch won’t – and I had a lot of different approaches:
– Launching the secondary app directly with NSWorkspace’s -launchApplicationAtURL:…
– Launching the secondary app via its URL scheme
– Having Finder open the secondary app
– Running an NSTask open -a <secondaryapp> /path/to/somefile
– Registering the app using LSRegisterURL

None of it worked. I figured, the problem was that it was Yoink launching the secondary app, not the “system” or “user”, like it was the case when double-clicking it in Finder.

Which made me think of login item helper apps.
Inside the macOS app sandbox, an app cannot set itself as a login item. It needs to have another “helper” app inside its Library/LoginItems folder which it designates as a login item, and that app will then in turn launch the containing app. Nuts, but there it is.

The point is, the system launches those login item helper apps, not the containing app.

Heureka. In Yoink, at launch, I set my secondary app, which contains the widget bundle, as a login item with SMLoginItemSetEnabled, causing the system to launch it. Now, finally, Notification Centre recognizes and shows Yoink’s widget.

What a needless journey.

Read more