> "there's no longer a dedicated Mac operating system team"

That took some time for me to sink in. I can fully understand the aversion towards dedicated teams á la Jobs, but we are talking about an OS that is used keenly by developers, an ecosystem essential to maintain. I was baffled by Apple not pushing ZFS further, the clear lack of interest in developers by not working on e.g. virtualisation, e.g. containers, a polished OpenSolaris or similar with tools we could make MacOS even greater. Like they couldn't afford it.

Under a different lens, that implies that previously iOS-only engineers now must also become familiar with the macOS codebase, and so more able to contribute to it. Given the large number of those engineers compared to the previous size of the macOS team, this may help more than hurt macOS (as long as you assume the engineering teams are of equivalent quality.)

While it's tolerable to have engineers jumping between projects in, say, web frontend, I'd imagine that operating system security work is incredibly sensitive to programmer context-switching - you can't dive deep into the security model of a desktop system in your 20% time when you're working with an entirely different system (with a different CPU architecture) in your 80% time. Of course there will be some specialization on this team, but it doesn't seem to be nearly enough. Unfortunately, it will take something like a botched release (not just a security problem) and heads rolling to reverse this trend.

Not sure if you're familiar with how iOS/OSX works.

For the Darwin team which is the actual core OS they would have to deal a lot with CPU architectures. But they again they have always dealt with this since back in the NeXT days. ARM and x86 isn't a big deal to manage and there isn't much evidence that something is wrong in that area.

For the UI teams i.e. System Frameworks, Cocoa, WindowServer etc. They are abstracted away from worrying about CPU architectures and they are the ones responsible for all the bugs we are seeing today. You can argue context switching is an issue here but again we don't have much visibility that iOS/OSX engineers are jumping back and forth every day.

So which team might have screwed up here? Is this a UI issue or a backend/system library issue? What about the previous root account unlock issue?

I actually put the blame on Agile.

A few years ago there was a noticeable increase in the frequency of point updates at the expense of quality. In agile, testing either (a) relies heavily on automation or (b) only tests that particular story. In highly complex systems that's often not sufficient and rarely do security teams for example involve themselves on a per story basis.

Personally I think the industry as a whole needs to sit back and realise that Agile wasn't the panacea it was made out to be.

I am absolutely agree with you. Agile is not silver bullet and people just don't get it. Also many times it is executed very wrongly.

Well, more specifically the issue is that unit-testing alone is not enough. At some point you have to test the entire system as a whole.

I don't think agile practices preclude running regression suites throughout the development cycle.

No, a lot of Agile teams do have integration tests and higher level tests

But the TDD cargo-culters and UncleBob fans forget that inconvenient fact and think TDD solves ALL problems

Most of the codebases of both iOS and macOS are fundamentally the same kind of (low-level but architecture-independent C and Objective-C) code, and encouraging team unification will make that even more true—if the same people are working on both AppKit and UIKit, for example, it's a no-brainer to unify them rather than maintaining that duplication.

The exception is the kernels and drivers of each OS, which have to consider things like architecture, but I would expect that it'll still be the same individual engineers working on these who always have, no matter what their team structure looks like now. Whether or not Apple has a formal "macOS kernel team" or "iOS kernel team", those groups definitely exist and have rather static membership.

(In fact, one main benefit you might see from this is that Apple has hardware hires—many from Intel[1]—who have stepped up to apply their knowledge of formal verification methods to the iOS kernel and drivers, but haven't necessarily had the flexibility to spread that love to macOS. That can change now.)

[1] https://danluu.com/cpu-bugs/ (search for "Apple")

Duplication of effort is something that a small company may worry about but Apple has boatloads of money.

It isn't just "we coded it twice" (which I would still argue is bad from a security perspective with respect to making sure both are actually correct), but "we both designed an API to solve the same kind of problem... different... so now the world has two APIs to learn on these weirdly different platforms when, by all rights, we should have just designed one".

One woman has a baby in 9 months. In how many months will 9 women have a baby?

Also: “Mythical man month” etc.

You do not solve your problem by having a bunch of engineers from a different domain and having different priorities.

First baby take 9 mo, but with a pipeline you can get the average close to 1 mo.

And if you'd been speculatively executing the baby making pipelines...

In this case we’re talking about just one baby :)

Just hire a woman who is in her 3rd trimester and you can cut that baby down to 3 months. ...

Visit the maternity ward. Problem solved.

Say why don’t you give us a call back when you’re in labor and we can have that job interview?

I heard rumors that Apple is moving towards one unified App development process for both macOS and iOS

Is it possible that this is related to that?

Microsoft Cairo...finally!

You mean Taligent: https://en.wikipedia.org/wiki/Taligent

Taligent was a replacement, not a merge like Cairo was supposed to be.

This reassignment and movement of people to the iPhone/iPad side has been happening for a long time. That's why I referred to the organizational structure, because the company is not equipped to handle so many things quite well (which has its advantages and disadvantages). One write up about this topic, which I share somewhat often is on Stratechery. [1]. That's worth a read.

[1]: https://stratechery.com/2016/apples-organizational-crossroad...