Beginners often hit a point where they're not sure which projects to dive into to really lock in those new skills. The real secret to getting good at Flutter is building practical, real-world apps that boost your understanding and show off what you can do to potential employers or clients.

In this blog post, we'll explore the top 5 Flutter projects that are perfect for beginners in 2025. These projects are designed to help you apply what you've learned, push your boundaries, and gain confidence in your Flutter development journey. From integrating cutting-edge AI technologies to creating intuitive financial tools, these projects cover a wide range of functionalities and use cases.

1. LinguaLearn

Description: LinguaLearn is a simple Flutter-based app designed to help users learn vocabulary in various regional Indian languages, including Hindi, Marathi, Kannada, Telugu, Gujarati, and Punjabi. This project is particularly useful for demonstrating AI integration with Flutter.

Features:

• Vocabulary learning in multiple Indian languages

• Integration with OpenAI for vocabulary assistance

• User-friendly interface built with Flutter

Why It's Great for Beginners:

• Introduces basic Flutter widgets and state management

• Demonstrates how to integrate LLM APIs to use AI capabilities in an app

• Provides a practical use case for language learning and AI assistance

Source: https://github.com/Snehal-Singh174/lingualearn

2. Expense Tracker App

Description: A modern, intuitive expense tracking application built with Flutter that helps users manage their finances with powerful visualization tools.

Features:

• Expense tracking and categorization

• Visualization tools for financial data

• Integrate Supabase/Firebase for storing/fetching data

Why It's Great for Beginners:

• Teaches data management and visualization in Flutter

• Introduces basic financial calculations and data storage

• Integrate Supabase or Firebase to understand CRUD operations and handling data from a database

• Provides a practical use case for personal finance management

Source: https://github.com/Snehal-Singh174/Supabase_Database_Select , https://github.com/Snehal-Singh174/expense-tracker

3. E-Learning App

Description: An all-in-one Flutter app that provides courses, materials, quizzes, and personal mentor support at no cost.

Features:

• Course materials and quizzes

• Integration with YouTube API to load videos from a YouTube channel

• Video player to display educational videos

• Material sections with PDFs of courses

• Quizzes for all courses to test knowledge and reinforce learning

Why It's Great for Beginners:

• Introduces complex state management and navigation

• Demonstrates integration with various educational resources and APIs like YouTube

• Teaches how to handle different types of media, including videos and PDFs

• Provides practical experience in creating interactive quizzes

• Offers a comprehensive use case for e-learning, covering multiple aspects of app development

Source: https://github.com/Snehal-Singh174/E-Learning-App

4. DevFolio - Developer Portfolio

Description: A portfolio app for developers created using Flutter.

Features:

• Showcase of developer projects and skills

• User-friendly interface for easy navigation

• Integration with various social media platforms

Why It's Great for Beginners:

• Teaches how to create a personal portfolio

• Introduces basic Flutter widgets and state management

• Provides a practical use case for showcasing developer skills

Source: https://github.com/Snehal-Singh174/Devfolio , Link:

5. Movies App

Description: A Movies List app that uses the TMDB API to fetch and display movie information.

Features:

• Fetching and displaying movie information from TMDB API

• User-friendly interface for easy navigation

• Search and filter functionalities

Why It's Great for Beginners:

• Introduces API integration with TMDB

• Teaches data management and visualization in Flutter

• Provides a practical use case for movie enthusiasts

Source: https://github.com/Snehal-Singh174/Movies-App

Wrapping Up

As we've explored, these top 5 Flutter projects for beginners in 2025 offer a fantastic way to apply and expand your Flutter skills. Each project is designed to introduce you to different aspects of Flutter development, from basic widgets and state management to integrating advanced technologies like AI, Supabase, Firebase and APIs.

By working on these projects, you'll not only solidify your understanding of Flutter but also build a portfolio that showcases your abilities to potential employers or clients. Remember, the key to mastering Flutter is consistent practice and a willingness to tackle new challenges.

So, pick a project that excites you, dive in, and start building! The Flutter community is vibrant and supportive, so don't hesitate to reach out for help or share your progress. Happy coding, and here's to your success in the world of Flutter development!

🚀 If you found this guide helpful, consider bookmarking it or dropping a reaction to support more in-depth tutorials.

🔔 Follow @themodularmindset to stay updated with the upcoming articles

In this hands-on guide, we’ll go beyond static previews and learn how to fetch and display real-time movie data using the MoviesDB API. You’ll learn how to set up Retrofit, Moshi, and Hilt the right way, build a clean architecture around them, and present data through sleek, modern Compose UIs.

Whether you’re building a client project, a startup MVP, or your next side hustle, this article is your practical blueprint to integrating APIs in Jetpack Compose like a pro.

Basics of API Integration in Jetpack Compose

APIs are the backbone of modern mobile applications, enabling them to fetch data from remote servers. When it comes to Jetpack Compose, integrating APIs involves setting up network calls, managing state, and displaying the fetched data in a composable UI. Let’s dive into the steps required to achieve this.

Setting Up Your Project

Before diving into API integration, ensure that your development environment is ready.

Before we start coding, let’s ensure that your development environment is ready. Make sure you have the latest version of Android Studio and Kotlin installed.

Step 1: Create a New Jetpack Compose Project (Official guide)

1. Open Android Studio and select “New Project”.

2. Choose “Empty Compose Activity” from the project templates.

3. Name your project and set the minimum SDK to 21 (or higher).

4. Click “Finish” to create your project.

Step 2: Add Required Dependencies

To make network calls, we’ll use the following libraries:

• Retrofit: For making HTTP requests.

• Moshi: For JSON parsing.

• Hilt: For dependency injection.

Add the following dependencies to your build.gradle file:

// In your project-level build.gradle
plugins {
    ...
    id("com.google.dagger.hilt.android") version "2.48" apply false
}

// In your app-level build.gradle
plugins {
    ...
    id 'kotlin-kapt'
    id 'com.google.dagger.hilt.android'
}

android {
    ...
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_1_8
        targetCompatibility = JavaVersion.VERSION_1_8
    }
}

dependencies {
    ...
    ...
    implementation("androidx.compose.ui:ui:1.6.8")
    implementation("androidx.compose.material:material:1.6.8")
    implementation("androidx.compose.ui:ui-tooling-preview:1.6.8")
    implementation("androidx.activity:activity-compose:1.7.2")
    implementation("androidx.lifecycle:lifecycle-viewmodel-compose:2.6.2")

    // Networking
    implementation("com.squareup.retrofit2:retrofit:2.9.0")
    implementation("com.squareup.retrofit2:converter-moshi:2.9.0")
    implementation("com.squareup.moshi:moshi-kotlin:1.13.0")
    implementation("com.squareup.okhttp3:logging-interceptor:5.0.0-alpha.2")

    // Dependency Injection
    implementation("com.google.dagger:hilt-android:2.48")
    kapt("com.google.dagger:hilt-compiler:2.48")
    implementation("androidx.hilt:hilt-navigation-compose:1.2.0")

    // Navigation
    implementation("androidx.navigation:navigation-compose:2.7.7")

    // Image loading
    implementation("io.coil-kt:coil-compose:2.7.0")
}

kapt {
    correctErrorTypes = true
}

Make sure to sync your project after adding these dependencies.
That’s it. Now we have enabled Compose in our Android project. Now we are ready to move forward.

Structuring Your Jetpack Compose Project

Before diving into API integration, it’s essential to establish a well-organized folder structure. Here’s a recommended structure for your project:

• data/api: Contains classes for API service interfaces.

• data/model: Contains data models representing API responses.

• data/repository: Contains repository classes to handle data operations.

• di: Contains dependency injection-related classes.

• ui/theme: Contains theme-related classes like colors, typography, etc.

• ui/components: Contains reusable UI components.

• ui/screens: Contains composable functions representing different screens.

• viewmodel: Contains ViewModel classes for managing UI-related data.

Setting Up the MoviesDB API Integration

Step 1: Define the API Service

First, create an interface that defines the endpoints for the MoviesDB API. In the data/api folder, create a file named MoviesApiService.kt:

interface MoviesApiService {
    @GET("movie/popular")
    suspend fun getPopularMovies(
        @Header("Authorization") token: String,
        @Query("page") page: Int
    ): Response

    @GET("movie/{movie_id}")
    suspend fun getMovieDetails(
        @Header("Authorization") token: String,
        @Path("movie_id") movieId: Int
    ): Response
}

Step 2: Create Data Models

Next, create data models to represent the JSON structure of the API responses. In the data/model folder, create files Movie.kt and MoviesResponse.kt and add the below classes in it respectively.

data class Movie(
    val id: Int,
    val title: String,
    val overview: String,
    val poster_path: String
)

data class MoviesResponse(
    val results: List
)

Next, add a data model for the movie details response. In the data/model folder, create a file named MovieDetailsResponse.kt:

data class MovieDetailsResponse(
    val id: Int,
    val title: String,
    val overview: String,
    val poster_path: String,
    val release_date: String,
    val runtime: Int,
    val vote_average: Float
)

Step 3: Set Up Retrofit and Hilt

Now, let’s set up Retrofit to handle the API calls. In the di folder, create a file named NetworkModule.kt:

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {

    @Provides
    @Singleton
    fun provideRetrofit(): Retrofit {
        return Retrofit.Builder()
            .baseUrl("https://api.themoviedb.org/3/")
            .addConverterFactory(MoshiConverterFactory.create())
            .build()
    }

    @Provides
    @Singleton
    fun provideMoviesApiService(retrofit: Retrofit): MoviesApiService {
        return retrofit.create(MoviesApiService::class.java)
    }
}

