Support universal macOS installer that works on both Intel and Apple Silicon Macs
I would like to share my frustration with recent changes in the Adobe Admin Console for generating packages. Adobe added the option to generate installers for specific platforms:
macOS (Apple Silicon)
This change has resulted in more work as an IT administrator deploy Adobe apps. Prior to this change, the installers generated from the Adobe admin console were not compatible at all with macOS on Apple Silicon. We had to use the steps in this article to create a package for Macs on Apple Silicon: https://helpx.adobe.com/enterprise/kb/deploy-packages-to-arm-devices.html
The resulting package from those steps worked on both Intel and Apple Silicon platforms. This means we only needed to deploy one installer to Macs. The changes you've recently made have now resulted in having to maintain 2 packages. Given that you had a workaround that worked for generating a single installer that worked on both Intel and Apple Silicon, it is disappointing that this behavior has changed.
Given the approach that's been taken here, I would like to ask that Adobe generate universal installers that work on both Intel and Apple Silicon. It already looks like the AdobeDeploymentManager tool in the Adobe installer is already a universal binary so it's perplexing that a decision was deliberately made to create installers that only work on specific platforms.
When native apps for Apple Silicon are delivered later this year, I would also like to request that Adobe also make sure to have universal versions of those apps (that run on either Intel and Apple Silicon) to avoid the same problem in the future. Apple has already made it simple for developers to build universal versions of apps (and clearly Adobe is taking advantage of this in some circumstances). This would make it easier for Adobe to maintain only one version of the Adobe apps (instead of having to produce separate native versions for Intel and Apple Silicon). You can consider also building native versions of the Adobe apps as well if you'd like but the majority of IT administrators would much rather have to deal with universal apps.
The transition to Apple Silicon is going to take years and the approach that Adobe has taken here means that it is going to make deploying Adobe apps take up twice as much space, twice as much time to test. It's going to just add a considerable amount of work to maintain installers for each app.
Hopefully, you can take this feedback and provide universal installers as soon as possible.
Tim Mann commented
Adobe as everyone on this post has already stated this is making unnecessary work for It admins.
You need to follow some of the other groups that made universal2 apps.
Apps downloaded from the admin console should just download. Why are we bothering to create installers that need to be run to get the actual packge?
I really would appreciate the installers being universal as well. Using non universal packages results in many problems concerning deployment. Please change to Universal2!
It's hard to overstate how much more complexity is added by having to track Intel and Apple Silicon during deployments. On top of that, many users don't even know which they are running, so it makes the entire user experience better if the installer handles the architecture requirements like it does when the app is Universal2.
Greg Neagle commented
Add another vote for providing Universal2 apps, or failing that, a Universal2 installer that installs the correct architecture-specific version. Managing Adobe installers is already difficult and tedious; having to do the work _twice_ for each title not only doubles the tedium, it greatly increases the chances for mistakes and inconsistency.
Rick H commented
The split in architectures has ballooned our disk space requirements for management and increases complexity of deployment - using universal packages with universal binary versions of the applications would keep things simple as we move into the future, and reduce the chance of mistakes as we try to deploy apps seamlessly to our users.
Neil Martin commented
I add my support to this - in its current state:
* Bundle packages that you have to artisinally generate, download and import into your management tools, (and they wrap proprietary installers which can be unreliable and difficult to troubleshoot) .
* Duplicatates of the above for different CPU architectures.
This is pretty untenable to administer and support in enterprise/educational IT environments without an unreasonable amount of time, effort and overhead. Just yesterday we saw updates for no less than 11 titles. So that's 22 lots of manually generating packages, downloading, unzipping, and ingesting into management tools - likely to be at least half a day's work.
Please help us by providing Universal installers and flat packages that are available as static download links (Microsoft do this with Office for Mac and I'm aware that an employee from them has reached out to Adobe to offer advice/guidance etc on this).
That way we can automate our download/ingest workflows and not have to host/deploy double the amount of software.
On my opinion the priority would be:
1) Provide native Universal2 applications (no separate apps for specific cpu-types on macOS)
2) Provide native Universal2 compatible standard flat-file Apple packages.
When realized these would make deploying Adobe CC apps so much easier on Mac platform.
Jacob B commented
Adobe is by and large the hardest deployment on our platform, largely due to the non-standard packing practices Adobe uses. Please provide Universal apps for the macOS platform, so that enterprise users can make sure the experience of actually using Adobe is smoother for our end users.
Please give us deployable standard packages - independent of CPU type and license like other software vandors do it.
Why do you make life so complicated for yourself, administrators and users?
Why are Adobe developers seemingly so out of touch with administrators and even the higher ed market as well? Separate installers more than doubles the workload. Our campus still grumbles about the price paid to Adobe and questions its value. If Adobe continues down this path of making it more costly to support, it's a matter of time before serious conversations start happening.
My thoughts on this are that it's time consuming and space consuming to have multiple Mac installer versions by hardware type. In general, I prefer universal versions of apps, but if that is not the direction you folks want to take and given that Adobe installers in general are heavily scripted and dependent on post install scripting, why can't you simply add a line that detects the given hardware type and load the right stuff on it? Better than having two ugly installer packages taking up space in our package repo.
Mike Bainter commented
Updating or even installing Adobe products are one of the most resource intensive tasks admins undergo. Any assistance devs can give would be so appreciated. Since named-user licensing was instituted workloads have skyrocketed.
Patrick van Nerum commented
I agree with all the posts here and can only acknowledge the amount of hours to deploy Adobe apps in the enterprise are insane compared to every other software vendor. All the people who posted these comments here support big environments with so much users!
If you want to know what I really want, please read the comment from Kevin M. Cox!
Steve Yuroff commented
Adobe- you're hearing from active folks in the Mac Admin community here- folks who are tasked with deploying and maintaining your software for the benefit of others and their workplaces to do great things. They're experienced, wise folks- please listen to them.
Kevin M. Cox commented
Sharing a comment I made in the #adobe channel on the MacAdmins Slack:
Here is my dream for Adobe deployment:
Abode should build and publish generic packages (true Apple packages) for all adobe apps and keep them updated. See Microsoft Office as the great example here: https://macadmins.software
This would allow us admins to automate the download and import into our management systems with #autopkg and greatly reduce the amount of time we spend dealing with Adobe updates.
Allow us to manage the settings (Disable self-service install, enable file syncing, enable RUM, etc.) of the Creative Cloud Desktop App with a configuration profile. This way we can download a generic package of the CCDA and configure the options we want with a mobileconfig pushed from our MDM.
Adobe also needs to release all apps as Universal as quickly as possible so we don't have to deal with multiple version for different architectures.
Shane Palmer commented
Summarizing a comment that I made on the #adobe MacAdmins Slack channel here:
I have tested creating Intel and Apple Silicon packages for Adobe Acrobat DC (which is an Intel application) and Adobe Lightroom CC (which is a Universal application).
It appears that the selection, in the Adobe Admin Console, of Intel vs. Apple Silicon is NOT about whether the application itself is native to Intel or Apple Silicon (or Universal), its about whether or not the installer packages themselves will run on Intel or Apple Silicon.
So not only do we have to double the number of packages that we need to build (which will amount to 30+ packages for those of us that build a package per application), but this is going to be super confusing trying to explain this to our 75+ Mac admins, that they might need to use the Apple Silicon version of the installer to install an Intel application on an Apple Silicon Mac and they might need to use the Intel version of the installer to install a Universal application on an Intel Mac.
The effort from Adobe over the last several months, since the Apple Silicon Macs were released, should have been spent making Adobe’s installers Universal. Now we IT admins have waited for many months in hopes of something that will make our lives at least a little easier when it comes to deploying Adobe applications to Apple Silicon Macs, but in true Adobe fashion we have gotten something that makes our lives MUCH MUCH harder (just like downloading the downloader to download the installer).
Graham R Pugh commented
I 100% agree with this. It is already far more labour intensive to deploy Adobe packages than almost any other vendors' products due to the crazy method we have to use via the Admin Console. Adobe showed us a method in development that would allow all this to happen via API over a year ago, but there's till no sign of this going into production. And, now, we have to manually generate duplicate packages for each product depending on which architecture our Macs have? Ugh.
We don't have any of these problems with Affinity apps. Please take a look at their model.
Stephen Boyle commented
very well said - i agree 100%
Anthony Reimer commented
As someone who manages shared Mac computers (academic computer lab), this is yet another irritant that makes it harder for us to support Adobe products and makes us consider alternatives more and more. It has been difficult enough to train users to login to an Adobe account in order to just use a single Adobe app (since our federation method requires 2FA authentication even if the user hadn't previously set up 2FA). With this change, I now have to setup two separate workflows (Apple Silicon and Intel) in my management system in order to deploy Adobe products in addition to making twice the number of (space-consuming) installer packages.
Universal installers are table stakes on the Mac platform. Anything else is user- and admin-hostile.
Vaughn Miller commented
Managing Adobe packages is already more work than other software vendors. This makes a bad situation worse.