MisakaX compatibility checker: match the exact build.

There is no single range for every release. MisakaX 2.2 is the public stable-labelled route for iOS/iPadOS 16.0 through 18.0 final, with conflicting beta 3/beta 4 wording for 18.1. MisakaX 2.3 is a macOS-only prerelease for 18.1 beta 5 through 18.2 beta 2. The separate misaka26 1.6 Unstable release claims 16.0 through 26.1 plus 26.2 beta 1.

The exact release channel matters. MisakaX 2.2 conflicts with itself at the beta 4 edge, while 2.3 explicitly begins at beta 5 and ends at 18.2 beta 2 on macOS. For 18.1 final and other later 18.1 builds, only the separate misaka26 1.6 release makes a current broad claim, and it is named Unstable.

The official 2.2 changelog names 18.0 final, not 18.0.1. A later technical issue refers to 18.0.1 as the historical working side of the 18.1 patch boundary, but that is not a maintainer test ledger. The checker therefore returns a documentation gap instead of an automatic release action.

MisakaX 2.3 explicitly claims only 18.2 beta 1 and beta 2, and only publishes a macOS binary. Do not extend that claim to beta 3, RC or 18.2 final. misaka26 1.6 makes a broader official claim that includes later iOS 18 builds, but its release is labelled Unstable.

Only iOS/iPadOS 26.2 beta 1 is named by the official 1.6 release. Beta 2, later betas and 26.2 final are outside that published boundary. Build 23C5027f identifies the first beta; do not shorten it to “26.2” when checking.

No official misaka26 release claims those versions. The current public boundary stops at 26.2 beta 1. Later issue reports include reboot-with-no-effect behavior, which is a reason to stop—not evidence that repeated Apply attempts will eventually work.

MisakaX 2.2 and misaka26 1.6 publish Windows files. MisakaX 2.3 does not; its attached application is macOS-only. A Windows file existing does not override the version/build boundary.

Yes, all three public routes compared here publish a macOS application: MisakaX 2.2, the 2.3 prerelease and misaka26 1.6 Unstable. You still need the release whose exact system range matches the device.

No official MisakaX 2.x or misaka26 release currently publishes a Linux binary. The checker returns Unsupported for Linux rather than redirecting to an unofficial build. If Linux is mandatory, compare related tools separately because their feature ranges do not transfer to MisakaX.

Marketing versions can contain several beta seeds, an RC and a final release with different patch status. BuildVersion identifies that exact seed. It is especially important around 18.1 beta 4/5, 18.2 beta 2/3 and 26.2 beta 1/2.

Yes for a broad, unambiguous stable range, but the result has lower precision. Enter BuildVersion whenever you are on a beta, RC, documentation-conflict edge or a version whose first beta is supported but later seeds are not. If the checker returns Unknown, do not remove the build just to force a match.

Open Settings, choose General, then About, and read the iOS or iPadOS Version entry. Tap the version value when needed to reveal the build identifier. Copy both the full version label and BuildVersion from the same current device state.

The official release ranges name both iOS and iPadOS, so the checker accepts iPad as a device family. That does not make every iPhone-oriented flag meaningful on an iPad. Match the system build first, then verify that the selected capability documents an iPad outcome and revert path.

No. The result matches a published release range and platform. Hardware, device model, region, selected flag and the final functional test are separate gates. A visible setting can appear while a sensor-dependent or server-side feature remains unavailable.

No. Success may describe file preparation or restore completion, not the final feature result. Public issue reports show devices rebooting after a success message while the requested settings remain absent, including on later unsupported builds.

No. Extraction only proves that you obtained an input file. It does not prove that the selected release can write or restore the change on that build. Import, Apply, reboot, setting visibility and functional behavior remain separate stages.

No. It runs locally in the browser using only the fields you submit. It does not use USB, upload a plist, inspect device hardware or silently scan the browser. The result is a release-routing decision, not a device test.

The developer distributes 3.0 beta as a separate unfinished test build, but the public listing does not provide a release/build matrix precise enough for this conservative router. It remains outside the automatic result until the track has an unambiguous range, channel and matching platform files.