Comment by kxyvr | Hacker News Reader

Comment by kxyvr | Hacker News Reader

Parent Full thread

So I'm one of those developers that got forced into buying a Mac Mini in order to test my software on MacOS. On one hand, you're correct that Apple "won" because I was pushed into spending $500 on their hardware. On the other hand, the parent is very much correct. Candidly, I'm still angry at Apple for making their ecosystem a pain in the ass to work with. Hell, I would have paid good money to buy a MacOS virtualization license because it screws up my work flow. Every other OS I work with I can virtualize on my laptop, which means that I can work remotely without internet such as on airplanes or in cheap hotels. For MacOS, I have to ssh into the box, but even that is a royal pain in the ass because there's a lot of the ecosystem that flat out doesn't work without the desktop open. Environment variables are set differently. Some programs like MATLAB will not run (Yes, you can run MATLAB on the console through an ssh session, but you have to VNC into the box first to make sure the desktop is running.) I hate it, which means that I flat out tell my customers not to use Apple hardware if at all possible. So, yes, they got $500 out of me, but I actively work to ensure they get less business in the long run because their ecosystem is a wreck. Just letting us virtualize MacOS would go a long way to fixing that problem.

Why don't you use a virtual machine, if it is just for testing?

You find a lot of tutorials on the web, how to install macOS. It is not much harder than to install Ubuntu.

Yeah, sure, it's possible. It's also against their EULA and they could break it (just like Hackintoshing) at any point in time and then bam; half of your customer base is receiving untested software because you no longer have access to your virtualized OSX until you fix it (just like every time an OSX/xcode update is rolled out). Is that worth saving the $500? For most of us, it's not.

Sure you can mitigate it by not doing updates, having a test machine to receive the updates and verify that it still works, yadda yadda.

I managed CI infrastructures for IOS/Android developers a few years ago and the hoops we had to jump through with xcode / EULA-breaking virtualization, etc was something I'd never experienced before. Hopefully it's different now, but we used to have to run farms of mac minis because we couldn't have jenkins/bamboo trigger more than one xcode test/build run at a time. So we'd have these $1500 mac minis sitting around doing ONE job at a time whilst the Android builds could easily do 1-10 things simultaneously.

Everything felt like Apple was fighting our developer experience. It was even worse for our business model as we developed 3rd party applications for other companies which brought it's own headaches with signing, testflight, getting demo/beta apps to clients before release to app store, etc.

> but we used to have to run farms of mac minis because we couldn't have jenkins/bamboo trigger more than one xcode test/build run at a time.

As someone who is interested in OSX testing like this - ie, not arguing with you - would it be possible to have a mac mini use virtualbox with real OSX installations running in parallel?

From what i've heard in this thread, Virtualbox/etc support OSX just fine, on OSX machines. Hypothetically, you could parallel-ize on a single machine via virtualbox, no?

I understand Apple is still making it a PITA though. Not disagreeing, just learning why you were only running a single instance per box. :)

I last worked on this stuff 2-5 years ago so I'm not completely clear. I'm probably very wrong on this nowadays so hopefully someone can give you better info. IIRC you can run two OSX guests on an OSX host with Apple hardware. Anything that isn't using OSX as the base OS is EULA violating. I see a lot of people doing it via esxi. I'm not sure if the EULA has changed and that's ok now or people are just doing it. Thankfully I'm out of that side of CI/CD and plan to never deal with it again.

Our initial goal was to have one OSX system running multiple xcode builds/tests. I think at some point we may have gotten it working by having different targets set up but I don't recall the specifics.

Sorry I can't be of more help. We worked with 3-4 other app developers and it seemed like all of us were doing completely different work arounds to reach the same goal. I'd love to know how King or any of the other huge (number of apps) developers deal with these things. It doesn't seem like it's talked about much.

No worries, appreciate what information you could give :)

Mac OS X is mainly a desktop OS and those of us that know Apple since the Mac Classic days don't have any issue with their desktop culture, which wasn't any different from the Atari and Amiga ones.

I never sshed into them.

That's the point. I don't want to have to ssh into it. However, since I can't legally virtualize MacOS on my laptop I'm forced to in order to make sure that my software works fine on MacOS. That's why I'm resentful toward Apple. They make it really difficult for people to develop cross platform applications that work on MacOS and the only response I tend to get is a smug, "Eh, just buy a Mac Book."

I'm just guessing here, but I don't think that Apple is all that interested in making it easier to develop cross-platform applications. From their point of view, the best applications are OS-specific ones. So if you want a Mac application, you're best coding on a Mac, with Mac tools, and within that hardware eco-system. From this point of view, the same argument applies with Windows, Linux, etc... (albeit with the caveat that hardware is more varied).

Apple isn't trying to make that way of working easier... they are trying to make life easier for macOS-specific devs. Apple is looking for well integrated applications, and as I'm sure you know, that's really hard to do well cross-platform as you often end up coding to the lowest-common interface.

Again, that's from the Apple point of view...

