Yes. The idea is that the contents of the run-only version generally differs only in its run-only-ness.
OK. I’ll edit the bundle ID in the master to match the run-only name. But great, great word usage with run-only-ness. I will definitely use that in class! 
i’m seeing reports that every time an app using AppleScript in Mojave beta 6 tries to access Safari or Chrome, it asks for authorization. Not just once, but every time. Anyone seeing that here?
If so, seems like this kills automation. If every time an AppleScript tries to get data from one app to store in another app, the user is forced to confirm for both apps, then many users will reject the script.
NDAs limit what can be said about Mojave, however what you describe is not the case.
About the only publicly discussable information on this is at the moment is what was said here:
https://developer.apple.com/videos/play/wwdc2018/702/
Aside from that, any reports you see about AS and Mojave are really beta-testers fuming in public when they should be just quietly submitting the bugs to Apple. There are Apple-hosted private and public discussion forums available for those people, so why they can’t stick to them (and the NDA) is both a mystery and a bit annoying (in that it unnecessarily worries other folk who should just relax and wait for the public release). 
Here is the the Mojave documentation that accompanies Script Debugger 7.0.4. If you have Mojave concerns or questions relating to Script Debugger, please post them on the private Script Debugger Beta section of the forum.
https://latenightsw.com/mojave-brings-in-big-security-changes
This link at the end of the documentation page seems dead.
Thank you for pointing this out. We are holding back on releasing that post until Mojave ships and we know more and we are able to speak more freely.
1 Like
Without knowing their current authorization status, apps can’t guard against triggering an authorization prompt that blocks their sending thread indefinitely.
go on this Linksys Router Support
if you face the router problem.
Man does that dialog get annoying when you see it for like the hundredth time… 
1 Like
iOS automation is starting to look relatively friction-free …
1 Like
I monitor Twitter for anything AppleScript related and the amount of confusion caused by Mojave’s AppleEvent security changes is vast. It’s effecting Automator, AppleScript, Keyboard Meistro, TextExpander, and everything in between. Since there is no documentation on from Apple, people are trying to divine the workings of the macOS automation black box for themselves.
Apple has really dropped the ball on this breaking change. There is no mention of any of this in the 10.14 release notes. It has fallen to developers to try and explain the consequences of these changes relative to their products. What a mess.
What’s the best channel for people to use to ensure that cries of pain are plainly audible in the infinite loop or apple park ?
File bug reports with Apple. Don’t yell, scream, lecture or threaten. Explain what is not working and how to reproduce it using Apple’s software - one issue, one bug report. Explain how the change is harming your business or your use of macOS. Consider each bug report with Apple to be a vote. Nothing happens within Apple without a bug report.
Don’t expect them to reverse these changes - a hardened macOS is clearly the future. But we can encourage them to improve the implementation so its less of a problem.
P.S. The people implementing this stuff are not dumb. I just think the full ramifications of what they are attempting to do were not understood. I have no direct knowledge, but I suspect the people doing SIP decreed new restrictions in Mojave and all the groups doing software higher up in the stack were trying their best to deal with this change.
3 Likes
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.
Mark (@alldritt), thanks for your guidance.
Please be aware that most of us, or at least me, don’t know how to do most of the things you suggested.
So, may I suggest, that you provide all of the details to:
- File a bug report with Apple. (can I do this even if I’m not a developer?)
- Provide a detailed suggested text of what to file.
- Remember, that the easier you make it for us, the more likely that we will actually file.
Thanks.
My apologies. Of course, I should have explained this.
-
You need to have an Apple Developer account. The free one is fine.
-
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.
2 Likes
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).
1 Like
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.