Amplify UI: AWS component library, and the v4 support cliff behind it

The library is four things stacked, not one component set

Amplify UI is described as an open-source UI library with cloud-connected components, and the README splits it into four parts that behave differently. Connected components simplify complex cloud-connected workflows, with the Authenticator as the headline example. Primitive components such as Buttons and Badges create consistency across the library and let you build complete applications that match your brand. Data-bound components display dynamic data, with DataStoreCollections named as the example. Theming capabilities let you customize the appearance to match your brand.

That split determines how much of it you actually need. A team that only wants a design system can take the primitives and the theming layer and ignore the cloud parts entirely. A team that wants authentication done properly takes the Authenticator, which brings the Amplify authentication workflow with it. Treating it as a single package with an all-or-nothing API is a mistake, because the pieces have different dependencies on the rest of the Amplify stack.

The customization story is the reason many teams look at it in the first place. The README says you can style Amplify UI with themes, override components with your own, or build your own UI and use Amplify for complex state management. That last option is the interesting one for a design-led team: take the state handling and leave the pixels alone.

The repository is a monorepo built with turbo and yarn, with separate packages per framework and per domain, so the shape of the source reflects the shape of the published packages.

Only React carries the full primitive set

The component matrix in the README is the single most useful piece of information for an adopter, and it is worth reading closely. The connected components table has columns for React, React Native, Angular and Vue. The Authenticator is the only row with a check in all four. InAppMessagingDisplay is supported in React and React Native. MapView/LocationSearch, Account Settings, StorageBrowser, FileUploader, StorageImage and FaceLivenessDetector are all React only.

The primitives table is shorter and blunter: it has one column, React, and it lists Alert, Autocomplete, Badge, Button, Card, CheckboxField, Collection, Divider, Expander, Flex, Grid, Heading, HighlightMatch, Icon, Image, Link, Loader, Menu, Pagination, PasswordField, PhoneNumberField, Placeholder, RadioGroupField, Rating, ScrollView, SearchField, SelectField, SliderField, StepperField, SwitchField, Table, Tabs, Text, TextAreaField, TextField, ToggleButton, View and VisuallyHidden. That is a substantial design system, and it is a React design system.

So the claim that the library works across frameworks holds for the connected components and largely not for the primitives. A Vue or Angular team gets the Authenticator and little else from the primitive column. React Native gets the Authenticator and InAppMessagingDisplay, and no primitives at all, which is a meaningful gap if you were expecting parity.

There is also a Svelte package in the release feed, at version 1.1.7 on 2026-10-02, and a svelte/ example directory in the repository, but the component matrix does not cover Svelte, so its parity is not documented. The package set in the monorepo is broader still, with workspaces for react-core, react-ai, react-geo, react-liveness, react-notifications, react-storage, test-utils, ui and svelte.

Accessibility is a stated goal with a stated basis

The README lists accessibility among the major benefits and grounds it in specific standards: the components follow WCAG and WAI-ARIA best practices and guidelines, and it names colour contrast, keyboard navigation, accessible labels and focus management as the areas covered. The component list itself supports the claim, with VisuallyHidden, a dedicated SkipLink-style primitive, plus form primitives such as PasswordField, PhoneNumberField and SelectField that are the places where labels and focus usually go wrong.

The reason to care is that connected components are exactly where accessibility regresses. A custom sign-in form is where keyboard traps and missing labels appear, and the value of a shared Authenticator is that a single implementation of that flow is fixed once instead of once per project.

Two things are worth being careful about. The claim is scoped to WCAG and WAI-ARIA guidance, not to a specific conformance level, so if your procurement process requires a formal accessibility audit or a VPAT, the README does not provide one. And accessibility conformance is a property of the composed page as much as of the components, so a themed override that changes contrast or focus styling can reintroduce the problems the primitives were careful about.

Building the monorepo locally is a yarn and turbo exercise

For consumers, the packages are on npm and the documentation site covers installation. For contributors, the repository's own scripts show the shape of the build. The root package.json is private, named @aws-amplify/ui-monorepo, and pins the package manager to [email protected], which is worth noting since it is Yarn Classic rather than the modern Berry release. The setup script installs and builds in one step.

yarn install && yarn build

That is the full local setup: dependencies installed, then every package built. The build script itself runs turbo with a filter that covers the packages directory while excluding the angular package and including its project path separately, so the Angular workspace is handled as a special case rather than built with the rest.

yarn build

yarn test

The second block is the build on its own and the third runs the test suites through turbo with the same filter shape. Other scripts follow the same pattern: lint, size and clean each target the package set, and clean also removes node_modules with rimraf. There is a refresh script that combines clean and setup, and a set of per-package shortcuts such as react, vue, svelte and angular, each of which runs yarn workspace against the matching workspace name, so you can work inside one package without the full turbo filter syntax.

