> I wonder from a modding perspective would it be better if all public methods are just the API users can call and they themselves create a way for mods to exist?
It's the way vintage story implemented modding. They developed the whole game as engine + modapi + hooking engine for stuff outside of hookapi.
Then most of gameplay is implemented as mods on top of engine using api and hooking. And those tools are open source, with central distribution point for mods, so servers can dispatch and send update of required mods to clients as they join.
Marvellous and elegant design. Makes running a server with client side mods a breeze, because mods are automatically pushed to the clients.
Though in the end, you can't really open all the interfaces and expect it to be stable without making some huge trade offs. When it works, it's extremely pleasing. Some mods for vintage story that are made purely using mod api can work between major game versions. Even server/client version check is intentionally loose as mismatched versions can still for the most part interact across most of mechanics.
In practice, to preserve balance of api evolution and stability, not everything in the game is in the api, and thus you have to use their hooking api, and stuff that is not exposed tends to break much more often, so mods require manual updates, just like in minecraft(though not as bad, tbh. In minecraft nowadays modders tend to support both fabric and neoforge/forge apis, targeting each for at least a few major versions. In vintage story, you only gotta support one modding api heh).
I've been using Niagara since its first days. Absolutely loving it and it keeps getting better year over year.
The only thing I miss still is not being able to open drawer by swiping up (though fastscroll on letters is good enough, but kinda sucks that it only handles latin letters there, cuz like 3rd of my apps are in Cyrillic and thus stuck at the first category).
UX on foldable device is unmatched, especially after it added support for side-to-side widgets and widget stacking.
Another slight annoyance is that in modern android quickstep is no longer standard part of AOSP, and depends on how OEM implemented it, which means that on many devices (including mine mix fold 2) you either lose access to gesture navigation in order to use Niagara(I get around it by using Infinite Gestures + OMS overlay to hide the navbar) or get broken animations when swapping between apps and going home.
UPD: it also recently got client-side implementation of monet and built-in contextual variable icons, which works even on devices that don't have it as a part of AOSP. It works marvels and I can't get enough of how good it looks.
And in general, I wish more launchers had fastscroller as overlay option, so that you can get to any app via tapping/flicking onto a letter in a single tap/swipe. Once you experienced it, it's hard to go back to the app grid.
While it's good to have core technology as part of OS, it also makes it non-updateable separately from the OS itself, which slows the spread of developments.
That's my main gripe with apple's approach to swift and swiftui. Yes, tech is getting better every day, but unless you target latest OS version, you can't use new fresh stuff until it's on enough devices around you. And that pretty much guarantees that no matter what apple adds, you still have to wait a year or two until you can safely start using it.
In modern android, kotlin(and compose) also part of the system, yet all the apps do not rely on the system libs, but rather inject the latest available runtime with each of the apps. It takes more space, but instead allows developers to target latest available stack, no matter what core os this app is being run on.
It's the way vintage story implemented modding. They developed the whole game as engine + modapi + hooking engine for stuff outside of hookapi.
Then most of gameplay is implemented as mods on top of engine using api and hooking. And those tools are open source, with central distribution point for mods, so servers can dispatch and send update of required mods to clients as they join.
Marvellous and elegant design. Makes running a server with client side mods a breeze, because mods are automatically pushed to the clients.
Though in the end, you can't really open all the interfaces and expect it to be stable without making some huge trade offs. When it works, it's extremely pleasing. Some mods for vintage story that are made purely using mod api can work between major game versions. Even server/client version check is intentionally loose as mismatched versions can still for the most part interact across most of mechanics.
In practice, to preserve balance of api evolution and stability, not everything in the game is in the api, and thus you have to use their hooking api, and stuff that is not exposed tends to break much more often, so mods require manual updates, just like in minecraft(though not as bad, tbh. In minecraft nowadays modders tend to support both fabric and neoforge/forge apis, targeting each for at least a few major versions. In vintage story, you only gotta support one modding api heh).