As many of you know, development started on Scrivener for iPad and iPhone early in 2012, and we had hoped that we would have it ready for the end of that year; we later revised that estimate to the first quarter of 2013. And, as many of you have pointed out to us, here we are in April – so where is it?

I’ll provide the information you are most likely after first: it will still be a little while–certainly much longer than we had hoped. We can give no firm release date yet, and given that past estimates have been wildly off, I’m not even going to make a guess at this stage. We very much hope it will be out this year, in time for National Novel Writing Month, but we’re not going to make any promises at all until we know for absolutely sure that we can keep them.

The frustrating part for us is that, for the past four or five months, we have had a version of Scrivener for iPad that is in many ways so nearly there and yet still not ready for beta-testing. We hit snags with the rich text system (or iOS’s lack of one) and building the synchronisation code is incredibly complicated because of Scrivener’s package-based file format, but we had most of the other basics in place and felt we were really making good progress.

Unfortunately, however, owing to unforeseen and serious health problems in our iOS developer’s immediate family, over the past few months our original developer has been unable to spend the time on the project that is required to get past the final roadblocks and finish it. It’s been a difficult time for everyone as we tried to work out the best way to proceed, all the while hoping things would get back to normal even as time slipped by, especially since she has done such an amazing job so far (the iOS versions of the binder and corkboard are a joy to work with). It gradually became clear, sadly, that our iOS developer had no choice but to officially reduce the time she could dedicate to the project so that she could concentrate on her family, and that we would need to find someone else to step in. But because we’re a small company with limited resources and no headquarters or offices, it’s not as though we could just throw money at the problem by hiring a bunch of developers and supervising them until it is done; we’re not Microsoft, Apple, or even Omni. We needed to find another iOS developer not just passionate about coding, but passionate about creating an iOS version of Scrivener in particular.

It is with great pleasure and some degree of relief, then, that I can now announce that we have found a new developer to focus on getting Scrivener for iOS completed. (The original developer will continue to work on it too, as much as her current circumstances allow.) The new developer is Tammy Coron, an experienced iOS coder who is also involved with Nickelfish and developed the iMore app. She’s a dedicated Scrivener user and, like many of our users, is desperate to have the iOS version for herself. (It’s not just our users eager for this–I want to be using the iPhone version as soon as possible too.) There’s an interview with Tammy available online for anyone interested here:

http://www.imore.com/debug-10-tammy-coron-nickelfish

Tammy can also be found on Twitter @Paradox927 (which is the same user name she uses on our own forums).

Tammy has been getting up to speed with the project for the past fortnight and has now started diving into the code proper. We hope to provide more news over the coming months, but we’re all excited to have her on board and to once again be forging ahead with getting our iOS app completed.

To those desperate to have an iOS version as soon as possible, we are very sorry for the delay, but remember that in the meantime Scrivener for Mac already has some great ways of working with mobile devices (e.g. via external folder sync). We know we’ll get a bunch of angry emails and tweets over this, but I hope that most of our users continue to find Scrivener one of the best desktop writing packages around, and that the iOS version will be worth the wait when it is eventually in everyone’s hands. We also hope that everyone will understand why we haven’t wanted to say too much about what has been holding up development until we really had to and had already got a solution in place.

– ORIGINAL POST –

Scrivener has been temporarily removed from sale on the Mac App Store. We are very sorry for any inconvenience this will cause to our Mac App Store users, but unfortunately we have been left with little choice other than to take this measure. I’d like to stress that this is only a temporary measure and we hope that Scrivener will be available on the Mac App Store again within the next few days. (Note: As I write this, you may still see Scrivener available – we’ve pulled it, but it will take up to 24 hours before it disappears from all stores.)

The reason we have taken this action is that the current version available in the Mac App Store, Scrivener 2.4, will not install or run on OS X 10.6 and Apple will not allow us to release a bug-fix for this problem in a timely manner. This 10.6 problem is due to a bug in the receipt validation code that crept into this release – please see a full explanation in my blog post of two days ago:

