Archive for May 31, 2022

Tuesday, May 31, 2022

Rediscovering the Mac

Federico Viticci (tweet):

As much as I love the iPad, at some point I have to face its current reality: if Apple thinks iPadOS isn’t a good fit for the kind of functionalities people like me need, that’s fine, but perhaps it’s time to try something else. If my requirements are no longer aligned with Apple’s priorities for iPadOS, I can switch to a different computer. That’s why I believe 2022 – and the upcoming WWDC – will be a make-or-break year for iPad software. And I don’t think I’m the only iPad user who has felt this way.

[…]

For the past six months, I’ve been using my MacBook Pro instead of the iPad Pro to get my work done on a daily basis.

[…]

Now, it’s not like all these things are possible on macOS because of ports (except for, you know, the multiple monitors thing): it’s just that they’re more user-friendly and well, nicer than trying to do the same on iPad. The computer doesn’t punish you for trying to do computer-y things.

[…]

Then there’s the keyboard. It’s a real keyboard: the layout and size is perfect for my hands, the keys feel great, and I love the black area around the keys; it’s a very tasteful look. More importantly, however, this keyboard has an extra row of function keys, whose absence I’ve long considered the single most limitating aspect of the Magic Keyboard for iPad Pro.

[…]

The single most important quality of macOS I’ve rediscovered over the past few months is the freedom to use my computer however I want. With the MacBook Pro, the App Store does not dictate the kind of software I can run on my machine; I am free to create my own experience – and tweak it over time – by installing apps and system modifications that go beyond putting apps on my Home Screen.

[…]

There are several Mac-only features in Shortcuts, but the multitude of ways to run shortcuts in the background on macOS is the one that truly sets it apart.

Matthew Cassinelli:

Things like running multiple shortcuts at once using keyboard shortcuts, setting up all my shortcuts on the Stream Deck, and the kind of power user apps available on the Mac are pushing the Shortcuts ecosystem much further in just one year than iPad saw in multiple years of development — beyond everything else Federico lists[…]

Previously:

Activating Applications via AppleScript

John Gruber:

On MacOS 12 Monterey (and apparently MacOS 11 Big Sur), what happens instead is that TextEdit becomes the active application but only its frontmost window comes forward.

On MacOS 10.15 Catalina, and all previous versions of MacOS back to Mac OS X 10.0, all of the open windows in an app come forward when you tell that app to activate in AppleScript, or with the equivalent in JavaScript for Automation[…]

Peter Maurer:

I’m voting for bug. Here’s why: NSRunningApplication has the exact same problem, where NSApplicationActivateAllWindows isn’t being honored. Started at around macOS 11.4, if I remember correctly.

Bonus fun fact: Earlier macOS 11 versions had the inverse bug, where activating apps via NSRunningApplication always behaved as if NSApplicationActivateAllWindows were set. Looks like they then attempted to fix it, overdid it, and then never got around to revisiting the problem.

The only way (that I’m aware of) to get the correct behavior is using SetFrontProcessWithOptions(), which is deprecated. Sigh.

Previously:

SwiftUI Equal and Ideal Sizes

Matthias Maurberger (via SwiftUI Weekly):

One example that illustrates this quite well is when you want to make all children of a VStack as wide as the widest child. Sounds like it should be straightforward. But it’s not. It’s a surprisingly hard problem.

[…]

First, we’ll wrap each Button’s Text label in a .frame modifier with maxWidth: .infnity. That alone only solves our problem if we want our stack of buttons to occupy the full width it was given. If we want the stack of buttons to be as wide as it needs to be, we’ll need to make a second adjustment: apply the fixedSize modifier to the VStack.

Previously:

Parse Swift SDK

Dave Verwer:

Parse lasted longer than their major competitor, Stackmob, who was acquired and then shuttered just a few months later. But eventually, in 2017, Facebook turned off the hosted Parse servers.

They did open-source the platform as they closed it down, partially due to the huge number (600,000, according to this article) of apps they’d disrupt without a migration path. I was vaguely aware that the open-source project was still around but I hadn’t paid much attention until I spotted this package pop up in the Swift Package Index RSS feeds this week.

[…]

Why am I writing about this? Well, it has always been risky to base an app on another company’s back-end server. Yes, it can save a lot of time, but you’re always at the mercy of another company’s business decision, and their priorities almost certainly don’t match yours. Maybe the platform you pick will shut down, fundamentally change its pricing, or make another decision that doesn’t work for you. Your options are limited as these frameworks live at the heart of your app. The Parse platform is now free of many of those problems. As it is open-source, it’s almost impossible to shut down, and being self-hosted, you’re in control of pricing.

Previously: