macOS 28 Rosetta Research Software Migration

A critical research application still depends on an Intel plugin, driver, or command-line tool.

Do not wait for macOS 28: in 2026, inventory every Intel dependency, test native Apple Silicon replacements in an isolated environment, and keep a verified macOS 27 setup if the core workflow still cannot migrate.

SECTION 01Who should use this migration runbook?

This guide is for graduate students and researchers whose experiments depend on Intel applications, legacy plugins, drivers, or compiled utilities.

It is also for laboratory IT staff maintaining shared Mac systems, and for developers building research tools that must run natively on Apple Silicon.

Last updated August 16, 2026. Source check: Apple Developer Documentation, Apple Support, and current vendor compatibility pages.

SECTION 02The Rosetta decision boundary

Apple has confirmed that Rosetta remains available as a general-purpose translation environment through macOS 27. Apple also states that later support will retain only a subset intended for older, unmaintained games. That is enough to establish a planning rule: macOS 28 must not be treated as a routine upgrade for an Intel-dependent research workstation. (developer.apple.com)

macOS 28 has not been formally released as of August 16, 2026. Its final release date and complete behavior outside the confirmed Rosetta lifecycle should not be guessed. However, waiting for the release before starting migration creates an avoidable risk. You may discover that the main application opens, while a plugin, installer, dynamic library, driver, or external compiler fails only when a real experiment begins.

The risk is not limited to old desktop applications:

• A Universal application can still load an Intel-only plugin.
• A shell command may resolve to an x86_64 binary even when the graphical interface is native.
• A package manager may install dependencies for the wrong architecture if the shell environment is mixed.
• A driver or kernel extension may not be translated by Rosetta at all.
• A script-only application may be launched under translation as a precaution.
• A workflow may complete but produce different output because an external compiler, numerical library, or hardware interface changed.

Apple explains that Rosetta applies to the whole process. The system cannot freely mix arm64 and x86_64 code within the same process. This is why checking only the main application is insufficient. (developer.apple.com)

A useful research example is MATLAB. MathWorks states that MATLAB R2025b is the final release supporting Intel Macs, while MATLAB R2026a and later are not available for Intel processors. The native Apple Silicon edition also has separate product and support-package boundaries. This does not prove that every research application follows the same schedule, but it shows why each vendor must be checked individually. (mathworks.com)

SECTION 03Current inventory: build the migration ledger

Start with the experiment, not the application list. Write down which research activities would stop if the Mac could no longer execute Intel software.

Classify each workflow into three groups:

• Critical: the experiment cannot continue, the result cannot be reproduced elsewhere, or the software has no accepted replacement.
• Important: the workflow can pause for a short period, but the interruption would affect a deadline, instrument schedule, or collaboration.
• Convenient: the tool is useful but can be replaced by a native application, a Linux workflow, or a documented manual step.

For every item, create a migration record containing:

• Application, plugin, driver, script, or command-line tool name.
• Current version and download source.
• Architecture: Apple Silicon, Intel, or Universal.
• License owner and renewal contact.
• Input and output formats.
• External dependencies and hardware connections.
• Person responsible for validation.
• Last successful test date.
• Replacement candidate, if one exists.
• Stop condition if the test fails.

Do not mark a component as safe because it launches. The minimum evidence should include the architecture, a representative data run, output inspection, and confirmation that the required plugin or external tool actually loaded.

A shared laboratory Mac often contains dependencies that no single researcher remembers installing. Check user-level locations, shared application folders, project directories, shell configuration files, launch agents, audio or instrument plugins, and custom compiler paths.

For command-line research tools, record the result of:

uname -m
arch
which tool-name
file "$(which tool-name)"

On Apple Silicon, uname -m normally reports arm64 for a native shell. The file command may reveal that the selected executable is still x86_64. If the tool is supplied by a project-specific environment, inspect that environment instead of relying on the system path.

Migration warning: Keep the original environment unchanged while you are still collecting evidence. Reinstalling packages or replacing plugins before the inventory is complete can destroy the only working configuration.

