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:

1. A working binder.
2. A working corkboard.
3. An editor that allows for basic rich text editing (bold, italics, underline, footnotes of some sort and so on).
4. Access to labels, status, synopses, notes and project notes.
5. 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…

http://dribbble.com/joostvanderree/projects/42516-Scrivener-UI-concept

(In his own words: “Based on the Scrivener. It’s an app with great functionality for storytellers. UI could be improved in my opinion. This is my approach.”)

Everyone has their own opinion about this or that UI, because visual appeal is entirely subjective. So, I’m not going to dissect these mockups; they are undeniably attractive, he’s clearly a talented UI designer, and it’s flattering that someone would be interested in Scrivener enough to spend time mocking up their own UI ideas. It’s also useful for me, because I get to see a different approach and think about it. I would say that the result isn’t very much like Scrivener, in that it doesn’t convey any of Scrivener’s core concepts beyond the corkboard (and throws in elements that wouldn’t work in Scrivener at all), as the designer himself admitted on Twitter; and, in my humble not-very-designer-y opinion, it also suffers from a problem you often see when a UI is considered purely from an aesthetic perspective with less regard for what the user actually wants to do with the program, in that it allows for very little data on the screen – you wouldn’t be able to get much of an overview of your writing on an 11″ screen with that UI as it stands. These aren’t criticisms of the artist, though – he was clearly just playing with ideas for his own ideal UI, and there are certain aspects of his design that I like. Over all, it looks very pretty and modern, in an iOS kind of way.

As much as I enjoyed looking at these mockups, though, they have reminded me of one thing I dislike greatly in many recent Apple UIs – monochrome icons. I will be striving to keep monochrome icons out of Scrivener for as long as possible. This was a trend introduced in Lion, as part of Lion’s attempt to be more iOS-like. Anyone using Lion will have noticed this trend – you can see it in the Finder, Mail and Preview, among other Apple programs. As of Lion, all the toolbar icons and all of the source list icons in these programs are solid grey – all colour has been drained away.

I’m going to take a wild guess that half of the people who read this will agree with me that the new grey icons are really annoying, and the other half will think, “So what? The new minimalist look is much smarter, less gaudy, and you can still easily tell the icons by the shape.” And I’d agree with the first part: at first glance, these programs do look a little smarter, a little less fussy. Monochrome looks good. The trouble is that, sometimes, making something look more coherent and better as whole can come at the expense of the unique functionality of its components.

As Joni Mitchell sang, you don’t know what you’ve got till its gone (although in all fairness she was talking about trees rather than colours in icons, and I’d concede that trees might be a little more important). When Apple decided to drain the icons in these programs of their colour, I learned something about the way my brain works that I hadn’t hitherto ever had to think about: my brain is an awful lot faster at processing colours than it is at processing shapes. This makes sense – I’ve never been very good with faces, for instance. Whilst I don’t have full-on prosopagnosia, there have been times when I’ve been talking to someone I know only in passing, unsure of whether the person I am speaking to is Bob or Jeff – because both Bob and Jeff wear the same brown corduroy jacket, NHS glasses and brown hair (names changed to protect the Morrissey lookalikes).

It also makes sense, I suppose, that just as some people are colour-blind, some people won’t be as quick at processing shapes in particular contexts. But what this means is that, since installing Lion, I spend a lot more time poring over the sidebar in the Finder and the icons in Mail’s toolbar looking for something I could find at a glance in earlier versions of OS X. I thought I’d get used to it, but I haven’t. Even a year later, I often click on “Get Mail” instead of “New Message” in Mail. In the Finder, I have found that I no longer even look at the icons in the sidebar: because my brain can process the words more quickly than it can the colourless icons, I just read the items in the list instead. The same in Mail – but with multiple email accounts resulting in the same titles in different places, I frequently find myself in the “Sent” list when I meant to be in the “Drafts” list. Before Lion, quickly finding the sidebar folder I wanted in the Finder was easy: I subconsciously found the Downloads folder by looking for a splash of green, the Documents folder by looking for mostly white, the Applications folder for sticks of brown. I didn’t consciously look for a colour: I just looked at the sidebar and my eyes were drawn towards the icon I was looking for. I didn’t know it was the colour that guided my eyes until after the colour had been removed and I found myself having to read the titles.

