Yes we run ANALYZE regularly, and no issues related to the FTS virtual table come back. What I've noticed is that if we drop any existing FTS virtual table on cold start and re-create it from the existing regular sqlite tables (our FTS virtual table is built from a combo of data in two regular SQLite tables). The search slowness resolves itself... It's not as if the OS is dropping the virtual table when the app is removed from memory. Otherwise we'd be seeing the search throwing errors that the table didn't exist etc. The table exists when the app comes back from from a cold state post OS upgrade. Queries against it just take 300% longer to complete. Once we DROP the existing virtual table and reload it, everything seems to work just fine until the next OS upgrade. We never had this issue before iOS 17.2.1 so I'm just trying to ascertain what possible changed in the OS since then that is causing this issue to begin with.

We received feedback from one of our affected users that updating from whatever version of the 18.1 Beta they were on to 18.1 Beta 5 fixed the issue for them. So this was definitely something related to the iOS 18.1 beta. But I cannot for the life of me reproduce it or figure out what was negatively affecting WebViews in that version.

We are experiencing the exact same issue with 18.2. Any update on this so far?