I don’t know about you, but I don’t typically feel like shelling out $1000 to buy a machine specifically for an OS I don’t use, just to build a binary to non-paying users of free software.
If Apple would provide easily installable ISOs for VBox/VMWare installations (or something equivalent), I might bother setting up a build for it.
Right now it’s out of the question.
I keep seeing this argument and it honestly just sounds rather lazy when a few seconds of Googling will point you towards build services you can use without having to purchase a Macbook (for instance, TravisCI has an OS X build environment). Or if you're opposed to cloud-hosted build tools for some reason you could ask users/the user requesting a macOS binary would mind working with you to test your build script(s) for compatibility and mention that Mac users will have to build from source in your README. This whole "well I would if Macs weren't so expensive" sounds like "I just don't want to support macOS" because you have options if you actually were interested.
Mac development is a bit more complicated than running MacOS on a CI, especially with GUI apps.
And of course code authors prefer compiling programs themselves on their infrastructure. If you want to volunteer and provide a Mac Build then get the source do it and distribute it. But don't accuse people of being somehow lazy for not supporting mac, that's preposterous.
Apple is responsible for the situation. Don't shift the blame away from them.
And this is a cross-platform project that's not exactly Cocoa-heavy (being based on Electron). The person I responded to did not say anything about creating GUIs either, so I am not sure what your point is.
> And of course code authors prefer compiling programs themselves on their infrastructure.
Which is why Travis, Circle, Appveyor and co have zero users, as we all know.
> If you want to volunteer and provide a Mac Build then get the source do it and distribute it
It's almost as if that was one of the things I suggested - working with the requester to provide a binary
> But don't accuse people of being somehow lazy for not supporting mac, that's preposterous.
I said the argument is lazy, not the people. If for some reason (ideological or whatever) you're not interested in supporting macOS, then say so outright. Don't pretend as though the only obstacle between you and distributing your otherwise cross-platform software for macOS is not having a literal Mac in your hands because there are other easy options, like taking on a contributor or using a build service.
I had to do it a few times in the past and it's surprising how easy it is to run macOS in VirtualBox. Insert ISO, change some configuration, and it boots and installs. Plenty of tutorials and such too.
You mean those hacked ISOs from TPB for 3 year old OSX releases?
How can I, or anyone else for that matter, be sure they are safe to use and represents runtime behavior of the latest ever-changing (read: breaking) OSX?
It’s not as easy as you make it out to be.
The Hackintosh community has plenty of very knowledgeable individuals who know what they're doing. If someone was trying to pass malware around they would be found out and ostracised very quickly.
You can also find the direct links to Apple's servers if you search. Hint: InstallESD.dmg and swcdn.apple.com .
Why does different rules apply to OSX?
Also: DMG-files can’t be used unless you’ve already purchased that $1000 machine you don’t really want/need. It’s completely unsupported in any meaningful sense outside OSX.
So more roadblocks.
You know how I get a Windows ISO? I download it from Microsoft. Ubuntu? Download it from canonical. Etc etc.
Can we all agree that it is Apple who put up all these roadblocks?
No other OS vendor makes it harder/more expensive to support their platform than Apple does.
And then you can’t really blame developers for not bothering. It’s all on Apple.
...and if you've been around and done enough, you would know that "unsupported" doesn't always mean "can't be done". The ones who know it can will hack around, play and investigate, explore the limits, and ultimately become better developers by developing these skills of critical thinking and problem solving. Contrast this with the cookie-cutter developers who won't think beyond what they're told and give up at the slightest difficulty.
I ain't no Apple fan myself but I can sure test something in macOS if I really need to. Give this a read...
https://www.insanelymac.com/forum/topic/329828-making-a-boot...
Sure, but that was the 90s. Now everyone in the world is connected to the same network, and any security flaw can have critical, global consequences.
Basically, having a "wormable" build and deployment pipeline may have been tolerated back then, but it sure isn't now.
> and if you've been around and done enough, you would know that "unsupported" doesn't always mean "can't be done"
Yes, I'm sure it can be done.
> The ones who know it can will hack around, play and investigate, explore the limits, and ultimately become better developers
That's disingenuous. You only have so much time available, and you cannot do everything which is technically possible. You have to prioritize.
My free and underfunded open-source projects are going to invest the efforts I have capacity for into making a better product for the users, not learning all the ins and outs of running a pirated OS on hardware Apple clearly doesn't want it to run on.
Basically: My point was Apple is putting up lots of roadblocks which no other OS-vendor is, and that if they stopped doing that, maybe you'd see more projects bothering to support MacOS as a build-target.
And really... As a user, would you be happy to be told that the software you are asked to install and trust was built on a hacked OSX copy downloaded from the internet which the developer has no way of verifying if is trustworthy or not? I'm going to assume not.
So why are you making the argument that developers should do just that?