Implementing the Repository Pattern

Repositories serve as an intermediary between the API and the ViewModel. In the data/repository folder, create a file named MoviesRepository.kt:

@Singleton
class MoviesRepository @Inject constructor(
    private val apiService: MoviesApiService
) {
    suspend fun getPopularMovies(token: String, page: Int): List {
        val response = apiService.getPopularMovies(token, page)
        return if (response.isSuccessful) {
            response.body()?.results ?: emptyList()
        } else {
            emptyList()
        }
    }

    suspend fun getMovieDetails(token: String, movieId: Int): MovieDetailsResponse? {
        val response = apiService.getMovieDetails(token, movieId)
        return if (response.isSuccessful) {
            response.body()
        } else {
            null
        }
    }
}

Creating the ViewModel

The ViewModel will manage the UI state and interact with the repository. In the viewmodel folder, create a file named MoviesViewModel.kt:

@HiltViewModel
class MoviesViewModel @Inject constructor(
    private val repository: MoviesRepository
) : ViewModel() {

    private val _movies = mutableStateOf<List>(emptyList())
    val movies: State<List> = _movies

    private val _movieDetails = mutableStateOf<MovieDetailsResponse?>(null)
    val movieDetails: State<MovieDetailsResponse?> = _movieDetails

    init {
        getMovies()
    }

    private fun getMovies() {
        viewModelScope.launch {
            try {
                val moviesList = repository.getPopularMovies("Bearer YOUR_ACCESS_TOKEN", 1)
                _movies.value = moviesList
            } catch (e: Exception) {
// Handle exceptions
            }
        }
    }

    fun getMovieDetails(movieId: Int) {
        viewModelScope.launch {
            try {
                val details = repository.getMovieDetails("Bearer YOUR_ACCESS_TOKEN", movieId)
                _movieDetails.value = details
            } catch (e: Exception) {
// Handle exceptions
            }
        }
    }
}

Building the UI with Jetpack Compose

Now, let’s create the UI to display the list of movies. In the ui/screens folder, create a file named MoviesScreen.kt:

@Composable
fun MoviesScreen(navController: NavController, viewModel: MoviesViewModel = hiltViewModel()) {
    val movies by viewModel.movies

    LazyColumn {
        items(movies) { movie ->
            MovieItem(movie = movie, onClick = {
                navController.navigate("movie_details/${movie.id}")
            })
        }
    }
}

@Composable
fun MovieItem(movie: Movie, onClick: () -> Unit) {
    Row(
        modifier = Modifier
            .padding(8.dp)
            .clickable { onClick() }
    ) {
        AsyncImage(
            model = "https://image.tmdb.org/t/p/w500${movie.poster_path}",
            contentDescription = null,
            modifier = Modifier.size(120.dp)
        )
        Spacer(modifier = Modifier.width(8.dp))
        Column {
            Text(text = movie.title, style = MaterialTheme.typography.h6)
            Text(text = movie.overview, maxLines = 3, overflow = TextOverflow.Ellipsis)
        }
    }
}

Now, create the UI to display the movie details. In the ui/screens folder, create a new file named MovieDetailsScreen.kt:

@Composable
fun MovieDetailsScreen(movieId: Int, viewModel: MoviesViewModel = hiltViewModel()) {
    val movieDetails by remember { viewModel.movieDetails }

    LaunchedEffect(movieId) {
        viewModel.getMovieDetails(movieId)
    }

    movieDetails?.let { details ->
        Column(
            modifier = Modifier.padding(16.dp)
        ) {
            Text(text = details.title, style = MaterialTheme.typography.h4)
            Text(text = "Released: ${details.release_date}")
            Text(text = "Runtime: ${details.runtime} minutes")
            Text(text = "Rating: ${details.vote_average}/10")
            Spacer(modifier = Modifier.height(8.dp))
            AsyncImage(
                model = "https://image.tmdb.org/t/p/w500${details.poster_path}",
                contentDescription = null,
                modifier = Modifier.fillMaxWidth()
            )
            Spacer(modifier = Modifier.height(16.dp))
            Text(text = details.overview)
        }
    }
}

Setting Up the Navigation Graph

Finally, create a navigation graph in your MainActivity.kt:

@AndroidEntryPoint
class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            MyApp {
                MoviesNavGraph()
            }
        }
    }
}

@Composable
fun MoviesNavGraph(startDestination: String = "movies_list") {
    val navController = rememberNavController()

    NavHost(navController = navController, startDestination = startDestination) {
        composable("movies_list") {
            MoviesScreen(navController = navController)
        }
        composable(
            "movie_details/{movieId}",
            arguments = listOf(navArgument("movieId") { type = NavType.IntType })
        ) { backStackEntry ->
            val movieId = backStackEntry.arguments?.getInt("movieId") ?: return@composable
            MovieDetailsScreen(movieId = movieId)
        }
    }
}

Setting Up Hilt for Dependency Injection

Now, create an Application class and annotate it with @HiltAndroidApp: in the root of the package.

@HiltAndroidApp
class MyApp : Application()

This step sets up Hilt in your project. Hilt will now be able to inject dependencies into your Android components.

Now, in your AndroidManifest.xml file, add network permission and MyApp name in the Application Tag.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:tools="http://schemas.android.com/tools">

    ...
    ...
    <uses-permission android:name="android.permission.INTERNET"/>

    <application
      android:name=".MyApp"
      ...
    >
        ...
    </application>

</manifest>

Now our application is finally ready😃. You can run it on a real device or emulator to bring your app to life and experience the smooth, intuitive UI firsthand. This marks the beginning of your journey into building more complex and feature-rich applications with Jetpack Compose.

Wrapping Up

With both popular movie listings and detailed pages wired up through MoviesDB API, you’ve now built a full-fledged Jetpack Compose app that actually feels alive. The clean architecture, modern tools like Hilt, Retrofit, and Coil, and the declarative UI all come together to showcase how powerful Compose can be when used right.

As you continue to explore and experiment, remember that the world of Jetpack Compose is vast and constantly evolving. Whether you’re refining this app, building something new, or integrating more advanced features, the possibilities are endless.

But we’re not done yet! In the upcoming parts of this Compose series, we’ll dive into real-world enhancements like local caching, paginated loading, and animating transitions that delight users.

🚀 If you found this guide helpful, consider bookmarking it or dropping a reaction to support more in-depth tutorials.

🔔 Follow @themodularmindset to stay updated with the next articles in the Jetpack Compose Mastery series.

Let’s dive in!

1️⃣Cache Expensive Work with remember to Avoid Recomposition 🧠

One of the easiest performance wins is not repeating heavy work every time your UI updates. Remember, in Compose, a composable can re-run every frame when its inputs change. If you do expensive calculations inside a composable, they can re-run on every recomposition and slow down your UI. Instead, use remember to cache results. For example, consider a list of contacts you want sorted before display:

@Composable
fun ContactList(contacts: List<Contact>, comparator: Comparator<Contact>) {
// Remember the sorted list so sorting only happens when 'contacts' or 'comparator' change
    val sortedContacts = remember(contacts, comparator) {
        contacts.sortedWith(comparator)
    }
    LazyColumn {
        items(sortedContacts) { contact ->
            Text(text = contact.name)
        }
    }
}

In this code, remember(contacts, comparator) { ... } ensures the sorting runs only once per unique list or comparator. Without remember, scrolling the list (which triggers recomposition on new rows) would re-sort the entire list over and over.

Pro Insight:
This pattern also applies to derived state. For example, if you have a list scroll position and you only need to trigger something once it crosses a threshold, you can derive that value with derivedStateOf (covered in the next tip). In general, pushing work out of the composition body and into remembered lambdas decouples your UI from needless overhead.

2️⃣ Hoist State and Use Unidirectional Data Flow 🔁

Compose shines when your UI components are stateless, but beginners often confuse who owns the state. State hoisting is the pattern of moving the state up to the caller, so a composable just takes its state and an event callback as parameters. This enables a single source of truth and unidirectional data flow (state flows down, events go up), which leads to cleaner, more testable code.

For example, instead of this stateful composable:

@Composable
fun HelloContent() {
    var name by rememberSaveable { mutableStateOf("") }
    TextField(
        value = name,
        onValueChange = { new -> name = new },
        label = { Text("Name") }
    )
}

We hoist the state out so that HelloContent is stateless:

@Composable
fun HelloScreen() {
    var name by rememberSaveable { mutableStateOf("") }
    HelloContent(
        name = name,
        onNameChange = { new -> name = new }
    )
}

@Composable
fun HelloContent(name: String, onNameChange: (String) -> Unit) {
    TextField(
        value = name,
        onValueChange = onNameChange,
        label = { Text("Name") }
    )
}

Here, HelloContent simply displays name and calls onNameChange when text changes, but it doesn’t own the MutableState. Hoisting creates a clear data flow: HelloScreen owns the state, and passes it down, while HelloContent emitting events upwards. This decoupling makes the UI easier to reason about.

