Feature Request: support for base64 encoded icons #100

New Issue

michael · 2026-01-19T18:31:32Z

michael commented

2026-01-19 18:31:32 +00:00

Originally created by @ecanault on GitHub.

Hi,

It could be helpful to add a new Icon Source defined as a base64 string inside the configuration profile.

This (long) string will be the encoded form of the icon: this will permit for example to avoid the maintenance and the deployment of icons inside packages.

Thanks,
Emmanuel Canault

Originally created by @ecanault on GitHub. Hi, It could be helpful to add a new Icon Source defined as a base64 string inside the configuration profile. This (long) string will be the encoded form of the icon: this will permit for example to avoid the maintenance and the deployment of icons inside packages. Thanks, Emmanuel Canault

michael added the enhancement wontfix labels 2026-01-19 18:31:32 +00:00

michael commented

2026-01-19 18:31:32 +00:00

@colorenz commented on GitHub:

Hi, you only need a storage location to upload the image. You can simply use your Jamf as a free image hoster.

You can upload them to your jamfcloud under the Branding TAB. If you upload a new image, jamf will not delete the old one. Just put your image there and use the IDs to find your images.
https://name.jamfcloud.com/api/v1/branding-images/download/id

@colorenz commented on GitHub: Hi, you only need a storage location to upload the image. You can simply use your Jamf as a free image hoster. You can upload them to your jamfcloud under the Branding TAB. If you upload a new image, jamf will not delete the old one. Just put your image there and use the IDs to find your images. https://name.jamfcloud.com/api/v1/branding-images/download/id

michael commented

2026-01-19 18:31:32 +00:00

@scriptingosx commented on GitHub:

There are two reasons I am reluctant to implement this:

creating profiles with base64 data is not trivial
in my experience, the more data a profile contains, the less reliable its deployment will be

Image data could easily balloon a profile to several Mbytes in size. Even if this doesn't affect the reliability of the deployment, it is not unlikely that it will affect the speed at which the profile downloads and might possibly lead to Setup Manager launching when the profile is not present yet, leading to a failed run.

@scriptingosx commented on GitHub: There are two reasons I am reluctant to implement this: - creating profiles with base64 data is not trivial - in my experience, the more data a profile contains, the less reliable its deployment will be Image data could easily balloon a profile to several Mbytes in size. Even if this doesn't affect the reliability of the deployment, it is not unlikely that it will affect the speed at which the profile downloads and might possibly lead to Setup Manager launching when the profile is not present yet, leading to a failed run.

michael commented

2026-01-19 18:31:32 +00:00

@ecanault commented on GitHub:

Well perhaps we don't have the same experiences 😉

I think that Mac admins using Setup Manager are smart enough to not put 1 Gb of data in a configuration profile during PreStage enrollment! Adding this feature is just another option for managing icons; it's not mandatory to put base64 encoded icons: all other options (URL, local app icons, symbols) are wonderful and permit to address 99% of use cases.

At this time if we want a very specific design for an action we have to add an extra package during PreStage:

It's not reliable anymore now that we don't really know in which order packages are installed during enrollment.
It's, in my opinion, out of the philisophy of the product to be able to rely on only a generic package (Setup Manager) and an easy-to-maintain-and-deploy configuration profile.

For a reasonable usage, it should have been great.
Too bad, but that said, it's up to you of course!

Regards,
Emmanuel

@ecanault commented on GitHub: Well perhaps we don't have the same experiences 😉 I think that Mac admins using Setup Manager are smart enough to not put 1 Gb of data in a configuration profile during PreStage enrollment! Adding this feature is just another option for managing icons; it's not mandatory to put base64 encoded icons: all other options (URL, local app icons, symbols) are wonderful and permit to address 99% of use cases. At this time if we want a very specific design for an action we have to add an extra package during PreStage: 1. It's not reliable anymore now that we don't really know in which order packages are installed during enrollment. 2. It's, in my opinion, out of the philisophy of the product to be able to rely on only a generic package (Setup Manager) and an easy-to-maintain-and-deploy configuration profile. For a reasonable usage, it should have been great. Too bad, but that said, it's up to you of course! Regards, Emmanuel

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jamf/Setup-Manager#100