Closed gverdouw closed 4 years ago
After reflecting on this a bit further, I believe the better approach would likely be to create a new iOS 13+ framework that has my current framework as a dependency. This would then avoid the issue and make it clearer what is supported, though at the cost of another framework to manage.
I am still curious about your thoughts on this (the combination of GRDB and Combine having a higher requirement than either separately?), but feel free to close this as it isn't really an issue with GRDBCombine
Hello @gverdouw,
I'm not sure I follow. What would be the point of hiding the whole GRDBCombine APIs behind @available
, since this library requires Combine anyway? I don't have enough information about your setup - maybe you just need something like #if canImport(GRDBCombine)
?
🤦♂️ How did I miss that, canImport is the solution here.
Thanks @groue!
Hi,
I'm currently building a framework which is shared between two applications, one with a minimum deployment target of iOS 13 and another with iOS 11.
I am able to use Combine in this scenario by utilising @available attributes to limit optional portions of the framework to iOS 13+, but GRDBCombine refuses to work when the target is lower.
Is it possible (or even desirable?) for a library such as GRDBCombine to allow the framework to be imported, but wrapped up with @available attributes everywhere such as what I would need to use it here?
Thanks