Now a question arises in your mind,
Does hoisting mean every composable needs two versions (stateful & stateless)?
The Answer is not necessarily, but it’s often useful. The pattern is: provide a stateful wrapper for simple use-cases, and a stateless core for full control. This way, you keep a “single source of truth” for your data and avoid duplicate states. If multiple screens need the same name, they can all use the hoisted value from, say, a ViewModel or top-level composable.

Pro Insight:
Think of your UI as a pure function: inputs in, events out. Avoid hidden state in Composables. Tools like rememberSaveable (to survive process death) or ViewModel (to survive configuration changes) often back this pattern. Eventually, your state can live in a ViewModel or Repository, and the UI just observes it via Compose-friendly primitives.

3️⃣ Minimize Recomposition with derivedStateOf & Stable Keys ⚙️

In Compose, any state read in a composable can trigger recomposition when that state changes. Sometimes, state changes very frequently, but you only want to recompose under certain conditions. This is where derivedStateOf shines: it lets you compute a value based on state, but only trigger recomposition when the derived value actually changes.

For example, imagine a “Scroll to Top” button that should appear when the first visible item index exceeds 0. You might be tracking a LazyListState. Instead of doing:

val showButton = remember { mutableStateOf(false) }
LaunchedEffect(listState.firstVisibleItemIndex) {
    showButton.value = (listState.firstVisibleItemIndex > 0)
}

It’s simpler and more efficient to do:

@Composable
fun ShowScrollToTop(listState: LazyListState) {
// derivedStateOf recalculates when index changes, but recomposes only if the Boolean actually flips
    val showButton by remember {
        derivedStateOf { listState.firstVisibleItemIndex > 0 }
    }
    if (showButton) {
        Button(onClick = { /* scroll to top */ }) {
            Text("Scroll to Top")
        }
    }
}

Here, derivedStateOf { ... } creates a state that re-evaluates whenever firstVisibleItemIndex changes, but Compose only recomposes ShowScrollToTop when the value of showButton actually changes (from false to true or vice versa). All intermediate index changes that do not cross zero are ignored for recomposition.

Another tip: Always use stable keys in lists or when using remember(key). For example, LazyColumn’s items(list, key = { it.id }) helps Compose identify item identity and avoid full recomposition. And if you do use remember(someKey), be sure someKey truly reflects when you want the stored value to refresh.

Pro Insight:
Whenever you have a state that’s derived from another state and changes less often, use derivedStateOf. It essentially implements a “change detector” so your UI re-runs only when needed. This pattern is common in performant Compose code: couple it with good data models (e.g., immutable data classes) so state equality checks are fast and correct.

4️⃣ Prefer LazyColumn & Avoid Deep Layout Trees 🪵

A common pitfall is building complex UIs with deeply nested Column/Row combos, especially for lists. Compose provides lazy layouts (LazyColumn, LazyRow, LazyVerticalGrid, etc.) that only compose and lay out what's on-screen. Always choose a lazy layout for large or dynamic lists. For example:

LazyColumn(modifier = Modifier.fillMaxSize()) {
    items(itemsList) { item ->
        Text(text = item.title)
    }
}

This way, only visible items are composed. In contrast, using a plain Column for a list of 1000 items would compose all of them at once – a performance disaster.

Similarly, minimize unnecessary nesting. Every extra Box, Column, or Row adds overhead. Sometimes you can achieve the same effect with fewer composables or by combining modifiers. For example, prefer Modifier.padding or Modifier.layout on one element over wrapping it in extra containers.

If your list is small (just a few elements) and fixed, a simple Column approach might be fine. But even then, lazy layouts handle small lists efficiently. The big wins come when your data set grows. In practice, default to LazyColumn for scrollable content, and avoid manual scrollbars or RecyclerView bridging.

In addition to using lazy layouts, take advantage of remembered measurements. For example, if you have a custom complex header in each row, calculate its size only once via remember or a custom modifier, rather than in each recomposition. Also, if you’re showing images, make sure to reuse image resources (painterResource, rememberImagePainter with caching, etc.) - though we’re not diving into libraries here.

The key is: avoid work until absolutely needed.

Pro Insight:
Layout performance in Compose is often about avoiding overdraw and redundant passes. Use tools like the Layout Inspector (coming up) to spot deep hierarchies. Sometimes flattening multiple layers with custom Layout or Modifier.layout (see next tip) yields big gains for complex UIs.

5️⃣ Supercharge Your Workflow with Compose Previews & Tools 🛠️

Jetpack Compose comes with powerful tooling. Familiarize yourself with Android Studio’s Compose-specific features:

• @Preview: Annotate composables with @Preview to instantly see UI in the IDE without running the app. You can even create multiple previews for different states or devices:

@Preview(name = "Light Mode", uiMode = Configuration.UI_MODE_NIGHT_NO)
@Preview(name = "Dark Mode", uiMode = Configuration.UI_MODE_NIGHT_YES)
@Composable
fun GreetingPreview() {
    MaterialTheme {
        Greeting("Compose")
    }
}

Previews update live as you code, saving endless emulator restarts. You can also specify device, widthDp, heightDp, or themes in the annotation. For example, @Preview(device="id:pixel_4", showBackground=true) lets you emulate a Pixel 4 device, and Focus mode in the Design tab can isolate one preview at a time.

• Interactive Mode: Newer Android Studio versions let you interact with a preview (click buttons, switch tabs) to simulate user actions. This helps catch UI glitches early without installing the app.

• Layout Inspector: When running your app on a device/emulator, open Layout Inspector > Compose Inspector. It visualizes your Compose hierarchy. Even better, you can show recomposition counts and highlight where recompositions occur. For instance, if a component is re-rendering too often, Layout Inspector paints it with a gradient to catch your eye. You can also view each node’s parameters and semantic information, which is invaluable for debugging.

• Compose Profiler: In the Android Studio System Trace view, there’s a Compose section that graphs frame times, measure/layout/draw timings, and recomposition counters per frame. It’s a great way to spot jank or slow frames.

By leveraging these tools, you gain immediate feedback. Android Studio’s UI Check in Compose Preview even runs accessibility and layout audits on the fly.

Pro Insight:
Always double-check your composables in multiple configurations (dark mode, small screens, RTL) using previews. The Compose inspector is so powerful that I once caught a costly recomposition bug simply by noticing one component was painting bright gradients in the Layout Inspector. Tooling tips are often the difference between a good and a great Compose developer.

6️⃣ Embrace Clean Architecture with ViewModel + StateFlow 🧱

Under the hood, Compose UI is just a frontend to data. For robust apps, use a tried-and-true architecture like MVVM or MVI with Jetpack libraries. A common pattern: ViewModel + StateFlow (or LiveData) to hold your UI state, then collect it in Compose.

For example:

// In a ViewModel
class MainViewModel : ViewModel() {
    private val _uiState = MutableStateFlow("Hello, Jetpack Compose!")
    val uiState: StateFlow = _uiState
}

// In Composable
@Composable
fun MainScreen(viewModel: MainViewModel = viewModel()) {
    val text by viewModel.uiState.collectAsState() // subscribe to StateFlow
    Text(text = text)
}

Here we expose a StateFlow from the ViewModel. Inside MainScreen, calling collectAsState() converts it to Compose State<String> and automatically re-renders when the value changes. Using viewModel() ensures the ViewModel survives configuration changes and is scoped properly. This keeps business logic and state updates out of the UI layer.

The official guide highlights why this pattern works: “StateFlow ensures UI reactively updates on data changes, and viewModel() automatically retains the ViewModel across recompositions.”. And by collecting state as Compose state, you inherently follow unidirectional data flow (the ViewModel pushes new state down, and the UI emits events upwards).

Question: Should I always use StateFlow over LiveData?
Answer: StateFlow is Kotlin’s coroutine-based solution and works seamlessly with Compose. It offers more operators and doesn’t need lifecycle owners inside Composables. LiveData still works (use observeAsState()), but StateFlow is lightweight and well-aligned with coroutines. Choose what fits your team; just be consistent.

Finally, organizing your code into layers pays off. For example, one common pattern is UI State holder (a data class or sealed class) that describes all UI fields, along with ViewModel methods to update it. This way, your Composables just render state; they don’t mutate it directly. You’ll find this separation makes testing much easier.

Pro Insight:
For very complex UIs, consider an MVI approach: have a single UiState and send Intents or Actions from the UI to the ViewModel. It enforces strict state transitions and immutability. Either way, always keep your composables stateless and your business logic in ViewModels or Use-Cases.

7️⃣ Create Custom Layout Modifiers for Pixel-Perfect UIs 🎯

Compose’s Modifier system is incredibly flexible. Whenever you need custom positioning or measuring logic, you can create your own Modifier using layout { measurable, constraints -> ... }.

For example, suppose you want to position text so that the first line’s baseline is a fixed distance from the top (not just the top of the box). The standard padding(top = X.dp) measures from the box edge, not from the text’s baseline. Using a custom modifier, you can achieve “padding from baseline”.

Here’s a simplified version:

fun Modifier.firstBaselineToTop(firstBaselineToTop: Dp) = layout { measurable, constraints ->
// Measure the composable (a Text)
    val placeable = measurable.measure(constraints)
// Get the first baseline (throw if no baseline found)
    val firstBaseline = placeable[FirstBaseline]
        .takeIf { it != AlignmentLine.Unspecified }
        ?: error("No baseline found!")
// Calculate the new height and position
    val placeableY = firstBaselineToTop.roundToPx() - firstBaseline
    val height = placeable.height + placeableY
    layout(placeable.width, height) {
// Place the text at (0, placeableY)
        placeable.placeRelative(0, placeableY)
    }
}

