Software Development

As a sort-of follow up to my post about Apple’s macOS Engineers running out of places to put new permission dialogs in, I had a thought, because, I do have those from time to time.

Here’s what’s up: In macOS, when you want to, for example, create a screenshot app and want it to be able to actually take screenshots, you’ll have to get permission from the user for it. With the upcoming macOS 15 Sequoia, that is going to be upped to two dialogs. One: the initial permission request, and two: a weekly reminder, asking if you want to continue to allow this app to capture your screen.
Here’s where my aforementioned thought comes in: Wouldn’t it be nice if a screenshot app from the Mac App Store was able to, like, take screenshots, right out of the box, without any permission dialogs?
I feel like apps on the Mac App Store should get some perks for being reviewed and vetted by Apple’s App Review.

So here’s my thought, wrapped into a couple of examples, to really drive my point home ad nauseam:
– A developer of a screenshot app that has successfully gone through App Review to be published on the Mac App Store should be able to request a default screen capture entitlement for it, which lets macOS know that no permission dialogs need to be presented, or asked for weekly, at all. It can just take screenshots right after download, because, you know, it’s a screenshot app, and that’s what the user downloaded it for.

– A developer of an audio recording app that has been reviewed by App Review to be released on the Mac App Store should be able to request a default Microphone recording entitlement, so it can record audio right after download, because, you know, it’s an audio recording app, and that’s what the user downloaded it for.

– A developer of an app that uses the user’s current location for core features that has successfully been reviewed by App Review to be released on the Mac App Store should be able to request a default Location entitlement so it can get its work done right after download, because that’s what the user downloaded it for.

Shouldn’t that be sort of the point of App Review?
I kind of understand making apps obtained from outside the Mac App Store jump through permission dialogs (to an extent, I just hate the new weekly permission reminders so much), but I feel like apps obtained from the Mac App Store could appear so much more user-friendly and polished without them, and would definitely make apps obtained from there feel special.

I guess what I’m saying is: Apple, please stop this Tour-de-farce security permission dialog onslaught and give users and developers some credit.

P.S.: I do realize it’s a pipe-dream. With all the ways stuff can be kept from App Review – which has happened time and time again – it’s not a system fit for such an implementation. Which, in turn, draws App Review’s reason for existing into question altogether.

Read more

To start with: it’s difficult, but it can “work”. Sort of.

The star of the show, the MacBook Pro Mid-2012, running macOS Ventura (far right)

Why do this to yourself?

Quite frankly, I didn’t feel like shelling out ~€600 for a refurbished Mac Mini just to be able to test the odd app of mine with iCloud sync. It just seems overkill. And I did have this old MBP lying around, so I thought: why not give it a try?
If all else failed, I’d still have the Mac Mini option, anyway.
And a Virtual Machine doesn’t work, because you can’t log into iCloud / Apple ID in a VM environment for some reason. It could have been so easy…

I’d done it before, too. That 2012-MBP has served me so well over the years, with 6 partitions, reaching from macOS 10.10 Yosemite to macOS 10.15 Catalina, all for testing purposes.

It really speaks to the quality and longevity of these machines. Eleven years old, and still rocking.

Installing macOS 13 Ventura on the MBPMid2012

Getting macOS Ventura (released in 2022) to run on a Mac that’s not supposed to run even macOS 11 Big Sur (released in 2020) is surprisingly easy.
Using OpenCore Legacy Patcher, it was pretty straight forward, with only one *gasp*-I-think-I-just-bricked-this-11-year-old-Mac moment that was resolved by a simple restart (a dialog appeared telling me the installation had to be aborted due to an unknown error, which had no effect at all).
There’s really only one thing that I thought could be improved (complaining on a high level here, since it’s a miracle this works at all in the first place):
You *have* to use an external drive to create the installer drive, you can’t use an internal partition. And you cannot use a partition of an external drive, you have to wipe that drive entirely.
None of my USB thumb drives were big enough (the biggest I have is 8 GB), and all my other drives have more or less important data on them, so wiping one of them was out of the question.
Thankfully, my girlfriend had a completely empty 2TB hard drive handy that she was supposed to use for backups (and never did), so I was able to use that.
Once that was out of the way, it was all just a matter of following the on-screen instructions and waiting. And waiting. It takes a while.

Running Xcode 15 on it

It runs. It compiles. It fails to attach the debugger to the app (the LLDB RPC server crashes). But the compiled app continues running. So, debugging and coding directly on the Mac is impossible.

In hindsight, I think I may have overshot with macOS 13 Ventura and perhaps should have installed macOS 12 Monterey instead with Xcode 14, but I did what I did. It’s done. I’m not doing it over. You can’t make me.

In my case, it’s just as well. All I wanted to do was to test ScreenFloat 2’s iCloud sync with another Mac. And as far as that’s concerned, it’s working perfectly.
It would have been the icing on the cake to be able to debug directly on that Mac, and commit changes back and forth, but what can you do…
I debug on my main Mac, and then commit-and-pull the new code over on the old Mac, and then re-build. It’s tedious, but I can’t really complain. Well, I can. And I am. But I shouldn’t.

Other Observations

I’m making use of the Vision framework in ScreenFloat, and that completely crashes the app on the old Mac. Apparently, there is a reason why macOS Ventura is not supported on these old Macs.

I don’t think you could use this as a machine for work, as I’d imagine you’d run into a lot of little, annoying, and big, terrifying issues. For instance, I imagine Preview would crash a lot, since it also uses the Vision framework for its OCR and whatnot.

For testing apps in development, however, it might work, depending on what it is you’re testing/developing. I had to jump through some hoops (disabling my Vision framework code) to get my app to run. Your mileage may vary.

As a no-cost alternative to a refurbished Mac Mini at ~€600, I couldn’t be more happy.
Here’s to my old, loyal MacBook Pro Mid-2012. It still has some life in it.

Unpacking the MacBook Pro Mid-2012 in… mid-2012.
Read more
Why is Xcode’s popup-documentation tied to the compiler? Kind of defeats its purpose at times.

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