We have some apps in the Microsoft Store or Mac app store, but some of them got published a long time ago, and since then no-one is updating them.
Like Okular, which is still on Gear 23.08.1 on the Microsoft Store. To me keeping so old apps officially published sounds like a bad idea, both for stability and security.
Would it make sense to require at least one “maintainer” who updates these before publishing them?
The Microsoft Store is famous for being the opposite of a Linux Repository - it’s less reliable than downloading directly from KDE’s official site.
Kate & Co. in the Microsoft Store - Kate Dated 3rd June, Kate 25.04 was pushed to the Microsoft Store already… so the delay is entirely on Microsoft.
Shame on you for thinking the problem would be on the Linux side of town and not a Microsux issue 
I don’t use Windows, but if I did, I’m sure I’d prefer it with some Chocolate:
I don’t use Windows either, but fwiw Chocolately isn’t an option for the vast majority of users we are yet to reach on Windows, and I’m not sure if finding the nightly is.
Same applies to Android. This needs someone to feel responsible for doing the manual work involved there in the long run, we indeed shouldn’t publish things just because we can.
There’s also some room for further automation to make that easier for the people doing the work, like automated testing of the packages/installers (which should now be technically possible with the recent CI transition to VMs).
Is it just testing the stable CI artifact and uploading to a web ui? But of course the best would be if a maintainer of Okular maintains it who can debug it too
In the best case, mostly yes. Don’t know how this looks on the Windows side, on Android it’s also filling in some extra information like release notes and going through two stages of review (which is just a matter of clicking some buttons and waiting a day or so).
Release notes should ideally be in the Appstream metadata already, but few apps do that yet.
There’s also the occasional random change in rules and requirements that need unpredictable amounts of work to comply (probably less common for Windows than on Android and macOS).
And yes, all that assumes the application actually works properly on that platform. For Linux/Android people using continuous/nightly builds are a massive help with ensuring that, not sure to what extend we have that for Windows/macOS.
I worry about whether this is possible for Windows.
For Android it probably is because many of us still use Android phones instead of Plasma Mobile.
But for the desktop OS, we’re all on FOSS OSs, so there likely is no one who actually cares about Windows.
That’s certainly the situation for myself, but I’m not sure it’s actually that platform-dependent. Most of the Android apps are in a similar state I think (which is additionally painful for those working on general platform and infrastructure stuff, as that must not break any app), while we have good examples for Windows as well, like Kate or Kdenlive.
I don’t have a sufficiently large sample size for the quality of our Flatpaks, but from what I have seen I suspect we might even have a similar issue there, although to a lesser extend.
Responsibilities, distribution channels, quality control, quality tiers, lifecycle management, etc around (Gear) applications are maybe something worth talking about at Akademy 
as @ben2talk suggested, having a nightly repo on winget or chocolately might help with getting testers on Windows