Let me establish my credentials for this comparison: my 2019 PhD dissertation was written in Texmaker. Every paper I’ve published — Texmaker. Every Beamer slide I’ve lectured from, for years of teaching — Texmaker. Ten-plus years, one editor. I didn’t evaluate alternatives annually like a responsible consumer. I just opened Texmaker every morning and wrote. That’s not usage; that’s a relationship.

So this is not a competitor dunking on a rival. This is a decade-long user explaining, with some tenderness, why he eventually built his way out.

What Texmaker got right

Among editors that compile locally, Texmaker had no real rival for years. Free, stable, everything in one window: editor, PDF viewer, structure panel, Quick Build one keystroke away. It ran the same on the Mac in my office and the Windows machine in the lab — for a grad student moving between machines, cross-platform wasn’t a feature, it was oxygen.

There’s a reason my entire academic output lives in .tex files shaped by its conventions. It never lost my work. It compiled what I told it to compile. For ten years, that was enough.

The itch that never went away

But a decade of daily use gives you a very specific list. Not of bugs — of almosts.

On a Mac, Texmaker always felt like a visitor. It’s a Qt app: keyboard shortcuts that were near-standard but not quite, font rendering a half-step off from every native app beside it. The structure panel stopped at subsubsection — I once patched the source myself to make it show paragraphs. Multi-file projects meant manually declaring a master document and remembering you’d done so. The PDF viewer synced, but with the enthusiasm of an employee near retirement.

None of these were dealbreakers. That’s precisely why they lasted ten years. Every single one was small enough to shrug off on any given day — and together they formed a low, permanent hum of friction I stopped consciously hearing.

So what is texspark, really?

The honest answer: texspark is my list of Texmaker itches, implemented one by one.

Native macOS text engine, so shortcuts and rendering simply match the rest of the system. An outline that goes all the way down and follows \include chains recursively — no patch required this time. A build target you set once (or that sets itself when you build from a sub-file). SyncTeX that jumps both directions across a multi-file project like it means it. Plus the things 2026 makes possible: a minimap, an AI panel beside the PDF.

Every headline feature traces back to a specific moment of “…almost” in my Texmaker years. It’s less a competitor and more a reply, ten years in the making.

The honest ledger

What Texmaker still has over texspark: it’s free, and it runs on Windows and Linux. If you live across platforms, or free is the requirement, Texmaker remains what it’s always been — the dependable answer. I’d never argue otherwise; I have a dissertation’s worth of reasons not to.

But if you’re on a Mac, and you know that hum I’m describing — the accumulated almost of a great tool that was never quite of your platform — that’s the exact gap texspark was built to close.

Fourteen-day trial at texspark.io. From one longtime Texmaker user to, quite possibly, another.

Dear stranger,

At 5:33 this morning — my time, not yours; for you it was probably a reasonable evening hour — you downloaded texspark. Safari, macOS, an IP address somewhere in Poland. That’s everything I know about you, and I’ve already thought about you more than is probably healthy.

You should understand the context. My download log so far reads like a directory of robots: Googlebot, AhrefsBot, OpenAI’s crawler, something called Dataprovider.com. My Telegram bot pings me for every download, and for weeks I’ve opened each notification the way you open junk mail — already knowing.

Then you. A real browser. A real Mac. A real person, presumably, with a real reason to want a LaTeX editor at that hour.

So now I’m wondering. Are you a PhD student with a deadline? A professor, like me, writing lecture notes? Did you find me through a search for something Texmaker-related, or did one of my tweets into the void actually land? Did the app launch fine? Did the trial banner make sense? Is it — and I ask this with my whole heart — working?

You have fourteen days. Somewhere around July 25th, you’ll decide whether texspark is worth keeping. No pressure. But here’s a small confession: the Purchase button isn’t even live yet — the business registration paperwork is still winding its way through the system. So I’ll make you a deal: before your trial runs out, I’ll ship a new release with the checkout actually working. You hold up your end by compiling something; I’ll hold up mine.

If anything breaks: support@texspark.io. It goes straight to me. There is, in the most literal sense, nobody else.

Powodzenia,
Jacob

