DEV Community: Andrea Sunny

How To Choose and Implement Response Queues, Caching, and Logging in Alamofire on iOS

Andrea Sunny — Fri, 12 Jun 2026 05:14:30 +0000

How To Choose and Implement Response Queues, Caching, and Logging in Alamofire on iOS

Andrea Sunny — Fri, 12 Jun 2026 03:30:00 +0000

Efficient network handling can make or break the responsiveness and performance of your iOS app. While learning about Alamofire and URLSession, I discovered some important (and subtle) behaviors around response queues, especially why Alamofire defaults to processing responses on the main thread. Here’s what I learned, with practical code examples and tips for caching, prioritizing, retrying, and logging network requests efficiently.

Why Does Alamofire's Default Response Queue Matter?

When you use Alamofire for network calls, by default, it delivers completion handlers on the main thread. This design is intentional:

UI updates in iOS must happen on the main thread.
Many developers handle response parsing and UI updates together in the same callback.

However, this behavior can lead to subtle UI glitches or dropped frames if your response handler does any heavy work (parsing, decoding, DB writes). Understanding and managing your "response queue" is essential for performance-oriented apps.

For example:

// Alamofire by default delivers on main thread
AF.request("https://api.example.com/data").responseJSON { response in
    // This runs on the main thread! Good for UI work, bad for heavy parsing.
}

To process on a background thread (off the main queue):

let backgroundQueue = DispatchQueue(label: "com.example.network", qos: .userInitiated)
AF.request("https://api.example.com/data")
    .response(queue: backgroundQueue) { response in
        // Heavy parsing or computation here
        DispatchQueue.main.async {
            // Then update UI as needed
        }
    }

Comparing with URLSession

By contrast, URLSession calls its completion handlers on background threads by default. That means you'll usually need a DispatchQueue.main.async jump for UI updates.

guard let url = URL(string: "https://api.example.com/data") else { return }
let task = URLSession.shared.dataTask(with: url) { data, response, error in
    // This block runs on a background thread by default
    if let data = data {
        // Parse data off main
        DispatchQueue.main.async {
            // Update UI
        }
    }
}
task.resume()

Caching and Data Persistence: URLSession & Alamofire

Caching reduces network traffic and improves performance. Both URLSession and Alamofire support HTTP caching, but configuration is explicit.

URLSession example:

let cache = URLCache.shared
let config = URLSessionConfiguration.default
config.urlCache = cache
let session = URLSession(configuration: config)
// Use 'session' for requests

Alamofire leverages the same NSCache mechanisms by default, since it wraps URLSession.

If you want more granular caching, you can configure URLSessionConfiguration passed to Alamofire's Session.

Request Prioritization in Alamofire

Alamofire 5+ lets you set request priority using the underlying URLSessionTask priority property. This helps you control which requests the system should focus on if resources get tight (for example, prioritize user-facing data over background image downloads).

let session = Session()
session.request("https://api.example.com/critical").priority = .high
session.request("https://api.example.com/background").priority = .low

Logging Network Activity with Alamofire

Tracking all requests and responses is invaluable for debugging and analytics. Alamofire supports plugins like Network Activity Logger, which prints full request/response details to the console.

Add this handy tool:

import AlamofireNetworkActivityLogger
NetworkActivityLogger.shared.startLogging()
NetworkActivityLogger.shared.level = .debug

You’ll see all Alamofire calls logged.
Great for debugging and performance checks.

Error Handling and Retry Logic

Transients network errors happen – timeouts, disconnects, rate limits. Alamofire makes retries easy via its RetryPolicy.

Example: Retry up to 3 times with delay if receiving 429 (Too Many Requests):

import Alamofire

class CustomRetryPolicy: RetryPolicy {
    override func retry(_ request: Request, for session: Session, dueTo error: Error, completion: @escaping (RetryResult) -> Void) {
        if let response = request.task?.response as? HTTPURLResponse, response.statusCode == 429 {
            // Retry with delay
            completion(.retryWithDelay(5.0))
        } else {
            completion(.doNotRetry)
        }
    }
}

let session = Session(interceptor: CustomRetryPolicy())
session.request("https://api.example.com/data").response { response in
    // ...
}

Monitoring and Analytics

To gain insights and debug network performance, you can use:

NetworkActivityLogger (as above)
System tools (Network Link Conditioner, Instruments, etc.)
In-app analytics/logging (for error codes, slow/failed requests)
Third-party monitors (like Appxiom)

For more on real-world monitoring and debugging, the original blog post is a practical guide covering end-to-end network handling in Swift, including caching and retries.

What Developers Often Get Wrong

Assuming Alamofire's completion handler is always on a background thread: In reality, heavy parsing in Alamofire’s default completion will block the UI!
Forgetting DispatchQueue.main.async in URLSession: UI code crashes or doesn’t update if you update UIKit from the background.
Not configuring URLCache: Missing out on free performance gains from HTTP caching.
Ignoring request priority: Background image/data requests can starve urgent calls if priorities aren’t set correctly.
Neglecting network logging: Makes debugging timeouts and API errors much harder.
Overusing retry logic: Blindly retrying can amplify server load or lead to bad UX.

Key Takeaways

Alamofire delivers responses on the main thread by default. Use a custom response queue for heavy background work.
URLSession delivers on a background thread by default. Always call DispatchQueue.main.async for UI changes.
Apply caching using URLCache for both URLSession and Alamofire where possible.
Prioritize and manage requests - assign priorities for best user experience.
Log network traffic with tools like NetworkActivityLogger to debug and optimize.
Handle errors and retries thoughtfully - don’t blindly retry everything.
Monitor performance and failures using analytics or observability tools.

If you learned something new, check out the original guide for deeper technical explanations!

How To Choose and Implement Response Queues, Caching, and Logging in Alamofire on iOS

Andrea Sunny — Fri, 12 Jun 2026 03:30:00 +0000

Why Does Alamofire's Default Response Queue Matter?

When you use Alamofire for network calls, by default, it delivers completion handlers on the main thread. This design is intentional:

UI updates in iOS must happen on the main thread.
Many developers handle response parsing and UI updates together in the same callback.

For example:

// Alamofire by default delivers on main thread
AF.request("https://api.example.com/data").responseJSON { response in
    // This runs on the main thread! Good for UI work, bad for heavy parsing.
}

To process on a background thread (off the main queue):

let backgroundQueue = DispatchQueue(label: "com.example.network", qos: .userInitiated)
AF.request("https://api.example.com/data")
    .response(queue: backgroundQueue) { response in
        // Heavy parsing or computation here
        DispatchQueue.main.async {
            // Then update UI as needed
        }
    }

Comparing with URLSession

By contrast, URLSession calls its completion handlers on background threads by default. That means you'll usually need a DispatchQueue.main.async jump for UI updates.

guard let url = URL(string: "https://api.example.com/data") else { return }
let task = URLSession.shared.dataTask(with: url) { data, response, error in
    // This block runs on a background thread by default
    if let data = data {
        // Parse data off main
        DispatchQueue.main.async {
            // Update UI
        }
    }
}
task.resume()

Caching and Data Persistence: URLSession & Alamofire

Caching reduces network traffic and improves performance. Both URLSession and Alamofire support HTTP caching, but configuration is explicit.

URLSession example:

