Two-Way Binding: What Is Bidirectional Data Binding in Android and iOS

What Is Two-Way Binding?

Two-Way Binding (bidirectional data binding) — an architectural mechanism where changes in the data model are automatically reflected in the user interface, and changes in the UI immediately update the model. Unlike one-way binding, where data flows only from the model to the view, bidirectional binding creates a closed synchronization loop without manual coding of each update.

According to the Android Developers Blog (2023), the DataBinding library, introduced in 2015, is used in 42% of commercial Android applications. The mechanism is especially in demand in input forms — text fields, switches, sliders and checkboxes — where user input must be instantly reflected in the model and programmatic changes in the UI. In all these scenarios, the developer writes one binding instead of a pair of "listener + setter".

At IT Sectr, we have applied bidirectional binding in projects since 2017 and recommend using it consciously: for simple input fields, but not for complex states with dependencies.

How Does Bidirectional Binding Work?

The Two-Way Binding mechanism is built on three key elements: observable field, change listener and reverse synchronization mechanism. When a user types text in an EditText field, the system intercepts the TextWatcher event, writes the new value to the bound variable, and notifies the UI to redraw if the variable changed from code.

Under the hood, the Android DataBinding library generates a Binding class at compile time that contains all the binding logic. For each View with the @={variable} attribute, a pair of setter + getter with invalidation is created. In SwiftUI, the @Binding propertyWrapper performs similar work, synchronizing the value through the Combine mechanism. SwiftUI tracks changes via @Published properties and automatically redraws the View on any change to the bound variable.

According to WWDC Session 10033 (2023), the @Binding mechanism in SwiftUI processes up to 60 frames per second when synchronizing input fields, making it suitable for interactive forms without lag. In both frameworks, Two-Way Binding is syntactic sugar over the Observer pattern, automating subscription and notification.

Two-Way Binding in Android: DataBinding and Jetpack Compose

In Android, bidirectional binding is available in two variants: classic XML DataBinding via the @={} attribute and Jetpack Compose via bidirectional state references. Both approaches solve the same problem — synchronizing UI and model — but differ in syntax and scope.

DataBinding with @BindingAdapter and @=

In XML markup, bidirectional binding is denoted by the @={variable.property} syntax — the equals sign inside curly braces distinguishes it from one-way @{variable}. For custom Views, the @BindingAdapter annotation with an inverse attribute is required.

<layout>
    <data>
        <variable name="viewModel" type="com.example.LoginViewModel" />
    </data>
    <EditText
        android:text="@{viewModel.email}" />
    <CheckBox
        android:checked="@{viewModel.agreeToTerms}" />
</layout>

The example shows a simple form with email and checkbox — both fields use bidirectional binding, which eliminates writing TextWatcher and OnCheckedChangeListener in Activity code. When the user changes the text, the viewModel.email field updates automatically.

@BindingAdapter("app:rating")
fun RatingBar.setRating(rating: Float) {
    if (rating != this.rating) {
        this.rating = rating
    }
}

@InverseBindingAdapter("app:rating")
fun RatingBar.getRating(): Float = this.rating

@BindingAdapter("app:ratingAttrChanged")
fun RatingBar.setListeners(
    listener: InverseBindingListener?
) {
    this.onRatingBarChangeListener =
        RatingBar.OnRatingBarChangeListener { _, _, _ -> listener?.onChange() }
}

A custom BindingAdapter for RatingBar uses a pair of annotations — @BindingAdapter and @InverseBindingAdapter — so the DataBinding library knows how to read the value from the View (reverse feedback) and how to write to the View (direct binding). The third adapter with the AttrChanged suffix notifies the system of user-initiated value changes.

Two-Way Binding in Jetpack Compose

Jetpack Compose does not support the @={} syntax but provides a similar mechanism via mutableStateOf and explicit setter function passing. Bidirectional binding in Compose is built on passing State and a callback function (value, onValueChange) to child components.

@Composable
fun LoginScreen() {
    var email by remember { mutableStateOf("") }

    OutlinedTextField(
        value = email,
        onValueChange = { email = it },
        label = { Text("Email") }
    )
}

@Composable
fun CustomRatingBar(
    rating: Float,
    onRatingChange: (Float) -> Unit
) {
    Slider(
        value = rating,
        onValueChange = onRatingChange,
        valueRange = 0f..5f
    )
}

In Compose, bidirectional communication is emulated through a state + callback pair — the parent passes the current value and an update function, the child component invokes the callback on user interaction. This approach explicitly shows the data flow direction, simplifying debugging compared to implicit DataBinding synchronization.

Two-Way Binding in iOS: @Binding in SwiftUI

In SwiftUI, bidirectional binding is implemented via the @Binding propertyWrapper, which creates a read-write reference to a data source owned by the parent View. @Binding does not store the value itself — it reads and writes through the parent's @State or @StateObject.

struct LoginView: View {
    @State private var email = ""
    @State private var agreeToTerms = false

    var body: some View {
        Form {
            TextField("Email", text: $email)
            Toggle("I agree to the terms", isOn: $agreeToTerms)
            ChildRatingView(rating: $rating)
        }
    }
}

struct ChildRatingView: View {
    @Binding var rating: Double

    var body: some View {
        Slider(value: $rating, in: 0...5)
    }
}

The $ symbol before a variable name creates a Binding reference: $email has type Binding, not String. SwiftUI automatically links text changes in TextField to updating the email property through the Combine mechanism. The parent View passes a Binding to its @State to the child component, allowing state modification from any hierarchy level without delegates or callbacks.

According to Apple WWDC 2023, SwiftUI uses a diffing algorithm to minimize redraws: if the @Binding value changes but the View does not depend on that value, no redraw occurs. This provides performance comparable to UIKit (up to 120 FPS on ProMotion displays).

Two-Way Binding vs UDF: When to Choose What

The choice between bidirectional binding and unidirectional data flow (UDF) is one of the key architectural decisions in mobile development. Two-Way Binding is optimal for local form states where each user step must be immediately reflected in the model without additional code. UDF is preferable for global application state where change predictability matters more than development speed.

Recommendation: use Two-Way Binding for simple input fields (text, checkboxes, switches) in forms with 3–5 fields without complex validation. For screens with global state, network requests and dependent fields, use UDF with unidirectional flow and explicit event handling. At IT Sectr, we combine both approaches: Two-Way Binding inside forms, UDF for navigation and business logic.

Common Mistakes in Bidirectional Binding

Infinite update loop — the most common problem when using Two-Way Binding. The loop occurs when a model change triggers a UI update, which in turn changes the model again. In DataBinding, this happens if the getter in @InverseBindingAdapter returns a new value immediately after a setter call. The solution is to check whether the value changed before writing back (guard condition).

The second common mistake is binding computed fields. If a field depends on another field (e.g., total cost = price × quantity), bidirectional binding can lead to an inconsistent state. For example, the user changes the quantity, triggering a cost recalculation, which changes the quantity again. For computed fields, use one-way binding with Flow or Combine.

The third mistake is binding Observable fields without LifecycleOwner. In Android DataBinding, a LifecycleOwner must be passed to the binding, otherwise observers will not be cleaned up when the Activity is destroyed, leading to memory leaks. Always pass viewLifecycleOwner in fragments and this in Activity.

According to Google Issue Tracker (2024), about 15% of DataBinding bug reports are related to cyclic updates. For diagnostics, use Android Studio Layout Inspector — it shows current values of all bindings on the screen, simplifying the search for the infinite loop source.