iced_aw: the widgets Iced does not ship, behind a feature gate each

Every widget is a feature, and the default set is empty

iced_aw is a crate of additional widgets for the GUI library Iced, and the design decision that defines it is in the second line of the documentation: every widget is hidden by a feature gate, and this allows you to cherry pick the widgets you actually need.

That is a different approach from a crate that ships everything behind a single optional feature. Here the Cargo.toml lists one empty feature per widget, and the default is an empty list:

[features]
default = []

badge = []
card = []
date_picker = ["chrono"]
color_picker = ["iced_widget/canvas"]
tab_bar = []
tabs = ["tab_bar"]
time_picker = ["chrono", "iced_widget/canvas"]
wrap = []
number_input = ["num-format", "num-traits", "typed_input"]
typed_input = []
selection_list = []
menu = []
quad = []
spinner = []
context_menu = []
slide_bar = ["num-traits"]
drop_down = []
sidebar = []
labeled_frame = []
custom_layout = []
debug_log = ["log"]

The consequence is that the default build of iced_aw compiles nothing, and a project that wants a badge and a card enables exactly two features and gets exactly those two widgets. The feature definitions also show which widgets need something else: the date and time pickers pull in chrono, the color picker and the time picker pull in iced_widget/canvas, and the number input pulls in num-format, num-traits and typed_input.

The `full` feature is the escape hatch for people who do not want to think about it, and it enables the whole set of widgets: badge, card, number_input, date_picker, color_picker, tab_bar, tabs, time_picker, slide_bar, wrap, selection_list, quad, context_menu, spinner, drop_down, menu, sidebar, labeled_frame and custom_layout.

For a Rust library, where compile time is a real cost that every user pays, that per-widget granularity is the feature that makes the crate worth a dependency rather than a fork.

The version table is short and it is the thing to check first

iced_aw is versioned separately from Iced, and the documentation publishes the mapping in a two-row table.

| `iced` version | `iced_aw` version | | -------------- | ----------------- | | 0.13 | 0.12 | | 0.14 | 0.13, 0.14 |

So a project on Iced 0.13 takes iced_aw 0.12, and a project on Iced 0.14 can take either 0.13 or 0.14. The current published release is v0.14.1 from 2026-06-04, before it v0.13.0 from 2025-12-08 and v0.12.0 from 2025-02-07.

The offset between the two version lines is worth noticing, because it is not a coincidence. The iced_aw 0.14 release is built against a development version of the Iced libraries, with iced_core and iced_widget both pinned to 0.15.0-dev in the dependencies, and the dev dependencies pull in iced_test at 0.15.0-dev with the debug, tokio, time-travel and advanced features. The crate's own rust-version is 1.92 and its edition is 2024, so it expects a recent toolchain.

That combination, a published release built against a dev version of its host library, is the thing to verify before you pin a version. The compatibility table tells you which iced_aw goes with which iced, and the Cargo.toml tells you that the current line is tracking Iced's next major version rather than the one you are on.

The widget list, and which ones need a second feature

The catalogue is the substance of the crate, and each entry comes with a feature name and a pointer to an example file in the examples/ directory.

Badge is a small status pill, enabled with `badge`. Card is a container, enabled with `card`. The Color Picker is enabled with `color_picker` and pulls in the canvas support. The Date Picker is enabled with `date_picker` and pulls in chrono. The Time Picker is enabled with `time_picker` and pulls in both chrono and canvas.

NumberInput is described as just like TextInput, but only for numbers, and it is the one widget with an explicit platform caveat in the documentation: it does currently not support web. The underlying typed_input feature is separate, which is what the number_input feature depends on.

SelectionList is a selection space to show any options passed in, enabled with `selection_list`. TabBar and Tabs are two features, with tabs depending on tab_bar, so enabling tabs brings the bar with it.

The Menu is enabled with `menu`, and the documentation adds a note that you might also want to enable the feature `quad` for drawing separators. That is a small detail and a good example of the granularity: separators are a separate concern from the menu itself, and a project that draws its own separators does not need them.

Then there are the ones with an example file rather than a screenshot, which suggests they are less settled: the Context Menu, the Drop Down Menu, the Sidebar, the Slide Bar, the LabeledFrame, the Wrap and the custom layout. The Sidebar is the interesting one, because its feature also includes two extra widgets, sidebar::column::FlushColumn and sidebar::row::FlushRow, which flush the end or start element to the opposite direction of the container's alignment. That is a layout primitive you would otherwise write by hand, and it is bundled with the sidebar rather than offered separately.

