Skip to content

Releases: mangobyte-dev/swiftui-ui-registry

0.4.0

Choose a tag to compare

@mangobyte-dev mangobyte-dev released this 19 Sep 08:59

A minor release, source compatible with 0.3.x. brew upgrade swiftui-registry installs the tool.
A package pinned .upToNextMinor(from: "0.3.0") resolves it, and every item keeps the 0.3.0
floor, since none needs anything newer.

Three things drove it. A Point-Free audit in two passes (docs/point-free-audit.md) hardened the
engine with no schema change. A build of a shop front from the released tool, read by hand, found
seven problems an agent meets. A measured study then had an agent build four small apps five
times each, changed the registry one thing at a time, and kept only what lowered the count
(docs/case-studies.md).

Added

  • Case studies (docs/case-studies.md, also on the website): the four apps, their screenshots,
    the items they used, and what the measurement found.
  • validated-input 0.1.0: a text field with a floating label, a rounded border that follows
    focus and validity, and rules checked while typing and again on blur. Rules are required,
    email, phone, custom, and the statics password, matching, numberRange,
    internationalPhone, and pattern; the first failing rule's message shows under the field, is
    the accessibility hint, and is announced. A validity binding reports every change so a form can
    gate its submit. Based on the owner's earlier enum-driven text field.
  • A fifth generator, swiftui-registry generate usage-checks, writes UsageSnippetChecks.swift:
    one View per installable item that compiles the item's usage snippet, so a snippet naming an
    undeclared symbol fails the Showcase build instead of shipping. Symbols a snippet leaves to the
    adopter are stand-ins in the hand-written UsageSnippetPlaceholders.swift.
  • describe lists Signatures:: every public initializer, function, static member, and enum of
    the item's sources, one line each, prefixed with the owning type, with labels, types, defaults,
    and enum cases. The JSON and MCP describe_item payloads carry them as signatures.

Changed

  • Thirteen items gained the words a shop developer searches first: product, cart, price,
    checkout, rating, and their neighbors now resolve to item, badge, button, field,
    empty, metric-card, and the rest. Search itself is unchanged: every term must still match.

  • Fourteen more items gained the words a chat, settings, or finance developer searches first:
    unread and counter reach badge; send, submit, and refresh-button reach button;
    composer reaches input-group; email, phone, and password reach input and field;
    sign-out and logout reach alert-dialog; notifications reaches settings-section;
    filter reaches accordion and checkbox; range reaches slider; total reaches table and
    metric-card; profile-header reaches avatar; refreshed reaches toast.

  • field 0.1.2: Field also takes its error as a String?, so a message computed at runtime no
    longer needs wrapping in a LocalizedStringResource. The resource initializer stays preferred.

  • attachment 0.1.2 and item 0.2.2: a bare trailing closure on AttachmentRow or ItemRow now
    resolves to the content initializer instead of an ambiguity error; the actions-only and
    accessory-only initializers are disfavored.

  • signup-form 0.1.2: SignUpForm takes isSubmitEnabled (default true) and disables its
    submit button and return-key submit while it is false.

  • Installer.FileStatus.status and InstalledInventory.File.status are now enums
    (PlanFileStatus, UpdateFileStatus, InventoryFileStatus) instead of String. JSON and CLI
    text output are byte-identical; Swift code that links RegistryKit directly and compares
    .status against a string literal needs to compare against the matching case instead.

  • RegistryKit's FileSystem and RegistrySource are structs of closures, the shape of its
    other six dependencies, instead of protocols. LocalFileSystem() and LocalRegistrySource()
    are FileSystem.local and RegistrySource.local; .unimplemented is each one's test default.
    write(_:to:) and repositoryRoot(override:refresh:) stay as methods, so call sites through
    @Dependency do not change; a type that conformed to either protocol now builds a value instead.
    The CLI and MCP output are unchanged.

  • skeleton 0.2.2: the doc comment names what redaction does not cover. An effect the wrapped
    content starts itself (task, onAppear, a request) still runs; gate it on the same flag. No
    visible change, no recapture.

  • The tuning panel's import sheet owns its draft and its failure state; a failed paste no longer
    outlives the sheet.

