iPad version under iPadOS 26 with Windowed Apps Turned Cannot Keep Find/Find Replace Open

[sfwrtr]

Even with the Scrivener App full screen, if Windowed Apps is turned on the Find and Replace dialog process opens, shows on screen, then in seconds dismisses itself. It is fully reproducible. Please see the attached screen recording and duplicate it yourself. A bug fix release is sorely needed. Little things like this make authors unease about losing text or being unable to work. The only suitable workaround is turn off all Windowing, but that causes other usability issue with other apps on the machine.

PS: I have also submitted feedback to Apple, in case it is only an iPadOS issue. It is issue that existed all through the beta release period when developers should have seen this and created new versions. Expect to be contacted.

[AmberV]

Thanks for the report, there are a few weird things going on here when one has an external keyboard in use (at least it seems more stable without that). I’ll get them all written up together as I feel they are at least interfering with each other (the large black bar at the bottom of the screen, for instance).

It looks to me as though all (or most) can be avoided by disabling the auxiliary keyboard row, which is the button with four dots and an arrow pointing up to it, on the right side of the standard Apple floating widget thing. So that’s your workaround for now, just toggle that on and off more as needed than always having it on.

@sfwrtr

It is issue that existed all through the beta release period when developers should have seen this and created new versions.

It’s what you’re supposed to do in theory, but you have no idea how much time was spent just trying to get the Mac fixed (time that is still being spent cleaning up their mess). We’ll get to iOS, but we can’t do everything at once.

[alanhartless]

This happens to me as well. Using the four dots to minimize it doesn’t work because it just reappears as soon as you open search. Sometimes I can get search to open after minimizing scriveners floating keyboard panel a few times but it’s very hit and miss and pretty frustrating. I use my ipad often to write when I travel or at a cafes. My workaround when I need to search is to disconnect the ipad from the magic keyboard and use the onscreen keyboard.

[geezer_nerd]

Same problem here, same lack of help with the floating keyboard gizmo disabling.

On the other hand, Apple’s Preview app has some real problems with windowed mode on the iPad, so Scrivener isn’t alone in this regard.

I solved it by switching back to full-screen app mode. It would be great if iPadOS consistently handled windows better. Maybe now that Alan Dye has jumped ship to Facebook, Apple will get a UI design head who enforces quality and consistency across the board.

[sfwrtr]

Thank you for acknowledging this. It is now January and 26.2 has been out for weeks with multiple Mac releases under your belt, but the iPadOS bug isn’t fixed. Not only that, disabling Windowing app mode in 26.2 nolonger reliably fixes the issue. I am hoping that it wasn’t Apple’s updates to the frameworks and XCode making it difficult to update Scrivener that’s the reason you haven’t attempted to fix this one very egregious issue. I’ve already seen one developer abandon their software over that.

Regardless, I cannot revise on my iPad, which is where I do most of my work. I even had the app lock-up when I succeeded in getting the ⌘F to bring up the search box. I failed on the Find again. I didn’t lose work, but the app crashed after about half a minute.

I did check your internal keyboard workaround. Yes, Find fails with both the Magic Keyboard and an external Apple Keyboard, but as you say, not with the internal iPad keyboard which I never use. For me, this is an awful workaround because I use an external monitor half the time I am on the iPad, but as you say, I should be able to make it work. As a retired long-time developer, I’d advise this: If developers were strictly sticking to the frameworks and best practices, they may have found a bug in Apple’s frameworks. They ought at minimum investigate the bug now so that they can to report it ASAP. If not, they can get a head start on the fix.

Most of your iPad user base is likely dealing with this bug, and are not happy. Apple’s Magic Keyboard is a must-have accessory for professional writers using an iPad, and Find doesn’t work with it.

Nevertheless, and I know it isn’t helpful, I posted a review on the app store. I will revise it or remove it when you either post a schedule an ETA for working on the iPad app, or preferably fix it.

[Ascher]

@geezer_nerd

Apple’s Preview app has some real problems with windowed mode on the iPad, so Scrivener isn’t alone in this regard.

