Given that we’re receiving emails, tweets and forum postings daily asking when the iPad and iPhone versions of Scrivener will be released, I thought it only polite to give everyone a quick update on where things stand. (For those of you who prefer brevity, the content of this post can be summarised thus: Not for a good while yet, sorry!)
First, let me say that we all really appreciate the enthusiasm that so many users are showing for an iOS version. And thank you, also, to everyone who has taken the time to share their thoughts in our “Scrivener for iPad/iPhone – What Do You Want?” forums.
Not being renowned as the most patient person in the world myself, I can certainly understand everyone’s impatience to get the iOS version in their hands. The problem – which I hope will come as no surprise – is that good software takes time. There’s just no way of getting around that, unfortunately; not without bending the laws of physics, at least (although if anyone has a Primer-style box, let me know). Just because iOS is very much a stripped-down operating system compared to OS X and cannot do nearly as much, it does not mean that it is easier or faster to come up with a good design, write good code and test everything thoroughly. (We’ve had some suggest that we throw money at it, get outside investment and suchlike, but it’s not a money issue at all: if we’re going to do it right, then it deserves thought, care, attention and nurturing rather than just hacking something together that we think will meet basic requirements and sell. Part of our ethos is that the people working on the software are also users, and passionate about it – we develop software that we want to use ourselves. We’re just not interested in making software we don’t love. If some users decide to go elsewhere because our crazy ideals – that’s no way to run a business! – drive them mad and they just can’t wait, we understand that, appreciate it, but such factors cannot have any influence on our design and development process, and we hope we’ll win them back with an end product that is worth waiting for.)
To put this in perspective, let me give you some idea of the gestation of Scrivener on the Mac. I first had the idea around 2001, but I didn’t start development on it until 2004, beginning with a design document and odds and ends of code, and this design and proof-of-concept stage took about six months or more before serious development could begin. The first version that was stable and complete enough to be tested by real users appeared at the end of 2005. It was then rewritten and redesigned and didn’t go on sale until the start of 2007 – and Scrivener 1.0 was a long way from what Scrivener is today (on both platforms), because development has continued constantly for the past five years.
Now, with the iOS version, in many ways we’re right back at the beginning again. Not entirely, of course – because OS X and iOS share many fundamental libraries, we are able to reuse some small parts of the existing code base, although none of the interface code is portable. We have had to look at the touch interface and ask ourselves: how can we bring the core features of Scrivener to a completely different interface? What will it look like, and how will you interact with it? In so doing, we’ve been going back to the reasons I built Scrivener in the first place – because to be Scrivener, it has to achieve the fundamentals of what Scrivener set out to do, but it has to do it in a way that makes sense for an entirely different interface. And then we have – or, rather, Jen has – had to start building the necessary interface components, one by one, step by step.
To explain: Cocoa software – which covers OS X and iOS – follows what is known as the model-view-controller paradigm. What this means is that, unlike those old BASIC programs we used to type in at school, you don’t just write one long list of computer instructions. Instead, it’s more like manufacturing a car: you make the wheels, which in turn will involve moulding the tyres, forging the hubcaps and so on and putting them together; you build the engine entirely separately, breaking that down into all its constituent components first too; there is the shell, the chassis, the steering wheel, the seats – all will be made independently and eventually put together. Hopefully some of the components can be sourced pre-built by someone else, but ultimately, you are going to have to build a lot of them yourself before you can combine all of those parts into anything remotely resembling an automobile. The model-view-controller paradigm is much the same. You build all the parts of the program separately (technically, this is what is known as “object-oriented programming”) and then you stitch them together. So, you build the views (the corkboard, the binder, the editor and so on, but also using views that are provided by Apple where possible, or customising them), and you build the models (the data – some code representing a single binder item, for instance, and dealing with writing it to XML, or some code representing a collection, or a keyword), and then you stitch it all together (the “controller” layer is code that does the stitching, basically).
Whenever I add something new to Scrivener, then, I go off, design it, code it in a test app, test it out, and then incorporate it into Scrivener only when it’s ready. By the time a new component makes its way into Scrivener, it is already fully-formed and stable (or at least, that is the idea). Likewise, with the iOS app, it doesn’t start life as a single program that will then evolve – that comes later. It starts life as lots of small demo apps that test out all the different views that have to be built, or test out data manipulation. None of these apps do anything meaningful in themselves except allow us to build and test individual components – by the time these individual components become part of the whole, the idea is that most of their bugs are squashed (ha). There will be any number of these test programs along the way. Most recently, for instance, because iOS doesn’t have a view that works like the binder, we have had to figure out how something like that would work best on a touch interface and build it; likewise, there is no corkboard on iOS unless you build it yourself; and so on.
So, this is where we are. Since December, we have spent a lot of time hashing out a design for the iPhone and iPad. And we’ve come up with something that we’re all excited about – something that brings across the core features of Scrivener but without trying to reproduce the desktop version on a touch interface. At the same time, Jen has been working furiously on various key components (such as the corkboard and binder), and putting together code that can read a .scriv project. We’re still a good way from combining all of that into an early working version, though, and perhaps the largest hurdle – getting syncing *right* – is still ahead of us.
Still, here are the basics that we are hoping to bring to the iOS version:
- A working binder.
- A working corkboard.
- An editor that allows for basic rich text editing (bold, italics, underline, footnotes of some sort and so on).
- Access to labels, status, synopses, notes and project notes.
- Seamless syncing without the necessity of closing the project on your Mac or Windows machine.
We know that we won’t please everyone – it’s impossible to bring the full desktop version to iOS, and everyone uses Scrivener differently – but these are the basics that most users have been keen to know will be in there. Beyond that, we cannot say anything more at this stage – sorry!
I said from the start that we wouldn’t be able to give a release date for a long time, and that still stands, I’m afraid. All we can say is that we are *hoping* to get it finished before the end of 2012 – but with no promises, given the amount that is left to do. It will be released when it is ready, and that certainly won’t be tomorrow or next week or even next month. We know you want something good, and that is what we are hoping to deliver – trust us, we’re not slacking off, but are working hard to bring Scrivener to iOS in as much of its glory as possible. (I hear occasional rumblings that we “should” have started all of this a couple of years ago, and while I can understand such frustration, especially from users who know little about how small shareware companies such as ours really are, trust us, we couldn’t, in good conscience, have started it any earlier. Remember we are a tiny company, selling what is really quite a niche product, and growing only at a glacial rate. Two years ago I would have had to step away from the Mac version to develop this, and leave our Mac version to rot for a while. Sadly, I’ve seen this happen to a number of other programs. I love my Mac, though, and Scrivener on it, and could never have done this. Now we have Jen, who is doing an amazing job, and we are in a much better position to deliver what our users want.)
Finally, a note on beta-testing. We’ve had lots of people – hundreds! – say they would love to beta-test. Thanks for everyone’s enthusiasm. At the moment, though, for various reasons, our beta-testing list is invite-only. There’s nothing cliquey or secretive about it – I simply look out for existing users on the forums or on Facebook or wherever, who seem to know their way around Scrivener and who are also good at reporting bugs or problems. Beta-testers have to be prepared to lose work, put up with persistent crashes and suchlike, so, at least for the first phase of testing, it’s always best to have a group of people who aren’t going to shout at you when things go wrong. Besides, we’re a loooong way from beta-testing yet – we’re not even at the alpha-testing phase. So if you really want to be a beta-tester, the best thing to do is to be active and helpful on the user forums, and then in three or four months drop me a line and say, “Hey, look, I’m such-and-such on the forums, you know me, I’m a great guy/gal, you just know you want to make me a beta-tester.”
Right, back to my iPad – Jen delivered an exciting component for testing today…