Deploying and releasing a plugin to the world.

[Doubl3]

Hi Fellow developers,

We are at a point that we need to think (and test) about deploying and releasing our plugin to the world.

So I'd like to know how you guys do it.

Do you use the adobe market or sell it yourself?

What packaging tool(s) do you use?

Are there pitfalls involved or what kind of infanty problems did you face in this domain?

Anything relevant....

Thx a ton in advance for taking time to answer this topic.

Regards,

Doubl3

[Rick E Johnson]

Do you plan to charge for it and use an online activation process? My system wouldn't work well if sold through Adobe Exchange. People download a zip file from the site and (except for the freeare offerings) purchase licenses there, then the plugins activate/authenicate via the internet.

I've looked into installers, but found it to be a bit complicated to adapt someone else's scripting rules to support multiple versions of the plugin for multiple versions of Illustrator in various locations and on multiple platforms. Maybe I just gave up too easily, but users need to drag the plugin from their Downloads folder to the appropriate Plug-ins folder. I hope that helps.

[iLLMonkey]

What type of plugin did you deploy? aip only? extension+jsx+aip?

[Rick E Johnson]

I only do .aip plugins, c++ using CORE. I could be wrong, but I've gone on the premise that plugins are .aip files that go into the Plug-ins folder, and anything else is either a script or an extension. Therefore, I presumed that Doubl3 was developing an .aip plugin as well, but now I'm not so sure.

[Doubl3]

We are making a plugin .aip with CEP extensions as a UI.

[Doubl3]

We plan to charge and activate in some way.

Adobe Exchange is a 'No Go' allready. I'v found out that the 'big plugins' don't bother to touch it and rather sell it themselfs. Adobe promisses a lot but but also fail to delliver a lot... I guess its there businessmodel. Shoot at a lot of things to hit couple...

[Rick E Johnson · Accepted solution]

Payment options such as Stripe (my favorite), Squarespace, and PayPal are pretty easy to incorporate.

There are a lot of software licensing managers out there. For those that work as a website plugin, when payment is completed on your website, activation codes are automatically generated for the relevant products and emailed to the customer.

Next, you'll need to make a connection between the user's plugin and your license database. Your plugin should send an HTTP POST activation request to your website. I don't think HTTP functions are part of the SDK. As I said earlier, using a portal script to communicate with your license manager means your plugins won't be hard-coded for (married to) only one license manager. 😉

Next, your plugin needs to respond to the returned POST to switch from demo mode to licensed mode.

You can, of course, store settings in Illustrator's preferences, but if the user deletes the preferences or upgrades to a new version of Illustrator, the info won't be there anymore. I recommend storing license status in an encrypted license file, and storing your plugin's preferences in your own preferences file.

Encryption, HTTP POST and GET, registration, and JSON-formatted preferences are all built into CORE which made it easy for me. If you incorporate them, I'd like to hear how you did it.

[iLLMonkey]

I'm also a first-time, - to be - , deployee.  Maybe someone can fill me(us) in but from what I understand you need a licence service that generates licences and then use API to register/check within your plugin. You need atleast two sign certificates, one for windows and one for mac to "sign" your files with your certificate. You need to get around installers for both Win/Mac and as @Rick E Johnson mentioned this could get complicated if you have many variables to consider.

[Rick E Johnson · Accepted solution]

Regarding distributing .aip plugins:

For macOS, you need to be a member of the Apple Developer program ($99/year) in order to notarize your compiled code. This lets other Mac users know that the code meets certain criteria and is from a known developer. Apple's Xcode compiler is free.

For Windows, just compile it with MS Visual Studio (not free) and the plugins are ready to install by dragging to the Plug-ins folder.

Regarding licensing:

If your plugins aren't free, there are a lot of ways to handle that. For example:

1) People can mail you money, then you email them the plugin. It can be totally unlocked or custom-compiled to run only on the customer's computer.

2) You can devise an algorithm of some kind, then add code to your plugin to determine whether it has been given permission to run.

