Why why why no Apps?

Apple makes available Software Development Kits (SDKs) for beta and shipping versions of macOS. If a developer chooses not to use the available SDK or decides not to make their software compatible with a current release of macOS (Intel or Apple Silicon), or even compatible with PyQt6, that is not on Apple, but the developer.

Apple provides the /usr/bin/make (GNU Make 3.81) binary as a result of installing Xcode, or the command line tools for Xcode. Many third-party developers favor cmake instead, and some Configure generated makefiles don't play nice with macOS without substantial effort or annexing another library path to the end of PATH. Case in point, libaacs. The Configure run borks if you don't tell it where to find libgcrypt (which must be installed by a package manager), and the generated makefile is simply horrific.

When buying a computer for a specific task, it is usually best to confirm app features and availability prior to purchase.

No experience with, but a couple of minutes’ searching finds: https://github.com/chychkan/DeepFaceLab_MacOS

The summer before the first M1 Mac was sold, Apple provided developers with a special build M1 Mac mini, the software developers toolkit, and the beta macOS 11 operating system. Any developer had several months to port their code (and indeed, many did) before that Mac mini went on sale in Nov 2020, and this proved quite adequate for those developers that chose to port their software to the new chip architecture and macOS 11. Four years prior, Apple made it very clear to developers that Apple would be moving to a strict 64-bit macOS application requirement, and again, many vendors chose not to heed that inevitability. Their apps would remain incompatible by their own choice, and with consequences for the users that simply wanted current compatible software.

Some developers chose to not upgrade their software to Apple Silicon compatibility, or they decided to only support their products on Microsoft Windows. Apple had no part in their internal business or technical decisions, and that is not Apple's role anyway.

MrHoffman does ring true when he states: "When buying a computer for a specific task, it is usually best to confirm app features and availability prior to purchase." That is not Apple's role either.

VeryVeryCheesedOff wrote:

I wonder why Apple didn't solve this issue before selling the M1 to ppl who find that they have no access to using some very great modern programs. It is sad for me as I want a few programs but, on my fairly new M1 I have no chance at all in using them, or downloading them with constant problems which prevent me ever being able to really enjoy the things I like to do on my own computer

Sell this Mac, and get what is necessary for your particular requirements.

Or maybe you can get the tools ported to and working on Asahi Linux, which is adding support for Apple silicon. The Asahi team is also now starting to upstream changes into RedHat, which will add options. Or boot this or another Linux as a guest in a hypervisor. The UTM hypervisor can further emulate x86-64. Or work toward a native macOS port, of course.

There are lots of apps and classes of apps that Apple doesn’t target. Apps for and tied to Intel x86-64, for instance, given the shift to AArch64 Apple silicon designs. Whether or not DeepFakes is an app market sufficient to interest third-party developers, it’s not a marker that Apple is presently in nor has Apple commented on it.

I've had it up to here with this as well. I've come across so many great apps over the years, and time after time I go into the App Store only to find it's not available for the MacBook. I'm now selling my MacBook and I would never purchase one again. I really hope Apple does something to remedy this, as many MacBook owners feel this way.