Fixed

  • Five usage snippets did not compile as printed. field read $name and emailError without
    declaring them; auth-form, signup-form, message-scroller, and settings-section bound state
    they never declared. Each now declares the state it assumes. toast's snippet shows message:
    and carousel's names its placeholder collection.
  • swiftui-registry search ... --format names printed nothing on zero matches. It now says
    No item matches ... on stderr and still exits 0.
  • In a test, an un-overridden registryFileSystem or registrySource reached the real disk and the
    release snapshot. Both now fail at the boundary: the file system's throwing members throw, its
    queries report an issue, and the source throws. RegistryKit declares IssueReporting through
    xctest-dynamic-overlay, the identity swift-sharing already resolves; RegistryKitTests
    declares CustomDump for line diffs on multi-field assertions and generated text. Neither
    changes Package.resolved.

Known limitations

  • Unchanged from 0.3.1: toggle-group's toggles report no frame inside a native ControlGroup,
    and the same six Showcase visual references fail on the pinned simulator by 4.1 to 5.5 percent
    (activity, auth, command, finance, nutrition, settings), on an unchanged tree.
  • A search for quantity matches nothing. The native Stepper is the answer, and an item that
    only renames it is out of scope by the value gate.

0.3.1

Choose a tag to compare

@mangobyte-dev mangobyte-dev released this 13 Sep 09:01

A patch release: every change is source compatible. brew upgrade swiftui-registry installs the tool. A package pinned .upToNextMinor(from: "0.3.0") resolves it, and every item keeps the 0.3.0 floor, since none needs anything newer.

Added

  • Recipes are selectable. A recipe's usage snippet ends its root with .registryItem("<name>"); copy it, and the design surface selects the recipe. A recipe whose snippet uses registry items declares them, so the panel scopes to the tokens they read. menubar carries no tag: its root is a Scene, and the tag is a View modifier.
  • RegistryItemReport.ancestors: the tagged roots an item sits inside, outermost first. ItemSelection.chain(reports:at:) reads it.

Changed

  • A child that fills its parent exactly is picked before the parent. Before, equal areas resolved by name, so an attachment won over the item inside it.
  • The panel shows only what an export reproduces. A value that arrives off its slider grid (an import, a hand edited registry-tokens.json) renders and exports at the nearest step, and a custom color at 8 bits a channel.
  • The System accent tints nothing while tuning. A consumer's export carries no accent for System, so its native controls keep their own colors; the tuner now shows the same.

Fixed

  • swiftui-registry preset apply wrote a theme file that did not compile for a code with a font design, a surface step, a chart palette, or a color pair. Those arguments now follow metrics:, the order RegistryTheme.init declares. The Swift that preset decode prints, the MCP tools, and the website's Create page share the fix.
  • Copy Swift rounded an off-grid number or a custom color to three decimals, which changed pixels. It now prints the fewest decimals that read back. The theme file prints each color channel the same way.
  • Neither export wrote surfaceOpacity, so registrySurface(level:) drew a different elevated surface in the consumer. Both write it when it leaves 0.055.

Known limitations

  • A native ControlGroup never places its toggles, so toggle-group's toggles report no frame and Select picks the group. registryToggleGroup(_:)'s variant has no visible effect on iOS 27.
  • Six Showcase visual references fail on the pinned simulator by 4.0 to 5.5 percent against the 1.5 percent tolerance (activity, auth, command, finance, nutrition, settings). They failed before this release too, on an unchanged tree.

Full Changelog: 0.3.0...0.3.1

0.3.0

Choose a tag to compare

@mangobyte-dev mangobyte-dev released this 09 Sep 03:36

The design surface: a tool for tuning a running app on the device, shipped as a second package product and driven through the Showcase and two real apps. Install or upgrade with brew install mangobyte-dev/tap/swiftui-registry or brew upgrade swiftui-registry

