Skip to content
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

Closed
p0wl opened this issue Jan 7, 2025 · 2 comments · Fixed by #2015
Closed

1.2.34 and newer are incompatible with ably-asset-tracking-swift #2003

p0wl opened this issue Jan 7, 2025 · 2 comments · Fixed by #2015
Assignees

Comments

@p0wl
Copy link

p0wl commented Jan 7, 2025

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:

Failed to execute Step: command failed with exit status 65 (xcodebuild "-project" "/Users/vagrant/git/Project.xcodeproj" "-scheme" "Project Development" "test" "-destination" "id=..." "-resultBundlePath" "/var/folders/7l/.../T/XCUITestOutput236194744/Test-Project Development.xcresult" "-xcconfig" "/var/folders/7l/.../T/.../temp.xcconfig"): /Users/vagrant/Library/Developer/Xcode/DerivedData/Project-.../SourcePackages/checkouts/ably-asset-tracking-swift/Sources/AblyAssetTrackingInternal/AblyWrapper/SDK/AblyCocoaSDK.swift:41:56: error: cannot convert value of type 'any ARTRealtimePresenceProtocol' to expected argument type 'ARTRealtimePresence' (exit code: 1)

┆Issue is synchronized with this Jira Task by Unito

@ttypic
Copy link
Contributor

ttypic commented Jan 16, 2025

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.
@lawrence-forooghian lawrence-forooghian self-assigned this Jan 16, 2025
@p0wl
Copy link
Author

p0wl commented Jan 17, 2025

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
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants