Symptom — NVivo 15 opens on macOS 27, but that alone does not prove your research workflow is safe.
Fastest safe move — validate a copy of your project; if you are already in a critical research phase, keep the verified system and software baseline until the full workflow passes and formal compatibility information is clear.
This guide is for graduate researchers and staff using NVivo 15 on Apple Silicon, project leads planning an upgrade, and university IT teams managing Mac environments.
Last updated November 6, 2026. Compatibility information was checked against Apple’s Rosetta guidance and NVivo developer or support-channel information available through the cited sources. Support-channel reports are not the same as a formal compatibility listing.
NVivo 15 macOS 27 compatibility: the current decision
Current support-channel information indicates that NVivo 15 and NVivo 14 can run on macOS 27, but you should treat that as a reported status—not a guarantee that every project workflow is officially supported. The current NVivo Mac version on Apple Silicon still depends on Rosetta 2. The developer has stated a plan to provide an Apple Silicon-native version before macOS 28, but its release date and delivery details are not confirmed in the available information. The support-channel update on NVivo and macOS 27 should therefore be read separately from NVivo’s Mac product information.
Your decision is not simply “does the app start?” A qualitative research workflow may also rely on opening a particular project, applying codes, running queries, editing memos, saving changes, and exporting results. Test those actions with a project copy before you treat macOS 27 as an accepted environment.
| Situation | Safe default | Evidence to collect before changing course |
|---|---|---|
| You are writing a thesis or handling an active study | Keep the environment already verified for the project | A completed test using a copy of the real project, including save and export |
| You are starting a new project | Test NVivo 15 and macOS 27 in a separate environment first | Written record of the app version, macOS version, chip architecture, and workflow results |
| You manage a lab or university Mac fleet | Separate compatibility, authorization, and device-management decisions | The relevant support statement, institutional rules, and a reproducible test record |
What to record before testing
Capture the environment before you change it. This gives you a useful comparison if a warning appears, an operation fails, or you need to ask support for help.
Record the macOS version shown on the Mac, whether it uses Apple Silicon, the NVivo version and build information available in the app, and the exact wording of any Rosetta or compatibility alert. Note whether the app was installed or updated recently and whether the test uses a project copy or the original. These are observations about your setup, not proof of vendor support.
NVivo’s guidance on opening projects in older or newer versions is relevant when you plan to move a project between versions. Before you do so, check which version will open the file, whether the project will be changed on save, and how you will return to the earlier copy if the new environment does not pass your test.
Keep the untouched project copy separate from the test copy. Do not use an upgrade test as your only backup, and do not assume that a successful save proves every team member can reopen or collaborate on the project.
Can NVivo 15 run on macOS 27?
It may run, according to the cited support-channel information, but you should verify the tasks your own project needs. Do not turn a reported current state into a blanket claim that all NVivo 15 functions are formally supported on macOS 27. The formal compatibility position can differ from a support response or a report relaying one.
Use this acceptance sequence with a non-production copy:
- [ ] Confirm that the copy opens and that the expected project content is present.
- [ ] Apply a test code to a small, known passage; then check that it appears where you expect.
- [ ] Run a query or other analysis operation that your actual study depends on.
- [ ] Create or edit a memo if your normal workflow uses memos.
- [ ] Save, close, and reopen the test copy; confirm that the test changes remain.
- [ ] Export the results you need and inspect the exported file in the application or process that will receive it.
- [ ] Record every warning, error, workaround, or difference from the existing baseline.
Choose a path by project role
The same reported compatibility state can lead to different actions. A student nearing a submission deadline has less reason to take migration risk than a team preparing a new study. A lab administrator also has to account for local authorization and device-management rules, which cannot be settled by a software launch test.
| Role | Recommended path | Recheck trigger |
|---|---|---|
| Student or individual researcher | Keep a verified setup during a critical phase; test a project copy before any planned change | The project reaches a safe checkpoint, or a formal compatibility update appears |
| Project lead | Preserve the working baseline for an active study; test a new setup with a limited project workflow before approving migration | Required coding, query, save, or export tasks fail or behave differently |
| Lab or university IT support | Track the OS alert, support-channel statement, formal compatibility status, authorization, and management policy as separate items | Apple updates Rosetta guidance, or the developer publishes a formal compatibility or native-version update |
Protect work already in progress
If you are writing a thesis or collecting and analyzing data, do not migrate only because the operating system is available. Preserve the setup already used for the study, retain an untouched project backup, and schedule a separate test. That gives you a clear fallback if the test environment cannot complete a required operation.
Before transferring a project between versions or collaborators, check the project’s version path and team process. NVivo’s information about project collaboration in NVivo 15 for Mac can help you identify collaboration details to verify. It does not replace your institution’s rules for storing or sharing research materials.
Separate a new study from an active one
For a new project, you can test an isolated environment before choosing a long-term baseline. Use a representative sample of the intended work, and write down the acceptance criteria before the test. That prevents a simple “it opened” result from becoming the team’s entire migration policy.
For an active project, keep the current reproducible baseline until a tested alternative is approved. Your team can still evaluate macOS 27, but it should do so without making the live project depend on an unverified change.
| Option | When it fits | Main trade-off | Decision checkpoint |
|---|---|---|---|
| Continue on the verified environment | The project is active and required tasks already work | You defer the macOS 27 test for production work | Revisit at a project checkpoint or when formal support information changes |
| Test macOS 27 separately | You need evidence before approving an upgrade or starting a new project | A test takes time and may expose workflow differences | Accept only after required operations pass on a copy |
| Wait for a native Apple Silicon version and clearer support information | Your team has no immediate need to change and wants to avoid relying on Rosetta | The release timing and delivery details are not confirmed | Reassess when the developer publishes specific availability and compatibility details |
What should you do about a Rosetta warning?
On Apple Silicon, a Rosetta prompt is a signal to check the app’s current architecture dependency; it does not, by itself, show that your project is damaged or that NVivo cannot run. The current NVivo Mac version is reported to rely on Rosetta 2 on Apple Silicon. If you see the prompt, record its exact wording, confirm the NVivo version, and follow the supported installation or launch path for your institution rather than trying undocumented workarounds.
Apple states that Rosetta remains available in macOS 27 and earlier, while macOS 28 is not expected to provide general support for Intel apps. Check Apple’s Rosetta availability guidance before setting an upgrade policy. A Rosetta prompt does not confirm that a specific NVivo build is formally compatible, and the presence of Rosetta on the system does not validate your project workflow.
For IT teams, keep four records distinct: the operating-system message, the application’s reported architecture requirement, the vendor’s formal compatibility information, and the institution’s authorization and device rules. That separation helps avoid treating a system-level prompt as a licensing decision or a vendor support commitment.
Will NVivo Mac work on macOS 28?
Do not plan on the current Rosetta-dependent NVivo Mac version continuing unchanged on macOS 28. Apple’s stated Rosetta boundary makes the present dependency a migration risk for later systems. The developer’s stated plan is to provide an Apple Silicon-native version before macOS 28, but the available information does not establish a release date, exact delivery form, or guarantee of uninterrupted compatibility. The plan is not the same as a released version.
If your research schedule permits, wait for a specific native-version announcement and formal compatibility information before making a lab-wide migration decision. Then test the exact version and project workflow your team intends to use. If you must prepare earlier, preserve a verified baseline and make the test environment independent of production research work.
For an IT change record, include the source and date of each compatibility statement, the exact app and macOS versions tested, the project-copy results, and the person responsible for approval. Recheck the record if the developer publishes a formal compatibility list or native build, or if Apple updates its Rosetta guidance. Avoid promising researchers that an announced plan guarantees support on a future system.
Validate a remote Mac before moving research work
If you do not have access to a local Mac, a remote macOS environment may be a candidate for a trial—not an automatic replacement for a university workstation. First confirm that your NVivo authorization permits the intended use, that your institution allows the connection and environment, and that your project data can be handled there under applicable rules. These checks are separate from whether NVivo launches.
Use a non-sensitive project copy to test the workflow, including opening, coding, saving, and exporting. Confirm how you will retrieve the test outputs and whether your approved method of access is suitable for the tasks. Do not move identifiable or restricted research data until the relevant institutional approval and data-handling conditions are clear.
A remote Mac can avoid buying and maintaining a physical Mac for a short validation period, but it also introduces dependence on network access, remote-control methods, authorization, and institutional approval. If your work requires a physical interface, a tightly managed local device, or sustained use under conditions a remote setup cannot meet, use an approved local or university-managed Mac instead. You can review MACGPU’s available Mac environments and its Mac access options only after checking those constraints; neither page establishes that your NVivo license or research data is eligible.
Make the upgrade decision auditable
Before you approve a migration, make sure your team can answer these questions from its own records:
- Does the test use a copy rather than the only working project?
- Did it cover the operations your study actually uses, not just app launch?
- Are the tested NVivo version, macOS version, and chip architecture recorded?
- Have you separated reported support-channel status from formal compatibility information?
- Are project backup, collaboration, authorization, and institutional data rules checked independently?
- Is there a named owner and a defined fallback if a required workflow fails?
If your current alternative is an unverified shared computer or buying a Mac solely for a short compatibility test, both can create avoidable costs or control issues: you may lack a clean test environment, and a purchase commits budget before you know whether the workflow passes. A remote Mac rental can be a better fit for a limited, non-sensitive validation run when your authorization, institutional rules, access needs, and project handoff all check out. If you need that kind of temporary test environment, review MACGPU’s options after your institution approves the plan; keep production research data on an environment your institution has cleared.