Adding it to a Cargo.toml, and the one dependency line that matters

The usage section is short. You include iced_aw as a dependency in your Cargo.toml, and the example given enables everything:

[dependencies]
iced = "0.14.0"
iced_aw = { version = "0.14.0", features = ["full"] }

The features list is where you substitute your own. A project that wants a date picker and a sidebar and nothing else writes features = ["date_picker", "sidebar"], and the crate compiles only those. The `full` value in the documentation is the example, not a recommendation, and the sentence above the snippet, that every widget is hidden by a feature gate so you can cherry pick, is the instruction.

Two things in the manifest are worth knowing about if you are reading the crate's own dependencies. The base dependencies are iced_core and iced_widget, both at 0.15.0-dev, plus chrono as an optional dependency at 0.4.44 with the wasmbind feature, and iced_fonts at 0.3.0. The dev dependencies include iced_test at 0.15.0-dev for UI testing, and rand, getrandom with the wasm_js feature, and env_logger, the last of which the comment marks as being for the wrap example.

The examples/ directory is the documentation. It holds a file per widget, including badge.rs, card.rs, color_picker.rs, context_menu.rs, custom_layout.rs, date_picker.rs, drop_down.rs, drop_down_test.rs, dropdown_pos.rs, labeled_frame.rs, menu.rs, menu_test.rs, number_input.rs, selection_list.rs, side_bar/, slide_bar.rs, spinner.rs, tab_bar.rs, tabs/, tabs_noshow.rs, time_picker.rs, typed_input.rs, widget_id_return/ and wrap.rs. Each documentation section points at the matching example, so the fastest way to learn the API is to read the example file rather than the widget description.

Where iced_aw is the wrong tool

The first limit is that this is a supplement, not a replacement. If the widget you need is one Iced already provides, the answer is Iced, and adding a second crate to get it is a dependency you do not need. The crate exists for the gap, and the gap is the list above.

The second is the version coupling, and it is sharper here than in most Rust libraries because this crate tracks a host library that is itself moving. The published iced_aw 0.14 line is built against iced_core and iced_widget at 0.15.0-dev, so a project pinning iced 0.14 has to check what the 0.14 release of iced_aw actually depends on, and the dev versions in the manifest mean the current branch is tracking Iced's unreleased work. Choosing a version here is not a formality.

The third is the feature gate maintenance burden, which is a double edge. The gates are what keep the dependency cheap, and they are also what mean the public API of every widget can change with the crate's version line, because there is no long-term compatibility promise to bind it. The `full` feature in particular will grow new widgets over time, so a project that takes `full` to save thinking is compiling more and more of the crate over time without changing its own manifest.

The fourth is one concrete platform gap that is documented rather than hidden: the NumberInput widget does currently not support web. A cross-platform project that needs a numeric field has to plan around that.

The fifth is the parts with examples instead of screenshots. The Context Menu, the Drop Down Menu and the Sidebar are pointed at example files rather than presented with a rendered image, and the tree includes menu_test.rs, drop_down_test.rs, dropdown_pos.rs and tabs_noshow.rs, which reads like a set of behaviours that are still being pinned down. The Slide Bar, the LabeledFrame and the Wrap also live in that group. For a widget you will put in front of users, that is a signal to read the example before committing to it.

Editorial conclusion

iced_aw is worth adding to a Rust desktop application that has outgrown the widgets Iced ships, because the alternative is writing a date picker or a menu from scratch, and because the per-widget feature gates keep the dependency cost proportional to what you actually use. It is the wrong choice if your project needs one of the few widgets Iced already provides well, and the wrong choice if you are not willing to track the crate's version line against Iced's. Before you adopt it, check the three things the crate's own documentation is explicit about: the compatibility table, since iced 0.13 pairs with iced_aw 0.12 while iced 0.14 pairs with 0.13 and 0.14; the default feature set, which is empty, so nothing is compiled unless you ask for it; and the per-widget feature names, which differ from the widget names in places, since the Menu widget also needs the separate quad feature for drawing separators and the number_input feature pulls in num-format, num-traits and typed_input.

Frequently asked questions

Official sources

1. iced-rs/iced_aw on GitHub
2. Issues
3. License: MIT
4. README
5. Releases