5 ms·

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" becau

by kxyvr 10y ago

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.

pjmlp 10y ago
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.
- kxyvr 10y ago
  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."
  - mbreese 10y ago
    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...
    - pjmlp 10y ago
      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.
    - flukus 10y ago
      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.
      - mbreese 10y ago
        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.
- ianai 10y ago
  And there are people talking about the "numbered" days of macOS. It's pretty crazy.
- deleted 10y ago
  [deleted]
macco 10y ago
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.
- swozey 10y ago
  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.
  - fizzbatter 10y ago
    > 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. :)

by kxyvr 10y ago

pjmlp 10y ago

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.

kxyvr 10y ago
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."
- mbreese 10y ago
  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...
  - pjmlp 10y ago
    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.
  - flukus 10y ago
    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.
    - mbreese 10y ago
      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.
ianai 10y ago
And there are people talking about the "numbered" days of macOS. It's pretty crazy.
deleted 10y ago
[deleted]

macco 10y ago

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.

swozey 10y ago
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.
- fizzbatter 10y ago
  > 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. :)