exAppleToo

The good thing about the nightly builds was you didn't have to use them, and people could respond quickly to showstoppers rather than wait for a sprint. There was a quicklook team to catch bugs which stopped nightly builds from release to general dev, and unless you really needed that build ( to test a new API) you didn't install until quality was restored. The xCode bug was therefore unusual, as they could have fixed it the next day ( and with enough heat they would have).

With fortnightly builds which are only then released to Engineering, if that is now what is happening, there will be massive instability every 2 weeks, until the final round of bug fixing cycle stops all features being added.

Which can't finish in time because the OS has to be released at an Apple event. Except for 10.0 when the date was known months in advance the old OS cycles were released when ready ( when show stoppers were 0). Of course that did lead to some wrangling about what a show stopper was, but consider if iOS 8 was not released with the HealthKit bugs, and other major issues, and instead we got what was in iOs 8.1, or 10.1 instead of 10.0.

Still some issues but mostly robust. Apple needs to decouple software from hardware releases.

The good thing about the nightly builds was you didn't have to use them, and people could respond quickly to showstoppers rather than wait for a sprint. There was a quicklook team to catch bugs which stopped nightly builds from release to general dev, and unless you really needed that build ( to test a new API) you didn't install until quality is restored. With fortnightly builds, if that is now what is happening, there will be massive instability every 2 weeks, until the final round of bug fixing cycles. Which can't finish because the OS has to be release at an event.