Droplets are mini-applications that store user settings and apply them automatically. This requires the droplet application to be changed after it was built by the developer. Doing this on macOS 13 Ventura or later, however, is detected by the operating system as a potential security risk and macOS will show a dialog with an unhelpful 'This application is damaged' message.
You can still run the droplets, but you first need to give them permission to run despite being flagged as 'damaged'. You can do so by right-clicking (or holding the control key and left-clicking, or tapping with two fingers on a track pad) and selecting 'Open' in the context menu.
On macOS 15 Sequoia this becomes even more complicated. Please refer to the user manual of your version of A Better Finder Attributes for full information. This is available from the "Help" menu.
Full details about the how, what and why are available in this Droplets & Ventura YouTube Video.
Follow the instructions on the installation manual page.
If you experience this problem, there is a simple solution to it:
There's a great deal of confusion about file dates, EXIF dates, timestamps, etc. and much about how they work is un-intuitive to say the least. As a result, using A Better Finder Attributes can be a little confusing at time.
Here's some general pointers that help you make sense of the Mac OS X time/ date jungle.
There are two fundamentally different kinds of dates:
File creation and modification dates are attributes of the file system. The creation date is the date (and time) that a file was first created on the file system (e.g. your hard disk). Note that this is different from the time and date that the contents of the file were created, e.g.
Say on the 23rd of September 2008, you scan in an old photo that was taken in 1885. The picture file's creation date will be the 23rd of September 2008.
The modification date of a file, is the last time the file was changed. Just opening a file won't change that date. Saving it or changing its name will update the modification date.
Digital Picture Shooting Dates are entirely different and completely separate from the file creation and modification dates. At the moment that your digital camera (or your scanner) creates the new file, it will store this shooting date INSIDE of the new picture file.
A Better Finder Attributes refers to this date as the "shooting date" or "date and time that the digital picture file was shot" or "EXIF" date. Even though it is often convenient to have the file creation date and the picture's shooting date be the same, they are quite separate. Changing one won't change the other. Depending on your camera and the way you import its pictures to Mac they will usually not be the same by default.
Technically, each digital picture format stores this information in a different place. The most common digital picture format is JPEG and digital cameras use a meta-data block called "EXIF information" to store this information inside of the file. The shooting date here corresponds to the "DateTimeOriginal" field of that standard.
Sophisticated digital cameras store unprocessed copies of the images in so called "RAW" formats. Each camera manufacturer has their own mutually incompatible format.
A Better Finder Attributes can read shooting dates from JPEG and the majority of RAW formats.
A Better Finder Attributes can only change the shooting dates of JPEG files with existing EXIF information and select RAW formats.
A Better Finder Attributes' support for changing timestamps in RAW file formats keeps expanding and depends on the version you are using. At the time of writing the current 5.12 versions supports witing to CR2, NEF, ARF, CRW & CIFF format files.
A Better Finder Attributes add shooting dates to JPEG files that do not already have any EXIF information.
File dates can be confusing and have non-obvious limits in their range and consistency requirements.
Here's a check list:
There's three kinds of dates: the file creation date, the file modification date and the digital picture shooting date (EXIF timestamp). More on this above.
On modern versions of macOS with APFS-formatted disks, dates back to 1677 now work fine, but on older versions of macOS and on volumes using other file systems, file creation and modification dates before the early 1970s remain unreliable. More about this below.
The file creation and modification dates are attributes of the file system. A Better Finder Attributes uses the file system driver of the file system that your file is located on to make the date changes. File system drivers come with different degrees of Mac OS X compatibility.
Changing file dates on volumes (=drives) that are formatted using Apple's own file systems, i.e. the standard "APFS" file system or the older "HFS+" ("Mac OS Extended (Journaled)") format, such as your local hard disk, is no problem.
When you start manipulating files on devices formatted using other file systems, e.g. network volumes, memory cards, some third-party hard disks, etc. file dates will only be changed if the file system driver of the device supports this. Moving the files to your local hard disk will resolve such problems.
A Better Finder Attributes can only change the shooting date of digital picture files that are in JPEG format or in select range of RAW formats, including CR2, NEF, ARF, CRW & CIFF.
A Better Finder Attributes can only change shooting dates of JPEG files that already have valid EXIF information. It cannot add EXIF information to JPEG files that do not already have this information. The "Shot on" date of JPEG files that do not contain EXIF information will show as "Unknown" in the file list.
JPEG-format digital picture files that come straight from a digital camera will almost certainly contain valid EXIF information. Some scanners also add such information.
Not all image manipulation programs will preserve existing EXIF information when they save the file. If your digital picture JPEGs seem to "lose" their EXIF information en route, there's a good chance that you are using a tool in your workflow that removes this information when saving the file.
Mac OS X protects files from un-authorized changes through a permission and authorization scheme. If you are trying to change files that do not "belong" to you or that are important for the operating system (system files, etc), Mac OS X may refuse to execute the changes. You can establish what your access privileges are by selecting the file in the Finder and choosing "Get Info..." from the "File" menu.
Mac OS X protects files from accidental changes by "locking" them. Mac OS X will refuse to execute changes on a locked file. You can establish whether or a file is locked or not by selecting it in the Finder and choosing "Get Info..." from the "File" menu.
The file modification date is the date and time that a file was last modified in any way. As such this date changes when you save the file or change its name. This is perfectly normal.
When a file is in use by another application, it is "locked": neither the contents, nor its creation or modification dates can be changed. Quit the application and try again.
Update July 2026: Good news: on modern versions of macOS this limitation has all but disappeared, provided that your files are stored on an APFS-formatted volume (the default file system since macOS 10.13 High Sierra).
APFS stores file dates as a count of nanoseconds from the 1st of January 1970 in a number format that also allows for negative values, i.e. dates before 1970. Our own tests on current macOS versions confirm that file creation and modification dates anywhere between the 21st of September 1677 and the 11th of April 2262 can be set, are stored faithfully and are displayed correctly by the Finder. The creation and modification dates no longer need to be identical, and the Finder no longer "corrects" historic dates behind your back.
One quirk remains: when a file already has a creation date before 1970 and its modification date is then explicitly set to a date after 1970, macOS silently moves the creation date forward to match the new modification date. If a painstakingly-set historic creation date mysteriously jumps forward, this is why; simply set the creation date again afterwards. Note that ordinary saves do not trigger this: editing such a file updates its modification date to the current time while leaving the historic creation date untouched.
The old limitations still apply to older versions of macOS and to volumes formatted with other file systems: HFS+ ("Mac OS Extended") cannot represent dates before 1904, Windows-style FAT and exFAT volumes cannot store dates before 1980, and older versions of Mac OS X performed unpredictable "sanity checks" that would reset historic dates to arbitrary values such as the 1st of January 1972 — the origin of this section's title.
For the curious, some historical background: in theory, the creation date of a file is the moment when the file was first saved to disk; this is different from the creation date of the content of the file. So if you have scanned in a photo of Edinburgh in 1912 on the 5th of January 2008, the file's creation date should be the 5th of January 2008, not sometime in 1912.. or at least that's what Mac OS X used to assume. When the Finder saw a file dated 1912, it "reasoned" a bit like this: "in 1912 there were no hard disks, so the file creation date is obviously wrong. Let's correct it." Different versions of Mac OS X applied different corrections, and different parts of the system stored dates in different ways, so historic dates were liable to change in unpredictable ways depending on which part of the operating system last processed them. On modern macOS with APFS, this is thankfully a thing of the past.
A Better Finder Attributes 7 introduced warning dialogs to protect users from the older, unpredictable behavior of pre-1972 dates. As of version 7.15, this warning can be switched off in the Preferences; on an up-to-date macOS with APFS-formatted disks, doing so is now safe.
With Application Enhancer installed, all bets are off. This is "wicked cool" software specifically designed to undermine OS X's built-in protection features.
Uninstall it and see whether the problem persists.
Blaming other people for your bugs is plain bad manners, so in our defense let us quote George Warner from Apple Developer Technical Support:
Our (Apple's) official policy is that we don't support APE'd systems. Period. The data miner that parses all the crash logs that are sent to us automatically ignores any report that has APE api's in the backtraces or dylb lists.
Likewise If DTS receives a crash incident with API in the backtrace or dylb list we will not investigate it. Our "standard answer" in this case is to inform the developer that we don't support APE and that we'll only be able to help them if they can reproduce the problem without APE installed.
I would suggest that you do the same for your "user X". ;-)
Email us immediately! It could be that many other people have the same problem. We can only fix the problems that we know about.
We do test each version carefully before a release, but with so many different factors (OS version, installed products, specific hardware, installers, builds, etc..) to consider, it is always possible that a bug does get into a release.
Unfortunately occasionally a bug affecting all users goes unreported for days and causes no end of frustration for everyone. Simply dropping us a line would allow us to fix the problem immediately.. don't be afraid of getting in touch!
Generally speaking it is not a good idea to work on files that are actively managed by an application like iTunes or Photos. You usually need to export the managed files first, then make changes and finally re-import.
MacWorld has got a great tutorial on how to do just that with A Better Finder Attributes.