Symptom: CSD Portfolio 2026.1.1 starts on a Mac, but your lab has not confirmed support for macOS 27.
Fastest safe action: Keep the lab’s primary system on its current baseline and run an isolated workflow acceptance test before approving migration.
This guidance is for structural chemistry and materials science researchers, graduate students, and lab support staff who rely on Mercury, ConQuest, or CSD Python API workflows.
Last updated: September 30, 2026. The support status below was checked against the CCDC macOS support information, its CSD Portfolio release and installation notes, and Apple’s macOS release record. Recheck the CCDC page before making a change; a later compatibility notice could change this decision.
SECTION 01Official support does not confirm macOS 27 compatibility
The CCDC support page lists macOS 14, 15, and 26 for CSD Portfolio 2026.1.1. It also says that the release includes a universal binary developed for M-series Macs, while ConQuest still runs through Rosetta. The same page does not list macOS 27. Apple’s release record lists macOS 27.0.1 on September 28, 2026. These are separate facts: a new operating system is available, but the cited CCDC page does not confirm it as a supported system.
That boundary does not establish that CSD Portfolio cannot launch on macOS 27. It also does not establish that a lab’s complete workflow is supported. Keep these outcomes distinct:
- Can install or launch: The installer completes, or an application opens. This is only an initial observation.
- Officially listed as supported: CCDC names the operating system in its support information. The cited list does not include macOS 27.
- Accepted for your lab: The exact applications, files, scripts, license path, and handoff tasks your group depends on pass documented tests.
A launch test is useful, but it cannot replace workflow acceptance. A failure in an export, a Python environment, or a license check can block research even when the main application window appears normal.
Hold point: Do not treat successful startup on macOS 27 as approval for a lab-wide upgrade. Preserve the existing working environment until your representative tasks pass and the support status has been reviewed again.
SECTION 02Mercury acceptance covers structure viewing and export
Test Mercury with files and outputs that represent actual work in your group. Avoid relying on a small sample that only proves the application can open a window.
Start with representative CIF files already cleared for use in testing. Include examples that exercise the features your researchers depend on, such as examining a three-dimensional structure, manipulating the view, and exporting a figure or structure output. The CCDC support page is the source for the current platform boundary; it is not a substitute for checking whether your specific files and output conventions behave as expected.
Use this sequence:
- Select sample structures that cover routine work and any known edge cases. Keep confidential or unpublished structures out of a shared test environment unless your institution has approved that use.
- Open each sample and confirm that the expected structural information appears. Record warnings, missing data, or differences from the group’s retained baseline.
- Repeat the structural operations your group uses for inspection or presentation. Do not mark the task complete just because the structure is visible.
- Export the figures and structure files that are part of your normal handoff. Check that the files exist, open in the expected downstream tool, and follow your group’s naming and storage conventions.
- Compare the results with an output produced on the lab’s current supported environment. Note the application version, system version, input file, actions taken, and output reviewed.
If the export looks different, first determine whether it is an intentional display or workflow change, a configuration difference, or a regression. Keep original inputs and outputs so another lab member can reproduce the comparison. Do not overwrite the only accepted baseline during testing.
The acceptance record should describe what you actually checked. “Mercury opened” is not equivalent to “structure viewing and export passed.” A useful record states which inputs were tested, which operations were completed, where the output was saved, and whether another user could inspect it.
SECTION 03ConQuest search and Mercury handoff require separate checks
Treat ConQuest as a separate acceptance path. CCDC documents that ConQuest in this release runs through Rosetta, even though the release also includes a universal binary developed for M-series Macs. That architecture difference is a reason to test ConQuest directly; it is not proof that a search or transfer will fail. See the CCDC macOS support statement and the release and installation notes.
Run a query that resembles the group’s normal use, with approved data and a known expected outcome. Check the process in separate stages:
- Confirm that ConQuest opens and reaches the expected database search workflow.
- Review the search criteria and hit list. Confirm that the selection is interpretable and that the expected records appear.
- Transfer selected results to Mercury using the documented ConQuest-to-Mercury search data procedure.
- Confirm that Mercury receives the transferred data and that the intended structures can be inspected.
- Locate the final result files and verify that another user can reopen them from the intended project location.
Do not reduce the handoff test to a single measure of waiting time. Record whether the interface indicated completion, whether the expected results arrived, and whether the saved files were usable. A delay observed in one test is specific to that session and environment; it is not a general performance result.
This scenario can expose problems that a component-by-component launch check misses. For example, a search may complete but the transfer may not produce the result file the group expects. Or Mercury may display transferred structures while the saved project folder lacks the files needed for a collaborator to continue. The lab should record these as separate outcomes rather than reporting only that “ConQuest worked.”
SECTION 04CSD Python API and lab scripts need their own acceptance path
Desktop acceptance does not establish that a script or Python API workflow is ready. The API has its own installation instructions and requirements, so check the CSD Python API installation notes against the interpreter and CSD Portfolio version you plan to use.
Use a minimal, reproducible test before running a full research pipeline:
- Record the Python interpreter path and how it was installed. Confirm that the test process uses the interpreter your project will use, not an unrelated environment available on the machine.
- Follow the API installation method documented by CCDC for the target setup. Save the installation command and any relevant environment configuration in the test record.
- Run a small public or suitably de-identified example that imports the API, performs a basic operation required by your group, and writes an expected output.
- Compare the output with the current research environment. Check file contents and downstream readability, not only a zero exit status.
- Repeat the test with the project’s real external packages and scripts in an isolated copy of the environment.
If a project depends on a specific processor architecture, external package, or historical environment, document that dependency and test it separately. Do not assume that an application using a universal binary proves that every package or script in the project has the same architecture compatibility. Likewise, a passing API smoke test does not prove a large pipeline, plugin, or lab-specific wrapper is ready.
Keep the test small enough to diagnose. If a call fails, determine whether the issue is interpreter selection, package installation, the API itself, input data, or the surrounding script. Record the exact error and the environment details needed to reproduce it. Avoid silently changing the production environment to make an exploratory test pass.
SECTION 05Licensing, networking, and access are independent acceptance checks
A software test is incomplete if the target account cannot activate or use the license in the environment where the work will happen. CCDC’s licensing information describes the licensing arrangements. Its network connection requirements describe connections required by desktop software. Check both sources, then validate the actual institution-approved account and network path.
Separate these questions in your acceptance notes:
- Can the intended user reach the activation or license service from the test environment?
- Can that user start the software and perform the intended task after activation?
- Does the group’s license arrangement cover the proposed use and users?
- Can the environment reach the CCDC services required for its operation or updates?
- Are institutional network controls, proxies, or security policies affecting those connections?
Do not treat access to a remote Mac as proof that your institution has authorized the license use. A reachable service and a valid institutional arrangement are different matters. This checklist does not determine license eligibility or interpret university policy; ask the responsible license administrator when the terms or permitted users are unclear.
Also test the account and access method your researchers will actually use. If a workflow relies on a shared account, remote desktop session, or handoff between staff, document how data is stored and who can access it. Do not place sensitive research data in an environment until your institution has approved the data-handling arrangement.
SECTION 06Compatibility FAQ
Is CSD Portfolio 2026.1.1 officially supported on macOS 27?
The cited CCDC support page lists macOS 14, 15, and 26 for this release and does not list macOS 27. That means official support is not confirmed by that page. It does not prove the software cannot start or work. Keep the new system isolated until CCDC updates its information and your group completes workflow checks.
Which components should you verify separately on an M-series Mac?
Check Mercury, ConQuest, and any CSD Python API workflow separately. CCDC says the release includes a universal binary developed for M-series Macs, but ConQuest still runs through Rosetta. These component differences matter because application launch, database search, API installation, and file transfer are distinct tasks with separate failure points.
Can Mercury view structures and export results on macOS 27?
The official support boundary does not answer that workflow question for your files. Open representative CIF inputs, inspect the structure operations your group relies on, export the expected figure or structure files, and compare them with a retained baseline. Record output differences and confirm that another user can reopen the deliverables before you mark the task accepted.
How can you tell whether ConQuest results reached Mercury correctly?
Check the search, the transfer, and the final result files as separate stages. Confirm that the hit list is plausible, transfer the selected data using the documented procedure, inspect it in Mercury, and verify the saved outputs. An interface message alone does not prove that the expected files were delivered or can be reopened by a collaborator.
SECTION 07Use documented test outcomes to choose an upgrade path
Use the outcome of the tests to choose a path, rather than relying on one successful launch:
- If CCDC’s current support page still does not list macOS 27, and a required task fails or cannot be reproduced, do not move the lab’s primary environment. Keep the accepted baseline and wait for updated support information or a documented correction.
- If the support page does not list macOS 27, but all representative tasks pass in isolation, permit a limited trial only if your lab can preserve the existing environment, restrict the test to approved data, and document the remaining support risk.
- If the official support information is updated and your Mercury, ConQuest, API, licensing, and handoff checks pass, follow your institution’s change-control process before migrating shared research machines.
- If you cannot test the same account, network route, scripts, or data handoff that researchers will use, the acceptance result is incomplete. Resolve that gap before making a production decision.
A lab can make the test repeatable without turning it into a broad system-upgrade project. Keep an untouched baseline, copy the minimum files needed for testing, assign a reviewer who did not run the original test, and record any difference that could change an analysis or deliverable. If the researcher who owns the workflow cannot reproduce the result, treat it as not yet accepted.
For a temporary validation environment, a remote Mac can let your team test real macOS workflows without replacing the lab’s primary machine. It does not remove the need to check CCDC support, your institution’s license arrangement, or data policies. If your current option is a shared Linux or Windows machine, its real limitations may include no macOS application environment, competing access, and an inability to reproduce the target desktop workflow. Buying a Mac instead avoids some remote-access dependencies, but it requires an upfront purchase and leaves your team responsible for maintaining a separate test machine. Neither choice changes the official support boundary.
If you want to compare a temporary test environment with your current setup, review MACNOX’s remote Mac access information and the available rental plans. Use the environment to validate representative tasks only after confirming that your data and license use are permitted; do not treat remote access as a compatibility guarantee. For a lab that needs a short-lived validation machine, renting can be a more reversible test than changing the shared research environment or buying hardware before the workflow is accepted.