I used to be able to use sidecar to easily and wirelessly extend my Mac screen to my iPad Pro.
then it mysteriously became intermittent. Then all of a sudden I needed to download an update to keep it working after an is update. Now it never works. I need a thunderbolt cable that only works sometimes. ReformT and reset resulted in the same degrading process. What the heck, apple?
Resorted to using Duet. And strangely it has been the more reliable option.
Apple NEEDS to stop the drumbeat of annual significant software feature enhancements. Quality hit the skids when they started that BS. It’s time to recover quality.
Where the marketing people go wrong is in the belief that only new features sell product. Which isn’t completely wrong. But you can make your existing customers much happier by stabilizing what’s already been developed, enhancing performance and improving the ease of use of existing capabilities. Happy customers tell their friends who might then be convinced to switch to Apple products. The latest iOS 17 and iPhone 15 overheating issue is a good example of something that should have been discovered in beta testing. Having a significant issue like that right on the release a new hardware product is embarrassing if not inexcusable. I’d also suggest Apple make public the list of bugs that have been identified and let customers add additional issues or comments on specific issues. Open up the process and let your customers help to guide your efforts.
iOS 17.1 has so many bugs related to Wi-Fi, Bluetooth and Carplay that I have to switch back to an older iPhone 12 which has not updated. There are many bugs in house apps like Calendars and Contacts that I gave feedback for years. Even the feedback website itself, is full of outdated information and you cannot give feedback about newer iOS and macOS. It’s late but better than not wake up to invest resources to clear up bugs.
It would be great if I can unmount disks from the desktop without the -6xxxx errors. Also, the disk icon should only disappear when the drive is ready to be unplugged.
Snow Leopard was one of Apple's best releases for good reason.
Squashing bugs and optimisation should always be main goals.
And even snow leopard still contained upwards of 2k open bugreports. Later releases went well over 5k open reports. I doubt many will be fixed in the timespan of a single week.
It seems like this article has touched a nerve to reveal something we all have been noticing. I used to tell people that the MacOS and iOS was more stable than it’s competition but Apple software has been much more buggy as of late. I still think there are other compelling reasons to change namely—build quality and the battery life of Apple Silicon
My old cheese grater running High Sierra that I use as a cheap version of a media server to my AppleTV has more stable software (though granted the Apple ecosystem was much more simple back then) and the old gal really puts out the heat.
My first reaction was “Only a week? This is mostly a PR stunt.”
But some folks here who know a lot more about software development seem to think it’s a reasonable thing, so I defer to them.
I wish they would do this once a quarter though…just devote a week for intensive bug quashing as a regular part of the development process (in addition to on-going efforts).
I do a lot of audio work and I miss the days of being able to say to my Windows using friends that the MacOS “just works” without the host of problems they were plagued with. As Windows has improved and the MacOS has become more problematic in some aspects, I say that a lot less.
It seems like this article has touched a nerve to reveal something we all have been noticing. I used to tell people that the MacOS and iOS was more stable than it’s competition but Apple software has been much more buggy as of late. I still think there are other compelling reasons to change namely—build quality and the battery life of Apple Silicon
My old cheese grater running High Sierra that I use as a cheap version of a media server to my AppleTV has more stable software (though granted the Apple ecosystem was much more simple back then) and the old gal really puts out the heat.
I think you hit on one of the root causes of many software quality problems, which is an unbounded increase in both size and complexity as the software product matures. These increases are usually accompanied by a continual increase in technical debt, which includes all known anomalies that are still in the code base.
Apple having to support two disparate architectures on macOS, Intel and Apple Silicon, does not help and only adds to the complexity and workload on the development staff.
Anomalies include not only “bugs” as generally understood by most users, i.e., issues that cause bad things to happen, like crashes and deadlocks and data loss, but also implementations that don’t crash the machine but do not work as intended, don’t really work at all (like the recent MAC address issue), are sub-optimally implemented, e.g., code that sorely needs to be refactored but there’s no time in the schedule to do it or it never rises in priority over other required software work, and a plethora of user interface, workflow, and usability issues. When you hear that a shipping software product has thousands or tens of thousands of “bugs” in it, which is not unusual, the vast majority of these are of the latter variety, things that don’t crash the system but don’t work as intended.
But that’s only part of the problem because those are all things that are known to the development team. Those things can be tracked and evaluated and hopefully queued up for assignment to developers. The other and more dangerous (imo) category of anomalies and bugs are those that are latent and undiscovered in the shipping software. Those are the ones that have survived the internal and beta testing regimens and are ripe for exploitation. Based on the constant drip of security updates that roll out with every software update there are obviously a nontrivial number of those lurking in Apple’s code base. This is not unique to Apple.
The reason why all of these anomalies don’t simply get fixed and removed from the technical debt backlog is because the development team’s release backlog, or prioritized queue of all work that has to be completed for a specific release, is competing for the same finite number of resources and program/marketing priorities as is the technical debt backlog. The release backlog will usually contain a number of technical debt reduction tasks, but everything is prioritized and negotiated to hit the release target. Priorities, resources, and dependencies are all huge contributing factors to deciding what work gets done and when it gets done.
To be clear, it’s not like a software development and product team sits down once a year and decides what new features to go after for the next release. The actual work that needs to be performed to bring a new feature up for consideration may involve a lot of upfront work by advanced development, system architecture, and aligning a number of other dependencies outside of the software team to ensure they are all onboard with the proposed new feature. These tasks can and usually do go well beyond what can be done in a single yearly release cycle.
I know that nobody wants to accept the excuse that software development is difficult, but it really is difficult. But nobody who does software for a living is giving up or accepting untenable compromises like freezing all new feature development for the sake of stability and robustness, at least not for commercial software development. Software is a mechanism through which human intellect, curiosity, invention, imagination, and problem solving of the most complex problems imaginable can be expressed and formed into tangible implements that serve the needs of individuals and societies. Since human curiosity and compulsion to create is unbounded, software will always need to adapt to solving larger and more complex problems. It’s a tool and a means to an end, but because it is built by imperfect and inherently flawed craftsmen and it is not typically mathematically provable for correctness, it will always have some level of imperfections.
When all is said and done, I think Apple is doing an excellent job considering the complexity of what they’re dealing with. I continue to be impressed most with the reliability of their installation and update process. So far, no bricks for me, which is a very good thing.
I love Stage Manager there has been a lot a great and good new features, but data integrity, stability and security are paramount. It just works, should be #1 on the list, always.
I suddenly can’t charge my iPad or brand new iPhone 15 pro max using USB-C. Using USB-A to USB-C works and wireless charging. This is using apple only chargers and cables. So yea, fix bugs please.
Idea: fix all the bugs, refine the existing technologies so they are flawlessly reliable, and put a new skin on them. Label them iOS18 and macOS15 respectively. Stop adding "features" and "improvements" that add nothing to the actual value of the OS.
You know, as I type this, I notice that only the macOS has a name. The other OS releases only have numbers. Maybe have the crack Apple Marketing Team address that in some genius method.
Of some importance, Apple has also paused further development of Vision OS in order for those engineers to also concentrate on the atypical number of bugs and stability issues with iOS, watchOS, and MacOS .
Dude, chillax, it's one week — i.e., it's not really of "some importance", unless by 'some' you mean to imply almost none.
Only a week? That's laughable. How about an entire year? We don't need major new versions of every OS every year. All my friends and family (and even coworkers) avoid installing the latest OSes from Apple now because they are afraid of bugs and instability... no one's asking for new features.
While not a bug, but a bad design choice is having the phone app stay on your screen after hanging up on a call. I really want Apple to change this and help put an end to butt dialing phone numbers. Just close the phone app after phone calls and go back to home screen.
Good idea. We need another Snow Leopard type refinement. Or two.
I read similar comments on ApplerInsider. You are suggesting a buggy, messy state. What are examples of bugs and glitches that make you conclude this? My experience is the opposite but that might be because I’m not exposed to major/critical issues due to the usage of the OS.
(A week long sprint isn’t going to change anything there I’m afraid)
Comments
then it mysteriously became intermittent. Then all of a sudden I needed to download an update to keep it working after an is update. Now it never works. I need a thunderbolt cable that only works sometimes. ReformT and reset resulted in the same degrading process. What the heck, apple?
My old cheese grater running High Sierra that I use as a cheap version of a media server to my AppleTV has more stable software (though granted the Apple ecosystem was much more simple back then) and the old gal really puts out the heat.
But some folks here who know a lot more about software development seem to think it’s a reasonable thing, so I defer to them.
I wish they would do this once a quarter though…just devote a week for intensive bug quashing as a regular part of the development process (in addition to on-going efforts).
I do a lot of audio work and I miss the days of being able to say to my Windows using friends that the MacOS “just works” without the host of problems they were plagued with. As Windows has improved and the MacOS has become more problematic in some aspects, I say that a lot less.
Apple having to support two disparate architectures on macOS, Intel and Apple Silicon, does not help and only adds to the complexity and workload on the development staff.
Anomalies include not only “bugs” as generally understood by most users, i.e., issues that cause bad things to happen, like crashes and deadlocks and data loss, but also implementations that don’t crash the machine but do not work as intended, don’t really work at all (like the recent MAC address issue), are sub-optimally implemented, e.g., code that sorely needs to be refactored but there’s no time in the schedule to do it or it never rises in priority over other required software work, and a plethora of user interface, workflow, and usability issues. When you hear that a shipping software product has thousands or tens of thousands of “bugs” in it, which is not unusual, the vast majority of these are of the latter variety, things that don’t crash the system but don’t work as intended.
But that’s only part of the problem because those are all things that are known to the development team. Those things can be tracked and evaluated and hopefully queued up for assignment to developers. The other and more dangerous (imo) category of anomalies and bugs are those that are latent and undiscovered in the shipping software. Those are the ones that have survived the internal and beta testing regimens and are ripe for exploitation. Based on the constant drip of security updates that roll out with every software update there are obviously a nontrivial number of those lurking in Apple’s code base. This is not unique to Apple.
The reason why all of these anomalies don’t simply get fixed and removed from the technical debt backlog is because the development team’s release backlog, or prioritized queue of all work that has to be completed for a specific release, is competing for the same finite number of resources and program/marketing priorities as is the technical debt backlog. The release backlog will usually contain a number of technical debt reduction tasks, but everything is prioritized and negotiated to hit the release target. Priorities, resources, and dependencies are all huge contributing factors to deciding what work gets done and when it gets done.
To be clear, it’s not like a software development and product team sits down once a year and decides what new features to go after for the next release. The actual work that needs to be performed to bring a new feature up for consideration may involve a lot of upfront work by advanced development, system architecture, and aligning a number of other dependencies outside of the software team to ensure they are all onboard with the proposed new feature. These tasks can and usually do go well beyond what can be done in a single yearly release cycle.
I know that nobody wants to accept the excuse that software development is difficult, but it really is difficult. But nobody who does software for a living is giving up or accepting untenable compromises like freezing all new feature development for the sake of stability and robustness, at least not for commercial software development. Software is a mechanism through which human intellect, curiosity, invention, imagination, and problem solving of the most complex problems imaginable can be expressed and formed into tangible implements that serve the needs of individuals and societies. Since human curiosity and compulsion to create is unbounded, software will always need to adapt to solving larger and more complex problems. It’s a tool and a means to an end, but because it is built by imperfect and inherently flawed craftsmen and it is not typically mathematically provable for correctness, it will always have some level of imperfections.
When all is said and done, I think Apple is doing an excellent job considering the complexity of what they’re dealing with. I continue to be impressed most with the reliability of their installation and update process. So far, no bricks for me, which is a very good thing.
You know, as I type this, I notice that only the macOS has a name. The other OS releases only have numbers. Maybe have the crack Apple Marketing Team address that in some genius method.
Dude, chillax, it's one week — i.e., it's not really of "some importance", unless by 'some' you mean to imply almost none.
(A week long sprint isn’t going to change anything there I’m afraid)