Next week, I shall—at long last—be submitting Scrivener for iOS to Apple’s TestFlight beta-testing program. It has spent the past month in alpha-testing in-house (I am writing this blog post in Scrivener on my brand new iPad Pro 9.7”, in fact), and we’re now ready to open up testing to a slightly larger group. We’ve had a lot of users emailing us asking if they can beta-test, so in order to be entirely open, I thought I’d explain how we are going to approach the beta-testing process.
We’re going to run the beta in two rounds. For this first round of testing, we’re using a private group of testers on an invite-only basis. That sounds a bit clique-y, but actually there’s no favouritism or secrecy in how this group is selected: we’re always on the lookout for users on our forums, social media pages and through our tech support channels who seem particularly good at finding and reporting bugs (perhaps because they are very patient when tracking down a gnarly issue or because they are good at communicating problems—or maybe they’re just good at breaking things). We ask such users to help with early betas of our software when needed (I’m sure there are many, many users we have missed, though). These are our Guinea pigs, in other words, and we know that they won’t shout at us when their work blows up because of a typo with a semicolon on line 956 of the Dropbox syncing code.
After the initial round of beta-testing with the closed group, once we’re happy there are no obviously nasty data-loss or sync bugs that might cause issues for a larger group, we will throw the doors open, make the beta public, and ask for volunteers. We won’t be able to accept everyone, because there’s a limit to how many users we can add as beta-testers via Apple’s TestFlight program, but all of those of you who have been so enthusiastic about getting your hands on it will be able to put your name in the virtual hat. We’ll put up a form on our site where anyone can apply, and we’ll provide information about what you will need in order to be a beta-tester (which mainly just comes down to patience and being prepared to come across and report bugs). I’ll post information about that here, on the forums, and via our social media sites, when the time comes.
Alpha testing has been a fun process, by the way (apart from the awareness that every day in alpha is another day the software is late, of course!). If beta-testing is where you sand down all those rough edges and fix the broken parts, alpha-testing is where theory meets practice and you realise that as great as your sketches and notes for feature X looked, something about it feels awkward to use now that it’s there in front of you on your iPad.
For instance: Scrivener’s binder was originally a solely drill-down affair. Tap on the Draft folder, and a list of its subdocuments slide in; tap on “Chapter One” inside the Draft, and its subdocuments slide in. That seemed like a very iOS way of approaching it on paper, and a great way of viewing sections in isolation. In practice, however, it’s not so great when you want to get more of an overview of your manuscript, and it means a lot of drilling down and hitting “Back”. So, during the alpha, I added the ability to expand and collapse folders and groups just like on the Mac (but in an iOS way), providing the best of both worlds (because you can still drill down too).
Another “for instance”: To begin with, the inspector on iOS always appeared in a floating panel. But this meant you could never have it open directly alongside the editor or corkboard. So during alpha-testing, we came up with another solution for this, keeping things simple and “iOS-like”, but allowing for more flexibility.
Not only that: during the alpha period, Compile was massively improved, the import and export formats were expanded, corkboard images were added, and much, much more—other features we’ll start talking about soon. I don’t want to waffle on about all the great features while there’s not a release date, though, as that will just cause frustration (understandably). Right now, I’m excited that we are finally going into beta. Look out for the call for volunteers in a month or so, and we’ll start talking about the software, and posting screenshots, once the larger beta is in full swing and we’re close to release.
Oh, before I sign off, some answers to questions that come up a lot in the comments:
- Scrivener for iOS will run on most iOS devices – the only requirement is that it can run iOS 9 and above.
- It runs on iPhones as well as iPads (although certain features that require more space—such as the corkboard—are iPad-only).
- It supports the multi-tasking features of the iPad Pro.
- Scrivener for iOS will not support iCloud (at least for now) – syncing will be done via Dropbox. I’ll write a post explaining why soon. (You’ll be able to leave your desktop project open while you’re off using it on your mobile device, though.)
I think that covers the most popular questions I got asked in the comments last time, but I’ll do my best to answer any other questions in the comments here.
Thanks again for everyone’s enthusiasm and support—the response to the last post was overwhelming in its positivity, and we all at Literature & Latte hugely appreciate it.
I know we’ve been quiet about the iOS version recently, and some users have been wondering if it’s still in development. After all the problems we’ve had with it, I took over development myself last year and rewrote it from the ground up. I had originally planned not to develop it myself so that I didn’t have to divide my time between the Mac and iOS versions, but in the event, coding our iOS version turned out to be a lot of fun, especially with the introduction of the iPad Pro. Adapting Scrivener for iOS felt like going back to the beginning and remembering why I built Scrivener in the first place.
I’ve now finished the rewrite and it’s in internal alpha-testing, which is going well – in fact, I was on holiday last week, and wrote exclusively using Scrivener on my iPad Pro. As soon as it’s in beta – which shouldn’t be too far away now (really, this time) – we’ll start bringing you more news. We’re incredibly proud of how it’s turned out, and I can’t wait to tell you more about it, and to get it into the hands of our users at last.
Thank you for your patience, your support, and your enthusiasm while Scrivener for iOS has been undergoing its long gestation.
— Keith (Scrivener designer, Mac and now iOS developer)
We’re looking for another iOS coder to help speed things along with getting our iOS app finished. Full details can be found here:
If you’ve got the right sort of experience and skills, and are interested in working with us, please drop us a line.
(A note to our users who have been waiting on this for far too long now: the iOS version has been feature-complete for a month or two but we are incredibly disappointed to say that it is still not ready for public beta testing – as we had hoped it would be by now – because of a number of outstanding issues. We are thus looking for a talented developer to help us get it ship-shape.)
This is one of my favourite buttons in Scrivener:
It sits in the footer bar below the outliner and corkboard, and it has sat there for several years now. Maybe you use it all the time; maybe you’ve never noticed it; maybe you’ve clicked on it and wondered what it’s for. It’s called the “Selection Affects Other Editor” button, and that’s exactly what it does.
Here’s how it works:
Split the editor so that you have two editor panes open.
Load the corkboard or outliner in one of the editors (usually the top or left one if you work in a left-to-right language).
Click on this button at the bottom of the corkboard or outliner so that the arrows turns blue.
Now, whenever you click on an index card in the corkboard, or on a row in the outliner, the document it represents gets opened in the other editor. Thus, you can use the corkboard or outliner to navigate instead of (or as well as) the binder.
In this way, Scrivener’s two editors can operate independently, or they can be linked so that one is used to navigate the other. It’s a feature I use all the time (I like being able to navigate from the outline, where I can see all my synopses), and it’s a feature that’s going to become even more useful in the future. It’s also a feature that, although it might at first appear trivial, had a deep influence on how we approached navigation in the iPad version. (But more on that soon.)
We have a lot of people asking after the iOS version given that I haven’t posted much about it on here recently (although I have been giving incremental updates over on the forums). The lack of updates isn’t intended as a slight against our very valued users; it’s just because we’ve had our heads buried in code and haven’t been coming up much for air.
The good news is that our iOS version is (at last!) feature-complete and is currently in internal beta-testing. We’re in the process of smoothing out the rough edges we find through use and fixing bugs before we make it available to our wider beta-testing group. Having taken so long to get to this stage (we know), we don’t want to fall at the last hurdle and rush beta-testing. After all, the sync code is complex (it was a three-month job in itself) and we want to ensure it’s never going to cause any data-loss in the real world (it is holding up well in testing so far, though). Once it’s out with our wider beta-testing group, I’ll start posting some screenshots and showing off the features. Given past debacles, I’m hesitant to talk about release dates, but we expect a summer release, though whether mid or late summer will depend on what is thrown up during beta-testing, of course.
To answer some common questions we’ve had about the iOS version:
- Version 1.0 will sync with the desktop version using Dropbox. The sync code has two components, the Dropbox-specific code, and the code that handles merging all the changed files between platforms and dealing with conflicts. This second part of the code has been designed for reuse with other sync clients, so we plan on adding support for sync solutions other than Dropbox post-1.0 (Cubby is one that has been requested several times, for instance).
- There is no iCloud syncing in 1.0 because iCloud does not work well with package-based file formats such as Scrivener’s. We were hoping that iCloud Drive would provide a solution, and are still looking into it, but the APIs don’t seem to provide the flexibility we need on the iOS side. (The reason syncing is more complex with Scrivener than for most apps is because .scriv files are really folders, which is how we can allow you to import any sort of research file and only load files into memory as they are viewed in the app.)
- You can also transfer projects simply using iTunes, of course.
- When the iOS version is released, there will be simultaneous updates for both Scrivener for Mac and Windows that provide sync features. So don’t worry, Windows users, we have no plans of leaving you unable to sync!
- Version 1.0 will not have any dedicated screenwriting features, but scriptwriters will be able to sync their scripts using Fountain syntax for paragraphs.
- Scrivener for iOS is a full-featured writing environment – the binder, corkboard, outliner, full rich text editing (with comments, internal links and so on), import, export, reference to other documents (including images, PDFs, media files) – all the core features of the desktop version are there in the iOS version, but with a UI designed from the ground up for mobile devices.
- Scrivener will require iOS 7.0 or above.
It’s been a long journey, but at last the light at the end of that proverbial tunnel is in sight. I can’t wait to start showing you screenshots and talking about it properly.
It’s not all about the iOS version, however: our heads have been buried deep in code working on serious and extensive (and exciting) updates for our existing platforms, too. But we’re not yet ready to talk about those, and we want to get the iOS version out first.
EDIT: We’ve had a lot of users ask about how to get involved in beta-testing the iOS version (thank you!). In the past, the way we have always selected beta-testers has been to look out for users on the forums and social media pages who know their way around Scrivener, are good at reporting bugs or giving constructive feedback, or who post useful information on using Scrivener for fellow users. We continue to look out for new beta testers that way, and from that, we already have quite a large pool of testers for the Mac and Windows versions to whom we’ll be sending out iOS beta invites to begin with. Once we’ve got a better idea of what the numbers are like, and when the time comes, I’ll post more information here on how to apply to become a beta-tester for anyone else interested. Please note that it’s not a good idea to apply to beta test if you just want early access, though – the beta-testing stage is where we find the most bugs, so you have to be prepared for crashes and even possible data-loss (obviously we hope to have ironed out data-loss bugs by the beta, but beta-testing is where users find the things we’ve missed and we cannot guarantee that there won’t be hideous bugs lurking – beta-testers are guinea pigs). Beta-testers also have to be prepared to spend time trouble-shooting and providing us with detailed reports on every issue they find. We’ll provide more details once we’re nearing the end of internal testing.
We’re running a quick survey to find out how our customers are using Scrivener. This information will help us plan and prioritise new features, and to work out how to reach potential new users of Scrivener in the future. It should only take a few seconds to fill in, and we’ll be very grateful to anyone taking part:
I learned two new “G” words last night: GamerGate and Gawker. Perhaps I’ve been living under a rock, but until about 8pm yesterday evening, I’d heard of neither of them. Then, suddenly, according to the Twittersphere, we had come out in support of GamerGate – which was news to all of us. I’d therefore like to set the record straight.
First, as I understand it, what has been claimed is this: that we have withdrawn advertising from Gawker following pressure from GamerGate. It would, in fact, be impossible for us to withdraw advertising from Gawker, because we have never knowingly advertised through Gawker in the first place; we have never had any form of relationship with Gawker. Not that this was a conscious avoidance – Gawker just wasn’t something that was even on our cultural radar. We do very little advertising, as it very rarely has much effect for us. Back in the summer, we did run a promotion with StackSocial, who pushed Scrivener through social media and various sites, and from what I understand, we appeared briefly on Gawker through that promotion (although we never saw the advertisement ourselves, and Gawker wasn’t on the list of sites StackSocial advertises with).
Following that, we received a number of emails from apparently concerned Scrivener users, expressing disappointment at our involvement with Gawker, and providing numerous links purporting to show Gawker as an evil, sexist and bullying entity. (It turns out that these emails may not have been from Scrivener users, as I have since learned that GamerGate supporters routinely send these exact same emails to many companies.) This is where we went wrong. The person who responded to those emails (actually two people responded to the emails, but using the same reply as written by one person), having never heard of GamerGate or Gawker either, was somewhat naive in his reply. He thought he was merely reassuring an upset user that we wouldn’t knowingly get involved with companies with bad reputations for bullying or sexism. (If we ever receive a complaint from a user about a company we have been associated with, we always take it seriously as we do our utmost to work only with ethical and like-minded companies.) Unfortunately, then, he wrote his reply without knowing anything about GamerGate and without actually researching the allegations about Gawker, and also over-stepped the mark a little in his reassurances. He certainly had no idea that he was unwittingly stepping into the GamerGate controversy.
Below is his stock reply that was sent to those who wrote to us complaining about our apparent association with Gawker (to put it in context, all of the emails we received contained multiple links pertaining to Gawker, and claims about large and reputable companies dropping support of that site). This is the reply that was posted on social media by GamerGate as though we were coming out in support of them:
Our reply was ill-informed, since we knew nothing about Gawker Media beyond what the person writing to us had told us, and the person who wrote the above email should not have said that we’d be saying no to any further marketing approaches from StackSocial since no such decision had ever been made among the directors of L&L. (And, just for the record, I have no opinion on Gawker either way, as it’s not a site I’ve ever looked at or read. My wife looked at it briefly last night and was less than impressed, but that’s about the sum total of L&L’s knowledge of the site.) What the reply should have said is that we would look into their allegations before pursuing future marketing promotions, which is what we would do with any such complaint.
So, just to be very, very clear: we are not affiliated with GamerGate in any way, nor have we endorsed the movement. Nor have we withdrawn any advertising because of pressure from the GamerGate community, since there was nothing for us to withdraw anyway. We have simply been drawn into something of which we were entirely oblivious because of the over-zealous reassurances of a member of our staff to what he thought was a concerned user.
Our official statement, a version of which was sent to The Verge and which was also posted on Reddit last night, is as follows:
Literature & Latte is most certainly not aligned with GamerGate in any way, and we have been somewhat caught off-guard. To be honest, I hadn’t even heard of GamerGate until all of this happened. We have, unfortunately, been rather naive. We received several emails complaining about our involvement in promoting Scrivener through a particular company of which GamerGate disapproves. We were entirely unaware of GamerGate and its associations, and the emails we received provided links purporting to prove sexist and bullying behaviour on the part of said company. As our company is – naturally – against bullying and sexism of all kinds, the person on our team who responded to those emails said that we would refuse further marketing approaches, unfortunately before researching the matter further and without consulting other members of the team. That is the entire extent of our involvement. We have not withdrawn any advertising from anywhere, as there was no advertising in place to withdraw. Had our member of staff been aware of GamerGate and the harassment with which it has become associated, our response would have been much more circumspect. We were certainly most surprised to see our reply to what we thought was a genuinely concerned user posted on social media as if we were endorsing GamerGate – we were not.
Literature and Latte is committed to equal opportunities (our company itself comprises an equal number of men and women across all positions on the team). Bullying and harassment, whether online or off, is abhorrent and Literature & Latte does not tolerate such behaviour in any form.
We would like to apologise unreservedly for any offence we have caused in our naive and un-researched responses and the way they have been represented.
In addition to that official response, I will also say this: bullying and harassment, whether sexist, homophobic, racist or anything else, is never, ever acceptable or justifiable, wherever and however it occurs, and the effect it has on its victims is hideous. I’ve seen some of it first-hand. Julia, my wife and fellow director at L&L, is also a journalist, and some of the online comments I have seen about one of her articles in particular were absolutely disgusting and sickening, of a kind that would never be posted about a man. I’d like my daughters (and son) to grow up in a better world than that, and I have absolutely no time whatsoever for anyone on any side of any movement involved in the harassment of women or of anyone else.
Yosemite is nearly upon us – the rumour is that Apple will release OS X 10.10 today, announcing it at their iPad event. Yosemite is a major upgrade to OS X, introducing a number of significant UI changes. (Sadly, it is not without its share of bugs at this stage.) Accordingly, we have just released Scrivener 2.6 for Mac, which adds support for Yosemite, fixing all known compatibility issues and updating several UI elements to better fit with the look of the new OS. We have also released Scapple 1.2 for Mac, which likewise addresses all known Yosemite compatibility issues.
Users who purchased from us directly can either update via the “Check for Updates” feature in the application menu, or re-download and re-install from our site. We’re sorry to say that Mac App Store users will have to wait a little longer for the updates – we have submitted the updated versions to Apple but they are still waiting for review. We had hoped they would have got through the review process by now, but presumably Apple has a backlog with many apps receiving updates for Yosemite.
There is one remaining known compatibility issue between Scrivener 2.6 and Yosemite: the Facebook and Twitter services integration in Scrivener (which allow you, for instance, to tweet your current word count progress) no longer work on OS X 10.10. This is because Apple has changed these services so that they no longer support 32-bit apps, and Scrivener is currently 32-bit. I brought this to Apple’s attention during Yosemite’s beta-testing period, but its engineers informed me that they had no intention of fixing it, meaning that only 64-bit apps can use these features moving forwards. Unfortunately, it’s not possible for us to update Scrivener 2.x to become a 64-bit app, because, owing to the frameworks it uses for features such as media file viewing, such a move would break backwards-compatibility with older versions of OS X.
I really like Yosemite’s new interface, and am happy to see Apple turning its attention to the Mac once more and giving it a facelift. (Let’s ignore the garish blue folders in the Finder – a number of developers asked Apple to fix that, but someone at Apple must like eye-bleeding colours.) Upon updating to Yosemite and acclimatising to the greatly-refreshed interface, however, some users might be forgiven for thinking that Scrivener’s interface isn’t yet fully adapted to its new environment (its binder is still blue rather than translucent, for instance). This is because we have so far focussed on functionality, ensuring that everything is working correctly, only updating the UI where problems arose. The changes in Yosemite are extensive, and the differences in its UI are only the tip of the iceberg – under the surface, in the Cocoa frameworks, almost everything has been modernised. This is an exciting time for Mac apps, but rather than try to rush through the changes, we have decided to take the time to get them right.
So, the good news is that, behind the scenes, we haven’t been slacking off – we’ve been quietly laying the foundations for development on the next phase of Scrivener – on both platforms. On the Mac, that means converting the codebase to be 64-bit compatible and to use all modern Cocoa and Objective-C conventions (and to be Swift-compatible – Swift being Apple’s brand new development language). It also means overhauling the interface to better fit in with Yosemite design aesthetics. On Windows, it means rewriting the way certain features work, such as scrivenings and outliner mode, to be more akin to the Mac, and catching up with Mac features while the codebase refresh take place in the Mac version. There’s a long road ahead, and we’ll bring more solid news of this next phase for Scrivener when things are much further along. Right now, though, Scrivener 2.6 is here and Yosemite-ready. Our iOS version is progressing, too, and we’ll be releasing updates for both the Mac and Windows versions of Scrivener next year to provide iOS sync functionality.
Just watch your eyes on those blue folders.
We’re over halfway through 2014, so I wanted to give our users a quick update on the progress of the iOS version of Scrivener. We receive emails and forum posts daily asking how it is coming along, and because of how long it seems to have been in development, we’ve even had users assume that it has been abandoned (we’ve even been accused of lying about it being developed at all, but I promise that’s not the case, even if we have continually underestimated the time involved).
The short version – the “tl;dr” version as the cool kids say – is that we still expect it to be finished this year, but now very much doubt it will be released until next year (2015) because of the amount of testing we need to put it through before letting it loose on the world. Don’t misunderstand – we are closing in on the final stages of development right now. But these final stages can still take a while, and I’d rather tell users now, in the middle of August, that we might be pushing into 2015, rather than keep my fingers crossed that we can squeeze it into 2014 and then only announce a delay at the last minute when we realise we aren’t going to make our target. Thorough testing of the iOS version is crucial, because it is designed to sync with desktop projects, and syncing can be a dangerous process – we want to ensure that any bugs that could cause data loss or corruption are truly ironed out before putting it into users’ hands.
I’m aware – if only because we’ve had it pointed out a lot! – that we have been saying “later this year”, then “next year” for two years now. Naturally, users wonder how so many delays can be possible. For a start, there’s a fairly obvious rule of software development: software development takes time (and developing good software takes a good amount of time). And then there’s the corollary to this rule: software programmers always underestimate how much time it will take (myself included).
Take the sync code, for example. Most iOS apps can take quite a simple approach to sync, using the built-in features that Apple provides for iCloud. Or they can use the Dropbox API to manage uploads and downloads. Nothing is so simple for Scrivener. One of Scrivener’s main features is that it allows you to bring in research files – photos, PDF files and so on – so that you can view them next to your text and keep everything together in a single project. In order to achieve this, Scrivener requires a file format quite different from most writing software. Scrivener, in fact, is something of a hybrid between a document-based program and a shoebox app.
Most writing software packages are document-based programs. A document-based program allows you to create, open and save documents, showing different documents in different windows. They use single, flat files that contain all the text and any graphical data for each document. These files are loaded entirely into memory when opened, and written out in their entirety as completely new files when saved.
A “shoebox app”, in contrast, usually has a single window that allows you to interact with many different files, opening them inside the one window. There will be a single folder on disk storing all of these files, but you usually won’t touch that folder at all. iTunes and iPhoto are examples of shoebox apps.
Scrivener is a bit of both. As a user, you interact with your Scrivener projects as though they were documents – each project is opened in a different window, and you have a .scriv file on disk for each project. But those .scriv files are really folders containing many different files – they are not flat files at all – and you navigate between them in the project window via the binder. This means that Scrivener doesn’t have to read these files entirely into memory on opening them, or save the whole file when saving. This is very important for projects that have a lot of research in them – you don’t want Scrivener storing a gigabyte of PDF files in memory while you are typing, or having to write all of this data to disk every time auto-save kicks in. This file format allows Scrivener to load into memory only the data that the user needs for a particular session, and it only ever needs to save what has changed (which also reduces the chances of catastrophic data loss caused by file system save errors).
The only downside to this file format is that whenever Apple introduces new technologies – Versions, iCloud, Handoff – it only provides out-of-the-box support for simple document-based apps. All of which to say: we have had to put together, from scratch, our own syncing solution so that our iOS version syncs with our desktop version. (We will use the Dropbox API, and hopefully other syncing APIs as time goes on, but all the conflict resolution handling has to be done by us.) Over the past couple of years, we’ve spent a great deal of time discussing how this could work, hashing out various ideas and solutions that could deal with the conflicts that will inevitably arise if someone works on both the iOS and desktop versions while offline so that the changes become out-of-sync. (Everything has to be considered: what happens if the user edits scene A on the mobile version but then also edits it on the desktop before there has been a chance for them to sync? What if the user’s kid opens up the app on the iPad and hammers away at their precious novel? How can we tell the difference between a scene that’s been deleted from one device and one that’s been added on another? And so on.)
Once most of this had finally been hashed out, it then took me a month to write out the design document that covers how the code will work (a design document is necessary for our Windows team to follow as well as for me and our iOS developer). And then yet another month to write the code itself, cross-platform for Mac and iOS (our Windows team will need to write this code separately). This has been what I’ve been doing for the past couple of months, and there is still work to do on getting all the sync components that have been written into place on the Mac and on iOS and then thoroughly tested (then testing on Windows).
So, that’s between three and four months on a single (but integral) feature. (And while I’ve been doing this, Tammy, our iOS developer, has been adding various “smaller” features that had to wait until late in development – printing, basic compiling, import and export, statistics, split and merge, find and replace… The sort of features that it’s easy for users to forget when suggesting that Scrivener for iOS should just be simple and only have the basics, but without which, Scrivener for iOS would feel crippled. And even some of these smaller features can take a couple of weeks each to implement, of course.)
The trouble is that it’s not only non-programmers who (understandably) don’t appreciate how long seemingly simple things can take to code – we do it ourselves. We’ll often think that a feature will only take us a day or two to complete, then find ourselves growling at the screen, desperate to have done with it, two weeks later. (This is no doubt why software and games are so notorious for being delayed throughout the industry.)
In a program as complex as Scrivener (even on iOS it requires a degree of internal complexity if it is to work with the desktop version), where various features can take a month or more to implement, the time creeps up on you and suddenly two years have passed… There are certainly programs out there that can be written in three or four months, but sadly, Scrivener isn’t one of them.
Not that “development takes time” is the whole picture. Something like Scrivener can easily take a couple of years to develop properly, but it has now been two and a half years since we started work on it; we had hoped it would be finished by now as much as anyone else – we don’t enjoy frustrating those of our users who write on mobile devices. The other big factor for us has been scaling up. Scrivener started out as a hobby – the software I wanted for my own writing. I wanted it so much that I taught myself how to code in order to create it. For the first couple of years, L&L was a one-man operation, and we are still a very small team. I work alone on the Mac version, two programmers work as a discrete unit on the Windows version, we have a couple of other full-time team members who write and maintain the manual and tutorials and handle all QC testing and some support, and we have a couple of part-time support staff. We have no central offices but are scattered across the world (the UK, US, Australia and Bulgaria). None of which is unusual for shareware, “artisan” software such as Scrivener.
The wonders of the information age make it easy for geographically-scattered teams to stay in constant touch and work together, but as a small company with such a setup, it meant that it was not possible for us just to hire some programmers and stand over them until the iOS version was finished. I was always adamant that I would not write the iOS version myself, because I’ve seen too much Mac software suffer as its developer has spent all his or her time working on iOS, and that would have been unfair to our existing user base. (Moreover, the Mac version is where I live for my own writing, and Scrivener is always going to be predominantly a desktop program.) So it was key to find someone self-motivated, with a good understanding of Scrivener, who could develop Scrivener for iOS and keep on developing it into the future, beyond version 1.0.
As I announced last year, unfortunately our first developer had to step away from the project because of family health issues, which had also stalled development progress throughout the eighteen months she had been working on it. We were very fortunate to find Tammy Coron, an experienced iOS developer and Scrivener user, to take over development. When she took over, she made the painful decision to rewrite much of the existing code, in part because of new technologies that had been introduced with iOS 7.0 (a rich text system at last!). Which means that while our iOS version has been in various stages of development since the end of 2011, the form it is in now has only been in development for just over a year.
We are really looking forward to releasing the iOS version – in many ways it’s become the proverbial albatross around our necks.* But it is getting there, and we hope the subsection of Scrivener users who are eager for an iOS version will be patient for a little while longer. We are genuinely grateful for your enthusiasm. I’m not known for great reserves of patience myself, so I do understand the frustration of some users who are more vocal in their eagerness, but to those I would say, please do try to remember that we want to get our iOS version into your hands as much as you want it. We’re a tiny company but we have put a lot of energy and resources into the iOS version (and for all we know it could be a loss-making venture), and we think Scrivener users will be happy with the final product.
I’ll post later in the year more on what sort of features to expect, but suffice to say that it has full rich text editing, a corkboard, an outliner, an inspector and, on the iPad version, the ability to view research alongside your text as you type. It is, essentially, Scrivener on iOS.
P.S. For anyone interested, I’ve uploaded a sort of developer diary for the iOS version here:
If nothing else, it should show at least that the iOS version has been in continual development, hitting snags along the way, even if progress has seemed glacial to the outside world.
[*] “Way I remember it, albatross was a ship’s good luck, ’til some idiot killed it. Yes, I’ve read a poem. Try not to faint.”