I think the reason behind using React and JavaScript is simpler - these tools are heavily vibecoded, and React/JavaScript is what was most present in the training data and as such is what the models excels the most at generating.
The crappy laggy UIs have the same root cause - heavy use of vibecoding with lackluster quality processes
The 24 hour wait period is the largest of the annoyances in this list, but given that adb installs still work, I think this is a list of things I can ultimately live with.
That's not correct - the flow described in the post outlines the requirements to install any apps that haven't had their signature registered with Google.
That means those apps still keep on existing, they are just more of a hassle to install.
Public transit in Stockholm has in the last ten years done two things that make for a godlike ride payment UX:
1. Removed the concept of zones - everything is now covered by one single ticket
2. Introduced tap-to-pay support for debit/credit cards
This means that you as a user can always just show up with the overwhelmingly most common way to pay for things in Sweden - by card - tap once, and then you're done. No more actions required. Need to transfer? No problem, the virtual ticket you bought by tapping your card is valid for 75 minutes, no more money will be charged if you tap again within this window.
No fumbling with an app, no awkward QR code scanning, just one tap and go. Peak UX.
Same with Edinburgh. Except that we also cap daily and weekly fees. So it's £2.20 for a single ticket to anywhere, maxing out at £5.00 per day, and £24.50 per week.
(And if you're regularly travelling more than that, then you can pay for a card that will give you unlimited bus/tram travel for £70/month.)
I'm a bit jealous of those prices, there are no caps on Stockholm transit if paid for on single tickets, and the price of a single ticket is 43 SEK (£3.45). The best deal available for period tickets is the unlimited monthly pass for 1060 SEK (£85).
The crappy laggy UIs have the same root cause - heavy use of vibecoding with lackluster quality processes
reply