Choose a contained task with a clear outcome, such as editing a preference or confirming an action. Record its current controls, labels, states, and keyboard behavior. Include waiting, empty, and error states where they affect the task.

Keep the existing data flow and application routes while evaluating the new controls. This makes it easier to identify which changes come from presentation and which come from application behavior.

This comparison preserves the enabled notification preference and the save label. The new controls do not add persistence; connect them to the same application operation and verify its outcome.

Confirm that the application uses the React and React DOM versions required by the installed package, then load its aggregate stylesheet once. The optional Theme provider can scope appearance to the interface being migrated; type="system" follows the browser's preferred color scheme. In a framework with React Server Components, put state and event handlers behind the framework's client boundary. Follow the React tutorial for the local integration sequence.

import { Button, Theme } from "@liquidify/react"
import "@liquidify/react/styles.css"

export function SaveAction({
  onSave,
  saving = false,
}: {
  onSave: () => void
  saving?: boolean
}) {
  return (
    <Theme type="system">
      <Button variant="glassProminent" loading={saving} onPress={onSave}>
        {saving ? "Saving changes" : "Save changes"}
      </Button>
    </Theme>
  )
}

The application still owns the save operation, including persistence, error handling, and the message shown after completion. For asynchronous saving, the parent sets saving while its request is pending and clears it when the request settles. Button uses that value to show progress and suppress repeated activation; it does not observe the promise. Handle rejected operations in the parent and provide a visible error and retry path. Follow Button guidance for the activation contract. A completed visual migration should preserve the original task's failure and recovery paths.

Choose the Liquidify component that matches the task. Use an action control for an action, a link for a destination, and a value control for a setting or selection.

Check callback names and value shapes before connecting existing state. For example, a controlled Toggle uses checked and onChange. Do not assume that every value control follows that same naming scheme.

Liquidify Form groups content visually; it does not render an HTML form or submit data. Retain a native <form> and its submit handler when migrating a submission workflow. Button defaults to type="button"; set type="submit" for the submit action and perform the save in the form handler. See Forms for validation and recovery and Button guidance for activation behavior.

Use the component catalog for the exact API and the controlled-state guide for ownership rules. Retain any existing behavior until its replacement has been evaluated.

Start with supported component variants. Existing background styles, borders, or overlays may obscure the intended surface or make labels difficult to read. Review those customizations in context before carrying them across.

Move shared color and spacing decisions into appropriate public tokens and page-owned classes. Avoid styling private component internals. Controls and presentational surfaces expose different customization options; use the documented boundary for each component.

Before extending adoption, check that people can still:

• Identify the main action and understand its result.
• Complete the task using a keyboard.
• Read labels over the actual backgrounds in both themes.
• Use the interface at narrow widths and with enlarged text.
• Understand waiting, failure, cancellation, and success.
• Return to their previous context after closing a temporary view.

Treat any missing behavior as application work or a library requirement. Apple framework features such as automatic native navigation adaptation are not implied by adopting Liquidify.

Record the component choices, token overrides, and unresolved issues from the first task. Apply the same decisions to the next related screen. Review exceptions as the interface grows so that customization does not produce a different visual language on each page.

Liquidify is experimental. Record the source revision and package artifacts used by the application; a 0.0.0 version label alone does not identify the code. Pin a usable release when one becomes available and review versioning guidance before future updates.

• Apple: Adopting Liquid Glass
• Liquidify React package
• Theming
• Coming from SwiftUI