I think I've just come up with a real flaw, losing writing

I’ve begin outlining a long story, a novel, in Scrivener, finding the iOS version ideal in many ways.

And then it has just lost me a chapter’s synopsis, the second time n two days.

How this happens is far too easy. I’m looking at the cork board, feeling the cards are ideal. I writte the flow of a synopsis, a critical scene as presently thought. I finish the text on the card, and reach to tap the screen. At arms length, the tap goes a little awry – touches on the cork board, instead of the card.

And with that, the entire card is gone. It seems not retrievable. It’s not in the Trash, a command-Z has no effect, and everywhere in the binder it’s missing.

This should never happen, I imagine we can agree. It might be one of those things that’s managed to sneak up via Apple’s tweaks by new hires on iPadOS, elsewhere showing with no mention or comment.

I hope you can fix this easily, as it should be a matter of proper active area masks, or trapping events. I hope you can fix it soon.

I don;t think I can construct just the same idea – the big loss.


p.s. Exactly the same thing happens when creating a new document, not in the cork board.

I just tried it before attempting a new pattern, creating from the binder, made brief one as a test. One touch outside the document, and it was gone. As if it had never been there…

p.p.s. I’m on the latest security release, iPadOS 16.6, via iPad Air 4, lots of resources.

The annoyance you have hit upon is not a bug.

Dismissing a dialog sheet by tapping outside the bounds of the sheet is entirely canonical on iOS/iPadOS, but it does seem like safety considerations might ought to hold sway in this case.

I take you to be suggesting the New Document sheet should only be dismissible by tapping Cancel or Done.

This seems like a good idea to me. You should consider posting an item to the Wish List to this effect.

@gr, you’re missing a distinction here, aren’t you?

Eased closing of panels by mousing off of them can be fine, in recent styles of speedup across several software lines-of-being. It’s a smoothing out of the activity dialog flow, which works as long as its effects are properly limited and managed.

In both cases here, though, content has been created…and one thing you never do in a user experience is throw away what a person has done.

This is true if the content is only a beginning with an empty card or document, not less actually than if you’ve written, pasted, or drawn something in it. The person made something, and it’s up to them to delete it by saying so, if they don’t want it to remain.

Thus, this situation now in Scrivener iPatOS is a bug, certainly. If it appears in iOS, bug as well. No one wants to find that they’ve disappeared things with a misplaced finger.

That Apple created the issue by changes of default behavior is normal in software – it is always a moving flow, and an application continues to live by adapting, refreshing, just as persons and tools do in the world we use it to describe, engage, and invent in, not so?

I’ve kept coming back to this, awkward as it is through trying to be short with the several concepts involved, because I’m wanting to give you a nicer answer. But the main thing must be to get this content-removing bug out of Scrivener, and technically, it appears this should not be a difficult challenge.

Not sure we need to go around about this. I agree it is unwelcome behavior and it would be well to change it. And you should post the matter to the Wish List. And I am happy to call it a design flaw that the sheet works that way.

But perhaps the least important thing I said is bothering you — and it seems at least sometimes this is because you think it means I disagree with you about the above — which I do not.

I would say this about the ‘bug’ point: Is the sheet behavior a bug? A programming bug is when there is a discrepancy between the algorithm the programmer meant to realize and the algorithm actually coded. I don’t think we have real reason to think that is what is going on here, and I think it unlikely to be so (given most of the behavior we are seeing is the result of intentionally invoking a certain OS-supplied sort of object). Not everything that does not work as it (in some sense) should is a bug!

I think the thing you are pointing to is a design flaw — just as you called it in the title of your post.


@gr, kind thanks, as that’s a well appreciated note to be able to respond to.

I’m very attuned to your concern; in fact especially in regard for the person who created this instrument I think entirely with his own hands, not to say thinking it up, after a hired project went astray. That’s @KB, Keith Blount, and at every level I’ve run into over years of this iOS accomplishment, he’s thought it out and imagined a fine way to get the maximum for Scrivener’s approach to writing, out of the highly constrained framework Apple provided. Right up there with the initiators there of so much still leading the way, how many decades after…but we know about that.

Myself, I’ve never been a programmer, if it’s a language I’ve used it seems a very long time, and where some young internationals liked to call me ‘Cheetah’ after the speed I could concoct elements and then a fully demanding and working local becomes global system for something we did in a relative instant, to try to answer early Covid needs. For Bell Labs once, I concocted a ‘natural language interpreter’ their PhD coterie unhappily argued was 20 years before could be made (it turned out 18 and gave friends jobs until then). This gave the entrée to quite a lot, where I could work much more fundamentally with puzzles across intents and cultures, but I am just trying to let you see where I might be coming from.

