The practical way to reduce app switching during ebook production is to give every correction one authoritative destination. The EPUB is an output to inspect, not the place where you repair chapter titles, metadata, cover text, or the colophon.
Consider a four-chapter essay. Its working set contains chapters/01.md through 04.md, book-info.md, assets/cover.png, and colophon.md. If those files own the content, every issue found after export has an obvious return path.
Build an ownership map before an ebook
App hopping becomes dangerous when the same information is editable in several places. A chapter title changes in a navigation tool but not in the manuscript. The author name changes on the cover but not in the package metadata. Fewer apps will not solve that conflict unless ownership is explicit.
Use a small table like this before opening the export controls:
| Item | Authoritative source | What enters the build | Where a correction goes | Acceptance rule |
|---|---|---|---|---|
| Chapter text and names | chapters/01.md–04.md |
Four chapters in a fixed order | The affected chapter heading | Order remains 1, 2, 3, 4 |
| Title and author | book-info.md |
Title, author, and language | book-info.md |
Cover, colophon, and metadata agree |
| Cover | assets/cover.png |
One image | The source image or metadata card | The cover is included in the package |
| Colophon | colophon.md |
One colophon | colophon.md |
Publication details are not retyped elsewhere |
| EPUB | Generated file | All approved sources | Never repair the EPUB directly | A rebuild reproduces the accepted package |
The map prevents a subtle mistake: treating navigation text as a second source. If a chapter name is wrong in the table of contents, correct the manuscript heading and rebuild. If the cover title conflicts with book-info.md, resolve which source is right before changing either output.
Give the workflow a handoff budget
Count a handoff whenever material leaves one app and must later return. A plausible old workflow might send manuscript titles to a navigation tool twice, metadata to cover and packaging tools twice, a cover from image editing to packaging once, colophon details back and forth twice, and inspection notes back to the editor once. That is eight handoffs.
For the mapped workflow, the target is zero cross-app handoffs after the cover asset is ready: sources stay in one workspace and corrections return to those sources. Eight-to-zero is a planning target for this example, not an observed result. Record your own before and after counts using the same definition.
Do not accept the workflow merely because the number falls. Reject it if any item lacks a correction destination. Conversely, a workflow with one necessary external handoff can still be safe when ownership is clear and a rebuild is repeatable.
Run the four-chapter production loop
- Duplicate the project, then place chapters, cover, metadata card, and colophon under one project folder.
- Fill the ownership map. Do not assign the same fact to two editable sources.
- Set horizontal writing, the four-chapter order, navigation inclusion, one cover, and one colophon. When a discrepancy appears, return to the mapped source instead of patching the export settings ad hoc.
- Export the EPUB. Check navigation, reading order, packaged cover, and missing resources separately.
- Apply corrections to the sources and rebuild. Confirm that the second package reproduces the accepted order and assets, then recount handoffs.
EPUB itself separates metadata, the manifest, the spine, and the navigation document. The EPUB 3.3 specification is useful here because a visible table of contents is only one part of the package.
What the sample established
Rune Studio’s published Mac feature description covers horizontal or vertical writing, chapter order, navigation, cover, colophon, and EPUB 3 output. In a four-chapter horizontal sample with no inline images, the generated package contained navigation and NCX data, one packaged image, and no missing resources. A local structure check reported a valid package.
That observation establishes the bounded EPUB result, not the eight-to-zero handoff target. It does not show that every correction returned to its owner, guarantee retailer acceptance, or predict identical rendering in every reader. Before adopting the workflow, run the ownership map with your own four chapters and record actual handoffs and return paths.
Choose one source, then choose the software
One-app ebook production is valuable when it protects a single source of truth. The decisive question is not whether every control fits in one window; it is whether every problem found in the EPUB can be traced back to exactly one manuscript, metadata, cover, or colophon source.
Start with four chapters, one metadata card, one cover, and one colophon. For more detail, review the Rune Studio download and feature page before choosing the workflow.