http://www.literatureandlatte.com/blog/?p=340

2.4 was released on the App Store last Thursday night, after a week in the review queue. On Friday morning, as soon as I found out about the bug in 10.6′s receipt validation code, I submitted a bug fix, Scrivener 2.4.1, to Apple, and I asked for an expedited review. With this all in place, we had hoped that Scrivener 2.4.1 would be available to our Mac App Store users by Tuesday at the very latest, so that our 10.6 MAS users were not inconvenienced for more than a few days at the most. (There is no way to upload an immediate bug-fix to the Mac App Store – every update has to go through the review process, and even when an expedited review is granted, it can still take a while.)

Unfortunately, this has not been the case. It is nearly a week now since 2.4 became available, and we still do not know when 2.4.1 will pass review and be made available on the store. 2.4.1 was rejected on Monday night for a reason that didn’t make sense (the reviewer said it wasn’t sandboxed when it was). We followed this up and resubmitted, but were then told that the reviewers needed more time. Yesterday, I was informed that they want us to make some changes to Scrivener 2.4.1 before it can pass review. I was also informed that Scrivener 2.4, 2.3.1 and 2.3 should really have not passed review either, given the things they want us to change. (Please note that the things we have been asked to change are not bugs, but features Apple interpret as not meeting their App Store review requirements.) I asked if we could roll back to making an earlier version of Scrivener available on the store while we address these issues, but the only way to do that, apparently, is to resubmit the older version, but because the older versions have the same “issues”, then doing so wouldn’t help as the reviewers would reject the older version that had previously passed review anyway. In other words, we currently have no way to get a bug-fix to our 10.6 MAS users other than to keep going back and forth with Apple until they pass 2.4.1 for release. Nor is there any way to prevent 2.4 from being available to 10.6 users.

We can therefore not in good conscience continue to sell Scrivener on the Mac App Store knowing that any 10.6 users who buy it will not be able to use it.

As soon as 2.4.1, which fixes the problem, passes review, we will immediately make Scrivener available on the Mac App Store again. We very much hope that this will be in the next few days.

Again, I’d like to say sorry to any of our Mac App Store users that this will inconvenience. We will not leave you without a working version of Scrivener, though. If you are a Mac App Store user and this temporary removal of Scrivener from the store leaves you without a working version of Scrivener, please contact us. If you are on OS X 10.6 and bought Scrivener in the past week so that it will not run on your system, again, please contact us – we will get you up and running. Email us at mac.support@literatureandlatte.com with these issues. Thank you for patience and understanding in this matter.

(Incidentally, because of some of the changes we are being required to make, we cannot guarantee that Scrivener on the Mac App Store will have as good support for .docx, .doc and .odt formats in 2.4.1 and future releases. This does not affect the version on our site.)

– ORIGINAL POST –

If you’re one of our Mac App Store users running OS X 10.6, you are probably wondering what on Earth has happened with the Scrivener 2.4 update. What you’ll find is, if you download Scrivener 2.4 from the Mac App Store, on OS X 10.6 you will be told that Scrivener is damaged and cannot be run. (Please note that this problem does not affect 10.7 or 10.8 users – Scrivener installs and runs fine on 10.7 and above. Nor does it affect the version available from our website.) I wanted to take a moment to (1) apologise profusely to our 10.6 App Store users, (2) provide a solution and (3) explain what has happened.

1. An Apology

I am genuinely sorry that any of our users should be facing this issue at all. Please rest assured that we have done everything in our power to ensure that this is addressed as soon as possible (please see below), and also know that we will never leave any of our users without a working version of Scrivener – you can get up and running again right now.

2. The Solution

To get up and running, please just download, install and run Scrivener from our own website:

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

Before doing so, you will need to move Scrivener from your /Applications folder to the Trash, upon which you may be prompted to enter your computer’s admin user-name and password. Please note that trashing Scrivener does not affect your work. Your work is saved separately, so this is entirely safe to do.

