MacBook or Windows for eDiscovery? An Honest Answer

The question comes up constantly, usually from someone starting out in litigation support: can I do this job on a MacBook, or do I need Windows?

Ask it in any eDiscovery forum and the answers arrive fast and short. "Windows." "Definitely Windows in this profession." Occasionally someone offers a joke about a Commodore 64. It is one of the few things the field agrees on without much argument.

The agreement is mostly right. But the reasoning behind it is rarely spelled out, and the parts that actually matter are not the parts people warn you about.

Here is how it really breaks down.

Review Runs in a Browser. Your Laptop Barely Matters.

Most of what a reviewer, associate, or case manager does all day happens in a web-based review platform. Nuix Discover, and every serious cloud review tool built in the last decade, runs in Chrome or Edge. It does not care what operating system is underneath.

If your day is document review, tagging, searching, running analytics, and QC-ing coding decisions, a MacBook is a completely legitimate machine. You are not compromising. The rendering is the same, the viewer is the same, the keyboard shortcuts are the same. Anyone telling you otherwise is describing 2012.

The old objection - that review platforms needed ActiveX viewers or Windows-only plugins - is largely dead. Browser-native rendering killed it.

Processing and Forensics Is Where Windows Still Wins

The moment you move upstream of review, the picture changes.

Forensic collection tools, image acquisition software, processing engines, load file utilities, PST and OST handling, legacy imaging applications - a large share of that ecosystem is Windows-first and, in many cases, Windows-only. Some of it is genuinely old software that nobody is porting. Some of it depends on Windows-specific APIs for disk access or Outlook interop.

The same applies to platform administration. Anything involving bulk data movement - staging, importing, migrating, the utilities that push and pull data in and out of a review environment - tends to assume Windows. Admins who have tried to do that work from a Mac usually stop trying.

If your role involves collections, processing, productions, administration, or repairing a broken volume from opposing counsel, you will need Windows. Not occasionally. Regularly.

That does not automatically mean you need a Windows laptop.

The Apple Silicon Complication

This is the part that has changed, and the part people get wrong.

On an Intel Mac, you could run Boot Camp and simply boot into full Windows. That option is gone. Apple Silicon Macs cannot run Boot Camp, and virtualization on Apple Silicon means running Windows on ARM.

Windows on ARM is better than it used to be. Emulation handles most ordinary x86 applications. But "most" is doing real work in that sentence. Forensic and processing software is exactly the category most likely to sit in the gap: kernel-level drivers, hardware write-blocker support, dongle-based licensing, and older installers are all common failure points. Testing a hardware imaging device through two layers of translation is not a fight you want during a collection.

So if your work is upstream, an Apple Silicon Mac is not a "run Windows in a VM and it's fine" situation. It might be. It might not. And you will find out at the worst possible moment.

The Workaround Most Firms Actually Use

In practice, plenty of Mac-based eDiscovery professionals never solve this problem locally. They remote into a Windows machine.

A VDI session, a Citrix desktop, or a cloud-hosted Windows workstation gives you a real x86 Windows environment with the processing tools installed, sitting close to the data. Your MacBook becomes a very good terminal. This is often the better architecture anyway - you would not want to pull 400 GB of PSTs down to a laptop to process them.

If your firm or vendor already provides a hosted Windows environment, the Mac-vs-Windows question mostly dissolves. You use the Mac for email, documents, review, and the browser. You use the remote Windows box for the heavy, licensed, Windows-only work.

The Mac Gotchas Nobody Warns You About

This is the section that matters most, and it has nothing to do with performance.

Macs quietly do things to files that break eDiscovery deliverables.

Resource fork files. When you copy files to a non-Mac filesystem or a network share, macOS can leave behind companion files beginning with ._ - one for every real document. These end up in production folders, get counted as documents, and generate confused emails from the receiving party.

.DS_Store files. macOS drops these into every folder it touches. They are invisible on a Mac and extremely visible to whoever loads your volume.

__MACOSX folders. Zipping a production using the Finder embeds a __MACOSX directory inside the archive. Opposing counsel unzips it on Windows and sees a phantom parallel folder tree.