I solved it by switching back to full-screen app mode. It would be great if iPadOS consistently handled windows better. Maybe now that Alan Dye has jumped ship to Facebook, Apple will get a UI design head who enforces quality and consistency across the board.

Thanks for pointing out that this is not Scrivener-specific and also affects some of Apple’s own apps.

[narrsd]

@sfwrtr, it might be well to be a little patient here, actually.

For one, there’s been a holiday period much of the time over which you register discomfort,

For another, as just above reminds, this doesn’t look like a Scrivener problem, and if Apple can’t fix their own apps, no workaround is likely yet.

In fact, the kind of interface element Find appears in is almost assuredly a simple and should be very reliable call for Scrivener to use, to make it appear and controllably disappear, 99% managed by Apple’s software.

To complete, I’m running the same iPadOs version, on a getting-to-be venerable iPad Air 4, and I can’t make the disappearing act appear, trying a number of ways under windowing, smaller or full-screen.

Maybe it occurs only on M-series iPads? A clue there may be an event-related problem is that there is one way I could get the Find box to disappear, which was to overlap the Scrivener window with another, even a much smaller one. When back in front, Find had cancelled, though it remembered its contents when raised again (clover-F).

But again, this should not happen, and if it does, it wouldn’t likely be anything in what the Scrivener code contains which could cause it.

In short, holding your water, using your writing practice to imagine just how difficult and long the travels involved in arriving at a cure for something like this often is, could be recommended.

With fortune, and holidays enjoyed, Apple will get themselves to a new release soon, which could include a fix.

p.s. the reason for the flagging above is that I at first had mixed up the testing a bit….

[sfwrtr]

@narrsd Maybe TL;DR, but I am annoyed, partially as a professional author and partially as retired professional developer. Scrivener is a great product, but the iPad version feels like abandonware. Below, except for the first section that specifies the hardware I use, the rest is me talking about my frustration.

Maybe it occurs only on M-series iPads?

I recently switched to the M5 13”, but at the time I originally posted I was running a late 2019 Apple Silicon iPad Pro 12.9”. Same problem. My problem started with the 26.0 first public beta, and I should have reported it then, but I figured, you know, professional developers run the betas, too. When release 26.0 showed up, removing the legacy features available all through beta, the search bar went completely FUBAR breaking the workarounds I’d been using.

the kind of interface element Find appears in is almost assuredly a simple

Nothing in programming is simple, programmers know this, except for maybe fixing a typo—but then increasing a literal string length might overflow a variable, and, you know… boom! I understand Apple is a real pain to program for, maybe not as hard as Windows ActiveX was, but testing against each beta is SOP, even if for an hour. The ⌘F bug would have shown up.

using your writing practice to imagine just how difficult and long the travels involved in arriving at a cure for something like this often is, could be recommended.

Really, I’ve no choice other than to register my “discontent.” I can’t log in remotely and do overtime to fix the bug for them.

Authors aren’t necessarily patient. Nor developers. I was what they now call a full stack programmer, everything from the UI to the backend, including the interface to the IBM mainframe version of the app. Panic happens. Good programmers work to prevent panic.

I am not saying I never missed things. I put out my share of fires. I do know that my company reacted immediately when they got a nasty-gram. I’ve ignored various minor Scrivener issues and Mac-app parity needs—like a text document diff to disambiguate conflict documents being paramount, and I’ve requested that in this forum. I simply adjusted my writing practices, but a ⌘F failure is bad. It’s like not being able to use the insert signature feature in a PDF app for a business user. So yes, nasty-gram. Since it’s unlikely to bubble to the surface in the app store interface, it isn’t likely to impact the company much, but I know the developers will read it.

I hate to admit this, but I’ve been trialing other software, but Scrivener has capital-F Features I’ve grown to view essential, especially Dropbox sync which beats all iCloud solutions other products use, even Apple’s with which I’ve lost pages of work. The ⌘F issue is so serious for me, I’m very close to buying a bottom-of-the-line Mac Mini ($599) to use where I Airplay my iPad, simply to bypass this bug and get on with getting my work done!