SECTION 04Initial inspection: identify Intel components

The first inspection should answer four separate questions:

1. Is the main application native?
2. Is the application Universal but forced to use Rosetta?
3. Does it load Intel-only plugins or libraries?
4. Does the workflow call external Intel tools after the main application starts?

For a graphical application, use Finder’s Get Info panel and check whether the application is Apple Silicon, Intel, or Universal. On an Apple Silicon Mac, a Universal application normally prefers its arm64 slice, but the user can force Rosetta mode. Apple documents this behavior and provides lipo for inspecting executable slices. (developer.apple.com)

For a bundle, inspect the actual executable rather than the outer application directory:

lipo -archs "/Applications/Example.app/Contents/MacOS/Example"

Typical results have a clear meaning:

• arm64: native Apple Silicon executable.
• x86_64: Intel executable that requires translation on Apple Silicon.
• arm64 x86_64: Universal executable with both slices.

For libraries and command-line binaries:

file path/to/library.dylib
file path/to/command
otool -L path/to/command

The dependency chain matters more than the top-level result. A native application linked to an Intel dynamic library may fail, fall back to translation, or disable a feature. A Universal host with an Intel-only plugin may require the entire process to run under Rosetta.

For software developed by your lab, inspect all compiled outputs. Apple’s Universal binary guidance includes applications, app extensions, plugins, frameworks, static libraries, dynamic libraries, build tools, command-line tools, daemons, and launch agents. A build that produces a native application but leaves an Intel helper binary is not a complete migration. (developer.apple.com)

SECTION 05Short-cycle native testing

Do not upgrade the workstation that is currently producing results. Create a separate Apple Silicon test environment and install the native software there.

The process should be repeatable:

1. Select a representative dataset that is public or fully de-identified.
2. Save checksums for input files and reference outputs.
3. Record the current application version and all package versions.
4. Install the native Apple Silicon release without copying unknown binaries from the old system.
5. Recreate the dependency chain from documented sources.
6. Run the same analysis, script, or instrument simulation.
7. Save installation logs, runtime logs, generated files, and error messages.
8. Compare outputs using field-level checks rather than visual inspection alone.

For R, MATLAB, Python, or compiled command-line workflows, test the host application separately from its packages, toolboxes, interpreters, compilers, and native extensions. MathWorks, for example, distinguishes native Apple Silicon MATLAB from the Intel Mac release and lists products and support packages that are unavailable on Apple Silicon. A successful MATLAB launch therefore does not prove that every toolbox used by your project has migrated. (mathworks.com)

For laboratory-developed software, review architecture-sensitive code as well. Apple identifies potential differences involving virtual memory page sizes, cache line sizes, just-in-time compilers, real-time threads, assembly instructions, vector instructions, and C++ ABI behavior. These issues may not appear in a short smoke test. (developer.apple.com)

SECTION 06Pre-upgrade regression gates

Run both environments against the same workflow before approving a system migration:

• Existing Intel or Rosetta environment.
• Native Apple Silicon environment.

The test is not only “does it open?” Record five results:

• Completion: did the full workflow finish without manual repair?
• Output: are expected files created in the same format?
• Numerical or scientific consistency: are differences within the project’s accepted tolerance?
• Feature coverage: did every required plugin, toolbox, hardware interface, and export option work?
• Reproducibility: can another member of the group repeat the run from the documented setup?

If the workflow involves large datasets or long-running jobs, compare resource use and execution time only after confirming that both environments performed the same operations. Do not present a timing difference as a general performance claim unless it comes from a controlled test or an official source.

A remote Mac can be useful as an isolated validation environment when your local laboratory Mac cannot be interrupted. Before using one, confirm the available macOS version, Apple Silicon availability, root or administrative permissions, network access, storage handling, and delivery schedule. A remote environment is suitable for software validation only if it can reproduce the conditions that matter to your experiment.

You can review MACNOX Mac rental options as one possible way to obtain a temporary environment. The decision should still be based on the test requirements, not on the rental option itself.

SECTION 07Migration release conditions

Use the following decision branches when the test results are available.

