O-stevns

It becoming "very good" now is the problem, because it's not backward compatible. So for us developers who are still lingering around supporting those poor iOS 15 (soon 17 thankfully) users, you are stuck with UI acting anywhere between horrendous or not not working at all, to being slightly broken, to working as intended.

It didn't have to be like that though... It hasn't always been this bad. Personally I think they've been ruining Swift since version 4.

It's particularly terrible in SwiftUI context nowadays but you can also make it chuck on something as simple as a .map(...)

No need to defend yourself, I share this sentiment as well. If I'm going to spend time writing and reading a lot of code in a new learning language, I want my previous knowledge to be somewhat reusable.

For this reason I was able to get into Odin as opposed to Zig because of some similarities with Swift Syntax as well how easy it is to parse.

The less I need to rewire my brain to use xyz language, the greater the chance of me getting into it.

If my life depended on it, I could get over such a shallow reason to dismiss a language but fortunately it doesn't and that's why I write Swift rather than Rust.

As we dive further and further into them being dependent on said devices to be part of modern society... Yes we do.

It's the niche that wants open and flexible devices and the ability to customize everything.

Let's not ruin iOS by trying to make it Android.

I say that both as an iOS developer and Android user.

That's a lot of code for a PR, though i should admit I have made PR's being half that size myself.

Personally I think it's difficult to address these kinds of PR's but I also think that git is terrible at providing solutions to this problem.

The concept of stacked PR's are fine up to the point where you need to make changes throughout all yours branches, then it becomes a mess. If you (like me) might have a tendency to rewrite your solution several times before ending up with the final result, then having to split this into several PR's does not help anyone. The first PR will likely be outdated the moment I begin working on the next.

Open source is also more difficult in this case because contrary to working for a company with a schedule, deadlines etc... you can't (well you shouldn't) rush a review when it's on your own time. As such PR's can sit for weeks or months without being addressed. When you eventually need to reply to comments about how, why etc.. you have forgotten most of it and needs to read the code yourself to re-claim the reasoning. At that time it might be easier to re-read a 9000 lines PR over time rather than reading 5-10 PR's with maybe meaningful descriptions and outcome where the implementation changes every time.

Also, if it's from a new contributor, I wouldn't accept such a PR, vibe coded or not.

Odin has no primary use case, it just happens that a lot of the members in the community have made or are interested in game making

I got the iPhone 13 mini as a work phone for the sole reason of it being the smallest iPhone at the time. I too dislike the phone landscape nowadays with their ridiculous and ever increasing sizes.

My personal device is a Motorola Razr 50 Ultra, which I got because while it's huge when flipped, it's portable enough when it's closed. I can have it in my pocket without it falling out.. without it being annoying while i put on shoes etc...

I use its cover screen a fair amount too, to avoid having to flip it open, which is also why I got the ultra rather than the slightly smaller version.

It's not my hill to die on but I will say use wireless in-ear monitors myself to avoid ever having to deal with adapters because... Adapters are terrible, often wonky in one way or another, incredibly inconvenient for anything but having them lie on a desk. It's also something you easily forget to carry around, or you lose or break because of shoddy build quality.

It's a bad alternative to something that wasn't a problem except it took up space and people still talk about it because there's still a need for something better

Not loving this trend that we are starting to doubt whether everything is AI generated.

Ahoy is a known Youtuber who has made content for 14 years. His voice is definitely not AI generated.

"Study smarter" or just make it easier to cheat... you be the judge of that. Maybe we should just go back to doing tests and exams on paper? What was the benefit of going digital with this again?

> a blind person can't see when an animation has finished. They expect that menu to be available once they've triggered it. However, seeing people see the dropdown appearing and then go to use it once it's ready.

A blind person can and should get cues from their assistive technologies that an item is is being loaded and is shown, either using announcements or aria tags that provide this information to the user.

While its fine to expect that something is available immediately, that's rarely a realistic expectation, whether you're blind or not.

The _mostly_ same behavior is what caused the problem though :P I'm curious, did these solutions come to pass because you had to make adjustments based on actual user feedback or was it just a developer trying to think ahead? I'm questioning whether forcing the user to tab to get to the menu item is a hindrance at all or whether the animation was a problem.

Maybe the former could have been solved using ARIA tags or maybe it would require bigger changes to the component itself. Accessibility is a roller-coaster for all these reasons alone.

Of course there are edge cases, I work with accessibility too, for an app in the public sector where WCAG rules are no joke, so I know this as well but even so, we don't build custom accessibility UI for our users. We (try to) build the UI with accessibility in mind so it's scalable, can be used and navigate properly by voice over and keyboard.

On mobile it's not perfect either but in general you do have features to change stuff like. focus, grouping of elements, how the keyboard navigate the view stack, how to access a button through custom actions and like you mention, change the tab index programmatically.

Even so, not everything can be fixed or handled through standard accessibility means and as such hacks will inevitably make it into the products.

I get what you're saying but I still think that making things accessible and designing with common accessibility in mind should be default and as such it has to be thought about when designing and developing from the get go. Having to create custom interfaces to fulfill a specific need might be a good fit for some things but not when developing apps and websites unless you're targeting that user-group specifically.