As mentioned in a few threads, @richard1 and I are the developers of the ZoomOSC application, hence our regular use of this forum! I am going to try to summarize the learnings from the many posts we’ve made recently.
I think it is fair to say that while this latest SDK release has brought some important features, there have been a series of very troubling bugs that make it hard for us to meet our deadlines and deliver a functional and platform-coherent application to our customers:
As we understand it, the current and most urgent issues are:
Video filter and virtual background controls are not functional together on Windows and macOS SDKs. On Windows, users get SDK Success for calling a change but the background does not change. MacOS sees the same behaviors on video filter setting.
Active Speaker is reporting the wrong user. This is extra troublesome for us because reporting this is a central feature of our app, and the functionality will need to be removed in the next update because of this.
Audio Events do not fire on Windows. I am currently getting around this by checking audio status on all users every program loop, but that should not be needed.
Breakout room controls are completely broken on the mac, and spotty at best on Windows.
Chat All does not appear to be working
Raising hands is broken at least on macOS
And then there are some weird things, such as new interfaces for multipinning promoted in this SDK, yet multipinning is not supported in all of the use cases that the SDK calls suggest. Also, now that the order of the gallery view can be changed by the users, we really do need a platform-agnostic way of getting the order of those users. Finally, the documentation for using the SDK needs a serious reworking, particularly in the area of code-signing. The existing documentation is wrong, and my team should not have to spend countless hours trying to figure it out from scratch (but we are always happy to share the results!).
I know that the SDK is an up and coming priority for Zoom, and the great community management and responsiveness from the team here on the forum recently is great evidence of that! Unfortunately, it is hard to build an app on this platform in its current state, especially when I need to eat my words to my own customers on features that will now not be available in our app because their SDK underpinnings are bugged beyond use. A timely hotfix for the SDK on all platforms is the first step in fixing this difficult scenario.
All this said, I am optimistic for the future of this SDK and the apps we are making for it! And as Richard said recently, we are more than happy to share Liminal’s internal validation tools to the SDK team to help with testing, or to give prompt feedback on beta builds of the SDK.
Let’s work together to get this SDK up to task and deliver great functionality to our combined customer base!
Hi @liminal_andy, thank you for the detailed and thoughtful feedback.
First off, I want to assure you that all of the issues you have mentioned in this post either are already being worked on or will be investigated in the near future. We do realize that some of these bugs are dwarfed by larger issues you have mentioned in this post.
As far as documentation goes, our desktop SDKs are probably the weakest point out of all of our developer docs at the moment. We are fully aware of the impact that this shortcoming has on developers new to the platform as well as those who have been using the SDKs for some time. The current state of this is not acceptable to us and we are actively working on increasing both the quality and quantity of our client SDK documentation. I cannot promise a precise timeline on these improvements, but I expect this to be a long process due to the wide scope of functionality that each SDK encompasses.
I know that the SDK is an up and coming priority for Zoom, and the great community management and responsiveness from the team here on the forum recently is great evidence of that!
We’re happy to hear that our recent increase in efforts towards the SDK platform has been noticed!
Unfortunately, it is hard to build an app on this platform in its current state
We completely understand where you are coming from on this note. In addition our SDK engineers who are constantly working tirelessly on improving the SDK, we have experienced engineers implementing our SDKs every day. We have been in your position. We know how difficult it is to figure out how to implement some of the more complex features in the desktop SDKs without extensive documentation. The plans for improving the documentation will help with this, but we also hope to make improvements to the SDKs themselves to make the developer experience the best that it can be. If you haven’t seen/taken it already, one of our efforts towards improving the SDKs is the developer survey. We always love hearing feedback on the forums, but providing meaningful feedback through this survey can help ensure that your experiences with the SDK are seen by as many people internal to Zoom as possible.
And as Richard said recently, we are more than happy to share Liminal’s internal validation tools to the SDK team to help with testing, or to give prompt feedback on beta builds of the SDK.
We are extremely appreciative of this offer! I cannot commit to anything on this front since we do not currently have any beta programs for the SDK. The best I can do is tell you that we will consider and discuss this internally.
Thank you again for the immensely helpful feedback! We are grateful to have people like you in our developer community and hope our future changes to the SDK provide the great experience you deserve!
Just to bump this post up, it would be great to understand when to expect an updated SDK which fixes these issues, I’ve added below some additional key broken features in the macOS SDK which we really could do with seeing fixed asap…
(void)onSpotlightVideoUserChange:(BOOL)spotlight User:(unsigned int)userID
Fails with multi spotlight use
Video filters and backgrounds only available in app when user logged in
Historically, we have tried to keep up with hotfix releases whenever critical bugs are identified in a release. Earlier this week, we released such a version of the SDK which was solely focused on user reported bugs/missing information.
Regarding the two issues you have mentioned, I know that the spotlight issue already has another thread and is already being tracked internally.
Can you please elaborate on the virtual backgrounds issue? I am able to correctly apply virtual backgrounds through the default UI without logging in.
Thanks and apologies - I hadn’t seen the new update (have now subscribed so will hopefully get an email!
The filters/backgrounds issue is one discussed in another thread - for some reason the standard zoom backgrounds and filters are not available to an SDK app unless the user is logged in to zoom, which isn’t great. I am assuming this is not deliberate!
We will have a go with the new SDK next week as we are hoping to get a release out this weekend and don’t have time to test before that.
No worries on the updates! We are always open to hearing feedback on how new releases are communicated, so if you have any suggestions that would be great!
Regarding the virtual background issue, that is currently how they work in the Zoom client. Since SDK behavior is inherited from the client, we would not be able to change that on the SDK at this time unfortunately.
Hopefully the latest SDK release is a better experience than the last one. Definitely let me know if you encounter any issues and I will do my best to help.
Thanks Jon - I’ve just done a test and we both appear to be half correct. On the mac client when I join a meeting without logging in I don’t see any backgrounds but I do have the full complement of filters. Not sure why this is the case on either platform.
You are correct that the filters are available without logging in, however I am seeing the same behavior in the SDK. Unfortunately I do not have insight on why this behavior was implemented in the client. If you would like, you are more than welcome to request a change to this behavior in the client here.
