Author: Colin Cornaby

  • Mac Games at WWDC 2023

    I’ve been really impressed by the games sessions so far at WWDC 2023. One of my complaints about Metal has been with the really small amount of community documentation – it can be difficult to find resources specifically on porting from DirectX. It looks like a problem Apple is really beginning to tackle.

    Automated conversion from HLSL based shaders is also a really good improvement. I’d love to see them support SPIRV shader conversion as well for personal reasons, but DirectX/DXIL is clearly the best starting point.

    Of course the big news is DirectX 12 to Metal translation – through a new Game Porting Toolkit and D3DMetal.

    D3DMetal

    I’ll start with what D3DMetal and the Game Porting Toolkit are not. They don’t automate ports of DirectX games to Mac. They’re not a capability of macOS Sonoma – nor do they ship with Sonoma. They don’t create a starting point for a port. You cannot ship a game with D3DMetal. They’re not open source and the licensing terms seem to forbid using D3DMetal in a shipping title.

    D3DMetal is a demonstration tool to show that a game can possibly run on the Mac. Apple provides a gameportingtoolkit command line tool that loads up WINE, and then D3DMetal is patched in to translate DirectX calls. DirectX 11 and 12 are supported. The game has to be emulated through Rosetta – and the game is not optimized.

    So – why? It’s strange Apple would invest so much effort into a demo tool.

    In the WWDC sessions – Apple pointed out that it can take a long time for a Metal port to achieve any level of functionality. This creates a long delay until the developer can get a feel of how their game feels on the Mac. The idea is this tool shortens that delay so… the developer feels better about porting? I don’t think it was completely clear in the session.

    But I could probably guess at a few other reasons.

    There’s a lot of doubt about games on macOS and Apple hardware. And there has also been a lot of noise about Apple Silicon not being able to handle DirectX 12 class games. I would bet some of that doubt has been coming from gaming companies themselves. D3DMetal and Game Porting Kit allow Apple to immediately disprove that. Apple is saying “Of course your game can run on the Mac, it’s running right here.” Apple can move the conversation from “Can we port our game to the Mac?” to “Should we port our game to the Mac?”

    D3DMetal is not something that is meant for end users (for reasons I’ll get into.) But my sense is Apple also knows some creative Mac users will be downloading this and running games in it. That creates additional pressure for game companies to have to recognize Mac users and port to the platform.

    Should Apple make D3DMetal a user feature?

    There’s been some talk on if Apple should actually include this translation layer with the operating system. My opinion? No.

    What Apple needs to prove is that Macs can not just run games – but run them well. D3DMetal doesn’t help Apple do that – and I think it’s actually kind of risky to release.

    Game Porting Kit runs games through Rosetta, which is an immediate performance hit. The games are still tailored for GeForce and Radeon cards – and not for Apple Silicon. Because these games are translated on the fly there can be massive stuttering in the games (which is common with WINE and other translators.) And the translator can’t take advantage of other features like offline shader compilation.

    If Apple wanted to put their best foot forward for Mac gaming – this isn’t it. The takeaway would be that while a title can technically play on Mac, it still plays better on a PC. And thats a reputation Apple needs to shed.

    But what about Proton?

    Proton is Valve’s translation layer – built on Vulkan – that allows Windows games to run on Linux and the Steam Deck. If Valve can get a great experience out of game translation, why not Apple?

    As far as I know – Proton only supports Intel compatible platforms. So Proton is able to deliver better performance because it doesn’t have to deal with CPU instruction translation.

    But the other thing to remember is Proton isn’t entirely automated translation. There is a lot of human effort going into Proton – with developers manually patching games for compatibility. Infamously – Valve has even patched games in Proton to eliminate problems that affect the game when running on Windows. Apple’s not interested in setting up some side business patching games manually like Valve has.

    Even games running on Windows can be inconsistent between driver versions and vendors. And Apple really doesn’t want to put in the effort to support a real, consumer ready version of DirectX on Mac.

    D3DMetal Performance

    I haven’t run D3DMetal myself yet – as I don’t have any Macs on Sonoma. But from Apple’s demos it’s pretty clear that it is not the greatest performance. Apple claimed a native Mac port had double the performance of the D3DMetal demo.

    Because I can feel the Mac YouTubers already firing up their video editors – D3DMetal should never be used for benchmarking Macs. If it performs well against a Windows PC thats great. But running games on D3DMetal isn’t the same as a real port. The games are not optimized. No one should take away any performance conclusions from this tool.

    (For what it’s worth – I’d say the same thing about WINE or Crossover. Windows games are optimized for Radeon and GeForce GPUs – not Apple Silicon. These solutions ran better when Macs also used GeForce and Radeon GPUs. But Apple Silicon GPUs have a unique design and require some unique optimizations through Metal.)

  • Mac games and cursor warping weirdness

    On the first internal test of Uru for Mac, I got some weird feedback from testers. As the player character was walking, the game wasn’t responding smoothly to the mouse. As the player moved the mouse to turn the player, the player would turn in fits and starts.

    The way Uru handles the mouse is pretty common for games, especially third person games. You hold down the mouse button, and then move the mouse left or right to make the character move to the left of the right. The mouse cursor is hidden – but the cursor is still there under the hood. That means the cursor may run into the side of the screen, which would cause the cursor not to move and the character to stop moving. To get around that, if the mouse reaches the side of the screen, it’s moved back to center. Effectively this allows for infinite turning of the character without worrying about the mouse hitting the screen edges.

    On macOS, the cursor can be re-centered using the command CGWarpMouseCursorPosition. The docs even mention this exact use case!

    You can use this function to “warp” or alter the cursor position without generating or posting an event. For example, this function is often used to move the cursor position back to the center of the screen by games that do not want the cursor pinned by display edges.

    I created a build of Uru that always showed the macOS cursor, and then ran it. And indeed, there was something wrong with the native mouse handling. Every time I used CGWarpMouseCursorPosition the mouse seemed stuck momentarily. I kept my mouse movements even, but the cursor seemed to not move for a split second after warping. This was causing the chunky mouse behavior testers were noticing.

    See the mouse sticking on reset?

    My first hunch was still mouse acceleration. Maybe the warp function was causing mouse acceleration to reset. That would cause the cursor to start moving slowly again every warp until it reached speed. But when logging the cursor’s X position I found something even weirder. After warp, the cursor wasn’t moving at all.

    2023-02-05 12:21:03.912695-0800 plClient[56084:1669557] Reset!
    2023-02-05 12:21:03.927519-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:03.927660-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:03.944247-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:03.960842-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:03.977446-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:03.994232-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.011021-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.015652-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.027695-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.031597-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.044252-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.047567-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.060862-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.063555-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.077461-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.079589-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.096340-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.111001-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.113572-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.127380-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.129576-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.144342-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.146081-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.160777-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.162525-0800 plClient[56084:1669557] X pos: 0.500000
    2023-02-05 12:21:04.177489-0800 plClient[56084:1669557] X pos: 0.518046
    2023-02-05 12:21:04.177664-0800 plClient[56084:1669557] X pos: 0.537489
    2023-02-05 12:21:04.194020-0800 plClient[56084:1669557] X pos: 0.574978
    2023-02-05 12:21:04.210724-0800 plClient[56084:1669557] X pos: 0.606649
    2023-02-05 12:21:04.227363-0800 plClient[56084:1669557] X pos: 0.654614
    2023-02-05 12:21:04.243930-0800 plClient[56084:1669557] X pos: 0.704136
    2023-02-05 12:21:04.260511-0800 plClient[56084:1669557] X pos: 0.761408
    2023-02-05 12:21:04.265584-0800 plClient[56084:1669557] X pos: 0.782302
    2023-02-05 12:21:04.277291-0800 plClient[56084:1669557] X pos: 0.801745
    2023-02-05 12:21:04.281584-0800 plClient[56084:1669557] X pos: 0.834301
    2023-02-05 12:21:04.293937-0800 plClient[56084:1669557] X pos: 0.852347
    2023-02-05 12:21:04.297583-0800 plClient[56084:1669557] X pos: 0.871790
    2023-02-05 12:21:04.312268-0800 plClient[56084:1669557] X pos: 0.891234
    2023-02-05 12:21:04.313994-0800 plClient[56084:1669557] X pos: 0.912127

    When resetting/warping the cursor, the cursor stays stuck at the midpoint of 0.5 for a full 0.25 seconds. It’s not slowly accelerating. The cursor actually isn’t moving at all after a warp.

    I was fortunate enough to find this Stack Overflow describing exactly whats going on. It seems that, after warping the cursor position, macOS will ignore hardware mouse events for 0.25 seconds. The CGEventSourceSetLocalEventsSuppressionInterval can be used to control this behavior.

    By default, the system does not suppress local hardware events from the keyboard or mouse during a short interval after a Quartz event is posted. You can use the function CGEventSourceSetLocalEventsFilterDuringSuppressionState to modify this behavior.

    This function sets the period of time in seconds that local hardware events may be suppressed after posting a Quartz event created with the specified event source. The default suppression interval is 0.25 seconds.

    Note that the documentation seems contradictory. It says that by default the system does not suppress local hardware events. The last paragraph is actually correct. By default the system will suppress hardware events for 0.25 seconds after a warp.

    With the following C code, we can fix the issue and get the desired behavior.

    CGEventSourceRef eventSourceRef = CGEventSourceCreate(kCGEventSourceStateCombinedSessionState);
    CGEventSourceSetLocalEventsSuppressionInterval(eventSourceRef, 0.0);
    CFRelease(eventSourceRef);

    So – if you are porting a Windows game to macOS and getting weird behavior with CGWarpMouseCursorPosition – CGEventSourceSetLocalEventsSuppressionInterval might be your fix.

  • Scaled Back Apple Silicon Mac Pro?

    Mark Gurman posted an update saying the M2 Extreme chip had likely been cancelled. I’m going to assume what Gurman is reporting is accurate, because it generally is.

    Workstation chips are expensive to design and produce. CPUs like the Xeon are sustainable because Intel splits the development cost over a wide range of customers. It didn’t seem sustainable for Apple to design a workstation chip just for the Mac market. According to Gurman, this is likely a factor in the cancellation of M2 Extreme.

    If Apple is refocusing the Mac Pro on customization and modularity. I think that’s a very good thing. But Apple should go a step further – and bring support for third party GPUs back to Apple Silicon.

    (more…)
  • One Year of Working on Myst Online for Mac/Metal

    One Year of Working on Myst Online for Mac/Metal

    It’s been a year since I started working on the Metal version of Uru/Myst Online!

    In 2020, I received an Apple Silicon Developer Kit. One of the first things I did was make a list of games I wanted to see on Apple Silicon. I wanted to understand the performance of the DTK, and I also wanted to keep some existing titles from being lost in the transition.

    On that list was Uru/Myst Online by Cyan – which holds the distinction of being the only Myst game to never get a native Mac release. Over the years there had been various WINE wrappers but never a real Mac client. If Apple ever cut off Rosetta support, the WINE wrappers might not keep working on the Mac.

    (more…)
  • An Early Eulogy for the Intel Mac Pro

    An Early Eulogy for the Intel Mac Pro

    As Apple gets closer to replacing the Intel Mac Pro, I’m not sure what my next desktop Mac is going to be.

    I’ve always found myself working on many different kinds of projects over the life of my Mac. And it’s been important to me that my Mac should be able to evolve with me. If I have a new graphics project, I should be able to install the GPU that I need. New project going heavy into virtual machine use? Throw in some more storage and RAM. When I needed to learn Metal – I didn’t need to buy a new Mac. I just needed to toss in a new graphics card.

    The closer we get to an Apple Silicon Mac Pro – the more it looks like those things might be lost. RAM slots and upgradable GPUs look like they could be on the cutting block.

    (more…)
  • Breaking up with Twitter

    Since the Twitter buyout saga initially started, I’ve been thinking a lot about how I want to engage with social media. I want to do more medium and long form content about projects I’m working on, such as Metal and games. And I also want to own and control my content.

    Going forward I won’t be posting to my Twitter feed directly. I’ll configure WordPress to tweet out new posts. I may also still respond to tweets, depending on how things go. For those who are still staying on Twitter and have been following me – I hope this is a happy medium that lets you follow what I’m doing even if I’m not longer tweeting.

    (more…)
  • Transitions

    I’m still learning SwiftUI.

    Learning something new is hard. I taught myself programming by typing random commands into HyperCard on a Mac SE. After that, I did REALbasic. When I was 14, I started learning Cocoa using whatever Apple tutorials and sites I could find online. It was a struggle. No one had taught me about classes, polymorphism, or memory management. I wrote a lot of bad code long before I wrote a lot of good code. But I stuck with it because Cocoa seemed like something special. And it was.

    Digging into SwiftUI this week gives me same feelings of being lost in something new, and looking at the future.

    New things can make everyone uncomfortable sometimes. I’ve worked in AppKit for 18 years and UIKit for 10 years. I know right now there are probably a lot of programmers that haven’t even graduated high school yet that can write far better SwiftUI than I can. It’s hard to go from being an expert one day to being a novice the next. I think a lot of developers might feel that way right now too.


    Earlier this week, The Verge posted an article arguing that Apple should make nearly all of their Mac apps Marzipan apps. The idea was that it might hurt the Mac in the short term, but in the long term would make the Mac a better platform.

    I use a Mac to get my work done every day. I spend more time with a Mac than I do nearly anything else in my life. It’s not that I don’t like the iPad. I love my iPad Pro. But I don’t want to see the tool I use every day get worse. I don’t want to have to see the Mac lose for the iPad to do well.

    SwiftUI is amazing because it doesn’t feel like there are any losers. It makes the Mac better. It makes the iPad better. It makes the iPhone better. Heck, it even makes the Apple Watch and Apple TV better. I’m thinking about ways to ship apps for the TV and Watch, and I never would have considered that before. I even have Mac apps I might bring to iPad. I didn’t want to give up the power of AppKit on the Mac, and I didn’t want to maintain two separate code bases. Now I don’t have to choose.

    AppKit and UIKit are going to be around for a while. Carbon was finally removed in Catalina, 13 years after its deprecation. And AppKit and UIKit are probably a long way from even reaching deprecation. It’s very likely both these APIs will be around in some form for at least a decade, probably longer.

    SwiftUI is also very young. It’s amazing which you can try for free, for a 1.0 API, but it’s still 1.0. Features that are missing will be added. I expect other Apple frameworks to also become become more reliant on and cleanly integrated with Combine and SwiftUI as time goes on.

    But none of that diminishes how powerful SwiftUI already is today, and how effortlessly it can integrate into the code I ship. All with the platform features I need to support.

    This is going to be new for everyone. I’m probably going to write some bad code, and I’m probably going to say some stupid things on Twitter. I’m not always going to be a smart guy on the internet (assuming I was before.) But that’s ok. Because it’s all part of getting somewhere better.

  • Reading Between The Lines On Marzipan

    John Gruber today posted some reliably sourced rumors about Apple’s cross platform efforts. Most notably, he’s placing any changes in 2019, and not at WWDC 2018, and casting doubt that what Apple is doing is UIKit on the Mac. (And if you follow me on Twitter, you’re likely aware that I feel that UIKit on Mac would be a bad move.)

    • “XKit” not assured. I read iMore’s article first and got quite excited about the prospect of an “XKit” framework, a unified framework that would replace UIKit (but I think was reading the original, pre-Gruber update article.) It’s worth noting that Gruber’s rumor says nothing about a new UI framework, only a new UI API and declarative toolkit, which is very open ended. API could mean anything between a new class (a la NSNib), or a full set of new frameworks. Later in his post, Gruber speculates that this new API and declarative tool could abstract UIKit and AppKit, or be part of a new UI framework, which is fairly non committal. The Gruber post also does not imply there are dramatic UI changes being made to macOS or iOS to support this new API, but I could see a declarative toolkit opening previously untapped creative avenues. Certainly Apple will want to dogfood such an API on a few applications, which could mean a few new crossover applications, possibly in both directions.
    • Declarative control API. Apple wouldn’t be the first to have one, and declarative UIs are typically written in a markup language, meaning it wouldn’t necessarily be in Swift (or Obj-C). Android has Layout XML, and Microsoft has XAML. I think Apple’s Xib format is also very similar, but I don’t know of any developers writing Xib by hand, and I think the format is too cumbersome to write by hand. Xib also does nothing to abstract the platform differences.
    • Auto Layout. A declarative control API also sounds a little bit like Auto Layout, although Auto Layout is missing is a way to declare controls themselves and not just the relationships between controls. It’s possible whatever Apple is working on is being built on Auto Layout. (Did you know that Auto Layout already has a declarative UI language? It’s uhhhhh…. interesting.)

    Other things to watch for:

    • Tooling. A declarative control API, especially using a markup language like XML, opens up a lot of tooling possibilities. Apple could extend Interface Builder to create these declarative APIs, but I would love them to return to more powerful standalone UI tools. When Microsoft unveiled XAML, they also unveiled a tool called Sparkle, which eventually became Microsoft Expression. The demo video is 13 years old now and is a little dated in a few ways, but I think is still worth a look. Even if Apple doesn’t come in with a high end tool, it would make it easier for a third party developer to come in and fill the void.
    • Dynamic Swift. There is room for this new technology to be all Swift based, but generally I’d still guess like other platforms this is still a better fit for a markup language. The Swift team has been hinting at more dynamic features, and I wouldn’t count on this getting us closer towards being able to deal with our declarative UIs using static style programatic development. I think this will still look like loading the declarative API from an archive format at runtime. It’s speculation. But Swift feels like way too heavy of an option for writing declarative API.

    All in all we don’t know much about Marzipan, or whatever it is called now. But my hunch is it’s a tool to help us deal with UIKit and AppKit, and not a tool to replace it. Although changes to keep us from having to deal with NSView vs UIView would still be welcome.

  • Apple Universal API

    I’ve been thinking about what a unified Apple API could look like. One of the biggest issues is that iOS devices and Mac devices are very different, and even some iOS devices like the AppleTV aren’t even similar to devices like the iPhone or iPad.

    One option Apple has is creating a new, massive API that exists on both iOS and Mac. This is a tremendous undertaking. It’s taken Microsoft many years of public iteration on their Universal Windows API, and adoption has not been quick. And Windows Universal apps are frequently targeted for not feeling like native desktop applications, which is something Microsoft has trying to improve on in the years since Windows 8.

    A brand new API would also have to deal with the platform differences. Is there a good way to force an iOS application developer to think about menus on the Mac as they build their iOS app? Would a Mac app built on this framework simply have it’s menus go missing when it runs on iOS? It doesn’t seem like there is a good option here that doesn’t require losing a lot of what Mac users love, or complicating iOS.

    I was thinking through the timing of this transition, and remembered that Apple will be ending support of 32 bit applications at the same time. One of the biggest problems with the 32 bit runtime on Mac is the fragile base class problem. I won’t get deep into the specifics, you can read more here. But, the fragile base class problem would prevent Apple from making serious changes to the core classes that made up AppKit, or prevent them from changing the class hierarchy.

    But now that Apple could change the class hierarchy, what if we’re wrong about how we think about a shared framework? What if it’s not a layer on top of AppKit and UIKit, but a layer underneath?

    Classes like NSImage and UIImage could be refactored to have a common ancestor, maybe just named Image. When you create an Image you get the platform specific version under the hood, but you can ignore that and work with Image’s shared cross platform functions. When you need something only currently available on the Mac, like image representations, you just downcast your image to an NSImage, and you have all your AppKit functionality back.

    This would solve the hand wringing of losing advanced Mac features because you don’t actually lose anything. And as Mac features are pulled into the common layer as needed, iOS gains the advanced features as well.

    It doesn’t let you write code once and have it run perfectly on both platforms. But I’m not sure that’s the point. I think Apple will want to avoid the mistake Microsoft did, and make developers still think about and specialize their apps on both platforms as necessary, much like they do with the iPad and iPhone. But not having to worry about things like NSImage or UIImage or NSView vs UIView could seriously turbocharge moving code between platforms.

    This sort of setup would also prevent the sort of fallout we saw from the ongoing pure Swift vs Obj-C debate. AppKit and UIKit would continue to exist, just with a shared heritage. There wouldn’t be a need to fight about which API is best, all APIs would win.

  • What should be the 2018 Mac Pro?

    I’m really happy to see Apple’s announcement on the Mac Pro today. Last November I wrote:

    “Even if you think the Mac Pro is going to be updated, Apple’s lack of a mention of it (or the iMac) implies that Apple is still misjudging the expectations of the pro community. When you’re a Pro, you don’t like uncertainty around the tools you need to earn a living. Would you risk your business on a vendor that doesn’t have a clear plan on continuing to support your workflow?”

    “Even a “we’re working on” for the Mac Pro would have gone a long way towards re-assuring a community that depends on Apple’s roadmap for a living.”

    Apple announcing they are working on a new Mac Pro is the right move. It’s something they should have done in 2016 or 2015, but it’s better late than never.

    With the announcement that they’re working on a 2018 completely redesigned Mac Pro, here are some things I’d love to see:

    Returning to a traditional design

    The 2013 Mac Pro looked great, but the design was just problematic. A tower goes on the floor where I don’t need to look at it. With a monitor and speakers already on my desk, I’d be hard pressed to find room for a Mac Pro. The Mac Pro should be built to go on the floor, which probably implies a tower design. The round can design was attractive, but it wasn’t practical.

    Off the shelf PCIe graphics

    The GPU is the quickest aging component of my Mac. On my Mac Pro the GPU is typically outdated after two years (my 2008 Mac Pro has gone through four GPU configs.) I shouldn’t need to change out my pro level hardware every two years.

    Apple and the rest of the PC industry have also all adopted the UEFI standard, which should open up a Mac Pro to a world of PC graphics cards without flashing (assuming the drivers are available on the Mac.) Support for off the shelf standard GPUs would help me get a lot more out of the machine. Yes, standard PC cards would have a bunch of unsightly video ports in addition to the onboard Thunderbolt ports. But I could use those video outputs with compatible monitors if I needed to preserve my Thunderbolt ports for data devices.

    Plenty of pros also use other kinds of PCIe cards, and have to shell out the extra expense to buy Thunderbolt enclosures to house these cards in.

    Multiple GPUs

    Apple talked about single GPU workflows. I’d also like to see two GPUs still be an option. Four PCIe slots, like the classic Mac Pro, would be especially great, as we have obscure workflows at work that really need four GPUs.

    Could this cause problems with the Thunderbolt ports not knowing which video card to use? Sure. But that’s easily solvable with a setting in Displays that lets you pin a display to a GPU.

    Use Existing Standards

    The 2013 Mac Pro has an user upgradable SSD (read the manual) that is also proprietary, and Apple won’t sell you their SSDs. OWC has come out with their own replacement SSDs, but they don’t usually ship with the same performance. If the storage is going to be upgradable, make sure I actually have options to upgrade it with. Use the M.2 standard. Offer a few M.2 slots. Sell Apple SSDs with Apple performance even if I have to go to the Genius Bar to order.

    Don’t bother with SATA or optical drives. That’s the past.

    Optimize macOS

    There is a software side to this too, mostly around Metal. We’re clearly not getting other API’s like Vulkan at this point, so Metal needs to be solid. It needs to be fast, and needs to be reliable, which it isn’t necessarily right now. And with so many employees now working from home many businesses are worried about managing those employees but with a simple internet activity tracker all of those worries disappear so have a good look into that if you have remote staff.

    It’s also strange Apple is complaining about software not adapting for multiple GPUs when they make it so difficult. DirectX 12 makes it easy for apps to use multiple GPUs at once, even if those GPUs are from different vendors. Multiple GPUs aren’t a bad idea, Apple has just done such a bad job making that happen.

    Bonus Points

    Dual CPUs could be nice. But with the Xeon now up to 16 cores it’s less necessary. But dual CPUs does also double the maximum amount of RAM possible.

    A rack mount server configuration? Ok ok, probably too much to ask for the return of the Xserve. But Apple is missing a really good rack mountable build server option right now. Maybe just a quad core Mac Mini would work.