Hello Quinn, many thanks for all this. Normally I use Script Debugger to export my applet run-only. Then, I use SD Notary to sign and notarize. I will try to put your suggestion into that workflow. Up until Tahoe, I was avoiding Script Editor partly because it ignored/wiped my custom icon no matter what I tried. SD, did not. I don't know how to use Xcode. Have tried a few times but found it impenetrable. It will take me some time to get it working even to just create a dummy app with a custom icon. Cheers.

Hi red_menace, Happy New Year. I don't think it's possible to use Xcode to prepare AppleScript applets – I can find no documentation on how. Have tried wandering/stumbling around in Xcode looking for a way. Nothing found so far. As mentioned, Script Editor does not respect a custom icon. It's had that bug for many years. Recently, with the macOS 26 release, Script Debugger was hit with the same bug (I believe SD always uses the latest AppleScript binary which I think is partly the cause). I assume that Xcode even if it can be used for exporting AppleScript applets will have the same bug. Just to be clear, even if a custom icon file is created with the default name, it is ignored and the default icon is shown on the Finder Desktop. Since my first post I've found that the "Get Info..." method works if done after notarization. In my testing, the applet when downloaded with Safari still runs. This suggests that code signing does not take into account such a change to data stored in the bundle's root folder. Need to do more testing.

B347, many thanks. Yes, I did try stylemask but tried different forms: .styleMask.subtract(.resizable) NSWindow.styleMask.remove(.resizable) Window.styleMask.remove(.resizable) Naturally, all my attempts resulted in errors. My app doesn't import AppKit as yet so, I'll just restrict it to running on macOS 13+. It's very early days for me.

Yes, I've thought of volunteering my own Apple Developer ID. However, I think it's best that the signing be by the people responsible for the code. Perhaps the developers can acquire a group Apple ID. Then, users who check the signing details will see the developers' details and not mine. Yes, quite a lot of people would benefit but the developers have no cash. I can donate some $ for an Apple Developer ID for them but, they would not want to rely on me in the long term. I'd rather not build and distribute the Python script to my users myself. The script is updated at least monthly and there are nightly releases too. It'd be too much ongoing maintenance to keep users up-to-date. My applet currently lets users update when they want which means I would have to be up-to-date 24/7. Apparently, it is possible to add code signing to a GitHub workflow. I've had a look and do not understand any of it. There's mention of secrets, actions, provisioning, profiles, etc. As GitHub warn: "You should be familiar with YAML". I did once try to learn YAML but gave up. Cheers. Updated to change Apple ID to Developer ID Updated to remove idea of an organisation developer ID – just not possible for unincorporated volunteer groups !!

Many thanks for this. Seems a bit counter-intuitive – I have thought quarantined code would be safer than non-quarantined. I will do more reading on what quarantining means. The binaries come from GitHub. The tool is a well known public domain cross-platform Python script maintained by volunteers. They are not macOS developers and I doubt they have an Apple Dev ID. They use GitHub's workflows to build macOS, Windows and Linux binaries. They are accommodating in providing packed and unpacked macOS binaries as well as a version for macOS prior to 10.15. Their tool is the best in the business and is used in many commercial and free apps.

imneo, thanks. I can't find a "View As => Source Code" function. But there is a "Open As => Source Code". I tried that but nothing changed. I took a clean copy of the "ContentView.swift" file from the downloaded Zip archive and replaced the existing copy. That also did not change anything. this suggests to me that the bug is in how Xcode uses the xcodeproj file. Looking at my capture above, how is Xcode viewing the code ? As plain text ? As rich text ? I've ditched the entire project and started again – that worked but really it's the nuclear option. I'm glad it's not a production project and is just the Apple tutorial. UPDATE: I opened the old ContentView.swift file in TextEdit and copied and pasted my code into the new copy of ContentView.swift. Xcode seems happy. Cheers.

+1 for those comments that "windowResizability" doesn't answer the question. The question still stands: How can a window be specified to be NOT resizable in macOS 11 and 12 ?

Report the bug using Feedback Assistant. Maybe if enough people complain, someone in Apple will work on a fix.

Piyomaru, thanks you can make standard installer to install AppleScript applets I don't need an installer for my applet. I need a way to automate installing Shortcuts so users do not have to do it themselves in the Shortcuts app. Some minor macOS update may effect your app due to the security reason or bug I don't understand your comment. I would like to use the Shortcuts URL scheme to call Shortcuts Events.app. At present, the URL scheme is useless to me because it always opens the Shortcuts app before running the shortcut. Because the Shortcut app is frontmost and active, it breaks my shortcut which gets URLs from web browsers etc.

Quinn, thanks. I've solved the problem. Eventually, I was able to get my applet notarized, in particular, by adding a new Keychain password profile with: xcrun notarytool store-credentials --apple-id "[appleid]" --team-id "[team name]" That was a duplicate with a new name but, at least notarytool did find it. Interesting that it's not visible in the Keychain Access app. I don't know what I would do if I forgot its details. Even then I couldn't get stapling to work. That was caused by a foul-up with the updates to Xcode 14.3 and the related Command Line Tools. Xcode could not link to the CLTs as shown in attached capture – although Xcode 14.3 is selected in the drop down, Xcode still says "No Xcode Selected": I had to switch to an Admin user account and do a reset: " sudo xcode-select -r". That solve all my problems. In fact, I was able to return to using SD Notary, which is a much easier method. I give thanks to discussions @ StackOverflow and NotarizeApp which had code that made things clearer. Cheers.

Well, I know, RTFM. But, I did look – and in the post, I quoted the advice provided in the API documentation. As hinted at in my post, the advice gave little information on the topic. The declaration "NSBoxPrimary = 0" was useful. The Human Interface Guidelines have good advice on best practices. Maybe I'm a bit dense but I couldn't find any description of the primary and separator box types in the HIG. I've also Googled for a few hours trying to figure it out with no luck. The search tool in "developer.apple.com" only points to the API doco.

See tip #14 in Quinn’s Top Ten DevForums Tips. Many thanks – didn't know about your post. macOS is under very active development and sometimes things break.  Have to admit I was surprised that my applet did hide normally when I tested my first versions years ago. I thought the modal dialogs would not hide. So, I'm not surprised if an under-the-hood change in macOS made apparent my applet's flaw. if you work through my steps but instead use Script Debugger, does that fail? I worked through your steps using SD. I'll try exporting my applet in Script Editor and check whether the result is the same. I'll also do up a test applet using the Dialog Toolkit. At the worst, I'll have to redevelop in SwiftUI. But, that will take me many months if not years – I find Xcode and SwiftUI very hard. Cheers.

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.

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.

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.