Apples interest in making cross platform applications easier waxes and wanes with their market share. If I remember correctly, they were quite keen on java and making it work well at one point.

They still heavily use Java on their backend systems, but that's not what we're talking about here...

You're right - they did have a Java-Cocoa bridge early in OS X, but deprecated it quickly when it was difficult to translate Obj-C semantics into Java. I remember trying it, but it wasn't really that easy to use. Even in this case though, the idea was to write Mac-specific applications, just in a different language. Most of the application's magic was still in the ObjC/Cocoa layers, which weren't cross-platform (or were they - I can't remember if there was a Windows port at sometime??).

While this would have made it easier to write cross-platform applications, realistically, that was never the goal. I think the goal of the Java-Cocoa bridge was to offer a backup plan in case too many devs didn't like Obj-C. At the time, Objective C was a novel language for many people. Once Obj-C got enough mindshare and it looked like it got enough of a buy-in from developers, Apple ditched Java quickly. I'm sure the licensing issues from Sun in the early 2000's didn't help matters here.

Also, it's only been fairly recently that Apple turned over the Mac Java port back over to Oracle. For the longest time, Java developers on Macs were always a version or two behind because they were on the OS X release schedule, rather than the Oracle/Sun release schedule.

The Java-Cocoa bridge was only an early bet as they weren't sure if the Mac developers were keen in jumping into Objective-C.

They dropped it the moment they realized most of them were happy to use Objective-C and somehow they were the first company to turn back the tide from JIT to AOT compilation.

Yes, back in the NeXT days there was a Windows version of the whole Objective-C dev environment for Windows, and also an initial port of Cocoa to Windows when it was still called Rhapsody.

As for fairly recent, it was almost 10 years ago. :)

I remember the days. Back when developing desktop java apps at all seemed like a reasonable idea.

Not only Apple, that was the culture in the 80 and 90's home computers, as you mention.

Which again is hardly different from UNIX culture, which doesn't matter what the hardware is capable of, as long as, it runs UNIX and given that the UNIX culture never cared for the desktop experience (Xlib and Motif really?!) that gives a clash of cultures.

> only response I tend to get is a smug, "Eh, just buy a Mac Book."

Of course.

Back in the day we had to buy Commodore 64, Spectrum, Spectrum +, Spectrum +2A, Spectrum +3, Atari ST, Atari Falcon, Amiga 500, Amiga 1200, PC, .... and Mac.

So those of us that enjoy a packaged experience of OS + Software + Dev Tools are more than used to it.

The culture of the hardware doesn't matter, just give me a CLI and a 2D frame buffer isn't the culture of the desktop computers.

6502 on the Commodore, z80 on the ZX's, 68k on the Ataris, Amigas, and Macs, x86 on the PC (and different hardware architectures, even when they had the same family of CPU)...compared to x86_64 on a PC architecture for just about anything now, with the biggest hurdle being legal, not technical.

That's not an "Of course" situation. It's a "bang your head against the wall in frustration" situation. The hardware is commodity hardware, so the software runs on the same hardware that everyone owns, but you're legally required to pretend that it doesn't.

> x86_64 on a PC architecture for just about anything now,

Not in any of my pockets or devices at home, besides the laptop.

In context of the discussion, we seem to be talking about personal computers, not hand-held devices, and my comment reflects that.

A tablet with a physical keyboard is a personal computer.

Nor does it run OSX.

https://www.youtube.com/watch?v=1zPYW6Ipgok

...and? I think I see the point that you're trying to make, but I don't think that it's pertinent to the discussion. A tablet is still a "personal computer" (solely as a descriptive term) without the keyboard, and regardless of Apple marketing. But it's not a "personal computer", in the same sense that common usage of that word doesn't include (most) tablets, smartphones, PDAs, programmable calculators, etc.

But, we digress. Tell me again how it's reasonable that hardware that will run OSes 1, 2, and 3 shouldn't be allowed to run OS 1, because the hardware doesn't have a fruit sticker on the side.

Old hardware was inherently incompatible software-wise, due to widely varying CPU and system architectures. ARM and MIPS hardware today somewhat mirrors that on a device-by-device level; every model has different interconnections between its components and often different mixes of components connected in. Luckily, we've got OSes that provide relatively robust hardware abstraction layers, so that the same software package from my 2010 device is highly likely to run on my 2016 device. I think that strengthens my argument: when even widely varied hardware isn't much of a barrier to software interoperability, why should we be satisfied with legal limitations?

And anyhow, the point was software development. Going into the definition of what is and isn't a PC is a bunch of BS semantics. Let's drill down to the devices that are pertinent to the discussion: The set of devices that are technically capable of native (as opposed to web) OSX and iOS development, and the set of devices that are legally capable of the same. Those are what the discussion is about.

No doubt. However, in the past, we physically couldn't do what we can do now. At the moment, this is a EULA problem. If Apple changed a single line, that'd solve a ton of problems for developers and they can still have their packaged experience.

And there are people talking about the "numbered" days of macOS. It's pretty crazy.

Reply on news.ycombinator.com