Apple Seeds Eleventh Beta of macOS 13 Ventura to Developers [Update: Public Beta Available]

[Lounge vibes 05]

Well, they released it on a 2-year deadline.

This isn’t even entirely true. They started pushing their releases back so much that it became two years, but it was originally supposed to be yearly. And it was for the first several versions.
10.0 Chita: march 24, 2001
10.1 Puma: September 25, 2001
10.2 Jaguar: August 24, 2002
10.3 Panther: October 24, 2003
This is where the time between updates started to lengthen
10.4 Tiger: April 29, 2005
10.5 Leopard: originally announced for fall 2006, delayed to spring 2007, delayed to October 2007 due to iPhone development.
Released: October 26, 2007
10.6 Snow Leopard: August 28, 2009
10.7 Lion: July 20, 2011
and this is where the yearly updates started back again.
And it should be noted that the initial 10.X.0 launches of tiger, leopard and snow leopard were riddled with issues, so it’s not like the longer wait time gave that much of a benefit when it came to bugs.
As pointed out earlier up thread, snow leopard launched with some nasty bugs that completely erased peoples data.
Also, best not to mention Windows Vista, software that was delayed so many times it became a joke, and when it finally launched (five years and three months after the previous version) it was a mess.

 

[woolypants]

it should be noted that the initial 10.X.0 launches of tiger, leopard and snow leopard were riddled with issues

I was there. It was true. Each release of OS X had at least one showstopper bug. I always though it proved Apple was mostly a hardware company, because the software never had the same degree of care and attention.

 

[miguel cortez]

Apple does seem to use letters at the end of their build numbers to give a rough approximation of how close they are to the end of betas. With a 'b' at the end of the build numbers for Ventura, iOS, and iPadOS, I expect all of them will have an 'a' release next week

You're reading too much into them. Generally how build mastering goes in most places, the letter simply reflects each additional build spun after they've branched from the trunk for a particular beta. For example Beta 5 (22A5321d) likely had four builds 22A5321, 22A5321b, 22A5321c, and 22A5321d after it was branched off. So at the end, yes fewer changes = less builds and eventually they're done.

 

[Realityck]

And it should be noted that the initial 10.X.0 launches of tiger, leopard and snow leopard were riddled with issues, so it’s not like the longer wait time gave that much of a benefit when it came to bugs.
As pointed out earlier up thread, snow leopard launched with some nasty bugs that completely erased peoples data.
Also, best not to mention Windows Vista, software that was delayed so many times it became a joke, and when it finally launched (five years and three months after the previous version) it was a mess.

Longer beta cycles doesn't necessary promote better software, what does that is expanding the seeding to more variance with testers setups and software utilized instead of it done mostly in house and with a few developers. I can't remember how far back it was when Apple restarted the public beta program after the very first MacOSX beta, but I am sure it has been of a great benefit this last decade.

 

[Realityck]

I was there. It was true. Each release of OS X had at least one showstopper bug. I always though it proved Apple was mostly a hardware company, because the software never had the same degree of care and attention.

Funny I always thought very few computer companies have created their own OS, so how many can compare to Apple.

 

[Martyimac]

It always impresses me with how fast the updates are done once the preparation is complete. With this being the "b"release I expect the RC to be next unless a show stopper unexpectedly shows up.

 

[woolypants]

Funny I always thought very few computer companies have created their own OS, so how many can compare to Apple

OK I'll bite.

• IBM—many. https://en.wikipedia.org/wiki/Category:IBM_operating_systems
• Commodore AmigaOS/Workbench.
• Every home computer in the 1970s/80s that didn't use MS Basic.
• PalmOS for all the Palm devices.
• Acorn RiscOS for the Archimedes
• NeXT!
• BeOS!
• Google Android.
• Google ChromeOS.

And that's just home consumer stuff. There's lots of embedded/industrial systems that came with their own OS.

 

[Realityck]

OK I'll bite.

