Golgotha Graphics has published about reasons for diversifying away from the Apple Books Store, but up until recently the Apple Books application (formerly iBooks, currently Books) itself was both a gold standard for reader applications, and for the Mac version, a vital piece in the EPUB production process.
Unfortunately, that is no longer the case.
To explain, an EPUB eBook is a website with certain specialised attributes, which is then zip compressed into a single file. Authoring an EPUB book, for people who really care about their craft, is something best done at the code level – editing the HTML and CSS to both place content, and control that content’s appearance.
There are significant technicalities when making the fixed-layout EPUB books we publish – comics and fine-art photo books, which require this code-level precision when authoring.
The role of Apple Books for Mac, was to push an EPUB project to an attached iPad as a proof, while it was still under development and not zip compressed. This ability to update the source files in the proof on the Mac, and see those changes in the actual deployment target made it a vital part of the EPUB authoring process.
This meant an author could change a word, or a colour in the authoring files, save the individual file, and then watch their book on the iPad update in real time as the changes are pushed to the device. Frequently, it would even stay on the same open page in the book, and refresh the page to the new content. This was literally the core of the EPUB authoring process.
With macOS Monterey, Apple discarded the Mac version of Apple Books, and replaced it with the iPad version, running through a compatibility technology. The iPad version lacks the entire push-to-device proofing workflow, and so the Mac version has lost that workflow.
What was previously:
- Change an authoring file.
- Save the change.
- eBook is automatically updated on the iPad to reflect the change while reading position is unchanged.
Is now:
- Delete the old proof copy from the iPad (because images are cached so aggressively that changes to them won’t show up unless the file is physically removed and re-added).
- Change an authoring file.
- Save the change.
- Airdrop your development version of the file to your iPad.
- Wait for the file to be imported to Apple Books.
- While this is happening, the entire book is being uploaded to your iCloud storage, so you have to make sure you have enough space in your iCloud plan.
If the change isn’t quite right?
Do those steps again – one keyboard shortcut for Save, the old way, Vs. multiple steps and bandwidth use as the new sweet solution.
Every. Single. Change.
Apple, for its part, avoids addressing this workflow regression by stating that EPUB authoring has now moved to the Pages application. This would be fine, except that the Pages application outputs terrible, unprofessional spaghetti code, and the image compression settings provide for no real control over the quality of the compressed images produced.
Ultimately, Pages and Apple Books are unfit for purpose as authoring tools.
The only real solution, therefore, is to use an older copy of Apple Books on an older Mac, running a pre-Monterey version of macOS, since Apple Books can’t see a connected iPad from within a (VMWare Fusion) virtual machine, even though iTunes and Finder in that virtual machine can.
After 30 plus years of using Macs, we are profoundly disappointed that a bad decision to replace a Mac app with a less-capable iPad version, has resulted in this entire task becoming something we simply cannot do as well with a contemporary Mac, as we could with the systems of a few years ago.
We are giving significant thought to abandoning the EPUB format entirely, and moving to simple CBR / CBZ archives, which will probably see us pull all our books from the Apple Books Store entirely, and stop expending effort on optimising for Apple devices.
Ultimately, the solution to this would require Apple to return the proofing workflow to the iPad version of Apple Books, where it would then carry over to the Mac version. A good solution, which could avoid the need to engineer a direct Mac-to-iPad push-to-device system, would be to allow Apple Books on an iPad to load, and maintain a live connection to an uncompressed proof directory that is stored on a network share, via WebDAV or SMB. That way an author can just enable file sharing to the directory in which they keep their development EPUB, load the development version as a proof from the iPad directly, and the whole push-to-device problem is solved.