I have a question with XD plug-in development. We do all our coding in C++/C/Objective C as required. But with XD it seems that Javascript is the only way to make a plug-in. We cant rewrite entire chunks of code in Javascript so, we are wondering how can we do a Javascript to C++ binding or if there is a C++ exposure in XD we can use?
Alternatives/suggestions are welcome also.
Hello, Paul.
I am actually dealing with the same problem at the moment and am new to XD development.
Here is a doc on how to bridge C++ with UXP https://www.adobe.io/photoshop/uxp/2022/ps_reference/media/cpp-pluginsdk/ .
They also have an example C++ program that uses this functionality - it is packaged with the Photoshop SDK that you can find here Loading... | Adobe Developer Console (search for Photoshop and then " Photoshop Plug-In and Connection SDK"). If Photoshop is what you’re interested in… But I didn’t get it running yet. And the documentation is very old (15yrs and older) and difficult to read.
Will let you know if I have figured this out.
Hey there!
XD, generally speaking, doesn’t provide a C++ SDK (the way that, e.g., Photoshop does).
So the short answer is that it’s not possible to use C++ to develop plugins for Adobe XD (this is possible in Photoshop where the C++ APIs predate the UXP ones and we, therefore, have bindings from UXP to these C++ based extensions).
However, depending on your needs, you might be able to use some of your C++ code by compiling it to WebAssembly. For example, WebAssembly might be helpful (and your best bet) if you have some heavy computation you need to do on a C++ side.
I’m, unfortunately, not an expert when it comes to WebAssembly, but we have a sample on how to use Rust-based WebAssembly in a Photoshop UXP plugin (which should be pretty much the same in XD) at uxp-photoshop-plugin-samples/wasm-rust-sample at main · AdobeDocs/uxp-photoshop-plugin-samples · GitHub.
All in all, this, of course, will only be able to solve particular problems but is currently the only way of using languages like C++ in XD whatsoever.
I hope this helps (even though it’s probably not the answer you were looking for). Please let me know if you have any more questions.
Best,
Pablo
Thank You for the answer, Pablo 
WebAssembly is the possible solution I’ve been playing with since yesterday. I managed to get a simple hello-world C++ app compiling to WebAssembly and then running in both Photoshop and XD. Likewise, I am an not an expert in WebAssembly and am now dealing with difficulties compiling a larger project that is dependent on external C++ libraries to handle 2D geometry.
Anyways, I’m glad to have a confirmation I’m going in the right direction, will have a look at the Rust example, and will share my progress in case I (hopefully) succeed or run into any interesting issues.
Cheers
Hi Pablo,
Thank you for the response. Would it be possible for example to write an XD plug-in that would say drive an external process and be able to communicate with it?
Regards,
Paul.
Yes and no.
It is possible to communicate with other processes (e.g., using web-socket-based communication with a server on the external process die of things). You can see one sample of using an (in this case Electron-based, but the principle remains the same) helper app and communicate with it https://github.com/AdobeDocs/uxp-xd-plugin-samples/tree/main/desktop-helper-sample.
However, it is currently impossible to initiate/run that process from the plugin itself. We’re still working on a permission system to allow more native actions without compromising the security end of things. As you can probably imagine, if a plugin downloadable from an “App Store like” experience could delete the entire user folder, that … wouldn’t be too good (and could create issues for all plugin developers as user trust would be compromised).
So, all in all, your best bet would probably be to have an external helper app and if it’s not running, ask your users to run the helper app in the plugin’s UI, for the time being.
Hey guys 
Just a quick update: WebAssembly compilation of a larger C++ project works (incl. the use of external math & geom libraries through the package manager vcpkg - those were a little problematic) and I am able to build a common solution for both Photoshop and XD.
That’s awesome, @matus-lttr! Thanks for letting us know 
Hello,
Thank you for the information. This is a great starting point as our main concern is XD. I’ll take this back to my team.
Hi Pablo,
I am going to reference the external helper app issue I raised before along with your comments. At present all our plug-ins for the CC apps call and launch an external helper app that does the brunt of the computation and communicates the results back to the plug-in. No user interaction is needed to launch the external helper app. The plug-in is able to launch it on both macOS and Windows (there are many benefits also by using the external helper app as we are able to use features such as concurrent processing, protect the main Adobe apps if our plug-in goes astray during the computation; further more this way the Adobe apps memory management isn’t taxed). So its a win-win for the user (this architecture of ours has been in place for 14-years now). You brought up a point saying:
“However, it is currently impossible to initiate/run that process from the plugin itself. We’re still working on a permission system to allow more native actions without compromising the security end of things.”
So we’re wondering what is so different about XD vs. say the core Adobe Apps (Illustrator, Photoshop, InDesign) preventing this to occur?
Thanks.
Hi @paul_at_reco,
You can find a lengthy discussion surrounding the topic here: Run External Application from XD Plugin - #13 by PaoloBiagini.
Please note that I wasn’t with Adobe then (just another plugin developer) => my points in that post don’t represent any “official position” (for that, you’ll need to have a look at Kerri’s comment there).
Long story short (/-ish 
):
There are two aspects to this. First, on a technical side, CEP had a full NodeJS integration, meaning it would have almost been impossible to stop this from happening. Thanks to UXP, we now have an opportunity to do it “the right way”, which isn’t (in my opinion) fully disallowing running external apps, but doing so after users gave explicit permission to do so.
Why do we want that? First, UXP plugins are easier to install than anything before (with an “app store like” experience using the Creative Cloud Desktop App). Users don’t necessarily expect a plugin to have deep system permissions and often install a few plugins to try them (which is fantastic as it also empowers small plugins built, e.g., by designers, to automate some tedious tasks). Suppose a malicious plugin executes something that it shouldn’t do (even without admin permissions, there’s a lot that shouldn’t get done, e.g., deleting stuff from the user folder). In that case, this could destroy trust and be bad for all plugin developers.
To avoid that, we want to have something comparable to mobile apps, where you get a popup (the first time) about “XY wants to access your file system” / “XY wants to run an external app” / something like that and then you can run an external application (since, of course, as you say, there’s a lot of benefit of plugins having the possibility to launch/drive external apps). This way, users get the explicit notification that the plugin wants to do something with deeper permissions and can make a conscious choice about that (users might think twice about giving a shady-looking plugin such access, while they wouldn’t expect a plugin to have that level of access “by itself”).
So, overall, it’s a combination of the ease of installation (requiring user trust) and just having an opportunity to make it right that’s the main factor.
While I understand that this isn’t ideal for you (as it, as of right now, still prevents you from achieving your result), I hope it still makes sense why we want to do this with a permissions system.
Thanks,
Pablo
PS: Here’s another post by @kerrishotts that sums it up better than I can 
: System Call Access for UXP - #12 by kerrishotts
Hi Pablo,
Just to understand this post. Is the permissions systems needed to run external processes available for use? Or is this a roadmap item for the future? I am interested in the ability to run source control commands (in a Photoshop UXP plugin) on an open document and it sounds like I would need the permissions system in order to accomplish this.
thanks,
-Liz
Hi @Liz,
The permission system will (most likely) be something that needs to exist before running arbitrary system commands. It currently doesn’t exist yet, though. So the latter: a roadmap item for the future.
In other words: It’s currently unfortunately impossible to run arbitrary system commands in UXP (as also, the permission system doesn’t exist yet). The best way to do that would be to use an external helper app to run the commands and communicate with your plugin.
Thanks,
Pablo
Ah got it. Thanks for the response!
Hi @pklaschka, Sorry to bring this up again. I was wondering if there is any way to package the external helper app or even another plugin (C++ or otherwise) with an UXP plugin such that you only had to do 1 install? Thanks -Liz