Project Builder, the precursor to xcode, ran on windows just fine. The first two version of Xcode originally ran on windows, but did not see the light of day. From version 3 and on, things get a little murkier. The point is, the tools running "mostly" on other platforms is always needed, in order to support potential changes from C-level decision makers. I can see it now - Tim wanting to switch the Apple Lineup to ARM, goes to the Tools team and asks "how long will it take for you to support the move?" only to have the team say - "Sorry three years to rewrite and port everything to ARM." - BWAHAHAHAHAHA!!! Never. Every decision maker on the Tools team would be fired within a week. For example, Apple's tools were running on intel, LONG before the call to switch from Motorola was made. Yet you are fighting that notion now?
I think the point you are missing is that while developers make up a very small % of people buying Macs, they do ironically make a VERY large % of software that RUNS on Macs/iOS. NOT giving developers what they want, tends to cause these smart folks to seek other solutions - Use older hardware, VM, expand into other avenues.
Apple increasingly looks at ONLY revenue. Look where that has gotten them, in the high end desktop world - once a leader, now a punchline. Portable workstations? now we have the ultralight MBP and it's bag full of dongles. Headless Macs? Nothing. Apple's offerings are appealing to fewer and fewer power users every day. Starbucks users? Apple's still doing OK there, but those over priced pastries do tend to stick in those MBP keys.
I see, so your evidence for your definitive statement that “I can assure you that there is some flavor of Xcode running on iOS, linux, windows, intel, AMD and ARM, in the bowels of Cupertino” is that NeXT had Project Builder running on Windows maybe 20 years ago or so, and the first two versions of Xcode ran on Windows some 15 years ago and 13 years ago respectively but you don’t know what happened after that? So, in essence, you have no meaningful evidence for that statement and it’s really just another assumption presented as fact.
And again, I disagree with your statement that ‘the tools running “mostly” on other platforms is always needed, in order to support potential changes from C-level decision makers’. That sounds like a terrible waste of engineering effort, is not how development and engineering teams operate in my experience, and if there is such a disconnect and lack of communication between the engineering teams and the “C-level decision makers” that the engineering teams don’t know what management might do next and feel the need to cover every possible base in order to accommodate their whimsical decision making (and at the cost of taking resource away from the things that management are
actively asking them to do now) then their organisation is completely broken. The far more likely situation, in my view, is simply that Apple has its people working on the things it believes are most relevant to its product and platform strategy.
Your example of Tim Cook and ARM is not a realistic one in my view because that’s not the sort of decision that is made overnight, or in a vacuum from the teams that would make it a reality. Again, the far more likely situation in my view is that there would be an ongoing discussion, over months or years, about the opportunity associated with moving to ARM, and to start having the teams prepare that move as part of a deliberate platform strategy. And your example could work both ways - Tim goes to the Tool team and asks how long it will take to implement some new features in Xcode required for some new hardware, and the team says “six months” (or whatever), and then Tim finds out that the team has had resource working on porting and maintaining Xcode for non-Apple platforms and could have done that work in three months instead - that, in my view, is far more likely to get people fired. “Why are you working on this? I didn’t ask you to work on this! We want to be driving our own platforms forward, not under-mining them and actively demonstrating a lack of confidence in them!” Etc.
My understanding of the history around the Intel transition was that it was not originally a deliberate strategy on Apple’s part but the work of a single engineer working on it alone, on his own initiative, working remotely on the east coast. And later it clearly became a deliberate strategy to invest in Intel because of concerns over the ongoing viability of PowerPC. It wasn’t, as you suggest, because Apple were maintaining a variety of ports on an ongoing basis just in case they might be needed.
I’m not missing that point at all - I just don’t understand how it helps Apple to port Xcode to Linux. Again, it feels to me like a weird suggestion for Apple to decide that the answer to the problem of developers not buying Macs is to offer Xcode for Linux. It just doesn’t make any sense as a solution to that problem. The more likely solution is to work to improve the Mac range for pros - which, funnily enough, is exactly what Apple have said they are going to do.