let cache = URLCache.shared
let config = URLSessionConfiguration.default
config.urlCache = cache
let session = URLSession(configuration: config)
// Use 'session' for requests

Alamofire leverages the same NSCache mechanisms by default, since it wraps URLSession.

If you want more granular caching, you can configure URLSessionConfiguration passed to Alamofire's Session.

Request Prioritization in Alamofire

let session = Session()
session.request("https://api.example.com/critical").priority = .high
session.request("https://api.example.com/background").priority = .low

Logging Network Activity with Alamofire

Tracking all requests and responses is invaluable for debugging and analytics. Alamofire supports plugins like Network Activity Logger, which prints full request/response details to the console.

Add this handy tool:

import AlamofireNetworkActivityLogger
NetworkActivityLogger.shared.startLogging()
NetworkActivityLogger.shared.level = .debug

You’ll see all Alamofire calls logged.
Great for debugging and performance checks.

Error Handling and Retry Logic

Transients network errors happen – timeouts, disconnects, rate limits. Alamofire makes retries easy via its RetryPolicy.

Example: Retry up to 3 times with delay if receiving 429 (Too Many Requests):

import Alamofire

class CustomRetryPolicy: RetryPolicy {
    override func retry(_ request: Request, for session: Session, dueTo error: Error, completion: @escaping (RetryResult) -> Void) {
        if let response = request.task?.response as? HTTPURLResponse, response.statusCode == 429 {
            // Retry with delay
            completion(.retryWithDelay(5.0))
        } else {
            completion(.doNotRetry)
        }
    }
}

let session = Session(interceptor: CustomRetryPolicy())
session.request("https://api.example.com/data").response { response in
    // ...
}

Monitoring and Analytics

To gain insights and debug network performance, you can use:

NetworkActivityLogger (as above)
System tools (Network Link Conditioner, Instruments, etc.)
In-app analytics/logging (for error codes, slow/failed requests)
Third-party monitors (like Appxiom)

For more on real-world monitoring and debugging, the original blog post is a practical guide covering end-to-end network handling in Swift, including caching and retries.

What Developers Often Get Wrong

Assuming Alamofire's completion handler is always on a background thread: In reality, heavy parsing in Alamofire’s default completion will block the UI!
Forgetting DispatchQueue.main.async in URLSession: UI code crashes or doesn’t update if you update UIKit from the background.
Not configuring URLCache: Missing out on free performance gains from HTTP caching.
Ignoring request priority: Background image/data requests can starve urgent calls if priorities aren’t set correctly.
Neglecting network logging: Makes debugging timeouts and API errors much harder.
Overusing retry logic: Blindly retrying can amplify server load or lead to bad UX.

Key Takeaways

Alamofire delivers responses on the main thread by default. Use a custom response queue for heavy background work.
URLSession delivers on a background thread by default. Always call DispatchQueue.main.async for UI changes.
Apply caching using URLCache for both URLSession and Alamofire where possible.
Prioritize and manage requests - assign priorities for best user experience.
Log network traffic with tools like NetworkActivityLogger to debug and optimize.
Handle errors and retries thoughtfully - don’t blindly retry everything.
Monitor performance and failures using analytics or observability tools.

If you learned something new, check out the original guide for deeper technical explanations!

How to Prevent Dropped Frames in SwiftUI with DispatchQueue

Andrea Sunny — Tue, 09 Jun 2026 03:30:00 +0000

If you’ve ever noticed your SwiftUI app stuttering, lagging animations, or random UI freezes, it may not just be heavy rendering. Sometimes, “frames get dropped at the source”: your app can’t even deliver frames for rendering because the main thread is overloaded. Here’s what that means, why it matters, and how practical use of DispatchQueue can keep your app smooth and responsive.

Why This Problem Matters

When SwiftUI apps drop frames, it’s not just an aesthetic issue. Choppy interactions and frozen screens frustrate users and hurt your ratings. For developers, fixing frame drops unlocks smoother animations and a more responsive feel - the difference between a good and a bad user experience.

What Does “Frames Get Dropped at the Source” Actually Mean?

In iOS, SwiftUI (and UIKit) tries to deliver frame updates at a constant 60 FPS. But if your code blocks the main thread with heavy tasks (data parsing, sync, image processing, etc.), new frames can’t be generated on time. When that happens, the UI won’t even get a chance to update - frames are missed before even reaching the render pipeline.

In short: If your main thread is busy, the UI can’t keep up.

A Simple Breakdown

Main Thread: Handles UI updates and event delivery.
Heavy Work (Computation/Networking/File IO): If done on main, it blocks everything else.
Result: UI stops updating, animations stop, and frames are dropped at the source.

Practical Example: Offloading with `DispatchQueue`

Let’s say you’re downloading and transforming data. Instead of blocking the main thread, run expensive tasks on a background queue, and update the UI on the main queue when ready.

DispatchQueue.global(qos: .userInitiated).async {
    // Heavy data processing or network fetch
    let result = intenseCalculation()

    DispatchQueue.main.async {
        // Safely update UI on the main thread
        self.viewModel.result = result
    }
}

This pattern lets SwiftUI keep rendering uninterrupted - no dropped frames due to blocking operations.

Where You’ll Encounter This in Real Projects

Making slow network requests on the main thread
Loading or decoding big images directly in a view
Parsing large JSON files right as your view appears

All of these can cause the main thread to stall, leading to dropped frames and a sluggish UI.

Common Misconceptions

“SwiftUI is slow.”
- Often, it’s not SwiftUI’s fault: frame drops are usually due to how you schedule work, not the framework itself.
“Using Combine or GCD is advanced.”
- You don’t need deep reactive skills to offload tasks. DispatchQueue is approachable for most use cases.
“Small computations can’t hurt - just keep them on main.”
- Multiple “small” tasks can add up and choke the main thread, especially in data-heavy UIs.

Implementation: Efficient View Updates and Async Work

Use .onAppear {} to trigger background fetches only when needed.
Always use background queues for heavy work (with DispatchQueue.global() or tasks in Combine).
Make sure your UI updates (like state variables or view model values) only happen back on the main queue.

Example using Combine for background work:

import Combine

class DataViewModel: ObservableObject {
    @Published var data: [Item] = []
    private var cancellables = Set<AnyCancellable>()

    func fetchData() {
        URLSession.shared.dataTaskPublisher(for: URL(string: "https://yourapi.com/data")!)
            .map(\ .data)
            .decode(type: [Item].self, decoder: JSONDecoder())
            .receive(on: DispatchQueue.main)
            .sink(receiveCompletion: { _ in }, receiveValue: { [weak self] data in
                self?.data = data
            })
            .store(in: &cancellables)
    }
}

What Developers Often Get Wrong

Doing heavy computation in SwiftUI view bodies.
Updating the UI from background threads (causes glitches or crashes).
Assuming Combine magically makes things async – you still have to pay attention to which queue work runs on.
Not profiling on real devices – performance issues are often less visible on simulators.
Neglecting image scaling or async loading - loading huge images inline can freeze your app.

Looking for a Deeper Dive?

I found this guide super helpful for understanding frame rate drops and app hangs at a technical level. If you’re interested in more examples, Xcode profiling tips, or background threading strategies, it’s a resource worth checking out.

Key Takeaways

