Early on, David goes through an assumptive timeline, from which he posits that there are only three months for the development teams to come up with cool new stuff. I suspect that the timeline for âcool new stuffâ is significantly longer than three months and that the planning is well underway for macOS 15.
Thatâs entirely possible. Your guess is as good as mine, or @MacSparkyâs.
I donât worry about Appleâs future plans. Iâve been satisfied since they introduced the Files.app on the iPad. 
Hmmm ⌠Iâm not sure why they are still âdoggingâ System Settings. Seems simpler to use than the previous options. And I can easily âsearchâ. If youâre visually looking it seems like you are wasting time (as it seems this is the approach they take). Iâm very happy for the change, it was an easy adjustment (and Iâm not young). Of course I hope they continue to refine System Settings, but âas isâ I have no problem with it at all. Iâd count it as a plus rather than a minus.
Sidenote: In the U.S. âdoggingâ is slang meaning hassling someone/something. Or overcomplaining about someone/something.
Iâm just a sucker for a sidebar.
Yeah ⌠what I should have said was active development time for cool new stuff. Iâve heard that from people but it was several years ago now.
Putting all platform discussions in one episode worked well!
I share some of the frustrations with the major OS release schedule. Feature parity across these huge systems is difficult in the classic good-cheap-quick sense. Pick one. Maybe.
Two caveats:
- this was dashed off rather quickly to get across a point to David and then I was asked to post here. This is a subject I could spend days writing about, so prod if more details are of interest
- This is on the edge of where I make my living and link back to my business site because this is where all of my agile writing is.
Iâve heard you advocate that Apple should switch to feature releases every two years⌠. Strangely this is my field of expertise. I wonât mention this on the Discourse forum because I get accused of advertising.
From experience when companies take the approach you outline - longer feature release cycles, quality typically goes down. Baking quality in after the fact was tried by car companies in the 70s & 80s. They gotten beaten by Toyota that makes a point of fix problems as theyâre found. The stop the line mentality. Literally if you spot a defect, you pull a cord (think the Japanese word is Andon: Andon (manufacturing) - Wikipedia).
This is a much more effective path, but it requires a mindset change at Apple. It would require an effort to build quality into every feature, potentially delaying features to deliver real quality. Given the years of technical debt (Technical Debt | Agile Pain Relief Consulting)- fancy pants language to indicate that theyâve made a number of messes in their code base. With this supply of debt, they might need to spend 30-40% of their time making existing parts of the system more readable. Over a period of years, this would improve the quality, stability and likely performance of the operating system. In the first few years of doing this there would be fewer features to announce at WWDC. In the medium term, this approach speeds teams up, as it makes easier to add new features. Finally in this modern world I just describe, we want to avoid âbig bangâ releases. Instead features are developed, tested and evolve incrementally. This evolution should be grounded in watching real people use the system and see if it fits their needs. Imagine if Stage Manager had been developed and tested in Fredricoâs hands 
Effectively Apple has a large large legacy code base (Legacy Code and Systems | Agile Pain Relief Consulting) they need to take 30-40% of their time as an ongoing tax.
Instead of encouraging Apple to live in the past, challenge them to join the future.
I would happily give Apple this advice in person. My fee is a very reasonable Pro Display XDR and an M3 Pro with 32GB of RAM and 8TB SSD.
I suspect Apple sells loads more because of their annual releases.
They do a lot of heavy lifting for their marketing department.
A quiet trickle of good-quality updates wouldnât help so much.
I think that is less the case than it was 10yrs ago. More and more of the world of software is incremental updates throughout the year.
Assume I agree with your product statement, I think (knowing your background), you would agree the way to better quality isnât reducing the release frequency. Rather it requires a mindset change that increasing the quality of the system is an important thing to do - for every team.
I think (knowing your background), you would agree the way to better quality isnât reducing the release frequency.
Absolutely Mark! I suspect you and I would agree on most things (except, perhaps, which of our two countries is the nicest - Iâd polity say itâs probably Canada, youâd politely say itâs probably NZ, and then weâd probably politely agree on joint 1st place for both), and this is one of them!
Shifting from one big release each year to one big release every second year, without rejigging a whole lot of other stuff, would mean that weâd have a huge, huge mess every 2nd year because there would be (simply put) twice as much stuff to go wrong, but the interconnections between the stuff are wayyyy bigger than that,âŚ
Apple does seem to be releasing software more frequently these days, but theyâve still got a lot of stuff that seems (presumably for historic techie reasons) to be unnaturally coupled with the big annual release.
Agreed - Final Cut Pro and Logic Pro for the iPad appear to be running on an Agile model with a more frequent release process. Other stuff like iMessage or Photos is tied far to much to the underlying OS updates. It would seem better to decouple more teams from the OS.
For me all of this came up because @MacSparky and others frequently suggest Apple should have fewer feature releases. Which as we both agree would likely make the problem worse.
Dear Tim Cook - I will happily take payment in Apple Hardware as I spend time to completely rework quality at Apple.
I wonder what would happen if Apple took their time and didnât release a software product until it was ready?
Would the iCloud Shared Library been able to match the competition and allow users to share their photos with more than 5 people if Apple had waited another year, or maybe just a few months? Or did they need to ship it âas isâ because they were light on new features for the big show?
Why not have some smaller events in addition to the big Keynote? Apple can get the worldâs attention whenever they want. Deskview and Center Stage wouldnât rate a separate event. But iCloud Shared Library, perhaps coupled with a new MacBook, probably could have.
The tricky bit here is defining âreadyâ. Ready for who?
Perhaps it is better to think in terms of a Minimal Viable Product, aka MVP. And you do not ship until all of the requirements for the MVP are met. And then you iterate, adding useful functionality, via frequent updates based both on the original roadmap and user feedback.
The MVP will not be ready for everyone. But it will be useful to some. And with each iteration it gets useful to a greater pool of potential users.
Smaller, more frequent updates allow for a more rapid feedback cycle, remove some of the pressure to hit somewhat arbitrary annual deadlines, and hopefully both cut down on the number of bugs and the time taken to release fixes.
Maybe. Two problems:
- How do you know when the product has truly meet market needs?
- Without real customer feedback how do you evolve a product or feature?
Ignoring bugs for a second Apple thought Stage Manager iPad was ready for release. I use it daily and have lots of feedback about what isnât working. However they doing make it impossible to share that feedback.
Sometimes Apple Software Product Management feels like a pinnate game. Sometimes you hit nothing and sometimes itâs amazing. (I donât want to attack the people doing the work, the problem is the system doesnât allow them to succeed.)
Corrected to catch the missing negative