A prebuilt calling interface can disappear without taking the underlying media service with it. That is the position ACS customers now face: Microsoft's retirement guide lists the Azure Communication Services Web and Mobile UI Library SDKs among the retired services and SDKs, while the underlying Calling SDK remains a separate part of the ACS story.
The Microsoft retirement and breaking-changes guide says the ACS UI Library will no longer be available after September 30, 2028. The same guide names no replacement for the UI Library. That wording matters. It does not establish that no partner or third-party option exists; it tells you that Microsoft has not named a replacement in its current guidance.
The practical consequence is a product decision. Your application can continue using the existing library during the wind-down, or you can take ownership of the call interface before the support boundary arrives. The work is larger than changing a few buttons because the library sat between your product and the Calling SDK's device, participant, lifecycle, and accessibility details.
The trade-off between a prebuilt UI kit and a headless SDK, and what each costs later, is priced in the guide to embed video options. For ACS teams, the retirement makes the headless side of that trade-off compulsory.
What Microsoft is retiring
The retirement applies to the ACS UI Library for web and mobile. Microsoft's overview describes the library as a set of production-ready UI components that developers could add to their applications. The retirement guide separately lists the Web UI Library SDK and Mobile UI Library SDK under retired services and SDKs.
This is a UI-layer retirement. It does not mean that every ACS calling capability disappears on the same date. The Calling SDK and the UI Library are different layers, so a team can still use the Calling SDK as the media and call-control foundation while replacing the interface that presents those capabilities to users.
Existing UI Library workloads remain available during the transition period. Support is limited to stability, security, compliance, and critical problems that block normal usage. Microsoft does not plan new features, UI modernisation, or proactive dependency upgrades during that period, so the interface may continue to work while becoming increasingly difficult to evolve safely.
That support boundary turns the retirement date into an engineering deadline, rather than a date to discover a broken application.
What the UI Library was doing for your product
The easiest way to underestimate this migration is to think of the UI Library as visual decoration. Its documented mobile CallComposite included a pre-call experience for configuring default audio and video devices, followed by an end-to-end call experience with a defined layout and participant video. Those are product behaviours as well as presentation choices.
A custom replacement therefore needs to make deliberate decisions about at least four areas:
- Device setup: how people choose microphones, cameras, and speakers before joining, and what happens when permission is denied or a device cannot be read.
- Call presentation: how local and remote participants appear, how the layout changes as participants or media states change, and how speaker-related information is surfaced.
- Call state: how the product represents setup, waiting, joining, active calls, disconnection, call ending, and rejoining.
- Accessibility: how keyboard users, screen-reader users, users who zoom the interface, and users who rely on clear control labels operate the call.
This is the rebuild surface relevant to the retirement. It is not a complete inventory of every Web, iOS, and Android component or edge case that the UI Library may have supported.
First responsibility: devices and permissions
A custom call screen has to earn access to the user's devices before it can offer a reliable call experience. Microsoft's device and permission guidance explains that the Calling SDK requires browser and system permissions for audio and video devices. An application can use DeviceManager.askDevicePermission to trigger the permission prompt, and detailed device-list information also depends on permission.
That creates several states your UI must represent clearly:
- The user has granted microphone and camera access.
- The user has denied one or both permissions.
- The browser or operating system has blocked access.
- The application cannot show detailed device information yet.
- The selected device is unavailable when the call begins or changes during use.
The Calling SDK gives you the mechanism. Your product still has to provide the explanation, retry path, device controls, and failure state. A permission prompt alone is not a device experience.
Once devices are available, the next problem is deciding how people and media should occupy the call surface.
Second responsibility: layout and speaker state
The UI Library overview describes the mobile CallComposite as providing a clean layout and participant video. Rebuilding that experience means defining how the interface behaves as the call changes, rather than drawing a fixed grid and hoping it remains usable.
The Calling SDK exposes an isSpeaking boolean for remote participants. Microsoft's call-management documentation establishes the available speaker-state input, while the UI Library changelog records Speaker Mode and visual speaker-state behaviour in the video gallery. Your replacement must decide how that input affects presentation: whether the current speaker receives visual emphasis, how the local preview is handled, and what happens when several participants speak or nobody is speaking.
Those decisions should be explicit because the Calling SDK does not prescribe one universal active-speaker algorithm for every product. The SDK provides state; the application owns the presentation and the interaction model.
Third responsibility: lifecycle and reconnection states
A call interface is also a state machine. Microsoft's calling-widget tutorial models waiting, setup, and in-call states around the CallComposite. The UI Library changelog records additional behaviours involving disconnecting, call-ended, hold, and rejoining states.
A product-owned interface should make those states visible and actionable. At minimum, the user needs to understand whether the application is preparing to join, waiting for the call to begin, connected, attempting to recover, ending the call, or ready to rejoin. The exact screens depend on the product, but the responsibility does not disappear when the prebuilt component does.
Reconnection deserves particular care. A user who sees a frozen layout cannot tell whether the other participant stopped sending media, the network changed, or the application is recovering. The UI needs a coherent status message and a defined next action, even when the underlying SDK supplies only events and state changes.
Lifecycle handling is where a replacement stops being a visual exercise and becomes part of the product's reliability model.
Fourth responsibility: accessibility and localisation
Microsoft described the UI Library as being developed with usability, accessibility, and localisation in mind. The UI Library theming documentation and its associated changelog record work involving keyboard navigation, ARIA roles, screen-reader announcements, high-contrast borders, 400% zoom and reflow, and device-control labelling.
Those examples show the kind of engineering detail that a custom interface inherits. A replacement needs semantic controls, predictable focus movement, announcements for important state changes, usable contrast, layouts that survive zoom, and labels that make device controls understandable. It also needs a plan for translated labels and messages if the existing product serves more than one language.
The documentation supports accessibility as a responsibility, but it is not a complete WCAG conformance statement. Treat it as a rebuild workstream that requires testing with assistive technologies, rather than as a checklist that can be closed by copying the old visual design.
What to do during the transition
The recommended path is to build a product-owned UI against the Calling SDK and begin with an inventory of the behaviours your current product actually uses. Record the join flow, device setup, participant presentation, speaker treatment, call controls, lifecycle states, error messages, keyboard paths, screen-reader announcements, and localisation requirements. Then implement and test those responsibilities in that order.
A fork can provide continuity when the existing UI Library is close to the product you need. Microsoft says customers who need ongoing evolution or dependency modernisation can fork and maintain the library independently. That makes a fork a bridge for preserving a known interface; it also transfers dependency, compatibility, security, and maintenance responsibility to your team. It should not be treated as a Microsoft-supported replacement product.
The limit is equally important: rebuilding the interface does not remove the need to review the Calling SDK's own lifecycle, permissions, browser, mobile-platform, and release behaviour. The UI Library retirement changes who owns the presentation layer. It does not turn the Calling SDK into a complete application interface.
Bottom Line
Microsoft's current retirement guide names no replacement for the ACS UI Library, and the Web and Mobile SDKs are scheduled to leave availability after September 30, 2028. The durable response is to own the call UI and build it against the Calling SDK, with a fork used only when short-term continuity is more valuable than long-term control.
The work covers device permissions, layout and speaker state, lifecycle and recovery states, and accessibility. Starting with those responsibilities gives the migration a concrete shape before the support window narrows.
What's Next
Owning the UI answers how the product continues to function, but it does not answer whether the remaining ACS Calling path still fits the commercial model. The Teams licensing analysis works through what staying on the ACS Calling path actually costs.
FAQs
When will the ACS UI Library be retired?
The ACS Web and Mobile UI Library SDKs will no longer be available after September 30, 2028. Existing workloads remain available during the transition, with support focused on stability, security, compliance, and critical problems that block normal usage.
Does ACS UI Library retirement mean the Calling SDK is also retired?
No. Microsoft's retirement guide lists the UI Library SDKs separately from the underlying Calling SDK. A team can use the Calling SDK as the foundation for a product-owned interface, subject to the separate support and product decisions that apply to that SDK.
Does Microsoft provide a replacement for the ACS UI Library?
Microsoft's current retirement guide names no replacement for the Web and Mobile UI Library. That statement describes Microsoft's published guidance; it does not establish that no third-party or partner option exists.
What has to be rebuilt when the ACS UI Library retires?
The main responsibilities include device setup and permission handling, participant and speaker presentation, call lifecycle states, recovery and rejoining behaviour, and accessibility. The Calling SDK supplies relevant controls and state, while your application owns the screens, explanations, interaction rules, and testing.
Can an ACS customer fork the UI Library?
Yes, Microsoft says customers who need ongoing evolution or dependency modernisation can fork and maintain the library independently. A fork can preserve continuity, but your team then owns its dependencies, compatibility, security fixes, and future changes.
Is rebuilding the ACS UI Library a small frontend change?
It should be planned as a product workstream rather than a styling update. The documented device, layout, call-state, and accessibility responsibilities reach into permissions, asynchronous events, recovery states, assistive-technology behaviour, and platform-specific testing.
