missing-root
GrapheneOS is different than Apple and Google. All have their advantage.
We follow the official Material style guide, we simply lack the resources to overhaul all of the legacy AOSP apps. We're in the process of updating all of our own apps to follow modern Material 3 + Material You along with targeting Android 15 including edge-to-edge across them. Overhauling the AOSP apps we plan to keep like Dialer, Contacts and Files will need to be done. It's unclear what to do about the keyboard, calculator, messaging, etc. since alternatives don't really meet our requires. There's a certain gallery app we'll likely fork for Gallery + image editing. We could avoid removing the AOSP one immediately to give people time to transition and complain about what's missing so we can potentially add it before the old one is dropped.
Designwise, Android was always worse than Apple I think. The alarm tones were strange and oddly specific, while apple just nailed their ringtones etc. This kind of "being precise, specific, distinct but not cringe" is appealing to a lot of people.
Many people don't agree and bear in mind AOSP has a bunch of legacy sounds, etc. compared to Pixel stock OS. We have fixed a lot of these little things but not sounds in particular, and not the legacy AOSP apps. You may not have that much experience with the current stock Pixel OS if you use GrapheneOS. The stock Pixel OS also has several proprietary fonts it uses and other differences. We changed the default AOSP green theme to a blue one that's very similar to theirs, use the same rounded icons, rounded corners, etc. but there are little UI quirks and differences from things the stock Pixel OS changes compared to AOSP. In the past couple years, we have eliminated a lot of these UI issues, etc. but there's more to do.
Also using a kind of gradient like red/blue/green as background could be neutral but look better.
We're not going to massively deviate from standard Android Material style. For now, we have simple icons that are much better than the legacy AOSP ones and which were the approach we took for our own apps. People only complained after we replaced the AOSP sample app legacy icons and never when it was just our own apps. Those AOSP icons were awful and this was a low resource way to replace them with something matching the modern Android style and giving us themed icon support without having to make 2 different icons as we would if we designed the main ones with more than 2 colors. Don't forget we need both themed icons and regular icons, and our current ones are actually both at once although it isn't why they are black on white and that isn't a limitation on color.
If Syncthing-android was just blocked for not being up to date, that may be fine. But it didnt sound like that, instead it sounded like Google complaining about some random permission the app has. The dev never got to talk with a human about this and have up after months.
They hadn't updated the target API level and were blocked from making new updates by the target API level being required around 1 year after being introduced by the new yearly update. That's what happened to it. It's clear from the target API level and the timing. A fork of it fairly easily updated it to 34 but wrongly updated it all the way to 35 without testing on Android 15.
Meanwhile, garbage apps like Slack (and everything else?) get along with bs changelogs like
Changelogs are not part of what's actually reviewed. They review the app's code/data/metadata including permissions and there are a bunch of things to submit to say why you use certain permissions, etc. Changelogs are for end users and they do not care what's put in them beyond it not being offensive.
missing-root The same happened for Conversations, where the dev had no privacy policy, but the app had optional contact permissions. Which led to a quite funny privacy policy (which was changed so it is not funny anymore).
Having a privacy policy is required. They make it very clear you simply need to provide a URL, similar to filling out the forms. It's not hard to do and there are few requirements about it. The same goes for declaring why you use certain permissions. As long as it fits into something they allow, it tends to be easy. If it doesn't or they strictly regulate it, you may have a problem. This does not impact the vast majority of apps and isn't relevant to any of these ones.
They have a work profile which is always on, sandboxed play in there (after more hacky things like Obtainium+APKPure caused random issues) and it works well.
Private Space is what's recommended now and is much easier for people to set up.
I know your stance on F-Droid, and while I have a bunch of points to add pro F-Droid I also agree on your negative arguments. I personally use Obtainium, which is kinda bad and background updates simply dont work. There will be something better, probably Accrescent, but not yet.
It does not truly avoid trust in app developers. They don't even pretend to review things. They just AV scan them, etc. and build them automatically, then sign them in batches. Malicious developers can check that in advance and make sure they don't trip it.
Their build environment does not make all builds reproducible and introduces issues such as recently breaking Organic Maps and other apps due to outdated tools and build environment. This introduces security issues which aren't noticed too. F-Droid is consistently using outdated software and development practices, which impacts the apps they build.
I understand why you wouldnt like to preinstall Obtainium etc. But I hope you get my points here.
Obtainium really can't be the answer. It's only even seriously considered because Android has signing verification built-in with pinning, but it lacks an answer for the initial installation being secured well which is important.
Aurora Store is problematic although may become less problematic... but it's just an unofficial way to use the Play Store and we have sandboxed Play Store support already. You're installing code from the Play Store that's almost all APKs generated/signed by the Play Store and many use the Google Play SDK although there's 0 requirement to use it unless you want to do push where they don't really allow an alternative to FCM for power saving reasons or payments (may be different due to recent court wins against them).
I get why you dont want to recommend random software. The outcome simply is that users need someone else to do that, somehow.
There are some rare cases like Organic Maps where we could talk make it available in our own App Store with a changed app id and icon so it doesn't conflict with the developer builds, and just leave it pointing to their site, etc. inside the app. We don't really want to ship mirrors of developer builds in our own App Store with the exception of sandboxed Google Play and Pixel apps not available via Play Store, since that's for Accrescent to do or the Play Store for other Google apps, Uber, etc.