Jason Snell:
In 2018, I want to see a new Mac Pro. But more than that, I want to see it really live up to Apple’s statements that it will be modular and expandable.
[…]
2018 is the year for the Mac mini revival. The Mac mini is never going to be a major part of Apple’s Mac product line, but it adds a huge amount of versatility to the platform, and that’s reason enough to keep it around.
[…]
But for the third straight year, I’m also hoping that we’ll see a proper MacBook update, one that does more than just speed up the internals.
[…]
I think it’s time for Apple to backtrack on a design misstep and change the keyboard on the MacBook Pro. A pro laptop deserves a great keyboard, not one that was built as a compromise in exchange for the ultra-thinness of the MacBook.
[…]
If Apple’s truly committed to the Touch Bar for the long term, it’s time to see some progress.
[…]
The most important thing to do is keep the platform stable. Reduce bugs, remove security flaws, and keep everything running smoothly.
Rene Ritchie:
Apple gets told it’s wrong so goddamn always the company can no longer tell when it’s really wrong. At least not in a way that prevents it from happening or course-corrects it quickly.
Hopefully, iMac Pro and the upcoming new Mac Pro are signs Apple recognizes this danger. Not just at the highest end of the lineups and not just after the fact — but across all of its products and well in advance of what’s going into production next.
[…]
These products have not been significantly updated in years yet they’re still being sold. Apple hasn’t discontinued any of them but it also hasn’t shown any sign of them being continued.
Apple typically doesn’t talk about future products. It leaves the old product up, unchanged, until a new product comes along to replace it. And that works, when we’re talking a year, maybe two at the outside. When we’re talking multiple products over multiple years, it stops working.
[…]
These are all growing pains. The problems that come with a company based on focus having to focus on multiple things at the same time. They’re problems of scale.
But unless Apple wants to go back to only making one or two products, its the core problem Apple absolutely has to solve in 2018.
Maynard Handley:
Yes it’s hard to slot new people into existing extremely difficult programming like the kernel.
It is NOT hard to hire merely competent people to fix the on-going bugs in apps like Finder or iTunes, or to write tests, or to deal with BugReporter reports.
Juli Clover:
Let us know what you want to see in the comments, and make sure to check out our What to Expect post to get a glimpse at the current rumors.
Apple Apple Software Quality iOS iOS 11 Keyboard Mac Mac mini Mac Pro MacBook macOS 10.13 High Sierra Touch Bar
Jason Snell:
One of my most common audio workflows involves grabbing audio files from panelists, converting them to WAV format via the ffmpeg command line tool, removing background noise via iZotope RX 6’s Spectral Denoise filter, writing that file back to disk, and using the private-beta tool sidetrack to sync the panelist’s file up with a reference track. There’s a lot of processor-intense stuff in there, as well as some disk access.
It took my 2014 5K iMac 160 seconds to perform all of those tasks; it took the iMac Pro 96 seconds, meaning that the iMac Pro was able to do the job in 60 percent of the time. Isolate just the processor-intensive task of denoising three hours of audio, and the 5K iMac took 94 seconds, versus 49 seconds for the iMac Pro—a little more than half the time.
I frequently take large 1080p videos export from editing apps and slim them down into versions I can upload to YouTube or post for a video podcast via the HandBrake video-encoding app. I performed one of these encodes on both the 2014 5K iMac and the iMac Pro; the 5K iMac encoded the video in 21 minutes and 16 seconds, while the iMac Pro took 11 minutes and 14 seconds. Once again, that’s a little more than half the time. It’s enough for me to declare that for jobs optimized for multiple processor cores, this base model iMac Pro is nearly twice as fast as the top-of-the-line 5K iMac from 2014.
Max Yuryev (via Václav Slavík):
After the second test, each additional run would cause the iMac Pro to slow down the CPU when the temperature reached roughly 94C, which caused the clock speed to drop from 3.9ghz to about 3.6ghz for a second or two. This allowed the CPU to drop below 92C, and the clock speed to rise back to the maximum turbo boost of 3.9GHz.
Interestingly, even after 10 consecutive benchmarks, the iMac Pro fans were barely audible. Instead of ramping up the fan speed to keep the CPU at its maximum turbo boost speed, the iMac Pro just kept the cycle going, with the clock speed dipping every 10 seconds or so while staying very quiet.
[…]
With that said, it is a bit disappointing to see Apple prioritize noise over performance and thermals on a high-end pro machine.
Ben Cunningham:
I’ve been trying out an iMac Pro for FCPX editing and have been really disappointed with the performance. This review confirms it: in many cases, the iMac Pro performs WORSE than this year’s iMac[…]
I can also confirm this reviewer’s findings: the CPU and GPU are seriously underutilized when dealing with any common formats, like H264 or ProRes. The Pro only starts to show an advantage when dealing with H265/Raw/8k formats.
rob-ART morgan:
In this article we highlight CPU and GPU performance of the ‘low end’ iMac Pro (with optional GPU) compared to two popular Mac Pro configurations and the fastest iMac 5K.
[…]
Apple did its homework when planning the iMac Pro. As you can see from the results above, it beat both beefy Mac Pros in CPU performance. And if we had not jury-rigged an RX Vega 64 in the 2010 Mac Pro tower, it would have won 3 out of the 4 GPU contests.
On the other hand, maybe the fact that an 8-year-old Mac Pro with an updated GPU can beat a current iMac Pro means that GPUs should be upgradeable.
Previously: The iMac Pro.
Update (2018-01-02): See also: iMac Pro Teardown.
Update (2018-01-03): Tuomas Artman:
First iMac Pro tests indicate that you’ll get almost no Swift Xcode compilation performance gains compared to a recent MBP.
Daniel Martín:
Assuming a good benchmark test, this is not very surprising. Parallelism is only exploited at the later stages of compilation; SIL generation, importing, and type checking never run in parallel, for example. Using WMO also exploits parallelism worse.
Troy Gaul:
Decided to do a few Xcode build timings of the iMac Pro. It’s about twice as fast as my [2016] 15” MacBook Pro.
Average full build times for Linea (simulator, debug build):
- iMac Pro (3 GHz 10-core, 64GB): 17.76 sec
- MacBook Pro (2.9 GHz 4-core i7, 16GB): 33.14 sec
A bit of context: Linea is written in Swift (about 200 .swift files of varying sizes) and only includes a little Objective-C and few dependencies. Build times were done in the Xcode app after cleaning twice (to avoid pre-build and indexing).
Update (2018-01-08): Steven Frank:
Very unscientific benchmark: re-encoding a 12m WMV video to MP4 with ffmpeg -- Mac Pro 2010 (12 core) 5:54 -- Mac Pro 2013 (6 core) 6:57 -- iMac Pro (10 core) 3:21
Nothing surprising, but I was surprised how much I'd future-proofed myself by buying a 12-core Mac in 2010. iMac Pro10-core is almost but not quite 2x as fast. Still trying to convince myself to hold off until the mythical modular Mac is revealed.
See also: Lloyd Chambers.
Oliver Peters (via Hacker News):
After all of this testing, one is left with the answer “it depends”. The 2013 Mac Pro has two GPUs, but not every application takes advantage of that. Some apps tax all the available cores, so more, but slower, cores are better. Others go for the maximum speed on fewer cores. All things considered, the iMac Pro performed at the top of these three machines. It was either the best or close/equal to the best. But, this is an incremental difference in the 10% to 30% range. But, of course some of these numbers will be meaningful and others won’t, depending on the apps used and a user’s storage situation.
Update (2018-01-11): See also: Lloyd Chambers.
Update (2018-01-12): James Thomson:
Rough first benchmark - doing a full build of PCalc in Xcode on this iMac Pro takes around 56s, compared to 92s on my 1st gen iMac Retina 4Ghz i7. Less of an improvement than I would have hoped to see for having six more cores, if I’m being honest.
See also: Accidental Tech Podcast.
Update (2018-01-17): Mark Bernstein:
The new iMac Pro builds Tinderbox from scratch in 30sec — about 6x my trusty MacBook Pro 15. In other respects, it’s just fast, but for compiling and running code, it’s blazing.
Update (2018-02-27): Orta Therox:
Interesting that it’s the Hackintoshes that are at the top of @ashfurrow’s Xcode Hardware Performance charts.
Update (2018-03-30): Peter Steinberger:
iMac Pro builds our project almost twice as fast as a 2015y iMac. (6 minutes. Maxed Mac Mini takes around 30)
Update (2018-05-10): See also: Austin Mann.
Audio Final Cut Pro X Hackintosh HandBrake iMac Pro Mac Mac Pro macOS 10.13 High Sierra Programming Swift Programming Language Thermal Video
Siguza (via Patrick Wardle, Hacker News):
This is the tale of a macOS-only vulnerability in IOHIDFamily that yields kernel r/w and can be exploited by any unprivileged user.
[…]
The thing is that between this line:
eop->evGlobalsOffset = sizeof(EvOffsets);
and this one:
evg = (EvGlobals *)((char *)shmem_addr + eop->evGlobalsOffset);
The value of eop->evGlobalsOffset can change, which will then cause evg to point to somewhere other than intended.
From looking at the source, this vulnerability seems to have been present at least since as far back as 2002.
Siguza:
I would’ve submitted to Apple if their bug bounty included macOS, or if the vuln was remotely exploitable.
Siguza:
And an engineer from Apple’s security team contacted me a bit after releasing - they had found the bug a while ago, but hadn’t verified the subsequent patch which actually didn’t fix it. And a while ago I tweeted this (try diff’ing sources to find it :P). So they do have people on it. I also told that person to extend my condolences to whoever has to come in and fix that now, but they basically said that there’s nothing to apologise for and that they (the team) really like such write-ups.
Previously: identityservicesd: What If Anyone Can Be You?, Explanation of HomeKit Vulnerability.
AppleScript Bug Kernel Mac Mach Kernel macOS 10.13 High Sierra Programming Security System Integrity Protection
Howard Oakley:
So how did this third-party kernel extension end up in this mysterious folder, complete with SIP protection? Surely SIP is there to protect macOS, not third-party app components installed later by the user? Who or what enabled SIP on that extension, and how can it be removed?
[…]
High Sierra has a new mechanism for handling third-party kernel extensions (User-Approved Kernel Extension Loading, or UAKL), which requires the user to authorise them. When a third-party installer tries to install a kernel extension, you see the warning[…] High Sierra then packages the extension in the form of a non-executable stub app, which it installs in /Library/StagedExtensions/Applications.
[…]
Thus SIP prevents the user from uninstalling a third-party app which the user installed, even though the kernel extension might be rendering macOS unstable, or have other significant side-effects.
Previously: Kernel Extensions in High Sierra.
Update (2018-01-03): See also: Hacker News.
Bug Kernel Extensions Mac macOS 10.13 High Sierra System Integrity Protection
Simogo:
This year we spent a lot of time updating our old mobile games, to make them run properly on new OS versions, new resolutions, and whatever new things that were introduced which broke our games on iPhones and iPads around the world. We’ve put months of work into this, because, well, we care that our games live on, and we want you to be able to keep playing your games. Had we known back in 2010 that we would be updating our games seven years later, we would have shook our heads in disbelief.
This year, a lot of time we had planned to spend on our current project, ended up being spent on just making sure that our games would not be gone from the app store. Because sadly, the platform holder seems to have no interest in preservation of software on their platform. We can criticize and be angry and mad about it all we want, but we don’t think that any efforts we put in can change that direction.
[…]
The ease of mobile game development drew us to making iPhone games back in 2010. But, it’s getting increasingly financially unviable, tiring and unenjoyable for us to keep on making substantial alterations for new resolutions, guidelines, and what have you, as they seem to never end. The appeal of the mobile platform is less evident today than it was a few years back. Before we started Simogo, we had made console games, and had grown really tired of the clunky processes, politics, certifications and primitive development environments that was involved in making a console game. Today, a lot of that clunkiness is gone, and sadly, for a small developer like us, mobile has become more difficult to support than consoles. Releasing a mobile game means supporting it perpetually, and justifying that is tough for us, at the moment.
Via Craig Grannell:
Apple should treat this as a body blow. Simogo has consistently been one of the best developers on the platform, pushing the boundaries of gaming in new and interesting directions. Device 6, in particular, remains a masterclass in touchscreen game development – a strange puzzle/adventure hybrid, where you explore corridors composed of the very words in the game’s narrative. Sure, it could be made for a traditional console or PC – but it’d make far less sense.
[…]
I’ve heard similar from other developers. It’s such a shift from when I visited an EA developer press event around 2012, when indies they’d got on board were brimming with excitement about iOS gaming. Then, it was a breath of fresh air – less hassle with platform issues and gatekeepers alike. But iOS has become a moving target in a way it never used to be.
Matt Birchler:
7 of the top 10 selling games on Amazon last year were Nintendo exclusive games. That’s positively nuts!
Lukas Mathis:
Telling Nintendo to abandon its hardware platform for iOS was never a good idea. It doesn’t help Nintendo, and it doesn’t help iOS. There is no sustainable market on iOS for really good, non-abusive, fairly priced mid- to high-budget games, and Nintendo can’t fix that. The only company that can fix that is Apple.
Previously: Super Mario Run’s Disappointing Profit, Nintendo.
Update (2018-01-19): NintendoSoup:
In a NPD research, the Nintendo Switch is the best selling console in history when comparing the console’s first 10 month sales data with every other console’s first 10 month.
64-Bit App Store Business Game iOS iOS 11 iPhone X Nintendo
