As noted it is on the list to be looked into for the next update. It’s not actually an easy fix, unfortunately. Different devices demonstrate different results, and factors such as auxiliary keyboards and additional toolbar strips can change things. Further, different sub-versions of iOS you are using and other factors can all make it so we don’t even see the problem ourselves sometimes. It’s really difficult to fix a problem “blind” like that, especially when it needs to work across dozens of different displays sizes and from iOS 9 to 13.
Let me know what I can provide you to help debug. If there are logs or project files or screenshots or some kind of testing you’d like me to share or perform, I’d be happy to assist. This bug makes the software essentially useless, even on very recent iPhones running the latest version of iOS, and it’s been “on the list” for months.
A stop-gap measure might be to implement typewriter mode for iPhone. At least we’d be able to see what we’re typing.
Thanks for the offer. There shouldn’t be any logging data, there isn’t much to speak of on iOS, save for crash reports. From the descriptions we have, it doesn’t look like it takes much by way of special data setups to trigger it, rather a pattern of usage repeated often enough.
Unfortunately that is often the actual problem. On older devices the issue is much less impactful, and may not even be visible. Like I said before, on my iPhone 6+ running iOS 12 there isn’t really an issue. I sometimes lose half a line after writing an entire screen (and I use a keyboard), but I can always flick scroll it back into view. It is not, I would say, any more or less of a management issue than any other program.
Newer stuff with Apple mainly means “the buggier stuff”, these days. My favourite was a memory bug in iOS 13 that caused sync to crash in a select newer devices. For months we took a beating over it, here and in social media and elsewhere—surely it’s our fault because it only happens in this one program, right? Then like magic one day, nearly half a year after they released iOS 13, Apple finally fixed their broken memory system.
Anyway, sorry for the rant. It’s just this kind of working around Apple’s broken toolkit is something that consumes a significant percentage our development time these days—and this in particular is galling. Like individual developers should have to in any way be manually handling the job of keeping text above the keyboard. It’s like asking developers to make sure the knob on their scrollbars doesn’t get desynced. Ensuring the bottom of the text editor view doesn’t slip below the keyboard apparatus shouldn’t be something we have any business messing with in the first place, let alone fixing their bugs with it. But here we are, and we’ll keep trying to fix it, because if we don’t it’s our fault.
I’m sorry it’s difficult to create an iOS app, but you are charging writers $20 for it without disclosing that every five or six words they’ll be expected to flick the screen to see what they just typed.
It still seems to me that typewriter mode (which personally I don’t really like all that much and don’t use on macOS) would be a stopgap that would enable users to use the app we bought.
I think you’re missing the point being made, it’s not that is it difficult to create an iOS app, but rather that this specific issue has a number of challenges that have made providing a solid fix unusually problematic. Most bugs are fixed in under an hour, to put it into perspective—and to knock a hole in the whole “it’s all difficult” misread.
As to the rest, that wouldn’t be a broadly true disclaimer. What you are describing is atypical behaviour, and from what I can tell, it requires a specific subset of variables in order to be severe enough to be of impact every five words. It sounds like we would even need to take into consideration the orientation of the phone (let alone that it is a phone and not a much more common tablet) as well as other contextual variables (like the fact that you seemingly write a lot of five-word paragraphs).
To compare, it sounds like I use my phone entirely differently from you. I position it sideways with the binder hidden, at a zoom rate of 1.0. My preferred font of Source Code Pro 12pt, at 1.1 line height, makes so I can see roughly 300 words per screen and on average 18 words per line. Since it takes about a dozen paragraphs on average before I run into a case where the bottom line gets de-synced, I would need to write on average 900 words before encountering it. That feels right to me, with how rarely I see it. I very uncommonly even write more than one screenful of text on my phone.
It’s something that I put forth as a potential solution as well, back when the first round of fixes were done for this. There was no response though, so I doubt there is much interest in implementing that.
Still having this problem. With regards to the post above, I write on iOS in a completely different way. My main writing is done on the Mac and my iPhone writing is done on the fly, those moments when I’m out and about, and an idea occurs to me and I can peck out a line or ten with my thumb.
And I don’t mean note taking. I mean actual novel writing. On the small phone I have (an SE), I’d have to drag the text up the screen every two or three lines. It’s not conducive to flowing writing.
Also, I’d be happy with a typewriter mode option if it fixed this.
Checking back to see if there’s a fix to this. From what I gather, there isn’t. Any idea when one will be available? It’s super annoying and it does the same thing on an iPad 11 Pro even when typewriter mode is on. The virtual board takes up half the screen when using the pencil or a bluetooth keyboard.
Thank you.
I don’t know anything about writing with a stylus, but you definitely shouldn’t be seeing the on-screen keyboard when using a physical keyboard, unless you want to. There may be a button on your keyboard that toggles the on-screen keyboard on/off. I’d check the documentation at any rate, as the system-wide default behaviour is meant to show the entire screen for editing, when using a real keyboard.
I can’t speak to when it will be fixed though, I don’t have that information. Sorry, I know it’s pretty bad, I’m not trying to minimise it, just help people find workarounds.
I bought the new iPhone SE recently. Still having the same problem.
Any updates on this? I’ve found this problem aggravating for over a year now. I understand the problem isn’t easy to fix, but I thought I’d see if there’s been any progress made?
Ugh, same here. Just upgraded from a 6S to a 12, and quickly ran into this problem. It’s driving me nuts.
Still have the same problem with seemingly no fix in sight. Have now deleted Scrivener on my iPhone and might even do the same on macOS as I’ve moved back to another writing app that has no such keyboard issue on iPhone.
I created an account just to post on this thread that this issue is ongoing and I imagine not just for me…
It’s 2022 and this is still the exact same issue. Can someone please address this and tell us when it will be fixed? It’s an issue for all iOS devices with a virtual keyboard, regardless of snark and silly use case arguments above. Also, it’s bizarre to blame iOS when every other text-input application on iOS I’ve ever used has managed to function without this issue, so I don’t see how this is an iOS problem.
I reinstalled the iOS app to see if the keyboard bug was still there. And unfortunately, it is. A shame, as I do love Scrivener on my Mac. I moved away for a while to other solutions that didn’t have a problem on iPhone… Ulysses and iA Writer for example sync really well and are usable on iOS with no keyboard issues. Ulysses is way to expensive for what it is and iA Writer doesn’t have the flexibility of Scrivener. For now I’m back to using Scriv on my desktop and have admitted defeat with the iOS app.
I can replicate the bug by following the steps listed in the first post in this thread (from 2019): Keyboard overlays text
Best,
Jim
Well, I count myself lucky. been using the iOS Scrivener for a long time and never saw such a serious keyboard bug as suggested above. Hence I ask.
iPhone 7, iOS 15.4.1, Scriver 1.2.1 (2096). I tried what is reported at Virtual Keyboard overlaps typing area on iPhone XR - #30 by Monkeyboy and don’t see what I would call a “bug”. I do see that text does get obscured as as more and more text gets entered, but I just use my finger to “flip” up the page a big to make more space at the bottom. I see that all over the place in other apps in iOS and it’s second nature to use the “flip of finger”. Probably an Apple thing to resolve, I would guess.
I’m not going to stop using iOS Scrivener because of it.
I can’t flip up the page. The bottom line stays tight to the top of the keyboard. Then the next line ends up under the keyboard. I’d have to flip it up with my finger for every single line. Other writing programs don’t have this problem, so it’s definitely a bug.
Would anybody still encountering this issue be kind enough to volunteer to test an upcoming version? I have made a change that I am hoping might improve this behaviour. Unfortunately I cannot be sure, however, as I have never been able to reproduce the problem, even after having tested on many different devices and simulator set-ups and across numerous versions of iOS.
The closest I’ve ever been able to get is simulating an iPhone XR with iOS 13.2 (as per the original poster), but even then text isn’t disappearing off the bottom, it’s just hugging the bottom a little closer than might be ideal.
After trying a bunch of stuff, I think it might be caused by the scroll animations not keeping up with the typing, and I think it might be related to the text being scaled (which would explain why it’s only seen in Scrivener as no other app to my knowledge scales a UITextView). (On that it would be interesting to hear if the problem occurs when the text is scaled at 1x; the default scale is 1.2x.) I therefor want to test whether the bug still occurs if I turn scroll animations off during typing.
If anyone can currently reproduce this 100% and is willing to test a new version, please drop us a line at ios.support@literatureandlatte.com with the subject line “FAO Keith: iPhone typing as per forum request”. Please include an email address that I can use to invite you to the TestFlight group. You’ll need to install TestFlight on your iPhone to try the build, and I believe you’ll need to send me the email that you use for your Apple account for builds to be made available to TestFlight for you.
Thanks and all the best,
Keith