If your app drops frames, it’s often because the main thread is overloaded.
Offload expensive work (networking, computation, decoding) to a background queue using DispatchQueue or Combine.
Always update your UI back on the main thread to avoid glitches.
Use tools like Instruments and real-device profiling for detecting bottlenecks.
Lazy image loading (AsyncImage) and efficient view hierarchies keep rendering fast and memory usage low.

Curious about what makes apps succeed (or fail). Sharing lessons from real-world performance stories.

Customizing SwiftUI Charts: Axis Lines, Styles, and Real-World Examples for iOS 16

Andrea Sunny — Sat, 06 Jun 2026 04:45:00 +0000

If you’ve ever needed to turn app data into something users can quickly understand - with no messy setup or external dependencies - Apple’s Charts framework for SwiftUI (iOS 16+) is a game changer. Whether you’re tracking user stats, showing growth, or summarizing key metrics, visually rich charts are now a native part of your iOS app’s UI toolkit.

Below, I’ll break down what I learned about SwiftUI Charts after experimenting with real code and reading some excellent resources (linked below), focusing on practical usage and how you can customize things like axis lines and marks. You’ll be able to get useful visuals running fast - without leaning on third-party chart libraries.

Why Use SwiftUI Charts?

No extra dependencies: Charts is built right into the SwiftUI ecosystem (iOS 16+).
Modern, smooth UI: Native SwiftUI look and feel, automatic light/dark styling.
Quick to implement: Declarative syntax, highly customizable.
First-class axes and marks: Control axis lines, labels, gridlines, and bar/line/sector mark styles directly in code.

In short: For most in-app data viz needs, this removes a ton of friction compared to older UIKit-based (or external) solutions.

Getting Started: Import and Setup

Make sure your project targets iOS 16+ and uses SwiftUI (Xcode 14+ required).
Wherever you want to use charts, import the framework:

import Charts

That’s it - no SPM/CocoaPods, just native Swift.

Example 1: Building a Simple Bar Chart

Bar charts are the best starting point for comparing categories (like monthly sales or feature adoption). You specify data points using BarMark and SwiftUI handles the layout.

struct BarChartView: View {
    var body: some View {
        Chart {
            BarMark(x: .value("Month", "Jan"), y: .value("Sales", 20))
            BarMark(x: .value("Month", "Feb"), y: .value("Sales", 30))
            BarMark(x: .value("Month", "Mar"), y: .value("Sales", 45))
        }
        .frame(height: 250)
        .padding()
    }
}

Chart is the container for your data.
Each BarMark represents a bar (with x and y values).
Layout, scaling, and axis rendering are handled automatically.

You can swap in real data from arrays, databases, or APIs.

Example 2: Line Charts for Trends

For visualizing time series or progress data, use LineMark.

struct TrendLineChart: View {
    let data = [(day: "Mon", value: 120), (day: "Tue", value: 135), (day: "Wed", value: 110)]
    var body: some View {
        Chart(data, id: \ .day) { item in
            LineMark(
                x: .value("Day", item.day),
                y: .value("Value", item.value)
            )
            .foregroundStyle(.blue)
            .lineStyle(StrokeStyle(lineWidth: 2))

            PointMark(
                x: .value("Day", item.day),
                y: .value("Value", item.value)
            )
            .foregroundStyle(.blue)
        }
        .frame(height: 240)
        .padding()
    }
}

Add both LineMark (for the trend) and PointMark (for data dots)
Useful for performance, growth, or analytics dashboards

Example 3: Pie Chart (with SectorMark)

Pie charts aren’t always the best for exact values, but are great for showing proportions.

struct PopulationPieChart: View {
    struct Country { let name: String; let population: Int }
    let data = [
        Country(name: "India", population: 1428),
        Country(name: "China", population: 1412),
        Country(name: "USA", population: 339)
    ]
    var body: some View {
        Chart(data, id: \ .name) { country in
            SectorMark(angle: .value("Population", country.population))
                .foregroundStyle(by: .value("Country", country.name))
        }
        .frame(height: 300)
        .padding()
    }
}

Example 4: Scatter Plot

Ideal for finding correlations or outliers between two continuous variables.

struct ScatterPlot: View {
    struct DataPoint { let hours: Double; let score: Double }
    let data = [DataPoint(hours: 1, score: 85), DataPoint(hours: 2.5, score: 93)]
    var body: some View {
        Chart(data, id: \ .hours) { dp in
            PointMark(x: .value("Study Hours", dp.hours), y: .value("Score", dp.score))
        }
        .frame(height: 200)
        .padding()
    }
}

Customizing Axes and Visual Style

The real power of SwiftUI charts comes from customizing axes and marks to fit your app design. This is where the keywords like swiftui charts axisline enter the picture. Let’s look at a bar chart with axis tweaks and better colors:

Chart(data, id: \ .x) { item in
    BarMark(
        x: .value("Month", item.x),
        y: .value("Sales", item.y)
    )
    .foregroundStyle(Color.red)
    .clipShape(RoundedRectangle(cornerRadius: 4)) // rounded bars
    .annotation(position: .overlay) {
         Rectangle().stroke(Color.black, lineWidth: 1)
    }
}
.chartXAxis {
    AxisMarks { _ in AxisGridLine(); AxisValueLabel().font(.system(size: 12)) }
    AxisLine() // Draws the axis line explicitly
}
.chartYAxis {
    AxisMarks { _ in AxisGridLine(); AxisValueLabel().font(.system(size: 12)) }
    AxisLine()
}
.frame(height: 250)
.padding()

Customizations shown above:

Bar color & shape: foregroundStyle and clipShape
Bar outlines: Add a black stroke for clarity
Axis labels/font: Change with .chartXAxis/.chartYAxis and AxisValueLabel()
Axis lines: Drawn explicitly with AxisLine()
Grid lines: Shown by AxisGridLine()

Where You'll Use These Patterns

Dashboards: Business analytics, admin panels
Fitness/Activity apps: Progress, goals
Personal finance/budgeting tools
Learning/tracking apps: Anything that summarizes change over time

If you need to summarize data quickly, this API is hard to beat for speed and cleanliness.

What Developers Often Get Wrong

Even though SwiftUI charts are straightforward, a few practical mistakes crop up:

Forgetting to set a frame: The chart won’t show up unless you use .frame(height: ...)!
Mismatching data IDs: Always provide a unique id: if your data isn’t simple - especially for animated or dynamic charts.
Ignoring data type mismatches: X-axis and Y-axis values must match expected types. Check string vs. numeric mismatches.
Skipping accessibility/labels: Charts can be unreadable for assistive tech if you skip annotation or neglect labels.
Over-customizing early: Resist the urge to over-stylize before your base chart works - debug raw visuals first.
Axis line confusion: If you want axis lines visible, you need to declare them directly (AxisLine()). By default, they may not render as expected.

Key Takeaways

SwiftUI Charts (iOS 16+) makes native data viz fast and modern - great for most in-app charts.
Import the Charts library and get started immediately - no setup overhead.
You can build bar, line, pie, and scatter charts easily, and style them using colorful, branded, or accessible themes.
Axis customization (lines, grids, label styles) brings polish - use features like AxisLine(), AxisValueLabel(), and .chartXAxis/.chartYAxis.
Avoid common mistakes by always specifying chart frame, unique data IDs, and type-matching axis values.
For deeper detail or more examples: the Appxiom guide is a great reference that helped clarify the API for me.

