A few years back, I built and released a small tool to simplify the deployment of macOS desktop pictures (also known as “wallpapers” since macOS Ventura and on other platforms) without actually locking them down or needing privacy (PPPC) exemptions. The tool is desktoppr and is quite popular among Mac admins.
I haven’t updated desktoppr in the last three years, and even that last update was just a re-compile to make the binary universal. It was always meant to do one thing and it has done that well, so there was no need for updates.
Recently however, I have been thinking about the workflows to install and set a custom desktop picture or wallpaper in a managed environment.
Note: my thoughts here are for Macs that are owned and managed by organizations and given out to employees to work with. They do not really apply to shared devices in classrooms, carts, labs or kiosk style deployments or even 1:1 devices in an education setting. Other rules (figurative, literal, and legal) apply in these scenarios and you probably want to set and lock a desktop picture/wallpaper with a configuration profile.
Why do it at all?
This is a fair question. My general recommendation for Mac Admins regarding pre-configuring, or even locking down settings in user space is to only do it when you absolutely need to for compliance and security reasons.
I often get the argument that it makes the lives of Mac Admins and tech support easier when you pre-configure settings that “everyone wants anyway.” However, I believe, from my own experience, that “tech geeks” (and I include myself here) are poor judges for which settings should be a general preset and which are just our geeky personal habits and preferences.
This holds especially true when macOS updates change default settings. There have been examples for this throughout macOS history, such as the “natural scrolling” on trackpads, whether to use dark mode, or more recently, the “click to desktop” behavior in macOS Sonoma.
You may be able to generate the statistics from your support ticketing system that tells you which pre-configuration would cut down a significant number of incidents and then, by all means, apply those. (I’d be very interested in those stats and which settings those are.)
But generally, a more hands-off approach is less intrusive, and also less effort in management and maintenance.
So, why configure the wallpaper?
Given my lecture above, this is a fair question. The desktop picture/wallpaper is special. It gives you a chance for a great first impression.
The desktop picture/wallpaper is the first thing a user sees when they log in to a new Mac. Apple understands this, and creates new, beautiful images for each major release of macOS to emphasize its branding. Likewise, when you are managing Macs, this is a very compelling opportunity to present your organization’s branding. This will also demonstrate to end users that this Mac is different. This will identify this Mac as a managed Mac from your organization.
Of course, many users will go ahead and change the desktop picture/wallpaper immediately, or eventually. And so they should. The ability to configure and setup the device the way they like it will make it “theirs,” i.e. more personal, and also might encourage some to learn a bit more about macOS and the device they are working with. Limiting a power user in how they can configure “their” device and how they work with it will be a cause for much frustration, friction and complaints. This is why desktoppr exists: to set the desktop picture/wallpaper once, but then allow the user to change it later.
But first impressions are important. There are very few ways Apple lets Mac admins customize the first use experience. The desktop picture/wallpaper is fairly simple to manage and can leave a big impression.
Ok, but how?
That said, there a few considerations to get this first impression just right. In general, to set a customized wallpaper you need to:
- install the image file(s)
- install desktoppr
- run desktoppr to set the wallpaper
The challenge is to get the timing right on these steps. In this case the first two steps can (and should) happen right after enrollment. The third step configures user space, so it cannot happen before the user account is created and the user logs in. If you run it too late, the user will see the default macOS wallpaper for a while and then switch to the new one, which is not really ideal to create a good first impression.
In Jamf Pro (the management system I have most experience with) you can put the packages for the image file and desktoppr in the PreStage or enroll them with policies triggered at enrollmentComplete. Since these pkgs usually are not very large, the image files and the desktoppr binary are ready to go when the user finishes setting up their account and gets to the desktop for the first time.
Jamf Pro provides an option to run policies at login, but that also has few seconds delay before it actually runs, giving the user a “flash” of the default macOS wallpaper.
The good news is, that when you run desktoppr with a LaunchAgent, it runs early enough in the login process, that the user does not get “flashed” by Apple’s default wallpaper.
That extended our workflow to:
- install the image file(s)
- install desktoppr
- install LaunchAgent plist
- desktoppr runs as LaunchAgent at login to set the wallpaper
The LaunchAgent will run on every login, and reset the wallpaper even if the user changed a different one. This might be desirable for some deployments, but in general this goes against the notion to leave the user in control. There are workarounds to this. You can build a script that sets the wallpaper and creates a flag file somewhere in the user’s home directory. On subsequent runs, the script would check for that flag file and skip re-setting the wallpaper.
Also, since macOS Ventura, the system warns users about background items in the system. We can manage these warnings with a configuration profile. Since the desktoppr binary is signed, this works quite well. But if you insert a custom shell script as the LaunchAgent to perform all this extra logic, you need to sign this script and managing the background item profile gets a lot more messy.
This works, but now our workflow is:
- install the image file(s)
- install desktoppr
- install LaunchAgent plist
- install signed custom script
- configure and deploy managed Background Item profile
- script runs at login and sets the wallpaper, when necessary
If any of the pieces in step 1–5 change, you need to update at least one installation pkg, upload them to your management system and deploy them down to the clients. Neither of these are very complicated, but the number of moving pieces will make this very tedious quickly.
These workflow steps will not vary much from one deployment to another. So I thought it would be nice if I could integrate some of these steps in desktoppr and find some means to make the pieces less volatile.
Manage the arguments
The first moving piece I wanted to fix was the LaunchAgent plist file. This needs to contain the path to the image file as the first argument to the desktoppr binary, which will be different for every deployment. This value might even change over time for a single given deployment as the org wants to updated and “fresh” desktop pictures/wallpapers with new branding.
For a managed environment, we can also provide this information with a configuration profile. This separates the ‘data’ (the path to the image file) from the logic (the other information in the launchd plist file, that controls when it runs).
I added a new verb manage to desktoppr that tells it to get configuration from a preference domain or configuration profile instead of the arguments. Now, we can put desktoppr with the single argument manage in the LaunchAgent plist. This means the LaunchAgent will not have to change when you update image paths or other settings. Instead, the admin updates the configuration profile in the MDM server. The LaunchAgent plist file is still required, but it won’t need frequent updates any more. (Step 3 is now less volatile)
Setting once
The next step is some new logic in desktoppr to only set the wallpaper once. For that, desktoppr now “remembers” when it last set the wallpaper and to which file. When it is called again to set it to the same file, it does nothing, even if the user changed the desktop picture/wallpaper. Some deployments might still want to reset the wallpaper every time the LaunchAgent triggers, so I added a key to the configuration profile to enable or disable this behavior. This flag only takes effect when desktoppr manage is run, other invocations of desktoppr will set the desktop picture/wallpaper regardless.
This removes the requirement for a custom script that determines whether desktoppr should set the wallpaper or not. (Step 4) Since we are now running desktoppr manage directly from the LaunchAgent, and the desktoppr binary is signed, it is easy to create the PPPC profile to designate this as a managed background item. (Step 5 is less volatile)
There is a sample configuration profile in the repo which has the settings payload and the payload for the background item pre-approval.
Fetch image files
The last volatile bit is the image file itself. So far, you have to create an installation pkg for the image file and install that before desktoppr runs.
To avoid this, I taught desktoppr to download an image file from a URL and use that. So now, you can upload a file to a web server (or AWS, or some file sync service that can provide a static URL) and use that as your desktop.
Since images can be a vector for malware, we add the option to verify the downloaded file with an sha256 hash given in the configuration profile.
Since the download can take a few seconds, this re-introduces the “flash” of the default wallpaper. I don’t really see a way to avoid this and if this really upsets you, you will have to fall back to pre-installing an image file. Nevertheless, I found the option to have desktoppr download an image file to be useful and left it in there.
The new workflow
- create and deploy a desktoppr configuration profile
- install desktoppr with a LaunchAgent plist (these shouldn’t change very often)
- desktoppr runs, downloads the image file and sets the wallpaper, when necessary
All the custom configuration is now in the configuration profile. You will only need to update the desktoppr installation pkg when the binary is an updated.
New use cases
This shortened workflow enables some new workflows. First of all, since there is logic in desktoppr to only change when necessary, we don’t really have to wait until the next login any more. (Most users only “log in” after a reboot for a software update.) We can change the LaunchAgent plist to run in the background every few hours or so. That way, new settings in the configuration profile should be picked up by all the clients within a few hours after coming online and receiving the new profile from the MDM.
Introducing desktoppr 0.5beta
I have been playing around with this and testing for a bit now. It has been working well for me, but I know there will some edge cases and workflows out there that I am not anticipating. For this reason, I am releasing the new manage feature as a beta, so you can start testing it and reporting any improvements, issues, or challenges.
I am curious to see what you are going to do with it.