This modifier measures the text, reads its first baseline position, and then adjusts the layout height and Y offset so that the baseline ends up firstBaselineToTop from the top. Using it is simple:

Text("Hi there!", Modifier.firstBaselineToTop(24.dp))

Custom layout example: aligning a Text by its first baseline. The top part of the above image uses firstBaselineToTop(24.dp) to fix the distance from the top to the first line’s baseline, while the bottom uses normal top padding. This level of control is only possible by measuring the text’s baseline explicitly.

Without such a custom modifier, achieving consistent baseline spacing would require manual tweaking or nested layouts.

Now the question arises,
Why not just add top padding?
Answer: Normal padding adds space above the composable’s bounding box, not relative to the text baseline. For text, designers often want baseline alignment. The layout modifier allows full control: you measure the child (via measurable.measure), compute sizes, and call placeable.place(x, y). Anything not placed is invisible, so you have to carefully set layout(width, height) with your intended size.

Custom modifiers can do much more: you can intercept draw, handle touch, or enforce aspect ratios. The key is to think of them as mini-layout blocks. And remember to make your modifiers extension functions on Modifier so they chain nicely.

Pro Insight:
If you find yourself writing the same measurement code in multiple places, factor it out as a modifier (or a reusable Layout). For example, you could create a Modifier.customCircularLayout(...) that arranges children in a circle, or a Modifier.gradientBackground() that draws a gradient. These abstractions make your UI code declarative and concise.

8️⃣ Master Animations with updateTransition & Coroutines 🎞️

Compose’s animation APIs are very powerful. Beyond simple animate*AsState, Transition and updateTransition let you synchronize multiple animated values based on a target state.

Here’s how you can animate a box’s color and size together when a boolean state changes:

enum class BoxState { Collapsed, Expanded }

@Composable
fun AnimatingBox(boxState: BoxState) {
// Create a Transition backed by the current boxState
    val transition = updateTransition(targetState = boxState, label = "BoxTransition")

// Animate color between Gray and Red based on state
    val color by transition.animateColor(label = "color") { state ->
        if (state == BoxState.Collapsed) Color.Gray else Color.Red
    }
// Animate size between 64.dp and 128.dp
    val size by transition.animateDp(label = "size") { state ->
        if (state == BoxState.Collapsed) 64.dp else 128.dp
    }

    Box(
        Modifier
            .size(size)
            .background(color)
    )
}

In this snippet, updateTransition watches boxState. When boxState changes, the transition runs both animateColor and animateDp in parallel, interpolating their values over time. This ensures the color and size animations start and end together. You can even use easing functions, keyframes, or spring specs inside animate* blocks.

Another tip:
For continuous or repeating animations, use rememberInfiniteTransition.
For example, to pulse a color back and forth:

val infiniteTransition = rememberInfiniteTransition()
val color by infiniteTransition.animateColor(
    initialValue = Color.Green,
    targetValue = Color.Blue,
    animationSpec = infiniteRepeatable(
        animation = tween(1000, easing = LinearEasing),
        repeatMode = RepeatMode.Reverse
    )
)
Box(Modifier.fillMaxSize().background(color))

This will smoothly animate between green and blue forever.

Pro Insight:
For very complex animations (like full-screen transitions or choreographed sequences), extract your animation logic into a separate composable or even a custom AnimationSpec class. You can create data classes that hold multiple State values from a Transition and return them together. This decouples the “animation data” from the UI, making testing and reuse easier.

9️⃣ Write Robust UI Tests with Compose’s Testing API ✅

Testing Compose UIs is surprisingly straightforward using the official testing APIs. Start with createComposeRule() (or createAndroidComposeRule if you need an Activity).

Here’s a basic example of a UI test:

@get:Rule
val composeTestRule = createComposeRule()

@Test
fun testGreeting() {
    composeTestRule.setContent {
        MyAppTheme {
            MainScreen() // Your composable under test
        }
    }
// Find a button or text and perform actions/assertions
    composeTestRule.onNodeWithText("Continue").performClick()
    composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()
}

This uses the semantics tree under the hood: onNodeWithText("...") finds composables with that text content. The test automatically waits for the UI to become idle before proceeding, so you don’t have to manage synchronization. You can also query by content descriptions, tags (Modifier.testTag("myTag")), or use .onNodeWithTag("myTag") for non-text items.

Do I always need to use createAndroidComposeRule<MainActivity>()?
Only if your composable depends on an Activity or you need to test intents/permissions. For most pure UI tests, createComposeRule() is sufficient. It’s lightweight and doesn’t require launching an entire Activity.

Remember to tag important elements with testTag if there’s no visible text. For example, if you have an Icon button, you might do:

IconButton(
    onClick = { /*...*/ },
    modifier = Modifier.testTag("SettingsButton")
) { /* icon content */ }

Then in tests: onNodeWithTag("SettingsButton").performClick(). This makes your tests robust against text changes.

Pro Insight:
Automating your Compose UI tests early can pay huge dividends. Use composeTestRule.setContent to inject fake ViewModels or state for isolated testing. Because Compose tests use semantics, they naturally support both Compose and older View UIs together. And don’t forget to run tests on multiple screen sizes or configurations for true confidence (there are Compose test utilities for different densities and font scales as well).

🔟 Interop with Views + Profile Performance Like a Pro 👀

Even in a fully Compose app, you’ll often need interoperability with the Android View system. There are two directions:

• Compose in XML Views: You can add a <androidx.compose.ui.platform.ComposeView> in an XML layout or a Fragment/Activity. In code, find that view and call setContent { ... } on it. Be sure to set a ViewCompositionStrategy. For example:

// In a Fragment using XML layout with a ComposeView
val composeView = view.findViewById(R.id.compose_view)
composeView.apply {
// Dispose the Compose tree when the view's LifecycleOwner is destroyed
    setViewCompositionStrategy(ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed)
    setContent {
        MaterialTheme {
            Text("Hello Compose in XML!")
        }
    }
}

This snippet inflates an XML with a ComposeView, then uses setContent { } to host Compose UI within it. The ViewCompositionStrategy ensures Compose cleans up resources appropriately. Similarly, you can use AndroidView inside Compose to embed traditional Views. For example, if you want to show a legacy MapView or a custom view inside your Compose UI, do:

AndroidView(
    modifier = Modifier.fillMaxSize(),
    factory = { context -> MyCustomLegacyView(context) },
    update = { view ->
// Optionally update the view with new parameters
        view.setData(viewModel.data)
    }
)

In newer Compose versions (1.4.0+), there’s even an overload of AndroidView for lazy lists that reuse the same View instance when items get recycled. It introduces onReset and onRelease callbacks so you can clear state when the view is reused (similar to ViewHolder patterns).

Gradual migration and reusing mature components. Many apps have decades of Android View code or libraries. Interop allows adopting Compose piecemeal. Eventually, you might move all the way to Compose, but until then, these bridges let you combine the best of both worlds.

Finally, profile performance. Android Studio’s tools (mentioned earlier) are key. Use the Layout Inspector’s recomposition counters (Figure below shows enabling “Show Recomposition Counts”) to spot unexpected updates. In the Android Profiler / System Trace, look at the Compose section: it can tell you how long compose, measure, and draw take per frame.

Android Studio Layout Inspector view: enable “Show Recomposition Counts” to see how often each composable is re-running. Here the AnimatedContent composable is recomposing 48 times, which may indicate a performance issue to investigate.

If you detect jank or excessive recompositions, revisit your code: use remember, lift state, or simplify your layout. Also consider baseline profiles or startup tracing (outside Compose scope) to speed up app launch.

Pro Insight:
Performance tuning is an ongoing process. Regularly profile your app on real devices. Remember that Compose is still evolving; newer compiler optimizations may change what costs the most. Stay updated on Jetpack Compose releases and experiment with things like Modifier.Node (for custom drawing) or snapshot API tweaks in critical sections if you hit limits.

Jetpack Compose is more than just a new way to build UI - it’s a mindset shift. These tricks helped me write cleaner, faster, and more maintainable code, and I hope they do the same for you.

💬 Which tip did you find most useful, or what Compose trick do you swear by? Drop it in the comments! Let’s build a solid community of Compose developers helping each other grow.

If this article saved you some debugging hours or sparked an “Aha!” moment, consider giving it a like ❤️ and sharing it with your team or Twitter/X followers. And if you want more advanced Android and Kotlin insights, follow me here on Hashnode - I publish practical dev content weekly.

Previously, I published an article on advanced Kotlin features that resonated with many experienced developers. Since then, the language and ecosystem have grown significantly, unlocking even more hidden gems that remain largely underappreciated, even by senior Kotlin developers.

In this sequel, I'll take you through some of the most undervalued Kotlin features and techniques that can supercharge your productivity and improve your code quality. These are not the typical Kotlin features everyone talks about; instead, these are the tools and tricks that most developers overlook, yet can make a big difference in day-to-day coding and project architecture.

So buckle up, and let's dive into the Kotlin features that deserve more attention in 2025 and beyond.

Let’s kick things off with a feature that’s changing how we write cleaner APIs...

🛠️ 1. Context Receivers: Writing Functions That Make Sense in Context