Added

  • The SwiftUIRegistryDesignSurface product. Add it, import SwiftUIRegistryDesignSurface, and apply designSurface() inside the app's registryTheme(_:). In a debug build it puts a draggable Tune button and a floating, movable, resizable panel in the tool's own window over the whole app, which stays live underneath on every tab, sheet, and cover; a release build returns the content unchanged. The tuned tokens persist as registry-tokens.json in the app's Documents directory and export as a preset code any registry tool applies, or as the Swift to paste
  • Tap-to-select. Select arms the next tap; the panel scopes to the tokens that reach the item you tapped, outlines every tagged item on the screen with its name, and lists them under On this screen. ItemSelection.chain names every item under the pick, innermost first, so a host can offer the row around a button as well as the button. A pick on nothing clears the selection
  • Host tokens: conform an app's own token value to TokenDocument (a shipped value, a file name, and pages of .number, .choice, and .color knobs with an apply()), pass it to designSurface(tokens:), and the panel gains an App tokens section that writes changes back to the app
  • Per-item knobs: register numeric knobs with designSurface(knobs:) (ItemKnob) and read them inside an item with registryKnob(_:_:default:); they persist beside the tokens in design-knobs.json, and only a value that moved is written
  • The host-hooks overload designSurface(enabled:tunesRegistryTheme:knobs:itemTitle:page:panelEnvironment:panel:) for an app that paints registry items from its own tokens. It compiles in every build configuration: enabled is the app's own switch, tunesRegistryTheme: false drops the panel's theme sections, panel adds the app's sections, page pushes the app's page for a picked item, panelEnvironment wraps the panel's stack, and itemTitle names rows and outlines
  • Foundations gained registryItem(_:) and registryScreen(_:), the tags the surface selects and names screens by, plus the surface reporter and the per-item knobs in the environment, all inert without a surface
  • A fourth generator, swiftui-registry generate item-tokens, writes the item-to-token map the design surface scopes its panel by, and CI checks it for drift with the other generated outputs
  • CHANGELOG.md (this file), a repository-layout table in CONTRIBUTING.md, and docs/RELEASE-CHECKLIST.md, the list a release closes line by line

Changed

  • The tuning panel moved out of the Showcase into the SwiftUIRegistryDesignSurface product; the Showcase consumes it. The panel is a floating card in the tool's own window, not the earlier sheet or inspector column: a drag bar moves it, a corner grip resizes it, a chevron collapses it, it may hang off the leading, trailing, and bottom edges while its grab strip stays inside the safe area, it never goes above the top, a drag against the trailing edge of an iPad snaps it into a full-height column, and its frame is remembered per size class and re-clamped on rotation
  • The tool's own chrome (the Tune button, the card, the selection ring, the outlines, the guides) is drawn from fixed system values, never the tuned theme, so tuning the app never restyles the tool; the tool's motion is off under Reduce Motion
  • Every installable item declares the 0.3.0 foundations floor, because every one applies registryItem(_:); the installer prints from 0.3.0 up to the next minor version
  • swift-sharing is pinned to the 2.9.x line (from 2.9.1, below 2.10.0) with no traits declared, so a consumer already resolving xctest-dynamic-overlay is not forced onto a newer major
  • The repository holds only what an adopter needs; planning, research, and run logs left it

Fixed

  • The tool no longer advertises an older Homebrew tag as an update: the notice appears only for a tag newer than the running tool
  • A tap on a List row under the card pushes again; the key window now follows the text field that takes focus (a field in the app takes the keyboard, a field in the panel takes it back) instead of switching during hit testing, which cancelled the touch
  • The collapse control has its own accessibility frame; the drag runs over the whole bar as a simultaneous gesture
  • The card is clamped into the window's safe area, so its strip never sits under the status bar and never stops short of it
  • A knob with a non-positive step or a shipped value outside its range is made usable and logged; a token file that fails to decode (edited by hand, or written by a newer version) leaves the shipped values in place, is logged once, and is not rewritten until a knob moves; a choice knob keeps a value its options no longer list; an empty item or screen name tags nothing; a host title that is an empty string falls back to the item's name; ties between equal frames resolve by name; an item scrolled off the screen is not listed as on it
  • Foundations compiles on macOS again (Color(uiColor:) had crept into the selection ring); an unused anchor preference left the public API before it shipped