As long as you have run a version of Scrivener from the Mac App Store at least once on your machine, the version on our site should recognise you as a registered user. If you haven’t, or if it doesn’t for any reason, you will find yourself in trial mode when you run this version of Scrivener. This should still give you more than enough time before the fixed version of Scrivener, Scrivener 2.4.1, appears on the Mac App Store, as that should be available within the next couple of days (see below). If the trial has expired because you have used it before, please contact us on mac.support@literatureandlatte.com.

There is more information on installing the version from our site if you are a Mac App Store user on our Knowledge Base here:

https://scrivener.tenderapp.com/help/kb/purchasing-and-installation/installing-the-direct-sale-version-as-a-mac-app-store-customer

Please note, however, that the information there is more geared towards users who want to switch to the direct-sale version indefinitely. For users who just want to use it temporarily until the fix is available on the App Store, you can probably ignore most of the information there.

When Scrivener 2.4.1 does become available on the Mac App Store, just delete the direct-sale version from your /Applications folder by moving it to the Trash and emptying the Trash, then click on the “INSTALL” button that appears next to Scrivener in the “Purchases” tab of the Mac App Store.

If you have any problems getting up and running or switching between versions, please do not hesitate to contact us at mac.support@literatureandlatte.com. I stress that we will absolutely ensure that paying customers are not left without a running version of Scrivener.

3. So What Happened?

How did our 10.6 Mac App Store users end up in this mess? Well, it is down to a very stupid coding error on my part – literally one missing letter in the code – which has been compounded by the way the Mac App Store works, which has meant that we have been unable to get a fix immediately out to our users as we would be able to do with our direct-sale version.

In case you’re interested, the stupid coding mistake was in the receipt validation code (the code that checks you have a valid Mac App Store receipt, as recommended by Apple). Apple introduced a function in 10.7 and above that tells apps where to find the receipt file on users’ systems; prior to that the path had to be hard-coded.  You don’t have to be a coder to understand the mistake in the following logic, which is what ended up in 2.4:

if (we are running on 10.6) - Use the 10.7 method for getting the receipt path else - Use the hard-coded path that works on all systems

The stupid thing is that I was paranoid when I made this change and stared at the code repeatedly, and still didn’t see the obvious error. (It should have been “if !(we are running on 10.6)”, that exclamation mark reversing the meaning to “if we are not running on 10.6″ – that one missing character causing all the trouble.)

So, how did this not get picked up before it went live? Well, the trouble is that, as a developer, I have no way of testing the installation of the Mac App Store version across platforms. I can test the integrity of the installer package that I send to Apple (which I did), but not the full installation procedure. (If you are a developer and know this to be incorrect, please let me know. I can test the installer package on the 10.8 machine I create it with, but not on my 10.6 machine it seems.) And unfortunately, it seems that the Apple review process doesn’t test the installation procedure thoroughly, either, since this problem was not picked up by the App Review process. Thus Scrivener 2.4 went live with the problem.

The next question is, okay, so stupid mistakes happen, but why wasn’t it addressed quickly? As Johnny Macintosh, one of our US Mac App Store reviewers, understandably complained:

“I am surprised that LiteratureAndLatte released an Update that is unrunnable to the Mac App store and left it that way over the weekend.”

I assure you that it was not for want of trying, Johnny. The truth is, I fixed this issue and submitted version 2.4.1, which contains the fix, to Apple first thing on Friday morning, as soon as I became aware of the problem. As soon as I did so, I also contacted Apple asking for an expedited review, so that we could get the fix into the hands of our users as soon as possible. The trouble is that Apple’s review team does not work weekends, and it takes up to two business days for Apple to decide on whether to grant an expedited review or not. What this means is that, if a serious bug gets into a release that appears on the App Store on a Thursday or Friday, there is no way the fix can make its way to users until the following week.

Another reviewer on the Mac App Store, “super dudes”, from the Canadian store, makes another very good point that needs addressing:

“they better fix this soon, why is there not a way to downgrade if something doen’t work”

