AzureCommunicationCalling: Guidelines Exceptions and Release Blockers

[tjprescott]

These are the current deviations AzureCommunicationCalling has from the guidelines.

Blocking for AzureCommunicationCalling 2.6.0

• Support M1 processors ($ARCH_STANDARD (arm64))
• MediaDiagnosticsDelegate and NetworkDiagnosticsDelegate methods should not end in *Value. link

Blocking for AzureCommunicationCalling 2.7.0

• SwiftPM support for AzureCommunicationCalling
• RecordingInfo must expose some kind of recording ID
• Deprecate onIsRecordingActiveChanged (tied to RecordingInfo?)
• AudioOptions.muted was deprecated in 2.5.1 but is "un-deprecated" in 2.6.0-beta.1 link
• Call.add event is not in CallBase, whereas all other event methods were moved there in 2.6.0-beta.1 link
• CallBase.applyOutgoingVideo(constraints:) is a non-standard name. Need resolution on final name before GA. link
• DataChannelReceiveDelegate must follow camelCase conventions. Currently they are using PascalCase. Also the names dataChannelReceiver(_:messageReady) should be re-evaluated prior to GA as it is non-standard. link

Blocking for AzureCommunicationCalling 3.0.0:

• APIGen should support generating properties as write-once (Swift equivalent of let) in order to adhere to guidelines surrounding immutability of clients.
• Resolve issue where id types are sometimes bridged to type Any or Any! depending on whether the referenced type is part of Calling or a dependency.
• Support API version (Calling: should support setting APIVersion #1225)
• Resolve issues with isMuted and isSpeakerMuted
• Remove the init(outgoingVideoStreams:) initializer
• enums should all be extensible enums

[raosanat]

SwiftPM support for AzureCommunicationCalling

This is a Swift PM limitation.

1. Binary framework written in ObjC A imports another Swift package B.
2. Swift application imports both A and B using Swift PM fails as Swift PM does not copy the bridging header file of B so that A can find it.

Possible solutions:

1. Investigate more if there is some work around we can do in Swift PM so that things work as it is.
2. If above does not work then write a Swift wrapper on top of A which interact with B. This is just a theory at the moment and we have to see if this is viable at all or not.

Support $ARCH_STANDARD (arm64)

We will look into this , it could also be an issue with Cocoapods.

Support BITCODE enabled

This is a much bigger work item. We have to coordinate with different teams who produce the library we consume to first build with BITCODE enabled before we can enabled it. Teams SDK is also shipped at the moment with BITCODE disabled.

[raosanat]

So regarding the following blocking topics for 2.2.0

>> SwiftPM support for AzureCommunicationCalling
The problem seems to be in SwiftPM since we depend on AzureCommunicationCommon which is open source we rely on SwiftPM to compile it and install the ObjC header which is missing in SwiftPM. Posted in Swift forum here as discussed with @tjprescott

https://forums.swift.org/t/swift-pm-support-for-binary-packages-which-depends-on-another-open-source-package/57482

>> Support M1 processors ($ARCH_STANDARD (arm64))
We investigated this and we do partially support M1 but local preview of video had to be disabled also the CallKit framework on Mac M1 is not working properly. This is how we got it to work

1. Disable CallKit before creating CallAgent on M1. CallKit on M1 is not working as expected.
2. Join a group call with Video disabled. I was able to join the group call with M1 with Audio only and I was able to see remote participant video and Audio was flowing fine.
3. Turning on local video crashes, we are looking at this issue why this happens.

So there is iOS CallKit framework also not working as expected on M1 currently along with our video related issue. We will start working on it next quarter. Officially we do not support running our framework on Mac yet.

>> Support bitcode enabled
This is a much bigger work and we need cross team collaboration on this. We cant address this until we get support from them.

>> All current delegates in Calling must also expose Closures as an alternate means of handling events. Delegates are considered optional. Closures are required. (okay if this is released as a beta and then should not block).

This will be delivered and we have already implemented this.

[Sherlouk]

Wondering if there is any update on the SwiftPM situation? We've seen that Firebase have overcome similar (though maybe not identical) problems. Our project is exclusively on SwiftPM.

[raosanat]

Wondering if there is any update on the SwiftPM situation? 

@Sherlouk we have a unique setup mainly because of the share common open-source project written in Swift. I have tried the way that Firebase did with a wrapper but does not help. We need a flag to be passed when Swift Code is built to install the bridging header file, which at the moment is hardcoded in Swift PM. The long term solution here is write a Swift projection instead.

@tjprescott regarding the bitcode support looks like its deprecated in Xcode 14. Can we remove it from the blockers list ?

Deprecations
Starting with Xcode 14, bitcode is no longer required for watchOS and tvOS applications, and the App Store no longer accepts bitcode submissions from Xcode 14.
Xcode no longer builds bitcode by default and generates a warning message if a project explicitly enables bitcode: “Building with bitcode is deprecated. Please update your project and/or target settings to disable bitcode.” The capability to build with bitcode will be removed in a future Xcode release. IPAs that contain bitcode will have the bitcode stripped before being submitted to the App Store. Debug symbols for past bitcode submissions remain available for download. (86118779)

Xcode 14 Release Notes | Apple Developer Documentation
Apple Developer Documentation

[tjprescott]

Yes, I removed that item.

[github-actions]

Hi @tjprescott, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.