I resonate with your viewpoint, in that I share a variation on it when persons come in here thinking they have the right to demand, that ‘programmers could just do it’, and keep it up without any respect or understanding. I’m sure you’ll see the connection.

Directly in this case, Keith and others had indeed invented and coded very gracious algorithms out of deep discovery and understanding, and in demanding waters of need and enablement. It’s that Apple upset the cart, much later, when persons who didn’t realize the original deep work there was important, or indeed what it’s subtleties arranged.

If there’s a (re-)design flaw, it’s there – at Apple, that they sprung abilities preferable in some cases that they could see, but without the nous to ensure guarding by defaults the long-used functioning. You’ll know this is rather typical these days, with a cavalier attitude not new either that we needn’t go into – wherever it happens, pride before a fall, or at least blocking from what they imagine they are achieving

How this flaw shows up – that’s a mis-performance of what persons have been confident to use, and for such persons, it’s simply a bug. There isn’t any pejorative about who caused it, just the natural desire to see it dealt with, anticipating what they enjoy in trust of a fine tool answering their own purposes – in their hands.

How you arrange that…well, one of my first consultings in Europe saved a company, made a friend and long partner of its managing director, and did so, yes, by engaging some deep understanding of how to work the technology, but primarily I would say in how it built a communication into what had been mechanics in their process.

This is where the aha’s came, in joy of the first demonstration, the sight of how it would save. It allowed natural imperfection, and developments over time, in just the way we’re discussing here – just with understanding and trust for all involved, not incidentally making space where everyone could be natural in response, and enjoy each thing they made next, which kept expanding the appreciation.

Well, you had to be there :slight_smile: , and it’s a nice memory. We both know that ‘feature suggestion’ is a much less enjoyed and coupled world, which is why I don’t go to that. Here, with the way L&L folk can and do respond, it just feels better to point out what they know they enjoy solving, each time so that persons realize what it is they’ve done.

Most of my commenting over the years here has been in aid of that, certainly with those intents of practice, the hope of such pleasure for Scrivener persons, when others find recognition of their accomplishment, each time renewed.

Thanks again, @gr, and hope this gives you something of a satisfaction to read yourself, and that it arrives suitably on your time zone, as intended :slight_smile:


Thanks for the report.

Going over some old notes, it looks like the only things that we added tap-to-dismiss on were the inspector and the compile sheets. You could consider both of those actions to act “normally” where this is considered a cancellation by the toolkit. However in the case of the Inspector (where that would not be desirable) it doesn’t really feel that way because data is written as you use the controls. There is no real apply/cancel dynamic there and all forms of dismissing the inspector will value what has been done within it.

So I think you may be right (though honestly I have no actual clue) that at some point Apple added cancellation mechanics to most or all of their sheet controls, where the expectation is probably along the lines of if that being unsafe, the control should be writing every action like we do already.

There is hopefully some solution that works within the framework for cases where the sheet is being used to build data that hasn’t been written anywhere yet, such as in the case of the Add panel. I don’t know what that could be, but it’s enough to at least write up a report on. At the least maybe there is way to override the tap-outside behaviour or disable it.


It is possible to turn off the tap-to-dismiss behaviour, but the strange thing is that I’m not seeing this particular bug in the corkboard anyway. It’s true that you can tap to dismiss the synopsis editor, but when you make changes to the synopsis, they get updated live anyway. So here’s what I see:

  1. I double-tap on the corkboard.

  2. I start adding text to the synopsis.

  3. I tap outside the synopsis editor so that it disappears.

  4. The text I added is there on the corkboard, so I haven’t lost anything.

Aaah… Wait. Are we talking about the “new card” feature. In that case, yes, you are right - you can tap to dismiss and thus lose a new synopsis. It seems that Apple added this default tap-to-dismiss behaviour a couple of OSes ago.

I have fixed this for the next update so that you will no longer be able to tap outside to dismiss the “new text/folder” sheet.

Thanks and all the best,


Great – yes, that’s it, then ‘new card’ is where I first hit this.

You probably noted that the same problem exists if you create a new document by any other means – + icon on Done document header, or in the Binder.

With any luck, the same code fix will just do it for all of them, but since it’s a differing pane, thought had better mention it.

Keith, thank you kindly, and as you’ve seen, for all :slight_smile:


1 Like