Let’s get the honest part out of the way first: if you’re co-writing a paper with three collaborators who all need to edit the same file this week, use Overleaf. That’s what it’s for, it’s genuinely excellent at it, and no desktop app — mine included — replaces real-time collaboration in a browser.

This post is about the other 80% of LaTeX writing: the part you do alone.

What Overleaf is

A browser-based LaTeX environment. Nothing to install, TeX Live lives on their servers, your collaborators see your keystrokes live. For shared papers, class assignments, and “I just need to compile this once,” it’s the obvious answer.

Where the browser starts to pinch

Write in Overleaf daily — alone — and small things accumulate.

The connection. No wifi, no writing. Train, plane, café with hostile internet: your manuscript is a loading spinner.

Compile queues. On the free plan your document compiles on someone else’s schedule, with a timeout. A book-length project with TikZ figures will meet that timeout personally.

It’s a tab. Your editor lives between Gmail and forty other tabs, with browser shortcuts fighting editor shortcuts. ⌘W closes your chapter, not your document.

Your files aren’t files. They live in Overleaf’s storage. Git integration exists behind a paywall, but your local Spotlight, backups, and scripts can’t see your manuscript.

The subscription. Overleaf’s serious features — longer compile times, Git, track changes — are a recurring cost, forever.

What a native editor changes

texspark is the opposite set of trade-offs. Your files are on your disk — versioned, backed up, greppable. Compilation is your Mac’s TeX Live: no queue, no timeout, works on a plane. The editor is a real macOS app: system IME for Korean/Japanese/Chinese input, native Find bar, shortcuts that don’t collide with a browser. SyncTeX jumps both directions across multi-file projects, the outline follows your \include chain, and an AI panel sits where Overleaf has none meaningful. One-time license instead of a subscription.

What texspark doesn’t do: real-time collaboration. There’s no shared cursor, no comment threads. If that’s your daily reality, see paragraph one.

The actual decision

It’s not “which is better” — it’s where does your writing happen:

• Multiple people, one document, this week → Overleaf
• You, your Mac, a long manuscript → a native editor wins every day you sit down

Plenty of people use both: Overleaf for the shared paper, texspark for the thesis. Files move between them freely — it’s all just .tex.

Try the local side of the argument: texspark.io, 14-day full trial, no signup.

One month into writing the book, I asked Claude a question I probably shouldn’t have: at this pace, when do I finish?

It answered without hesitation, the way only something with no stake in the answer can. First draft: end of this year. Publication: early next year. On a bookstore shelf: next summer.

Next summer.

Here’s the strange part: I wasn’t discouraged. There’s something clarifying about a timeline with zero flattery in it. A friend would have said “it’ll be done before you know it.” Claude just ran the numbers.

And the numbers are fine. Books take the time they take — the whole premise of Machine Learning from Scratch is building things properly from the ground up. It would be embarrassing if the book itself were an exception.

Back to chapter 5. See you at the bookstore. Apparently.

Every LaTeX writer has one. You might not have chosen it consciously, but somewhere along your first hundred equations, your fingers picked a default — and now it’s less a technical decision than a personality trait.

Here’s the lineup.

equation

The institutional choice. Numbered, respectable, exactly one equation at a time. People who default to equation cite theorems by number, keep their references in order, and probably have a .bib file that doesn’t embarrass them. The paperwork of mathematics, filled out correctly.

align

The workhorse. Once you’ve derived anything across multiple lines — an & here, a \\ there — you never quite go back. align people are process people: they want you to see how they got there, step by step, aligned at the equals sign like a well-organized argument.

The dark side: align users have all, at some point, used it for a single equation out of pure muscle memory.

gather

The rarest breed. Multiple equations, centered, no alignment — gather says “these belong together, but I refuse to impose a relationship on them.” Honestly, I respect it. Choosing gather means you know align exists and decided your equations deserve to stand on their own.

\[ ... \]