Text encoding and line endings. This is the dangerous one. Concordance-style DAT files rely on specific delimiters and, frequently, UTF-16 encoding with CRLF line endings. Open one in a careless Mac text editor and save it, and you can silently convert it to UTF-8 with LF endings. The file still looks fine. It will not load, or worse, it will load with shifted fields.

Excel for Mac and CSVs. Excel on macOS has a long, unhappy history with delimiter and encoding handling. Using it to "quickly check" a load file is a good way to mangle one.

None of these are reasons not to use a Mac. They are reasons to know your tools. A Mac user who understands them is fine. A Mac user who does not will eventually ship a bad volume.

The Text Editor Problem Is Real

This is a complaint you hear from long-time Mac owners in this field, and it deserves more attention than it gets.

eDiscovery involves opening very large, very fragile text files - DAT files, OPT files, extracted text, log files that run to millions of lines. The Windows tooling for this is simply better. The editors built for it handle multi-gigabyte files without choking, show you encoding and line endings explicitly, let you change both deliberately, display non-printing delimiter characters, and support column-mode editing across enormous files.

The Mac has capable options, and a terminal is often the right answer anyway. But the day-to-day ergonomics of "open this 4 GB DAT, find the row where the field count breaks, fix it, save it in the exact encoding it came in" are better on Windows, and people who do that work for a living notice.

It is a small thing that turns out not to be small.

The One Thing Macs Are Genuinely Better At

Credit where it is due. macOS is Unix underneath, and that is a real advantage for load file work.

Field counts, delimiter validation, encoding checks, Bates sequence gaps, orphaned images, family breaks - all of it is fast, scriptable work with standard command-line tools and Python, both of which are native and frictionless on a Mac. Windows can do this too, with PowerShell or WSL, but on a Mac it is simply there.

If you are the person who diagnoses why an import failed, a Mac terminal is a genuinely good place to work.

So: What Should You Buy?

If your work is review, project management, or case strategy: buy whatever you like. A MacBook is a fine, arguably excellent choice. Battery life and build quality are real benefits when you are living in a browser for ten hours.

If your work is processing, forensics, or production: you need reliable access to x86 Windows. Either buy a Windows machine, or buy a Mac and pair it with a hosted or virtual Windows workstation you have actually tested against your specific tool stack. Do not assume a VM will cover it.

If you are early in your career and not sure which way you will go: buy Windows. Not because a Mac cannot do the job, but because Windows never blocks you, and at the start of a career you do not yet know which parts of the workflow you will end up owning. It is a bad time to discover a limitation.

If you are buying a personal machine mainly to sit certification exams: the proctoring software used for most industry certifications runs on macOS, and people do pass exams on MacBooks without incident. But if you are spending real money on a laptop, you are not buying it for the exams. You are buying it for the five years after them. Optimize for that.

If your firm has strong opinions: their opinions win. IT support, device management, disk encryption policy, and security tooling are all reasons a firm standardizes, and none of them are unreasonable.

The most common arrangement among experienced people, incidentally, is not a choice at all. It is a Windows machine for work and a Mac at home. Right tool for the job, and nobody has to feel bad about liking their laptop.

The Direction of Travel

The interesting thing about this debate is that it is slowly answering itself.

Every year, more of the eDiscovery workflow moves into the browser and into the platform. Processing runs on servers, not laptops. Review runs on the web. Analysis increasingly runs on AI operating inside the review platform rather than on tools installed on a workstation.

Claira is a case in point, and it is deliberate: Claira is system agnostic. It runs inside Nuix Discover, which means it runs wherever Nuix Discover runs - which is to say, in your browser. There is nothing to install. There is no client application, no local dependency, no minimum spec, no "supported on Windows 11 only" line in the documentation. The summaries, extractions, and issue flags it produces are written into the review database itself, so they arrive as fields you can search, sort, and filter like any other metadata.

A reviewer on a MacBook, a case manager on a Windows laptop, and a partner on an iPad are all looking at the same AI output in the same platform. Nobody had to check a compatibility matrix first. That is not a small design decision - it means the AI layer of your workflow is one place where the Mac-versus-Windows question does not arise at all.

The workstation era of eDiscovery is not over. Processing and forensics will keep you tied to Windows for a while yet. But the question "can I do this job on a Mac?" gets a slightly more comfortable answer every year, and the reason is that less and less of the job depends on the box in front of you.