Open ffittschen opened 1 year ago
Hey @ffittschen
Thank you for your feedback! We have noticed this behavior lately but didn't have any research on this topic yet. We will keep you posted.
Hey @ffittschen
We would like to have a better understanding of your case. The "internal binary framework", who uses it?
Prospect PR #1413
Hi @ffittschen,
We merged a fix for the described issue to develop yesterday 🤝 Feel free to check it out for confirmation for now.
Best, Alex
Hi @ffittschen,
we just released 5.5.0 that contains support for library evolution.
Please let us know if you are running into any issues. And feel free to re-open the issue, if so. 👍
Best, Alex
Hi @goergisn, while trying to update to 5.5.0, we are still facing an issue with Adyen's @_spi
usage. Compiling the individual Adyen schemes with library evolution enabled and creating an xcframework out of them works fine now, but when importing them in our own code, we get the following error.
Cannot use conformance of 'AbstractPersonalinformationComponent' to 'Component' here; the conformance is declared as SPI
Attached below you can find a minimal sample project that reproduces the issue. For the example, I compiled Adyen
and its dependency AdyenNetworking
and created XCFrameworks using the following script:
After creating the XCFrameworks, I generated the project using Tuist (which should not be relevant for the example, but I included the Project.swift for completeness) and built the LibraryEvolutionTest
scheme, which results in the same error as in the screenshot above.
Please correct me if I'm wrong, but looking at the original PR that introduced the @_spi
usage, it looks to me like it is only used to hide types from the DocC documentation. Since Swift 5.8, there is a @_documentation(visibility:) annotation, which was introduced specifically for this purpose.
Maybe it would make sense to migrate from @_spi
to @_documentation(visibility: internal)
? That would most likely also eliminate the need to provide default implementations the compiler complained about when compiling @_spi
annotated code with library evolution.
Hi @ffittschen Thank you for sharing + providing a sample project.
@_spi
is used in our case to have visibility/accessibility of the specific objects within the SDK parts (Core, Session, Card, Components, ...) but not exposing them to the public interface. The reason for that is to not imply stability of these parts of the code (meaning not having to introduce breaking changes if any of these interfaces change).
I'm taking a look at it and keep you posted.
Ahh I see, maybe in that scenario the package
access modifier introduced in Swift 5.9 would help to explicitly remove those SDK parts from the public interface instead of hiding them through SPI groups, while still being able to access them within the SPM package?
Yes, we're currently exploring the scope of switching to the package
access level as we also use @_spi
on protocol properties/methods which don't allow individual access control and might require some more thought/work.
Describe the bug As we are using Adyen alongside an internal binary framework, we need to compile it with library evolution enabled (
BUILD_LIBRARY_FOR_DISTRIBUTION=YES
), so that binary compatibility between our binary framework and its Adyen dependencies is guaranteed.Starting with this PR, Adyen uses the underscored attribute
@_spi
to mark declarations as System Programming Interface (SPI). These@_spi
annotations cause build errors when compiling Adyen with theBUILD_LIBRARY_FOR_DISTRIBUTION=YES
build setting to enable library evolution.To Reproduce Steps to reproduce the behavior:
Expected behavior I'd expect no build errors when using the
BUILD_LIBRARY_FOR_DISTRIBUTION=YES
build setting.Screenshots If applicable, add screenshots to help explain your problem.
Environment
Additional context This problem was first brought up in this issue: https://github.com/Adyen/adyen-ios/issues/1130