Yes, this is pretty much the definition of a “first world problem”, but it’s still one we have to think about as we continue to enhance and improve Scrivener and ensure its UI remains modern. And the simple fact is that an icon has a single job: to represent a feature of the program in a simplified pictorial form that can be immediately recognised by the user. How is this achieved? The icon designer has two main tools at his or her disposal: shape and colour. And while we may disagree about what makes an attractive or ugly icon, because aesthetics are very subjective (some users hate the Scrivener application icon, others love it; Ioa hates the tone of green used in the “Add” icon in Scrivener’s toolbar, but the palette is borrowed from iWork and I rather like it), shape and colour are the only information an icon can contain, and it is from that information that we ascertain meaning. An icon succeeds if we can find it quickly when we need it, at only a glance; it fails if we have to compare it carefully to the icons around it to discern its meaning, or if we have to read its title. With only 32×32 pixels to play with for the largest icons, getting this right is difficult enough; I have thus always been baffled by the decision by Apple – renowned, rightly, for its UI expertise – to remove half of the information (i.e. colour) from many of its icons and therefore make them a lot less readable to potentially half of its user base.

I know I’m not the only one to feel this way – I’ve spoken to a couple of other people who find icons difficult to read without colour, too – but are we in the minority? I’d be interested to know if other users have similar problems with these monochrome icons, or whether it is a complete non-issue for most people. Imagine, for instance, that all of the icons in Scrivener’s binder were grey – you’d no longer be able to pick out a PDF file by its red header bar, or the Research folder by its maroon border. I’d find that difficult, and so I’ll be resisting this trend for as long as possible, if only for my own sake. And I would beg Apple and other UI designers not to kill the colour in their icons, and to spare a thought for those of us who are a little shape-blind.

To answer the most obvious question first, I’m afraid it won’t be possible to provide a direct export to iBooks Author, as the .iba format is proprietary and not in the public domain (and Apple hasn’t historically shared its file formats with third parties). At least, not to the best of my knowledge – if Apple did make it public then we’d certainly look at it.

So, for the foreseeable future, that leaves other formats for import and export. When I heard the rumours about an e-book creator being announced at today’s Apple event, I had high hopes that it would open and save .epub files. Unfortunately, despite iBooks Author having WYSIWYG editing and generating files that seem to be at least based on .epub, this isn’t the case. iBooks Author saves to the proprietary .iba format and publishes to the .ibooks format (which seems to be Apple’s version of .epub, much as .rtfd is Apple’s extended version of .rtf; iBooks Author cannot open or import .ibooks files, however). This is perhaps unsurprising, as Apple are obviously only interested in generating content for iBooks (iBooks Author – hmm, the clue might be in the name). What this means for Scrivener users, though, is that you can’t just export an .epub from Scrivener and open that up in iBooks Author.

Currently, the only way of bringing existing text into iBooks Author is by importing Word .doc and .docx files, or Pages .pages files (the latter being another of Apple’s proprietary formats). Moreover, each file you import is treated as a chapter or section – there is at the moment no way in iBooks Author of importing a large text file and splitting it up into chapters after it’s been imported, other than by using copy and paste. (In these regards, iBooks Author feels very much like a 1.0 release – given that it is clearly designed for laying out and producing beautiful e-books, not for creating the content in the first place, we can hope that the import features will improve in future versions.)

For Scrivener users, this means that the best way of getting your work into iBooks Author is to compile to the .docx format, and then drag the resulting file into iBooks Author. You’ll then have to copy and paste the text into different chapters in iBA itself. You could compile each chapter to a separate file, but that would be time consuming.

