Done! I wrote up both my concerns about this and how it affects app/app-store market competition, and how limitations like Play Integrity encourage apps to block usage on non-Google approved devices as well, since that's anti-competitive within the mobile device & OS market (blocking GrapheneOS, Waydroid, etc).
Supporting free competition with and within the Android market is in theory what these teams are all about so hopefully with enough voices they'll push harder on it. I'd love to see a shift here that makes non-Google/Apple-controlled mobile a possible option (even if it's a Linux-on-desktop-style niche for the foreseeable future)
This exists, https://www.sonofatailor.com/ for example. You put in a full set of your measurements, pick a type of garment, and they make it to fit and ship it, takes a couple of weeks or so.
It is more expensive, but not impossibly so, and they fairly aggressively discount for larger orders which presumably amortizes some of the overheads.
> 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.
Supporting free competition with and within the Android market is in theory what these teams are all about so hopefully with enough voices they'll push harder on it. I'd love to see a shift here that makes non-Google/Apple-controlled mobile a possible option (even if it's a Linux-on-desktop-style niche for the foreseeable future)
reply