An app’s settings form used to show every option it had, all at once, in whatever order they happened to arrive in. For an app with a handful of settings that is fine. For one where half the options only matter if you picked a particular mode, it means reading past settings that do nothing for you and guessing which ones your choices have made irrelevant.
A setting can now depend on another, so the form shows it only when it applies, and an app can set the order its settings appear in, putting the decisions you make first at the top.
This is something each app’s author adopts, so you will see it on apps as their authors take it up rather than everywhere at once. Nothing changes for an app that has not.
For app developers
Both keys go in a setting’s help_text, as a JSON object instead of a plain string:
{
"schema_version": 1,
"properties": {
"help_text": "Which symbol the widget follows, for example NASDAQ:AAPL.",
"display_order": 20,
"depends_on": { "setting": "widget_type", "values": ["chart", "ticker"] }
}
}depends_on names another setting and the values that make this one apply. Above, the symbol
field appears only while widget_type is chart or ticker. A setting hidden this way is
genuinely absent rather than merely invisible: it is not validated and its value is not saved, so
a required setting that does not apply to the chosen mode cannot block an install.
display_order is a number, sorted ascending within the basic and advanced groups separately. A
setting without one keeps the order it arrived in and sorts after every setting that has one.
The help_text inside properties is the text shown under the field, since the outer help_text
is now carrying the schema.
Both keys fail open. A help_text that is not a JSON object with a schema_version is treated as
plain help text exactly as before, and a malformed depends_on shows the setting rather than
hiding it, so a mistake in a schema cannot make a setting unreachable.