• IBM—many. https://en.wikipedia.org/wiki/Category:IBM_operating_systems
• Commodore AmigaOS/Workbench.
• Every home computer in the 1970s/80s that didn't use MS Basic.
• PalmOS for all the Palm devices.
• Acorn RiscOS for the Archimedes
• NeXT!
• BeOS!
• Google Android.
• Google ChromeOS.

And that's just home consumer stuff. There's lots of embedded/industrial systems that came with their own OS.

You're comparing a mix of very different OS's. Nextstep was the acquired basis of the original MacOSX for Apple. Apple is really the only company out there other than linux distributions that uses a UNIX operating system to sell consumer computers (desktops/laptops). It's because of that particular choice that Apple is very unique in the computer world. Yes lots of workstation companies that have come and gone has some similarity to Apple in choosing Unix. Google with their linux based OS doesn't promote computers like Apple does. This Ventura is far different than what others provide in the level of capabilities and deployment. Good list of OS's to discuss.

 

[woolypants]

Apple is really the only company out there other than linux distributions that uses a UNIX operating system to sell consumer computers (desktops/laptops).

At this point I'm unsure if you're trolling me.

 

[Realityck]

At this point I'm unsure if you're trolling me.

Nope just speaking from technical facts of this current marketplace. One of the reasons I always liked MacOS vs Windows and Linux is what it represents as a Unix based OS. I've used all three extensively.

 

[Confused-User]

Does anyone who had trouble with Mail in beta 10 have anything useful to say about beta 11? Please?

 

[Realityck]

Sadly for me, Safari is still as broken as before. But at least my Technology Preview install works well. As I said before, I'll see if it's still broken when Ventura goes golden master and will then re-install the OS if it isn't fixed.

The interesting thing I find about running Safari and its Technology Preview is that other machines see two sets of iCloud tabs labeled [machine name](1) and [machine name](2).

You seem to have something in the system settings/preferences related to Safari that might need to be removed when you do what we previously discussed (ASR backup/wipe/factory reset OS/restore). The fact that the technology preview doesn't have this issue leads one to this conclusion.

 

[tobybrut]

You seem to have something in the system settings/preferences related to Safari that might need to be removed when you do what we previously discussed (ASR backup/wipe/factory reset OS/restore). The fact that the technology preview doesn't have this issue leads one to this conclusion.

If it’s not a bug, it’s likely corruption somewhere. I’ve cleared caches repeatedly and I’ve changed every setting I can think of that might make a difference and the only one that “solves” the problem is turning off JavaScript. However, turning off JavaScript disables everything that makes web pages interactive beyond being a simple text, image, and link container, so that’s not really a good solution. Too bad I can’t just delete Safari and find a Safari installer. The only one I could find was the Technology Preview, but that installs alongside Safari, not on top of it.

I have a feeling it will come down to a full re-install.

 

[tobybrut]

You're reading too much into them. Generally how build mastering goes in most places, the letter simply reflects each additional build spun after they've branched from the trunk for a particular beta. For example Beta 5 (22A5321d) likely had four builds 22A5321, 22A5321b, 22A5321c, and 22A5321d after it was branched off. So at the end, yes fewer changes = less builds and eventually they're done.

You might be right. Or not. Unless you work for Apple you won’t know their exact processes, and I’ve never worked for them. I’ve seen many different build processes and numbering conventions over the decades and Apple’s doesn’t resemble any one I’ve been a part of before. However, my observation is that the lettering tends to start around ‘j’ in their first beta release, give or take a letter or two depending on how late in June WWDC is, and moves downward towards ‘a’ with each release. It doesn’t always do that, which tells me they changed their mind about the release schedule, either skipping a letter or reusing a letter based on accelerated or slowed progress. It’s been pretty consistent over the years to indicate their rough final release. Or in the case of iPadOS 16, they backed up several letters to indicate a delay of at least a month.

