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.
Attached is a submission to the Australian Competition & Consumer Commission’s Digital Platforms Services Inquiry. It brings together a number of ideas which relate to Golgotha Graphics’ eventual decision to cease bringing new content to the Apple Books Store, and to pursue an independent sales model.
Starting 2022 with some minor typographic updates to all the Surfing The Deathline books, on both the Golgotha Graphics store, and the Apple Bookstore:
Further, to update the Apple Bookstore situation; the previous problems with cover display seem to have been resolved, after a few months in which the Apple Books Preview website wouldn’t display at all in older versions of Safari.
Since late 2013, Golgotha Graphics has been publishing exclusively on Apple’s iBooks / Apple Books store. We are now making a move to leave Apple’s store, and sell books independently, via a FastSpring store.
For people who’ve already bought our books via Apple’s store, the plan is to keep maintaining those works on Apple’s store, as a legacy option.
The first book to be exclusive to our FastSpring store, is the new, collected edition of Surfing The Deathline – “Full Course“. In addition, we have produced new JPEG versions of all five parts of Surfing The Deathline, which require around 1/3rd the storage space of the standard editions, and have a negligible loss of image quality. Again, these new versions are exclusive to our FastSpring store.
The motivations for this change have been brewing for some time. Broadly, it comes down to the following:
Apple is changing the appearance of our book covers on the Apple Books Preview website (support case No. 20000063806784), in a way that damages the integrity of the artwork, and potentially harms the reputation of both the artist, and the publisher.
Apple’s store only allows sales to Apple devices.
The Apple Books application has regressed in terms of what it lets us do from a creative perspective, which negates any benefit to us from investing time in creating versions of the books that only run on Apple’s platforms.
1. The Cover Problem:
As can be seen, the covers for Surfing The Deathline, which are supposed to be bright colours on a black background, are dark & muted. Important features – the red reflections in the glasses on the Fifth Dose cover, the entire background and character’s head in Fourth Dose, the Blue cogwheel in Third Dose, are rendered almost invisible, as are the author names, & Dose titles.
Even the book’s main title is barely readable.
The above image was taken in February, when we first became aware of the problem, and you can see the nature of it. We had just pushed an update to the two books on the left, and for some reason they received the new grimdark cover treatment. Checking the page out with WebKit’s inspector, we were able to turn off the coverart, and reveal the image templates used underneath.
What’s happening for Surfing The Deathline, is that Apple is adding a black book cover as a base image, and is then applying the uploaded cover art as a semi-translucent overlay. While this sort of thing seems to be un-noticeable on covers with the light base, on the dark base, huge amounts of detail simply disappear. Weirdly, their system is also lightening The Metaning’s cover.
When the other three parts of Surfing The Deathline were updated, they were also given the grimdark muddy covers.
We’ve talked to Apple’s bookstore Publisher Support staff multiple times on this issue, periodically checking up to see if there’s any update on when a fix will be put in place. Every time, the answer is the same “engineering are working on it”.
That wouldn’t be so bad, if they actually applied a temporary fix in the mean time.
The fix, by the way, can be achieved by Apple changing…
…on the CSS for the book cover images on the Apple Books Preview site.
All that does, is take away the faux-lighting effect on the cover art and make the covers look correct.
No one we’ve spoken to in Publisher Support can say why these covers are on a black background, it seems there’s no policy document they can refer to.
Is it some misguided aspect of DARK MODE, or is it an attempt at creating an overall look for comics in the store (and as you’ll see below, scifi books). Who knows?
What we do know, is that Nervous Spaces had a recent update, and didn’t get the black cover. That’s a reasonable test for whether Surfing The Deathline received this treatment on account of having a dark cover already.
It’s not just us, here’s a comparison of prolific scifi author Peter F. Hamilton’s books on Apple Books Preview, Vs. with Apple’s decorative CSS disabled – which is how the publisher would see them when uploading to Apple’s systems, and as they would appear in the Apple Books app.
How it looks…
How it SHOULD look.
We can’t imagine he, or his publishers are happy with most of his book titles, and author names being half-unreadable.
Perhaps Apple is working on a fix, perhaps not, but whatever they’re doing, it’s our books which look bad, and us who look like we don’t know how properly set the gamma on an image.
Suffice to say, Apple is treating our intellectual property, in a way they would never tolerate for their own.
2. The Sales Problem:
Apple’s store is only available on Apple devices. If you want to sell to someone using Windows, Linux or Android, even if you’re selling standard formats like EPUB or PDF, and have DRM disabled, you have to find additional distribution channels. This means:
Spreading your total sales out over multiple stores, each of which will have a minimum payout threshold.
Multiplication of workload from having to maintain multiple versions of your finished product – do you supply an EPUB to this store, a PDF to that store, CBZ to another store.
Upgrade policies – how does each store handle updates?
If you’re going to have to find alternative distribution options anyway, it really becomes a question of whether you’re better off just moving everything to a single store that serves all platforms equally.
One option to reach the widest target market, would be to sell via a third-party service like ComiXology, but revenue splits are generally worse, the further you go from selling directly. If you sell via a platform that offers a reading app and storefront on iOS, Apple takes their cut of the cover price, then the reading app platform takes their cut – some of them you end up only receiving ~35% of the cover price. We did the numbers on selling via Kindle a while back, and if we wanted to receive 70% of the cover price, rather than 30%, we would have had to pay Amazon ~AUD$25 in download fees, for every AUD$5 book we sold.
While FastSpring is a little more clunky in terms of updating books, it provides download hosting, and a zero-cost update facility, at a lower cost than Apple.
There is a caveat to this – your EPUB files aren’t DRMed, or watermarked, so if you’re really worried about piracy, perhaps look to a service that will lie to you with claims about having working anti-piracy technology.
We’ve decided to go with the honour system – making our work DRM-free, on the basis that we’re only ever going to get money from people who want to give us money, and those people deserve the best product we can give them. If that makes the work easier to pirate, that’s up to the consciences of the individuals stealing food from our mouths.
3. The Reading App Problem:
It was once argued that Apple’s take of the cover price was justified, on the basis that it funded a premium-experience reading application. When that reading app was iBooks, there was merit to that argument. But, with the rebranding to Apple Books, the app suffered significantly.
From a user-perspective, the app became slower to launch, and instead of simply opening where it was when you closed it, there’s now multiple seconds of displaying the “Reading Now” view, which has advertising for other author’s books, then displaying the cover of whatever you were reading, then animating opening the book to the page you were on.
The other major change, was a realignment of the UI/UX away from being user-library centric, with a store function, to being store-centric, with the user-library as a secondary option. The most glaring example of this advertising-everywhere dark pattern, is the “Audiobooks” section, which doesn’t show the audiobooks on your device (they’re in Library, in the Audiobooks sub-section), but rather shows the Audiobooks section of the Apple Books Store.
That aside, there’s a bigger problem with Apple Books for us as book developers, and that is the loss of interactive functionality available to book authors, as compared to iBooks.
In iBooks, we could do things using JQuery, or any other designer / non-programmer-friendly Javascript library, to create books that behaved more like applications, without having to build an entire paginated reading experience ourselves. For example, in our Derby Daze books, we were able to include settings to let users toggle image metadata labels on or off globally within the book. For The Metaning, we had the option to enable or disable panel numbering, as an assistive function for people who were new to comics. For Surfing The Deathline, we had something rather more special in development. Sadly, we had to abandon it once the change from iBooks to Apple Books removed the ability to set, and read cookies, which was the key to making things work.
Here’s a vision of what was supposed to be released as “Surfing The Deathline – Full Course”…
The Book That Never-Was:
The structure of the book had all the text on a separate layer. The text could be turned on or off, and additional layers could have been toggled on or off in order to provide additional language translations. This could be done on a page-by-page basis via little slide-in control panel, or globally, via an initial settings page.
Art was available in three versions – the finished art, the pencil sketches, and the rough thumbnails. The global settings would allow reading the whole book in any graphics mode, combined with the above text options, and again, the individual page control panel would let the reader switch pages between different modes.
The frame-by-frame view that ComiXology once (and possibly still does) claim (laughably) to have a patent upon, was going to be an option, using a standard off-the-shelf javascript lightbox.
Unfortunately, key to making all that work, was the ability to have pages in the book render based upon pre-set choices the user had made. With iBooks, we accomplished this by having the CSS display properties determined by the status of cookies that were set by previous user choices at the beginning of the book. Unfortunately, with the switch to Apple Books, it was no longer possible to set or read cookies on a page.
Like the cover art issue, we simply weren’t able to speak to anyone who could tell us why it wasn’t working. Apple’s publisher support people don’t handle technical authoring issues, and don’t have any direct communication with the people who make the app. They tried forwarding us to the Pro Media Support group, but they only support Apple’s authoring apps, not people hand-coding EPUBs in HTML. An EPUB book is not an app, so there’s no Developer Support options. Basically, it had been broken, no one could tell us why, and no one could tell us how to fix it. We looked through all the documentation for book developers to see if we could find an answer, but that documentation was merely the old (and in many places now incorrect) iBooks documentation, with “Apple Books” word-substituted for “iBooks“.
Publisher Support told us the case had been forwarded over to the Apple Books application team, who they couldn’t speak to directly, as a “feature suggestion”. So, we abandoned the project, and Surfing The Deathline – Full Course had its scope narrowed to just being the collected version of the standard art.
Conclusion:
With Surfing The Deathline – Full Course becoming just a screen version of a dumb print book, we went about stripping all the javascript functionality out of every book we had on the Apple Books Store, since they’d all stopped working properly. It became clear to us that there was no longer anything unique about Apple’s platform. Why make books for a specific reading app, if there’s no ability to do anything special with that app?
So, here we are – it’s sad we didn’t get to make the rich media book we know we can make, but on the upside, we’re now able to offer the same book experience to everyone, regardless of their choice of computing or reading device.
Change is coming to the Golgotha Graphics store – a change that’s been a long time in the making, but many, many years overdue – Books are going cross-platform, as emphasis is shifted away from the Apple Bookstore, and onto an independent sales model.
This will mean books are able to be bought by anyone with a web browser, and they’ll DRM-Free, so they can be read by any app supporting Fixed-Layout EPUB.