• Choose native migration if the main application, critical plugins, data import and export, automation scripts, external tools, and result reproduction all pass in the Apple Silicon environment.
• Choose a dual-environment transition if the main workflow is native but one non-critical component still requires Intel execution, or if some users need time to update project files and scripts.
• Keep a verified macOS 27 environment if a critical Intel component has no supported replacement, the vendor has not documented Apple Silicon support, or the experiment cannot be reproduced natively.
• Reject the upgrade for now if the migration test changes scientific output, breaks a required instrument connection, removes a licensing function, or depends on an undocumented workaround.
• Escalate to the vendor if the architecture is unclear, the application is Universal but a plugin fails, or the vendor’s system requirements do not describe your exact release.

A retained macOS 27 environment should not be an untracked spare machine. Freeze its update policy, document its software and license state, restrict access, and define how results will be transferred to the current research archive. It should be a controlled exception while migration continues.

SECTION 08FAQ for research teams

Will Intel research software still run after macOS 28?

You should not plan on full Intel application compatibility after macOS 28. Apple has confirmed that Rosetta remains available as a general-purpose translation layer through macOS 27, while later support is limited to a subset aimed at older games. Treat macOS 28 as a migration deadline until each application and dependency is confirmed by its vendor. (developer.apple.com)

How can you check whether a research application depends on Rosetta?

Check the application architecture in Finder or System Information, then inspect the actual executable with lipo -archs or file. A Universal application may still launch through Rosetta if you force that mode or if an older plugin is loaded. Also inspect command-line tools, dynamic libraries, scripts, installers, and drivers instead of checking only the main application. (developer.apple.com)

Should a laboratory keep a macOS 27 test environment?

Keep a verified macOS 27 environment when a critical workflow still requires an Intel-only application, plugin, driver, or binary with no tested replacement. It should be isolated from routine upgrades, documented with its exact dependencies, and used only under a controlled exception. Do not treat it as a permanent substitute for migration planning.

What should you do if an Intel plugin has no Apple Silicon version?

Classify the plugin by whether it is essential, replaceable, or avoidable. Test a vendor-supported native alternative, remove the plugin from the critical path, or keep the workflow on a verified macOS 27 environment. Do not assume that a Universal host application makes an Intel-only plugin safe, because a process cannot freely mix arm64 and x86_64 code. (developer.apple.com)

SECTION 09Long-term maintenance

The migration ledger should become part of laboratory operations rather than a one-time document. Recheck it whenever macOS, a major research application, a plugin, a compiler, or an instrument driver changes.

For each review, update:

• Application and dependency versions.
• Architecture status.
• Vendor support statement.
• License and activation method.
• Test dataset and expected output.
• Known limitations.
• Responsible owner.
• Approved macOS versions.
• Rollback or fallback procedure.

For software developed by your group, add architecture checks to the build pipeline. Confirm that release artifacts contain the intended slices, then test the release on both Intel and Apple Silicon where the project still supports both. A Universal build is not enough if the runtime depends on an Intel-only plugin or helper process.

For personal research projects, keep the evidence proportionate. A complete ledger does not need to become a compliance exercise. It needs to answer one question before an upgrade: can you reproduce the result with the same inputs, documented dependencies, and accepted output on the target environment?

If your current setup is a Windows or Linux workstation plus an older Mac borrowed from a laboratory, that arrangement has three weaknesses: the Mac may be unavailable when you need it, its software state may be undocumented, and you cannot safely test an upgrade without disturbing an active experiment. Buying a new Mac solves availability but creates a larger upfront cost and may still leave you with the same dependency-audit work.

For a short migration window, an isolated remote Mac can be a more controlled option. You can copy a de-identified project, test Apple Silicon behavior without touching the production machine, and return to the verified environment if a plugin or tool fails. Review MACNOX access options only after confirming the required macOS version, permissions, storage workflow, and test duration.

The right outcome is not “upgrade as soon as possible.” It is a documented choice between native migration, dual-environment operation, and a controlled macOS 27 fallback, supported by evidence from your actual research workflow.