WinDynamicDesktop ships the Mojave wallpaper cycle through four channels

Four channels, and the Store build carries its own bug list

The app reaches you four ways:

https://github.com/t1m0thyj/WinDynamicDesktop/releases
https://apps.microsoft.com/detail/9NM8N7DQ3Z5F
https://chocolatey.org/packages/windynamicdesktop
https://github.com/microsoft/winget-pkgs

That is GitHub releases, the Microsoft Store listing 9NM8N7DQ3Z5F, a Chocolatey package, and an entry in the microsoft/winget-pkgs repository. The channel matters because the known issues name the Store app specifically: one bullet is wallpaper fit not remembered in the Microsoft Store app, and the wiki anchor behind it describes the fit setting not being saved with multiple monitors. So the same feature behaves differently depending on where it was installed, and the release build is the one the issue list does not single out. Two smaller differences ride along. Location handling differs by channel, since the Store app uses the Windows location API when permission is granted. And updates arrive on each channel's own schedule, so a winget or Chocolatey user can sit on an older build than someone who installed the release asset.

One schedule over 24 hours, and nothing per virtual desktop

The scheduling model is deliberately narrow: you choose a schedule for cycling through wallpaper images over 24 hours, and the app follows it. There is no per desktop configuration, and the limitation section says so directly, with separate images on multiple virtual desktops tracked as issue 299. That is the single most important expectation to set before installing, because separate wallpapers per virtual desktop is a standard request on Windows and the answer here is no. The second known issue is a wallpaper that gets stuck and will not update. Neither problem is described as fixed in a particular release, so both are worth checking against your own setup rather than assuming a recent build clears them. The CHANGELOG.md at the top level is where a fix would show up.

The wallpaper images belong to Apple, not to the project

The disclaimers section is short and worth reading in full, because it separates what the license covers from what the app displays. Wallpaper images are not owned by the author, they belong to Apple, and the bundled themes are macOS themes. The project license is MPL-2.0, which covers the code in src/ and uwp/, not the artwork the app cycles through. If you are evaluating this for an organisation, that distinction is the one to settle first, since a bundled set of Apple images and a redistribution story are different questions from a code license. The icon is a separate case again: it was made by Roundicons from flaticon.com and is licensed under CC 3.0 BY, so the icon carries its own attribution requirement. Read the four channel links above and the disclaimers together, because the images travel with the app on every channel.

Location runs through LocationIQ, and the keys sit in .env.example

Typing a location into the app sends it to the LocationIQ API to convert it to latitude and longitude, and the Microsoft Store build instead uses the Windows location API when permission is granted. The credentials for the first path are not in a settings dialog. The committed .env.example is two lines:

LOCATIONIQ_API_KEY=
POEDITOR_API_TOKEN=

So a build made from source reads a LocationIQ key from an environment file, and the translation pipeline reads a POEDITOR_API_TOKEN from the same place. Two consequences. If you self build, the geocoding path for typed locations depends on supplying that key, while a Store install can lean on the Windows location API instead, which means the two builds do not fail in the same way when location is unavailable. And because translations are managed through POEditor rather than in the repository, a fork inherits a dependency on an external service, and the token in the example file is the only hint about how that sync is wired.

Themes arrive bundled, hosted, or hand made

There are three sources of themes and they are not equally supported. The app ships bundled macOS themes. Hundreds more are browsable online at windd.info/themes/. And you can create your own, with the wiki page on creating custom themes as the guide. A separate community tool exists for the third route: a .ddw theme creator hosted at ddw-theme-creator.vercel.app, credited in the resources section to another contributor, gdstewart. It sits outside this repository, so the format it writes is effectively the interchange point between tools: whatever the creator produces has to be something the app reads. That is also the practical test for anyone authoring themes, since the app and the creator can disagree about the file layout without either project noticing. The help entry point is the project wiki, and translations are handled through POEditor rather than by editing files here.

Extension happens in PowerShell, and user scripts live in another repo

Behaviour is extended with PowerShell scripts, and those scripts are shared with other users in a separate repository, WDD-scripts, rather than in this one. The top level here has its own scripts/ directory next to src/, test/ and uwp/, so two different things answer to the word scripts: the scripts that belong to the application, and the user written scripts that extend it. Keep them apart in your head before you go looking for the extension mechanism in the source tree, because the source tree holds the C# application, the unit tests, and the UWP project behind the Store build, with WinDynamicDesktop.sln at the top. A build workflow lives under .github/ as build.yml. The practical upshot is that custom behaviour is a PowerShell file you obtain and run, which makes experimentation cheap and makes review of someone else's script your own responsibility.

Windows 11 first, Windows 7 as a floor, Insider builds excluded

Support is stated as primarily Windows 11, with the expectation that it runs on any device with Windows 7 or newer, and Windows Insider builds called out as not officially supported. That middle position is the practical one: the floor is old enough to cover a decade of machines, and the Insider exclusion is where breakage would arrive first on a machine you cannot pin. Version numbering tells the rest. The newest stable is 5.7.0, dated 2026-06-16, preceded by a 5.7.0 beta dated 2025-11-18 and 5.6.1 dated 2025-03-10, so the stable line has moved slowly while previews move on their own schedule. The last push to the repository is 2026-10-28 and nothing is archived, so commits continue after the last release. Check CHANGELOG.md and the known issues wiki before upgrading an existing install, since the release you move to may not contain the fix you are after.

Editorial conclusion

Use it if you want the Mojave wallpaper cycle on Windows and are content with a feature set the author explicitly bounds: one schedule, no per virtual desktop images, and no Insider support. Pick the GitHub release over the Store build if the wallpaper fit setting matters to you. Before installing, read the known issues page, decide whether bundling Apple owned wallpapers fits your situation, and expect a self build to need keys in .env.example.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. t1m0thyj/WinDynamicDesktop on GitHub