3) Use commercial licensing software, which requires your plugin to be coded to communicate with it. I recommend having your plugin communicate with your own server script, which in turn communicates with the licensing software. That gives you the option to change your licensing system or even write your own, so you're not at the mercy of another entity that could (surprise!) suddenly go out of business and everything stops working or (surprise!) double or triple their subscription fees.

Message me if you have specific questions, and I'll do my best to help.

[iLLMonkey]

A couple of questions.

Does the Visual Studio output .aip Work on both PC and Mac? or do they need to be separate since they're signed/notarized differently?

Do you bundle both 32 and 64 bit versions of your plugin? Are people still using 32-bit?

[Doubl3]

While it is theoretically possible to crosscompile for mac on Windows, I wouldn't do it. 

I didn't touch mac yet, but they work with xcode for the SDK plugin development.

The code is the 99% the same (some os specific things make up 1%) but it gets compiled differently.

Also Mac is moving heavaly towards ARM instead of x86 cpu's wich are two verry different architectures.

I wouldn't bother for 32bit unless I'm in a niche market with users that use old 32bit systems.

[Rick E Johnson]

VS c++ will not compile for Macs. CodeWarrior used to have options to compile for both platforms from one code base, and could do so from either Mac or Windows. I miss that! I've never heard of a binary that runs on either OS, although AI 26 and 27 plugins for Mac are "universal binaries" which include code for both X86 and ARM processors on macOS.

I compile for both 32- and 64-bit, although the 32-bit folks are becoming a smaller and smaller minority, especially among those who have gone beyond the non-subscription CS6. It's a simple setting in the compiler, so it's easy to accommodate them.

[Rick E Johnson]

I read up on CEP and see that it requires some sort of signing for both Mac and Windows. Signing for Adobe is not necessary with CORE, and probably not with non-CEP SDK projects. The CEP approach looks horribly cryptic and complicated. :-0

If you download CORE <http://hotdoorcore.com> and look at the sample projects, you'll see a much simpler way to work. It defines UI elements a lot like Adobe's ADM (Adobe Dialog Manager) did before Adobe killed it with CS6. I import SDK suites into my CORE projects and get the best of both worlds. Not selling, just saying...

[iLLMonkey]

Never heard of it but it sound/looks awesome, thanks

[Doubl3]

CEP is awesome when it is right for your project. Once you get it going and set to communicate with the .aip then its like building a website. It allows for more flexible graphical UI's then ADM or hotdoor, but that doesn't mean its 'better'. We did go for the graphical ui's and now it might seem overkill for what I've built so far. 

We did not choose Hotdoor for the reason that we might get stuck with it... again just a choice. 🙂

[Rick E Johnson]

I apologize, I didn't mean to steer your post off on a UI tangent. I admire you for figuring out CEP as you did. The licensing and activation should be easy by comparison.

[iLLMonkey]

It's interesting how different people perceive the difficulty of these things. From my perspective, on a scale of 1-10, JSX=1, CEP=3 and C++ = 11. 

[A. Patterson]

Sorry, late to this thread -- been sick all week -- but we use a full blown installer using WiX and a custom written installer start screen (basically a window that lets you pick a language and then runs an MSI). But our plugin is probably far more complicated than all but maybe two or three third party plugins in the world.

If you're just looking to deploy CEP & a plugin, ZXP might suit you, even if you're not using Adobe Exchange. It still lets you just double-click install (I think! It's been a while!). We worked with Adobe years ago to try and use ZXP, but we had way too many components that had to go to the right place for it to work. But it should handle a 'standard' plugin without many (or any) dependencies and a supported UI framework.

[A. Patterson]

Oh, and our plugins require a license or trial, which you can receive in-application. We use a third party licensing system that I've heavily wrapped in our own custom code & UI. So not something that is easily replicated. For years we just used an 'enter a code' system which had a built in end date (or not), indicated the feature level and could be verified as valid or not. We left that behind about twenty years ago, but it might be a good solution. Though it it won't work if your code is readily available. If the code isn't obfuscated somehow, any licensing will heavily rely on good ill 🙂