This is a very good question, and I wish I knew the answer – but this is a limitation of the Mac App Store, unfortunately, and entirely out of our hands. Once Apple approves an app for sale, any older versions of that app become inaccessible to the user, meaning that users have no way of rolling back to earlier versions. (For our direct-sale version, we provide links to every earlier version just in case there is ever a reason a user wants or needs to downgrade: http://www.literatureandlatte.com/scrivChangeList.php )

But older versions don’t only become inaccessible to the user – they become inaccessible to the developer, too. Once I became aware of the issue and uploaded the 2.4.1 fix, I then looked for a way to revert the on-sale version to 2.3.1 until 2.4.1 got through review, so that this issue could be eradicated in the meantime. However, it seems there is no way of doing this, and that the only way forward is to wait for Apple to approve the 2.4.1 update.

As for the status of the 2.4.1 update, Apple yesterday informed us that the expedited review process had been accepted, and 2.4.1 officially entered review. Unfortunately, it was rejected this morning for a reason that makes no sense (for not being sandboxed, even though it has been sandboxed since 2.3). I have disputed this, asked for more information, and re-submitted, so we are now in limbo waiting for Apple to get back to us on what is going on. I am really hoping that 2.4.1 will be with users either later today or tomorrow, but it is entirely in Apple’s hands.

All of this is made worse for everyone by the fact that there is no really obvious “Contact Support” button on the Mac App Store (even though they added such a button to the “Apps” section of iTunes recently) and many users seem to miss the “Scrivener Support” link, meaning that a lot of frustrated users don’t seem to realise that they have a way of contacting us and getting help from us, and so instead leave one-star reviews telling us they love the app but that it’s broken.

In short, the situation is just as frustrating for us as it is for you. The coding mistake is mine, and I take full responsibility for it, but because of the workings of the App Store, we were not able to get a fix into your hands immediately, despite having the fix ready within hours of the problem coming to light.

As I say, in the meantime you can use the version on our site and contact us if you run into any issues – we will absolutely ensure you get up and running somehow. And we hope that 2.4.1 will be with you very soon.

UPDATE: We have been left with no choice but to withdraw Scrivener from sale on the Mac App Store until this problem is resolved. We hope to have it available again soon. Please see my blog post explaining this decision here:

http://www.literatureandlatte.com/blog/?p=348

We are fortunate that Scrivener is being adopted by numerous fields of practice http://www.literatureandlatte.com/whousesscrivener.php, so we’ve tried to automate our web-store as much as possible in order to cater for most purchasing requirements. If you go to our web-store here http://www.getscrivener.com you will notice a Volume Discounts Available link associated with all our Scrivener licence types. If you press the link, you will then be able to see that we offer pricing in discrete bands that depend on the number of licences being purchased in a single transaction. Taking Scrivener 2 for Mac OS X (Regular Licence) as an example, it is typically $45.00 for each licence, but if an institution were to purchase 51 licences then they would only cost $27.00 each.

Going the volume discount route and purchasing licences within a single transaction can obviously lead to a decent saving, but note the institution will only receive a single user name associated with a single serial number covering the number of Scrivener installation seats requested. It is therefore advisable that an institution name is used when going through the purchasing process. If you were purchasing on behalf of Stanford University, for example, using ‘Stanford’ as the ‘User’s First Name:’ and ‘University’ as the ‘User’s Last Name:’ would be advisable. If you were buying a number of licences for a particular department, perhaps the library, then ‘Stanford’ as the ‘User’s First Name:’ and ‘Library’ as the ‘User’s Last Name:’ would probably be a good way to go.

If employees at a company want personalised licensing for Scrivener, tied to their specific user name, then going the volume discount route is not possible. Licences tied to a single user name need to be purchased separately.

Some institutions may be exempt from sales taxation. As there is no global database available detailing exempt universities or businesses, it is a limitation of the automated system that sales tax, if appropriate, will always be charged in the first instance. If you’re organisation is exempt from taxation, the value can be rebated to your method of payment once you’re in receipt of your STxxxxxxxx order confirmation. The order number is dispatched immediately to the given email address, and if you send this, along with your exemption certificate, to supportATesellerateDOTnet then the sales tax portion of your order will be rebated to your method of payment.

The easiest methods of payment in our web-store are via credit card or a PayPal account, but if your order value is over $500.00 then the option to complete the transaction using a purchase order will open up. The company that run our web-store (eSellerate) manage the entire purchase order process. E-check (ACH) (U.S. only) and wire transfer are further payment options, with the wire transfer attracting a non-refundable banking fee.

I trust the above information will make the process of cleanly securing a bulk licence order for Scrivener easier to achieve. I hope any institutions that implement Scrivener into their workflows really benefit from the experience.

All the best, David.

When writing your book this month, it is widely considered acceptable to write as much as you can, even if the quality of what you write may not be what you would consider “up to snuff” for the story you are writing. Since the daily word count is the main goal of the project for most people, this is okay. However, if you are also working toward the goal of producing something worthy of publishing—or at the very least, something you can be proud of—you might wish to somehow mark passages of text that you do not feel happy with, without completely deleting them or excluding them from the total counted work. There are a few ways of doing this in Scrivener.

Inline Annotations: The first and most direct method is through the use of inline annotations. Annotations can be used to mark blocks of text as a “comment”, and it works a bit like a toggle, much like a bold or italic range of text might—but this is merely the default way in which Scrivener treats them when you compile. In the “Footnotes/Comments” compile option pane, you can elect to leave annotations in the text, right where they are in your editor. You can even remove the enclosing brackets that Scrivener would normally insert around them, causing them to appear as normal text. For NaNo, all you need to do is submit raw words. You don’t need a formatted document, and so compiling as a .TXT file is perfect as it will strip out markings such as annotation colour. The advantage of this method is that it is as easy to “delete” a poorly phrased sentence as it is to italicise it, and it even looks a bit like you took a red pen to a printout, which is always satisfying.

A “Dust Bin” File: Another way of approaching this is to indeed fully remove the offending text from the section you are working on, but in such a way that it remains counted. An easy way of doing this is to select the text and then right-click on it, choosing to “Append Selection to Document”. What I like to do is create a single “Dust Bin” document at the bottom of my draft for the collection of all these bits of text. On the Mac, you can set that as a favourite document by right-clicking on the “Dust Bin” item in the Binder and selecting “Add to Favorites”. This will bump the item up to the top of the append sub-menu for easy access in the future. While this method takes a bit more work, the advantage is that it leaves inline annotations free to use for their intended purpose, as comments to yourself while writing, as well as keeping your text clean and easy to read. So long as the “Dust Bin” text item is located somewhere in the draft, they will be counted by the various statistics tools available to you, and included in the draft when you compile. Once November has expired, you can simply move this file elsewhere or delete it entirely.

Inspector Comments: Similar to the above, this technique moves the text to the Inspector sidebar instead of a secondary document. Inspector comments, like inline, can be included in the final output, with the advantage of being pinned to the precise location where they came from. That may come in handy if you change your mind later on. One downside to using these is that text moved to comments will not be counted in the program’s statistics while you work. (If you are a Windows user and cannot find this feature, try downloading the NaNoWriMo demo version. It has a sneak preview of the feature, which will be included in the next stable release.)

Overstrike: A natural way of marking text to be deleted is to draw a line through it. It’s easy to mark text with an overstrike in Scrivener, and on the Mac you can even set the compiler to automatically delete any text that has been overstruck. For NaNoWriMo, that won’t matter much, because as we’ve already noted, you want all of this to be in your word count anyway. For Windows users, while there isn’t a way to strip out overstruck text automatically, you can however search for overstruck text with the Edit/Find/Find by Formatting tool. An alternative to overstrike, if you find it causes too much visual clutter, are highlighters. A number of preset highlighter colours are available. Like overstrike they can be searched for with “Find by Formatting”, even by colour.

There are many other ways to sequester text to the loony bin without fully getting rid of it. Stashing them into the Document Notes sidebar is a good choice, as this pane is readily accessible even from Composition Mode (called Full Screen on Windows). You can turn on Notes export in the compile Formatting option pane to include them in the overall count (though do note that Scrivener’s internal statistics features will no longer pick up on them if you do this).

I have found the ability to set aside text I don’t much care for to be liberating in an endeavour like this. It is all too easy to just throw up your hands and tell yourself that quality shouldn’t matter. And to a degree, when you have 50,000 words to write in 30 days, that is not an unfair assessment. But being able to physically shove text aside that you know you’re not happy with, and forging on without it toward a better core of text that you are happy with can help keep your spirits up throughout the month.

As always, remember that we have a coupon available for 20% off to all participants of NaNoWriMo, and those that qualify as winners by November 30 will receive a 50% off coupon toward Scrivener on the platform of your choosing (Windows or Mac OS X). Good luck, and keep writing!

Many of our Mac App Store users have been writing to us to ask why the Mac App Store is still showing Scrivener 2.2 as the latest version, when the version on our site was updated to 2.3 over three weeks ago. This is as frustrating to us as it is to our users – we would much rather everybody was using our most recent version – but unfortunately we have no control over how long it takes for updates to get onto the Mac App Store, and this time around things have been a little more complicated.

We submitted version 2.3 to the Mac App Store three weeks ago, on the same day we released 2.3 on our site. Every time an app is updated on the App Store, it has to go through Apple’s review process again. Usually, it takes anything up to a week before a reviewer picks it up from the queue, and then it takes a day or so to get accepted or rejected. (I don’t think we have ever been accepted first time – there’s always a new reason for rejection!)

However, the App Store review process has recently slowed to a crawl, presumably because of all the problems Apple had last month whereby they somehow managed to corrupt many of the updated apps they uploaded, causing crashes for thousands of users of different applications. As a result, it took a little over two weeks before we even received notification that 2.3 had made it into review.

A brief digression: A few users have asked us why we can’t go back to simultaneous releases – after all, for the past few updates, we have released the Mac App Store version on the same day as the version on our site. But the only way we could do this was by holding back the update from our site until Apple had accepted it for the Mac App Store. We’ve never been entirely happy about doing this, and have decided, especially with certain things we have had to get into place in our non-MAS version ready for Mountain Lion, that it’s better to get an update into as many users’ hands as possible as soon as it is ready. After all, simultaneous releases won’t get Scrivener to our Mac App Store users any faster; they just make everybody else wait unnecessarily as well. And besides, we thought it would only be a matter of a week or so before App Store users had 2.3 in their hands too.

But, as I say, this time it took over two weeks to get into review. It then took another five days for us to receive the news that Scrivener 2.3 had been rejected.

The rejection wasn’t entirely unexpected, although it was disappointing. On 1st June, Apple introduced a new rule on the Mac App Store – all apps sold through the App Store (by third-party developers, at least) must be “sandboxed”. Sandboxing is a new security feature which essentially locks down everything an app can do on your Mac – reading and writing files, accessing the internet and so on. For an app to be able to do any of these things (which is obviously vital for a great number of programs), it must get “entitlements” from Apple, justifying them to the reviewer, and even then, some things are prohibited and certain long-standing features of many apps – such as the ability to access a folder or file between launches – are no longer automatically available and involve having the user do a little extra work to grant permission.

Which is all fine (from a technical perspective, at least; this isn’t the time to talk about the pros and cons of such a security system, and I am not expert enough in that domain) – I have done a lot of work on sandboxing over the past few months to ensure that, should Apple enforce it, Scrivener would work without too much extra inconvenience to the user. However, Apple said that any apps that had been sold on the App Store before 1st June (as Scrivener was) would not need to be sandboxed for bug-fix updates. So, knowing that sandboxing would cause some minor extra inconvenience to users (users will explicitly have to tell Scrivener which folders it is allowed to access for features such as linked images, references and aliases to work, for instance), we submitted an unsandboxed version of 2.3 in the hope that it would be considered a “bug fix” update. It wasn’t.

So, as soon as 2.3 was rejected for not being sandboxed, I was ready to re-submit a sandboxed version immediately. But before I did, I noticed something rather worrying. Although our sandboxed version had been extensively tested on Lion and on some pre-release versions of Mountain Lion, when I tested it out on the developer Golden Master of Mountain Lion, I discovered that some key academic features no longer worked – in particular, the integration with MathType (which relies on Apple Events).

As far as I can tell, this is a bug in sandboxing on Mountain Lion, and I’ve contacted Apple about this (taking out a Technical Support Incident with them) to see if there is anything I can do about it on my end. But, until I hear back from Apple, at least, it leaves us between the proverbial rock and a hard place. Apple won’t let us upload the non-sandboxed version of Scrivener 2.3 (which works fine on Mountain Lion) and sell it through the Mac App Store. But if we upload the sandboxed version of 2.3, then although it will work fine on Lion, as soon as any of our Mac App Store customers upgrade to Mountain Lion later this month, they will find that the MathType integration is broken. (I have appealed to Apple to let this release through the App Store without sandboxing until the issue has been resolved, but that was a no-go.)

I know most of our users are probably not going to be worried about MathType support, and may feel that holding back from re-submitting for a few days over this one feature is unnecessary. But for some of our academic users this is a key feature, and I would like to get it resolved before resubmitting if I can, rather than having to explain to users why this is broken when they update to 10.8.

So, as things stand, I am waiting for a response from Apple and will re-submit 2.3 to the App Store, sandboxed, as soon as I can either fix the MathType issue or know that it cannot be fixed.

But now for the good news: Mac App Store users do not have to wait until 2.3 is released on the Mac App Store in order to start using it; you can just download and run the version from our site if you like. As long as you have run the Mac App Store version once, the version on our site will recognise you as a registered user. This is because the first time you run the Mac App Store version, it copies its internal machine-specific, Scrivener-specific, user-specific validation file (which is installed into the app by the Mac App Store’s activation procedures) to an external location on your hard drive (the Application Support folder). Our regular version can then look for that validation file and thus recognise your machine as registered. So please do go ahead and download 2.3 from our site if you don’t want to wait for all of these issues to be resolved. (Please note that to install it without any problems, you should delete the version of Scrivener from your Applications folder, first – you will most likely be asked for your admin password when you do this because the Mac App Store write-protects downloaded apps. If you don’t do this first, you may have problems installing because of this write-protection. This won’t affect any of your Scrivener projects.)

As an addendum, I am going to grumble about one aspect of sandboxing, seeing as implementing it has involved a lot of bug-reporting to Apple over the past few months. I’m not against sandboxing in principle (much), and the Apple sandboxing engineering team has worked hard to fix as many bugs as possible. But the big flaw, in my personal opinion, is that, for the first time in as long as I can remember, Apple has enforced a new technology on third-party developers without first “dog-fooding” it (as all the cool kids say). At the point when Apple announced that all apps on the App Store would have to be sandboxed, of Apple’s own software, aside from some small helper apps, only TextEdit and Preview – some of the simplest apps on your Mac – were sandboxed. That’s still the case on Lion (on Mountain Lion, a couple of other apps have been sandboxed, but not many). None of Apple’s major, high-end programs have yet been sandboxed. Having problems with updating an app on the App Store because of sandboxing issues is thus made just that little bit extra infuriating when you know that Apple released significant, non-sandboxed updates to iPhoto, iMovie, Aperture and Final Cut after their own 1st June deadline (Apple isn’t obliged to follow the rules it sets for other developers, of course, this being its own store – but its own software is just as much at risk from security threats as any other). I can’t help feeling that, had Apple set out to sandbox all of its major applications before ruling that other developers must, we wouldn’t be facing problems such as these, and sandboxing would have been a much smoother transition for developers and, more importantly, for users.

But hey, I’m just a grumbly developer. Fingers crossed Apple helps us iron out these issues and 2.3 (or 2.4) makes it onto the App Store soon. In the meantime, my sincere apologies to our Mac App Store users for these delays.

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.