The bug reference is FB10313868 - thanks
jon-iproov
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
The most thorough official explanation of module stability which I can find is at https://swift.org/blog/abi-stability-and-more/ which talks about the ability to "mix versions". There is no mention of any restriction around backwards or forwards compatibility. Indeed, it specifically states that with module stability "clients can use a module without having to care what compiler it was built with" - this would seem to not be the case.
Having had a further dig into this I can see a more nuanced discussion about backwards-compatibility at https://forums.swift.org/t/plan-for-module-stability/14551 but this is not explained anywhere in any of the official sources. We don't seem to be the only ones taken by surprise on this... (Especially as there is no compiler errors or warnings, just an obscure dyld crash).
I was directed to this answer by Developer Technical Support (DTS) in response to a question I asked about an issue we're seeing with our binary framework when we compile it with Xcode 12.5 but then it is linked by our clients against Xcode <12.5 which results in a crash on launch:
dyld: Symbol not found: __ZN5swift34swift50override_conformsToProtocolEPKNS_14TargetMetadataINS_9InProcessEEEPKNS_24TargetProtocolDescriptorIS1_EEPFPKNS_18TargetWitnessTableIS1_EES4_S8_E
In this case, we actually don't get this warning, everything compiles fine until the app crashes on launch with the above (rather unilluminating!) error. We also found this issue only seems to impact Xcode 12.5, so it seems to be an Xcode 12.5 vs Xcode <12.5 issue, rather than Xcode 12 vs Xcode 13.
There appear to be a number of other frameworks affected by this issue in Xcode 12.5. I also have a question on StackOverflow about this.
@edford can you elaborate a little on the expected behaviours around module/binary stability and what's going on here under-the-hood? This took us (and our customers) a little by surprise as we had expected that our framework would continue to be both forwards and backwards compatible as it has been until now.