Virtual Keyboard overlaps typing area on iPhone XR
AmberV wrote: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.
It's been three months - any update on this or did I basically waste $20 on this app?
-
AmberV
- Posts: 24551
- Joined: Sun Jun 18, 2006 4:30 am
- Platform: Mac + Linux
- Location: Ourense, Galiza
- Contact:
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.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles
AmberV wrote: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.
-
AmberV
- Posts: 24551
- Joined: Sun Jun 18, 2006 4:30 am
- Platform: Mac + Linux
- Location: Ourense, Galiza
- Contact:
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.
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.
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.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles
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.
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.
-
AmberV
- Posts: 24551
- Joined: Sun Jun 18, 2006 4:30 am
- Platform: Mac + Linux
- Location: Ourense, Galiza
- Contact:
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.
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 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.
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.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles
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.
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.
-
katlovergilpin
- Posts: 32
- Joined: Thu Aug 27, 2015 5:52 pm
- Platform: Mac
- Location: Portland, Oregon
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.
Thank you.
-
AmberV
- Posts: 24551
- Joined: Sun Jun 18, 2006 4:30 am
- Platform: Mac + Linux
- Location: Ourense, Galiza
- Contact:
The virtual board takes up half the screen when using the pencil or a bluetooth keyboard.
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.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles