Result: When typing in a document, the virtual keyboard overlaps most of the current line of text so the user cannot see what they are typing.
Expected Result: To be able to see the text being written on the screen above the virtual keyboard.
Open Scrivener iOS on iPhone XR
Go into a project.
Open a new document or an existing one.
Type down to line 21 or lower.
Observe the text as it prints to screen is beneath the virtual keyboard.
This occurs regardless of which keyboard features are enabled. It also occurs on third party keyboards if enabled. It will occur if adjusting line spacing on Scrivener as well.
Tested on iOS 13.2.3, iPhone XR, Scrivener for iOS version 1.2.
Repeatability 3/3
I’m having the same problem, have been for a while now and it makes the app unusable. I’m on an iPhone SE. Updating to 1.2.1 doesn’t fix the issue.
I think I’ve found a fix. Delete Scrivener from your phone and reinstall it. I also rebooted the phone before downloading it again from the App Store. The last line of text now doesn’t disappear below the keyboard! No guarantees this’ll work for other users but it worked for me! Wish I’d tried this sooner.
Thanks for the updates, we’ve got it on the list to look into tweaking it further.
Meanwhile this should be relatively simple to work around, no? Just leave some empty lines at the end of the file. I can’t reproduce this myself, so I don’t know if it works, but it seems logical to me.
How much text would you estimate you need to write, and is this something where you see the scroll point gradually getting worse and worse, into the empty lines you added? I’ve never seen anything remotely that bad on my own device, which is why I have to ask. Sometimes the very edges of descenders crop into the keyboard a bit, but that’s the most I’ve ever seen—certainly not whole paragraphs.
I am having this issue as well. The scroll is not working on my iPhone 11. It doesn’t matter how many lines I enter, I eventually catch up and everything is hidden by the keyboard. When I do scroll up, my blank lines are still there, but the app no longer follows along. I suppose that’s a good way of putting it.
I’m having this issue. Weirdly I’ve found that switching to the emoji keyboard and then back to the regular keyboard fixes it. Needs a proper fix still but that’s a good workaround. I have reported this issue to the Apple support team hopefully they solve this issue soon.
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.
Wish I’d tried this sooner.
