I found the answer which was simple: open the Service in Automator and choose "Other" in the application drop down box to add other applications. I now have the Service restricted to 5 web browsers.

UPDATE: OK, I found an image elsewhere in SwiftUI documentation that shows the required code. Monkey see – monkey type. So, now I understand what a stroke is !

what are you doing that risks corrupting the workflow declaration file? I'm not sure what might happen but, I am wary of "3" because the raw workflow file contains a lot of XML code I don't understand. Option "4" seems less risky as long as Automator doesn't delete the file. Also, in AppleScript, it's a bit quicker to get the entire contents of the file rather in "3" which would require code which parses the content looking for the version number. I've done test code for both and found "4" a little bit easier.

OK, I tried using automator actions to add the variable to the wflow file. I tried with "Get Specified Text" which I had hoped would pass the value to "Set Value of Variable". Automator said the value of the variable versions was "1.21" which was good. But, in fact the value was not stored anywhere near the variable in the xml file. Instead there is a mass of UUID and RTF data sprinkled in many places. Anyway, I tried your code but, it produced an error: Can't get value of {identifier:"com.apple.Automator.Variable.Storage", |name|:"Version", UUID:"844A34DE-EEA4-48B1-B56C-4941A4510522"}.) So, I'll try another day. Thanks. p.s., I've just found the "variables" pane in Automator Library. Maybe I'll try that. cheers.

It's working. Many thanks.

Many thanks for looking at this. I suspect the problem is with my "strings" files. A while back I had a problem in Script Debugger which, on compiling my applet, removed my custom icns file (Script Editor does that too) and removed the entire "en.lproj" folder. I was advised to rename the custom icns file and to rename all the localisable strings files. I did that. SD now compiles my app normally. More recently, I added French localisation. I think that's why French does not appear in the "Apps" pane – macOS is only looking for strings files which have the default name "localizable.strings". My guess is that macOS has already registered the other three languages and leaves them in place even though I've renamed the strings files. I have tried testing that hypothesis by renaming all the strings files back to "Localizable.strings" and compiling in SD. So far, French still does not appear in the "Apps" pane, although, I don't know how long to wait for the new localisation to be registered (perhaps I have to reboot). The "Apps" pane is weird. I have deleted my applet from the "Apps" pane then added it back. Before adding it back, I can see French is registered: But, after clicking on "Add", the applet is added but French is not shown.

Good advice, many thanks. I'll do up a VM or two to help test my applet in various versions of macOS. Currently, I can test cleanly only in 10.13 and 10.14. I had thought adding an app to the "Apps" pane would add the specific copy chosen – I used the "Other" menu item to locate the copy I wanted to add. But, I think you are right about the risks of having multiple copies floating around. Cheers.

+1. Yes, macOS 12.3.1 seems to have fixed my original problem. I've already changed my AS code from Finder to System Events – which is usually quicker than Finder anyway. Think I'll leave it there.

Sorry, should have posted to Apple Support Communities.

I'm having the same problem. I created a fresh, vanilla plain text file in TextEdit. Then ran this code: set open_this to "MyMac:Users:MyHome:Desktop:MyTest.txt" tell application "Finder" to open open_this I get this error: "The document "MyTest.txt" could not be opened. You don't have permission. To view or change permissions, select the item in the Finder and choose File > Get Info" So, I switched to this code: set open_this to "/Users/MyHome/Desktop/MyTest.txt" tell application "System Events" to open file open_this That produced a new error: "The document "/Users/MyHome/Desktop/MyTest.txt" could not be opened. The file does not exist." This seems to be a variant of the bug in macOS 12.3 which prevented using Finder to open files from within AppleScript. Switching to system Events was a workaround but now, even that is not working.

This behaviour seems not to occur in macOS 12.4 beta (Build 21F79). Not sure it has been fixed in all situations.

Yes, many thanks. It's good to know I'm not the only one caught out. It leaves me wondering: is it possible to create a Ventura beta install drive ? If so, how ? I can't find the Ventura installer anywhere. Also, is there a way to get the Ventura beta into a VM ? I've tried but my Parallels VM refuses to sign in with my Developer Apple ID. How are we expected to test betas if we can't install them safely ? I have sent Apple a (polite) roast via "Feedback Assistant". Maybe someone will read it.

Claude31, darkpaw, many thanks. I did look at the App Store download but, I thought that would be a "combo" update involving a full install. I thought updates were like "delta" updates of the past and not clean installs. I can remove myself from the beta prog but, why can't Software Update show all relevant updates (according to what is installed) ? Anyway, I think I'll just DL from the App Store rather than wait for 13.1. Cheers.

Problem solved. I clicked on "Learn More..." and got this dialog: I clicked on "Restore Defaults" and the 13.0.1 update became visible. Why would my Mac think updates are "managed externally" ? Beats me. Anyway, back to work.

Many thanks. Yes, that test did work – the applet hides normally. There are quite a lot of things in my applet which are different and could be involved: I use Script Debugger, not Script Editor. The applet is quite large with over 6,000 lines of code in 4 script files, a separate Service and 3 executables. The applet has windows which are created with the Dialog Toolkit Plus script library from Shane Stanley, modified by me. [Sorry can't provide a link - this Forum rejects the URL] All the applet windows are modal (due to design of the Dialog Toolkit). Nonetheless, the main app window has been hiding normally since late 2018. I don't understand why the behaviour would change now. My only guess is that something changed in macOS recently that disclosed a flaw in my applet. Evidence for that is that versions of my applet (e.g. January 2022), which previously behaved normally, do not hide reliably in macOS 13.0.1. There was no such problem in macOS 12. Maybe I have some deprecated code which has become problematic. For example, in the Script Library, I am using a property "NSLeftTextAlignment" instead of "NSTextAlignmentLeft". I stayed with the old form because the new form crashed my applet no matter what I tried. Maybe the problem is the main window being modal. But why would that not be an issue before now ? Anyway, the applet still works which I think is quite something.