makecheck

The overwhelmingly most common one I see is cyclists not stopping at STOP signs (or worse, red lights), and the real crazy ones appear to not even slow down.

It is illegal to run a stop sign, and it is certainly possible a car (crossways or turning) will arrive first and have right of way. So a car is turning, why should it expect a cyclist to come plowing through on a whim?

Again: it is ILLEGAL for cyclists to run stop signs. You have to stop, just like a car. (And in case you think it’s no big deal, I see plenty of cars that aren’t too good at stopping either. You want to hit them?)

And it hasn’t evolved with cloud/sandboxing/magic-paths/whatever. Like today on the Mac I used the popup directory path to try to navigate to the parent directory (since it showed it to me, and it was selectable) and it couldn’t; it just threw me to my home folder as if that was my request. I can only assume it was some weird cloud thing but when path navigation itself is a question mark we have problems.

Unfortunately impossible to read on my mini screen…

Seems like the viewport is fixed so zoom is disallowed. (Sites should never do this.)

This is also one of the many cases of Apple not following their own guidelines. They suggested that Touch Bar items should act statically like keyboard keys and not be used to display status, etc. (In reality, plenty were abused for that, I guess the allure of a dynamic colorful display was too great.)

So in this case, all they had to do was make it key-like and it wouldn’t have had any of the features that could trigger this problem.

Brings back memories; the Apple Platinum look appeared around the time when 90% of the UI was black-and-white or at least boring so it really seemed to instantly transform the Mac into a professional-looking tool.

I can’t wait until they release it (oh wait, they did, decades ago; now we just have — whatever — the Mac is now).

A really cool example of good debugging especially without the source.

Also a good reminder that the slow thing may not be what you think and if you aren’t profiling you don’t really know what’s going on.

And an even better reminder that typical “metrics” trying to assess developer value can be pretty meaningless. This is the kind of code change that would drastically improve everything but show up as a blip on some of the pathetic measurements out there, e.g. hardly any lines of code or whatever.

Proper up-front never occurred because Apple refuses to implement a simple free-trial-period mechanism. And it is impossible to filter store searches in a way that tells you which apps would behave roughly in that way (therefore anything with IAP I just assume must be a gambling/gem-bags/garbage model).

The only way to really deter this stuff is to make it cost the sender something per spam. Bonus points if the user can feed back into the system to discourage truly unpopular notifications.

Like any organization, things have to be reliable and some open-source doesn’t really have the support model figured out.

And if cost is an issue, that is more an indictment of how schools are funded: if there doesn’t seem to be room in the budget for buying software and/or support, why is that the budget?

“…in that order” is the full quote, and omitting that from the title really changes the point.

Ultimately if you don’t work on the first two, it isn’t enough to have the third. Persuasion is really important because you’re usually not working in a vacuum.

Lots of great and specific points in these threads, many of which I have personally seen.

SwiftUI was really promising at first, and even fun to use (nothing like ripping out entire UI files or pages of code). Yet, issues were almost immediately apparent.

A major concern is that it seems to take Apple a really long time to address even basic issues, e.g. years go by and things still broken since day 1 are there, while other things are randomly introduced. And of course, “Feedbacks” have the usual dice-roll effect: will you even get a response, much less see any indication that the reported bug will ever be fixed? (Or will Apple just wait 2 years, close your bug as “probably fixed in this OS update, please confirm”, and repeat the whole thing?)

And the thing is, this is not hard to believe. If you auto-complete in SwiftUI (what else can you do, there is rarely good documentation?), some of the APIs are truly scary: levels of complexity and variation that really make me wonder if they can truly test, much less support, every variation of every API. I would strongly argue that some things just have way too many options instead of a handful of clear starting points.

SwiftUI also occasionally changes behaviors (e.g. subtle or gross layout differences). Worse, it is easy for Apple to not call any of these changes “breaking” because apparently you are just supposed to let SwiftUI figure out what is needed in any situation. Except that kind of “trust us, we’ll come up with something” approach is not great for writing stable production software.

The auto-generated hierarchies can do truly weird things. For example I realized at one point that an “auto-saved” window layout auto-generated preference names based not on a simple string but the entire SwiftUI view hierarchy, which was huge and indecipherable and of course would become a different value if any part of the window or view hierarchy was modified. So I discovered I had dozens of preference settings scattered throughout my defaults, 99% of which were completely obsolete because they were based on previous incarnations of the view I was developing, and they all had names that were almost impossible to type (so how do I delete them while preserving the rest?). What do you even do with that?

Yet another major concern is that SwiftUI is very dependent on Combine which is not necessarily the future given other developments in the Swift language. So what if they just decide to, say, deprecate Combine and move further toward actors and async APIs? How much of SwiftUI might just fundamentally change in, say, WWDC this year, completely invalidating years of effort people have put into it?

Not limited to games, either; “pre-animation” makes regular software feel sluggish too. Having actions taken immediately is critical.

Their need to develop so many cross-platform apps should have been more than enough justification to do an outstanding job of Catalyst/SwiftUI/whatever-is-recommended. They could have iterated internally to get those really good at handling every last important detail and make it a great experience.

Instead, they did things like: just forget about proper keyboard support in a lot of places, have really awful performance at times, weird gaps where entire UI elements were just not there, etc. And that’s before even getting into the apps, where they were clearly doing things lazily like leaving iPhone elements in place exactly as they were no matter how awful an experience that was on the Mac.

Almost every app they have now should not have been released in its current state, much less left more-or-less-still-broken 1-2 years later! It is certainly possible to embark on major updates like this but you do that internally, only releasing something when it is not full of obvious flaws (and certainly not worse than some previous version it replaces).

Well whether you add “site:.edu” or not, Google still does the thing where they just spit out a pile of extra “matches” that don’t contain your search phrase AT ALL. Just thrown into the list, as if they have any business being there (oh wait, they do have business: Google’s business).

Frankly, if it’s not reliable as a tool, it has no real value and I can’t believe it has come to this. Imagine if every time you ran `ls` in a shell with a glob pattern, it just decided to sort of “add in” a few other files loosely based on your query (or heck, files that aren’t based on it at all)? Oh, now imagine if `rm` did that.

Sadly this happens with lots of search tools now. Why the heck is the default state on a new Mac to funnel what you type to everything, e.g. I searched for “Chrome” and hit Return and the FIRST thing it did was throw me into the App Store and call up some not-even-a-web-browser scam app with Chrome in its name, instead of selecting the Chrome already installed on my computer and opening it? More and more it seems that you have to turn off all kinds of poor defaults to put tools into a useful state, or there is simply no way to get them there at all.

What seems to be lost in these “redesigns” is the why: why are you doing it? If there isn’t a list of benefits long enough to justify the cost and possible risk, well, that’s a problem.

There’s also a tendency for companies to be super proud of what they’ve done so they neglect methods like A/B testing and instead just bet the farm on their great new design. After all, it cost a lot of money and looks cool to the decision-makers so what could go wrong? Um, maybe before you throw out all of your packaging everywhere and double-down, you could tone it down a little and try it out in a few small markets first? Then watch and see if sales are going up or down? Then think about going further?

And at this point there is also a tendency to ignore history. This is far from the first big failed redesign; what is going on that no one is looking at past failures (plenty of which have had high costs to other brands too), and imagining that there might be a downside?