Scrivener for Mac’s .docx export isn’t, in truth, the best at the moment, as it tends to lose certain formatting and doesn’t support images, which may be a problem for some types of text but shouldn’t cause problems for novels and text-only first drafts (this is because it currently uses the standard OS X exporters, the same ones that are used in TextEdit – Apple uses its own proprietary .docx importers and exporters in its own programs, not the ones provided to third-party developers in the Cocoa frameworks). The good news is that I am currently working on better .doc, .docx and .odt support, so this situation should be improved in the next update. We’re also thinking about what better ways we can provide of going from Scrivener to iBooks Author – for instance, by generating different .docx files for each chapter – given that I’m sure that many users are going to want to do this after they’ve hammered out their text in Scrivener.

Please bear in mind that I have only had as long as anyone else to play with iBooks Author, so the above is all just based on a couple of hours of testing. Over all, iBooks Author looks very nice, and once we find the best workflow for getting your Scrivener text into it, then I’m sure it will be a great way of taking your Scrivener drafts and turning them into beautiful e-books on iBooks.

I’ve said all along that I wouldn’t develop an iOS version myself, any more than I would have tried to code the Windows version myself – with such a small team, I think it’s in the customers’ interests to have a dedicated developer for each platform to ensure that each version is always kept up-to-date, and my hands are full with the Mac version. To that end, I’m very pleased to announce that we have just signed contracts with a developer, Jen Yates, to develop the iOS versions for us. Jen has been beavering away in secret for two or three months now, putting together some proof-of-concepts:

I have to say that moving index cards around on a touch screen is a lot of fun, and the corkboard implementation she has come up with is, I think, one of the nicest I’ve seen on a touch screen device in terms of selection and dragging.

It’s still early days, though – we are about to embark on the design process proper, and all we can say in terms of a release date is that our iPad and iPhone versions will be out some time in 2012. If you would like to share your own ideas about what you see as essential in an iPad or iPhone version, please feel free to drop by our special sub-forum for iOS suggestions here:

http://www.literatureandlatte.com/forum/viewforum.php?f=36

Thanks to everyone who has contacted us to show their enthusiasm for an iOS version of some kind – we hope you’ll like what we come up with – and welcome to Team L&L, Jen!

EDIT 17/12/11: Thanks for all the enthusiastic responses to this post, much appreciated. To those asking about an Android version, this is on our radar too, don’t worry. We have to take it one step at a time, though. Our design process for iOS will take Android into consideration (although our iOS version will be Cocoa and native), and we hope to investigate Android in more detail later in 2012.

http://www.literatureandlatte.com/scrivener.php?platform=win

Scrivener for Windows costs a mere $40 ($35 for students and educators) – slightly less than the Mac version simply because it still has a little catching up to do, given that the Mac version has been in development for five years longer. That said, Scrivener 1.0 for Windows has shipped with far more of the Mac 2.0 features than we had initially planned (including epub and Kindle mobi support), and Lee (the Windows developer) has done an amazing job on it. If you’ve used Scrivener for Mac, you’ll feel right at home in Scrivener for Windows; if you haven’t, then rest assured that Scrivener for Windows has been built from the ground up as a native Windows program (i.e. it is not a dodgy port!).

Thanks to everyone who has shown such enthusiasm for a Windows version, and to all our beta-testers who have helped improve Scrivener for Windows no end over the past year. 1.0 is just the beginning, of course – there are lots of free 1.x updates in the works. Anyway, we hope you like Scrivener for Windows and that you find it useful with your own writing endeavours, as we do in ours.

(And by the way, bestselling author David Hewson has updated his ebook, “Writing a Novel with Scrivener”, to cover the Windows version too – details available here.)

“I love deadlines. I like the whooshing sound they make as they fly by.”

Well, we’re hearing a bit of a whooshing sound ourselves today. We have been telling people that today, 31st October, would be the official release date of Scrivener for Windows, but – at the last minute – we have made the painful decision to postpone for just one more week, moving the release date back to 7th November. However, as a thank-you to beta-testers, and to make up for this slight delay, we are today making Scrivener for Windows available as a pre-order, with a 10% discount which will be available until the full release on 7th November. So, for the next week, you can buy a licence for $36 instead of $40 (or $31.50 instead of $35 if you are buying the educational licence). Any other discounts floating around (cough NaNoWriMo cough) can be applied on top of the 10% discount for the regular licence, too.

