A lot of people learn LaTeX in TeXworks. It ships with TeX Live and MiKTeX on Windows, it’s what many courses hand you on day one, and it does exactly what a first editor should: a source window, a PDF window, and a green button that turns one into the other.

Then you move to a Mac, or your document grows past a single file, and you start looking for what comes next. This is an honest map of the options.

First: you can keep using TeXworks

TeXworks runs on macOS. There are official builds on the project’s GitHub releases page, and it’s available through Homebrew:

brew install --cask texworks

It doesn’t bundle a TeX distribution, so you’ll want MacTeX (or the smaller BasicTeX) installed first. If which xelatex prints a path in Terminal, you’re set.

If TeXworks is working for you, there’s no reason to leave. But if you’re searching for alternatives, something has probably started to pinch.

Where TeXworks starts to pinch

TeXworks was designed to be simple, and its limits are mostly the flip side of that choice.

• Multi-file projects. Once a thesis is split into main.tex and a folder of chapters, the structure sidebar only shows the file you’re looking at. There’s no view of the whole document.
• Autocompletion. Completion comes from fixed word lists, not from your project. Typing \ref{ won’t offer the labels you defined in chapter three, and \cite{ won’t offer your .bib keys.
• Finding errors. When a build fails, you read the console output and work out which file and line TeX was complaining about.
• Feeling at home on a Mac. TeXworks is a cross-platform Qt application. It works, but it doesn’t always behave like the rest of macOS.

None of these matter for a ten-page paper. All of them matter by chapter six.

The alternatives

TeXShop — the one already on your Mac

If you installed MacTeX, you already have TeXShop in /Applications/TeX. TeXworks was modeled on it, so the two-window workflow will feel familiar, and it’s a native Mac app. It’s free and mature. It’s the closest thing to “TeXworks, but on a Mac” — which also means it shares a similar philosophy of keeping things minimal.

TeXstudio — everything, everywhere

Free, open source, and packed with features: a structure view that follows included files, completion for labels and citations, an error list, a long menu of tools. If you want maximum capability without paying, this is the usual answer. Like TeXworks, it’s a cross-platform Qt app, so on a Mac it trades some polish for breadth.

VS Code with LaTeX Workshop — if you already live in VS Code

A general-purpose editor turned into a capable LaTeX environment by one extension. Strong on configuration, multi-file support, and everything else the VS Code ecosystem brings. The cost is setup: it’s a toolkit you assemble rather than an editor that arrives ready.

Overleaf — if you’d rather not install anything

LaTeX in the browser, with real-time collaboration that nothing local can match. Your documents live on Overleaf’s servers, and some features — longer compile times, full history, more collaborators — sit behind a subscription.

texspark — native, and built for multi-file projects

Full disclosure: we make this one. texspark is a native macOS editor built specifically around the point where TeXworks starts to pinch — a project that outgrew one file. The outline covers the whole \include tree, \ref{ and \cite{ complete from across the project, and ⌘-clicking the PDF opens the sub-file the text came from. It’s paid, with a 14-day free trial and no signup.

Moving your project over

The good news: there’s nothing to convert. Your files are plain .tex, and every editor above reads them as-is. A few habits are worth checking, though.

Magic comments. TeXworks users often put these at the top of each chapter file:

% !TEX root = ../main.tex
% !TEX program = xelatex

The first tells the editor which file to compile when you’re editing a chapter; the second picks the engine. TeXShop, TeXstudio, and LaTeX Workshop all understand a version of these, so they’ll mostly carry over. Overleaf sets the main document and compiler in the project menu instead. texspark uses a build target: double-click the root file’s tab once, and ⌘B compiles it from any chapter. The engine lives in the project’s build command.

SyncTeX. TeXworks passes -synctex=1 in its default tool configurations, which is why clicking between source and PDF just worked. If you set up a custom build command elsewhere, make sure the flag comes along — otherwise jumping between source and PDF will quietly stop working.

Your TeX distribution stays. None of these editors replace MacTeX; they all drive the same xelatex or pdflatex underneath. Switching editors doesn’t change your output.

Picking one

• You liked TeXworks’ simplicity and just want it to feel at home on a Mac → TeXShop
• You want every feature, free → TeXstudio
• You already write code in VS Code → LaTeX Workshop
• You collaborate, or don’t want to install anything → Overleaf
• Your project is many files and you want a native Mac app built for that → texspark

They look like the same environment with a suffix, and the documentation tends to describe them in terms of “inner” and “outer” mode, which doesn’t help much when you just want your equations to line up. Here’s the short version:

gather stands on its own and numbers every line. gathered lives inside something else and has no numbers of its own. That single difference explains everything else.

Both need amsmath.

gather — several equations, several numbers

Use it where you’d use equation, in the flow of your text. Each line gets centered and numbered separately:

\begin{gather}
  E = mc^2 \\
  F = ma
\end{gather}

That produces two equations with two numbers. You can suppress one with \notag, label them individually, and use gather* if you want none of them numbered.

What you cannot do is put it inside another math environment. gather expects to be at the top level, and nesting it will get you a math delimiter error.

gathered — one block, one number

gathered is a building block. It has to sit inside a math environment, and it borrows that environment’s numbering:

\begin{equation}
  \begin{gathered}
    E = mc^2 \\
    F = ma
  \end{gathered}
\end{equation}

Same two lines, but now one number for the pair, placed beside the block as a whole. That’s usually the reason people reach for it: two or three lines that belong together conceptually and shouldn’t be numbered separately.

Used on its own, outside math mode, it will fail — typically with a missing-$ complaint, since TeX hits math content where it expected text.

The thing only gathered can do

Because it’s a box rather than a full-width display, gathered takes an optional vertical alignment argument — [t], [c], or [b] — and can be placed next to other material.

\[
  \left\{
  \begin{gathered}[t]
    x + y = 1 \\
    x - y = 3
  \end{gathered}
  \right.
\]

Two gathered blocks can also sit side by side in one display, aligned at their tops or bottoms. gather can do none of this — it always occupies the full width.

You might want gather* instead

A common detour: someone wants a few unnumbered equations stacked up, reaches for gathered, and then has to wrap it in \[ ... \] to make it work. That detour exists because gather* was the answer all along.

Reach for gathered when you need the block to share a number with its parent, or when it has to sit inside something else. If you just want no numbers, the starred form is simpler.

The same pattern, everywhere

Once you see it, amsmath gets much easier to remember. The -ed suffix always means “the inner version of this”:

• gather / gathered — centered lines
• align / aligned — lines aligned at &
• alignat / alignedat — same, with manual column spacing

And split is the special case: an inner environment like aligned, but designed specifically to break a single equation across lines under one number.

Deciding in one step

Ask how many equation numbers you want.

• One per line → gather
• None → gather*
• One for the whole block → equation + gathered
• It needs to fit inside a brace, a cell, or beside something else → gathered

You ⌘-click a line in the PDF and the editor lands three pages away. Or nothing happens at all. SyncTeX is one of those features that either works invisibly or fails confusingly, with not much in between.

Here’s what it’s actually doing, and the four reasons it goes wrong.

What SyncTeX is

When TeX typesets your document, it normally throws away the connection between source and output. A line of .tex becomes ink on a page and the relationship is forgotten.

SyncTeX keeps a record of it. Compile with the flag on and you get a .synctex.gz file next to your PDF — a compressed map from source positions to page coordinates, and back. Your editor reads that map to answer two questions: “the cursor is on line 412, where is that in the PDF?” (forward search) and “the user clicked here on page 87, where did it come from?” (inverse search).

Everything that goes wrong is a problem with that map — it’s missing, it’s stale, or it points somewhere your editor can’t follow.

Nothing happens at all

The map doesn’t exist. Check the folder your PDF is in — if there’s no .synctex.gz (or an uncompressed .synctex), the flag isn’t on. Add it to your compile command:

xelatex -synctex=1 main.tex

With latexmk, add it to the engine options rather than latexmk itself:

latexmk -pdf -pdflatex="pdflatex -synctex=1 -interaction=nonstopmode" main.tex

One thing that catches people: some build scripts clean aux files afterwards and sweep the .synctex.gz away with them. If the file appears during the build and vanishes when it finishes, that’s your culprit.

It jumps, but to the wrong line

The map is stale. It describes the document as it was at the last compile, and you’ve edited since. Add twenty lines near the top and every position below shifts by twenty — SyncTeX has no idea.

Rebuild and the offset disappears. If it persists after a clean rebuild, the map is genuinely confused rather than out of date, which usually means one of the cases below.

It lands in the wrong file

This is the multi-file case, and it’s where editors differ most.

SyncTeX itself handles it fine. The map records which file each piece of text came from, so a paragraph pulled in through \include{chapters/ch7} is tagged as belonging to ch7.tex, not to main.tex. The information is there.

What varies is whether your editor acts on it. Some read only the file they compiled and land you at the corresponding line of main.tex — which is meaningless, since main.tex is forty lines of preamble and a list of includes. Others open the right file but lose the build target, so your next ⌘B tries to compile a chapter with no \documentclass.

If your jumps consistently land in the root file, that’s not SyncTeX failing. That’s the editor ignoring what the map already knows.

The paths are wrong

Rarer, but worth knowing. The map stores file paths as TeX saw them at compile time, relative to the working directory. If you compile from one directory and open the PDF from another — a build script that cds somewhere, an output directory set with -output-directory, a project moved after building — the paths no longer resolve.

Symptom: jumps work for the root file but silently fail for anything included. Fix: compile from the directory your source lives in, or rebuild in place after moving things.

How texspark handles it

The default build commands in texspark include -synctex=1, so the map is there without you thinking about it, and builds run in the build target’s own directory — which keeps the recorded paths resolvable.

For the multi-file case: ⌘-clicking the PDF opens the sub-file the text actually came from, at the right line, however many \include levels deep it sits. The build target stays on your project root, so ⌘B from that sub-file still compiles the whole document. Forward search (⌘⇧↩) works the same way in reverse, from any chapter.

If something here doesn’t match what you’re seeing, email support@texspark.io — it goes straight to the developer.