As I fixed an issue I had with text messages by installing a FOSS app from F-Droid, I realized that at this point I’ve replaced nearly every Mudita app with a FOSS app that does that same thing but does it better.
That made me wonder, why is Mudita spending so much effort on its own inferior apps? There are so many good open source apps, the team could have forked the code, made whatever tweaks they think are appropriate, and then packaged them in the phone. Then more time could be dedicated to the MuditaOS / UI. In some of these cases, it feels like they tried to reinvent the wheel and now we’ve gone from an EV back to a Model-T. I like their vision for the device and I’m sure they’ve been working hard, but it really seems odd that better versions of these apps already exist for free and could have just been optimized for E-ink. Am I off base in thinking this? Is there something I’m missing?
I feel exactly the same way. The hardware of the phone is very good , but the apps are unfinished in my opinion. I originally didn’t want to sideload anything. I don’t have the skill and experience with ADB or writing code, but the poorly functioning existing apps forced me to learn. Yes indeed it would be enough to use open source apps and modify them for e-ink. The big benefit is the ability to download apps and customize your phone to your image.
I agree. I’ve disabled all of the builtin apps on my Kompakt. I’m disappointed to hear that upcoming development will mostly be spent reinventing the wheel with all these builtin apps, since there are so many system level improvements to be made. I’ve been enjoying using the phone the past few weeks, but that’s only because I’ve heavily modified the system configs and patched some of the system partitions just to get functionality I would’ve expected to have already from an AOSP based rom. This phone has been making me use my phone less, and it’s been great not browsing the web, texting, etc. as much. But when I am on my phone, I waste more time than I’d like navigating the excessively rigid UI just to do simple stuff like pause music, check battery life, change media volume, etc.
Yeah that was my thought as well. Why are we working on trying to catch these apps up to what existing FOSS apps already do when we’re missing things as basic as voicemail notifications (or how about just let us control our own notifications entirely). It’s crazy the workarounds I’ve had to use to access certain settings that seem to have been blocked off for whatever reason. I’ve even replaced the launcher (I used multilauncher, which is pretty similar to the yamlauncher in the screenshot previously posted). Even really really basic apps like the alarm and contacts app lack functionality that’s present in apps from other sources.
Now I do like the idea of a phone that respects my privacy so I wouldn’t just grab any random app out there but the nice thing about FOSS apps is that they could examine the code first to make sure it’s not sending our data out to some third party (or just use a network capture tool while it’s running on WLAN).
I have been saying this since the beginning. I have a FOSS music player and podcast player. Why didn’t they just reuse an existing app? The FM radio also works, btw. And with DAVx5 and the stock calendar app you have calendar sync.
It looks like a hobby from Mudita to rebuild things from scratch. They did the same with the Mudita Pure.
No, it’s not terribly difficult. For one, you could run the app on a test phone with a WLAN connection only and then run packet capture to see what’s being sent out.
But an even better method is you only take FOSS apps and you have your engineers examine the source code to see exactly what it does. If the app is going to send your data somewhere, that would have to be defined in the code. That’s a daunting task for a random user to do but totally doable for a software team.
I also find it hard to get used to the native apps on the kompakt but I just want to stick with them.
Texting is just slower but I see it as an intentional feature to be slower and more mindful about my texting.
The Maps app with navigation (after the upcoming update) will be completely fine by me.
The Music app with Playlists (after the upcoming update) would really improve my listening for different music. Love Nick Lewis Songs, but I need more songs soon
Chess is fine as it is. (just would love an actual two-player mode)
Weather is fine, maybe air-quality or uv would be neat?
Meditation is really nice and I like it a lot.
Calculator is also simple and useful
e-reader lacks some features and looks a little rough. BUT it really helped me to start reading books again.
Calendar needs CalDav (for more personal use)
Having no actual timer is a litte baffling, but maybe it will come?
Notes and Recorder are just fine for me
So I really like that mudita develops its own apps. I think only that they have complete control and know how it will perform on their kompakt.
I understand custom apps for the device and I see the value as a customer.
The simple, clean, eInk appropriate apps complement the overall experience.
I find that I prefer the simple meditation app to Headspace for a number of reasons.
On the other hand, KOReader is vastly superior to the built-in e-Reader thanks to contrast and margin adjustments.
I will patiently wait to see how Mudita improves the OS and apps and surely enjoy each iteration.
I think the issue is the divergence from base Android means that you may get a better experience with their native apps (in the long term - this is a young product right?) But I agree not every app needs to be reinvented. What I would dislike more than if a few of the native apps aren’t yet perfect is if they just made the phone basically become a blank canvas of hardware and OS with no bundled software, even worse if they gave up on their own OS. To me it then just becomes a shell, one where you’re more likely to end up with a ‘smart phone’ but worse because the whole design was never oriented around that. Likely Mudita will make some decisions users agree with and some they disagree with but I actually like the fact someone is thoughtfully doing that for me (with a good balance of configurability and ability to sideload). Everything else I’ve seen is one extreme or another - either some ridiculously pious approach of a device I can’t control or do much with or something that is basically like any other smart phone. I can see the argument for a middle ground with no bundled software centred around open source - but maybe that’s a completely different product they could look at.
All this said the quality of discussion on here is a really good thing.
And again guys, we’re talking about FOSS apps, so the arguments about being optimized for the Kompakt or having more control don’t make sense.
They could have forked the code from an existing app to get all the features that are already developed, then optimized it for e-ink and thereafter maintained that fork on their own, thus giving them complete control. So I still don’t see a reason for them to insist on reinventing the wheel.
Hi everyone,
It’s an insightful question, and a very interesting thread. From the beginning, our goal with the apps was not to reinvent the wheel, but to build on open-source foundations whenever possible.
We picked which apps to build on based mainly on the following criteria:
a) Open license that also allows us to freely distribute on Kompakt and potentially through other channels in the future.
b) Stable code. Apps with few bugs and a solid history of active maintenance. In some cases, we couldn’t find enough reliable information to confidently assess the app’s quality, and since testing and fixing issues in a baseline app also takes time and resources, that factored into our decisions. In some cases, the safest choice was to start with an AOSP app.
c) Offline-friendly. We didn’t want apps that rely on always-on connectivity.
d) Adaptation cost – how much effort it would take to adjust the app to E-Ink and our design language.
e) Functional fit. We aim for minimalistic, lightweight apps. We try to avoid the need to remove or disable functions, as this can compromise quality and increase maintenance costs.
f) Languages/Frameworks used – unifying the tech stack makes maintenance and development easier.
Points b and d were especially tricky to evaluate at the beginning of the project. It’s totally possible we made a few wrong calls or missed better starting points.
What we’re focused on now:
improving the core apps to better match what you’ve been asking for,
making sideloading easier (first changes coming in 1.2.0 this month),
releasing our design system to make it easier and faster for the community to build apps for Kompakt - planned for Q4 this year.
If you know of any FOSS apps that run well on Kompakt and preferably use a license like MIT or Apache 2.0, we’d love to hear about them. Even at this stage, your suggestions could still help us move forward.
Ooh, I love this last bullet point. No idea what I could develop for the Kompakt yet, but this is interesting and very likely a step in the good direction. It is very pleasant to see that you explained to us the vision you have for Mudita OS. I still do not have my device yet, but I will probably stick with the default apps. Will only sideload messaging apps.
The point of having so many features in such a simple phone kind of demonstrates the need to “go back to basics”, and that’s what this device aims, I guess.
Fossify.org has a number of apps. They are under the GPL-3 license, not MIT/Apache but it’s still a license that allows you to modify and freely distribute the software. I can’t comment on unity of framework/languages because I don’t know what your dev team is using.
So far, the Fossify apps I’ve tried seem to be very stable and looking at GitHub they are being actively maintained.
Messages - Displays well enough on e-ink, main reason I switched to it is because it can read group text messages whereas on the Mudita SMS app, I was racking up notifications from group texts but I couldn’t clear the notifications because the Mudita SMS app wouldn’t even show me the messages. Bugs: If I respond to a group chat, it sends an individual text message to each person on the chat rather than sending it to the group chat. I don’t know if there is some weirdness with the MK that is causing this since I haven’t tried it on another device.
Phone: I started using the Fossify phone app because I can add a number from my call history to my contacts, whereas the MK phone app did not give me this option. Bugs: When a call comes in, it wasn’t displaying properly so I had no way to answer the call. That was a pretty big one so I had to switch back to the stock MK app
Music Player: Looks great on e-ink, offline, lets you organize music by folders or playlists.
Gallery: The display is passable on e-ink, I’m not sure how much you can really expect since the pics themselves are very hit-or-miss in how well they look on an e-ink display.
Clock Beta: This one is likely a bit less refined since it’s labeled as a beta, but it looks good, has a stopwatch and timer, and I can customize the snooze time.
We actually looked into SMT at the beginning. It’s a great project, but the GPL license was a limiting factor. We don’t have a strict policy against using GPL - it’s evaluated on a case-by-case basis. For example, MuditaOS used in Pure and Harmony was released under this license. However, even though we don’t sell the software itself, the obligation to release all of our work is not always feasible, especially since we operate in a competitive market where most of our competitors don’t do the same.
That’s why the ideal candidate for a baseline project is simple and offline, licensed under MIT or Apache 2.0, written in Kotlin, and using the Jetpack Compose framework.
