Supported Platforms

4.0 beta 4 includes several updates to how different operating systems and hardware are handled. This allows us to add Apple Silicon (M1) support, and also better handles other devices like the Raspberry Pi.

The final decision is that a “variant” should consist of the OS name (windows, macos, or linux) followed by a the naming from the os.arch value returned by System.getProperty(). Because those names can vary across JDK implementations, we'll be using the name used by the JDK included with the Processing download, which is currently from Adoptium.

This {name}-{arch} naming style helps drastically simplify the code inside the PDE, and also gets us out of the business of deciding how to rename each platform. While the naming is sometimes awkward (i.e. macos-x86_64), the alternatives are inelegant as well, so we'll err on the side of simplicity by inheriting how the platform handles naming. Users will (should) never see those awkward names! And only Library developers that need additional native code will need to understand the naming, but they should already be somewhat familiar with that nomenclature if they're working with native code.

As a result of these changes, the subfolders used to identify native libraries for each platform are different. Any library that used the old naming convention (macosx, windows64, etc) correctly will still work. But use these new names so that your library is ready for other platforms like Apple Silicon, or ARM on the Raspberry Pi.

Hardware/OS	os.arch	bits	4.0 library folder	old library folder	download suffix
macOS (Intel 64-bit)	aarch64	64	macos-aarch64	—	macos-aarch64
macOS (Apple Silicon)	x86_64	64	macos-x86_64	macosx	macos-x64
Windows (Intel 64-bit)	amd64	64	windows-amd64	windows64	windows-x64
Linux (Intel 64-bit)	amd64	64	linux-amd64	linux64	linux-x64
Linux (Raspberry Pi 32-bit)	arm	32	linux-arm	linux-armv6hf	linux-arm32
Linux (Raspberry Pi 64-bit)	aarch64	64	linux-aarch64	linux-arm64	linux-arm64

(The “bits” column is equivalent to sun.arch.data.model)

Technically, the Raspberry Pi releases may run on other ARM Linux installations, but they aren't tested that way. And the Raspberry Pi version includes additional libraries that are specific to the Pi. Put another way, generic Linux on ARM is not a supported platform, so we don't list it as “Linux (ARM 32-bit)” in places like Export to Application.

Some libraries did not properly use the old naming system, which will cause them to break in the 4.0 release. For instance, if dylib and dll files were simply placed in the root of a library, the library will probably not work. Moving the files into subfolders that use the naming conventions above should get them working again. If this sounds confusing, just look at how the core folder is laid out in the Processing software itself: it's a single library with native libraries for all six platforms to support OpenGL .

You can also view the Supported Platforms from 3.x, though half that information will be out of date.