The US anti trust legislation punishes the abuse of monopoly power, not being monopoly in itself. Google was found guilty in leveraging their dominating position on the platform to do just that.
On the other hand in the US Apple's App Store was not found to be a monopoly in the first place. Different cases about abusing dominating position also didn't go far.
SwiftUI is build upon Apple's frameworks like Metal, CoreGraphics, CoreAnimation, and UIKit / AppKit. If someone want's to make a version for another platform, they will have a whole lot of work to do. That is the real show stopper, and not the core SwiftUI features like many were led to believe
I believe the statistics doesn't count Windows version of Steam games running on Mac via Crossover. And of course Steam is not the only store to purchase games on Mac (in last couple of years bought 2 games via App Store and none via Steam)
Seems this kind of comments will keep coming no matter what. Nevertheless, here's some points on the matter:
Apple was the company that boosted OpenGL popularity by using it as the graphics API for OS X. In Apple platforms world there's only one graphics API that is guaranteed to work across their hardware, so it was a big deal. However, they could not keep up with OpenGL updates, as they overlapped poorly with their products map, i.e. switching new OS X to newer OpenGL revision would require to drop support for older Macs.
Out of that need (and also to address multiple shortcomings of OpenGL) Metal was born. OpenGL support layer was implemented on Metal.
Metal was released before Vulkan API was finalised. There was never need for Apple to support Vulkan. Vulkan, as the OpenGL before it, has the same downsides for Apple, but bringing nothing to the table compared to Metal.
Very few games have custom written Vulkan rendering pipeline. Majority rely on game engines, and if the engine supports Vulkan rendering, it is almost certain to also supports Metal.
So, instead of relying on supporting 3rd party rendering APIs Apple spends resources on helping with porting games to Macs natively.
It seems like these sorts of defenses will be written even when Nvidia is worth $2 trillion more than Apple. Here's a reminder why people are mad:
Apple can support both. There's no reason they shouldn't, as a competitor on the open market; AMD, Nvidia and even Qualcomm are supporting both DirectX and Vulkan in software. It would not require Apple to retool their hardware (as Asahi has shown) and would not require them to depreciate Metal (as their OpenGL support shows). The only significant sacrifice Apple has to make is their unforgiving monopoly on modern GPU APIs that they have meted out against everyone's will but their own.
macOS will be depreciated on Apple's roadmap by the time developers take it seriously as a gaming platform. It's outrageous that people like me have to abandon the Mac because Apple expects me to satisfy myself with iPad games instead of the full range of experiences available on the software market. They have a monopoly, Apple is throwing a temper tantrum because they know Steam has the better experience and they can't compete any better than Microsoft does. Their best strategy is to kill the Mac and pretend the iPad is a console with computer-like features, which should outright terrify you if you own a Mac.
> Apple was the company that boosted OpenGL popularity by using it as the graphics API for OS X
Certainly they were a company that boosted OpenGL, but the company? During the early years OSX had less market share than Linux does today, and OpenGL was already well established by gaming and professional software before OSX ever came out. Quake supported it (not on release), Quake II and Half Life supported it on release, Quake III required it. Heck, Quake III released on Linux shortly before MacOS (classic), making it arguably as influential then, and of course the OSX port of that only came a few years later. But point is, that Id dared to release their new flagship with only OpenGL support shows that OpenGL was already firmly established and supported before OSX existed.
> So, instead of relying on supporting 3rd party rendering APIs Apple spends resources on helping with porting games to Macs natively.
I have been using a MacBook Pro for decades (Linux/Windows PC for gaming). I haven't seen this happening.
Apple have, in recent years, sponsored a few triple A titles to add MacOS ports but the vast majority of games don't run or run so poorly it doesn't matter.
With CrossOver there are a handful of games that work well, most don't. I tried to play Fallout New Vegas and it wouldn't start. Tried to play Raft with some friends and it didn't start. Borderlands 2/3 didn't start. Democracy 4 started but ran at 2 fps.
Some games like EU4 and Dark Souls 1 remastered work pretty well. I ended up buying an ROG Aly because I travel a lot and want a portable gaming experience. I use game streaming to my MacBook to play games - I wouldn't have bought the Ally if my MacBook could just game.
IMO - if the Asahi team were able to implement Vulkan with no documentation or references - Apple could do so in a weekend if they so desired. I'd like to see Apple write Windows or Linux drivers for their hardware so we can use official Bootcamp and run games on platforms that care about it.
Games on Mac are a multifaceted problem, but IMO the main issue stems from Apple treating games like they do apps. They expect developers to continue to support them, to update them as APIs get depreciated.
Apple can spend all the resources they want, but they'll never be able to convince enough developers to foster a gaming ecosystem that could ever be taken seriously when there's other platforms that have 20+ years of back catalogue titles available. This has largely been enabled on Linux through wrapping D3D to Vulkan and if Apple put in the work to support Vulkan all that work could be used for free. Or if they more permissively licensed GPTK's D3D>Metal wrapper, but as it stands it's still not as good as DXVK/VKD3D. Practically speaking Steam on Mac would be considerably more useful if there was native Vulkan support.
Of course, Apple wouldn't want that given their desire for vertical control of software distribution, though notably they don't do the same for video or audio. I mean they support MP3s right? That's what games should be treated as, a piece of media. MP3 might not be the best quality, most would prefer AAC or FLAC, but sometimes an MP3 is all a user might have, so they should let users play it. But they can't seem to break free from this delusion that game software should be treated the same as Uber Eats.
First, due to substantial differences in graphics hardware, that is tiled-based deferred rendering for Apple Silicon and immediate mode rendering for NVIDIA and AMD the software simulation or translation layer will never be as good as DXVK/VKD3D, which essentially do rendering on exactly same GPUs. In case of using TBDR the pipeline must be rewritten to get the benefits. Simply put, for Apple hardware every Windows game wrapped in a translation layer will be significantly worse off than a native port. That’s why it’s important for Apple to push for that.
Second, Apple is the owner of the biggest game storefront in terms of revenue. They don’t have to ask for game developers to come, they are already here. The market we are talking about is AAA games market. And this market is characterised by dedicated hardware: consoles and gaming PC. So I think this is where lies the actual problem: Apple doesn’t make dedicated hardware for games.
> First, due to substantial differences in graphics hardware, that is tiled-based deferred rendering for Apple Silicon and immediate mode rendering for NVIDIA and AMD the software simulation or translation layer will never be as good as DXVK/VKD3D, which essentially do rendering on exactly same GPUs. In case of using TBDR the pipeline must be rewritten to get the benefits. Simply put, for Apple hardware every Windows game wrapped in a translation layer will be significantly worse off than a native port. That’s why it’s important for Apple to push for that.
Doesn't matter for the back catalogue, which is the thing that is missing that makes the platform a running joke re: gaming. It's also an issue that affects Adreno on Snapdragon, but it isn't stopping Valve from planning to ship a version of Proton for that platform. Having personally talked to a DXVK developer about this specifically, the overhead, while existent, I understand isn't necessarily as severe as you make it out to be either.
> Second, Apple is the owner of the biggest game storefront in terms of revenue. They don’t have to ask for game developers to come, they are already here. The market we are talking about is AAA games market. And this market is characterised by dedicated hardware: consoles and gaming PC. So I think this is where lies the actual problem: Apple doesn’t make dedicated hardware for games.
Not just AAA, but most everything outside of the F2P/casual sphere. Speaking as someone who actually likes games as a form of art, the App Store's library is the video games equivalent of reality TV and home shopping. It's mostly exploitative trash. Maybe Apple is happy with cornering the market on exploitative trash though, good for them.
I don't think there's any issue to run any older game using Crossover or similar on a Mac. Grab that on Steam or GoG and go. Not sure why Apple should become involved in those simulation efforts.
> the software simulation or translation layer will never be as good as DXVK/VKD3D
> every Windows game wrapped in a translation layer will be significantly worse
That's not wholly accurate, though. Apple Silicon has reverse-engineered drivers that do perfectly well keeping up with immediate-mode multiple-pass graphics pipelines, MoltenVK is not SOTA anymore: https://youtu.be/BbJMPfXTbbE?t=447
You're correct that tile-based deferred rendering is more efficient. That's not the issue, though. Apple can (and already does) support traditional raster APIs on the desktop, because they have to for compatibility's sake. Thousands of Mac apps will never use TBDR or Metal and will never be updated to use it. And there's no good reason to stop supporting those applications, because OpenGL runs perfectly well on Apple Silicon. The same goes for DirectX, whether you're willing to acknowledge it or not.
There are hundreds of thousands of games that do not support TBDR and will never be ported to Mac in their lifetime; and Mac owners could be playing them regardless. The only one holding them back is Apple, because they'd rather Mac owners play Genshin Impact and earn Tim a few RSUs with a gachapon pull.
I think what you are describing is Apple Silicon GPUs delivering good results with sheer power. However, when the same titles are adopting TBDR you'll get faster rendering time or higher resolution. Cyberpunk is a good example of porting properly done.
Skipping unnecessary operation during frame rendering is always better for games.
I don't think I am. Even before Apple released Game Porting Toolkit, Crossover could play the game at nearly the same framerate as native: https://youtu.be/mEZJFjhLAbc?t=46
Looking at this kind of footage really does not convince me that "porting properly done" is worth enduring a library with no games. Nevermind the fact that the game runs fine through translation on the $400 Steam Deck hardware. You really are overstating the difference it makes.
Maybe there's subtleties on why the situation is like it is, but the matter of the fact is that most developers need to go out of their way to support Apple (maybe even to a larger extent even than to support linux).
> spends resources on helping with porting games to Macs natively.
This is news to me, is there some writing about it somewhere?
> However, they could not keep up with OpenGL updates, as they overlapped poorly with their products map, i.e. switching new OS X to newer OpenGL revision would require to drop support for older Macs.
It works for me, but not as good as the ones based on content list filters. It's also brings odd problems: google.com breaks on first search request, but ipv6.google.com does not.
> Answer: bank/financial apps, enterprise apps, government apps and copyrighted media (music, video, games, books, ...).
Those are the players that demand excessive control over end-user devices, and thus the ultimate driver behind the problem we're discussing.
Those work perfectly via a browser, on any platform where the browser can run. As long as a hypothetical open OS has a browser capable with bog standard modern capabilities, it will be fine
I tried to log into a banking website on a full desktop browser recently, one that I had previously used with a password. It literally would not let me login until I downloaded their app and set up a passkey. That is now the _only_ way for me to access those accounts. Presumably, I could call in, though I wouldn't be surprised if the person on the phone also asked that I download the app in order to verify my identity, and even if it wasn't the case, they didn't offer that option when I was trying to login. Many bank websites now also require the phone app.
For a while Netflix didn't support 1080p on browsers other than Edge on Windows or Safari on Mac. This has changed somewhat but they still reserve their resolution content for their "blessed" OS/browser combinations
You're saying I can use Revolut in the Firefox on, say, Fedora?
People have genuine reasons to stay with the provider / platform and usually browser doesn't cover half of their use cases.
For example I have to use Revolut because it's one of the very few banks that allow me to use Garmin Pay and work (reluctantly) on my phone without Google rootkit. Can't use, say, Curve because their privacy policy is alarming (and I had a very very weird/disappointing interaction with their compliance team).
And you've already got a good example with Netflix.
You're getting downvoted because that's not the point.
You are technically right, we still have access to these services via a web browser today. It doesn't mean we'll have it forever.
With the advent of AI browsers and AI agents, it's not hard to think of a future where LLM chat interfaces and mobile apps are the future, and web apps start getting disregarded as legacy and eventually, discontinued.
Try ordering some food via mobile application and then again via web app. You'll instantly feel the downgrade on the web app. Bugs, glitches, slow experience.
The desktop web is already the 2nd-class citizen for modern startups.
My reply is a counterpoint to the statement that banks, government services and streaming services require excessive control over my device. They aren't, as they all can run in a browser, which sandboxes them from the OS. That's it.
And I guess people who downvoted my counterpoint thought that it means that all services on the planet have very well functioning browser version, judging by their comments. Some don't, some do. But no one of them "requires" excessive access a native app can provide.
Some may want to have it, for some browser version is simply not a priority. But nobody needs to have additional info for those services to function.
reply