You can now visualize insights natively, with clarity, and without third-party cruft.

Happy charting!

How to Actually Test Jetpack Compose UIs with Espresso (Without Losing Your Mind)

Andrea Sunny — Thu, 04 Jun 2026 02:30:00 +0000

If you’ve just moved to Jetpack Compose for your Android UI (like me!) but still want reliable UI testing, you might wonder: Do I use Espresso? Compose Test APIs? Both? How do they work together?

After digging into Compose UI testing and running into a few walls, here’s what actually worked - and the practical ways to catch sneaky UI bugs before your users do.

Why Compose UI Testing Matters (and How Espresso Fits In)

UI bugs often hide in plain sight. Maybe the animation works for you but breaks on another device. Maybe that new Compose screen looks fine - until a user can’t tap a button.
Automated UI tests help you catch these issues before they hit production.
With Jetpack Compose, Espresso isn’t replaced - it’s complemented. Compose brings its own testing APIs. But you can (and often should) use both.

Let’s walk through the setup, how it fits together, and real code examples.

How Compose UI Testing (with Espresso) Actually Works

Testing Compose UIs is a bit different than traditional Android Views, but the basics are still:

Set up your test class and environment
Render your Compose UI in a controlled test
Use Espresso/Compose test APIs to interact and make assertions

Setup: What You Need

Android project using Jetpack Compose
UI tests enabled (androidTest directory)
Dependencies:

  androidTestImplementation 'androidx.test.espresso:espresso-core:<latest>'
  androidTestImplementation 'androidx.test.ext:junit:<latest>'
  androidTestImplementation 'androidx.compose.ui:ui-test-junit4:<compose version>'

1. Create Your UI Test Class

Create a new file in androidTest, e.g., ExampleEspressoTest.kt
This is where your UI test code lives

2. Import Required Testing Tools

import androidx.compose.ui.test.*
import androidx.compose.ui.test.junit4.createComposeRule
import androidx.test.espresso.Espresso.onView
import androidx.test.espresso.matcher.ViewMatchers.*
import androidx.test.espresso.action.ViewActions.click
import org.junit.Rule
import org.junit.Test

3. Set Up the Compose Test Rule

class ExampleEspressoTest {
    @get:Rule
    val composeTestRule = createComposeRule()
    // ...
}

The rule launches your Compose UI in a test harness

4. Write a Test: Compose + Espresso in Action

Let’s write a minimal test that ensures a button is visible and clicks it:

@Test
fun testButtonVisibilityAndClick() {
    composeTestRule.setContent {
        Button(onClick = { /* no-op */ }) {
            Text("Click Me")
        }
    }
    // Check if button text exists with Espresso
    onView(withText("Click Me")).check(matches(isDisplayed()))
    // Click it as a user would
    onView(withText("Click Me")).perform(click())
}

setContent { ... } renders your Compose UI just for the test
onView(withText()) lets Espresso find the button by text
isDisplayed() asserts it’s there
perform(click()) simulates a real tap

Prefer Compose Matchers for Compose UIs (When Possible)

You can interact directly with Compose:

composeTestRule.onNode(hasText("Click Me")).assertIsDisplayed().performClick()

More reliable for complex UIs
Prefer onNode/Compose matchers unless you really need Espresso integration (e.g., hybrid View + Compose screens)

Common Compose UI Test Patterns

Matchers:
- withText("text") (Espresso) | hasText("text") (Compose)
- isDisplayed() (with both APIs)
Actions:
- click() (Espresso/Compose)
Assertions:
- .check(matches(isDisplayed())) (Espresso)
- .assertIsDisplayed() (Compose)

Your test code should read like: Find this element, make sure I see it, then click - just like a user would.

Where You’ll Run Into Compose UI Testing

Migrating legacy UI tests: If you’re replacing classic Views with Compose, you’ll need to rethink your test logic.
Hybrid screens: Sometimes you have both Views and Compose in the same Activity. Both Espresso and Compose test APIs work together!
Custom UI components: Use these patterns to reliably assert and interact with custom composables.

What Developers Often Get Wrong

Mixing up Espresso and Compose APIs:
- Don’t use onView() to interact with Compose-only components unless they’re displayed in hybrid layouts.
- For pure Compose UIs, prefer composeTestRule.onNode(...) and related APIs.
Missing Test Rules:
- Forgetting @get:Rule val composeTestRule = createComposeRule() means your Compose tests won’t run properly.
Relying on UI details:
- Targeting implementation details (like hardcoded text) makes tests break easily. Prefer unique testTags or stable attributes.
Ignoring synchronization:
- Compose and Espresso each handle UI thread sync differently; stick with one approach per test to avoid flaky results.

Useful Learning Resource

If you want a deeper technical guide - including more code snippets and explanations that clarified a lot for me - check out the original blog post I used as a reference: Testing Jetpack Compose Based Android UI Using Espresso

Key Takeaways

Compose UI testing is practical with the right setup - combine composeTestRule and Compose matchers for clarity.
Use Espresso only when mixing Compose and traditional Views, or if you need legacy integrations.
Make your tests read like user stories: find, check, act.
Don’t rely on fragile attributes - use testTag for robust selectors.
Learning resources (like the Appxiom blog) can save you hours of confusion.

Curious about why some UI tests fail on real devices or how to avoid flaky Compose UI tests? Share your experiences or questions in the comments!

How to Build Efficient Real-Time Location Features in Flutter

Andrea Sunny — Sun, 31 May 2026 04:00:00 +0000

Whether you’re building a delivery app, a fitness tracker, or just curious about how location works under the hood, chances are you’ll run into the need for reliable and efficient location tracking in Flutter at some point. I recently dug deep into real-world implementations (and mishaps) with Flutter’s location ecosystem, so I thought I’d share what helped me finally make sense of the process.

Why Location Flutter Is Tricky (and Worth Mastering)

Location features in Flutter can seem straightforward—just grab the user’s latitude and longitude, right? But in practice, there’s a lot that can go wrong:

Apps crashing because of permission issues (especially with geolocator and permission_handler together).
GPS draining the battery by requesting more updates than needed.
Weird results running code on platforms like FlutLab, where GPS isn’t always supported.
Handling accuracy, speed, altitude, and heading, all while users move unpredictably.

A solid understanding of location services can help you avoid a lot of headaches—and deliver smoother, faster apps that respect user privacy and device resources.

Picking the Right Package: `geolocator` vs. `location`

Flutter offers a couple of battle-tested packages for GPS and location:

geolocator: My personal favorite for flexibility. Offers real-time streams, control over accuracy (LocationAccuracy.best), and lots of configuration.
location: Great for simple use cases. If you just need to grab the current position once and display it.

For tracking, like fitness or delivery, geolocator shines because you can:

Subscribe to position changes using getPositionStream().
Tune frequency and precision to balance battery usage and accuracy.

Example: Streaming Location Data

import 'package:geolocator/geolocator.dart';
import 'dart:async';

StreamSubscription<Position>? positionStream;

void startTracking() {
  positionStream = Geolocator.getPositionStream(
    locationSettings: LocationSettings(
      accuracy: LocationAccuracy.best,  // or your preferred accuracy
      distanceFilter: 20,               // Only update if user moves 20m
    ),
  ).listen((Position position) {
    // Now you have latitude, longitude, speed, altitude, and heading
    print(position);
  });
}