yarn workspace @aws-amplify/ui-react

The example applications in the examples/ directory, including next-app-router, react-router, vue, angular, svelte and react-native, are the practical way to see the components running rather than reading the source.

The v4 dependency timeline is a hard boundary, not a warning

The version support section is the most consequential paragraph in the README for anyone evaluating adoption. AWS Amplify UI libraries for React, React Native, Angular and Vue that depend on AWS Amplify JavaScript library v4 and below will end support on April 13, 2026, as documented in the project's version support calendar. The same section says that, effective immediately, those libraries entered Maintenance Mode until that date, after which they receive no more updates, and that during Maintenance Mode they only receive updates for critical bug fixes and security vulnerabilities.

The consequence is concrete. If your application resolves to an Amplify JavaScript v4-era UI library, that line of the package tree is now frozen, and the README strongly recommends upgrading to the latest AWS Amplify UI library before April 13, 2026. Since that date has passed, the recommendation has already expired for anyone still on the old line.

This is also why the release feed matters. The recent releases are @aws-amplify/ui at 6.15.7, @aws-amplify/ui-vue at 4.4.7 and @aws-amplify/ui-svelte at 1.1.7, all published on 2026-10-02, and the last push was on 2026-10-19, so the current line is moving. The split is between the actively released current packages and the v4-era line, and the boundary between them is a dependency version rather than a package name.

The practical check for an adopter is therefore not the version of the UI library but the version of the Amplify JavaScript library it pulls in, and whether that dependency resolves to the supported or the frozen line.

Apache-2.0, a NOTICE file, and a monorepo with many published packages

The licence is Apache-2.0, which is permissive and widely used for AWS open source. You may use, modify and redistribute the code, including in commercial products, and you may patent-license contributions you receive, provided you keep the licence text, the NOTICE file and the required notices. The repository has both a LICENSE file and a NOTICE file at the root, which is the standard Apache-2.0 pairing. This is a licensing fact rather than legal advice.

The published surface is wide. The README's download table lists @aws-amplify/ui-react, @aws-amplify/ui-vue and @aws-amplify/ui-angular as the flagship npm packages, and the monorepo workspaces add @aws-amplify/ui, @aws-amplify/ui-svelte, @aws-amplify/ui-react-ai, @aws-amplify/ui-react-core, @aws-amplify/ui-react-core-notifications, @aws-amplify/ui-react-geo, @aws-amplify/ui-react-liveness, @aws-amplify/ui-react-notifications, @aws-amplify/ui-react-storage and @aws-amplify/ui-test-utils. The presence of separate liveness, geo and storage packages tells you the connected components are split so that you only pull in the cloud services you actually use, which keeps bundle size down.

The repository also carries the tooling a large project needs: a .changeset directory for release notes, husky and lint-staged for commit hooks, prettier configuration, an .nvmrc pinning the Node version, a turbo.json for the build pipeline, and a docs/ directory that is also the published documentation site, ui.docs.amplify.aws. The .changeset setup is the part that matters for you as a consumer, because it means each published version has a changelog entry you can read before upgrading.

Where the alternative approach differs: build the flow, keep the tokens

The realistic alternative is to use a generic component library for the interface and write the sign-in and data flows yourself against the Amplify JavaScript client. The difference in approach is that Amplify UI ships the workflow, not only the widget. The connected components are described as being written with framework-specific implementations so that they follow framework conventions and are easier to integrate, and the README states plainly that you can build your own UI and use Amplify for complex state management.

That last option is the real alternative inside Amplify UI itself. If your design system already exists and your team is strong on front-end, the primitives plus the state layer can be a better fit than adopting someone else's Authenticator markup, which you would then spend time restyling anyway. The cost of that path is that authentication flows are exactly where the edge cases live, and you inherit them.

The other alternative is a different connected-components library with its own cloud coupling, but the trade there is straightforward: you gain a different framework's conventions and lose the direct relationship with the Amplify services the components are built around. The repository's own package split is a fair model of the difference. Amplify UI ships liveness detection, geo, storage and notifications as separate packages, and each is written against a specific Amplify service rather than a generic backend.

Whichever way you go, the connected components are where the coupling to AWS lives, and the primitives are the part you can lift out and keep if you later move off Amplify.

Editorial conclusion

Amplify UI fits a team already on AWS Amplify that wants the Authenticator and a themed component set instead of hand-rolling sign-in flows and design tokens, and that is prepared to stay on current Amplify JavaScript versions. It does not fit a team on Amplify JavaScript v4 or below, whose support ended on 2026-04-13, nor a team that needs the full primitive set outside React. Before adopting it, check the version your Amplify JavaScript dependency resolves to against the support calendar, then install the framework package you need and confirm the connected components you rely on exist for that framework, since the matrix lists the primitive set as React only.

Frequently asked questions

Official sources

1. aws-amplify/amplify-ui on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases