The GRDBInternal private framework that ships with iOS 18 might well create conflicts for apps that use the regular GRDB. The symptom is a hard crash whenever one performs a database access through a DatabaseWriter or DatabaseReader existential - an action that almost all GRDB-powered apps have been doing, for many years. I'm not sure how to write an efficient feedback about this concerning issue. https://github.com/groue/GRDB.swift/issues/1619

Hello, A few GRDB users of the GRDB library (http://github.com/groue/GRDB.swift) see warnings with Xcode 15 beta, similar to this one: objc[59263]: Class _TtC4GRDB25ValueObservationScheduler is implemented in both /Library/Developer/CoreSimulator/Volumes/iOS_21A5248u/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 17.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/GRDB.framework/GRDB (0x1c0be5490) and /Users/***/Library/Developer/CoreSimulator/Devices/77039DFC-6093-4B01-A3F6-4113835E7E0F/data/Containers/Bundle/Application/4BA438C9-3327-44DD-ADC8-B54B45B98742/***.app/*** (0x104325598). One of the two will be used. Which one is undefined. A few of those reports: https://github.com/groue/GRDB.swift/issues/1395 https://github.com/groue/GRDB.swift/discussions/1396 https://twitter.com/JidanzaiDashan/status/1671032934713937920 https://hachyderm.io/@rinsuki@mstdn.rinsuki.net/110496052872999933 I believe some of those users have reported the problem with Feedback Assistant. I have two questions: Is there a way to workaround this problem until a release of Xcode that fixes it? Is there an actual risk of having the runtime use mismatching GRDB classes?

Hello,Technical Note TN2151 describes the 0xdead10cc exception:> The exception code 0xdead10cc indicates that an application has been terminated by the OS because it held on to a file lock or sqlite database lock during suspension. If your application is performing operations on a locked file or sqlite database at suspension time, it must request additional background execution time to complete those operations and relinquish the lock before suspending.This is all pretty clear. After the additional background execution time has expired, all SQLite accesses that create a lock create a risk for sudden termination. An application which wants to avoid 0xdead10cc has thus to actively prevent such accesses... until the application wakes up from the suspended state. My questions are all about the end of this critical lapse of time in the app's life cycle.Eventually, the application may become active, and this clearly marks the end of the 0xdead10cc danger. This moment is notified by UIApplicationWillEnterForegroundNotification. After this notification is posted, it becomes possible again to access an SQLite database without risking any 0xdead10cc exception, until the next UIApplicationDidEnterBackgroundNotification, and the next notification of additional background execution time expiration.But what about cases when the application leaves the suspended state and reenters the background state? This may happen due to the various background modes supported by iOS.First question: Is there one way to be notified of this transition from suspended to background state, regardless of the reason for this background wake-up (core location, VoIP, background fetch, etc.) ?Second question: Is it then possible to start another request for additional background execution time and be reliably notified when accessing the SQLite database creates a 0xdead10cc threat again?Third question: do you have any other advice regarding 0xdead10cc prevention?For the context, I'm the author of GRDB, and I'm looking for a way to package 0xdead10cc prevention in a way that reduces to a minimum the amount of code users have to write in order to protect their app from this exception. Ideally, it would be reduced to a simple boolean flag targetted at users who store their database in an App Group container.Thank you very much!