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.
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.
But the TDD cargo-culters and UncleBob fans forget that inconvenient fact and think TDD solves ALL problems
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")