Why iOS 13 and Catalina Are So Buggy (tidbits.com) 72
David Shayer, who worked as a software engineer at Apple for 18 years across iPod, the Apple Watch, and Apple's bug-tracking system Radar, among other projects, looks at the current iOS and macOS releases and tries to work out why they are so buggy. He writes: 1. Overloaded Feature Lists Lead to Schedule Chicken: Apple is aggressive about including significant features in upcoming products. Tight schedules and ambitious feature sets mean software engineers and quality assurance (QA) engineers routinely work nights and weekends as deadlines approach. Inevitably some features are postponed for a future release, as we saw with iCloud Drive Folder Sharing. In a well-run project, features that are lagging behind are cut early, so engineers can devote their time to polishing the features that will actually ship. But sometimes managers play "schedule chicken" since no one wants to admit in the departmental meeting that their part of the project is behind. Instead, they hope someone else working on another aspect of that feature is running even later, so they reap the benefit of the feature being delayed without taking the hit of being the one who delayed it. But if no one blinks, engineers continue to work on a feature that can't possibly be completed in time and that eventually gets pushed off to a future release.
2. Crash Reports Don't Identify Non-Crashing Bugs: If you have reporting turned on (which I recommend), Apple's built-in crash reporter automatically reports application crashes, and even kernel crashes, back to the company. A crash report includes a lot of data. Especially useful is the stack trace, which shows exactly where the code crashed, and more importantly, how it got to that point. A stack trace often enables an engineer to track down the crash and fix it. Crash reports are uniquely identified by the stack trace. The same stack trace on multiple crash reports means all those users are seeing the same crash. The crash reporter backend sorts crash reports by matching the stack traces, and those that occur most often get the highest priority. Apple takes crash reports seriously and tries hard to fix them. As a result, Apple software crashes a lot less than it used to. Unfortunately, the crash reporter can't catch non-crashing bugs. It's blind to the photos that never upload to iCloud, the contact card that just won't sync from my Mac to my iPhone, the Time Capsule backups that get corrupted and have to be restarted every few months, and the setup app on my new iPhone 11 that got caught in a loop repeatedly asking me to sign in to my iCloud account, until I had to call Apple support. (These are all real problems I've experienced.) Shayer has offered several more possible explanations in the original post.
2. Crash Reports Don't Identify Non-Crashing Bugs: If you have reporting turned on (which I recommend), Apple's built-in crash reporter automatically reports application crashes, and even kernel crashes, back to the company. A crash report includes a lot of data. Especially useful is the stack trace, which shows exactly where the code crashed, and more importantly, how it got to that point. A stack trace often enables an engineer to track down the crash and fix it. Crash reports are uniquely identified by the stack trace. The same stack trace on multiple crash reports means all those users are seeing the same crash. The crash reporter backend sorts crash reports by matching the stack traces, and those that occur most often get the highest priority. Apple takes crash reports seriously and tries hard to fix them. As a result, Apple software crashes a lot less than it used to. Unfortunately, the crash reporter can't catch non-crashing bugs. It's blind to the photos that never upload to iCloud, the contact card that just won't sync from my Mac to my iPhone, the Time Capsule backups that get corrupted and have to be restarted every few months, and the setup app on my new iPhone 11 that got caught in a loop repeatedly asking me to sign in to my iCloud account, until I had to call Apple support. (These are all real problems I've experienced.) Shayer has offered several more possible explanations in the original post.
Apple products are indeed so buggy (Score:4, Interesting)
Re: (Score:2)
Apple never was really a good commercial platform for development. Microsoft has been in the commercial market for their core business and they have a set of well defined tools to do the boring things. Being boring they are usually good at their job. That said Apple Bugs are less apparent for users using the devices as a consumer electronics, and Microsoft seems to be more buggy.
Re: (Score:1)
Apple never was really a good commercial platform for development.
I disagree.
The Apple II was a great machine that allowed all kinds of people to develop on it using basic or assembly. The early Macintosh had its own development capabilities as well proven by the amount of extensions, control panels, and other user programs for it. When the system software began to bloat, I'd say around 8.6, is when bugs during user experience really started to pop up. Of course, Jobs made a bundle selling NeXT to Apple with the added benefit of having his old job back, so it doesn't su
Re: (Score:2)
The Apple II was a consumer devise and not really commercial ready. For the time big issues like 80 column displays were a big deal for businesses. Which is why in general IBM XT came Popular in Business.
OS X had a a Unix Core, which actually made it much better in development over Windows and most other modern systems (besides Linux) at the time. It came with a common set of development tools to allow coding. Making GUI Apps was flaky, but real programs that did work, was very easy.
Re: (Score:2)
The Apple II had much wider variety of Languages: C, Lisp, Forth, UCSD Pascal, Logo - those I have used and remember from my mind, but here you find more: http://apple2.org.za/gswv/a2zi... [apple2.org.za]
Remember the Finder and its spatial file manager design? Why did that disappear - because Jobs thought one window, one folder was too difficult to use.
No idea what you mean with that. All Finders could open multiple windows.
I was never impressed by OS X. It was all gloss.
No, it is Unix. Perhaps you should open the termina
Re: (Score:1)
Re: (Score:1)
Re:Apple products are indeed so buggy (Score:5, Informative)
Being old enough to remember what a debacle Microsoft made of Exchange calendaring back when the US lengthened daylight saving time - Microsoft released something like 40 patches which still left everyone with a broken enterprise calendaring system for three weeks - I'm not sure Apple has ever achieved quite that level of perceived incompetence.
Yeah, time management is hard - but still.
Re: (Score:1)
Re:Apple products are indeed so buggy (Score:4, Informative)
They're still at it. Just did an Exchange 2016 install as part of a migration to a hybrid 2016/O365 environment.
Ran into 3 poorly documented bugs that honestly should have been fixed by 2016 CU14. 32 connection limit per user for MAPI, an authentication issue with backlink checking that is fixed with a KB article that applies to 2003 server, and the autodiscover app pool needing manual recycling to avoid stale cached mailbox location data.
I'm mostly convinced MS has let on-premise Exchange rot because they want to drive business to O365.
But I also think that software generally has been getting worse. Everything is beta-quality or worse. Bugs don't get fixed and vendors push "workarounds" instead.
It's probably some combination of reasons -- software is so complex they can't easily find the bugs, testing is too expensive and slows release cycles, not enough quality developers (or they're too expensive, your pick), and some sense that people won't change vendors anyway (or have no viable alternatives), so sticking customers with shitty quality has no cost to the vendor. Plus in many cases the bugs affect an end user so far down the accountability chain there's no feedback possible.
Re:Apple products are indeed so buggy (Score:5, Interesting)
I worked for apple about 7-8 years ago. They have a real culture problem of secrecy and burying problems. They had a whole group of people that literally spun problems as features or worked very very hard at blackmailing press people to not report things. It's in their DNA to hide problems. They HATE bad press and will do anything to keep it quiet, more so than any company I have ever worked for.
I strongly believe this has led to buggy OS releases the last 5-7 years. The engineers either feel emboldened by the ability to hide these things or are insulated from them so much that they truly don't know they exist.
Re: (Score:2)
Apple products have always been that way for me. In my experience all Apple products I have ever tried to used could be summed up as:
It just doesn't work!
I thought it was just me.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Buggy and Overpriced (Score:2)
Re: (Score:1)
Doing Data Capture for Catalina as I write this (Score:3)
Interesting. Catalina needed a lot of disk space (and on a 128GB MacBook Air this was a bit of a challenge).
I have a problem where the system will not connect properly to free WiFi - I just figured out that if I start in Safe Mode, connect to the WiFi there aren't any problems and then reboot in Normal Mode the WiFi shows up and all is well. Not great as I just came back from two business trips with a buggy WiFi connection (I ended up taking along a Chromebook for basic email connectivity on the second one). Apple support told me that Catalina is a lot more buggy than anything they've seen before with everybody having different bugs (ie they haven't seen my problem before).
I did the upgrade first on a Mac Mini, absolutely no problems.
When I RFTA, I was disappointed to see that they don't do automated testing. Yes it's a pain to setup but it really provides you with a tool for validating basic features and operations that *shouldn't* have been affected by updates - I would consider the issue I'm dealing with right now (I'm in a public library testing how their free WiFi works) to be something that should have been caught before release.
Re: (Score:2)
I recently did the Catalina update.
As far as I can tell so far, the only changes are that the desktop image changed, and Safari got a little bit more broken.
Specifically, CNN often has everything on the right side flickering at about 10Hz, and mousover/tooltips somehow get stuck and stay on the screen as their own thing, durably and won't go away.
Of course, this is my fault, because I use an eGPU on my Macbook Pro. It's not even a good GPU because Apple won't let nVidia sign drivers for GPUs on MacOS. Which
It's buggy because it's running new code (Score:3)
Catalina is the first release to run all-64 bit code. They got rid of all the 32-bit code, which means there are lots of subsystems that are being used for the first time.
New code == buggy code.
For example, I"m positive a bunch of the IMAP mail issues are 32/64 bit impedance problems...especially if a lot of the code is all-new for 64-bit. The old protocols are sort of fucked up, and I'm sure that when they were redone a lot of the hacky workarounds got refactored away by well-meaning but naive devs.
"new code == buggy code" should be !TRUE (Score:2)
I refuse to accept that new code is buggy as an axiom.
If you have good planning, code development and testing processes, you will be able to identify deficiencies as well as fix them without missing the target release date. When I read things like in TFA about "Schedule Chicken", that just saddens and angers me. This is not what I expect from Apple (nor any other software company). Apple's been developing Mac software for more than 35 years now (the first one was released in 1984); they should have the d
Re: (Score:2)
They had this type of problem before— it is something they are re-learning, likely due to the code change. Is it a Cisco network by any chance?
Re: (Score:2)
Unfortunately it IS true. Any system that has to work with other system will end up developing co-depency on eachother's quirks. Sometimes due to hacks, but mosly just due to bugs never discovered because they were not excercised by the old code. Replacing software parts with new code will always produce system bugs, ESPECIALLY if the new code is cleaner and less bug free than the old one, because that is what causes the depending quirks and bugs in the other software to show.
When you are finished squashin
Re: (Score:2)
Your code is only as good as your test cases. The internet is substantially bigger than your test cases, by definition.
Re: "new code == buggy code" should be !TRUE (Score:2)
I know a bunch of ex-Apple people. From what I've heard it's mostly all "developers" who were in diapers when the iMac came out because the woke culture demanded that people with mature opinions bend to their silliness and at some point it's less frustrating to go work for a smaller company that turns a profit or dies (so that incentives align with reality)
To be sure there are a few wizards there who get left alone to handle low-level stuff, but I suspect they're also content to be disagreeable.
Maybe someb
Re: (Score:3)
This brings up the question, of does getting rid of 32bit code offer any advantage? Heck most of my programs would run fine on a 16 computer, as 640k is indeed enough. A lot of components don't need to deal with big numbers, and we really don't need to handle all these extra unused 0 bits (or 1's if you have negative number) that is making every process take twice as much RAM and saved data is taking twice as much disk.
Re:It's buggy because it's running new code (Score:5, Informative)
> Don't know where you got that idea that 64bit code occupies twice as much RAM.
Depends on how many pointers the app uses. Pointers went from 4 bytes to 8 b. Plus pointers may have to be 8 byte aligned depending on the CPU.
Reports from the field vary between 20% to 60% bigger from what I've seen. It would be good to have a white paper on this but sadly no one has the time to do the research.
See this SO: Size of 64-bit dll 50% larger than 32-bit [stackoverflow.com] for more details.
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
There are a lot of pointers in memory in modern object-oriented operating systems. Every object is made up of other objects that point to yet other objects etcetera. The UI and much of the OS structures are probably about 80% pointers and 20% data.
Obviously things like pictures, fonts and text are not going to take more space. But that window containing widgets, views, scroll bars (each containing more icons, methods, etc) is just one really big mess of lots of pointers. Same for the "application delegate",
Re: (Score:2)
I've been running a full 64bit linux desktop for at least 7 years, and I don't think I never had any problems related to it. On windows with a lot of legacy and abandonware it is different, but if you have full control of your hardware and software blaming 64bit is wrong or utter incompetency. Don'
Re: (Score:1)
Perhaps they haven't been taking advantage of language features that simplify the transition to 64 bits, or they over-optimized for 32 bits and now the inherently buggy logic is revealing itself.
I also wonder if their software development people have been churning during all this time. A lot of lost institutional knowledge can bring about bugs when platforms are switched.
Re: (Score:2)
macOS has been 64bit for a long time. iOS was 32bit and then new CPUs lets them go 64bit.
The many, many system libraries could just reasonably moved to 64bits.
but.... watchOS is 32bit. Can't just check a box and be assured that everything is portable.
32bit ain't gone for them yet. I'm trying to build a cross-platform app and this whole
thing with CGFloat vs. Double vs. Float is driving me nuts. Some calls want CGFloat,
some don't. Swift won't let you get away with that and do it on the fly, transperently.
Lots
Re: (Score:1)
It's not that easy. Entire libraries disappeared (like Carbon, for example) because Apple decided it was old technology not worth keeping alive. But lots of stuff still used some parts of those old libraries and now had to be rewritten.
This is certainly a problem for a lot of app developers (it took me a fair bit of time to rewrite my old brick game Colibricks which was still using the Carbon libraries), but I imagine a lot of OS system components that hadn't been updated for a while had the same sort of pr
Re: (Score:1)
What year was that "Catalina" realeased? 2005?
Cook effect? (Score:2)
Reality Distortion Field (Score:2)
I was surprised the reality distortion field lasted more than a pico-second after Jobs died... but obviously it's got to dissipate sometime now that he's gone. There's nothing sustaining it.
Also, he was the one that would ditch a desired feature if it wasn't rock solid, his one contribution to Apple tech besides the California Global Design, and probably a good one. Jobs was an asshole, but he understood what ordinary people like about gadgets beyond "features".
More of a Woz Guy (Score:2)
I used to despise Jobs in contrast to the Woz side of the universe... but you have to give him some credit for making Apple, Apple, in the sexy-tech sense.
regarding object oriented programming (Score:1)
what's your point?
Re: (Score:2)
Sounds like normal Software development problems. (Score:5, Insightful)
This is an unfortunate problem with large software development builds.
Too many features, not enough resources, and general fear of under-performing.
Normally when developing software. Getting the proof of concept while the most challenging part is also the shortest to develop in terms of time. The rest of the development process is polish, reliability, integration and security. This is extremely frustrating to project managers, because they see a working product but they see the last 10% of the build taking 90% of the time. The developers during this phase is actually writing a lot less code, but they are doing a lot of reading code, testing and fixing what they think can be fixed. It is just slow and sluggish part of the process. Most Managers are not in an environment where they can explain this phase well, so they try to do political tricks to explain their status, and meet deadlines.
Re: (Score:2)
The developers during this phase is actually writing a lot less code, but they are doing a lot of reading code, testing and fixing what they think can be fixed. It is just slow and sluggish part of the process.
Yeah, there's nothing like having to justify why you fixed no bugs and added no new features, and in fact didn't touch any of the actual code base since the last meeting, since all you did was write new unit tests.
As the "fixed no bugs" might suggest, writing these tests didn't unveil any broken behavior, but it did provide a baseline to know how things actually work to get ready for future changes, even though in some cases I'm not sure the tested behavior is in fact the right behavior...
But if you don't h
Re: (Score:1)
This is an unfortunate problem with large software development builds.
Huge Apple builds you mean. Linux kernel is a huge build, one of the hugest in the known universe, and it is not buggy like things Apple builds. Debian build is an even huger build than anything coming out of Apple. Likewise. Oh yeah, if you look at every package Debian ships, there are plenty of bugs, but its not rotten through and through, far from it.
No surprise at all... (Score:2)
Seriously? (Score:1)
Re: Seriously? (Score:2)
good grief itunes.
I wasnt going to bother commenting on this story. But you went and reminded me of iTunes.
That POS put me off Mac for life.
Re: (Score:2)
apple has never been good at writing software. Never.
Its either itunes bad or apple maps bad.
True, for a software company they were pretty bad at it. Their main saving grace the last 20 years is that being a bad software developer among software companies still put them miles ahead of software developers in hardware companies, at least on the UI front. They made a LOT of money on that.
It's right there in the name. (Score:1)
Because Microsoft Operating Systems are bug free? (Score:3)
Re: (Score:2)
Back to reality, all Operating Systems have bugs. If all software didn't have bugs I would be out of a job. It's how you handle it when they are discovered that counts.
Apple handles both hardware and software defects very badly. QED, Apple is crap. With Jobs around at least most of the garbage got squashed. Now that he's dead, so is quality at Apple.
They shoulda gone with BeOS. It was a better OS, and it came with a guy who wouldn't have refused to get his cancer treated.
Re: (Score:2)
I agree.
Didn't they do a bug fix year on Leopard vs. Snow Leopard?
Or was it Lion vs. Mountain Lion?
In any case, they need someone that knows how to run a software shop without
being a media darling with a fancy haircut.
Added to your list:
- spend a year re-engineering APFS so it's not a dog on non-ssd drives.
- look at the basic file I/o operations and squeeze every bit of performance out of them
- unify all the library calls in mac/I/iPad/tv/watch OS instead of bandaids like SwiftUI
Bug fixes don't sell devices (Score:2)
Apple has virtually abandoned the idea that you can issue a bug fix that isn't accompanied by some new feature. Fix 20 bugs, add 30 in the new features.
Re: (Score:2)
Been there first hand (Score:2)
Years ago I was on Apple's seeding program. teh 2 issues that stand out to me of that huge amount of wasted time was when a buggy video driver made it out the door after i had reported it every build and the update had to be pulled to put the old driver back in. I also had to make an actual *VIDEO* showing undocumented internet proxy behavior when using java after being told over and over 'it totally works!' Oh the video was *after* submitting a wireshark log that they were unable to understand.
Re: (Score:3)
Linux is bug free? Good to know.
Re: (Score:1)
Compared to I-OS? Bet your booties.
Re: (Score:2)
No, but the time to fix opensource software is much orders of magnitude faster...
How to make an OS work (Score:2)
2. Study and understand the hardware that is listed to support that OS.
3. Work hard on the OS.
4. Ensure everyone working on the OS actually has the skills needed to work on the OS.
5. Test the OS on all the hardware it will be installed on.
6. Find people in the wider computer using community to test the OS.
7. Create a system to accept feedback from people testing the OS.
8. Makes changes due to feedback.
9. Tes
50% (Score:2)
Business as usual (Score:2)
Maybe to a non programmer stuff like "over promising" and "lack of decent logging (not just exceptions)" is someth
No Brainer (Score:1)
The iPhone is Audrey Hepburn, the Samsung - Jenna Jameson. Some people flirt with the idea of banging Jenna up the dirt-track, and leaving her face like a glazed donut. But we'll make that long term commitment to Audrey every day of the week.