Self-Publish an Ebook on One Mac with a Controlled Workflow

For a one-Mac self-publishing workflow, “finished” should mean one release candidate has a name, an inspection date, a known source set, and a repeatable rebuild path. An EPUB that merely opens is still a working file.

The example is a six-chapter horizontal essay titled Six Days by the Harbor. It has one cover and one colophon. Retailer setup is deliberately outside the workflow; the goal is to decide which local package is ready to hand to that later process.

Write the release definition first

Use a release card before exporting:

Field Planned value Acceptance rule
Title Six Days by the Harbor Cover, package metadata, and colophon agree
Author Minato Tomino The spelling agrees in all three places
Language and direction Japanese, horizontal Settings match the manuscript
Chapter order Prologue, Morning, Noon, Evening, Night, Afterword Navigation and reading order agree
Cover and colophon One of each Cover is packaged; colophon is last
Candidate name harbor-sixdays-v1.0-20260901.epub A record exists under the same name
Inspection date 2026-09-01 Any later edit produces a new version or date

The filename is a management example, not the name observed in the available export. Choose a convention that exposes the work, version, and inspection date for your own book.

Promote a build to candidate status

  1. Freeze six sources named 01-prologue.md through 06-afterword.md; compare their order with the release card.
  2. Enter title, author, language, horizontal direction, and version 1.0. Select one cover and one colophon.
  3. Set navigation inclusion separately from reading order. Do not count the cover and colophon as if they were ordinary manuscript chapters.
  4. Export and inspect navigation, reading order, packaged cover, and missing resources. If a check fails, return to the source or setting; do not assign the candidate name.
  5. Copy only the accepted EPUB into release-candidate/, then record its name, date, and completed checks. Begin retailer-specific preparation from a copy of that candidate.

Anything outside release-candidate/ remains a build. If you edit even one source after promotion, keep the old candidate, increment the version or date, and repeat the inspection.

Retain more than the EPUB

A self-publisher should keep:

Give a retailer only the files and information its current process requests. Do not mix the entire editable source set into the submission folder. If the retailer reports a problem, repair the source and build a new candidate instead of patching the submitted EPUB.

EPUB has distinct roles for package metadata, resources, reading order, and navigation. The EPUB 3.3 specification explains those boundaries and helps prevent a visible table of contents from becoming the only release check.

What the six-chapter run supports

Rune Studio’s published Mac feature set includes horizontal or vertical writing, chapter ordering, navigation, cover, colophon, and EPUB 3 output.

In a six-chapter horizontal exercise with no inline images, the package contained navigation and NCX data, one image, and no missing resources. A local package check reported a valid structure. Those observations support a bounded six-chapter EPUB result.

They do not establish the sample title and author, the proposed candidate filename, the inspection card, retention in release-candidate/, or a retailer handoff. Retailer acceptance, listing, and identical rendering in every reading system also remain separate checks.

A release candidate must be reversible

The endpoint of self-publishing on one Mac is not simply “an EPUB exists.” It is “one identified EPUB can be rebuilt from retained sources, and every correction has somewhere to return.” That is what keeps a retailer revision from becoming an untraceable patch.

Start by fixing the six-chapter order and filling out a release card. For more detail, review the Rune Studio download and feature page before promoting a package to candidate status.