I'm hesitant to update to Tahoe and Xcode 16, but at least in Xcode 15, you can still add the AppleScriptObjC project templates that Apple removed. I just threw that in there since Xcode has various editors and does a lot of that kind of stuff for you. Get Info stores the icon in the Icon\r file at the root level for a folder, which would be outside the application Contents folder and code signed bits. Script Debugger isn't quite as bad, but the script editors have pretty much always made their own tweaks to the bundle settings when saving as an app, so you should always manually go through the final build and double-check that the assets and Info.plist are set the way you want, including removing the default icon file. I haven't had any problems setting custom icons that way.

The Get Info procedure is a way to set an icon to something different than is already there. The normal way to set an icon is to include the icon file in the Resources folder of the application bundle and edit the name in the Info.plist CFBundleIconFile entry. If using Xcode, it has various options to generate and include the icon as part of the build process.

Inside a Finder tell statement, the term folder is indeed a class. You would need to use the statement outside the tell statement, or use something from the Finder itself such as the kind property, for example: set myVariable to (kind of (directory as alias) is "Folder") Note that kind can differ from info for, since bundles/packages such as applications are technically also folders. The privilege violation is from using the info for command (a long deprecated StandardAdditions command) in a Finder tell statement. There are a few that don't trigger the warning, such as display dialog, but common practice is to only use statements inside an application tell statement that specifically target that application. The terms my or of me can be used for statements that target something else (handlers, etc), but this case is problematic in that the result from info for actually uses scripting terms for the record keys.

VIP is an item related to the Mail "Smart Mailbox" or Contacts "Smart List" constructs, in that it is just something that can be used in a search from which the application can do something like show the results in one of its normal views. While the application can use these results internally, it would need to provide a mechanism for a user to access or use them (or not). As mentioned, if a term (such as a VIP property) is not declared an application's scripting dictionary, the app doesn't provide it, and you can't just make it up. Mail places the VIP data in the VIPMailboxes.plist (XML) and VIPs.plist (binary property list) files in the ~/Library/Mail/V10 (or whatever version) /MailData folder, where they can be used by the app along with other search terms. It may be possible to edit these files, although you would need to figure out what they are using for the keys and how they are linked to the messages.

I just threw those out there because I was aware of them. To build the GitHub project you would need Xcode and know a little about how to use it in order to shuffle around some of the build settings (I'm not much of an Xcode or Swift guy either). It looks like you may have downloaded an older version of SKProgressBar, which has been around for a while and is from one of the regulars at MacScripter.net. The latest released (signed and notarized) version of that is at ht tps://klieme.ch/Downloads/SKProgressbar/SKProgressBar2.0.zip (remove the space, I didn't include it earlier as the forum won't accept it as a link).

How the built-in progress indicator is shown is dependent on what is using it. For an Automator workflow or a script from the Script Menu, the progress is shown in a status item menu by the system's ScriptMonitor application. For each process it just has a menu item with a circular progress indicator and descriptive text, but note that for an Automator workflow the progress is for the workflow itself - e.g. how many actions have been completed. A separate third-party background (agent) application such as SKProgressBar or swift-progress could be used, as it would handle its own dialog independent of the script or workflow. This can also avoid issues when updating the progress in a repeat loop, since normally that doesn't give the built-in progress indicator time to update.

AppleScript hasn't changed much since then; the documentation is still the AppleScript Language Guide (even though it hasn't been updated in a while). There is also the Mac Automation Scripting Guide. If you are wanting to interact with applications, AppleScript is still the way to go - check the app's scripting dictionary for whatever terminology it provides. For Notes.app, a note does have an ID property. The checkmarks appear to be a different feature separate from the HTML content of the note. It doesn't look like this functionality is exposed to AppleScript, although you can create new notes using your own HTML source.

The scripting terms are used when compiling a script that targets the application. What are you trying to accomplish?

Automator and AppleScript applications can be passed files like any other app. Is there a particular reason for using one to run the other?

The Get Specified Finder Items action will only return those items, and the Get Selected Finder Items action returns the current selection in the front Finder window. Your workflow isn't getting anything to move, unless there happens to be a current FInder selection. You would need to do something like use Get Folder Contents on the specified folder(s), and then filter those items for folder names. You may also be able to use Find Finder Items to combine the getting and filtering actions. To see what a specific action is returning, you can view its result.

Actions are designed to perform a specific task, which is usually general-purpose in nature. They do what they do. I don't know what you did before to get windows moved, but your posted sample workflow isn't going to work at all. Take a look at the action info, which specifies what the input and output will be. Opening files returns files (not windows), and the window actions require a window (not an image) to resize or move, which isn't specified anywhere. Also note that there isn't a line connecting the actions, which indicates they aren't compatible (there isn't anything to convert the action's input/output). You would need to do something like open the files in Preview, wait a little bit to let them open, then have the Find Windows action filter for Preview windows. From there, you would need to loop through the windows, resizing and moving as desired, but now you are fighting what Shortcuts was designed to be (like a graphical shell script), and might as well use something more designed for the task, like a 3rd party action or scripting. Shortcuts (and Automator) have their purpose, but they aren't really designed for much beyond batch workflows without some help.

Automator and Shortcuts built-in actions are general-purpose in nature, based mostly on existing shell utilities or common functions, or a developer was generous and decided to include some to support their application. There are tiling and window moving scripts out there (various scripting forums, GitHub, etc), but you would need to graft them into your specific workflow (Run AppleScript, Run Shell script, etc). Other options would be to find 3rd-party actions or make your own, although manipulating the UI is a pain no matter what you use.

The usual approach would be to save whatever the existing delimiters are, set the delimiters to what you want to use, split the string into a list of its text items, restore the previous delimiters, and then just use the list. You are continually splitting the string to get each piece, so all it would take is for the delimiters to get changed/reset somewhere else in the bigger script for the text items to be different the next time you split the string. Another option would be to try using the words of the string.

Finder and/or System Events can provide some information (see their scripting dictionaries), and the Cocoa API (via AppleScriptObjC) can use framework methods such as NSURL's getResourceValue. You would need to provide additional details for a more specific answer.

OK, I am getting a few different errors, but the problem seems to be that for whatever reason (looks like a bug), when you initially click in the window or use the divider or history, the window accessibility properties are not getting set up. Clicking the window again gets things set up, but until then the "front" window doesn't have any properties for the script to use, such as selected tab, so trying to use that throws an error. Unfortunately, this also prevents targeting the window by name, id, tty, etc, so I haven't found a workaround other than to click the window a couple of times before running the script. A command line tool to do the clicking could probably be used, but you would need to get information about the "front" window to get the bounds to click into, which would most likely be way more involved than what you are doing now.