<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/those-ugly-backing-properties-are-always-useless-sfyoduisf" -->

---
title: Those ugly backing properties are always useless | daily.dev
description: Backing properties in Kotlin (using underscore-prefixed MutableStateFlow) are commonly used to enforce encapsulation in ViewModels, but the author argues they...
canonical: https://daily.dev/posts/those-ugly-backing-properties-are-always-useless-sfyoduisf
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Those ugly backing properties are always useless | daily.dev
og:description: Backing properties in Kotlin (using underscore-prefixed MutableStateFlow) are commonly used to enforce encapsulation in ViewModels, but the author argues they...
og:url: https://daily.dev/posts/those-ugly-backing-properties-are-always-useless-sfyoduisf
og:image: https://api.daily.dev/og/posts/sFyoduIsF.png
og:image:alt: Those ugly backing properties are always useless
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Those ugly backing properties are always useless

**[Just Kotlin](https://daily.dev/sources/justkotlin)** · [@giorgishalvashvili](https://daily.dev/giorgishalvashvili) · 2 min read · 5 upvotes · 2 comments

## Summary

Backing properties in Kotlin (using underscore-prefixed MutableStateFlow) are commonly used to enforce encapsulation in ViewModels, but the author argues they provide little real protection. Any developer can simply remove the underscore and make the field public, and code reviews will catch architectural violations regardless of whether a backing property exists. The author suggests backing properties are only truly necessary when writing libraries where consumers must not access mutable internal state, pointing to Kotlin's Explicit Backing Fields as the proper solution for that case. The post questions whether backing properties solve a real, recurring problem in practice.

## Content

It takes about five seconds to write a backing property in Kotlin. They help enforce encapsulation and keep the code clean. We can add it to every ViewModel and repositories.

```
private val _uiState = MutableStateFlow(UiState())
val uiState: StateFlow<UiState> = _uiState.asStateFlow()
```

But let’s be honest: this isn't a concrete wall. If a developer really wants to do a dirty hack and update the state directly from a UI button click, there is absolutely nothing stopping them from opening the ViewModel, deleting the underscore, and making the `MutableStateFlow` public.

### **PRs Catch Hacks Anyway**

The biggest defense of the backing property is that if someone deletes it to do a hack, it shows up as a massive red flag in the Pull Request.

But do we really need a deleted backing property to spot a hack?

If a developer writes `viewModel.uiState.value = newState` directly inside a UI Fragment or Compose function, any reviewer is going to spot that instantly. The bad code in the UI file _is_ the red flag. We don't need a secondary red flag in the ViewModel file to tell us the architecture was violated. Code reviews catch bad architecture, with or without the underscore.

### The right solution for actual problem

The only case where hiding mutable state is important is when writting a library and you don't want the consumers updating the internal state of your library then, use [Explicit Backing Fields](https://app.daily.dev/posts/7lmikq0bk).

For example

```
val city: StateFlow<String> // Public field is immutable
    field = MutableStateFlow("")

fun updateCity(newCity: String) {
    // Inside the library we can update the value
    city.value = newCity
}
```

### Do backing properties solve an actual problem that you had?

Usually solving problems goes like this: problem -> solution -> problem fixed. Have you guys had a problem where junior devs kept updating state from UI so many times that you decided to add backing properties and this solved the problem?

## Community discussion

Top comments from developers on daily.dev.

**@pratikbharad** · 1 upvotes

> @giorgishalvashvili, Yes, I've seen in the PRs that jr. developers directly interact with mutable state flow from the View, and whenever I've seen something like that, I've rejected that PR 😅.
>
> The main advantage of this thing is that we don't need to create and manage 2 variables from now on.

## Similar posts on daily.dev

- [Understanding Backing Fields in Kotlin: The Hidden Storage Behind Properties](https://daily.dev/posts/understanding-backing-fields-in-kotlin-the-hidden-storage-behind-properties-b8jc7izjl) · Medium · 2 upvotes · 0 comments
- [How to Avoid Common Pitfalls With JPA and Kotlin](https://daily.dev/posts/how-to-avoid-common-pitfalls-with-jpa-and-kotlin-hgchpvpwb) · Kotlin · 1 upvotes · 0 comments
- [KMP Architecture: The Case for Pure Kotlin ViewModels](https://daily.dev/posts/kmp-architecture-the-case-for-pure-kotlin-viewmodels-2xnkadg3i) · ProAndroidDev · 1 upvotes · 0 comments

---

Tags: [#general-programming](https://daily.dev/tags/general-programming), [#android](https://daily.dev/tags/android), [#kotlin](https://daily.dev/tags/kotlin)

[View this post on daily.dev](https://daily.dev/posts/those-ugly-backing-properties-are-always-useless-sfyoduisf)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"DiscussionForumPosting","mainEntityOfPage":"https://daily.dev/posts/those-ugly-backing-properties-are-always-useless-sfyoduisf","headline":"Those ugly backing properties are always useless","text":"Backing properties in Kotlin (using underscore-prefixed MutableStateFlow) are commonly used to enforce encapsulation in ViewModels, but the author argues they provide little real protection. Any developer can simply remove the underscore and make the field public, and code reviews will catch architectural violations regardless of whether a backing property exists. The author suggests backing properties are only truly necessary when writing libraries where consumers must not access mutable internal state, pointing to Kotlin's Explicit Backing Fields as the proper solution for that case. The post questions whether backing properties solve a real, recurring problem in practice.","url":"https://daily.dev/posts/those-ugly-backing-properties-are-always-useless-sfyoduisf","datePublished":"2026-04-07T18:22:27.262Z","dateModified":"2026-04-11T14:25:43.485Z","author":{"@type":"Person","name":"Giorgi Shalvashvili","url":"https://daily.dev/giorgishalvashvili","image":"https://lh3.googleusercontent.com/a/ACg8ocIwuIzmwaSYq8PEmOWByDg7J5ZxDHoG2lH-05--GDMIH4LQQ1tM=s96-c","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":2280}},"image":"https://media.daily.dev/image/upload/s--wds-IOAr--/f_auto/v1775917542/posts/sFyoduIsF?_a=BAMAMiWQ0","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":5},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":2}],"comment":[{"@type":"Comment","text":"@giorgishalvashvili, Yes, I’ve seen in the PRs that jr. developers directly interact with mutable state flow from the View, and whenever I’ve seen something like that, I’ve rejected that PR 😅.\nThe main advantage of this thing is that we don’t need to create and manage 2 variables from now on.","datePublished":"2026-04-14T05:56:05.230Z","url":"https://daily.dev/posts/sFyoduIsF#c-t44fWulQI","author":{"@type":"Person","name":"pratik bharad","url":"https://daily.dev/pratikbharad","image":"https://media.daily.dev/image/upload/s--_L6xwplo--/f_auto,q_auto/v1700137990/avatars/avatar_yQ0Yyq4SQpV7nCTC0nWSi"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/squads/justkotlin","name":"Just Kotlin"}}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Just Kotlin","item":"https://daily.dev/squads/justkotlin"},{"@type":"ListItem","position":3,"name":"Those ugly backing properties are always useless"}]}
```