And why would Meta even do that?
For one, the sales were still perfectly respectable. "Versus the rest of the lineup" is doing a ton of work here, because the rest of the iPhone models sell like crazy. For two, it is still bizarre that manufacturers refuse to make small phones even with that in mind. If you wear very small clothes (or very large clothes) that won't sell as many units, your options are limited, you have to pay more, but you aren't forced to go naked. But there's nobody out there doing the equivalent strategy for phones.
- remind you that the phone is in your pocket, to initiate the infinite scroll
[1] https://forum.fairphone.com/t/official-lineageos-23-for-the-...
[2] https://wiki.postmarketos.org/wiki/Fairphone_(Gen._6)_(fairp...
Forking GOS and porting it to a new device is a huge and unreasonable ask for an individual user. Even less so when you include the fact that you'll need to keep it up to date.
https://wiki.postmarketos.org/wiki/Fairphone_(Gen._6)_(fairp...
> Fairphone has said they don't plan to add a secure element. It can be seen from their current devices that they don't fully keep up with privacy/security backports and lag a year behind on shipping yearly OS releases. They skip over the monthly and quarterly releases entirely. They replaced their own non-GMS Fairphone OS with a dramatically less secure /e/OS option in partnership with Murena. They clearly demonstrate that security and even privacy are not the priorities.
it sounds like they are saying that /e/OS is less secure than fairphone's own OS. with all criticism against /e/OS taken into account, i highly doubt that fairphone would have been able to make their own version of android more secure than /e/OS when they are not even interested in working on that.
Case in point, I recently wrote a CLI to show which of your AWS infra is not captured in terraform, and you can either print the result as a json to consume by a machine or generate a dashboard with some charts. It took me an embarrassing while to realise that I should have included a damned screenshot in the README, in fact I think I only realised when I wanted to show it to my brother.
Which is a bummer because it is a complete different point of view from the more typical user experience
In many cases the repository isn't meant to be more than for source code too, not everyone use their git repository as also the marketing page, that'd go somewhere else.
With that said, grapheneos.org doesn't seem to have any screenshots either, which I also don't understand and think is a bummer. Even though the point of the differences with GrapheneOS might not be mainly visual, just showing what it looks like seem like a no-brainer.
It's like we've had this ancient knowledge passed down for generations but people constantly just ignore it.
Your comment is unnecessarily inflammatory.
There's only a handful of critical details in a call history, and absolutely no reason for any UI to implement them as secondary or tertiary details: Whether it was in- or outbound. To/from what contact. The date and time.
2 taps for some other extra info such as call length, or further contact details, would be OK I guess, but for first-level info as these, it's 100% bad design.
I mean come on, design-wise this was already a "Done" thing in the golden Nokia days! https://the-gadgeteer.com/2009/03/02/a-week-with-the-nokia-n...
[*] Ctrl+F to find the image below "miss a call".
Clearly.
>There's only a handful of critical details in a call history
And they're all there: profile pic, contact name, indicators that show incoming/outgoing + missed/connected, which SIM, a redial button, how long ago (which after about a week shows the date), Tapping the middle expands the row (no obstructive pop-up) to show Block, Message, & Details buttons.
The reason it has 'human times' is because multiple calls with the same contact are grouped, so a precise time doesn't always make sense. Tapping the Details will show all calls in that group, whether it's one or seven, with their full dates, times, durations, and further options. It's never been a difficult UX.
I might be mistaken but I seem to recall it being a done thing for android prior to several years ago when it was "improved" with an update. Although it's possible I'm confusing the call apps from AOSP and various vendors. Either way several of my past android devices had a significantly better address book, dialer, and call history.
Also, GrapheneOS has very recently released automatic call recording for the Dialer.
You mean the perfectly functional (if barebones) AOSP call app? :)
Unfortunately I think that feature is shutting down.
https://www.verizon.com/support/vtext-vzwpix-shutdown/
I'm still waiting until RCS is supported before I actually use it.
It's not as funny in hindsight, given the unexpected results of that election, but at the time, it felt like top-tier humor.
AFAIUI though GOS does intend on providing an RCS impl eventually even if it takes years to do.
TIL that RCS was designed as a fairly decentralized protocol where every carrier could run their own RCS servers, but it didnt get adoption. So Google stepped in and built their own routing infrastructure, and now mostly all RCS is centralized on Google's servers (even if you use an iPhone, because the RCS server is mandated by your carrier)
I broadly expect third-party RCS apps to drop that though, like how essentially none support all of MMS. did you know MMS supports slideshows (I built support for this once)? 3d objects (mimetype model/gltf+json)? "timed text" (mimetype text/mp4)?
In my experience, Graphene OS doesn't make compromises.
So having a bare bones aosp messaging app was never an issue for me. Having said that, I find fossify messages pretty good.
Will try out the new GOS app too.
(sarcasm obvious, but indeed full system backup is sorely missing. Seedvault is crap, not an option)
I can imagine many reasons to devote resources to it:
* A platform is only as good as its apps. If they want to grow GOS in the general public, it requires a good SMS/MMS messaging app.
* LLM tools greatly reduce development costs, especially for well-known functions like text messaging.
* Without secure messaging (as far as SMS/MMS can be secure), the platform security is greatly reduced.
* GOS got a big donation, or has a volunteer that wants to do messaging ...
But idk what I'm talking about. What is their approach?
If they fix(ed) their messaging app and their keyboard, then they've really eliminated a lot of potential complaints if a less tech-savvy crowd ends up buying future Motorolas.
They also plan to eventually support RCS in the Messaging app.
That's great. How can a FOSS project afford that? Where does GOS money come from? Did Daniel win the lottery?
They have 14 devs 13 are payed in ETH and 1 in CAD.
Iirc they said something like 2 million in donations in 2025. Vitalik Buterin may have donated at least some time ago.
Proton donates double digits.
Cape has donated around 100k https://www.cape.co/blog/cape-supports-grapheneos and plans to donate 100k this year.
There's estimated 500k users so if 25% donated 10 dollars a year that's 1.25 million.
Modernizing these apps seems very high-impact. These are the very first things a new user sees and after the initial modernization, they should be relatively cheap to maintain.
Messaging can be replaced with one of the hundreds decent messaging apps.
Unlike the backup app which is utterly unusable, untrustworthy and frankly crap. And CANNOT be replaced by anything else.
As it stands it's impossible to have reliable backups in GOS.
If my phone were lost, stolen or destroyed, I would simply revoke its Wireguard key, buy a new Pixel, flash Graphene, and provision a new Wireguard key. Essentially no data of value would be lost, and restoring my apps and settings manually would take an hour tops. Admittedly, I don't use many apps, so YMMV.
IIRC when they started first announced their replacement for the AOSP camera they said they hired a developer specifically for it.
People prefer larger tap targets on touch screens.
Only in a completely stupid, nonsensically A/B tested notion of "prefer". I'll refer you to this ~~excellent piece of satirical writing~~ actual post from Google design team: https://design.google/library/expressive-material-design-goo...
Are you this … poorly informed
Makes me wonder about all the testing now
And the issue worded/tagged as a feature instead of a regression. Are the devs aware the feature existed before?
later:
It's doubly disappointing because just 4 days ago the project wrote [1], on using AI for the new Messaging app:
"it's also helping us raise our standards for our own work by pointing it at that to get extremely pedantic criticism catching many things we would miss...We've hired multiple experienced app developers who have spent months working on modernizing the Messaging app and carefully reviewing it"
People sometimes.
Further, I believe it's reasonable for users' expectations to be influenced by what the project itself communicates about the development process.
> People sometimes.
I have experienced many (relatively minor but some annoying) bugs in GrapheneOS the past few years, without complaint to the developers. And have submitted bug reports and logs. I'm "in the trenches", not just slinging mud from the outside. If I were in a better financial situation right now, I would be donating too.
I suspect there are fewer regressions per release on graphenes alpha messenger than there are in googles message's app.
Why? Using an LLM as an additional reviewer seems like a good use of LLMs? Personally I have found LLMs very useful for that and they catch issues that other experienced programmers do not always find. It’s not like they are vibecoding a messages app.
> shame an obvious regression happened for one of my primary use-cases: copying one-time codes
Then the "later" is that even with frontier AI review tools, it was still missed
I am not alleging vibe coding - that's a strawman.
Other than that -- next year. And this is other companies' choice, not GrapheneOS team, to fix on releasing grossly insecure hardware or NOT releasing patches and fixes.