The minimalist. No number, no name, no ceremony — just math, displayed, gone. \[ people write quickly and don’t look back. They’ll tell you most equations don’t need numbers, and they’re right, and it’s still slightly unsettling how little they care.

(If you write $$ ... $$ instead: I see you. TeX purists would like a word, but I see you.)

eqnarray

Ah. So you learned LaTeX from a thesis template last touched in 2003, passed down through your lab like an heirloom nobody examines too closely.

Here’s the thing nobody in that lab told you: eqnarray has been considered obsolete for decades. The spacing around the equals sign is subtly, famously wrong — wide enough that amsmath’s documentation politely pretends it doesn’t exist. Every eqnarray in the wild is a small archaeological record of how LaTeX knowledge actually spreads: not through documentation, but through inherited templates and the phrase “just copy what the last student did.”

Switch to align. It takes five minutes. Your equals signs will thank you.

(If you knew all this and use eqnarray anyway: you are a chaos agent, and I’d love to know what else is in your preamble.)

For the record

I’m a gather person. I like my equations centered, independent, and free of imposed relationships — which, now that I write it down, may explain more about me than about my typesetting.

What’s yours?

---

Short answer: you can open a .tex file in Xcode. You can also eat soup with a fork. Nobody’s stopping you.

I understand the impulse, though. If you’re a Mac developer who suddenly needs to write a paper — or an academic who happens to live in Xcode — the question is natural. You already have a professional editor installed. It has syntax highlighting, a file navigator, and find-and-replace that works. Why install anything else?

Here’s what happens when you try.

What Xcode gives you

Xcode will treat your .tex file as plain text. You get the editor surface — which, to be fair, is excellent. Native text engine, flawless IME handling for Korean, Japanese, and Chinese, buttery scrolling, every macOS keyboard convention you already know. The bones are good, because the bones are AppKit.

What Xcode doesn’t give you

Everything else.

There’s no LaTeX syntax highlighting — your \section commands sit there in monochrome. No build integration: you’ll be alt-tabbing to Terminal to run xelatex, then to Preview to see the PDF, then back to Xcode to find your place again. No SyncTeX, so “where does this paragraph appear in the PDF?” is a question you answer by scrolling. No document outline, no autocompletion for the four hundred LaTeX commands you half-remember, no error list that jumps to the offending line.

You can bolt some of this together with Run Script build phases and external tools. People have — there are decade-old Stack Exchange threads with heroic Xcode-LaTeX configurations, and they all read like instructions for teaching a horse to drive.

The instinct is right, though

Wanting to write LaTeX in a real native Mac app — with the system text engine, real IME support, and keyboard shortcuts that match every other app you use — is exactly the right instinct. Xcode just isn’t the app.

That’s roughly why I built texspark. I wanted the part of Xcode that’s good (the native editor feel) attached to the parts LaTeX actually needs: one-keystroke builds with any engine, SyncTeX in both directions, an outline that follows \include chains, autocompletion that knows the difference between \ref{ and \begin{, and an error list where clicking a row lands you on the line that broke. Plus an AI panel, because it’s 2026 and half my debugging is asking Claude why my table is off the page.

One-time license, 14-day full trial, and it weighs a lot less than Xcode.

If you still want to use Xcode

Genuinely, no judgment — here’s the minimal setup: install MacTeX, add a Run Script build phase calling xelatex -interaction=nonstopmode "$FILE", and keep Preview open next to it. It works. For a two-page document, it’s fine.

For a thesis, come back to this post. I’ll be here.

Looking for a Texpad (Texifier) Alternative on Mac?

If you typed “Texpad” into a search box recently, you know it goes by Texifier now. And if you’re searching for alternatives, you’re probably not unhappy so much as curious — wondering what else the native-Mac LaTeX world has to offer these days.

Fair question. The answer used to be “not much.”

Credit where it’s due

Texpad earned its following. It was, for a long stretch, the definitive native LaTeX editor on the Mac: fast, polished, with a live-typesetting engine of its own and an iPad version to boot. Texifier carries that lineage on, and if it fits your workflow, this post won’t talk you out of it.

But “native Mac LaTeX editor” was a category of roughly one for a long time, and having options is healthy.

What the rest of the landscape looks like

Texmaker and TeXstudio are free and capable, but they’re Qt apps — functional, cross-platform, and unmistakably not Mac-native. Overleaf is a browser tab with a subscription, brilliant for collaboration, less so for offline work. VS Code with LaTeX Workshop is powerful if you enjoy configuring things, which is a specific personality type.

If what drew you to Texpad was the native part — system text engine, real IME support, keyboard conventions that match every other Mac app — that list doesn’t offer much.

Where texspark fits

texspark is my addition to the category. Native SwiftUI + AppKit on the system text engine, so IME input, dictation, and every macOS text convention just work. It drives a standard TeX distribution (MacTeX/BasicTeX), so your documents build identically everywhere. SyncTeX in both directions across \input/\include files, a recursive outline of your whole project, a customizable build pipeline, and an AI panel for the “why is my figure floating to page 9” moments.

One-time license, 14-day full trial, no signup.

The honest caveats

texspark is macOS-only — no iPad version, unlike Texifier — and it’s young. It also doesn’t bundle a typesetting engine; it drives the TeX Live you install. If iPad editing or built-in live preview matters most to you, Texifier holds those cards.

But if you’re a Mac-first LaTeX writer who likes the idea of two good native options instead of one: texspark.io. Kick the tires for 14 days.

Here’s a problem they don’t teach you in a PhD program: I made a thing, and I have no idea how to tell people about it.

The building part, I understood. Every problem had a shape — you debug it, it works, you move on. Six weeks of that and texspark became something I genuinely reach for every day, which is the highest praise I can give my own software.

Then I looked up from the code and realized: nobody knows it exists.

So far my marketing strategy has been, in its entirety: tweeting into the void with #buildinpublic, writing blog posts like this one, and refreshing a Telegram bot that mostly reports visits from Googlebot. (Hello, Googlebot. You’re my most loyal user.)

The honest inventory of what I know about marketing: Nothing. That’s the inventory.

But here’s what I’m trying, in increasing order of terror: SEO groundwork first — comparison pages, feature docs, blog posts that might index before anyone searches. Then the communities where LaTeX people actually live. Then, once the checkout pipeline is real, the big swings — Show HN, Product Hunt — the places where an indie app either finds its people or dies in the “new” tab.

If you’ve marketed a developer tool before, I would genuinely love to hear what worked. And if you haven’t but you write LaTeX on a Mac — well, that’s convenient. texspark.io. Tell a friend. Apparently that’s how this works.

Last month I set out to write a book. What I actually did was build a LaTeX editor.

The plan was always “just fix this one thing, then get back to the manuscript.” One thing became a build pipeline, then SyncTeX, then an AI panel, then a minimap, then session restore, then — you get the idea. The git log reads like a confession.

But somewhere in the last week or two, something changed. I’d sit down to write, reach for a feature that wasn’t there, and find that… it was there. Forward search landed exactly where I expected. The outline followed my \include chain without complaint. The build target stayed pinned to main.tex no matter which chapter I wandered into.

The editor stopped getting in my way — which was the whole point, one detour and one month ago.

So this week, I opened chapter3.tex. Not to test bracket matching. To write.

texspark isn’t finished — no software ever is. There’s still a list of things I want to build, and the changelog will keep moving. But it’s crossed the threshold from “project I’m building” to “tool I’m using.” The dogfooding phase is over; the dog is fed and the food is fine.

The book is about machine learning, written in Korean, typeset in LaTeX — obviously. If the editor holds up through a few hundred pages of equations, figures, and my questionable prose, you’ll know the 1.0 badge was earned.

Back to the manuscript. For real this time.

It was 2:49 AM and I was deep in a debugging session with Claude — the kind where you’ve lost track of time and the git log is starting to look like a diary of questionable decisions.

Then the notification: You’ve reached your usage limit.

And right below it: Your limit resets at 2:50 AM.

One minute. My AI pair programmer had walked out on me — for exactly sixty seconds.

I’d like to tell you I used that minute wisely. Stretched. Drank water. Reflected on my life choices. What actually happened is that I sat there watching the clock, waiting for my robot colleague to come back from its one-minute break.

It came back at 2:50. We kept going. I went to bed at 4.

There’s probably a lesson here about work-life balance, or about how “my AI ran out and I had to wait a minute” is now a genuine inconvenience in a developer’s night. But mostly the lesson is: I should go to bed earlier.

(I won’t.)