ATLAS.ti 26 Project Cloud is suitable for individual cross-device work and asynchronous file sharing, but it should not be treated as a shared workspace for simultaneous editing. Use ATLAS.ti Web for live collaborative coding. Use one desktop master project with controlled distribution and merging when desktop analysis or intercoder agreement is required.
This guide is for qualitative research leads who need rules for a master project, user access, and deliverables. It also supports graduate researchers and coders moving between Mac and Windows, plus university IT teams assessing remote Mac access, licensing, and data storage.
Last updated September 7, 2026. Version and capability checks are based on the ATLAS.ti 26 Mac manual, the Project Cloud documentation, and the related desktop collaboration guides.
[ SECTION_01 ] The four collaboration routes have different acceptance conditions
The main decision is not whether ATLAS.ti has a cloud feature. The decision is whether the team’s work pattern matches that feature.
| Route | Best fit | Main control point | Release decision |
|---|---|---|---|
| Project Cloud | One researcher switching between Mac and Windows | Obtain the newest project before editing; upload after finishing | Approve for sequential use |
| ATLAS.ti Web | Multiple people coding in a shared browser-based project | Confirm Web project access, role boundaries, and export needs | Approve for live collaboration |
| Desktop project packages and merge | Separate coders, intercoder agreement, or desktop-only analysis | Keep one master project and track user identity and entity conflicts | Approve after a test merge |
| Remote Mac desktop | A team without a Mac that needs Mac desktop analysis | Validate licensing, download, analysis, export, and cleanup with a redacted project | Approve only after end-to-end testing |
The official Project Cloud documentation describes the feature as Beta and states that two devices should not edit the same project at the same time. It also distinguishes a local project copy from a permanently shared project instance. That difference determines whether the workflow is safe for sequential work, not whether it supports real-time team editing. See the official Project Cloud limitations and workflow before approving a production process.
[ SECTION_02 ] Scenario 1: Cross-device continuation between Mac and Windows
ATLAS.ti 26 Mac and Windows project collaboration requires a handoff rule
Project Cloud can fit a researcher who starts coding on a Mac and continues on a Windows workstation. The acceptance condition is sequential ownership. One device must finish its work and upload the current state before another device downloads and edits it.
The project should be treated as a versioned handoff, not as a shared document. A researcher should confirm the project’s version state before opening it. If the application indicates that a newer version is available, the newer version must be obtained before coding begins. After the work session, the local changes must be uploaded and the session must be closed cleanly.
The official documentation is especially important when both devices contain changes that have not reached Project Cloud. Continuing to code in that situation can create uncertainty about which project copy is authoritative. The correct response is to stop, preserve both local copies, and restore a known version baseline before doing more analysis.
Use this five-step acceptance test:
- Create a redacted test project on the primary desktop installation.
- Upload the project through Project Cloud and record the visible version state.
- Open the project on the second operating system and confirm that the newest version is available.
- Add a test code or memo, close the project, and upload the change.
- Return to the first device and verify that the expected change is visible before editing.
The workflow passes only when the second device receives the current project, the first device is no longer editing, and the uploaded result can be opened without missing documents, codes, memos, or links.
If both computers show local modifications, the workflow fails at that point. Do not attempt to resolve the conflict by guessing which copy is newer. Preserve the copies and use the project transfer or controlled merge route instead.
Storage and licensing still need separate checks
Project Cloud availability does not remove licensing checks. Each researcher must confirm that the assigned account can activate the required desktop application. The official license activation documentation should be checked alongside the institution’s account policy.
The Mac installation also has to meet the documented system requirements. A successful download does not prove that the project can be analyzed reliably. Confirm the operating system, application version, account, and project access on every device that will enter the workflow. The ATLAS.ti 26 Mac system requirements are the source for the supported environment.
[ SECTION_03 ] Scenario 2: Asynchronous distribution to a small coding team
A project copy is not the same as a jointly edited project
A small team can use desktop copies for asynchronous coding, but only when the lead researcher controls the master project and the collection process. Each coder should receive a defined copy of the same starting project. That copy should already contain the agreed documents, code system, groups, and instructions.
The team should document:
- The name and owner of the master project.
- The starting version given to each coder.
- Which documents each coder may code.
- The coding period and return deadline.
- The return format and file naming convention.
- Who checks and merges each returned project.
A common failure occurs when a returned project is mistaken for an automatic update to the master. Project Cloud does not turn independently edited copies into a single automatically merged project. It only supports the documented cloud workflow and version state. The official team work guidance should be used to define the distribution and collection process.
The minimum operational test is one full round with redacted material:
- Build a clean master project.
- Duplicate or distribute the project according to the desktop team workflow.
- Give each coder a separate assignment and an identical coding brief.
- Collect the returned project files without overwriting the master.
- Compare the returned content and perform a trial merge.
- Record unresolved conflicts and revise the instructions before real data is used.
The route passes when the lead can identify every returned copy, trace each coding contribution, and reproduce the merge result. It fails when members use different starting code systems, rename the same entities inconsistently, or return files with unclear ownership.
A shared folder alone does not solve these problems. File naming, user identity, version control, and a protected master project are still required.
[ SECTION_04 ] Scenario 3: Live coding and ATLAS.ti Web boundaries
Can several people edit one ATLAS.ti Project Cloud project at the same time?
No. Project Cloud should not be approved for two devices editing the same project simultaneously. The official documentation identifies this as an unsupported workflow. The safe interpretation is sequential cross-device continuation or controlled sharing of project copies.
When several coders must work in the same project at the same time, ATLAS.ti Web is the more relevant route to evaluate. However, Web and desktop projects should not be assumed to be interchangeable. The documented boundary is that desktop Project Cloud projects and ATLAS.ti Web projects are currently not mutually visible.
This creates an important planning rule: choose the collaboration environment before the coding round begins. Do not promise that a Web project can simply be opened in the desktop application with every object, relationship, setting, or analysis feature preserved.
Can an ATLAS.ti Web project continue directly in the desktop application?
Not as an automatic continuation should be assumed. The team must validate the documented import and export path, the objects included in the transfer, and any format or feature changes. The official project transfer documentation provides the basis for this check.
Use a staged delivery model when the research depends on desktop-only analysis:
- Conduct the live coding phase in the selected Web workflow.
- Export or transfer a controlled project copy.
- Open that copy in the desktop application.
- Compare documents, codes, comments, memos, quotations, and relevant metadata.
- Complete desktop analysis only after the comparison passes.
If the project depends on features that do not survive the transfer with acceptable fidelity, do not mix real-time Web editing with a desktop master during the same coding round. Finish one phase, preserve its output, and begin the next phase from a verified project copy.
[ SECTION_05 ] Scenario 4: Intercoder agreement and formal project merging
Separate coders need the same starting project
Intercoder agreement requires more than collecting two independent code files. Coders need a shared project structure so that their decisions can be compared against the same documents and code entities.
The lead researcher should create the common project first. The coders should receive independent working copies. They should not each create a new project, re-import the documents, or rebuild the code system from memory. Those actions can produce duplicate documents and unrelated entity IDs, making the later comparison less reliable.
The intercoder agreement guidance and the Mac merging and agreement documentation should be reviewed before the first production round.
Check these points during the trial merge:
- Each coder is identifiable through the correct user account or coding identity.
- The documents are not duplicated after merging.
- Codes with the same intended meaning are mapped to the correct entities.
- Conflicting quotations and coding decisions are visible for review.
- The merged project retains the material required for the agreement analysis.
- The original master and each independent copy remain preserved as read-only evidence.
A five-step merge acceptance procedure
- Prepare one redacted master with a small representative document set.
- Create independent coder copies from that master.
- Have each coder apply a limited, documented coding task.
- Merge the copies using the supported desktop process.
- Inspect the merged project and agreement output against the original files.
The merge passes when documents remain unique, coder identity is recoverable, and disagreements can be inspected without manually reconstructing the project. It fails when the result contains duplicate documents, anonymous coding, missing quotations, or a code system that cannot be reconciled.
The project merge documentation should be treated as an operating procedure, not as optional background reading.
[ SECTION_06 ] Scenario 5: Sensitive interviews and large multimedia files
Cloud storage decisions must begin with the institution’s ethics approval, data classification, consent language, and cross-border requirements. This guide does not make a legal determination about whether a particular interview dataset may enter Project Cloud.
The research team should separate two questions:
- Is the project container approved for the data?
- Can the project’s documents and linked media be restored reliably on another device?
Audio and video may exist as files inside the project or as external links. An external link may depend on a mounted drive, a local path, a permission token, or a network location. A project that opens successfully on another computer may still have unusable media links.
Use a redacted sample to test:
- Project download on each approved device.
- Playback of representative audio and video.
- Access to external links after changing devices.
- Export of transcripts, quotations, and coded excerpts.
- Removal of temporary files after the session.
- Preservation of a read-only original outside the working copy.
Stop the cloud route if the institution has not approved the storage location or if media links cannot be restored consistently. Keep the desktop project in the approved local environment and use a controlled transfer route instead.
Do not upload real participant data to a test environment merely to prove that the software opens. Use synthetic or fully redacted material until the institution has approved the storage and access model.
[ SECTION_07 ] Scenario 6: Remote Mac acceptance when the lab has no Mac
A remote Mac can solve a platform access problem, but it should be validated as a desktop workstation rather than assumed to be a collaboration platform. The team should first test with a redacted project. The test must cover application launch, license activation, project download, desktop analysis, export, and session cleanup.
Use this acceptance sequence:
- Confirm that the remote Mac meets the documented ATLAS.ti 26 system requirements.
- Sign in with the approved account and verify license activation.
- Download a redacted Project Cloud project.
- Open documents, codes, memos, quotations, and representative media.
- Run the desktop analysis tasks required by the research protocol.
- Export the expected results and reopen them on the team’s existing platform.
- Remove temporary project files, sign out, and confirm that no sensitive data remains in the remote session.
The test has three separate outcomes. Application operation asks whether ATLAS.ti launches and remains usable. Remote interaction asks whether keyboard, display, and file transfer are acceptable for the work. Research portability asks whether the final project or exported results can return to the approved team environment.
NOVAKVM can be considered for this validation when a lab has no Mac but needs a temporary macOS desktop. The remote Mac access options can support a controlled trial without forcing the department to purchase hardware before the workflow is proven. For a more specific ordering path, the Mac mini remote rental option can be reviewed after the redacted acceptance plan is defined.
The acceptance test does not prove universal performance. It only establishes whether the selected remote environment can complete this team’s required sequence with this project type and these transfer rules.
[ SECTION_08 ] The final release checklist
Use the following checklist before moving production material into any collaboration route:
- [ ] The team has selected Project Cloud, ATLAS.ti Web, desktop merge, or remote Mac for a defined scenario.
- [ ] The master project owner and backup owner are documented.
- [ ] Every coder starts from the same approved project baseline.
- [ ] Mac and Windows users have confirmed the application, operating system, account, and license requirements.
- [ ] Project Cloud users understand that simultaneous editing is not approved.
- [ ] A newer-version check occurs before every cross-device editing session.
- [ ] Each completed session uploads its changes before another device opens the project.
- [ ] Web-to-desktop transfer has been tested if the workflow uses both environments.
- [ ] A redacted distribution and merge round has passed.
- [ ] Coder identity, document uniqueness, entity mapping, and conflict reporting have been checked.
- [ ] Ethics, storage, access, and cross-border requirements have been approved.
- [ ] External media links have been tested after a device change.
- [ ] A read-only original is preserved outside the working copy.
- [ ] Remote Mac cleanup and export have been verified if no local Mac is available.
A useful scoring rule is strict: a failed stop condition cannot be compensated for by several successful convenience checks. If simultaneous editing is required, Project Cloud is not approved. If desktop merging is required, a Web-only workflow is not approved until transfer fidelity is demonstrated. If sensitive storage is not authorized, the cloud route is not approved regardless of technical success.
[ SECTION_09 ] Final recommendation for research teams
ATLAS.ti 26 Project Cloud is a reasonable choice for one researcher moving between Mac and Windows, and for carefully controlled asynchronous sharing. It is not the correct basis for multiple people editing the same project at the same time. Use ATLAS.ti Web when live shared coding is the primary requirement. Use a single desktop master and supported distribution and merge procedures when desktop analysis, formal merging, or intercoder agreement matters.
For teams currently relying on Windows or Linux alone, the weakest long-term option is often an untested mix of copied project files, shared folders, and occasional access to someone else’s Mac. That model creates unclear ownership, hidden version conflicts, license interruptions, and no reliable evidence that media or analysis outputs survive the handoff. Buying a Mac may be excessive if the requirement is only a short validation or one project phase; a generic cloud workstation may also fail if the workflow needs a real macOS desktop application.
A controlled NOVAKVM remote Mac trial is more appropriate when the team needs temporary Mac access, desktop-only analysis, or a repeatable upload-to-export acceptance run. The team should start with a redacted project, complete the checklist, and choose long-term hardware, Web collaboration, or continued rental only after the workflow passes.