If you think you know Kotlin inside out, think again. One of the coolest yet least used features introduced recently is Context Receivers. This feature lets you write cleaner, more modular code by explicitly declaring the context your functions or classes need, without cluttering your method signatures or passing extra parameters everywhere.

📌What are Context Receivers?

Imagine you have multiple “context” objects (like a database connection, a logger, or a configuration) that many functions need to access. Traditionally, you'd either pass these as parameters repeatedly or rely on global singletons -both messy and error-prone approaches.

With Context Receivers, Kotlin allows you to declare those contexts explicitly at the function or class level. This means you can use members of these context objects directly inside your functions, without passing them as parameters.

🤔Why should you care?

• Reduces boilerplate in large codebases where many functions depend on the same context objects

• Improves code readability by making the dependencies explicit and scoped

• Enables better modularity and easier testing

👨‍💻How to use?

class Logger {
    fun log(message: String) = println("Log: $message")
}

class Database {
    fun query(sql: String) = "Result of '$sql'"
}

context(Logger, Database)
fun fetchData() {
    log("Fetching data from database")
    val result = query("SELECT * FROM users")
    log("Query result: $result")
}

fun main() {
    val logger = Logger()
    val database = Database()

    with(logger) {
        with(database) {
            fetchData()
        }
    }
}

In this example, the fetchData() function explicitly declares that it requires Logger and Database contexts. Inside the function, you can directly call log() and query() without passing them as parameters.

🧪Real-world use cases

• Building DSLs where multiple context objects are needed, but you want clean, readable syntax

• Services or repositories accessing several shared resources, avoiding messy parameter passing

• UI components that require multiple context-like objects (theme, resources, handlers) in a clean, scoped way

🎯Mastering context receivers today will put you ahead as Kotlin continues evolving -it's a smart investment in your toolkit.

🧾 2. Kotlin Contracts: Make Your Code Smarter with Compiler-Assisted Guarantees

When you write Kotlin, you probably rely on standard null checks, smart casts, and conditions. But did you know Kotlin allows you to define contracts? Contracts give the compiler additional information about how your functions behave, enabling smarter code analysis, better optimization, and safer nullability checks.

🧠What are Kotlin Contracts?

Contracts are a way to describe the behavior of functions beyond their signatures, specifically how they affect control flow, argument nullability, and exceptions. They let the compiler understand conditions like:

• “If this function returns, then this parameter is guaranteed not to be null.”

• “This lambda is invoked exactly once.”

• “This function throws an exception under specific conditions.”

By declaring contracts, you empower the compiler to perform better smart casting, eliminate unnecessary checks, and warn about incorrect usage early.

😕Why do most developers miss this?

Contracts are still an experimental feature and require explicit enabling. Because they are underused, many senior developers don't even realize the power they can unlock, which means their code misses out on helpful compiler assistance.

⚙️How to enable Kotlin Contracts

Add the opt-in annotation in your build setup:

@OptIn(ExperimentalContracts::class)
fun someFunction() {
    // function body
}

Or enable it globally via compiler arguments in your Gradle configuration.

Add the following compiler argument to your build.gradle:

kotlin {
    sourceSets.all {
        languageSettings {
            optIn("kotlin.contracts.ExperimentalContracts")
        }
    }
}

This opt-in ensures your entire module can use contracts without repeating the annotation on every function.

🚫Typical Code Without Contracts

Let's say you're writing a utility to validate a nullable input and continue only if it's non-null:

fun requireNonNull(value: String?) {
    if (value == null) throw IllegalArgumentException("Value cannot be null")
}

fun useValue(value: String?) {
    requireNonNull(value)
    println(value.length) // ⚠️ Smart cast doesn't work here!
}

Kotlin doesn't smart cast value here - because it doesn't know that requireNonNull() guarantees non-null on return.

✅With Kotlin Contracts

Now watch this:

import kotlin.contracts.*

@OptIn(ExperimentalContracts::class)
fun requireNonNull(value: Any?) {
    contract {
        returns() implies (value != null)
    }
    if (value == null) throw IllegalArgumentException("Value cannot be null")
}

fun demo(value: Any?) {
    requireNonNull(value)
    // After requireNonNull, Kotlin smart casts 'value' to non-null automatically
    println(value.hashCode()) // No need for null checks here
}

With the contract in place, Kotlin's compiler now understands the condition and treats value as non-null after the call.

💡Use cases where contracts shine

• Custom assertions and validation functions

• Control flow helpers that influence program execution paths

• Lambda invocation control (how many times a lambda is called, etc.)

• Optimizing code for safety and readability by reducing boilerplate null checks or redundant conditionals

🧙 3. The Secret Sauce Behind Beautiful DSLs: @BuilderInference

Ever wondered how Jetpack Compose or kotlinx HTML manages to infer types so well in deeply nested builders? The answer lies in one of Kotlin's most underused yet powerful tools -the @BuilderInference annotation.

Most Kotlin developers either misuse this or don't even know it exists. But once you get it, you'll start writing DSLs and extension lambdas like a magician.

⚠️The Problem: Type Inference Falls Apart in Lambdas

Let's say you want to build a generic utility that creates a list using a builder pattern:

fun buildSmartList(builder: MutableList<T>.() -> Unit): List {
    return buildList { builder() }
}

Now try using it like this:

val items = buildSmartList {
    add("Hello")
    add("World")
}

🔴 Uh-oh, the Kotlin compiler can't infer what T is. You'll get this:

“Cannot infer type parameter T."

Why? Because Kotlin doesn't perform type inference deeply enough inside lambda receivers when generics are involved.

💡The Fix: Add @BuilderInference

Here's how to make Kotlin smarter:

fun buildSmartList(
    @BuilderInference builder: MutableList<T>.() -> Unit
): List {
    return buildList { builder() }
}

Now you can call it like this, without specifying any type:

val items = buildSmartList {
    add("Kotlin")
    add("Rocks")
}

✅ This works perfectly. Kotlin now infers T as String.

🎯Where This Shines

This is incredibly useful when building domain-specific languages (DSLs), especially if you want to allow users to define behavior using intuitive syntax without fighting the type system.

You've probably used it unknowingly if you've ever written:

LazyColumn {
    items(listOf("A", "B")) { item ->
        Text(text = item)
    }
}

Internally, Compose uses @BuilderInference on many of these lambda receivers to infer types smartly.

🧱 4. Sealed Interfaces + Smart when : Exhaustive, Safer, and Cleaner

Most developers know about sealed class in Kotlin, it's one of the cleanest ways to model restricted hierarchies. But did you know Kotlin now supports sealed interfaces too? And that you can use them in powerful new ways to enforce exhaustiveness in when blocks, even across multiple hierarchies?

Let's dig into this, because it can seriously clean up your business logic and reduce runtime bugs.

📘The Basics: What's a Sealed Interface?

A sealed interface lets you define an interface that can only be implemented by a fixed set of types, just like how a sealed class restricts inheritance.

sealed interface UiState

data class Loading(val message: String) : UiState
data class Success<T>(val data: T) : UiState
data class Error(val throwable: Throwable) : UiState

This means that UiState can only be one of Loading, Success, or Error. No more. Not even by accident.

🔄Why Use a Sealed Interface Instead of a Sealed Class?

• Multiple inheritance: You can implement a sealed interface along with other interfaces or classes.

• Cleaner modeling: If you're defining behavior more than state, interface is a better fit.

• Better testability: Interfaces are naturally easier to mock or substitute during testing.