The Scrivener for Windows pre-order page is now up here:

http://www.literatureandlatte.com/scrivener.php?platform=win

Thus, you can buy today at a slight discount and enter your serial number next week when Scrivener 1.0 for Windows is released (you will receive your serial number immediately after pre-ordering). Or, if you don’t like pre-orders, you can wait the extra week. And for those beta-testers worried about the expiry date of the current beta, remember that we have a special trial version available for NaNoWriMo that lasts all the way up to 7th December:

http://www.literatureandlatte.com/nanowrimo.php

So, why the delay? Lee, the Windows developer, has been working around the clock to meet this deadline, which we decided on a couple of months ago based on the state of the Windows version at that time. He has been killing himself trying to fix the bugs reported by our excellent beta-testers, and in his attempts to meet the exacting standards we set for ourselves. But as of last night, there were still a few issues that we felt needed addressing before we could truly call this a 1.0 release; things we weren’t comfortable leaving for a 1.0.1 update. We know that pushing the release date back – again – risks annoying some potential users who have been eagerly waiting for the release (which we appreciate, and we hope the discounted pre-order helps), but we’d rather get shouted at for being late than for releasing software with minor glitches we could have ironed out had we taken a few extra days.

Scrivener 1.0 for Windows is nearly ready, then – but that “0″ signifies only that we’re at the end of the beginning; it’s just the proverbial line in the sand. 1.0 will – we hope! – be awesome, but following 1.0, there will be a 1.0.1, a 1.0.2, a 1.0.3 and so on, as we continue to address any minor issues left over, and then a 1.1 and a 1.2 and onwards as we continue to refine Scrivener for Windows and make it into the best program for writers – and for ourselves – that we can.

Please let me take this opportunity to thank each and every one of our beta-testers, everyone who has blogged about Scrivener for Windows, and all those who have been eagerly awaiting its release. We hope you’ll enjoy using Scrivener on both platforms – hopefully see you back here next week. Thanks!

Fortunately, however, some great new learning materials for Scrivener are now available from third parties. Two e-books have just been released covering different aspects of the program, one a fantastic introduction to all of Scrivener’s main features written by a senior contributor to Macworld magazine, and another written by a bestselling author explaining exactly how he uses Scrivener for his own novels. There is also an upcoming online course dedicated to using Scrivener run by Outreach International Romance Writers (a branch of Romance Writers of America – although you don’t need to be a romance writer to take part in the course).

Take Control of Scrivener 2 from TidBITS Publishing

We’ve worked with TidBITS Publishing, creators of the popular “Take Control” series of e-books covering many Mac applications, to sponsor Take Control of Scrivener 2. Using Melville’s Moby Dick as his exemplar, author and senior Macworld contributor Kirk McElhearn walks you through using Scrivener to create and manage a writing project. Kirk takes readers through using Scrivener’s binder, outliner and corkboard to develop characters and settings, collecting and organising research materials, and arranging scenes.

The book covers how to keep yourself on track by composing in Scrivener’s Full Screen mode and by setting daily progress targets, building up to producing a manuscript ready for submission or self-publishing. It also contains quotes from published authors on how they use Scrivener, including David Hewson, James Fallows, Jason Snell, Jeff Abbott, and Michael Marshall Smith.

Although it uses Moby Dick as an example, Take Control of Scrivener 2 is not aimed only at fiction writers but is a general guide to using Scrivener. If you’ve been through the tutorial but want a more hands-on guide written by someone with a bit more distance from Scrivener, and who has years of experience explaining software to a general readership, you may want to give Kirk’s e-book a whirl. A sample of the contents can be found here:

Read sample pages.

Take Control of Scrivener 2 comes in both PDF and ePub formats (you get both), so you can view it on your iPad, and costs $10. You can buy it from the tidbits.com site or directly from our store here:

