Apple:
We’re introducing updated terms that will apply this fall for developers with apps in the European Union storefronts of the App Store that use the StoreKit External Purchase Link Entitlement.
[…]
Developers can communicate and promote offers for purchases available at a destination of their choice. The destination can be an alternative app marketplace, another app, or a website, and it can be accessed outside the app or via a web view that appears in the app.
[…]
Developers may design and execute within their apps the communication and promotion of offers. This includes providing information about prices of subscriptions or any other offer available both within or outside the app, and providing explanations or instructions about how to subscribe to offers outside the application.
[…]
Developers can use any number of URLs, without declaring them in the app’s Info.plist.
Links with parameters, redirects, and intermediate links to landing pages are permitted.
Apple:
If your app communicates and promotes offers for end users at a distribution channel of your choice, pay an initial acquisition fee [5%] and an ongoing store services fee [20%].
Juli Clover:
Developers do not have to opt in to the new terms with the Core Technology Fee to take advantage of these link entitlement changes, but must agree to the StoreKit External Purchase Link Entitlement Addendum, which is coming this fall. These terms require developers to use the StoreKit External Purchase APIs, report external purchase transactions, and pay fees and commissions.
[…]
There is one other notable change that Apple is making, and that's giving customers an option to turn off in-app disclosure sheets. By default, Apple will still warn users when they are clicking a link that takes them to non-Apple purchase methods and options, but customers can choose to turn off these warnings when an app links to an external channel. An app that links to an in-app web view will only need to display the disclosure sheet once per session.
Benjamin Mayo:
However, for instance, if the user downloaded the app on their iPhone, but then initiated the purchase later that by navigating to the service’s website independently on another device (including, say, a Windows PC or Android tablet), the Initial Acquisition Fee and the Store Services Fee would still apply. In that instance, Apple still wants its cut as it sees the download of the iOS app as the originating factor to the sales conversion.
[…]
This results in a complicated matrix of eligibility and fee costs, that developers will need to carefully evaluate.
[…]
Apple says the new structure results in lower fees for developers in both the alternative and existing terms for linking out, especially for existing users. This is because previously Apple charged upwards of 17% and the Core Technology Fee, for the privilege of linking out to an alternative payment method.
Benjamin Mayo:
Imagine you are Spotify. You list your app in the EU on the Apple App Store, and link out to your website for payment.
Assuming a new user downloads the iOS app first, you will now be subject to a >20% commission on any new purchases; that includes if the purchase is made later on the web on an Android tablet.
Steve Troughton-Smith:
Here we go again. Fees upon fees upon fees.
Dare Obasanjo:
The interesting dance around Apple’s DMA compliance is that it seems clear that the EU wants Apple to stop taxing developers for IAPs while Apple’s compliance is to just rebrand the fee and keep the tax.
Kyle Howells:
This is insane.
Apple’s new rules aren’t any better either and aren’t going to be allowed either.
They are just dragging this out as long as they possibly can.
Previously:
Update (2024-08-09): John Gruber (Mastodon):
What many people want is for Apple to just give in, concede, and allow iOS apps in the EU to just collect payments however they want, in-app or through links to the web, freely. Where by freely I mean free-of-charge freely. No CTF for downloads, no tracking of purchases made after users tap a link in the app to the web. What Apple wants is to continue making bank from every purchase on digital goods from an iOS app. We’re left with a mess where no one is happy with the result.
M.G. Siegler:
Wait a minute. What’s that? At the bottom. The last bullet point: “Updated business terms for apps with the External Purchase Link Entitlement are being introduced to align with the changes to these capabilities.” What could that mean? Humorously and fittingly, there’s no link. And the link below to “learn more” about all these changes is broken.
Yep, I had to guess at the link I quoted above.
Apple, of course, will note that they’re okay with the changes they’re offering but have the right to be compensated for their IP and infrastructure usage. And that will be hard to argue with, legally, if nothing else. But you can’t help but feel that this is getting so impenetrable that it’s almost like Apple is doing it this way on purpose.
Nick Heer:
I am not sure what business standards apply here and whether it is completely outlandish, but it sure feels that way. The App Store certainly helps with app discovery to some degree, and Apple does provide a lot of services whether developers want them or not. Yet this basically ties part of a developer’s entire revenue stream to Apple; the part is unknown but will be determined based on whichever customers used the iPhone version of an app first.
[…]
None of these changes applies to external purchases in the U.S., for example. But what I wrote at the time applies here just the same: it is championing this bureaucracy because it believes it is entitled to a significant finder’s fee, regardless of its actual contribution to a customer’s purchase.
Matt Birchler:
Two, sometimes I propose some new feature I want Apple to implement, and there’s a weird vibe from some people who seem to think I expect Apple to implement that feature badly. Of course I would want them to do it well…that’s like the entire reason we use Apple’s stuff, right? Well, this DMA behavior is exactly what those people are thinking about: Apple is implementing features as poorly as they can so that people hate them.
[…]
Anyway, this is all really annoying and I wish they would treat these required changes the way they’ve treated things like adopting USB-C or RCS where they do them well and lean into how they make their users’ lives better. This whole affair looks so petty.
Juli Clover:
Spotify likewise didn’t have anything nice to say about the updated link rules. In a statement to TechCrunch, Spotify said the revisions are “deliberately confusing,” but “at first glance,” Apple is continuing to “blatantly disregard” the requirements of the DMA.
Jeff Johnson:
Developer tools are not charity. Apple platforms would never have achieved their current success without 3rd party software.
[…]
Apple monetized its IP to the tune of $60 billion in hardware sales last quarter.
[…]
Rogue Amoeba’s Airfoil sold countless Airport Express units for Apple. Did we get a cut of that? Hell no. Of course not. And that’s fine. Apple sold its hardware, and Rogue Amoeba sold its software for Apple’s hardware.
That was the mutually beneficial relationship between Apple and developers since 1977. But it all changed in 2008, when Apple greedily decided that it wanted to double dip: increased 1st party hardware sales from 3rd party software and ALSO a cut of that software revenue.
The Animal and the Machine:
I’ve started a hammer business. I’ve sold the hammers but I expect to be very rich now as I’ve deployed the Apple business model where I collect a third of the revenue from every builder and crafter.
We are so lucky that the Web was invented before the App Store.
Update (2024-08-13): Chance Miller:
It’ll be interesting to see how the European Commission responds to Apple’s latest changes in the EU, given that Google and Apple’s terms are more similar than ever before.
Steve Troughton-Smith:
It’s almost like the two duopolists are colluding on pricing.
Update (2024-08-14): Emma Roth:
But using the feature comes with fees so steep that it’s hard to imagine any developer using it.
[…]
Apple’s latest changes offer some improvements, but they come with the same caveats that make it more difficult for developers to do business.
Update (2024-08-15): Joe Rosensteel:
The part I’ll never understand is the assumption that the App Store is the reason a developer, or corporation, was able to acquire a sale. The days of people browsing the App Store are long gone. People hear about, or encounter ads for, apps and services in the real world or online and then have to download the app. The App Store serves as a hosting venue for static code. It’s Tucows. It’s not doing anything.
Antitrust App Marketplaces App Store Business Digital Markets Act (DMA) European Union iOS iOS 17 Top Posts
Matthias Gansrigler (Mastodon):
As a macOS engineer, what do you do when you’re told by Apple’s security team you have to turn it even more into Windows Vista and place even more useless alibi-security permission dialogs somewhere, but you’ve run out of new places to put them in?
Well, you get creative, and show multiple permission dialogs for the same permission.
Can’t innovate anymore, my ass!
Chance Miller (Mastodon):
With macOS Sequoia this fall, using apps that need access to screen recording permissions will become a little bit more tedious. Apple is rolling out a change that will require you to give explicit permission on a weekly basis to these types of apps, and every time you reboot your Mac.
[…]
While many speculated this could be a bug, that’s not the case.
William Gallagher:
There are accessibility apps that use screen recording, for instance. Keyboard Maestro can use it to look for specific buttons being shown on a screen, and even the Bartender app uses it as part of controlling menubar apps.
[…]
In each case, before the recording can be started, a prompt appears saying that a specified app “can access this computer’s screen and audio.” Curiously, it does not as yet offer the option to say that you don’t want this.
[…]
There does appear to be a bug in that sometimes there is a significant delay before the Continue to Allow button responds to clicks. It’s also inconsistent in how sometimes clicking that does allow the screen recording, but the screen recording shows that prompt.
Craig Hockenberry:
I’ve always been proud that xScope is a tool that sits quietly in the background, ready when you need it.
So much for the “quietly” part…
Riley Testut:
As someone who reboots my iMac every morning, looking forward to daily permission alerts 🙃
Miguel Arroz:
I’ve caught suspicious things thanks to macOS security warnings like games wanting global keystrokes (nothing evil going on, just shitty open source multi-platform libs).
But this seems excessive. Why not asking if I want the app to have this ability during the next 24 hours, or forever? Either it’s a one off, or if it’s not, I don’t want to have to answer every week.
Jon Gotow:
And if an app isn’t using Sequoia’s new “screen recording picker”, you’ll see this very technically worded warning. I’m not sure how your average Mac user will respond to this.
[…]
Of course, the reason I’m grousing about this is because Default Folder X is affected. In some situations, DFX captures an image of an Open or Save dialog and displays it on top the real file dialog as a “curtain” to hide what its doing while it manipulates the dialog. It doesn’t store or transmit the images – it just takes a screenshot of the file dialog, pops it up on the screen to obscure the dialog while it twiddles a menu, then throws away the screenshot.
Now Sequoia is throwing up scary weekly reminders about it recording “personal or sensitive information”. Sigh. Assuming that this new Sequoia “feature” is here to stay, I feel the only workable solution is to remove the screen captured façade and just put up a blank window to hide what Default Folder X is doing. This is … ugly.
Kyle Howells:
The privacy teams in Apple have way too much power.
Someone high up enough in Apple needs to start telling them NO.
My number 1 feature request for iOS and macOS is a big switch to turn ALL these “are you sure you want X to still have permission to do Y” off forever!
Every time one of those puts up it both: interrupts me; and presents an opportunity to break things!
Erik Schwiebert:
Yes, really, this Mac is under our full control (in fact, it gets paved and re-built multiple times a day) in a secure lab. WTH is it prompting for permissions all the time? There isn't even a TCC entry to suppress the alerts when you are full admin. Sigh.
Tuomas Hämäläinen:
I share my screen on Teams all the time, and I think drawing/design apps that want to sample colours outside of their windows with the eyedropper tool also need to use this API, so looks like I’m gonna be seeing this a lot…
Apple have made Mac OS into exactly the thing they made fun of Windows Vista for. After some time, no one is going to be reading these dialogues anyway, people will blindly click on “allow”, effectively working against the intent of better security.
Luc Vandal:
macOS: Gradually making your Mac more annoying each year because “security”.
Jason Snell:
It’s part of a general trend for Apple to continue placing barriers in the way of users who are trying to use software on the Mac.
[…]
For the past decade, Apple has been trying to tighten the screws on the Mac in order to bring it closer to the level of security offered on iOS. And on iOS, it’s also restricted software features, including a (supremely annoying) feature that repeatedly asks you if you want to continue allowing apps to track your location.
[…]
But what Apple’s testing in the latest macOS Sequoia betas is brutal because there’s no end to it. It’s a subscription you didn’t buy and can’t cancel.
[…]
Asking for permission a second time is not unreasonable for the reasons I mentioned above. But at some point the user must be in charge. […] Some users will make bad decisions. That’s just reality. The wrong reaction is to take the decision out of every user’s hands to protect the ones who might do something stupid.
[…]
Apple’s recent feature changes suggest a value system that’s wildly out of balance, preferring to warn (and control) users no matter how damaging it is to the overall user experience.
Steve Streza:
The Vista-ification of macOS is so incredibly sad to watch. It is going to grow harder and harder to convince people not to shut off security features because of how annoying they're getting. Apple is becoming the thing they mocked (and sold a lot of Macs on the back of mocking).
Sami Samhuri:
Can the macOS team please stop? This is worse than UAC.
Matthew Cassinelli:
Worst decision Apple has made in years.
John Brayton:
The excessive permission checking is probably the most frustrating aspect of using a Mac.
Martin Pilkington:
After winning an Oscar and an Emmy, Apple is moving onto the next step in getting an EGOT by going for the Tony Award in Security Theatre 🙄
Mike Rockwell:
I’ve been toying with Linux again on my 11-inch MacBook Air and I absolutely love how much control you have over the system. Maybe DHH is onto something with his switch away from macOS.
Jason Snell:
And you know what they’ll say if Apple just declares this a “beta bug” and addresses it before launch: “What were you guys all complaining about?”
But we know that if we don’t complain, this all just slides through and we’re stuck with it.
Nick Heer:
But relentless user confirmation is not a good answer for privacy, security, or competition. It merely kicks the can down the road, and suggests users cannot be trusted, yet must bear all the responsibility for their choices.
Matthias Gansrigler (Mastodon):
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.
[…]
I feel like apps on the Mac App Store should get some perks for being reviewed and vetted by Apple’s App Review.
[…]
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.
And similarly for core permissions for other app types.
Guy English:
If adopting new APIs is what developers need to do in order to avoid these user hostile dialogs is what is needed then Apple should provide sample code showing how to move from the old to the new. If the App is on the Mac AppStore they could and should reach out to apps with that entitlement and point the developers in the right direction. For extra points allot Apple dev rel folks to do the conversion for them if needed.
This helps the user.
Daniel Jalkut:
I think the problem is there is no new API to avoid the hostile dialogs. They occur with the newest APIs.
Craig Hockenberry:
You’d think that Apple would have figured out that letting developers know about Security changes ahead of time would be a good idea.
Craig Hockenberry:
A friend pointed me to this [Persistent Content Capture entitlement] the other day and it feels like a solution to the (justified) uproar over the screen sharing nag.
The issue here is that Apple has provided no documentation or any other guidance on how to get this entitlement and prevent an app from becoming nagware.
Isaiah Carew:
we’ve clearly hit an inflection point. the kickback from the macOS screen recording warning has been huge.
for years apple has slowly improved security, but at extreme detriment to usability, functionality, and developer pain.
i think this either means apple listens and changes course here right now or the groundswell will continue and accelerate.
i have trouble being optimistic in these cases, but they did eventually listen about the shitty keyboard. so hope is not entirely lost.
Jason Snell:
Here’s the thing. Apple should be making it harder for apps to do stuff without users understanding what they’re approving. But with great power comes responsibility. If you’re going to make these changes, you have to make the effort to mitigate the UX disaster. If you introduce new, better APIs, you need to evangelize them to developers and document them properly.
Too often for the last few years Apple does step one and then fails to do steps two and three. Step one is not the sin.
John Gruber (Mastodon, 2):
I think it shows just how much care and thoughtfulness went into turning up the dial on these nags that the button label incorrectly capitalizes the “to” in “Continue To Allow”. You can say, well, that’s a little thing. But that’s exactly the sort of little thing that almost never shipped from Apple, even in beta, until the last few years.
Having to click through these confirmation nags every week, for every such utility you use, is not a little thing at all. It’s the sort of thing companies do when decisions like this are made by people looking to cover their asses, not make insanely great products.
Craig Hockenberry:
The biggest win for the user experience would be to reorganize System Settings around the apps, and not the categories.
I want to see all the things that Google Chrome can access, not dig into Extensions, Privacy, Location, et. al. (and don’t get me started on search capabilities).
Harder than it is on iOS because there are more things to allow/deny, but it’s the way folks expect it to be.
Anything short of that is just a bandaid.
Jeff Johnson:
That info should be in the Finder Get Info window and/or preview pane. Also when you press and hold an app icon on the iOS home screen.
Juli Clover:
Apple’s User Privacy Engineering Manager Katie Skinner and Privacy Product Marketing Lead Sandy Parakilas recently sat down with YouTuber Andru Edwards for a wide-ranging discussion on Apple’s privacy policies.
Previously:
Update (2024-08-13): Craig Hockenberry:
The thing that really gets me about this screen capture situation in the next version of macOS is that it lays bare the hubris of security folks.
I bet they rarely take screenshots - all their work is low-level internal mechanisms. What good is an image of a SHA hash going to do them?
Meanwhile there are hundreds of thousands of developers working with designers, clients, managers, and other folks who want to see the current state of their work.
We take a shit-ton of screenshots.
Hagen Terschüren:
also … who is surprised when they use a shortcut they specifically programmed to be the shortcut to take a screenshot in a specific app that it then lets this specific app take a screenshot?
i would understand this for background screen recording. but yes, i actually do know what action i want to happen after purposefully pressed three keys at the same time.
Craig Hockenberry:
In fact, folks have noticed that CI workflows that build projects and take screenshots from the command line are also affected.
The only exception is Apple Remote Desktop (VNC) because it has some very specific private entitlements.
Gus Mueller:
Acorn “records the screen” to sample pixels in other apps when you use the color loupe. This is great if you see a color in a Safari window that you’d like to grab, even if you do have to deal with a scary warning (once) from MacOS. At least it was only once, until now.
[…]
This is sad, but not unsurprising given the trajectory of things lately. And if you look closely, you can still see bits of [the canary’s] yellow feather intermixed with the rest of the decomposing body.
John C. Welch:
Let’s assume we only have to give permission once. After that, an app wants to take screenshots, how does the user know when that happens, how often, and what is being done with those screenshots?
[…]
So how do you manage this? Because with a one time forever auth, and a bit of care, I can build an app that seems legit, but meanwhile happily takes screenshots of your Mac, then uploads them to wherever and you’d most likely never know.
So how do you prevent that for a non-technical user in a way that doesn’t make them have to be a sysadmin?
This is a good question. It’s not crazy that Apple wanted to do something in Sequoia, but it’s not clear to me that the solution they went with even helps at all.
Nick Heer:
In response to Apple’s increasingly distrustful permissions prompts, it is worth thinking about what benefits this could provide. For example, apps can start out trustworthy and later become malicious through updates or ownership changes, and users should be reminded of the permissions they have afforded it. There is a recent example of this in Bartender. But I am not sure any of this is helped by yet another alert.
[…]
I do not think this new prompt succeeds in helping users make an informed decision. There is no information in the dialog’s text informing you who the developer is, and if it has changed. It does not appear the text of the dialog can be customized for the developer to provide a reason. If this is thrown by an always-running app like Bartender, a user will either become panicked or begin passively accepting this annoyance.
The latter is now the default response state to a wide variety of alerts and cautions. Car alarms are ineffective. Hospitals and other medical facilities are filled with so many beeps staff become “desensitized”.
[…]
Even if you believe dialog boxes are a helpful intervention, Apple’s own sea of prompts do not fulfill the Jobs criteria: they most often do not tell users specifically how their data will be used, and they either do not ask users every time or they cannot be turned off. They are just an occasional interruption to which you must either agree or find some part of an application is unusable.
Christina Warren:
17 years ago, Apple rightfully skewered Vista for this same sort of behavior. I actually think the Sequoia stuff is worse.
Previously:
Update (2024-08-14): Chance Miller (MacRumors):
In macOS Sequoia beta 6, however, Apple has adjusted this policy and will now prompt users on a monthly basis instead. macOS Sequoia will also no longer prompt you to approve screen recording permissions every time you reboot your Mac.
[…]
A permission request on a monthly basis is certainly better than one on a weekly basis, but I still think there needs to be a way to permanently grant an app screen recording permissions.
Additionally, Apple’s lack of communication with developers about this change has only made things more confusing and frustrating. Likewise, I’ve reached out to Apple multiple times for clarification and have not received a response.
Federico Viticci:
I wanted to share something funny about Apple’s nonsensical permissions for macOS Sequoia, but then I realized that at least Mac users do have those options, so I grabbed my iPad and cried in a corner instead 🥲
Update (2024-08-19): John Gruber (Mastodon):
I continue to think part of the problem is thinking too small, and requiring what’s effectively whack-a-mole with multiple recurring permission prompts. Playing that game of whack-a-mole monthly instead of weekly is absolutely an improvement. But I still think there ought to be a way to grant a properly notarized app permanent permission.
Adam Engst:
Reducing the frequency of these repeated permissions prompts is a step in the right direction, but it is still a mistake. A monthly schedule is less annoying than weekly prompts, but it’s more irritating than what we’re currently accustomed to, with no indication from Apple of why the purported additional security is necessary.
[…]
Also, while specificity in interface language has its place, even I don’t know what “requesting to bypass the system window picker” means, so I can’t imagine that a user less involved in the technical details of macOS would have any clue. Allowing obscure technical language to creep into a user interface is problematic on its own; putting it in a dialog meant to inform ordinary users about a potential security concern exacerbates the feelings of ignorance many people already have. Nobody who would have approved usage the first time would find themselves denying it on a subsequent occasion because of this new language. It’s far more likely that people will tune out the dialog gobbledygook and reduce their overall system vigilance.
Update (2024-08-21): Apple has updated the documentation for the Persistent Content Capture entitlement, clarifying that it’s intended for Virtual Network Computing (VNC) apps and offering a form for developers to request the entitlement (via Luc Vandal).
Update (2024-08-22): Dr. Drang:
The writing of the permissions prompt is as bad as its frequency[…]
[…]
In the original Macintosh OS, warnings were conveyed to the user through a specific type of dialog box called an alert. Here’s an excerpt from Inside Macintosh (p. 401) introducing alerts[…] The last paragraph of this excerpt spells out how alerts could change with each occurrence and gives an example of how Apple expected this mechanism to be used.
Update (2024-09-09): Craig Hockenberry:
Here’s why the Sequoia screen capture stuff is such a worry:
I just got a permission prompt when launching xScope to debug a problem, I had to delete the previous permission to get it to take, authenticate using Touch ID, then quit and relaunch the app manually because it didn’t restart. Then I checked that the Loupe is working.
Now I can’t remember what I was going to debug in the first place.
Update (2024-09-12): Nick Heer:
Here is an excerpt from the release notes for the MacOS 15.0 developer beta[…] It turns out the “and” in that last sentence is absolutely critical. In last year’s beta releases of MacOS 14, Apple began advising developers it would be deprecating CoreGraphics screenshot APIs, and that applications should migrate to ScreenCaptureKit. However, this warning was removed by the time MacOS 14.0 shipped to users, only for it to reappear in the beta versions of 14.4 released to developers earlier this year. Apple’s message was to get on board — and fast — with ScreenCaptureKit.
ScreenCaptureKit was only the first part of this migration for developers. The second part — returning to the all-important “and” from the 15.0 release notes — is SCContentSharingPicker. That is the selection window you may have seen if you have recently tried screen sharing with, say, FaceTime. It has two agreeable benefits: first, it is not yet another permissions dialog; second, it allows the user to know every time the screen is being recorded because they are actively granting access through a trusted system process.
[…]
I think it is possible MacOS 15.0 ships without this dialog. In part, that is because its text — “requesting to bypass the system window picker” — is technical and abstruse, written with seemingly little care for average user comprehension. I also think that could be true because it is what happened last year with MacOS 14.0. That is not to say it will be gone for good; Apple’s intention is very clear to me. But hopefully there will be some new APIs or entitlement granted to legitimately useful utility apps built around latent access to seeing the whole screen when a user commands. At the very least, users should be able to grant access indefinitely.
Update (2024-09-18): Nick Heer:
It turns out this prompt, awkward language and all, made it into the public release.
[…]
In the latest beta release of MacOS 15.1, Apple added a new device management key, forceBypassScreenCaptureAlert, to override the monthly permissions request. […] However, my understanding is this cannot be used by more general users; it is only for managed devices.
Previously:
Update (2024-09-23): Miles Wolbe (via Hacker News):
Jeff Johnson credits Ricci Adams with discovering that ~/Library/Group Containers/group.com.apple.replayd/ScreenCaptureApprovals.plist stores screen capture approval dates. He reports that the file is protected by TCC and suggests granting Full Disk Access to Terminal, using defaults to read and modify the file, then logging off and on to permanently disable the prompt.
See also: Matthias Gansrigler.
Update (2024-09-25): Johan Steen:
Using the color picker to pick a color from my own document.
? Allow For One Month ?
WTF, am I going to be nagged about this, once per month, per app, from now on? I've managed just fine without this baby sitting.
Matt Birchler:
“It’s one pop-up a month, that’s not so bad,” the apologists will say, but dear reader, this is 16 pop-ups at random intervals throughout the month, typically interrupting me in the middle of me trying to actually use these apps for my work. That’s damn near one alert every weekday of the month and I gotta tell you, I hated it during the beta.
Adam Engst:
These prompts are examples of poor user interface design in multiple ways[…] They’re also problematic from a security standpoint for three reasons[…]
Juli Clover (9to5Mac):
If you’re someone who prefers not to get these reminders for screen recording apps at all, you can use the Amnesia app for the Mac to get rid of them. The app basically changes the .plist file for the screen capture app access feature, and it’s a pay what you want situation.
Update (2024-10-08): Juli Clover:
In the release notes for the sixth beta of the macOS Sequoia 15.1 update, Apple says that users aren’t going to see as many popups for apps they regularly use.
[…]
There is no option to remove the popup permanently, but macOS Sequoia 15.1 may make the frequency of the popup more bearable for those who use screen recording apps on a daily basis.
Apple says the apps are using “using our deprecated content capture technologies” even though they don’t have modern replacements for many of the use cases.
Amnesia Default Folder X Entitlements Mac Mac App macOS 15 Sequoia Privacy Screen Recording ScreenFloat Screens Screenshots Top Posts Transparency Consent and Control (TCC) Virtual Network Computing (VNC) xScope