Known limitations

  • Two visual references, auth-light and nutrition-light, are stale after the tuning-strip change (measured at 2.70 percent and 1.54 percent against the 1.5 percent tolerance). They are recaptured but await the owner's copy into ReferenceImages/, so those two Showcase UI tests fail until then (docs/visual-testing.md)
  • The iPad simulator intermittently never reports idle after keyboard input, so the UI suite passes -disable-animations on the iPad destination and one test records a measured skip rather than a failure (docs/visual-testing.md)
  • The tool's window installs over the first connected scene; a second window of the same app on iPad is not covered
  • Items installed from 0.1.0 or 0.2.0 carry no registryItem(_:) tag, so Select and the outlines find nothing in them until swiftui-registry install <item> --update brings the tagged sources
  • The Showcase is portrait-only on iPhone; rotation of the card is exercised on the iPad destination and in the host apps

Full Changelog: 0.2.0...0.3.0

0.2.0

Choose a tag to compare

@mangobyte-dev mangobyte-dev released this 07 Sep 08:08

swiftui-registry 0.2.0, the Stage 7 release.

The catalog grows from 57 to 73 items: six chat and feedback components (attachment, bubble, marker, message, message-scroller, toast), seven recipes (carousel, chart-tooltip, date-picker, input-otp, menubar, sheet, typography), and three blocks (dashboard, signup-form, questionnaire). Every item is captured on the iPhone 17 and the iPad Pro 13-inch, and the website shows both.

The tool gains describe <item> (the metadata, usage, accessibility contract, install order, package requirement, and files, with --source and --format json) and info --destination <dir> (every owned file reported as up-to-date, modified, or missing through the receipt).

Preset codes gain format version b: after the version a fields and the custom accent block, a code can carry the font design, a surface step for a four-level elevation ladder, a chart palette, and optional light and dark pairs for the background, the foreground, and the secondary foreground. A code stays a whenever nothing appended leaves its default, so every existing code keeps decoding to the same theme. preset decode, apply, and resolve read and write the new fields; the Create studio and the Showcase's tuning panel expose them.

SwiftUIRegistryFoundations 0.2.0 adds fontDesign, surfaceOpacity, surfaceStep, chartPalette, background, foreground, and secondaryForeground to RegistryTheme (all defaulted, so existing initializers compile), the mango preset (MangoByte's sample design system, documented in docs/mango.md as the template for building one), RegistrySurfaceLevel with registrySurface(level:), and a root modifier that applies the font design and the color pairs once. The chart item reads the palette and declares the 0.2.0 floor; every other item keeps 0.1.0.

Registry styles keep the iPadOS pointer effect (button, checkbox, accordion, breadcrumb), the sidebar recipe adds the sidebarAdaptable tab view, and three agent skills under Skills/ document consuming, theming, and authoring the registry.

Install or upgrade: brew install mangobyte-dev/tap/swiftui-registry or brew upgrade swiftui-registry.

0.1.0

Choose a tag to compare

@mangobyte-dev mangobyte-dev released this 06 Sep 13:14

The first published contract of the SwiftUI registry: 57 source-owned items (31 components, 8 blocks, 18 recipes), the SwiftUIRegistryFoundations theme package, and the swiftui-registry tool.

The tool installs items with receipt-backed three-way updates, searches the catalog, validates it, reads and writes preset codes, serves the same operations over MCP, and generates the catalog, the Showcase manifest, and the website data. Outside a clone it fetches this tag's registry snapshot on first use.

The release workflow attaches swiftui-registry-macos-universal.tar.gz (arm64 and x86_64) and its sha256 for the Homebrew tap.