Thanks for speaking up, Mark. The most perplexing problem is the lack of documentation or any sort of acknowledgement. You and Shane are somehow doing the work that a billion dollar corporation refuses to do, while continuing to provide your own users with a much higher level of customer support.
I typed a lot more, but just erased it. For now, I will just say that AppleScript and automation are so valuable that we will continue to do great things despite the obstacles. Some of us will stick to older OS versions. Eventually, Apple will start listening to users again. Another software company just started doing that this year, after years of ignoring them. Things do happen in cycles. This is a challenging one for us now, no doubt.
I fear giving boilerplate bug text because that will not be effective in helping Apple see the scope and range of the problems at hand. That said, when reporting a bug you need to answer these questions:
What did you expect to happen (or what happened before)
What is actually happening
How do I reproduce the problem
What is the environment you are using (apps, system versions, etc.)
What is the consequence for you (least important part of the bug report)
Where possible, you want to provide enough information that the folks within Apple donāt have to do much to see the issue for themselves. When providing sample code, make it the smallest possible example that illustrates the problem with the fewest external (i.e. non-Apple) dependancies possible. Screenshots, screencasts, etc. are all good ways of demonstrating the issue.
Iāve had a developer account since System 7 or 8. Iāve also filed numerous bug reports, and some of my bugs were fixed. One bug was in AppleScript before and after the move to OSX and was finally closed (something about not being able to get month as text or something).
Itās pretty easy to do, but itās not like here with Mark and Shane. You file a bug report and sometime nothing happens for months, then they respond, and if they didnāt understand you have to start over. Other times theyāre right on top of it.
Also, for anyone that ever signed up for the public beta testing program (even if you never actually bothered to take part), you can also report bugs through the built-in app āFeedback Assistantā. Type it in Spotlight to find it (itās not in /Applications).
Hi, my first post here as I was looking for discussions on the subject.
In my opinion, we should politely ask Apple to reconsider and abandon this approach altogether.
All it does is pesters users with unnecessary annoying dialogs. Nearly all users will dismiss them like annoying flies. Very few users will understand what they mean anyway, and of those few very few would care. And I highly doubt that any kind of additional āsecurityā can be achieved by that.
To the developers it causes a measurable damage by making their products harder to use for no reason whatsoever. An example: user clicks āDonāt Allowā by mistake while using a software trial. As we all know, trial goes to trash to never look at again. And as a developer I sure donāt like any of this.
It makes using Mac yet more complex by adding some obscure unnecessary settings with no benefits to the user.
Iāll submit my suggestion to Apple bug reporter soon. Hopefully Apple will listen if they hear from plenty of users and developers.
The difficulty, I think, is that there is an inevitable tension between security and automation. The balance of forces is bound to favour security ā numbers affected, gravity of consequences, visibility in the press etc etc are all much higher on the security side than on the automation side.
Most big systems suffer from gradual bureaucratic encroachment over decades. macOS is still usable and even to a fairly large extent scriptable. We havenāt yet reached the stage of one of those hotels in which every floor has been taken over by administrative offices, and none are left for guests.
( I think Mark is right ā a single bug report is worth a thousand impassioned voices in the wilderness. Much more likely to improve the quality of the relationship between automation and security )