For Apple, I find almost the opposite in terms of forced development. If I want to write a program on macOS, I can expect the porting effort to Linux to be simple if not trivial, thanks to UNIX.
Compare that to Windows, which has ostensibly less control, but I continue to find to be a massive pain to develop for.
You are speaking from inside the walled garden here, from the outside the effort of porting to macOS is monumental. The naive way is: I have to buy hardware, learn new Apple specific languages, learn a new OS, learn a new IDE, be compliant with their app store policies, distribution etc. (which applies to Windows now too I suppose).
(not the OP). I develop linux services on a Mac, connected remotely to a linux workstation. My company pays the Apple tax, and the hardware is nicer. Plus, my friends use iMessage.
I tried using a company Linux device only to find that its graphics drivers weren't supported, the 4k scaling didn't work nicely without spending ~30 minutes looking up how to do it the hard way, and it didn't play nicely when connected to a normal 1080 monitor. I returned the device after (thankfully) it failed.
Except for "I have to buy hardware", that's... just not true. Even buying the hardware can be circumvented but let's stay strictly legal here.
As OP said, it's unix, at least extremely unix-y so you don't have to learn apple specific languages. You can choose to do so for better integration to their system and vision and UI idioms (and should I say, macOS native applications are the BEST thought out applications you'll ever have the pleasure of using in user experience side). But whatever code you run in Linux will be trivially ported to macOS.
Learning a new OS is... I mean it is a new thing to learn but it isn't like you didn't learn the OS you are using at some point. Unless you think that there should be one and only one OS for the entire universe that everyone uses, this is an irrelevant point.
For the IDE, again, you don't have to, but you can choose to learn. Most popular IDEs natively work on macOS just fine, and you can just use your terminal like in any unix system, use your build scripts etc.
For macOS, you don't have to be compliant with anything, you can distribute your apps the old fashioned way. If you want to be in their dedicated store though, yeah they have rules. I think that makes sense.
For iOS, that store is the only way to distribute software and your points would make a bit more sense. But I actually am on the fence about the merit of the walled garden approach of iOS. Android ecosystem is a cesspool of malware. I can deal with malware on my computer. My computer has the resources etc. And computers are my job. But my mobile phone IMO has to run trusted code, I will happily delegate some standards to a central body as long as they manage it sufficiently well. When I install an app, I want to be sure that there are reasonable protections about what they can and can't access in my phone. I take my phone with me everywhere, it knows A LOT about me. I can't disassemble all binaries I use to make sure they aren't doing anything shady. Apple has automated tests for this stuff. I know it can't be bulletproof but it is something. They are fast to respond to exploits and they manage to keep their platform secure.
If a "free for all" device was popular, I'd still manage. I'd just have to be EXTRA EXTRA paranoid about what I install in my phone and it would decrease my productivity and quality of life quite a bit. That I can manage. But the whole ecosystem would be A LOT less secure. Not many people would exercise discipline. Viruses, malware, rootkits everywhere, billions of people carrying them in their pockets everywhere. My inclination right now is that that would be a worse deal right now for the world. While Centralisation and corporate power is something I generally despise, in this case (mobile OS, walled garden, corporate control over what apps can and can't do on their platform), I think can see the merit as long as they don't majorly screw it up.
Apple refuses to update their command line tools because of the license. The bash I have here is more than ten years old. It's only a matter of time before things diverge enough to make porting a major pain.
I dont understand this, they already share some of the source to several OS components. Do you care to elaborate a bit on this? Is there some GPL clause or something that became too risky for Apple or something? How do BSD projects get by with the newer licenses aside from already being open source it doesnt seem to affect their underlying license...
Anyway, the message is pretty obvious: Apple won’t ship anything that’s licensed under GPL v3 on OS X. Now, why is that?
There are two big changes in GPL v3. The first is that it explicitly prohibits patent lawsuits against people for actually using the GPL-licensed software you ship. The second is that it carefully prevents TiVoization, locking down hardware so that people can’t actually run the software they want.
So, which of those things are they planning for OS X, eh?
I’m also intrigued to see how far they are prepared to go with this. They already annoyed and inconvenienced a lot of people with the Samba and GCC removal. Having wooed so many developers to the Mac in the last decade, are they really prepared to throw away all that goodwill by shipping obsolete tools and making it a pain in the ass to upgrade them?
Linus Torvalds has in multiple talks said that he does not hate gplv3. He thinks limiting DRM (tivo case) in the license is something he do not want for the kernel, and he strongly disliked the method where GPLv2 automatically upgrades to GPLv3 with the "or any newer version", since his view is that GPLv3 and GPLv2 is two very different licenses because of the DRM clause. During the debconf talk, he said that describing gplv3 as being similar to gplv2 was immoral.
Here is a direct quote "I actually think version 3 is a fine license" - Linus Torvalds
FSF view DRM as just being a physical version of a legal restriction, and they often quote laws that makes it illegal to bypass DRM as proof that DRM is also a legal restriction. Thus in GPLv3 they treat them as identical and they don't see it as a change in how the GPL license work. Linus strongly disagree on this.
This is very different from the Apple case and I doubt anyone can find similar quotes from them.
Their lawyers likely strongly advised against bundling GPLv3 software with their OS because there is a non-zero risk that some judge, somewhere, some day, will claim that requires them to release the source of all their software under GPLv3.
I think that, if GPLv3 ever gets sufficiently tested in courts all around the world (which is highly unlikely) that stance could change.
The main difference would be in that, since Windows has no native Unix environment, all these tools are added functionality while on the Mac, it overrides built-in functionality and can make things go a bit weird.
Actually "for Linux" came from the legal department as Linux is a trademark and it's a common practice to indicate relationship with "for X" where X is a trademark (e.g. "Y for Twitter" instead for "Twitter Y" that would suggest close relationship, from the same company).
The only problem with Cygwin and MSYS and MinGW was that they filled that need poorly.
You could say that WSL is filling that need on Windows now, WSL certainly does remove some of the earlier obstacles/objections why one would want to avoid Windows and use Linux for development.
> For Apple, I find almost the opposite in terms of forced development. If I want to write a program on macOS, I can expect the porting effort to Linux to be simple if not trivial, thanks to UNIX.
Reminds me of the days when I had to buy Windows to test if my website worked on IE.
In the case of Apple, I have to buy the hardware too!
Yes, you can write a UNIX program that will run on MacOS. You can even use Autotools and X Window API. On the other hand, a usual MacOS application is not "a UNIX program."
Compare that to Windows, which has ostensibly less control, but I continue to find to be a massive pain to develop for.
With that said, if macOS lost UNIX, I’d be done.