Mac - PS 26.4.1 droplets broken

[bellevue scott]

This is on Mac Sequoia. Adobe PS 26.4.1

Old droplets run. But now when I try and create new ones, I get this error that says droplet is broken, would I like to move it to the trash. How might I fix this latest in a (rant) long history of PS droplets breaking?

steps in this droplet are: resize to 50%, save as PNG. Close. 

 

thanks

[LAMY2017]

Odd: "This file was downloaded on an unknown date."

Was it created on another machine?

--update--

one search of Help -- Ps>Help>create droplet -- found instructions for troubleshooting droplets on Windows. I could find no help on Mac.

But, I saw something in the help text that I will guess should go for Mac as well as Windows:

 

[bellevue scott]

Thanks. This droplet was just created, and on the same machine. Nothing was uninstalled. 

[bellevue scott]

More trying. I tried saving a copy rather than "save as" in the actions. But that didn't help. I don't know why it says "this file was downloaded from the internet on an unknown date" because I just created it seconds before I ran it, same machine, same PS. 

[Jeff Arola · Accepted solution]

With the Droplet selected go to Apple>System Settings>Privacy & Security>Security and click Open Anyway for the Droplet.

[bellevue scott]

Thanks. This works. Sort of. I did this but then the first time I ran the droplet I got this message again: 

 I selected  "cancel" and then it asked me for my admin password and proceeded. 

I can't believe that Mac has devolved to this level of unusability. The need to do this every single time I create a droplet is beyond the pale unusable, but given the related issues I've seen since Sequoia, this is much more likely Apple than Adobe. 

thanks for the help. 

[bellevue scott]

I posted this on the forums at Apple.com and they deleted it. This is a Mac bug caused by their new security. 

[bellevue scott]

I really think Adobe needs to deal with this. Again, yesterday and today I was making droplets, and this has so messed with my productivity that it has made PS almost unusable for some things. There has to be a way for Adobe to make it so you don't have to approve every single droplet. 

[Dom Henry]

Since Sequioa 15.5 this has been a headache. Here is a fix.

Currently creation of new droplets (as a .app file) is broken on current version of Photoshop as I write this. However, you can get old ones working as follows.

1. Open terminal

2. Copy in: 

xattr -d com.apple.quarantine

3. Add a space then drag your droplet onto terminal so it copies over the address

4. Which should be like this xattr -d com.apple.quarantine /Users/Username/Filename

5. Hit enter

6. Open System Settings > Go to Privacy & Security - See the Security Menu where it says Allows Applications From - keep this open

7. Open your Droplet - when you get the ...is damaged and can't be opened message hit Cancel

8. Your droplet name should now appear in the Security window with an "Open Anyway" button - click it

9. Your droplet should work

In previous versions of Sequoia this button used to come up as soon as you hit cancel, in 15.5 it is now buried further so you need the terminal entry. At least you can get existing Droplets to work.

[Eric Peac*ck]

I think the root of this problem that the previously working droplet updater within Photoshop itself isn't working anymore. For example when macOS went 64-bit only one had to simply drag and drop all their 32-bit droplet apps onto the PS application icon and they were batch updated to 64-bit. Doing that now creates broken app bundle source files that will likely confuse the average user.

The above could be an Apple Silicon issue since all my Droplets are still compiled for the Intel architecture, but I'm pretty sure I've had the same issue on my Intel Mac when I tried to get PS droplets updated for Ventura or later.

Updating existing droplet apps aside, currently on my Apple Silicon Mac manually re-creating Droplets from actions from Photoshop's Automate menu generates an incomplete app folder  "[Droplet Name] (Universal).appContents". This can be manually fixed by putting all the contents within inside a "Contents" folder, then changing the parent folder from ".appContents" to simply ".app". That has to be a syntax bug where a sub-directory command is missing when the droplet is compiled — and the average user won't know how to do to the above fix.

If that isn't something on-my-end with a funky installation, it's likely an indication that compiling or updating droplets in Photoshop is currently broken. It's been this way for a while and took me some time to figure out workarounds; Someone at Adobe really needs to test their work.

Also, the security issue driving this thread might have been entirely prevented if the droplet app bundles were updated to be properly signed for newer macOS versions, hence the droplet updater needing to be updated/working; I use a third-party node-based automation app called Retrobatch which also uses droplets — and none-of-those have had to be manually approved to run as new macOS versions have come up. Other apps like Apple's own Compressor have a simple "Update Droplets" batch command that just works whenever there are major OS leaps.

[Scott_BFAR]

@Eric Peac*ck Thanks for this. It's very detailed and helpful. It also has concrete examples of companies doing the exact same thing that have fixed droplets, showing that Adobe could fix this if they chose to, with likely not too much effort. 

I tried however to create a droplet using your method of making a folder called "Contents" inside the .appsContent folder and then renaming that folder to .app, but it doesn't work for me. As soon as create a folder called "Contents" inside that folder and put all the content in there, the .appsContent folder's icon changes to the arrow with "PS", indicating that the OS thinks it's a droplet, but then trying to run the droplet gives me this error: 

If Adobe is reading this thread still, it would be super nice to get some input. If users can come up with this much informaton about root cause and similar SW that still works and get us this close to a solution, then surely Adobe could be much more helpful. 

[Eric Peac*ck]

Good catch! I can replicate that as well. It's on me for not actually testing the Universal compiled Droplet after manually getting it to register as a working application — like many of us I ended up here while working on a deadline where droplet issues had come up, and I didn't have the bandwidth to go through all-the-motions.

It's worth noting that the non-working Universal droplet app does not need the manual Gatekeeper security reset even there's are other errors at play.

[Eric Peac*ck]

Another update that may help focus in on what's breaking:

I ran a "diff" check on my Intel droplet vs the broken manually repaired Universal droplet. What was missing is a file called "Droplet.8BDR" in the Resources folder inside the app bundle, but the newer Universal app also has a Code Resources file not present in the older droplet.



Right-clicking the apps and choosing "Show Package Contents" in new tabs, then copying "Droplet.8BDR over to the broken universal droplet app and it now works as expected.

I'm not sure where the droplet-specific recorded actions are actually stored; If those are in "Droplet.8BDR" this manual fix may not work as expected if "Droplet.8BDR" were to be copied between different action-based droplets.

...as if anyone should be manually re-building their droplet apps in-the-first-place!