Up until Apple announced the delay, iPadOS has always had the identical build number as iOS. This tells me the number has no relation to how many builds there have been for a particular beta because it’s very unlikely iOS and iPadOS are built at exactly the same time and in the same frequency internally. Each team would build according to its own needs since they aren’t the same code base. I wouldn’t be surprised to find the other letters and numbers are some hash of the date of the build’s release.

I think this pattern is why most people have been predicting 16.1’s release near the end of October. With the latest build being a ‘b’, it’s too far away for it to release within the next two weeks. Using the pattern, next Tuesday will be an ‘a’ build while Golden Master/Release Candidate 1 will be on Tuesday, October 25 with final release likely to be on Monday, October 31. I predict the latter date, even though it’s not a Tuesday because Apple said it would release in October, not November. However, final release could be on the previous Friday since that’s the day of the week they officially release products like the expected new iPads or Mac mini. Golden Masters and final releases are very inconsistent, sometimes coming just a day apart, but sometimes as long as a week. They don’t have to have any time between them since they are usually the same build.

Observationally moving from ’d’ down to ‘c’ down to ‘b’ down to ‘a’ in subsequent beta releases is too much of a coincidence to ignore. Builds simply aren’t done in such a way that one beta has four builds, then the next three builds, then the next two, and so on. Most build systems I’ve ever seen are done nightly, so there are at least ten builds over a two week period. And often near a public release, there are flurries of manual builds, usually because of a single bug fix, trying to squeeze in some changes.

Now everything I said could simply be wrong and just a coincidence since I have no direct evidence, but this is merely an observation based on detecting patterns over the years. As you said, I’m probably overthinking it, but that’s what we engineering nerds do.

 

[tobybrut]

Longer beta cycles doesn't necessary promote better software, what does that is expanding the seeding to more variance with testers setups and software utilized instead of it done mostly in house and with a few developers. I can't remember how far back it was when Apple restarted the public beta program after the very first MacOSX beta, but I am sure it has been of a great benefit this last decade.

The more users an OS gets during the beta period, the more likely bugs will be uncovered. No QA department in the world can find all bugs because there are an infinite combination of configurations that could create just the right conditions for a bug to manifest.

The more complex an OS gets, the buggier it can potentially get. I think many of us suffer from recency bias where the latest release is always the buggiest when I think they’ve all been buggy to a certain degree for x.0 releases even going back to the early Steve Jobs iCEO era. Some are worse than others, but none have been bug free. I saw an article a few years ago that said Windows had at least 100,000 bugs that will never be fixed. I’m not surprised and wouldn’t be surprised to find Apple’s OS’es have similar numbers.

 

[eflx]

Normally Beta is feature complete free of known bugs. Alpha may have bugs on any feature.
Beta collects customer feedback not about bugs but about the behavior of features to adjust before the final release.
Continuity camera is a major feature of Ventura, if this is not caught by QA, how many other issues are in the release that are not obvious.

I switched back to beta 8 which is working with the features I observe.

Not necessarily. Beta doesn't mean feature complete at all, it simply means a software release with enough of the core functionality and stability to open it up for further testing on a wider array of machines and users. I've been a software developer going on 20 years. Beta has never meant feature complete and free of known bugs ... it was actually always assumed more work needed to be done, and there were bugs that *we* just couldn't find or see yet and needed a fresh set of eyes and for someone who's not a developer to test the software as software engineers tend to use and interact with the software how they designed it to be used, while at times having a blind eye to how someone completely unfamiliar or with a different configuration might use it.

Sorry ... but way off base.

 

[benwiggy]

Longer beta cycles doesn't necessary promote better software, what does that is expanding the seeding to more variance with testers setups and software utilized instead of it done mostly in house and with a few developers. I can't remember how far back it was when Apple restarted the public beta program after the very first MacOSX beta, but I am sure it has been of a great benefit this last decade.

From recent insider accounts, Apple now gets more bug reports than it can actually cope with, and you're lucky if a report gets escalated by the triage workers.

 

[Realityck]

