UXP for Illustrator: Current Status and What to Use Today

By Michael Peters · Published May 7, 2026 · Last updated May 7, 2026 · 7 min read

← Back to Blog

The honest summary

If you’ve come here looking for a tutorial on building a UXP plugin for Illustrator, the first thing to know is that you can’t — not as a third-party developer outside Adobe’s NDA prerelease programme, and not as of May 2026. Adobe uses UXP internally for some built-in Illustrator features, which is why the runtime is technically present in the application. But there is no public API, no developer documentation, and no announced release timeline.

This is not a temporary hiccup or a misunderstanding. The state of "UXP for Illustrator" has been unchanged for several years now — community threads asking about the roadmap go back to 2020 — while UXP for Photoshop and InDesign has matured, gone public, and accumulated a significant ecosystem of third-party plugins. Illustrator is genuinely lagging on this front, and Adobe has not, at the time of writing, said publicly when that will change.

What UXP is, briefly

UXP — Unified Extensibility Platform — is Adobe’s replacement for the older CEP and ExtendScript stack that has powered Creative Cloud plugin development for over a decade. The strategic case for UXP is straightforward:

• Modern JavaScript. CEP panels run in a Chromium webview but call ExtendScript (an ES3 dialect from the 1990s) to talk to the host application. UXP unifies the two: a single ES2018+ JavaScript runtime with async/await, modules, and modern tooling.
• Direct host API. No marshalling strings across the CSInterface bridge. UXP plugins call the application API directly.
• Spectrum components. A native-looking UI library so panels match Adobe’s product design without bespoke styling.
• Better security and isolation. Each plugin runs in its own isolated JavaScript context, sandboxed by the OS, with explicit permission requests for filesystem and network access.
• Performance. No webview overhead and no IPC round-trips on every API call.

Adobe has shipped public UXP for Photoshop (since 2021), InDesign (since 2022), and the now-deprecated XD. Illustrator’s name has been on the "coming soon" list for most of that time without a date.

Why Illustrator is the slow one

Adobe hasn’t given a public technical reason. Reasonable inference from the public timeline:

• Illustrator’s C++ codebase is one of the oldest in Adobe’s portfolio — it predates UXP’s architectural assumptions about how host applications expose their APIs. Refactoring the API surface to match UXP’s expectations is non-trivial.
• The Illustrator team has been re-platforming for the iPad, which has consumed engineering capacity that might otherwise go to UXP rollout.
• The CEP/ExtendScript ecosystem in Illustrator is large and active (most professional cartography, packaging, and fashion-design panels run on CEP). There’s less commercial pressure to break that ecosystem until the UXP equivalent is at parity.

None of those are official statements. They’re the kind of things developers infer from where Adobe’s engineering effort visibly goes.

The prerelease programme

Adobe runs a prerelease programme for developers who want early access to forthcoming Illustrator features, including UXP. To join:

1. Apply via Adobe’s prerelease portal (the application is free but selective).
2. Sign a non-disclosure agreement covering anything you see, including UXP API surfaces.
3. Once accepted, you get access to prerelease builds of Illustrator, the prerelease UXP API, and a private forum for prerelease developers.

The catch — and it’s a real one — is that the NDA prevents you from publishing anything you build with the prerelease UXP, including documentation, tutorials, blog posts, or open-source code. You can prototype privately. You can’t ship. For that reason, prerelease UXP is the right path for product teams that want to be ready on day one of public release, but it’s not a path for general client work.

What to build with today

For Illustrator extension work in 2026, the choice is between three established frameworks:

ExtendScript — for automation and batch

If you’re writing a tool that runs once when a user invokes it, ExtendScript is almost always right. It’s an old language, but the API it exposes covers nearly the entire Illustrator object model, the deployment is drag-and-drop, and scripts written ten years ago still run. Our Illustrator automation guide and batch processing guide cover the patterns. Don’t avoid ExtendScript because it’s old — the production reality is that most working Illustrator automation is ExtendScript, and that won’t change when UXP arrives.

CEP — for persistent panels

If users need a panel that stays visible while they work — a settings interface, a search-and-replace tool, a database-backed asset browser — CEP is the only public option for Illustrator. The framework is mature; ZXP packaging and Marketplace distribution work; debugging via Chrome DevTools is well-documented. We cover the framework end-to-end in Illustrator CEP extensions.

The reasonable concern with starting a new CEP project in 2026 is that you’re investing in a framework Adobe is migrating away from. The mitigation is that Adobe has not deprecated CEP for Illustrator — and historically, when UXP launched for Photoshop, CEP continued to load for several years afterwards. A CEP panel built today should still work on the day public UXP for Illustrator ships, and probably for several years after that.

C++ SDK — for the hard cases

For performance-critical operations (large-batch geometric processing), custom file formats, native tools that appear in the Illustrator toolbox, or anything that hooks the Illustrator notifier system, the C++ SDK is still the only option. UXP, when it ships, is unlikely to replace the SDK — the two address different problems. The cost of the SDK is the per-Illustrator-version compile and a more demanding development environment, but for the cases that need it there’s no substitute.

Migration planning — sensible, not premature

If you’re building a new CEP panel, structure it so the eventual UXP migration is as cheap as possible:

• Keep ExtendScript thin. The CEP panel’s ExtendScript layer should be the smallest possible — just the calls that need direct Illustrator API access. All UI logic, state, async work, and business rules should live in the panel’s JavaScript. When UXP arrives, the ExtendScript layer goes away; the JavaScript layer ports almost as-is.
• Avoid CEP-specific Node.js APIs where you can. CEP gives you Node.js inside the panel. UXP doesn’t. Where you can use browser-standard APIs (fetch instead of require('https')) you save migration effort.
• Use a UI component library that ships for both. Spectrum Web Components are available outside UXP too. Building your CEP panel against Spectrum now means the visual design carries over.
• Don’t over-invest in CEP-only features. Things like the CSInterface vfs cache, deeply nested CEFCommandLine flags, and CEP-specific debugging tooling won’t survive the migration. If you can avoid them, do.

None of this is reason to delay shipping. It’s reason to architect with one eye on what the next platform is going to ask for.

How to track when this changes

Three reliable signals worth watching:

• Adobe Tech Blog on Medium — where Adobe announces extensibility milestones, including UXP rollout to new applications.
• Creative Cloud Developer Forums — the prerelease programme has occasionally signalled openings here. Community sentiment also shifts visibly when Adobe is preparing a public release.
• UXP Developer Tool changelog — lists which applications and versions UXP supports. When Illustrator appears in the supported-applications list, public availability is imminent.

The honest take

The right posture on UXP for Illustrator is patient. Build today with the tools that ship today — ExtendScript, CEP, the C++ SDK — and architect the new work cleanly enough that the eventual port isn’t painful. Don’t delay client projects waiting for an unannounced platform. Don’t rebuild working CEP panels speculatively. And don’t treat the prerelease programme as a substitute for public availability — the NDA makes it useful for product strategy and useless for client deliverables.

When public UXP for Illustrator does arrive, it will be a good thing — faster panels, modern tooling, a better developer experience. Until then, the existing stack works, and the work that needs to be done can still be done.