Buy Take Control of Scrivener 2.

Writing a Novel with Scrivener by David Hewson

David Hewson, the bestselling author of the Nic Costa series of crime novels, has long been providing readers of his blog with insights into how he uses Scrivener. Following popular demand, he has now written a full e-book on this very subject.

Writing a Novel with Scrivener assumes some knowledge of Scrivener (making it a great companion to the Take Control book or to our own Help materials). In it, David explains all the features of Scrivener he finds useful for writing his own novels, including how he uses keywords and collections to keep track of individual character storylines, keeps an “Unplaced Scenes” folder for writing ideas out of sequence, uses the “Append Selection to Document” feature for quickly assigning character descriptions to a character document, and much more.

As David explains from the outset, Writing a Novel with Scrivener isn’t intended as an explanation of every feature, but rather how one working, bestselling novelist makes use of the features he needs for his own workflow and hides the ones he doesn’t – and along the way he exhorts users to find what works best for them, too.

Writing a Novel with Scrivener is available from Amazon and requires a Kindle or Kindle software (so you can read it on a Kindle or on Kindle for the Mac, iPad or iPhone). The entire book was written using Scrivener 2.0 and created using Scrivener’s .mobi exporter. For further details, including links to the Amazon pages for the countries in which it is available, please see the announcement on David Hewson’s own site here:

http://www.davidhewson.com/writing-a-novel-with-scrivener/

Online Workshop from OIRW (Outreach International Romance Writers)

For those of you after a little more personal tutoring in the ways of Scrivener, Gwen Hernandez is currently running online workshops covering all the main aspects of using Scrivener through OIRW (a chapter of Romance Writers of America, although you do not need to be a romance writer or a member to participate). Gwen has written numerous incisive tutorials on various aspects of Scrivener over the past few years, which can be found on her site:

http://www.gwenhernandez.com

Her online course is entitled “More than Word: Getting the most from Scrivener for Mac”, and is aimed at beginning and intermediate users of Scrivener. Topics include using the binder, splitting and merging files, snapshots, split screen, collections, keywords, working with labels, templates, full screen mode and more.

