It sounds like your issues are mostly down to individual maintainers, rather than snaps as a platform. I wrote a much longer version of this originally but felt it was getting too wordy, so I thought I’d respond in summary to each.
Snapd is a small Go daemon that follows Unix philosophy. Flatpak has no daemon explicit but implicitly demands an entire functional desktop shell. This means snaps work on e.g., WSL2 (even graphically) whereas Flatpaks don’t because the Flatpak design is far more bloated in terms of what’s required to be minimally functional.
- it’s proprietary software
The daemon and tooling aren’t. The only proprietary component is the web server dealing with HTTP REST API the daemon interacts with. The API is completely open.
Anyone could reimplement it. No one can be bothered to. So whilst this feedback is valid, it’s not unsurprising the first thing people do when installing Flatpak is adding the Flathub remote, because actually the majority of people actively want centralization for convenience and security. So whilst it’s a valid complaint, would your experience be any different if the server components were open practically? People would move onto new reasons to not bother helping out, and we should focus our efforts on stuff that will actually have a payout IMO.
slow
Historically this has been due to XZ compression being used. Modern snaps now use LZO. If a snap is slow make sure the dev is using LZO. In the future ZSTD will be used for even further speed gains.
The Steam snap opens quicker than the Flatpak from version 2.65 of snapd, and big apps like Firefox have had specific optimisations to speed them up to be on par with native. Huge chunks of this were with the apps own logic, and while there were improvements in the snap ecosystem around the same time for the benefit of all, the fact “Firefox is (was) slow to boot” isn’t true any longer and was only a singular snap out of thousands that required significan engineering resource due to bugs in the app itself. Most people just need to become more proficcient in minimalism of what they package and making sure to use the newest features available.
bugs
Same as any software, the maintainer should fix them.
I don’t personally see it as a failing of snap if we can’t yet support them with the tooling available. The maintainers have responsibility to not produce and leave garbage in the public. Flathub does this much better because Flathub doesn’t seemingly have as many randomers dabbling around and then commitment traps.
I don’t fundamentally see any reason snap would have more bugs than e.g Flatpak, the apps and packaging needs accomodating for both, but I do think Flatpaks community holds themselves up better here for the user experience.
Could you explain?
- firefox trying to update every 2 ~ 3 hours,
There’s been a load of work on this and I can’t honestly remember where each release is currently up to. You don’t have to update when it asks, though I’d recommend you do. Fundamentally this comes down to Firefox being open a lot for most people, and being unable to update an app when it’s open. (Apt couldn’t either, and would force you to restart Firefox on demand crashing your tabs when it does so!)
- blank fonts and/or Unicode block instead text like: �������
This is a maintainer problem for the most part because the fix for this landed 5 years ago but people have to use it (extensions being rewritten to separate all underlying font caches and regenerate them with the appropriate userspace tools for each snap). Unfortunately a lot of this problem seems to come from Electron where people happily use 5 year old toolchains for 10 years at a time.
Bugous themes like: text and background with same color, giant text or icons, blury fonts and/or images.
Honestly I’ve not noticed this one cos I don’t play with themes, but unfortunately, there’s a reason GTK4/Libadwaita is going the way it is, and why frameworks such as Flutter, Avalonia, Java, etc, don’t even attempt to integrate natively.
The theming situation is bad for both Flatpak and Snap IMO, and personally I just never bother changing themes to anything that’s not built in, knowing that most third party devs don’t bother caring to fit anything other than “the default” if they even bother at all.
I’d be happy to go into specific points more, but this is getting pretty wordy. In summary, I think a lot of your points are valid at certain points but the impression I’m getting is you’re having specific UX issues with certain flows (I.E the Firefox updates, and I know the Refresh App Awareness stuff is constantly in the patch notes for future improvements), but a lot of them, slow, bugs, bad text rendering; come down to the individual maintainers.
Out of curiosity, other than Firefox, what snaps have you tried recently?
Personally I feel there’s a lot of stuff that should land in the next year (better updates, dynamic sandbox permissions / prompting, components which I think are what’s going to allow PC-Kernel snaps for NVidia users on hybrid systems, including TPM managed FDE & etc) that should mean that the Snap experience on Ubuntu 26.04 should hopefully be absolutely solid, but I’d agree for the past several years there’s been elements lacking. As a platform separate to it’s ecosystem though, I think snaps in a great spot! Including other things such as AF_UNIX mediation landing upstream in AppArmor, spreading the sandboxing improvements to other distributions, improving other distributions compatibility in general, etc 
. The next 2 years are more exciting then the last 2 have been to me.
(And I’m still hoping for Deckubuntu Core).