void stopTracking() {
  positionStream?.cancel();
}

FlutLab Note

If you’re testing on FlutLab, true GPS may not be available. This can lead to misleading results. Check the docs or use device emulators with GPS support.

Mastering Permissions: No More `geolocator` & `permission_handler` Crashes

Most issues I found were related to improper permission handling—even causing crashes! In Flutter, location is sensitive and both Android and iOS platforms demand a clear flow.

Ask users with context: Don’t slam a permission dialog at launch. Show a rationale first.
Handle denial: Guide users to device settings if needed.
Always check: Users can revoke permissions at any time.

import 'package:permission_handler/permission_handler.dart';

Future<bool> ensureLocationPermission() async {
  final status = await Permission.location.request();
  return status.isGranted;
}

Pitfall:

Mixing geolocator and permission_handler can create double-requests or unexpected behavior. Use just one for permission requests and check documentation for updates—these packages evolve fast (the latest geolocator flutter version for 2026 may have changes).

Avoiding Battery Drain: Accuracy & Update Frequency

Real-time tracking sounds great until user reviews complain about dead batteries! Here’s what helped me optimize:

Adjust accuracy (LocationAccuracy.best, LocationAccuracy.high, etc.). Most apps don’t need meter precision.
Use distance filters: Only update after significant movement.
Start streams only when needed (e.g., tracking screen).
Stop streams as soon as tracking isn’t needed.

Geolocator.getPositionStream(
  locationSettings: LocationSettings(
    accuracy: LocationAccuracy.medium,
    distanceFilter: 50,
  ),
)

Decoding Addresses and Rate Limiting: Geocoding in Flutter

Turning coordinates into human-friendly addresses? Use the flutter geocoding package, but be careful: it can hit API rate limits fast if overused.

import 'package:geocoding/geocoding.dart';

Future<void> getAddressFromCoords(double lat, double lng) async {
  try {
    final placemarks = await placemarkFromCoordinates(lat, lng);
    print(placemarks.first.street);
  } catch (e) {
    // Handle geocoding errors (like limit exceeded)
  }
}

Caching & Handling Flaky Location Data

Cache recent positions to avoid repeat lookups and improve speed on re-entry.
Store a timestamp with cached locations to know when to refresh.
Only send updates to the backend if position changes significantly.

Error Handling: Don’t Leave Users Hanging

Sometimes, GPS or permissions fail silently—users just see a blank map. Avoid this:

Always check if location services are enabled before subscribing.
If permissions are denied or location is disabled, display a clear, helpful message.
For example: "Location is off. Please enable it in your device settings."

Common Developer Misconceptions

Assuming permissions are always granted: Users can change their mind or OS settings can revoke access.
Polling current location is better than streams: Streams (with the right settings) are more battery friendly.
High accuracy is always needed: Lower accuracy modes can be accurate enough for many tasks and save major battery power.
GPS always works in web/FlutLab: Location support varies—review your platform requirements!

Where This Comes Up in Real Apps

Real-time delivery tracking (Uber, DoorDash)
Fitness and running apps (Strava)
Geo-fenced notifications (reminders or alarms based on position)
Travel guides (finding attractions nearby)

Takeaways

Choose the right package—geolocator is powerful for tracking, but test on your build targets.
Master permission flows; avoid double prompting (no more crash-y geolocator/permission_handler bugs).
Balance accuracy and frequency for smooth, battery-friendly tracking.
Cache location data and handle errors up front for a smoother UX.
Stay updated—Flutter packages evolve, especially location-dependent ones.

If you're diving deeper, I highly recommend this blog for technical explanations and practical best practices that really helped me structure my implementation.

Data Structures in Swift: What Every iOS Developer Should Know in 2026

Andrea Sunny — Thu, 21 May 2026 05:26:17 +0000

Swift is clean, expressive, and powerful - but writing efficient Swift applications requires more than just understanding syntax.

If you really want to level up as an iOS developer, you need to understand data structures in Swift.

Because at scale, performance problems usually don’t come from UI code.

They come from choosing the wrong structure for storing, searching, sorting, or updating data.

That’s why mastering Swift data structures is one of the biggest upgrades you can make as a developer.

In this article, we’ll break down the most important data structures every Swift developer should know, when to use them, and why they matter in real-world iOS applications.

👉 Detailed guide here:

https://www.appxiom.com/blogs/data-structures-in-swift/

Why Data Structures Matter in Swift

A lot of developers jump directly into:

SwiftUI
UIKit
Combine
Async/Await
CoreData

…but skip computer science fundamentals.

The problem?

Without understanding data structures, apps become:

slower
harder to scale
memory inefficient
difficult to optimize

The difference between a smooth app and a laggy app often comes down to choosing the right structure.

Most Important Data Structures in Swift

Here are the core data structures in Swift every iOS developer should understand.

Data Structure	Best Use Case
Array	Ordered collections
Set	Unique values
Dictionary	Key-value storage
Stack	LIFO operations
Queue	FIFO operations
Linked List	Dynamic insertions
Tree	Hierarchical data
Graph	Connected systems
Heap	Priority-based operations

1. Arrays in Swift

Arrays are the most commonly used Swift data structure.

var numbers = [1, 2, 3, 4]

Arrays are great when:

order matters
indexing matters
you frequently iterate through items

But many developers misuse arrays for lookups.

Example:

numbers.contains(4)

This becomes slower as the collection grows.

2. Sets in Swift

If you need uniqueness + fast lookups, use Set.

var uniqueUsers: Set<String> = ["Alex", "Sam"]

Sets are much faster for:

duplicate prevention
membership checks
filtering unique data

A lot of performance issues in Swift apps come from developers using arrays where sets are more appropriate.

3. Dictionaries in Swift

Dictionaries are essential for key-value access.

var userAge = [
    "Alex": 25,
    "Sam": 30
]

Perfect for:

caching
API response mapping
local storage models
lookup-heavy operations

Real-World Example

Imagine building a messaging app.

Bad approach:

var messages: [Message]

Searching for a message repeatedly becomes expensive.

Better approach:

var messagesById: [String: Message]

Now lookups become almost instant.

This is why understanding data structures in Swift matters in production apps.

4. Stack Data Structure

Stacks follow:

Last In → First Out (LIFO)

Example use cases:

navigation history
undo systems
expression parsing

Simple implementation:

struct Stack<T> {

    private var items = [T]()

    mutating func push(_ item: T) {
        items.append(item)
    }

    mutating func pop() -> T? {
        items.popLast()
    }
}

5. Queue Data Structure

Queues follow:

First In → First Out (FIFO)

Used in:

task scheduling
networking pipelines
media buffering
background processing

Example:

struct Queue<T> {

    private var items = [T]()

    mutating func enqueue(_ item: T) {
        items.append(item)
    }

    mutating func dequeue() -> T? {
        guard !items.isEmpty else { return nil }
        return items.removeFirst()
    }
}

6. Linked Lists in Swift

Linked lists are less common in modern iOS apps but still important conceptually.

They help when:

frequent insertions occur
dynamic memory behavior matters
node traversal is needed

However, Swift arrays are heavily optimized, so linked lists are not always the best practical choice.

7. Trees in Swift

Trees are everywhere in software engineering.

