Almost every time since new launcher was Anki crashes when closed:
(wanted to upload txt file but forum complained that it’s not permitted 
so here is the gist:)
Another annoying thing is that after upgrading with homebrew Anki starts with the terminal window and (re-)installs dependencies, which is mildly annoying…
I recommend including the version of Anki that you’re using. Or better the whole debug info (Anki > About Anki > Copy debug info). The crash report of macOS doesn’t include that information.
In any case, try version 25.07.3 as the crash you’re reporting was reported already a few times here and subsequently fixed.
Issues stemming from third-party packaging should probably be brought up there. However what you mentioned about installing dependencies might be due to a misunderstanding: If Homebrew doesn’t build their own Anki binaries, then they probably just install the official launcher for you.
The launcher is a small program that downloads only the dependencies that need updating. This makes it quicker to update, as big dependencies without changes (for example the Qt framework) don’t need to be downloaded again. It also allows for more flexibility in case you want to use other versions of certain dependencies. And first and foremost it solves the issue of PyOxidizer development being abandoned.
See also New online installer/launcher
Now it seems like the behavior of Homebrew that you describe boils down to, whenever there is a new Anki version, Homebrew will apparently download a new launcher for you, and then when you start it for the first time, the launcher will do the actual updating of your Anki version. Be assured that that last step is needed, as Homebrew just downloading the launcher again does not modify/update your Anki installation in any way.
However I see that it would be neater if all this could happen in one step. I see some options here:
1: Homebrew could provide an actual package of Anki instead of just helping you download the launcher. The source code is available, everybody is allowed to create and distribute binaries. This approach would forego using the launcher altogether as Homebrew would need to make sure their Anki binaries work properly on the systems that they target (mostly macOS I guess).
2: Homebrew could leave updating Anki to the launcher that it downloaded during initial install. After all, the launcher is now the official way to upgrade Anki, and auto-update functionality is included. With the launcher installed, no real reason for Homebrew to get involved anymore. (Small caveat currently being that while the launcher can update Anki, the launcher cannot update itself in case there are changes to the launcher itself.)
3: Just continue on always replacing the launcher with every new Anki version. This might be a slight inconvenience to some users, but it requires no additional effort on Homebrew’s part and also ensures the user gets the newest launcher code just in case something ever changes there.
My bed, will do next time.
Where?
Well, I see misunderstanding here but it’s the one on how hombere works. It’s not like linux package manager from a distro that they rebuild (ad nauseum…) all the packages but rather uses a descriptor with the information about version, download location and hashcode for verification.
e.g for Anki: homebrew-cask/Casks/a/anki.rb at 58443cdebf44a0ad9968519a18935e848f50f000 · Homebrew/homebrew-cask · GitHub
So it’s using Anki packages and it’s a way to make installing and maintaining packages up-to-date without having to go scour the internet looking for downloads…
I read about the new launcher and from the moment I read about it I wasn’t amused (as I’m not amused with terrible state of Python ecosystem altogether, which is completely schizophrenic…)
Why, an end user should care about different versions of dependencies (like Qt)? As I user I want to download the complete app with sane and tested set of dependencies… (though I’ll probably rant in the launcher thread…)
Homebrew doesn’t provide any builds (why would it)? it relies on available stuff. It’s possible to create “formula” which is more akin to building stuff from ground up but it’s mostly for sell apps or those that can’t be bothered with providing sane package…
I’m sorry but:
There are macOS apps that have auto-update functionality and homebrew casks marks them as such so it “doesn’t get involved” and once the app is installed then auto-update from within the app takes over (most of them use https://sparkle-project.org/ which just downloads complete package and updates the .app)
There is no “Check for updates” inside Anki because… it relies on the shell launcher 
Homebrew does have formulas and casks. For the former, they build binaries. Not sure if anybody got nausea yet, though.
Well there aren’t really Anki packages anymore. Maybe the current cask should get renamed from anki to anki-launcher or something?
Ok guess I shouldn’t have mentioned that particular part. Of course as long as one doesn’t tinker with it, everybody gets the same set of dependencies. For some debugging purposes it’s now easier to change up things, but yes agreed that this shouldn’t be done in the general case.
Let’s not discuss package management philosophy. As Homebrew understands itself as a package manager, I only mentioned it providing builds as a possibility. Never did I say anything “Homebrew should definitely do this”.
Tools > Upgrade/Downgrade. This invokes the launcher, but it does check for updates.
Other ideas:
If the cask doesn’t provide Anki itself but just the launcher (as that’s all it realistically can do), and is ideally renamed appropriately, version numbering should be used that reflects changes in the launcher instead of Anki. Because there is merit in updating it in case it changes, but also it’s not needed to update it for every Anki update as that is taken care of by the launcher itself. The only problem being that there doesn’t seem to be any distinct version numbering for the launcher right now.
As Homebrew is really just installing the launcher, and that one currently does not have a GUI yet, it technically makes it an open-source CLI-only software. According to homebrew rules it should be a formula, not a cask. (“App is both open-source and CLI-only (i.e. it only uses the binary artifact). In that case, and in the spirit of deduplication, submit it first to homebrew/core as a formula that builds from source. If it is rejected, you may then try again as a cask”)
There is also another Homebrew rule: App is open-source and has a GUI but no compiled versions (or only old ones) are provided. It’s better to have them in homebrew/core so users don’t get perpetually outdated versions. This, too, seems to apply here if we think about Anki in general. Anki itself obviously does have a GUI but only old compiled versions are provided.
Crashing when closing sounds like you’re still on Qt 6.8. Can you reproduce the issue after updating Anki to the latest version?
It doesn’t reinstall anything if the latest version is unchanged, only checks that everything is already intstalled. But the next launcher update should prevent the launcher from being opened:
No, THEY don’t build anything. Formulas at best are just a recipies how to build things (locally on your machine). Think “slackware” (yuck)
Have you noticed that the current trend is for the distributions to actually stop building their own (often patched) binaries and rely on upstream? Or even use “uber applications” akin to macos .app’s that bundle everything to avoid the clusterf*ck and dependency hell… called flatpacks?
Not to mention whole docker thingy, that relies on static images that are 100% exact wherever you run them?
So the current state is: OS provide minimal OS and required dependencies (often as immutable images), applications get distributed as complete bundles with all dependencies so everyone has the exact same of libraries and dependencies in exact same versions making debugging easier.
And now Anki is doing completely the opposite 
Again, jumping through the hoops because Python ecosystem is bonkers xD
Also: user packages shouldn’t be used for development or “tinkering”… those are "developers packages/environments 
Yeah… those are nice rules, yet after using Homebre for the past ~decade they are more like “things nice to have” instead of solid rules. Not to mention you can have your own cask providing whatever you want.
In the end the discussion boils down to the Anki packaging…
Yes, after updating to the latest version the other day the crashing stopped. Thank you.
My bad - indeed in only performs the checks, which takes some time (and looks like downloading stuff) 
Oh! that’s awesome information! Thank you so much! <3
Well they call them bottles, see the docs here: Bottles (Binary Packages) — Homebrew Documentation And when you install a formula without specifying --build-from-source then it will usually just download the bottle. The binaries are built by their BrewTestBot, see BrewTestBot — Homebrew Documentation and then uploaded to GitHub Packages. You can see if bottles for a certain system are available for a formula by looking it up on their page, for example: xz — Homebrew Formulae The vast majority of formulae do have bottles available. So they do build something, but yes you can also build formula by yourself.
I would say the complete opposite would be something like providing only a tarball for a release. Anki is still providing binaries. Now in Python land they’re apparently called wheels: anki · PyPI (naming stuff in IT is a lot of fun). There’s no complete package that includes all the dependencies anymore, though, that’s true. I think that’s more to do with the state of the Python ecosystem and not something easily changed by Anki.
I guess I just don’t know what a good actionable alternative would be (but my knowledge around Python is also quite limited), which is why I were thinking about ways to improve the situation at the package management level.
I guess that also pretty much solves the mild annoyance factor that was mentioned.
Well, everything started because PyOxidizer was disconinued and there doesn’t seem to be any sane alternative for packaging…
Looking at the threads/issues it seems that Anki migrated to uv (yay! good experience with that) and there was also a mention of python-build-standalone (from the same team) and there were mentions of it in one of the PR (Upgrade python by andrewsanchez · Pull Request #4023 · ankitects/anki · GitHub) which should give an option to have complete-sell-contained build but couldn’t figure out if it was used or not…