@ShaneStanley is there a must reason for not allowing Apps to use
prepare storage for domain
I get an error on Ventura 13.1 when I do.
Just to confirm, you are providing your domain name with that command, right?
In my case the command would look something like this:
prepare storage for domain "com.edstockly.123"
(the 123 usually the name of the app/script, or some unique identifier)
Yeah. I think it’s not allowing it for Apps and Enhanced Apps. For now I can only specify the application path instead of path to me which is easy to forget and not a good long term. Rather use domains for everything in the case of 2 apps sharing the same prefs. Which is only necessary because I have a helper app.
Is the domain name you’re providing different to the ID of the app?
Yes intentionally. I have a helper app and an enhanced app and scripts inside app sharing the same prefs for users. I couldn’t figure out a way to have an app respond when url is clicked at the same time if already open as menubar app.
Allowing a custom domain would also be nice to have all scripts and parent app share the same subroutines in a library using the prefsstoragelib so I don’t have to maintain source in different script bundles and the apps.
OK, I was just checking that none of the apps match the ID you are using.
Loud headslap…in all my efforts using defaults then moving to your PrefsStorageLib, I am finding that I missed the most obvious…it is safest NOT to use the Application’s Bundle ID for the Domain. When I tested my app stopped unexpectedly quitting when reading/writing prefs even though I was using (path to me) and I was able to use the domain callout in scripts, script bundles AND apps as long as they did not match the apps Bundle ID. It might be worth adding to the documentation that the Domain Callout should NOT match any application IDs Bundle ID and should be unique. Not that in any way, I should have thought of trying this.
You can also use the for domain parameter instead of the for parameter if you wish to share preference values between multiple scripts. In this case, do not use any existing Bundle ID used for an application.
prepare storage for domain “com.my-domain-name.some-unique-string-NOT-A-BUNDLE-ID” default values
I never thought of this since I was using defaults before which depended on the Bundle ID and use Sparkle.
Since the Pref filenames already saved on users computers use a domain matching ID, do you think it is safe checking for the old.plist and renaming it when starting the application? Is there a method you can recommend using ApplescriptObjc instead of FInder/System Events to search and rename? I can put the code into the app or try and figure out how to trigger using Sparkle. I remember reading something about triggering housekeeping using Sparkle. One less headache a week… 
Not so much safest as required.
I’m not sure that’s strictly correct. The restriction is that no app should use its own ID.
@ShaneStanley Thank you for the clarification. I had no idea that was the case.
Last question…do you think it is safe checking for the old.plist and renaming it when starting the application? Is there a method you can recommend using ApplescriptObjc instead of FInder/System Events to search and rename? I can put the code into the app or try and figure out how to trigger using Sparkle. I remember reading something about triggering housekeeping using Sparkle.
Not really. If you must, consider duplicating and renaming the dupe.
You could instead just get the existing values using NSUserDefaults and its dictionaryRepresentation method, and then use its registerDefaults: method to save them to the new domain. But because that searches all defaults domains, it might not be a great idea.