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…
.we-artwork::after {
background-color: var(--background-color);
}
…to…
.we-artwork::after {
background-color: inherit;
}
…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.
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 authors’ 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.