⚠️What Developers Often Do (And Why It's Risky)

Here's a common pattern seen in older Kotlin code:

interface UiState

class Loading : UiState
class Success : UiState
class Error : UiState

fun handle(state: UiState) {
    when (state) {
        is Loading -> { /* show spinner */ }
        is Success -> { /* show data */ }
        is Error -> { /* show error */ }
        else -> { /* this should never happen... */ }
    }
}

Notice that ugly else? It's mandatory because the compiler can't guarantee exhaustiveness on open interfaces.

This means: if someone adds a new implementation tomorrow, and forgets to update the when - boom. Silent logic failure.

✅How Kotlin Sealed Interface Fixes This

With sealed interfaces, you now get compile-time exhaustiveness:

fun handle(state: UiState) = when (state) {
    is Loading -> { /* show spinner */ }
    is Success -> { /* show data */ }
    is Error -> { /* show error */ }
    // ❌ no need for else - compiler ensures we handled all cases
}

Much better, right?

🔥Real-World Use Case: Combining Sealed Interface with MVI

Imagine modeling screen states in a robust MVI architecture:

sealed interface ScreenState

object Loading : ScreenState
data class Content(val data: List<String>) : ScreenState
data class Error(val message: String) : ScreenState

Now, in your Composable:

@Composable
fun Screen(state: ScreenState) {
    when (state) {
        is Loading -> ShowLoading()
        is Content -> ShowContent(state.data)
        is Error -> ShowError(state.message)
    }
}

No risk of accidentally forgetting to handle a new screen state. The compiler has your back.

🤯Bonus: Nested Sealed Interfaces with Smart when

Kotlin 1.8+ even allows nested sealed interfaces -combine this with smart when expressions, and you get some seriously expressive modeling. For example:

sealed interface NetworkResult {
    sealed interface Success : NetworkResult {
        data class Data(val content: String) : Success
        object Empty : Success
    }

    data class Failure(val reason: String) : NetworkResult
}

This allows you to precisely structure the outcomes of a network request and enforce handling at each level.

🧠 Pro tip: Use sealed interface when you're defining behavior categories, and sealed class when your types share common properties.

🖼️ 5. Making Compose APIs Cleaner with Function References & Receiver Lambdas

Jetpack Compose's declarative UI shines when your code is clean and easy to read. Two powerful yet often underused Kotlin features - function references and lambdas with receivers - can help you write Compose code that's more concise and expressive.

🔗What are Function References?

Function references let you pass functions around as first-class citizens without explicitly writing lambda expressions every time.

Instead of writing this:

Button(onClick = { onClickHandler() }) {
    Text("Click Me")
}

You can use a function reference:

Button(onClick = onClickHandler) {
    Text("Click Me")
}

This small change improves readability and avoids unnecessary lambda overhead.

📦Lambdas with Receivers in Compose

Lambdas with receivers let you write blocks of code where the receiver object becomes the implicit this. This is heavily used in Compose DSLs for building UI trees.

For example:

Column {
    Text("Hello")
    Button(onClick = { /*...*/ }) {
        Text("Click Me")
    }
}

Here, the Column's lambda has a receiver of type ColumnScope, so you can call UI functions directly inside it.

🔄Combining Both for Cleaner APIs

Sometimes Compose APIs expect lambdas with receivers, but you want to reuse existing functions that don't match the signature exactly. Kotlin's feature called function references with receivers (or context receivers) can bridge this gap, allowing you to pass function references where lambdas with receivers are expected.

This helps avoid verbose inline lambdas and makes your composable calls cleaner.

🧑‍🏫Real-World Example

Say you have a reusable function:

fun ButtonScope.myButtonContent() {
    Text("Reusable Button")
}

You can pass this as a function reference when Compose expects a lambda with a receiver:

Button(onClick = { /* do something */ }, content = ::myButtonContent)

This makes your composable invocations concise and your reusable UI logic easy to manage.

😬Why Most Developers Miss This

Despite the clarity and conciseness these features provide, many developers don't fully leverage them because the syntax can look unfamiliar at first, and IDE support for some edge cases is still evolving.

⚡ 6. Value Classes: Boost Performance with Zero-Overhead Wrappers

Kotlin's Value Classes (formerly known as Inline Classes) are a game-changer for optimizing performance while keeping your code clean and type-safe. Despite being available since Kotlin 1.5, many developers - even experienced ones - still don't fully leverage them.

ℹ️What Are Value Classes?

Value classes allow you to create a wrapper around a single property without the usual runtime overhead of object allocation. The Kotlin compiler tries to inline these wrappers during compilation, resulting in zero runtime cost in most cases.

@JvmInline
value class UserId(val id: String)

Here, UserId behaves like a String at runtime, but gives you strong type safety at compile time, avoiding accidental mix-ups with other strings.

📈Why Should You Use Value Classes?

• Zero runtime overhead: No extra objects created for the wrapper.

• Improved type safety: Prevent bugs from passing the wrong primitive types around.

• Better readability: Express your domain model clearly without clutter.

🛠️Practical Example

Suppose you have multiple ID types (UserId, ProductId) represented as strings:

@JvmInline
value class UserId(val id: String)

@JvmInline
value class ProductId(val id: String)

fun getUserName(userId: UserId): String { /*...*/ }
fun getProductName(productId: ProductId): String { /*...*/ }

The compiler prevents you from accidentally passing a ProductId to getUserName—which would be impossible if you used plain String.

🧠Important Notes

• Value classes require Kotlin 1.5 or higher.

• They support most basic operations and can implement interfaces.

• They cannot have init blocks or backing fields.

• Interoperability with Java can be tricky; sometimes the wrapper becomes a real object at runtime.

🧑‍💼Best Practices

• Use value classes to improve domain modeling in your app.

• Avoid overusing them for complex data - stick to wrapping single primitive or immutable types.

• Check interoperability if your project uses mixed Kotlin-Java codebases.

🧩Conclusion

Kotlin's power goes far beyond its surface-level features, and the six underrated capabilities we explored today prove exactly that. From context receivers that bring cleaner, safer APIs, to value classes that boost performance with zero overhead, these hidden gems can fundamentally change how you write, structure, and optimize your code.

Leveraging these advanced features isn't about just following trends - it's about building scalable, maintainable, and future-proof applications. The tools are here; the difference now lies in how boldly and smartly you use them.

I encourage you to experiment with these features in your real projects. Push their boundaries, combine them in creative ways, and notice how they improve your code quality and developer experience.

Got your own favorite “hidden” Kotlin feature or a clever trick? Share it in the comments below - let's build a community of Kotlin enthusiasts who raise the bar together.

Show some love with a like—it helps others discover these hidden Kotlin gems and supports me in creating more high-value content just for you.

✍️ Follow The Modular Mindset for weekly Kotlin deep-dives and engineering strategies for the modern developer.

🔔 Bookmark this space or follow The Modular Mindset on Hashnode to catch the next Kotlin deep-dive.

How much of my world is shaped by artificial intelligence?

The answer? Almost all of it.

AI didn’t arrive like a lightning bolt. It crept in invisibly, quietly, and with calculated precision. From our smartphones and streaming services to our cars and job applications, it has woven itself into the daily fabric of our existence. We welcomed it in the name of convenience, and now, it lives among us - not just as a tool, but increasingly as a decision-maker, a creator, and for some, even a companion.

From Fiction to Function

Just a few decades ago, artificial intelligence lived mostly in the realm of science fiction. Think of HAL 9000 from 2001: A Space Odyssey, the replicants in Blade Runner, or the seductive AI in Her. These stories warned us, amazed us, and sparked philosophical debates. Could machines ever think? Feel? Replace us?

Back then, such futures felt distant. But today, some of those same questions are knocking on our doors.

Now we talk to machines. We trust them with our money, our emotions, even our health. What was once a cinematic spectacle is now a mundane reality - delivered via sleek apps, neural nets, and invisible algorithms. The fictional future has become a functioning present.

The Trade-Off We Never Noticed

The most remarkable part? We didn’t even notice when the shift happened.

AI was supposed to help us. And in many ways, it still does. But in the background, something subtle is unfolding. We are no longer just using AI - we are starting to depend on it. We defer to it. We shape our behaviors to align with it. We let it finish our sentences, design our logos, diagnose our diseases, and recommend who we should date, hire, or fire.

This shift is not just technological - it’s deeply emotional. And philosophical.

Because at its core, the real question isn’t about what AI can do.
It’s about what we want to become in the presence of it.

We’ve built something that can think faster than us, learn faster than us, and eventually - if we’re not careful - replace what made us human in the first place.

A Quiet Revolution, or a Silent Surrender?

This brings us to a pivotal question, one that this series will keep returning to:

Are we building a better world   or a synthetic one?

One where convenience trumps curiosity.
Where precision replaces passion.
Where algorithms echo louder than human voices.

We stand on the edge of a tipping point. Whether we fall or fly depends not on the intelligence of our machines, but on the wisdom of our choices. And if we continue to let AI evolve without deliberate direction - not just technical, but ethical and emotional - are we accelerating toward a world where,

we no longer recognize what it means to be human?

What Is Artificial Intelligence, Really?

Let’s strip away the buzzwords for a moment.

Artificial Intelligence is not magic, and it’s certainly not sentient - at least not yet. At its core, AI is a set of computer systems designed to perform tasks that typically require human intelligence. Think learning, reasoning, problem-solving, understanding language, recognizing patterns, or even generating creative content.

But what makes it different from traditional software? Let’s break it down.

🤖 Traditional Software vs. Artificial Intelligence

Most traditional software follows explicit rules:
If X happens, do Y.

For example, a tax calculator simply applies a set of rules (pre-programmed by a human) to compute your refund. It cannot adapt or learn from new data on its own.

AI, on the other hand, is designed to learn from patterns in data and improve over time. Instead of telling it what to do step-by-step, we feed it data, and it figures out the rules by itself.

Traditional software is like a cookbook. AI is like a chef who experiments, learns, and creates new recipes on their own.

This is why AI systems can recognize your face in a crowd, recommend your next favorite song, or summarize a research paper, without being explicitly told how to do each step.

🧠 The Many Faces of AI: Understanding the Branches

AI isn’t a single technology. It’s an umbrella term that covers several specialized fields, each serving a different purpose. Here’s a breakdown of the major branches,  along with real-world examples you likely interact with every day.

1. Machine Learning (ML)

“Learning from data to make predictions or decisions.”

Machine learning is the engine behind most modern AI systems. Instead of being explicitly programmed, ML models learn from massive amounts of data to identify patterns and make decisions.

🔍 Example:
Netflix uses ML to analyze your watch history, the time you spend on each show, and even when you stop watching,  to recommend what you’re most likely to enjoy next.

Other examples:

• Spam filters in email

• Credit card fraud detection

• Personalized news feeds

Types of ML include:

• Supervised learning (learning from labeled data)

• Unsupervised learning (finding patterns in unlabeled data)

• Reinforcement learning (learning by trial and error)

2. Natural Language Processing (NLP)

“Understanding and generating human language.”

NLP enables machines to read, write, understand, and even respond to human language. This field combines computer science with linguistics to make language-based interactions with machines possible.

💬 Example:
ChatGPT is a perfect use case. It understands your questions, generates coherent responses, and can even mimic writing styles or summarize complex topics.

Other real-world uses:

• Voice assistants like Alexa and Siri

• Sentiment analysis in social media

• Translation apps (e.g., Google Translate)

• Customer service chatbots

3. Generative AI

“Creating new content - text, images, audio, and even video.”

This is one of the most exciting and controversial branches. Generative AI doesn’t just understand, it creates. These systems learn patterns from training data and use that understanding to generate new content that looks and feels real.

🎨 Example:

• Midjourney and DALL·E generate stunning artwork from text prompts.

• OpenAI’s Sora is pushing the boundaries by generating realistic video from simple ideas.

Other use cases:

• AI-generated music

• Deepfake videos

• Copywriting tools

• Code generation

The power is incredible, but so are the risks, especially in misinformation and ethical boundaries.

4. Robotics

“Machines that interact with the physical world, powered by AI.”

While not all robots are “intelligent,” AI-powered robotics is where machine learning meets machinery. These systems not only move and perform tasks, but also adapt to their environments in real-time.

⚙️ Example:

• Tesla’s Optimus robot aims to perform human-like tasks,   from carrying boxes to interacting with people.

• Amazon’s warehouse robots sort, move, and deliver packages based on dynamic needs and sensor feedback.

Other applications:

• Surgical robots

• Drones used in agriculture and defense

• Self-driving cars (which combine robotics, vision, and ML)

🧩 Why This Matters

Understanding these branches is more than just tech trivia.

Each branch represents a layer of influence in your life  -  what you read, what you watch, how you work, and even how you feel. And knowing how AI works makes you less likely to be blindly influenced by it.

Because the truth is: AI is not neutral.
It reflects the data it’s trained on, the values of its creators, and the objectives of those who deploy it.

That’s why it’s not enough to ask, “What can AI do?”
We must also ask, “Who decides what it should do  and why?”

The Origin Story: Why Was AI Created?

Artificial Intelligence didn’t emerge overnight; it was the culmination of decades of curiosity, ambition, and relentless pursuit of understanding human cognition. The journey began in the mid-20th century, driven by pioneers who envisioned machines that could emulate human thought processes.

🧠 The Visionaries Behind AI

Alan Turing, a British mathematician and logician, is often regarded as the father of theoretical computer science and artificial intelligence. In his seminal 1950 paper, “Computing Machinery and Intelligence”, Turing posed the provocative question: “Can machines think?”. To explore this, he introduced the concept of the Turing Test, a method to assess a machine’s ability to exhibit intelligent behavior indistinguishable from that of a human.

John McCarthy, an American computer scientist, took these ideas further. In 1956, he organized the Dartmouth Conference, where the term “Artificial Intelligence” was coined, marking the official birth of AI as a field of study. McCarthy also developed LISP, a programming language that became foundational in AI research.

📜 Milestones in AI Development

• 1950: The Turing Test
  Turing’s proposal laid the groundwork for evaluating machine intelligence, emphasizing the importance of indistinguishable behavior over internal processes.

• 1966: ELIZA Chatbot
  Developed by Joseph Weizenbaum, ELIZA was one of the first programs to simulate human-like conversation, mimicking a psychotherapist by rephrasing user inputs. While simple, it demonstrated the potential of machines to engage in human-like interactions.

• 1997: IBM’s Deep Blue Defeats Garry Kasparov
  In a historic match, IBM’s Deep Blue supercomputer defeated world chess champion Garry Kasparov, showcasing AI’s ability to handle complex, strategic tasks.

• 2011: IBM Watson Wins Jeopardy!
  IBM’s Watson competed against and defeated two of Jeopardy!’s greatest champions, demonstrating advanced natural language processing and information retrieval capabilities.

• 2018–2023: OpenAI’s GPT Milestones
  OpenAI introduced a series of Generative Pre-trained Transformers (GPT), with GPT-3 in 2020 boasting 175 billion parameters, enabling it to generate human-like text. In 2023, GPT-4 further advanced these capabilities, passing the Turing Test by convincing over half of the participants that they were interacting with a human.

The True Purpose of AI: Empower, Not Replace

Artificial Intelligence was conceived not to overshadow human capabilities but to augment them. The foundational vision of AI emphasized collaboration - machines assisting humans in tasks, enhancing efficiency, and expanding possibilities. However, as AI’s capabilities have grown, so have concerns about its role in society.

🤝 AI as an Assistive Partner

At its core, AI was designed to handle repetitive, data-intensive tasks, allowing humans to focus on creativity, empathy, and complex decision-making. This partnership aimed to elevate human potential, not diminish it.

Real-World Applications Enhancing Human Capabilities

1. Accessibility Tools for the Visually Impaired

AI has revolutionized accessibility, offering tools that empower visually impaired individuals to navigate the world more independently.

• Be My Eyes: This app connects blind users with sighted volunteers for real-time assistance. Its AI-powered “Virtual Volunteer” feature provides instant visual descriptions, enhancing autonomy.

• OKO AI Copilot: Utilizing smartphone cameras, OKO identifies pedestrian signals, audibly informing users when it’s safe to cross streets, thereby improving safety.

2. AI in Disaster Prediction and Relief

AI’s predictive capabilities are instrumental in disaster management, enabling proactive responses and saving lives.

• Hurricane Forecasting: In October, AI models accurately predicted Hurricane Milton’s landfall near Siesta Key, Florida, allowing for timely evacuations. source

• Multilingual Alerts: The National Weather Service partnered with AI translation services to deliver rapid, multilingual emergency alerts, reducing translation times from an hour to just 10 minutes. source

3. AI in Medical Diagnosis

AI enhances diagnostic accuracy and efficiency, supporting healthcare professionals in delivering better patient outcomes.

• Thyroid Disorder Diagnosis: At HealthCity Vistaar Hospital in Lucknow, AI integration has improved the accuracy of thyroid disorder diagnoses, facilitating personalized treatment strategies.

• Ambient Clinical Documentation: AI-driven ambient listening tools, like Microsoft’s DAX Copilot, automate clinical documentation during doctor-patient interactions, reducing physician burnout and enhancing patient engagement.

These examples are just the tip of the iceberg. AI is also revolutionizing fields like agriculture, where it’s used for precision farming to optimize crop yields; finance, where it enhances fraud detection and risk assessment; and education, through personalized learning platforms that adapt to individual student needs. The potential applications of AI are vast and continually expanding, offering innovative solutions across virtually every industry.

🧠 Final Thoughts: A Future Still in Our Hands

Artificial Intelligence has quietly become a part of our everyday lives. It’s in our phones, our homes, and even our workplaces. It didn’t arrive with a big bang but slipped in through helpful apps and smart devices.

At first, AI was created to assist us   in making tasks easier and help us solve problems. And in many ways, it still does. It helps doctors diagnose illnesses, supports people with disabilities, and predicts natural disasters to keep us safe.

But as AI becomes more advanced, we need to ask ourselves: Are we still in control? Are we using AI as a tool, or are we letting it shape our choices and behaviors?

The future of AI depends on the decisions we make today. We must ensure that AI continues to serve us, not the other way around.

This journey is just beginning.

💡 What’s Coming Next…

In the next part of this series, we’ll explore how Artificial Intelligence, once envisioned as a tool to uplift humanity, has been steered by profit-driven motives. We’ll delve into how the influx of big data and venture capital has reshaped AI’s trajectory, leading to concerns about privacy, misinformation, and our growing dependence on technology.

We’ll examine real-world examples where AI’s capabilities have been misused, such as social media algorithms fostering echo chambers, and AI-generated content blurring the lines between reality and fabrication. These instances highlight the ethical dilemmas and societal impacts arising from AI’s commercialization.

By understanding these developments, we can better navigate the complexities of AI in our lives and make informed decisions about its role in our future.

So stay with me - because the story of AI isn't just about machines.

It’s about us.

✍️ Follow The Modular Mindset for weekly explorations into AI, human behavior, and the shifting landscape of modern technology.

🔔 Don’t miss the next part - just hit Follow on the publication to stay in the loop.

But here's the problem: most tutorials stop at the basics. They cover smart casts, null safety and data class, but they don't explore the advanced tools that truly make Kotlin shine in production environments.

This article is for those who've been shipping apps, debugging production crashes, and managing complex codebases - and are ready to go deeper.

Below are 8 underrated yet powerful Kotlin features that can elevate your code to new levels of readability, safety, and performance.

1. Higher-Order Functions: Functional Power in Practice

Kotlin makes functional programming first-class. With higher-order functions, you can pass behavior as parameters. This leads to reusable, expressive, and clean APIs.

fun calculate(a: Int, b: Int, operation: (Int, Int) -> Int): Int {
    return operation(a, b)
}

val sum = calculate(10, 20) { a, b -> a + b }
val difference = calculate(10, 20) { a, b -> a - b }

✅ Why it matters: Enables clean abstraction, especially in reusable libraries or use-case classes.

💼 Real-World Example: In a typical Android repository pattern, you can define a generic method to wrap API calls and unify error handling:

suspend fun <T> safeApiCall(apiCall: suspend () -> T): Result<T> {
    return try {
        Result.success(apiCall())
    } catch (e: Exception) {
        Result.failure(e)
    }
}

// Usage in Repository
fun getUser(id: String): Flow<Result<User>> = flow {
    emit(safeApiCall { userService.fetchUser(id) })
}

Here, safeApiCall is a higher-order function that accepts a suspendable lambda and returns a unified Result<T>. This pattern makes your data layer significantly cleaner and easier to debug or test.

🔥 Pro Tip: Combine with inline functions for performance in critical sections.

2. Lambdas: Your Code's Secret Weapon

Lambdas are concise, anonymous functions. They shine when used with Kotlin's collection APIs:

val evenNumbers = listOf(1, 2, 3, 4, 5).filter { it % 2 == 0 }

✅ Why it matters: Simplifies operations like filtering, mapping, and chaining transformations.

💼 Real-World Example: Suppose you're building a search feature in a news app and want to filter articles by title keywords:

data class Article(val title: String, val content: String)

val articles = listOf(
    Article("Kotlin 1.9 Released", "Details on the new version..."),
    Article("Understanding Coroutines", "Concurrency made easier..."),
    Article("Jetpack Compose Basics", "UI with less boilerplate...")
)

val keyword = "Kotlin"
val filtered = articles.filter { it.title.contains(keyword, ignoreCase = true) }

Here, the lambda helps isolate business logic clearly - no need for verbose loops or custom classes.

🔥 Pro Tip: Prefer trailing lambdas and implicit it for readability - but use named parameters for clarity in nested lambdas. For example:

val result = buildString {
    listOf("One", "Two", "Three").forEach { append("- $it") }
}
println(result)

This lambda-heavy pattern is great for DSLs, adapters, and Compose builders.

3. Coroutines: Simplifying Async at Scale

Kotlin Coroutines are more than just syntactic sugar - they are a paradigm shift in how you structure concurrency. They provide structured concurrency, which means your async jobs are bound to a parent scope. This makes cancellation predictable and resource cleanup automatic.

suspend fun fetchData(): String = withContext(Dispatchers.IO) {
    delay(1000) // Simulate network call
    "Data fetched"
}

fun showData() {
    CoroutineScope(Dispatchers.Main).launch {
        val data = fetchData()
        println(data)
    }
}

✅ Why it matters: Coroutines simplify background tasks, allow cleaner try/catch for error handling, and eliminate callback hell. They're built for modern Android components, like Jetpack Compose and ViewModel.

💼 Real-World Example: When fetching UI data in Jetpack Compose, you might use viewModelScope to tie the job to a ViewModel's lifecycle:

class UserViewModel : ViewModel() {
    var userData by mutableStateOf<String?>(null)
        private set

    fun loadUser() {
        viewModelScope.launch {
            userData = fetchData()
        }
    }
}

This ensures that if the ViewModel is cleared (say, on config change or navigation), your coroutine job is canceled too, preventing memory leaks or wasted CPU cycles.

🔥 Pro Tip: Use supervisorScope to isolate failures in sibling coroutines, and leverage CoroutineExceptionHandler for graceful fallback strategies. Always prefer lifecycle-aware scopes like viewModelScope or lifecycleScope in Android projects.

Structured concurrency + proper scope usage = async code that scales and survives real-world complexity.

4. Extension Properties: Add Power Without Inheritance

You already know about extension functions, but extension properties are often overlooked:

val String.firstChar: Char
    get() = this[0]

val name = "Kotlin"
println(name.firstChar) // Outputs: K

✅ Why it matters: Cleaner syntax for computed properties. Great for utility modules.

🔥 Pro Tip: Avoid mutable state or heavy logic - keep them fast and side-effect free.

5. Sealed Classes: Pattern Matching, the Kotlin Way

Sealed classes are Kotlin's way of enabling type-safe, exhaustive when expressions - essentially empowering your code with algebraic data types. Unlike regular class hierarchies or Java-style enums, sealed classes enforce compile-time constraints: all subclasses must be defined in the same file. This means the compiler knows every possible type a sealed class can take, allowing for safer and more expressive control flow.

sealed class Result
class Success(val data: String) : Result()
class Error(val message: String) : Result()

fun handle(result: Result) = when (result) {
    is Success -> println(result.data)
    is Error -> println(result.message)
}

✅ Why it matters: Enables exhaustive pattern matching, which means that if a new subclass is added later, the compiler will warn you about unhandled cases in your when blocks - something enums can't do when carrying complex state or associated data.

🔄 Comparison with Enums: Enums are perfect for simple, flat choices, like Color.RED, Color.BLUE, etc. - but sealed classes can hold data and behavior, which makes them ideal for modeling UI states, network responses, or any domain-specific result.

For example, while enums are value-based, sealed classes support full polymorphism. You can define different behavior inside each subclass, and even nest logic, which you can't do cleanly with enums:

sealed class UiState {
    object Loading : UiState()
    data class Success(val data: List<String>) : UiState()
    data class Error(val error: Throwable) : UiState()
}

fun render(state: UiState) = when (state) {
    UiState.Loading -> showLoading()
    is UiState.Success -> showData(state.data)
    is UiState.Error -> showError(state.error)
}

This makes sealed classes a go-to pattern for modern UI architectures like MVI, where state modeling and predictability are crucial.

🔥 Pro Tip: As of Kotlin 1.7+, sealed interfaces allow you to combine the power of sealed classes with multiple inheritance. You can model orthogonal traits while still preserving exhaustive when handling:

sealed interface NetworkResult
class Success(val data: String) : NetworkResult
class Failure(val reason: String) : NetworkResult

🧠 Bottom Line: If enums are your hammer for flat states, sealed classes are the Swiss Army knife for expressive, hierarchical, and pattern-matchable modeling. Use them when you need a combination of safety, clarity, and power.

6. Inline Functions: Hidden Performance Boost

Kotlin lets you mark functions as inline, reducing lambda overhead:

inline fun measure(block: () -> Unit): Long {
    val start = System.currentTimeMillis()
    block()
    return System.currentTimeMillis() - start
}

val timeTaken = measure {
    // expensive task here
}

✅ Why it matters: Improves performance in hot paths, like UI measurement or analytics logging.

🔥 Pro Tip: Combine with reified to access type info at runtime (e.g., for generic logging).

7. Type Aliases: Rename Complexity Away

Typealiases make complex generics or data structures readable:

typealias Cart = MutableMap<Item, Int>

data class Item(val name: String, val price: Double)

val cart: Cart = mutableMapOf(
    Item("apple", 0.99) to 2,
    Item("banana", 0.79) to 3
)

✅ Why it matters: Makes APIs self-explanatory.

🔥 Pro Tip: Use for listener interfaces, callback types, or JSON parsing structures.

8. Delegated Properties: Behavior Injection at Its Finest

Delegation isn't just for lazy. You can delegate property logic to custom handlers, injecting behavior like validation, logging, or dynamic value resolution without cluttering your main class.

class Example {
    var data: String by DataDelegate()
}

class DataDelegate {
    private var _data: String? = null

    operator fun getValue(thisRef: Any?, property: KProperty<*>) =
        _data ?: throw IllegalStateException("Data not initialized")

    operator fun setValue(thisRef: Any?, property: KProperty<*>, value: String) {
        _data = value
    }
}

✅ Why it matters: Delegated properties offer a clean, reusable way to encapsulate common behaviors tied to property access and modification.

💼 Real-World Examples:

• Analytics Tracking: You can wrap setters in a delegate to automatically log when certain properties are updated.

    class AnalyticsDelegate<T>(private var value: T) {
        operator fun getValue(thisRef: Any?, property: KProperty<*>) = value
        operator fun setValue(thisRef: Any?, property: KProperty<*>, newValue: T) {
            println("[Analytics] ${property.name} changed to $newValue")
            value = newValue
        }
    }
  
    var screenName: String by AnalyticsDelegate("")
  

• Shared Preferences: Easily synchronize in-memory properties with disk-backed persistence.

    class PrefDelegate(context: Context, key: String, private val default: String) {
        private val prefs = context.getSharedPreferences("app", Context.MODE_PRIVATE)
  
        operator fun getValue(thisRef: Any?, property: KProperty<*>) =
            prefs.getString(key, default) ?: default
  
        operator fun setValue(thisRef: Any?, property: KProperty<*>, value: String) {
            prefs.edit().putString(key, value).apply()
        }
    }
  
    var username: String by PrefDelegate(context, "user_name", "guest")
  

• Database Field Syncing: For Room or Realm, you could build delegates that lazily load related fields or invalidate cached relationships.

🔥 Pro Tip: Kotlin provides out-of-the-box delegates like lazy, observable, and notNull() that handle many common use cases without custom boilerplate:

• lazy { expensiveComputation() }

• observable(initialValue) { prop, old, new -> onChange(old, new) }

• Delegates.notNull<String>() for lateinit-style properties with compile-time safety.

🧠 Bottom Line: Delegated properties aren't just syntactic sugar - they're a gateway to composable, maintainable, and DRY property logic. Start simple, and you'll find countless areas in your app architecture where they fit naturally.

Final Thoughts: Beyond the Basics

Kotlin isn't just a language. It's a toolbox for modern, maintainable software. These 8 features unlock patterns that used to require boilerplate or inheritance-heavy designs.

Whether you're scaling a Compose UI, optimizing a Ktor backend, or building a shared KMM library, each of these tools will serve you well.

➡️ Challenge: Pick one feature you haven't used before. Refactor a current project with it. You'll be amazed at the clarity it brings.

✍️ Follow The Modular Mindset for weekly Kotlin deep-dives and engineering strategies for the modern developer.

🔔 Subscribe to get notified when the next advanced guide drops.