-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.2.34 and newer are incompatible with ably-asset-tracking-swift #2003
Comments
Hi @p0wl, Thank you for reporting this! We are investigating this internally and will get back to you soon. |
lawrence-forooghian
added a commit
that referenced
this issue
Jan 16, 2025
That change, which moved the `presence` property from the ARTRealtimeChannel class to ARTRealtimeChannelProtocol, changed the type of the property from ARTRealtimePresence to id<ARTRealtimePresenceProtocol>. This is a breaking change for anybody who was relying on the property returning the concrete type, one such example being our Asset Tracking SDK. So, we undo it. The change made in 26d9bf7 was triggered by us noticing, whilst working on the Chat SDK — which does its best to avoid referring to ably-cocoa's concrete types — that when you have an ably-cocoa concrete type ConcreteA which implements a protocol ProtocolA, and where ConcreteA has a public method or property `someMethod` which returns an instance of another concrete type ConcreteB which happens to implement a protocol ConcreteB, then `someMethod` is always defined directly on ConcreteA, not on ProtocolA. We wondered "why can't these properties be on ProtocolA instead?", hence 26d9bf7. But the first reason is that we can't because in order to do this it makes sense for you to also change the the return type of `someMethod` from ConcreteB to ProtocolB, which is a breaking change as we've seen here. But also I'm not sure whether it'd work even if we accepted the breaking change; for example, I don't know if you can mark a protocol as Sendable in Objective-C (haven't looked into it since we currently have no intention of making the breaking change, but one to investigate if we consider it in the future). Resolves #2003.
lawrence-forooghian
added a commit
that referenced
this issue
Jan 16, 2025
That change, which moved the `presence` property from the ARTRealtimeChannel class to ARTRealtimeChannelProtocol, changed the type of the property from ARTRealtimePresence to id<ARTRealtimePresenceProtocol>. This is a breaking change for anybody who was relying on the property returning the concrete type, one such example being our Asset Tracking SDK. So, we undo it. The change made in 26d9bf7 was triggered by us noticing, whilst working on the Chat SDK — which does its best to avoid referring to ably-cocoa's concrete types — that when you have an ably-cocoa concrete type ConcreteA which implements a protocol ProtocolA, and where ConcreteA has a public method or property `someMethod` which returns an instance of another concrete type ConcreteB which happens to implement a protocol ConcreteB, then `someMethod` is always defined directly on ConcreteA, not on ProtocolA. We wondered "why can't these methods be on ProtocolA instead?", hence 26d9bf7. But the first reason is that we can't because in order to do this it makes sense for you to also change the the return type of `someMethod` from ConcreteB to ProtocolB, which is a breaking change as we've seen here. But also I'm not sure whether it'd work even if we accepted the breaking change; for example, I don't know if you can mark a protocol as Sendable in Objective-C (haven't looked into it since we currently have no intention of making the breaking change, but one to investigate if we consider it in the future). Resolves #2003.
Thank you for the fast fix! We'll update to 1.2.37 and report back if it doesn't work :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Which version of the Ably SDK are you using?
1.2.34
On which platform does the issue happen?
iOS17
Which version of Xcode are you using?
Xcode 15.3
What did you do?
After updating the ably-cocoa package to 1.2.35 or 1.2.34, we cannot build our iOS App anymore, as it is using the ably-asset-tracking-swift SDK as well and ably-asset-tracking-swift has not been updated to be compatible with the changes that were introduced in #1995
The build fails with:
┆Issue is synchronized with this Jira Task by Unito
The text was updated successfully, but these errors were encountered: