Mac Admin

Deploy Adobe Applications to Apple Silicon Devices

Adobe have made some efforts towards deploying and using their suite of software on Apple’s new silicon (currently M1) devices, announced in November 2020. This post is intended to share the work required to achieve this and hopefully help some folks out!

Before I begin, full-disclosure: I’ve not had the chance to test any of this on an Apple Silicon device myself, and the information shared is from Adobe’s official sources and work from members of the MacAdmin community (#adobe).

The Current Situation – General Usage

Most Adobe Suite applications will run on Apple Silicon devices but through the use of Rosetta 2. The exception to this is Lightroom 4.1 which is Adobe’s first native Apple Silicon application. Details of compatible applications can be found here. For reference these are currently listed as:

  • Acrobat Pro (with known issues detailed here)
  • After Effects
  • Animate
  • Adobe Audition
  • Adobe Bridge (with known issues detailed here)
  • Character Animator
  • Dreamweaver
  • Illustrator
  • InCopy
  • InDesign
  • Lightroom Classic (with known issues detailed here)
  • Adobe Media Encoder  
  • Photoshop (with known issues detailed here. There is also a beta with native Apple Silicon compatibility available here)
  • Premiere Pro
  • Premiere Rush
  • Adobe XD (with known issues detailed here)

It is not specified which versions of these applications are compatible but I’d assume it’ll be the latest version (2021 for the vast majority, with 2020 for those yet to have a 2021 version).

Users can download these installers from the usual end-user download page at creativecloud.adobe.com/apps

The Current Situation – Mass Deployment

As it currently stands, the installation packages you’ve created for Adobe deployments on macOS will not work on Apple Silicon devices. This includes those created from the Adobe Admin Console, with additional applications or those with the Creative Cloud Desktop App (CCDA) only.

So I can’t deploy Adobe Apps…again?

Well, yes and no. It is possible to actually edit your current installers to work with Apple Silicon (they’ll still require and run through the Apple Rosetta 2 translation environment). The good news is these new packages will work on both Intel and Apple Silicon devices automatically, so you’ll likely not need to keep duplicates of the packages. The bad news is the packages will install one of two different versions of CCDA depending on the architecture you’re deploying to.

Graham Pugh covered this in some detail within his blog post here, but the super-short TL;DR is: Currently Intel Macs will have CCDA version 5.3.2.471, where-as Apple Silicon devices will get version 5.3.5.518. Both of these are correct and current for each architecture, and both come from your same identical package!

Adobe have documented the process to convert your current / new Adobe packages to be “compatible” with Apple Silicon deployments here (remember, this is still via Rosetta 2). As per my comments above (The Current Situation – General Usage) this will only work for applications that are supported on Rosetta 2. The process requires you to open up your current package, delete and insert a hot fix, clear out any quarantine bits from the package and re-upload to your deployment system of choice.

Certainly better than nothing, but still not ideal.

Oh and one MacAdmin has knocked up a script that can semi-automate the package manipulation process with a copy on the MacAdmins Slack here. Obviously test fully with your own specific use-case and environment!

Progress is coming

Adobe are working on bringing full support (as you can imagine!) as fast as possible. No I don’t have insider information, but the following is observable:

  • The Adobe re-packaging KB (Deploy packages to Apple Silicon devices) specifically mentions “Temporary workaround to deploy Named User or Shared Device Licensing packages to Apple desktop devices that use the M1 chip.” (emphasis is mine).
  • The Adobe M1 compatibility KB (Do Adobe apps work on Apple computers that use the M1 chip?) mentions that Photoshop is planned for a 2021 release (“We plan to release a native version of Photoshop in 2021“) and they’re working on the other applications but don’t have release dates yet

Additionally, Ryan Ball made a nice discovery on Thursday that they shared with the community – Adobe has an updated KB with a link to an arm64 (the architecture reported for Apple’s Silicon devices) installation of CCDA – Download the Creative Cloud desktop app. The links can be found under the “macOS | Alternative downloads” section.

As mentioned up top, I haven’t had the chance to test these for myself, but the fact that Adobe has provided a (what appears to be) native installation mechanism for CCDA on Apple Silicon is a good sign that progress is being made. No I’m sorry to say it’s not a native Apple package installer 😉 And yes, its separated out and not a universal app or installer, which leads my onto my wish list…

Wish in one hand…

I’ve knocked up a few wish list items below, directly related to Adobe and Apple Silicon. These are aimed at the deployment side directly related to my needs!

First of all: Automate the package modifications you’ve outlined above and integrate into your package build systems. You have the full details, and all the files. You now also have an example script to do the work! This would be a quick-win and help out Admins perform less work to deploy your products.

Secondly: Please work towards universal builds (and universal packages) of your applications, not split builds for Intel and Apple Silicon devices as it looks like with the CCDA above (Progress is coming). The reasons for this are two fold:

  • If we have to deploy different versions of your applications dependant on device architecture, we immediately need to double up on storage space for packages. Depending on the applications we as admins need, this could mean a requirement for an additional 20-40GB of space for distribution. It’ll also double up on the effort to run the already manual process to create and download packages, and repeated again each time there are patches or updates released.
  • If we have to deploy different versions of your applications dependant on device architecture, we will need to add extra complexity to our deployment solutions. I’d argue that adding complexity to anything increases the risk of issues, mistakes and hitting unexpected conditions. In some cases this might even affect the user experience negatively.

Now I’m well aware of the phrase “wish in one hand, do…something else in the other and see which one fills up first” and so I’ll be logging the above with Adobe at their Feature Request pages (here) after this post goes live. If you’re also affected I’d strongly request and suggest that you follow suit and maybe we can improve things further!

Outro

And that’s another Adobe post done 😉 I felt it was something that was worth sharing and digging into, and I hope that it’ll help out some of you folks out there.

As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

Standard

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s