Yes, it's been awhile since the mini and Mac Pro have been updated or upgraded but is it really hurting you?
Actually, yes. I have a 2013 quad-i7 Mini (fast with 1 TB SSD) that I'd like to upgrade or replace. However the current Mini is a less-capable system.
In fact, my brother-in-law recently gave up waiting for a new Mac Pro and bought a used Mini similar to mine (for various reasons, iMac is not a suitable solution for him).
>However, Apple hasn't been actively pushing Macs at Windows users lately.
Actually Apple hasn't been actively pushing Macs at a rather large group of existing Mac users either.
Mini, Mac Pro and to some extent MacBook Pro users have been neglected, pushed out in the cold for years. Add to them macOS Server users, and with the deprecation of OpenGL, an entire class of high end graphics and scientific users from whom the ability of running iOS apps is virtually irrelevant.
Yes. The installed base of Mac users is ~150M. The installed base of iOS users is ~1,150M
The media narrative that Apple isn't updating Macs
Media narrative? - What planet are you living on?
Besides ALL the iOS users are 100% dependent on Macs.
Not a single app is created without a Mac.
NOT catering to the developer community who creates and maintains those apps is over time cutting the branch you sit on.
NOT catering to the IT professionals running the backends and infrastructures for those devices in everything from small businesses to large enterprises is over time cutting the branch you sit on.
As a dev I can heartily say you’re full of it.
Docker works fine on my 2016 MBP. XCode works great. Swift is very nice.
If you don’t need mobility then the MBP isn’t designed for you. Buy an iMac. If you do need mobility (as in you actually travel) the current MBPs are better than the older ones.
And with eGPUs you can have both power and mobility, although at slightly higher cost than just an iMac.
Docker works depending on what you want to run on it. One example is UNMS - Ubiquiti Network Management System they cannot get to work reliably in Docker for macOS. Besides if you really want to use Docker for anything but hobby and some testing there are virtually no hardware from Apple any more that makes sense to deploy it on.
No, the 2016 MBP is not designed for me. For lengthy Xcode builds that routinely takes 50 minutes with all cores active, due to the thermals of the 2016 MBP it starts throttling a few minutes into the build. - NOT GOOD!
Even for testing the application stability on that hardware that many users may end up with (for any reason), the GPU also starts throttling after a few minutes. So it is useless.
International pricing is also an issue when a moderately configured 2016 MBP 15" set you back over $3700, that is also not very good.
In addition there are 4 minis in a setup to properly test the software (backend for multiple clients), and they all are looking long in the tooth since new i7 minis cannot be had. The ability to run multiple processes at full load is much more important than absolute processor speed.
1) You don’t deploy production docker instances on Macs. You develop on Macs and deploy on production servers. That’s one major reason to use Docker in the first place...so the transition from dev to ops environment is lower.
2) While Docker For Mac runs on hyperkit, Docker toolbox uses virtual box and UNMS should have no issues.
3) Unless you are consistently doing 50 min builds on an airplane or hotel room you should have bought an iMac. What are you building that takes 50 mins anyway? Why isn’t this being done on your CI server? XCode 9 now has XCode server built in.
4) If your backend is dockerized then you can test on AWS. WTF would you use Docker and then lock yourself to testing on Mac mini’s?
$1750 4 core Mac Pro. International Shipping to Europe and maybe some other countries (dunno where you are). Apple refurbished with 1 year Apple Warranty...maybe.
Also it used to be that businesses could deploy their production to Apple hardware. It could even be racked alongside the other production servers.
With the removal of anything server from Apple's portfolio, I suppose you could always put a bunch of iPad Pro's in a nice rack enclose and use them as "blade servers". </sarc> The 4 core Mac Pro - seriously?? 2013 tech? This config? has 75% of the memory I have in my MBP, 1/4 of the SSD storage. Not a single user of the app will have this machine, so it isn't even a valid test config.
You really should check out MacStadium, if you're that invested in the Mac minis.
There are many clever solutions, but these are not particularly space or service friendly. In my view it serves to illustrate there is a need for space efficient server centric hardware also from Apple.
You may have a point about server centric hardware from Apple, but I have used MacStadium and they are quite a service friendly setup. The quality of their Mac hosting services is quite fabulous.
>However, Apple hasn't been actively pushing Macs at Windows users lately.
Actually Apple hasn't been actively pushing Macs at a rather large group of existing Mac users either.
Mini, Mac Pro and to some extent MacBook Pro users have been neglected, pushed out in the cold for years. Add to them macOS Server users, and with the deprecation of OpenGL, an entire class of high end graphics and scientific users from whom the ability of running iOS apps is virtually irrelevant.
Yes. The installed base of Mac users is ~150M. The installed base of iOS users is ~1,150M
The media narrative that Apple isn't updating Macs
Media narrative? - What planet are you living on?
Besides ALL the iOS users are 100% dependent on Macs.
Not a single app is created without a Mac.
NOT catering to the developer community who creates and maintains those apps is over time cutting the branch you sit on.
NOT catering to the IT professionals running the backends and infrastructures for those devices in everything from small businesses to large enterprises is over time cutting the branch you sit on.
As a dev I can heartily say you’re full of it.
Docker works fine on my 2016 MBP. XCode works great. Swift is very nice.
If you don’t need mobility then the MBP isn’t designed for you. Buy an iMac. If you do need mobility (as in you actually travel) the current MBPs are better than the older ones.
And with eGPUs you can have both power and mobility, although at slightly higher cost than just an iMac.
Docker works depending on what you want to run on it. One example is UNMS - Ubiquiti Network Management System they cannot get to work reliably in Docker for macOS. Besides if you really want to use Docker for anything but hobby and some testing there are virtually no hardware from Apple any more that makes sense to deploy it on.
No, the 2016 MBP is not designed for me. For lengthy Xcode builds that routinely takes 50 minutes with all cores active, due to the thermals of the 2016 MBP it starts throttling a few minutes into the build. - NOT GOOD!
Even for testing the application stability on that hardware that many users may end up with (for any reason), the GPU also starts throttling after a few minutes. So it is useless.
International pricing is also an issue when a moderately configured 2016 MBP 15" set you back over $3700, that is also not very good.
In addition there are 4 minis in a setup to properly test the software (backend for multiple clients), and they all are looking long in the tooth since new i7 minis cannot be had. The ability to run multiple processes at full load is much more important than absolute processor speed.
1) You don’t deploy production docker instances on Macs. You develop on Macs and deploy on production servers. That’s one major reason to use Docker in the first place...so the transition from dev to ops environment is lower.
2) While Docker For Mac runs on hyperkit, Docker toolbox uses virtual box and UNMS should have no issues.
3) Unless you are consistently doing 50 min builds on an airplane or hotel room you should have bought an iMac. What are you building that takes 50 mins anyway? Why isn’t this being done on your CI server? XCode 9 now has XCode server built in.
4) If your backend is dockerized then you can test on AWS. WTF would you use Docker and then lock yourself to testing on Mac mini’s?
$1750 4 core Mac Pro. International Shipping to Europe and maybe some other countries (dunno where you are). Apple refurbished with 1 year Apple Warranty...maybe.
1. No I don't.
If you happened to pay attention I said i7 minis in the test environment. – You know the species that went extinct around 2012 only to be spotted on eBay since. A species that existed even before Docker for macOS even was a remote possibility. So neither test nor production is dockerized (and even if it can be, it will just need more memory and resources overall.)
Also it used to be that businesses could deploy their production to Apple hardware. It could even be racked alongside the other production servers.
With the removal of anything server from Apple's portfolio, I suppose you could always put a bunch of iPad Pro's in a nice rack enclose and use them as "blade servers". </sarc>
2-5. You just confirmed what I said, Apple's most Pro portable cannot be used as a developer machine if you throw at it lengthy builds. – You have to have an iMac, and a CI server with Xcode 9. God forbid being a developer who move between offices, meeting rooms and clients all day, who work in an environment where you don't have a fixed desk, who demo solutions or discuss ideas at client locations. - NO, you have to have an iMac!
The 4 core Mac Pro - seriously?? 2013 tech? This config? has 75% of the memory I have in my MBP, 1/4 of the SSD storage. Not a single user of the app will have this machine, so it isn't even a valid test config. And what's with the building that takes 50 minutes anyway. - You're winning there too because this baby will soon go away like every other solution using OpenGL. Problem solved! Another of those pesky Mac users gone...
I guess I am holding my iPhone wrong too.
Another “expert” unwilling to use modern workflows and prefer to do it the 2008 way.
1) if you don’t use modern dev ops then too bad for you. The back end stuff can and should run anywhere. Testing on minis is stupid. The minor resource cost penalty for Docker is well worth the savings in deployment. Deploying in the cloud is a lot better than self managed xserves.
2) you don’t rebuild demos at the client site and certainly not for 50 mins. If you are a dumbshit crippling your devs to work on a 15” screens on a regular basis you deserve what you get. That’s ignoring that in an office environment you should have fast networking and able to hit your ci servers to rebuild as needed. And 50 min rebuild time implies you are using your build system wrong whatever it is and your dependency graphs are completely hosed.
At the startup I was at the primary devs had high end iMacs with a second 4K display because that was just a lot more productive than working with just a laptop. There were demo laptops to use at client sites. Only devs that regularly developed at client sites had MBP and often it was easier to just fedex an iMac to the client site than carry a huge desktop replacement laptop like the Dell Precision around.
3) you use the Mac pros as inexpensive CI machines moron and you can add as much memory and storage as needed. It’s cheap and fast and 2013 or not those machines work well.
4) if you are so stupid you are unable to deploy your app with Vulkan over the next few YEARS before OpenGL is removed (if ever) you deserve to be left behind
Whether you use Macs or PCs running Windows or Linux makes no difference. You’re doing things in a stupid way. Devs needs screens and work spaces that don’t suck. Preferably quiet workspaces so they can actually code and not “cool open concept” and shared spaces where it is hard to concentrate. They are more productive with modern workflows, tools and first class devops support. Testing can and should be done with automated regression tests as part of your CI builds and system testing done on target platforms and not minis.
4. What is Apple's support of Vulcan? - ZERO! So that sounds like a brilliant strategy for future development if you want to stay on their platforms.
If you can’t deliver a MacOS app with Vulkan support in 2-3 years you suck as a dev shop. By then it’s going to be trivial to do so. Today any semi decent dev shop can likely do it with some effort.
I bundle and deliver java apps all the time without any Apple support. It’s completely trivial to do so.
You and cropr like talking BS about how Macs can’t be good dev machines because frankly you suck as devs shops and don’t use tools that Apple provides or use them in sub-optimal ways.
If it takes your devs 50 mins to compile you are doing it wrong and rebuilding everything too much. If you are testing backend services on Mac mini’s you are doing it wrong. If you are testing your OpenGL apps on a mini you’re doing it wrong because that’s not your most likely customer machine.
I can compile from scratch a 800 KLOC Application + Embedded Framework in less than 50 min on my MBP inside Docker. When just changing one app it takes no time because my build system doesn’t recompile everything. Just recompile the app and a rebuild of the elf for the arm target.
I can compile from scratch a 800 KLOC Application + Embedded Framework in less than 50 min on my MBP inside Docker. When just changing one app it takes no time because my build system doesn’t recompile everything. Just recompile the app and a rebuild of the elf for the arm target.
So you're running xcode-build inside Docker on your MBP running macOS?
In comparison our 1.3 MLOC builds in about 50 minutes from scratch on bare macOS. With Xcode 10 beta it is actually faster.
I can compile from scratch a 800 KLOC Application + Embedded Framework in less than 50 min on my MBP inside Docker. When just changing one app it takes no time because my build system doesn’t recompile everything. Just recompile the app and a rebuild of the elf for the arm target.
So you're running xcode-build inside Docker on your MBP running macOS?
In comparison our 1.3 MLOC builds in about 50 minutes from scratch on bare macOS. With Xcode 10 beta it is actually faster.
Inside docker it’s gcc cross compiled to arm and cmake. The bulk of our code is embedded UAV stuff.
For the UI for ground stuff we use unity, arcgis and Xcode. I haven’t had to work on that in a while so don’t recall the code size. Middling sized...200-300ish KSLOC. Mostly I pull the stable artifact out of the CI builds but rebuilding from scratch isn’t memorably bad.
Xcode 9 has/had some issues with storyboards but we don’t use those as much. There were iOS simulator issues with but not, IIRC, compile. There was something about XCode indexing that went away.
50 min build time likely means something is wrong and you should spend effort to fix it. Try this as a temporary bandaid: create a 1-2 GB ram disk...yes you should have plenty to just run xcode and other normal dev stuff on a 16GB machine...and set xcode to use that for derived data. Googling xcode ramdisk should find current instructions. I havent done that in a while but even vs a ssd was faster. That’s just a bandaid that could buy you time to track down what’s really killing performance.
compiling even your codebase should be go grab a coffee...not startup Netflix and watch a show. Xcode has had wierd bugs but that has nothing to do whether the MBP is too slow for development. I remember there was some bug that drove even the 12 core Mac Pro to its knees trying to compile swift that was fixed later by Apple. The dev forums were all like Xcode broken! Can’t do work!
As an Apple Mac user (mac mini), Apple has pushed me to get a Windows machine. Apple has let the headless mac waste way on purpose, and adding insult to customers, selling >4 year old hardware at release-day prices. That is indicative of how much Apple cares about the mac, macos and its customers. Action speaks louder than words.
And also, a new dark theme as the main feature MacOS Majave? Well, that really says it all.
Go get a NUC computer. Why should the Mac Mini or Mac Pro be update more than once every 5 years?
i believe the part that gave me the most insight was the part about new Continuity features in Mojave.
iOS, and more specifically, iPhone, as an extension of larger, less portable (less pocketable, or, even less wearable) device(s). functioning as input tool, camera, QR code reader, scanner, as pedometer, as workout info gatherer. yes, as data source peripheral device !
iOS/iPhone as an a mobile extension of/to/for macOS devices.
thank you for leading me to this. its brilliant.
my own personal wish is to see a MacBook Air as the true total fulfilment of this. still ultralight, and with the best functional power and capability possible in a light weight device. not dumb downed in any way, except for real work limitations for heat, etc. thanks to even base line models of macs becoming so powerful, i increasingly want a simpler device that mimics iOS, but built for a larger screened device with a trackpad and conventional keyboard (hopefully with a keyboard with keys that have alot of travel!!!! /s).
Comments
Actually, yes. I have a 2013 quad-i7 Mini (fast with 1 TB SSD) that I'd like to upgrade or replace. However the current Mini is a less-capable system.
In fact, my brother-in-law recently gave up waiting for a new Mac Pro and bought a used Mini similar to mine (for various reasons, iMac is not a suitable solution for him).
If you can’t deliver a MacOS app with Vulkan support in 2-3 years you suck as a dev shop. By then it’s going to be trivial to do so. Today any semi decent dev shop can likely do it with some effort.
I bundle and deliver java apps all the time without any Apple support. It’s completely trivial to do so.
You and cropr like talking BS about how Macs can’t be good dev machines because frankly you suck as devs shops and don’t use tools that Apple provides or use them in sub-optimal ways.
If it takes your devs 50 mins to compile you are doing it wrong and rebuilding everything too much.
If you are testing backend services on Mac mini’s you are doing it wrong.
If you are testing your OpenGL apps on a mini you’re doing it wrong because that’s not your most likely customer machine.
I can compile from scratch a 800 KLOC Application + Embedded Framework in less than 50 min on my MBP inside Docker. When just changing one app it takes no time because my build system doesn’t recompile everything. Just recompile the app and a rebuild of the elf for the arm target.
D.E.D. delivering 30 pages about how my most admired company and product "is going to be coming in hot!".
In comparison our 1.3 MLOC builds in about 50 minutes from scratch on bare macOS. With Xcode 10 beta it is actually faster.
For the UI for ground stuff we use unity, arcgis and Xcode. I haven’t had to work on that in a while so don’t recall the code size. Middling sized...200-300ish KSLOC. Mostly I pull the stable artifact out of the CI builds but rebuilding from scratch isn’t memorably bad.
Xcode 9 has/had some issues with storyboards but we don’t use those as much. There were iOS simulator issues with but not, IIRC, compile. There was something about XCode indexing that went away.
50 min build time likely means something is wrong and you should spend effort to fix it. Try this as a temporary bandaid: create a 1-2 GB ram disk...yes you should have plenty to just run xcode and other normal dev stuff on a 16GB machine...and set xcode to use that for derived data. Googling xcode ramdisk should find current instructions. I havent done that in a while but even vs a ssd was faster. That’s just a bandaid that could buy you time to track down what’s really killing performance.
compiling even your codebase should be go grab a coffee...not startup Netflix and watch a show. Xcode has had wierd bugs but that has nothing to do whether the MBP is too slow for development. I remember there was some bug that drove even the 12 core Mac Pro to its knees trying to compile swift that was fixed later by Apple. The dev forums were all like Xcode broken! Can’t do work!
when will they add features to the iPhone/iPad version of iWork and port the software over to Mac?
thank you for writing this.
i believe the part that gave me the most insight was the part about new Continuity features in Mojave.
iOS, and more specifically, iPhone, as an extension of larger, less portable (less pocketable, or, even less wearable) device(s).
functioning as input tool, camera, QR code reader, scanner, as pedometer, as workout info gatherer.
yes, as data source peripheral device !
iOS/iPhone as an a mobile extension of/to/for macOS devices.
thank you for leading me to this. its brilliant.
my own personal wish is to see a MacBook Air as the true total fulfilment of this.
still ultralight, and with the best functional power and capability possible in a light weight device. not dumb downed in any way, except for real work limitations for heat, etc.
thanks to even base line models of macs becoming so powerful, i increasingly want a simpler device that mimics iOS, but built for a larger screened device with a trackpad and conventional keyboard (hopefully with a keyboard with keys that have alot of travel!!!! /s).