Examples:

file systems
view hierarchies
JSON parsing
DOM structures

Basic tree node:

class TreeNode<T> {

    var value: T
    var children: [TreeNode] = []

    init(value: T) {
        self.value = value
    }
}

8. Graphs in Swift

Graphs model relationships between objects.

Examples:

maps/navigation
social networks
recommendation systems
dependency graphs

This is one of the most underrated Swift data structures.

9. Heap / Priority Queue

Heaps are useful when you constantly need the “highest priority” item.

Examples:

scheduling systems
leaderboard ranking
real-time gaming systems
notification prioritization

Common Mistakes Swift Developers Make

1. Using Arrays Everywhere

Many developers default to arrays for everything.

That creates performance bottlenecks quickly.

2. Ignoring Time Complexity

Operations have costs.

Example:

Operation	Array	Set
Lookup	O(n)	O(1)
Insert	O(1)	O(1)
Remove	O(n)	O(1)

Understanding complexity changes how you architect apps.

3. Optimizing Too Late

Bad data structure decisions become expensive to refactor later.

Choose wisely early.

Swift Data Structures and Interviews

A huge reason developers search for:

swift data structures
data structures in swift

…is interview preparation.

Most iOS interviews now include:

arrays
stacks
queues
trees
recursion
hashing
graph traversal

Even for senior mobile roles.

Best Way to Learn Data Structures in Swift

Don’t just memorize definitions.

Instead:

Build them manually
Use them in small apps
Analyze time complexity
Compare tradeoffs
Study real-world architecture

That’s where concepts actually stick.

How Data Structures Improve App Performance

Choosing the right structure can improve:

app startup speed
memory usage
scrolling performance
caching efficiency
database operations
API processing

This becomes extremely important in large-scale SwiftUI apps.

Final Thoughts

Understanding data structures in Swift is one of the highest-leverage skills for becoming a better iOS developer.

Frameworks change every year.

But core computer science fundamentals stay valuable forever.

If you want the deeper implementation breakdown, examples, and architecture discussion, check out the full guide here:

👉 https://www.appxiom.com/blogs/data-structures-in-swift/

It covers practical Swift data structures with examples developers can actually use in real projects.

Building an Offline-First Android App with Jetpack Compose (2026 Guide)

Andrea Sunny — Fri, 15 May 2026 06:24:35 +0000

Modern Android apps are expected to work even when the internet doesn’t.

Users open apps inside elevators, during flights, in low-network regions, or while switching between Wi-Fi and mobile data. If your app crashes or becomes unusable offline, users leave quickly.

That’s why offline-first Android architecture is becoming the default approach in 2026.

In this guide, you’ll learn how to build an offline-capable Android app using Jetpack Compose, Room, WorkManager, and Retrofit - along with the latest stable dependency versions developers are searching for right now.

👉 Original detailed guide:

https://www.appxiom.com/blogs/build-offline-android-app-jetpack-compose/

Why Offline-First Apps Matter

Offline-first apps provide:

Faster UI responsiveness
Better user retention
Reliable performance in poor networks
Seamless background synchronization
Reduced server dependency

Apps like WhatsApp, Notion, Spotify, and Google Keep all rely heavily on offline-capable architecture.

Tech Stack for Offline Android Apps

Here’s the modern stack most Android developers use today:

Technology	Purpose
Jetpack Compose	Modern UI toolkit
Room Database	Local offline storage
WorkManager	Background sync
Retrofit	API networking
Kotlin Coroutines	Async programming
Flow / StateFlow	Reactive streams

Latest Android Dependency Versions (2026)

Many developers search for dependency versions directly in Google Search Console, which explains queries like:

androidx.room:room-runtime:2.6.1
androidx.work:work-runtime-ktx:2.9.0
androidx.activity:activity-compose latest version 2026

Here are the commonly used stable versions.

Room Database

implementation("androidx.room:room-runtime:2.6.1")
implementation("androidx.room:room-ktx:2.6.1")
ksp("androidx.room:room-compiler:2.6.1")

You may also see older searches like:

implementation("androidx.room:room-runtime:2.5.2")

But 2.6.1 is the preferred version for most new projects.

WorkManager

implementation("androidx.work:work-runtime-ktx:2.9.0")

This is currently one of the most searched WorkManager dependencies because developers want:

Reliable background syncing
Offline queue processing
Retry mechanisms
Battery-efficient background tasks

Activity Compose

implementation("androidx.activity:activity-compose:1.9.0")

If you searched for:

androidx.activity activity-compose latest version 2026

this is the dependency you likely need.

Step 1 - Create Your Room Entity

Room acts as your local source of truth.

@Entity(tableName = "notes")
data class NoteEntity(
    @PrimaryKey(autoGenerate = true)
    val id: Int = 0,
    val title: String,
    val content: String,
    val synced: Boolean = false
)

Step 2 - DAO Layer

@Dao
interface NoteDao {

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insert(note: NoteEntity)

    @Query("SELECT * FROM notes")
    fun getAllNotes(): Flow<List<NoteEntity>>
}

Using Flow ensures the UI updates automatically whenever local data changes.

Step 3 - Configure Room Database

@Database(
    entities = [NoteEntity::class],
    version = 1
)
abstract class AppDatabase : RoomDatabase() {

    abstract fun noteDao(): NoteDao
}

Initialize it like this:

val db = Room.databaseBuilder(
    context,
    AppDatabase::class.java,
    "offline_db"
).build()

Step 4 - Retrofit Networking

Retrofit remains the standard for Android APIs.

implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")

A lot of developers also search for:

square retrofit 2.6.0 suspend support release notes
retrofit latest version 2026 2.9.0

Suspend support is now fully standard in Retrofit.

Example API service:

interface NoteApi {

    @POST("notes")
    suspend fun uploadNote(
        @Body note: NoteEntity
    )
}

Step 5 - WorkManager for Background Sync

This is where offline-first architecture becomes powerful.

Whenever the internet returns, WorkManager syncs unsynced local data automatically.