From recent insider accounts, Apple now gets more bug reports than it can actually cope with, and you're lucky if a report gets escalated by the triage workers.

With personal experience I asked that over the phone when contacting Apple dev staff about feedback submitted, and they said they read it all, but only respond back to submitters when there is a particular instance they are trying to get more details from several sources to determine the cause. Likely a lot of submissions are too vague to reproduce. Something I think about always before submitting.

 

[Confused-User]

With personal experience I asked that over the phone when contacting Apple dev staff about feedback submitted, and they said they read it all, but only respond back to submitters when there is a particular instance they are trying to get more details from several sources to determine the cause. Likely a lot of submissions are too vague to reproduce. Something I think about always before submitting.

I've submitted a bunch of 100% reproducible bugs. All totally ignored.

Even the powerd/mail bug in b4 (b6? I forget) that everyone was having - I tracked it down and submitted a complete report before I found that others had done the same. Here's what I added to the ticket when closing it:

"Solved in 22A5342f, so I'm closing this.

Your triage processes are a hideous embarrassment. This was reported all over the net. And yet "Recent similar reports: None". Opening bugs with Apple is like shouting into a well. It hardly seems worth the effort."

 

[benwiggy]

Responses to the submitters is something else entirely; however, I was talking about anecdotes from Apple employees that suggest that most BRs don't get passed upwards.

It's evident that if you've got a million beta testers, then you're going to get a million BRs, on average, at least. That's going to take a lot of manpower to work through; and if you're under a time constraint (100 BRs a day), you're likely to miss the significance of filings, even if they do get read.

The first bug I filed took 6 years to get fixed. Whether my filing was instrumental in that, I have no idea; but likely not.

 

[TriBruin]

Responses to the submitters is something else entirely; however, I was talking about anecdotes from Apple employees that suggest that most BRs don't get passed upwards.

It's evident that if you've got a million beta testers, then you're going to get a million BRs, on average, at least. That's going to take a lot of manpower to work through; and if you're under a time constraint (100 BRs a day), you're likely to miss the significance of filings, even if they do get read.

The first bug I filed took 6 years to get fixed. Whether my filing was instrumental in that, I have no idea; but likely not.

Apple probably has a hierarchy of triage when submitting tickets. When you submit feedback, it is tied to your AppleID. Based on the AppleID, you are either a Developer (tied to a paid Developer account), an IT Admin (has a Managed AppleID tied to Apple Business Manager), or a regular user, using the public beta.

My guess is that Developers and IT Admins are going to get much better responses than the general public.

 

[Martyimac]

With personal experience I asked that over the phone when contacting Apple dev staff about feedback submitted, and they said they read it all, but only respond back to submitters when there is a particular instance they are trying to get more details from several sources to determine the cause. Likely a lot of submissions are too vague to reproduce. Something I think about always before submitting.

Agreed. I was having an issue where every time I installed a new beta version, it would kill my wifi connection. Submitted a bug report and actually had an  engineer respond back for more info. Long story short it wasn't the beta that was the issue is was my VPN kill switch that would kill the wifi. Once we figured that out, my last 2-3 beta installs have gone well after I turned the kill switch option off. I am a public beta tester, not developer.

 

[macnerd77]

Golden Master?

 

[Martyimac]

Golden Master?

???????

 

[Lounge vibes 05]

I was there. It was true. Each release of OS X had at least one showstopper bug. I always though it proved Apple was mostly a hardware company, because the software never had the same degree of care and attention.

this idea that Apple would have less buggy initial releases If they didn’t release new software every year is ridiculous, especially with how minor these updates have gotten recently.
If Apple released Ventura in, for example, May 2024, giving Monterey, two years and seven months as the latest update, there’s absolutely no guarantee that 13.0 wouldn’t have the usual X.0 release day bugs.
This is why it’s always been suggested, since the first version of Mac OS X two decades ago, unless you’re prepared to deal with possible issues or you’re purchasing new hardware, always wait for the .1 or .2 update.