Originally published at: https://tidbits.com/2019/10/21/six-reasons-why-ios-13-and-catalina-are-so-buggy/
By most accounts, the release of iOS 13 and macOS 10.15 Catalina have been troubled, with numerous significant bugs making it past Apple’s internal testing and the public beta phase. Former Apple engineer David Shayer explains the underlying reasons these releases have had so many problems.
I have never ever seen such a buggy macOS before. Most of the bugs I reported were fixed. But I didn’t even get a notification about the bug fix.
And it doesn’t look like it’s going to get better. 15.1b1 foobared dragging a file on the dock. That was fixed in b2. But now the menus get foobared.
So is the fact that Mail in iOS 13 no longer displays the contents of mime-attachments in mailing list email digests a regression, or “Not a Regression”?
I really wish Apple would adopte a longer OS Update strategy say 2 years rather than 1. Sierra/High Sierra (and the Desktop/Documents/Photos cloud trap people fall into - Hey Ben My mac is crawling ! help ! )Mojave - Catalina has made for a fast paced modern update
path (not to mention the phones and now the branch of iPad and watch) but it hardly allows for a user to breathe. For the first time all but one of MY machines need upgrading to meet OS standards (a bottom of the barrel Air is what i run Catalina on right now). I see a lot of issues especially with Apps not thoroughly quitting -Finder issues! Time Machine problems (which has prevented me from loading a backup of a library that got hosed by a third party vendor’s crappy programming) Photos and Music crashing. Really stupid issues could have been tested before released. I do get a boost in work when Apple dumps this crap on users who are are (imho) Bleeding edge wanna bees… but i’d rather deal with other issues. Oh and I had to delete Swift completely in Catalina because it would not download at all. I think i have to Nuke and Repave to get it to work because it isn’t happening at all.
-> my motto -> You can’t download patience.
4 Likes
There’s no way of knowing, but if you report it as a bug or provide feedback, at least it will get recorded.
1 Like
Fascinating article.
Exactly this. Why does Apple have to release a new OS every year? Who would not purchase a new Mac if they needed it because the OS is 11 months old? Especially since Apple hasn’t charged for OS upgrades in a while. I would much rather have the OS upgraded every 2 or 3 years, but be more polished.
I’m also in this camp. There is no reason macOS needs a ‘major’ update every year (apart from marketing maybe).
So here’s a thought. Arguably, some of the problem here is the effort of developing the core of the operating system and a vast suite of bundled apps and releasing them all at the same moment.
What if, going forward, Apple took a page from ChromeOS and had the core of macOS update itself quietly over time without drawing attention to itself (and hopefully without impacting users in a big way now that 32-bit apps are off the table).
Then, for apps like Safari, Photos, Mail, Messages, Calendar, Contacts, Reminders, Notes, and so on, Apple could still do a splashy release that would showcase new features that users care about. But without the core macOS stuff to develop and test at the same time, the overall project might be a lot more manageable.
Even the splashy app release wouldn’t necessarily have to be all at once in September—Apple could bundle a few apps together into releases that would happen at different times of year in conjunction with the hardware devices that best show off those apps and features.
3 Likes
As a late adopter of everything, I’m not impacted as much, but Apple is impacted. I won’t even buy hardware anymore until it and the software have been around at least 6 months.
I’m so glad I got out of the coding business before the hurry up attitude took over. The stress would have killed me.
For several years I’ve been helping out Apple via the AppleSeed program. Sometimes they reply to bug reports, sometimes not. Sometimes bugs are fixed at a decent pace, sometimes not until the next major release. At the moment, I’m involved with an unsettled iOS bug report that includes documentation and a workaround. The general situation is described here at Apple’s Discussions forum:
Q: Unable to rearrange app icons in ios 13
But Apple’s response to my bug report has been, to put it gently, nonsensical. This has lead me to consider what’s going on at Apple, and likely a lot of other coding establishments. Here are my current conclusions:
-
Apple is indeed in a state of triage. The code clinic has to put less urgent bugs on standby.
-
The volume of complex code has, as we expected decades ago, forced coding-by-committee. We know what that’s means. Human communication, reason, logic and emotional stability breakdown in proportion to the complexity of the task at hand.
-
Object-oriented development means the use of ‘established’ code that’s commonly just as prone to bugs as any other. Fixing object code isn’t on anyone’s front burner. Old code lumbers on, incapable of addressing new features, new security concerns, etc.
-
There are mounting pressures of Time and associated Money. In an age when Quality Capitalism has been overthrown by Quick and Dirty Capitalism (to put it mildly), priorities have shifted away from The Art of Coding toward: Good enough; Skip the code commenting; Feed the stockholders stat; Progress, not perfection; Skip the code verification; Skip the functionality verification; Exploitation without explication! Or as I like to simply put it: Short-term thinking leads to long-term disaster. Pick your synonym. It’s a Spirit of the Age.
-
Modern coding tools are dinosaurian. Improvements in rapid coding have not adequately addressed the ongoing failures of coding fundamentals. Consider the term Memory Buffer and the frequent, constant, voluminous ways in which it is exploited by hackers, crackers, black hats, script kiddies. Pick your descriptor. IMHO (In My Heretical Opinion) everything C-based must go. It’s zombie coding. Let’s cut off its head and move on to the bright and promising young things, such as Swift and Rust. Let’s focus on developing so-called ‘Artificial Intelligence’ that helps us establish actual Human Intelligence in coding.
Summary: Apple and the rest of the world’s coding community are caught in a conflict between the forces of Expectation versus Realization.
1 Like
That’s a very interesting take on it from the developer’s perspective. Thanks, Derek.
I have to say I was somewhat startled by your comment on object-oriented coding. I believe in pretty much every seminar I have ever attended where the topic of OO coding came up, the concept was introduced by mentioning that OO became necessary because otherwise code would eventually no longer have been maintainable ( and/or scalable/extensible).
Yet here we are, ~40 years later, learning that our OO code is no longer maintainable either. So maybe it’s not the type of code after all. Maybe it’s the coding environment? And as you indicate that’s both the tools and the economic environment.
I hope you caught my recent edits.
I have a biological systems perspective I find useful in understanding human systems. We humans demand simplicity amidst unfathomable natural complexity. But here we are creating our own unfathomable human complexity while attempting to force our demand for simplicity. Expectation versus Realization.
I haven’t used Rust, but I’m pretty conversant in Swift. I agree it’s a big step in the right direction. Swift, along with ARC, makes it hard or impossible to make a number of basic programming mistakes.
1 Like
lowengard I really wish Apple would adopte a longer OS Update strategy say 2 years rather than 1.
I think this is unlikely. Apple has a yearly product update cycle, and OS updates are part of that. Apple gets free publicity, and sells more toys, based on flashy new features. Fewer updates means fewer sales, and lower stock price.
2 Likes
Note though that for the Mac that’s not true in general. The MBP might get an annual update. Most other Macs don’t get that level of attention these days.
That’s absolutely true on the Mac side (heck, most Mac hardware changes barely get a press release these days), but all of Apple’s operating systems are so inter-related at this point that it may be tricky to decouple them enough to ship at different times.
Although I do agree with most everything said in the article, I do take exception to the above. My observations are that all of the significant bugs being discussed now were well known to testers prior to release. I think there may have been a small delay in the original release date, but Apple appears to lay out an iron-clad schedule far ahead of time that is rarely violated. If there are bugs, they get shoved into the next update, as long as they aren’t known to be catastrophic.
There have been a handful of cases of near catastrophic releases, but most of these involved a last minute change that was never provided to testers before release. I don’t feel that was the case in this instance.
I watch a new release break something I use. In a subsequent release they fix that problem but something else is broken. In the next release they fix that and …
It appeared to me people are not testing the whole application instead they are only testing the code they changed and missing the code they broke in the process. They need to test the whole application before shipping it not just the parts they think they touched/impacted.
Without likely sounding like a captain obvious doofus, is there also a fundamental lack of engineering staff for all the platforms they’re trying to maintain and develop for?
From previous stuff I’ve read, there’s two issues.
Firstly, are there enough quality engineers to employ or is there still a mass shortage in the industry, thus making it an ever-increasing battle to acquire, and worse, actually hold onto staff.
Secondly, aren’t Apple as a tech company supposed to be renowned for not employing enough engineering staff too (small teams, for example), so the sheer lack of people in the fight makes maintaining and gaining ground in the ever increasing battle to improve software and ever get around to squashing these “not a regression” bugs ever unlikely. I mean, do they even consider having teams that deal with these longstanding bugs, or is that too much of a financial cost pipe dream for us to expect?
All I can say as a customer is it certainly doesn’t sound at all good, knowing these “Not a Regression” things more often than not are never fixed.
From Scientific American June 2015: Why the Upgrade Cycle Will Never End
“Eventually these companies have no choice but to add features that nobody asked for. Meanwhile bloated, overwhelming technology has a very real emotional effect on us; we feel like idiots when we can’t master it. Then, as the software becomes increasingly weighed down with features, the interface must be redesigned to accommodate them all. (Such a redesign is then, of course, marketed as a new feature.) And each time you lose a few days of productivity as you learn the new layout.”
and Douglas Adams in 1984:
“it is very easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all. In other words - and this is the rock solid principle on which the whole of the Corporation’s Galaxy-wide success is founded - their fundamental design flaws are completely hidden by their superficial design flaws”