class SyncWorker(
    context: Context,
    params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {

        return try {
            // Upload local notes
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

Schedule it like this:

val request = OneTimeWorkRequestBuilder<SyncWorker>()
    .build()

WorkManager.getInstance(context)
    .enqueue(request)

Step 6 - Jetpack Compose UI

Compose makes reactive offline UIs much easier to implement.

@Composable
fun NotesScreen(viewModel: NotesViewModel) {

    val notes by viewModel.notes.collectAsState()

    LazyColumn {
        items(notes) { note ->
            Text(text = note.title)
        }
    }
}

Because Room exposes Flow, the UI updates instantly whenever local data changes.

Offline-First Architecture Flow

The recommended architecture is:

UI → Local Database → Background Sync → Remote Server

Instead of:

UI → API → Database

This ensures your app remains functional even without connectivity.

Common Mistakes Developers Make

1. Treating APIs as the Source of Truth

Your local database should always be the primary source.

2. Syncing Too Frequently

Aggressive background sync drains battery and impacts performance.

Use WorkManager intelligently.

3. Ignoring Conflict Resolution

Offline edits can conflict with server data.

Use:

timestamps
versioning
merge strategies

What Does “Offline Capable” Mean?

One interesting search query from Search Console was:

offline capable

An offline-capable app means:

Users can view data without internet
Users can create/update data offline
Synchronization happens automatically later
App functionality degrades gracefully

This is now expected behavior for production apps.

Recommended Android Architecture in 2026

The best modern Android architecture stack includes:

MVVM
Repository pattern
Room as source of truth
Retrofit for APIs
WorkManager for sync
Compose for UI
Coroutines + Flow

This setup improves maintainability, scalability, and user experience.

Why This Architecture Scales Well

Offline-first apps scale better because:

APIs can fail temporarily without breaking UX
Users continue interacting with the app
Cached content improves speed
Sync operations happen in the background
Mobile battery usage becomes more optimized

This architecture is especially useful for:

Note-taking apps
E-commerce apps
Chat applications
Healthcare systems
Logistics platforms
Field-service apps

Advanced Improvements You Can Add

Once the basics are working, you can improve the architecture further with:

Paging 3

Efficiently load large offline datasets.

DataStore

Store preferences and lightweight app settings.

Hilt Dependency Injection

Improve modularity and testing.

Network Monitoring

Automatically trigger synchronization when connectivity returns.

Encryption

Protect local Room database data for security-sensitive apps.

Final Thoughts

Offline-first Android development is no longer optional.

If your app depends completely on network availability, users will eventually experience frustration.

By combining:

androidx.room:room-runtime:2.6.1
androidx.work:work-runtime-ktx:2.9.0
Retrofit
Jetpack Compose

you can build apps that feel fast, modern, and reliable.

For the complete implementation walkthrough, check the original article:

👉 https://www.appxiom.com/blogs/build-offline-android-app-jetpack-compose/

Sqflite Flutter: A Simple Way to Add Local Database Support in Flutter Apps

Andrea Sunny — Thu, 14 May 2026 06:03:05 +0000

When building production-ready Flutter apps, one thing becomes obvious very quickly - you eventually need local storage.

Whether it’s:

offline access,
caching API responses,
storing user preferences,
or maintaining app state,

having a reliable local database solution matters.

That’s where sqflite Flutter integration becomes extremely useful.

If you’ve searched for sqflite tutorials recently, you probably noticed that many examples only cover basic CRUD operations without explaining real-world usage patterns. So in this post, I want to share why sqflite is still one of the best choices for Flutter local storage and where beginners can learn it properly.

What is Sqflite?

Sqflite is a Flutter plugin for SQLite.

It allows Flutter developers to store structured data locally using SQL queries inside mobile applications.

With sqflite, you can:

Create local databases
Insert/update/delete data
Perform SQL queries
Store relational data efficiently
Build offline-first apps

Since SQLite is lightweight and optimized for mobile devices, sqflite has become one of the most popular local database solutions in the Flutter ecosystem.

Why Developers Use Sqflite Flutter Solutions

Here are a few reasons why sqflite is widely used in Flutter projects.

1. Offline Support

Your app can continue functioning without internet access.

This is especially important for:

productivity apps,
note-taking apps,
expense trackers,
learning platforms,
and field-service applications.

2. Better Performance

Reading data locally is much faster than making repeated API calls.

Many apps use sqflite for:

caching,
session persistence,
and reducing unnecessary network requests.

3. Structured Data Storage

Unlike simple key-value storage systems, sqflite supports relational tables and SQL queries.

That means you can build:

searchable datasets,
filtered records,
connected entities,
and scalable local architectures.

Common Sqflite Flutter Use Cases

App Type	Usage
Todo Apps	Task persistence
Finance Apps	Offline transaction storage
E-commerce Apps	Cart & wishlist caching
Chat Apps	Local message history
Learning Apps	Saved progress & lessons

Things Beginners Usually Struggle With

When starting with sqflite Flutter development, beginners often face challenges like:

Database initialization
Async query handling
Managing database versions
Writing reusable helper classes
Structuring CRUD methods cleanly

That’s why following a proper implementation guide is important instead of just copying snippets from random tutorials.

Sqflite vs Other Flutter Storage Packages

Flutter developers often compare sqflite with:

Hive
Drift
SharedPreferences
ObjectBox

Each has its strengths, but sqflite still works really well when:

you need relational data,
SQL queries matter,
or you want full control over your database structure.

Final Thoughts

Even with newer storage libraries available, sqflite remains one of the most practical solutions for local database management in Flutter.

If you’re building apps that require:

offline functionality,
structured local storage,
or scalable persistence,

then learning sqflite flutter development is definitely worth your time.

And if you want a clean beginner tutorial, the Appxiom guide linked above is a solid place to start.

The Hidden Problem in Most Flutter Location Implementations

Andrea Sunny — Tue, 17 Mar 2026 11:00:19 +0000

Let’s talk about something most Flutter developers implement…
but rarely optimize properly.

👉 Location services.

At first, it feels simple:

Get location
Show it on UI
Done

But once your app hits real users, things change.

The Problem Most Developers Don’t Notice

Location features don’t fail loudly.

They don’t crash your app.
They don’t throw obvious errors.

Instead, they:

Drain battery silently
Reduce app performance
Deliver inconsistent location accuracy
Run unnecessary background updates

And users don’t say:

“Your GPS polling strategy is inefficient”

They say:

“Your app kills my battery.”

Why Location Services Are Harder Than They Look

Modern location-based apps rely on:

GPS
Network signals
Background services
Permission handling
Real-time updates

And each of these comes with trade-offs:

Accuracy vs battery usage
Frequency vs performance
Real-time updates vs system load

Even small inefficiencies can compound quickly.

For example:

Continuous tracking can drain power rapidly
Poor filtering can create noisy location data
Frequent updates can overload UI rendering

What Most Implementations Get Wrong

From what I’ve seen (and probably you too), common mistakes include:

Fetching location too frequently
Not handling permissions properly
Ignoring background optimization
Treating all location updates equally
Not filtering noisy GPS data

The result?

👉 An app that “works” - but performs poorly in the real world.

A Better Way to Think About Location in Flutter

Instead of thinking:

“How do I get the location?”

Start thinking:

“How do I get location efficiently and responsibly?”

That means:

Choosing the right package (geolocator, etc.)
Handling permissions gracefully
Reducing unnecessary updates
Optimizing for battery
Structuring location logic cleanly

Where Things Get Interesting

There’s a really solid breakdown I came across that goes deeper into this - not just how to implement location services, but how to optimize them properly in real apps.

It covers things like:

Efficient location fetching strategies
Handling permissions correctly
Reducing unnecessary updates
Structuring location logic for performance

👉 If you want to go beyond basic implementation, this is worth reading:
Best Practices for Using Location Services in Flutter

Final Thought

Location services aren’t just a feature.
They’re a system inside your app.

And like any system:

It needs optimization
It needs balance
It needs intention

Because in the end, users don’t care how you implemented it.

They care about:

Battery
Accuracy
Smooth experience

And that’s where good engineering shows up.

Read the Full Guide

If you're building anything involving maps, tracking, or real-time location, don’t stop here.

👉 Read the full detailed guide here:
Best Practices for Using Location Services in Flutter

How Do You Extend Jetpack Compose Components Without Making Them Messy?

Andrea Sunny — Wed, 04 Mar 2026 05:16:17 +0000

When building Android apps with Jetpack Compose, you quickly notice something: UI components evolve constantly. A simple button suddenly needs loading states, analytics tracking, accessibility hints, or animations.

The easy solution? Modify the component directly.

The better solution? Use a design pattern that lets you extend behavior without rewriting the original component.

One pattern that fits this idea perfectly is the Decorator Pattern.

I recently came across a great walkthrough explaining how this pattern works in Compose, and it’s worth exploring if you care about building reusable UI components.

(Full guide here: How to Implement the Decorator Pattern in Jetpack Compose)

Let’s break down the idea and why it’s useful for modern Android development.

What the Decorator Pattern Actually Means

The Decorator Pattern is a classic design pattern that allows you to add behavior to an object dynamically without changing its original code.

Instead of modifying the base component, you wrap it with another object (a decorator) that enhances its behavior.

Think of it like layering features.
Example:

Base Button
  ↓
Loading Decorator
  ↓
Analytics Decorator
  ↓
Accessibility Decorator

Each layer adds something without touching the original implementation.

This approach keeps components:

reusable
maintainable
easier to test

Why This Pattern Works So Well in Compose

Compose is built around composition and small reusable UI pieces.

That means patterns that rely on wrapping and layering behavior naturally fit its architecture.
In fact, you already use this idea daily through modifiers:

Modifier
   .padding(16.dp)
   .background(Color.Blue)
   .clickable { }

Each modifier is essentially decorating the UI element with additional behavior.

The Decorator Pattern simply applies the same idea at a component architecture level.

A Simple Implementation Walkthrough

The Appxiom guide walks through the pattern using a simple example: enhancing a button.
Here’s the general idea.

1. Create the Base Component

Start with a minimal composable that does only one thing.

@Composable
fun BaseButton(text: String, onClick: () -> Unit) {
   Button(onClick = onClick) {
       Text(text)
   }
}

This component is intentionally simple.
No logging.
No loading state.
No analytics.

Just a button.

2. Create Decorators

Decorators wrap the base component and add new behavior.

For example, a loading decorator might look like this:

@Composable
fun LoadingDecorator(content: @Composable () -> Unit) {
   CircularProgressIndicator()
   content()
}

Instead of modifying the button directly, the decorator simply wraps it and enhances it.

3. Apply Decorators

Now we can layer behavior on top of the base component.

LoadingDecorator {
   BaseButton("Submit") {
       println("Clicked")
   }
}

Need analytics?
Add another decorator.

Need animation?
Wrap it again.

Each feature stays isolated and reusable.

4. Use the Decorated Button

Once wrapped, the final component behaves like a richer version of the original.

This keeps your UI architecture flexible because you can combine decorators depending on the screen’s needs.

Why This Pattern Matters in Real Apps

As apps grow, UI components often accumulate responsibilities.

Without patterns like this, you end up with components that look like:

SuperMegaButton(
   loading = true,
   analytics = true,
   tracking = true,
   animate = true,
   accessibility = true
)

Eventually, the component becomes hard to maintain.

The decorator approach keeps responsibilities separate.

Benefits include:

easier testing
reusable behavior
cleaner composables
better separation of concerns

The Real Value of Patterns in Compose

Patterns like this aren’t just academic ideas.

They solve practical problems that appear in real Android projects:

feature layering
UI reuse
scalable component design

Compose encourages thinking in small building blocks, and the decorator pattern fits naturally into that mindset.

If You Want the Full Walkthrough

This article only scratches the surface.

The original guide includes a step-by-step implementation with working examples and explains how to structure decorators properly.
👉 Read the full guide here:
How to Implement the Decorator Pattern in Jetpack Compose

If you’re building reusable UI systems with Jetpack Compose, it’s definitely worth a read.

Final Thought

Jetpack Compose gives developers powerful tools for building UI quickly.

But writing scalable UI still depends on good architectural decisions.

Patterns like the Decorator Pattern help keep your components small, reusable, and adaptable as your app grows.

And sometimes, the simplest patterns make the biggest difference.

DEV Community: Andrea Sunny

How To Choose and Implement Response Queues, Caching, and Logging in Alamofire on iOS

How To Choose and Implement Response Queues, Caching, and Logging in Alamofire on iOS

Why Does Alamofire's Default Response Queue Matter?

Comparing with URLSession

Caching and Data Persistence: URLSession & Alamofire

Request Prioritization in Alamofire

Logging Network Activity with Alamofire

Error Handling and Retry Logic

Monitoring and Analytics

What Developers Often Get Wrong

Key Takeaways

How To Choose and Implement Response Queues, Caching, and Logging in Alamofire on iOS

Why Does Alamofire's Default Response Queue Matter?

Comparing with URLSession

Caching and Data Persistence: URLSession & Alamofire

Request Prioritization in Alamofire

Logging Network Activity with Alamofire

Error Handling and Retry Logic

Monitoring and Analytics

What Developers Often Get Wrong

Key Takeaways

How to Prevent Dropped Frames in SwiftUI with DispatchQueue

Why This Problem Matters

What Does “Frames Get Dropped at the Source” Actually Mean?

A Simple Breakdown

Practical Example: Offloading with DispatchQueue

Where You’ll Encounter This in Real Projects

Common Misconceptions

Implementation: Efficient View Updates and Async Work

What Developers Often Get Wrong

Looking for a Deeper Dive?

Key Takeaways

Customizing SwiftUI Charts: Axis Lines, Styles, and Real-World Examples for iOS 16

Why Use SwiftUI Charts?

Getting Started: Import and Setup

Example 1: Building a Simple Bar Chart

Example 2: Line Charts for Trends

Example 3: Pie Chart (with SectorMark)

Example 4: Scatter Plot

Customizing Axes and Visual Style

Where You'll Use These Patterns

What Developers Often Get Wrong

Key Takeaways

How to Actually Test Jetpack Compose UIs with Espresso (Without Losing Your Mind)

Why Compose UI Testing Matters (and How Espresso Fits In)

How Compose UI Testing (with Espresso) Actually Works

Setup: What You Need

1. Create Your UI Test Class

2. Import Required Testing Tools

3. Set Up the Compose Test Rule

4. Write a Test: Compose + Espresso in Action

Prefer Compose Matchers for Compose UIs (When Possible)

Common Compose UI Test Patterns

Where You’ll Run Into Compose UI Testing

What Developers Often Get Wrong

Useful Learning Resource

Key Takeaways

How to Build Efficient Real-Time Location Features in Flutter

Why Location Flutter Is Tricky (and Worth Mastering)

Picking the Right Package: geolocator vs. location

Example: Streaming Location Data

FlutLab Note

Mastering Permissions: No More geolocator & permission_handler Crashes

Pitfall:

Avoiding Battery Drain: Accuracy & Update Frequency

Decoding Addresses and Rate Limiting: Geocoding in Flutter

Caching & Handling Flaky Location Data

Error Handling: Don’t Leave Users Hanging

Common Developer Misconceptions

Where This Comes Up in Real Apps

Takeaways

Data Structures in Swift: What Every iOS Developer Should Know in 2026

Why Data Structures Matter in Swift

Most Important Data Structures in Swift

1. Arrays in Swift

2. Sets in Swift

3. Dictionaries in Swift

Real-World Example

4. Stack Data Structure

Practical Example: Offloading with `DispatchQueue`

Picking the Right Package: `geolocator` vs. `location`

Mastering Permissions: No More `geolocator` & `permission_handler` Crashes