Custom Zoom App added for local testing is absent from Zoom desktop client on Windows

Zoom Apps
1

Zoom Apps Configuration
ASP.NET, but I don’t think it’s relevant yet.

Description
I’ve reviewed the Create a Zoom App instructions, enabled developer tools, tried setting Admin-managed and User-managed both ways, added the surfaces “Meetings”, “Webinars”, and “Rooms”, ensured that the zoomapp:inmeeting and zoomapp:inwebinar scopes are added and have custom justifications, and used the Local Test section to add the app to my account for both Development and Production. But when I open the Apps pane in the Windows desktop client while signed in to the same account, I don’t see my app anywhere in the list. I also tried adding the official Timer app to Added Apps alongside my custom app to ensure I’m using the correct account, and I see that app show up. I used the webview’s developer tools to see the Apps pane make the following request and get the response that shows only the Timer app:

https://marketplace.zoom.us/api/v1/zoomapp/my?pageSize=100&sort=name_asc

{
    "essentialApps": [],
    "noAuthAppList": [],
    "items": [
        {
            "id": "IIrusMA1QSmLBMcPxhDJnw",
            "displayName": "Timer",
            "icon": "https://marketplacecontent.zoom.us//xOS7J3MRStCHf3D-Pgt5cA/-BJ3w5Q3Rf2VRMxZzu8EfA/app/pR61TxyXQGCBKSdfInJhSQ/dSOUPXMfSgGLVicw56AYqg.png",
            "companyName": "Zoom",
            "applicationId": "cXw5IXmqT6SIIBQxgM_PfQ",
            "description": "Keep control of your workday with the Timer App. Timer enables you to set timers, screenshare timers, and ensure your meeting isn't going overboard.",
            "supportTransferZoomRoom": false,
            "supportInCurrentDevice": true,
            "supportTouchDevice": false,
            "essentialApp": false,
            "shareLink": "https://marketplace.zoom.us/apps/cXw5IXmqT6SIIBQxgM_PfQ"
        }
    ],
    "extMap": {
        "essentialAppIntroduction": "Apps in this bundle have paid features that are available for free for Pro, Business and Business+ accounts. <a href=\"https://explore.zoom.us/en/zoom-apps/essential-app-bundle/upgrade/\" target=\"_blank\" style=\"text-align: right\">Learn More</a>"
    }
}

I thought I’d try an old troubleshooting tip to review the installation privileges for the Timer app and my custom app, but that page appears to be missing scope names now.

I’ve confirmed that my app can redirect to Zoom to authorize the app (I see a code returned in the URL).

I did notice some potential signs of service interruption when I was first filling in the app information — when I first got to the scopes step, I didn’t see either of the zoomapp:inmeeting and zoomapp:inwebinar scopes prepopulated in that step, and when I opened the picker to add them manually, they didn’t show up in a search, nor did the Zoom Apps category appear. Some time later, I changed between Admin-managed and User-managed, picked the surfaces again, and then I saw zoomapp:inmeeting prepopulated, and then I manually added zoomapp:inwebinar.

This app is currently intended to be a static web page (a panic button for hosts to see organization-specific instructions on how to deal with disruptive attendees), so the only scopes it declares are zoomapp:inmeeting and zoomapp:inwebinar.

Error?
No observed error message.

Troubleshooting Routes
I’ve tried removing and adding the app again to my account, and adding it for both Apps in Production and Apps in Development in the Added Apps page.

How To Reproduce
This is probably account-specific, but launch the Zoom desktop client for Windows, sign in using the developer user that owns the app, host a meeting using the Personal Meeting ID, use the meeting controls to open the Apps pane, and look for the absence of the custom app in the My Apps section.

2

Turns out that the missing requirement for the app to appear is that a Home URL is specified — having just an OAuth Redirect URL is not enough.

3

There’s a more subtle problem with the listed apps when there is a mismatch between the Zoom desktop client’s signed-in user and the host user that is running the meeting. Steps to replicate:

  1. Launch Windows Sandbox for a fresh system.
  2. Transfer and run ZoomInstallerFull.exe (the Zoom Desktop Client) in the sandbox to install version 5.17.10 (33775).
  3. In the Zoom client, click Sign in and enter your developer user credentials.
  4. Click the Apps toolbar icon and confirm that you see your added apps (for the signed-in user).
  5. In Microsoft Edge, navigate to the Zoom sign in page and sign in with another user that is part of the same account.
  6. In the Meetings section, switch to the Personal Room tab and click Start.
  7. If prompted by the web browser, allow the Zoom client to open.
  8. In the Zoom client meeting controls, click Apps to observe that no added apps are listed (for the host or the signed-in user). (This is the unexpected behavior.)
  9. Switch to the main window of the Zoom client, open the account menu, and click Sign Out.
  10. Switch back to the meeting window of the Zoom client and in the meeting controls, click Apps to observe that added apps are listed now (for the host).

We use a dedicated Zoom user for webinars that is separate from the host’s personal Zoom user, so we can’t rely on the two users involved to be the same. We’re trying to pin a private Zoom App in the user interface so that the host can quickly refer to it for guidance during a sudden meeting attendee disruption. What other ways can we make a Zoom App easy to launch for the host?

4

For cross-referencing purposes, we’ve opened a customer support case TS0720571 to report the apps list being empty for the host if the Zoom client has a different user signed in.

5

Do the windows support third party apps with extended features? Does zoom support such apps?

6

I’m glad that you were able to identify the issue here! The Home URL lets us know where your app lives and what page to open when the user opens the app.

This currently expected behavior but I have reached out to our PMs to let them know that it would benefit developers greatly to support a separate meeting host and signed in account.

7

Thanks for clarifying that multi-user scenarios aren’t supported at the moment; implementing this can be tricky — Windows added Universal Windows Platform belated support for multi-user applications to support Xbox consoles and Surface Hub, and it resulted in massive API surface duplication to accept either an unspecified traditional single user workflow and an explicit specified user workflow.

We were considering using the App Dock as a possible application launcher, but it looks like that user interface has been revamped and is now actually the official name for the pane that appears when clicking Apps in the meeting controls or webinar controls.

We looked at the app deeplink API (overview of app deeplinking), but it suffers from the same out-of-workflow discoverability hurdles and requires a web browser window interstitial.

Most likely, we’ll end up emailing a link to the person that’s hosting, and maintain a Zoom App equivalent as a nice-to-have option if it happens to be discoverable via that Zoom client user interface, but try to steer them away from Zoom Apps because they can’t count on the host’s added applications being shown reliably, and asking them to sign out of the desktop client or sign in redundantly as the same host user seems undesirable or unlikely to be remembered.

8

Thank you for sharing your use case and design considerations here. Of course, we want Zoom Apps to be a first choice when it makes the most sense. I’m working with PMs to see if we can add a per-account flag or another workaround.

9

That per-account flag is intriguing. The scenario that we want to ensure happens is that when the host opens the Apps pane, they see and can quickly launch applications we’ve added for that host (or at least applications that are specifically designed for this scenario), regardless of who is signed in to the desktop client (it could even be a user that isn’t part of our account and hasn’t consented). That might raise privacy concerns, so perhaps only applications that don’t access user information would be eligible.

The only contextual information we might want to retrieve is the current meeting or webinar ID so we can produce a link to its settings page, so the host can quickly reinstate a webinar attendee that was accidentally removed. Aside from that, this application is static content (text, screenshots, links to Zoom Support articles, maybe mailto: hyperlinks for email contact information).