> for the Android case, as you use it from your bank's app, it would typically require some Google security assurances - so no Huawei phones allowed, for example
I don't know about Huawei, but actually most (all?) of the banking apps in Spain should work on a non-Google-certified Android builds. There's an community list tracking GrapheneOS compatibility at https://privsec.dev/posts/android/banking-applications-compa... and all of them currently appear supported just fine.
> Police in Spain have reportedly started profiling people based on their phones; specifically, and surprisingly, those carrying Google Pixel devices. Law enforcement officials in Catalonia say they associate Pixels with crime because drug traffickers are increasingly turning to these phones. But it’s not Google’s secure Titan M2 chip that has criminals favoring the Pixel — instead, it’s GrapheneOS, a privacy-focused alternative to the default Pixel OS.
> “Breakup” seems a bit exaggerated considering the % of payment volume which might switch to the new system.
Brazil introduced Pix in 2019, it's now the most used payment method for all transactions nationwide, ahead of both cards & cash.
India introduced UPI in 2016, it now handles >80% of digital payments there, and handles more transactions a day than Visa does worldwide.
It's totally plausible to me that a similar replacement could overtake cards completely within a decade. The lack of cross-border support means "Pay with Bizum" is a niche feature that's only useful in Spain, but if "Pay with Wero" becomes an instant & ~free payment method that works for hundreds of millions of users then it's a very different ballgame.
And also much of East and Southeast Asia as well: AliPay (CN), Kakao (KR), PayPay (JP), JKO (TW), GrabPay (SG/MY), QRIS (ID), etc. with various interop compatibility between them. If you build it they will come.
It took over cash in 2024 by number of transactions. And yes, cash is estimated.
I imagine bank transfers are still the largest payment method by value. Pix is taking over bank transfers, but companies have very few reasons to migrate.
I've been using their DNS (and CDN) for a good while. Only positive experiences - fast & rock solid. I would start a new project with them again in future.
I've also tried some of their new more experimental stuff (magic containers, edge scripting) and it's much rougher, but the core product is very good imo.
I wish they'd focus more instead there tbh, there's plenty more that could be done in terms of core content delivery, without trying to enter other (very competitive & I think much more complicated) markets like serverless hosting.
It's not about money. It's not a tradeoff in cost vs quality - it's a tradeoff in development speed. Shipping N separate native versions requires more development time for any given change: you must implement everything (at least every UI) N times, which drastically increases the design & planning & coordination required vs just building and shipping one implementation.
Do you want to move slower to get "native feel", or do you want to ship fast and get N times as much feature dev done? In a competitive race while the new features are flowing, development speed always wins.
Once feature development settles down, polish starts to matter more and the slowdown becomes less important, and then you can refocus.
Doesn't this get thrown out the window now that everyone claims you can be 10x, 50x, 100x more productive with AI? Hell people were claiming you can ask a bunch of AI agents to build a browser from scratch, so surely the dev speed argument no longer applies.
Even if we assume a developer is actually 10x more productive with AI, if you triple their workload by having them build 3 native apps now you're only 3.33x more productive.
Yeah that's why startups often pick iOS first, get product-market fit, and then do Android. The fallacy that abstractions tout is that Android and iOS are the same.
They are not.
A good iOS app is not 1:1 equivalent to what a good Android app would be for the same goal. Treating them as such just gives users a lowest common denominator product.
So, this certainly was a valid argument. But it seems to me that the whole value proposition behind these agentic AI coding tools is to be able to move beyond this. Are we very far from being able to define some Figmas and technical specs and have Codex generate the UIs in 5 different stacks? If that isn't a reality in the near future, then why should we buy AI Tools?
> Similar experience in Spain, fill out 2-3 forms and it's done.
This isn't true in Spain - all company creation requires a notary, among other awkward steps (although as of relatively recently in some cases you can now do this over videoconference, without physically visiting at least). It's not as bad as what I hear of in Germany, but it's non-trivial and slow, and the banking setup process is similarly annoying and slower than it should be.
You can register as autonomo (an individual freelancer) easily with just a couple of forms, but that is not the same thing as creating a separate legal business entity (SL).
In terms of waiting times to see a doctor or specialist (the only cases where stats for the US seem to be available), the US looks a touch better than average in waiting times for healthcare within comparable countries: https://www.oecd.org/en/publications/health-at-a-glance-2025....
Ahead of Canada, sure (they come worst here in both scenarios) but behind countries like the UK, Germany & the Netherlands that do have universal health care.
It's definitely annoying if you work in enterprise, but on the flip side: the fact that these enterprise requirements exist is the main reason that TLS certificate configurability is possible at all, without which it would be dramatically harder (or impossible) to reverse engineer or do security & privacy research on mobile apps, IoT, etc etc etc.
Enterprise control over company devices and user control over personal devices are not so different.
A few apps do use certificate pinning nowadays, which creates similar problems, but saying "you can never add your own MitM TLS cert" is not far from certificate pinning everything everywhere all the time. Good luck creating a new home assistant integration for your smart airfryer when you can't read any of the traffic from its app.
Imo: let's make it easier! Standardize TLS configuration for all tools, make easy cert configuration of devices a legal requirement (any smart device sold with hardcoded CA certificates is a device with a fixed end date, where the CA certs expire and it becomes a brick), guarantee user control over their own TLS trust, and provide good tools to check exactly who you're trusting (and expose that clearly to users). Not really practical of course (and opens all sorts of risky games with nation state interception as well) but there are upsides here as well.
> Standardize TLS configuration for all tools, make easy cert configuration of devices a legal requirement
I think this is the right idea (it’s configuring dozens of things which causes problems) but the other idea I’d consider is standardizing a key escrow mechanism where the session keys could be exported to a monitoring server. That avoids needing active interception with all of the problems that causes, and would pair well with a standardized OS-level warning that all communications are monitored by «name from the monitor cert» which the corporate types are required to display anyway.
Totally agree. Chiming in as another React dev: I really regret the last few years of choices React has made. I don't want a React-integrated BFF layer, even on greenfield projects, hooks are awful and the whole thing just gets more awkward to solve tangentially related problems.
I really do want a good frontend framework that lets me expressively build and render dynamic frontend components, but it feels like 99% of React's development in the last few years has been just been creating churn and making that core frontend experience worse and worse. Hooks solve challenges around sharing component meta-functionality but then end up far worse for all other non-trivial cases, and it seems like RSC & concurrency just break things and add constraints instead of improving any part of my existing experience.
I guess this is cool if you're building mega-projects, but it makes React actively painful to use for anything smaller. I still use it every day, but as soon as I find a good off-ramp for my product (something similar, but simpler) I will take it. Moving towards Preact & signals currently seems like the best option for existing projects so far as I can tell.
> These non-free software components are not required - you can compile and run Pebble watch software without them. This will always be the case.
This seems like a reasonable balance. They're shipping default distributions with these blobs included, but you can remove them and run the literally completely purely open source version directly instead if you prefer (although it sounds like you'd notably lose heart rate tracking, along with speech recognition & similar).
reply