The first course is running right now and is already fully subscribed, and we’re hearing a lot of fantastic feedback from the people taking it. The next one will be taking place in August and will be announced on the OIRW site soon, so if you’re interested I recommend keeping an eye on the OIRW site or on Gwen’s own site (click on “Scrivener” at http://www.gwenhernandez.com ) or Twitter feed.

We’re over the moon that Kirk and David have decided to make Scrivener the focus of their most recent books, and that Gwen has made it the focus of her online seminar, and I hope that their work proves useful to Scrivener users out there who are looking for practical guides beyond our own help materials.

You can find us under the productivity section, here:

http://itunes.apple.com/us/app/scrivener/id418889511?mt=12

Just to remind everyone, though, that we are not going MAS-exclusive, so if you don’t mind installing things the regular way (and want us to get more of the proceeds ) you can still buy Scrivener from us directly via the product page:

http://www.literatureandlatte.com/scrivener.php

Of course, if you prefer the Mac App Store, that’s now an option, and we’ll be delighted to welcome new users however they choose to purchase.

UPDATE 31/03/11: I’ve put together an FAQ that should cover most questions users have about Scrivener and the Mac App Store here:

http://www.literatureandlatte.com/wiki/doku.php?id=mac_app_store

Please let me know if there are any questions you think I’ve missed.

So, those questions answered in full:

Will You Be Putting Scrivener on the Mac App Store?

Hopefully, yes; that’s certainly our plan. Who wouldn’t want to be in a store that sits on every Mac? (Or at least every Mac running 10.6.6 and onwards…)

When?

I’m hoping to submit Scrivener to the Mac App Store once 2.0.3 is finished. There are still some bugs lurking and my first priority is to ensure existing customers are happy. I’m hoping to have 2.0.3 ready by the end of this month, or early February (but don’t quote me on that; I have a Douglas Adams approach to deadlines). Of course, once I submit Scrivener to the App Store, there is still no telling how long it will take to get on there. I’m hearing about lots of apps that have been sitting in review since November and aren’t on there yet, and there’s no way of knowing in advance whether Scrivener will even be accepted first time or not – to a certain extent it depends on how they are approaching the review process. Things like the block cursor and certain HUD controls in Scrivener might not be allowed – I may yet have to strip certain features out for the App Store version just to get it on there. We’ll see.

Will You Still Be Selling Via Your Site?

Absolutely. We most certainly will not be moving exclusively to the App Store. Anyone who owns Scrivener 1.x should upgrade directly via us, too, because the App Store doesn’t allow upgrade pricing, and even if it did there would be no way of validating the update because Apple maintain complete control over the App Store customer database. There’s also no way of offering trial versions via the App Store, so if you want to try out Scrivener it will always be best to come here first. Even if we eventually get more sales via the App Store, our plan is that our site and our own (eSellerate-run) web store will remain our own central hub for selling both the Mac and Windows versions of Scrivener. The Mac App Store will just be another option for our customers.

Will the App Store Version Be Cheaper?

No. Or, if so, not by much. I’ll be choosing whichever price tier is closest to $45. As Ken Case of the Omni Group said recently, the App Store doesn’t change the value of our software, so it won’t affect the price. A lot of people talk about a “race to the bottom” in terms of price, but that’s not a race we want to win! There’s no way of knowing right now whether all quality apps will thrive on the App Store or whether it will be a place people go predominantly to look for cheap apps for quick entertainment. We already sell Scrivener at a very reasonable price that students and struggling writers can afford. And although there’s a chance that dropping the price in the App Store could lead to enough of a volume increase to more than make up for the price drop, it’s not all about the money. It’s partly about the money, of course – or we wouldn’t be bothering with the App Store at all. We need to eat, after all. But I like the fact that our customers have generally come to Scrivener out of a need for software like it; I don’t necessarily want to encourage impulse purchases in the App Store by dropping the price significantly and then find that we have unhappy customers who bought based on a single screenshot or a two-line review. Instead, what I hope is that the Mac App Store either brings Scrivener to more potential users’ attention, who then research it in more detail to see if it is the tool for them, or that it makes Scrivener easier to find by people who have heard about Scrivener and automatically look for it on the App Store. So, we’re approaching the App Store as a nice way of getting “out there” to more potential users who haven’t heard of Scrivener, but who would have bought it had they known about it; we won’t be trying to draw in people who don’t think Scrivener is worth $45.

That was a very long-winded way of saying, no, the price will stay the same, wasn’t it?

What’s All This About Piracy and Receipt Validation?

Okay, we’re not getting any questions about this at all, I just wanted to mention it anyway.

I spent a couple of days last week getting Scrivener 2.0.3 App Store-ready so that I can just click the “Submit” button in Xcode’s Organizer when 2.0.3 is finished. I still have the receipt validation code to deal with, though. There was a minor furore last week when it transpired that within the first day of the App Store trading, the popular game Angry Birds had been hacked and pirated. This caused the usual to-and-fro’ing: on one side, there were accusations that Apple had been careless and had exposed developers using the App Store to piracy; on the other, there were rebuttals that Apple had made it very clear that developers should use a process called “receipt validation” to avoid piracy, and that it was entirely the fault of developers for not implementing this properly if their programs got hacked. I think the reality is somewhere in between, but I’m surprised that I can’t find more discussion from developers about this – perhaps it’s my lack of a computer science degree showing.

It is true that in their Mac App Store guidelines, Apple tell developers to use “receipt validation”, and they link to a document explaining it. The document (which although part of the password-protected developer site has been pasted all over the internet, so I’m not leaking anything that isn’t publicly available here), begins thus:

“Receipt validation requires an understanding of cryptography and a variety of secure coding techniques. It’s important that you employ a solution that is unique to your application.”

And herein lies the rub. While the Mac App Store seems a wonderful way for indie developers to get their products “out there”, I doubt there are many indie developers with cryptography experts on their team. If you’re not a coder, it’s understandable that you might think all developers probably have a good understanding of this stuff, and that therefore the Apple document gives developers everything they need to protect their software. But no single developer can be an expert in every aspect of computer science or code. (Bear in mind that I’m a self-taught coder, but on the other hand I bet so are a lot of developers trying to get into the App Store; that’s part of the beauty of Cocoa.) Half of Apple’s receipt validation document may as well be written in ancient Hebrew for all the sense it makes to me: “The outermost portion is a PKCS #7 container, as defined by RFC 2315, with its payload encoded using ASN.1 (Abstract Syntax Notation One), as defined by ITU-T X.690…” Are these droid names? So, I’m not entirely surprised that other developers have had issues here too (and for the record, it seems that Angry Birds did follow some of those instructions, but unfortunately Apple give some shaky advice in their document that does leave programs open to hacking, as pointed out here with a solution: http://www.craftymind.com/2011/01/06/mac-app-store-hacked-how-developers-can-better-protect-themselves/ )

Fortunately, there seem to be a couple of good receipt validation examples and source code snippets on the internet that I am hoping will steer me right. (If you come across any sites featuring great, clear tutorials on the subject, though, please do feel free to steer me towards them.) The fact remains, however, that the whole point of indie software such as Scrivener using third-party serial-number schemes such as that of eSellerate (which we use), is that they are the cryptography experts so we don’t need to be; we can leave them to worry about serial number validation, encryption and so on while we get on with adding features and fixing bugs. We hand over 8 or 9% or however much and in return get a serial number and activation scheme, a web store handled by eSellerate, and full control over our customer database. Apple, meanwhile, take 30%, do not give developers any access to their own customer databases, and place the burden of a copy-protection scheme squarely on the developer. There’s no way you would choose Apple’s scheme over eSellerate, Kagi or any of the others were it not for the fact that they offer you a place on a store that resides on every Mac desktop. So, I can live with the 30% in return for being placed in a store known of by every potential user, but I am a little disappointed that Apple insist on applications in the Mac App Store not using application-specific protection schemes when they haven’t put in place a mandatory anti-piracy scheme that doesn’t require the developer to have a firm understanding of cryptography.

Hopefully these are just teething troubles, though, and that over the coming months we will see Apple introduce trial modes, upgrade pricing and easier copy-protection schemes. And hopefully, too, I’ll be able to figure out the sample source code out there and get my head around receipt validation…

(I’d be interested to hear from other developers – whether you are using Roddi’s source code from GitHub, whether you had no problems with Apple’s docs and therefore think it’s just me, etc.)

Oh, and I nearly forgot:

Happy New Year!

You can get an overview of some of the new features here:

http://www.literatureandlatte.com/scrivener.php?show=new

I hope you like it.

Just a reminder that this is a paid update (the first in nearly four years). The regular licence is now $45, or $38.25 for the educational licence. If you’re upgrading from any version of Scrivener 1.x, the update is only $25 (the update price is the same for both licences – sorry, we can’t afford to go lower than $25). If you bought Scrivener 1.x on or after 1st August 2010, the update is free. To update from 1.x, please use this page:

http://store.eSellerate.net/s.asp?s=STR4913460776&Cmd=BUY&SKURefnum=SKU81634174866

(Note that you will need to enter the e-mail you used to buy Scrivener 1.x – e-mail David at sales AT literatureandlatte DOT com if you have changed your e-mail address since.)

Tomorrow I’ll be starting work on 2.0.1 – for now, a glass of champagne, I think. A ginormous thank you, though, to David, who is fielding a zillion e-mails right now and who has worked his backside off on all the videos, to Julia for helping me write the website copy and proof-reading everything, manual and all, and last but far from least, Ioa, who not only wrote the new manual but who also completely redesigned the website.

Thank you also to every user who has been so eager to update, and who has been shouting about us on Twitter and elsewhere; well, to everyone who uses Scrivener really – so, yeah, thank you!

Keith