Buzz Andersen:
Am I the only one who finds Apple Universal Links to be, like, an enormous pain in the ass?
Paul Haddad:
As much as Apple makes a big deal about privacy, the fact that you can’t globally disable universal links feels like an info leak.
Tap on an Amazon link a friend sends you on iMessage with the Amazon app installed, now Amazon knows you are interested in that product.
I like the idea of Universal Links, but in practice they always seem to get in my way.
On iOS, I often end up viewing a tweet in the official Twitter app, even though I would prefer Tweetbot or even Safari. I can’t prevent this by uninstalling the Twitter app because I need it for authentication.
On macOS, clicking on a WWDC video link in Safari opens the Developer app, which I never want.
Ryan Nystrom:
[Is] there a way for users to opt out of Universal Links for a single app? Either via system settings or something developers can do in app.
In Safari for Mac, you can use the contextual menu to tell it to open in Safari instead. But this is a bad solution because you have to know that what you are clicking is potentially a Universal Link and remember to do it. And there’s no option that I could find to make it remember your preference. One workaround is to use a different browser instead of Safari.
On iOS, I think you used to be able to tap and hold to change the default. But now it seems to behave like on the Mac. And the case of WWDC videos is extra confusing because on iOS the default is the opposite—to use Safari even if the Developer app is installed.
The other annoying part is that when I finally do get to see the Universal Link’s content in Safari, it sometimes fills a good portion of the screen with a banner recommending that I open the app instead.
Jeff Johnson:
You can’t tell Safari to just STFU about the Twitter app.
[…]
My final, “insanely devious” idea (as someone called it) was to create a fake Twitter app. When there are multiple apps installed on your Mac with the same bundle identifier, macOS tends to prefer the one with the highest version number. So I opened a new Mac app project in Xcode and gave it the bundle identifier maccatalyst.com.atebits.Tweetie2, matching the real Twitter app. I gave the new app the bundle version 1000.0.0, which was arbitrary but likely higher than anything you’ll ever see in the real Twitter app, currently at version 8.18.1. And I added an AppIdentifierPrefix key with the string “8248RGMF2D.“ to the new app’s Info.plist file, again matching the real Twitter app. The critical difference between the real Twitter app and the fake Twitter app is that I did not add com.apple.developer.associated-domains to the fake app’s entitlements. The associated domains in the real Twitter’s entitlements indicates that it supports Universal Links (applinks). You can see its entitlements with the command codesign --display --entitlements - /Applications/Twitter.app in Terminal. My theory was that Safari would hopefully look at the fake app with the higher version number instead of the real app with the lower version number, and decide that Twitter did not actually support Universal Links.
It appears that my theory was correct! You can download my new app StopTheTwitter, which is notarized for macOS Catalina.
Previously:
Update (2022-04-21): Rene Ritchie:
On the flip side, I’m super sad that so many apps intercept universal links and throw me into a web view just to keep me contained
This should be a built-in part of Settings for each app so that the user can choose and also see what the current setting is.
Update (2022-04-26): Jaanus Kase:
I did a study of Universal Links last summer, and found them to be plain broken on macOS with SwiftUI app lifecycle. Plus I could not figure out “developer mode”.
Update (2023-01-31): Jeff Johnson:
Universal Links on the Mac operate via the swcd (Shared Web Credentials Daemon, /usr/libexec/swcd) process.
[…]
The solution to the problem is to deny swcd with Little Snitch.
However, I’ve already allowed the Universal Link, which is still in effect. I also need to undo the damage of allowing it.
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f -R /Applications/Twitter.app
Previously:
Apple Developer App Entitlements iOS iOS 15 Mac Mac App macOS 12 Monterey Privacy Safari StopTheTwitter Twitter Universal Links Web WWDC
David Smith:
After 9 years, I’ve decided it’s time to shut down Feed Wrangler. I’m stretched too thin with my other apps, it’s time to let it go.
I’ll turn off the servers next year on March 1, 2023.
See also: Widgetsmith 3.0.
Previously:
Feed Wrangler RSS Sunset Web Web API
Martin Mitrevski:
SwiftUI has been around for almost 3 years now, and during this period working with it, I’ve noticed few groups of developer mistakes (both mine and from others) that can impact its performance. In this post, we will look at these pitfalls, and their potential solutions.
[…]
We are using an in-memory image cache and whenever we receive new value, we publish it and the corresponding view redraws. However, all the others are redrawn too. Whenever a new image is downloaded, the @Published images is updated and it fires a new event. The ListItem uses the ViewModels image(for:) method, which depends on this published variable. So it’s called for all views whenever a new image is downloaded and this can cause sloweness with the many not needed view updates.
[…]
SwiftUI relies on the type of the views to compute the diffing. If it’s AnyView (which is basically an unknown type), it will not know how to compute the diffing, and it will just redraw the whole view, which is not really efficient. You can find more details about SwiftUI’s diffing mechanism in this great WWDC talk.
iOS iOS 15 Mac macOS 12 Monterey Optimization Programming Swift Programming Language SwiftUI
Howard Oakley (Hacker News):
Apple claims that all its new models using M1 series chips come with Thunderbolt ports which support “USB 3.1 Gen 2 (up to 10Gb/s)”. However, many users have reported performance which doesn’t reach 10 Gb/s for directly connected external disks.
[…]
Currently, and as far as I’m aware since their release in November 2020, no Thunderbolt port in any M1 model appears to fully support 10 Gb/s SuperSpeed+ in USB 3.1 Gen 2, at least for SSDs.
The only ports in M1 Macs which currently appear to support USB 3.1 Gen 2 fully are those on the front of the Mac Studio Max.
10 Gb/s SuperSpeed+ in USB 3.2 devices does appear to be supported by the Thunderbolt ports of M1 Macs.
It sounds like there are multiple bugs here, especially the 20 MB/s read performance when using the ports on the front of the Mac Studio.
Users with USB 3.1 Gen 2 devices should connect them to a Thunderbolt 3 Dock, or the USB ports on a Studio Display, where they should perform better.
I have had trouble using the Studio Display as a hub, as there seemingly wasn’t enough bandwidth for my keyboard while the Mac was cloning to spinning disks connected to the display.
Previously:
Apple M1 Apple M1 Max Apple M1 Pro Apple M1 Ultra Hardware Mac Mac Studio macOS 12 Monterey Storage Studio Display Thunderbolt USB USB-C
Bill Cheeseman:
UI Browser will reach its end of life and be retired on October 17, 2022. The current release of UI Browser, version 3.0.2, will not be updated. On the end-of-life retirement date, the PFiddlesoft website will be closed. Thereafter, it will no longer be possible to download or purchase UI Browser, and product support will no longer be available. UI Browser has been a labor of love for me, its sole developer for almost twenty years. Now that I am 79 years old, it is time to bring this good work to a conclusion.
Thanks to Bill for his many contributions to the Mac community over the years, particularly in the areas of AppleScript and automation.
See also: UI Browser 3.0.0.
Previously:
Update (2022-04-26): John C. Welch:
It is impossible to list or even really comprehend all the ways Bill Cheeseman contributed to AppleScript and scripting/automation on the mac in general.
He is a mostly unsung giant in those communities & everyone in those communities owes him all the gratitude we can muster. Bill was one of the few people whose advice/input I trusted implicitly.
The Mac scripting/automation world will be a lesser place w/o him, but he has earned his retirement in every way possible. I hope he enjoys the hell out of it.
Update (2022-04-28): John Gruber:
The only downside: scripting the user interface this way is tedious (very verbose) at best, and inscrutable at worst. Cheeseman’s UI Browser makes it easy.
[…]
UI Browser seems like a tool Apple should have purchased long ago. It’s like Apple only did the infrastructure of making UI scripting happen, but Bill Cheeseman did the work of making it usable. If UI scripting is worth keeping in MacOS, UI Browser is worth Apple buying. It’s not merely useful but essential.
See also: Late Night Software Forum.
Update (2022-05-09): Federico Viticci:
I think it’s more realistic to hope another indie developer or studio picks up UI Browser and continues developing for as long as possible. There’s nothing else like it on the market, and I’d like to thank Bill Cheeseman for his amazing work on this application over the years. It’ll be missed.
Bill Cheeseman:
I am currently making arrangements for a permanent download site for the version 3.0.2 disk image for licensed users and for public access to the source code.
Update (2022-10-17): Late Night Software:
Bill has graciously agreed to allow Late Night Software to continue making UI Browser available to those that purchased it before it was withdrawn.
[…]
UI Browser is no longer available for purchase. UI Browser’s source code will not be released as open-source. Late Night Software will continue making UI Browser available and supporting it on a best-effort basis for as long as there is a demand for the software.
AppleScript Mac Mac App macOS 12 Monterey Sunset UI Browser
