1. It uses the builder pattern for views (familiar to those who used Java) but for some reason they decided to make it so that the order of the modifiers in the builder matters. Each modifier doesn't actually modify the main view but it modifies what the modifier before it decided to return. This makes no sense as the modifiers should each be modifying the main view to make everything predictable and easy to debug. I'm convinced no one (not even senior devs with 5 years of SwiftUI experience) understands how the ordering of modifiers works. It's just swap them until it does what you want it to.

2. The view lifecycles and code execution path seem random and hidden behind layers of "magic," making it incredibly difficult for developers to trace and debug issues.

3. It is practically impossible to set breakpoints for rendering and view construction, it's impossible to really figure out when re-renders happen and what drives them. I'm convinced SwiftUI apps are incredibly slow not because the SwiftUI implementation itself is slow, it's because, even Apple's own apps probably do a bunch of unnecessary re-renders and one no one seems to have any idea. This is unfortunately another design issue that can't be solved by just making SwiftUI more efficient. It requires simplification and tooling to help developers not footgun themselves.

4. Lots of issues start appearing later on in the development cycle because, for simple apps, bad SwiftUI design decisions and footguns have unnoticeable effects, until the apps gets more complex and things start breaking. Fixing these issues sometimes requires rewriting whole features or spending hours debugging.

5. There seems to be almost no documentation on Liquid Glass. It's laughable that after more than 1 year, Apple has simply refused to document or provide good examples for Liquid Glass, except for maybe couple pages that resemble the brain dump of an engineer that has never passed a writing class in college?

6. Stuff seems to be rapidly changing and breaking from version to version. It took days to make my app look and work the same in iOS 27 as it did on iOS 26, even though iOS 27 is supposed to be a minor bug fix release. We don't even use anything non-standard and don't do any hacks. This defeats the whole purpose of a simple UI framework that can be easily adopted to different platforms (this never used to happen with UIKit).

7. View debugger still has no SwiftUI equivalent. It used to make things so much simpler in UIKit when you could just see the view bounds, pick views apart and understand what's actually happening. SwiftUI has no equivalent other than `.background(.red)`. Terrible.

I don't know how Apple can salvage this beyond just undoing some of these terrible design decisions and making it 1. super simple to work with, 2. stop relying on magic, making things more explicit, and 3. providing actual 1:1 UIKit feature parity.

I watched polymarket like a hawk for weeks before the attack and am incredibly familiar with the numbers. Fact is, there were no indications on Polymarket that an attack was happening that morning. The chances of an attack was like 10 percent if I remember correctly.

1. they can get away with it, or 2. they don't agree with it.

DHH does a great job of clarifying this during his podcast with Lex Friedman. The "why" is immediately clear and one can decide for themselves if it's what they're looking for. I have not yet seen a "why" for Zig.

1. Maps crashes almost every ride on Car Play (this used to happen a lot back in 2023 and was fixed for majority of 2024. Seems like it regressed again)

2. Trying to expand reviews on Google Maps expands the wrong review (100% reproducible, not an edge case)

3. Firebase Auth has terrible reliability when it comes to SMS delivery and fail rate of like 5-10%.

4. Gmail keeps opening links with the wrong account (Click on Google meet link from an email in account number 2, as in .../u/2/... . Link opens with account 0 and now you gotta switch accounts again).

5. Gemini is famously unreliable and produces wrong results for seemingly simple queries.

And many more I can't recall on top of my head but surely exist.

Dreamweaver was how I learned MySQL back when I was 12-13 and got into web development. I don't remember how I came across it but somehow things, the way they were laid out at the time, made sense to me. This would ripple into a career that's making my living 16 years later.

I remember downloading XAMPP and installing it to get a local MySQL and PhpMyAdmin server. A few clicks in Dreamweaver later, I somehow had a connection file that would connect to my local MySQL server. I started playing around with it and creating different forms. The MySQL query generators on Dreamweaver were so simple that you could, with a few clicks, have a full on CRM.

I ended up coding a test score reporting system for my middle school class and the school somehow trusted me and started using it. This made me possibly the most hated person in the school because parents could now see their kids scores every day and there was no more "Oh the teacher hasn't given out the scores yet." But it was good times, and I was so excited about it.

Many years later, I now run a startup and have transitioned into using Node.js but MySQL is still my bread and butter. I still remember that day when I discovered the SELECT query.

1. Upgrade protocol to include protections for well known cold wallets held by exchanges (ex: API call has to be made to the exchange's security endpoint to validate each transaction out of the wallet. Exchange staff would need to manually allowlist large transactions before they are transmitted).

2. Decentralized voting on reversal of transactions (90-95%+ vote needed to reverse to avoid 51% attacks)

What is going on at the Pixel team??? They have probably single handedly cost Google millions of dollars

1.66M Unique visitors

24TB served

However, I do understand in their world, 24TB is chump change