- The models today are great at making Windows tray utilities
- With the right API the process is very straightforward
- There are many opportunities for better Taskbar APIs
Let’s take these one at a time.
The tools and models are good for WinDev now.
Building the kind of apps I built for Tray-tober with the Claude Pro $20/mo plan was more than enough. To improve my chances of having a solid app on the first build, I did build and refine a skill called winui-tray-app and invoked it for every app. The skill did more than just make it easy to build apps, it also made it easy to manage, package, and release so many apps. The main tool used by the skill was the WinAppCLI making it possible, and easy, to parallelize work on multiple apps each in their own Terminal tab.
A non-programmer could easily use a tool like Claude, Codex, or GitHub Copilot to build these tray apps, assuming they have a goal in mind. Big companies like Apple are already opening this door in the form of Safari extensions built from users’ plain text description. During Tray-tober I learned about omarchy plugins. Both of these highlight there is user demand for more precisely tailoring their operating systems and browsers to work for them.
The right API makes all the difference.
One of the reasons building tray utilities is not just possible, but ideal, is because the tool is small. A major challenge of AI coding is the models do too much, write confusing code, and developer understanding goes down. This is not as much of a challenge for a tray app due to its small scope. The challenge of describing the change you want to see becomes increasingly tedious and challenging with larger and more complex software; keeping things small and simple dividends.
Many times a good API encodes domain knowledge into the its design. Most of these project were as simple as invoking the skill, pasting in a link to the API documentation, and giving a relevant example app if I had made one that fit. As the LLM model crawled through documentation it was also learning about the problem space. This is true for a web API or a nuget package.
A few of my apps were basically demos of what the nuget package could do within a tray app. Bogus, NCalc, and UnitsNet each had their own tray app and defined what could be done, but also what should be done. Many times people ogle at what LLMs are able to do, but frequently the impressive features are done by open source packages and the LLMs wired them together in clever ways.
Ironically the games ended up requiring much more detailed instruction around how the app should behave. Perhaps because once the basic game rules were codified there were so many assumptions around UI and interaction patterns that really make a game feel fun to play that the LLM had to make too many assumptions. Good data and API structure really leads the coding agents well to building the needed screens, and interaction methods. Also it doesn’t hurt that WinUI is better suited for forms and data heavy controls rather than for building games.
Windows Devs need more modern Taskbar APIs.
While each app lives in the tray, the extent they take advantage of different Windows Taskbar and shell API ranges widely. An app like Tray Converter or Tray Folder just use the notify icon as a launch point. While apps like Tray clock and Set Sett generate many different icons. Several apps generate .ico files and swap out the file used on the notify icon to create animations.
While it is impressive what can be done with an API surface from WinForms there leaves a lot to be desired. All UI in the tray has to be rendered as an image in the app and swapped out. Not as WinUI code which means animations have to be faked, icons generated at different sizes, and all within a tiny square.
Seeing what other platforms like MacOS and iOS do with the Dynamic Island really makes me wishing we had an equivalent on Windows. Not just for robust animations and more declarative UI, but for the OS to dynamically show and hide the icon when it is relevant. Today the icon is either in the tray visible to the user, or not. No way to move to and from the overflow on demand or change in size.
It is easy to understand how bad actors abusing the system become the instant scape goat for why these APIs don’t exist, but there need to be more robust signals combined with user preference to find the right balance. While other companies are introducing new UX patterns Windows continues to hold tightly to the past in a way that I believe makes the OS seem out of date, but it doesn’t have to be that way.
I did the Tray-tober project and built these apps because I personally wanted these apps to use them in my daily life. I have Wiz lightbulbs which are a more modern way to light a house, and when I can only control them with my phone… my more than capable PC feels like it is slipping behind. AI/LLM coding has reignited native development and I hope that means more awesome native Windows apps. It seems like the core Windows UI team has been awaken from their slumber, and hopefully they are able to meet the moment and make building all types of apps for Windows a good and modern experience.
Joe