Byte Me

A Guide For Practical Modularity and Architecture with Spring

2026-04-02T00:00:00+00:00

Modern Spring projects rarely fail because of missing features. They fail because of architecture erosion: tangled dependencies, oversized contexts, and codebases that become hostile to change. Spring’s flexibility is a double-edged sword: without discipline, it enables exactly the kind of accidental complexity developers later regret.

In this article I focus on concrete, developer-controlled practices to improve modularity and architecture in Spring-based systems. The goal is not theoretical purity, but sustainable projects that scale in features, teams, and time.

1. Modular Package Design: Structure Is Architecture

Package structure is not cosmetic. It defines boundaries, controls coupling, and communicates intent.

Avoid Technical Layer Packages

This structure is common—and problematic:

com.example.app
├── controller
├── service
├── repository
└── model

It encourages cross-cutting dependencies and turns services into dumping grounds.

Prefer Feature-Oriented Modules

A better approach is vertical slicing by domain or feature:

com.example.orders
├── api
│   └── OrderController.java
├── application
│   └── PlaceOrderService.java
├── domain
│   ├── Order.java
│   └── OrderRepository.java
└── infrastructure
└── JpaOrderRepository.java

Benefits:

Changes stay localized
Dependencies become intentional
Refactoring costs drop significantly

Rule of thumb: If a package cannot be deleted without breaking unrelated features, it is not a real module.

2. Hexagonal / Clean Architecture with Spring (Without the Ceremony)

Hexagonal (Ports & Adapters) and Clean Architecture work extremely well with Spring, if you let Spring adapt to the architecture, not the other way around.

Core Principle

Domain and application layers know nothing about Spring
Spring is an infrastructure detail

Example: Application Port

public interface PaymentGateway {
  PaymentResult charge(PaymentRequest request);
}

Application Service

public class ProcessPaymentService {
  private final PaymentGateway gateway;

  public ProcessPaymentService(PaymentGateway gateway) {
    this.gateway = gateway;
  }

  public void process(PaymentRequest request) {
    gateway.charge(request);
  }
}

Spring Adapter

@Component
class StripePaymentGateway implements PaymentGateway {
  @Override
  public PaymentResult charge(PaymentRequest request) {
    // Stripe API integration
  }
}

Spring Configuration

@Configuration
class PaymentConfig {
  @Bean
  ProcessPaymentService processPaymentService(PaymentGateway gateway) {
    return new ProcessPaymentService(gateway);
  }
}

Why this matters:

Business logic is testable without Spring
Infrastructure can be swapped without refactoring core logic
Framework upgrades become far less risky

My strong opinion: if your domain layer has @Component, you already lost.

3. Avoiding God-Contexts: Stop Wiring Everything Everywhere

Spring’s auto-scanning makes it dangerously easy to create a single, massive application context.

Symptoms of a God-Context

Thousands of beans loaded for every test
Unrelated modules referencing each other “just because it works”
Refactoring causes cascading failures

Practical Countermeasures

1. Explicit Configuration per Module

@Configuration
@ComponentScan(basePackageClasses = OrdersModule.class)
public class OrdersConfiguration {}

Each module owns its configuration. No global scanning.

2. Use spring-context-indexer

This avoids classpath scanning entirely and forces discipline.

<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-context-indexer</artifactId>
  <optional>true</optional>
</dependency>

3. Context Boundaries in Tests

@SpringBootTest(classes = OrdersConfiguration.class)
class OrderServiceTest {}

If a test requires half the system to start, the architecture is already broken.

4. Multi-Module Spring Boot Projects: Real Modularity at Build Time

Single-module projects scale poorly once multiple teams are involved.

Recommended Module Layout

root
├── domain
├── application
├── infrastructure
├── web
└── boot

domain: entities, value objects, domain services
application: use cases
infrastructure: JPA, messaging, external APIs
web: REST, GraphQL, MVC
boot: Spring Boot entry point

Boot Module Example

@SpringBootApplication
@Import({
  OrdersConfiguration.class,
  PaymentsConfiguration.class
})
public class Application {
  public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
  }
}

Benefits:

Clear dependency direction
Faster builds
Easier parallel development
Enforced architectural boundaries via Maven/Gradle

My recommendation: if your IDE can’t prevent illegal dependencies, your build should.

5. Event-Driven Design: Decoupling Without Chaos

Events are one of the most effective ways to reduce coupling, when used deliberately.

Domain Events with Spring Events

public record OrderPlacedEvent(UUID orderId) {}

@Component
class OrderService {
  private final ApplicationEventPublisher publisher;

  public void placeOrder(Order order) {
    // persist order
    publisher.publishEvent(new OrderPlacedEvent(order.getId()));
  }
}

@Component
class InventoryListener {
  @EventListener
  public void on(OrderPlacedEvent event) {
    // reserve inventory
  }
}

Advantages:

No direct dependencies
Easy extensibility
Clean separation of concerns

Asynchronous Events

@Async
@EventListener
public void handle(OrderPlacedEvent event) { }

When to Move to Messaging

Use brokers (Kafka, RabbitMQ) when:

You need durability
You need cross-service communication
You need replayability

Spring makes the transition smooth, but do not start with messaging if in-process events suffice. Complexity compounds quickly.

Architecture Is a Daily Practice

Spring does not enforce good architecture, it amplifies whatever discipline you already have.

Developers can dramatically improve project quality by:

Designing feature-oriented packages
Keeping Spring out of the domain
Enforcing module boundaries
Limiting application context size
Using events to decouple behavior

Modularity is not a one-time decision. It is a habit reinforced by structure, tooling, and refusal to accept “just one shortcut.”

Designing On-Device Machine Learning That Actually Improves iOS UX

2026-03-31T00:00:00+00:00

On-device machine learning on iOS is often treated as a checkbox: “We use Core ML.” The model runs, predictions come out, and the feature ships. Technically correct, and practically underwhelming. Real value emerges only when ML is treated as part of the product experience, not a background technical detail.

In this article I argue that on-device ML becomes compelling when it is adaptive, fast, and private by design. That means background model updates and personalization, streamed inference with progressive results, and pipelines that work offline without degraded UX. The focus here is concrete: what an iOS developer can do today to raise the quality bar of an ML-powered feature.

1. From Static Models to Living Systems

Shipping a single frozen .mlmodel inside the app bundle is the ML equivalent of hard-coding copy into a view controller. It works, but it ignores the reality that data changes, users differ, and models age.

Background model updates

Apple gives you enough primitives to treat models as updateable assets rather than immutable artifacts. A robust pattern looks like this:

Ship a baseline model in the app bundle
Download improved models in the background
Validate and atomically swap
Fallback automatically if anything goes wrong

Using URLSession background downloads plus Core ML’s compiled model loading, you can do this without blocking the UI or risking crashes.

func loadModel() throws -> MLModel {
  let fm = FileManager.default
  let updatedURL = fm.urls(for: .applicationSupportDirectory, in: .userDomainMask)
    .first!
    .appendingPathComponent("model.mlmodelc")

  if fm.fileExists(atPath: updatedURL.path) {
    return try MLModel(contentsOf: updatedURL)
  } else {
    return try MyBundledModel(configuration: .init()).model
  }
}

The key is zero-friction fallback. If the update fails, expires, or becomes incompatible, the user experience must remain unchanged. Users should never be aware that a model update occurred—only that things got better over time.

Personalization without servers

Personalization does not require sending raw user data to the cloud. On iOS, you can adapt models locally using lightweight techniques:

Feature re-weighting
Threshold tuning
Small on-device fine-tuning using Core ML training APIs
User-specific post-processing layers

A simple example is adjusting decision thresholds per user:

struct UserCalibration {
  var positiveThreshold: Float
}

func isPositive(score: Float, calibration: UserCalibration) -> Bool {
  score > calibration.positiveThreshold
}

Store calibration values locally, update them based on user behavior, and you have personalization with no server round-trip and no privacy risk.

Opinionated take: most personalization problems do not need federated learning or massive infrastructure. They need thoughtful product constraints and local adaptation.

2. Fast Is Not Enough: Streamed Inference and Progressive UX

Many iOS ML features technically run “fast”, yet still feel slow because the UX waits for a final result. This is a design failure, not a model failure.

Progressive results change perception

Users tolerate latency when they see progress. On-device ML allows you to stream partial results instead of blocking the main interaction.

Examples:

Incremental transcription
Progressive image classification
Live ranking updates as context improves

Instead of this:

let prediction = try model.prediction(input: input)
// update UI once

Design your pipeline like this:

for chunk in input.streamedChunks {
  let partial = try model.prediction(input: chunk)
  ui.update(partialResult: partial)
}

Even if total computation time is identical, perceived speed improves dramatically.

Using concurrency correctly

Swift concurrency makes it easier to run inference off the main thread while still delivering UI updates:

Task.detached(priority: .userInitiated) {
  for frame in frames {
    let result = try model.prediction(input: frame)
    await MainActor.run {
      viewModel.update(result)
    }
  }
}

The important point is architectural: the model should not dictate UX timing. UX should drive how results are surfaced.

Opinionated take: if your ML feature only updates the UI once, it is probably leaving UX value on the table.

3. Designing for Failure: Fallbacks as a First-Class Feature

On-device ML removes server dependency, but introduces new local failure modes:

Thermal throttling
Low-power mode
Memory pressure
Older devices

Ignoring these leads to brittle features.

Capability-aware inference

Before running a heavy model, check the environment:

let processInfo = ProcessInfo.processInfo
if processInfo.isLowPowerModeEnabled {
  useLightweightModel()
} else {
  useFullModel()
}

Similarly, keep multiple model variants:

High accuracy
Low latency
Ultra-light fallback

Switching models dynamically is better than degrading the entire experience.

UX fallbacks, not just technical ones

If ML fails, what does the user see?

Bad fallback:

“Prediction unavailable”

Good fallback:

Deterministic rules
Cached results
Manual controls
Reduced automation with clear affordances

The user should never feel blocked because a model failed. They should simply get less magic, not no product.

4. Privacy-First Pipelines That Are Actually Productive

Privacy is often framed as a constraint. On iOS, it is a design advantage.

No server dependency by default

When inference happens fully on device:

Features work offline
Latency is predictable
Sensitive data never leaves the device

This changes how you design flows. You can confidently apply ML to:

Draft content
Private media
Personal habits
Health-adjacent signals

Without permission dialogs or legal gymnastics.

Explicit data lifetimes

A privacy-first pipeline makes data lifetimes explicit:

func process(input: Input) {
  let result = model.predict(input)
  cache.store(result, ttl: .hours(1))
  // raw input discarded immediately
}

Avoid logging raw inputs. Avoid long-lived caches. Treat temporary data as toxic waste: useful briefly, dangerous if stored.

Opinionated take: on-device ML done right simplifies compliance more than any backend anonymization ever will.

5. What This Means for iOS Projects

Improving an ML-powered iOS project is less about model architecture and more about system thinking:

Treat models as updateable assets
Personalize locally with intent
Stream results to the UI
Design graceful degradation
Make privacy the default, not a feature

Core ML is necessary, but not sufficient. The real work is in how models evolve, how results surface, and how failure is handled without user friction.

If your ML feature feels like a black box bolted onto the app, users will ignore it. If it feels responsive, adaptive, and trustworthy, they will rely on it, and that is where on-device ML justifies its complexity.

Time Travel for Android Bugs - Practical Deterministic Replay Debugging

2026-03-26T00:00:00+00:00

Debugging Android applications becomes exponentially harder once concurrency, asynchronous callbacks, and device-specific behavior enter the picture. Bugs that disappear under the debugger, crashes that only happen “sometimes,” and race conditions reported by users but impossible to reproduce locally are common symptoms of a deeper issue: non-determinism.

Deterministic Replay Debugging addresses this problem by allowing developers to record what happened, replay it exactly, and reproduce concurrency bugs reliably. This article focuses on what Android developers can actually do to introduce deterministic replay techniques into real projects, without waiting for magical tooling.

What Is Deterministic Replay Debugging?

Deterministic replay debugging means recording enough information about an execution so that it can be replayed later with identical behavior. Given the same initial state and the same sequence of events, the app behaves the same way every time.

In Android, non-determinism typically comes from:

User input timing
Thread scheduling
Async callbacks (coroutines, executors, Rx, WorkManager)
Network and sensor input
System events (configuration changes, lifecycle)

The goal is not to record everything, but to record the sources of non-determinism.

1. Recording User Intents and Events

Why This Matters

User behavior is the largest source of entropy in an Android app. Two taps separated by 20 ms instead of 50 ms can trigger completely different execution paths when concurrency is involved.

Instead of logging strings, you want structured, timestamped events that can be replayed.

What to Record

At minimum:

UI events (clicks, gestures)
Lifecycle events
Intents and deep links
System callbacks you rely on (permissions, activity results)

Example: Centralized Event Recorder

Create a thin abstraction that records events in a deterministic format.

sealed class AppEvent {
  data class Click(
    val viewId: String,
    val uptimeMs: Long
  ) : AppEvent()

  data class IntentReceived(
    val action: String,
    val extras: Map<String, String>,
    val uptimeMs: Long
  ) : AppEvent()
}

A recorder interface:

interface EventRecorder {
  fun record(event: AppEvent)
}

Concrete implementation:

class JsonEventRecorder(
  private val output: File
) : EventRecorder {
  private val events = mutableListOf<AppEvent>()

  override fun record(event: AppEvent) {
    events += event
  }

  fun flush() {
    output.writeText(Json.encodeToString(events))
  }
}

Hooking Into the UI

Instead of scattering logging everywhere, intercept events at the framework boundaries:

fun View.recordClicks(recorder: EventRecorder) {
  setOnClickListener {
    recorder.record(
      AppEvent.Click(
        viewId = resources.getResourceName(id),
        uptimeMs = SystemClock.uptimeMillis()
      )
    )
    performClick()
  }
}

This gives you a replayable timeline of user actions, not just logs.

2. Replaying Exact App Behavior

Recording is useless unless replay is exact, not approximate.

Core Principle: Control Time and Inputs

To replay deterministically, your app must:

Stop calling System.currentTimeMillis() directly
Stop relying on uncontrolled schedulers
Funnel inputs through replaceable abstractions

Time as a Dependency

Introduce a clock abstraction:

interface Clock {
  fun now(): Long
}

Production implementation:

object SystemClockImpl : Clock {
  override fun now() = SystemClock.uptimeMillis()
}

Replay implementation:

class ReplayClock(
  private val timestamps: Iterator<Long>
) : Clock {
  override fun now() = timestamps.next()
}

Now your business logic depends on Clock, not the system.

Replaying Events

Given a recorded event list:

fun replay(events: List<AppEvent>, clock: ReplayClock) {
  events.forEach { event ->
    when (event) {
      is AppEvent.Click -> {
        clock.now() // advances deterministically
        dispatchClick(event.viewId)
      }

      is AppEvent.IntentReceived -> {
        clock.now()
        dispatchIntent(event)
      }
    }
  }
}

This allows you to replay exact user timing, which is critical for concurrency bugs.

3. Reproducing Race Conditions Reliably

Why Race Conditions Are Hard

Race conditions depend on:

Thread scheduling
Relative timing of async operations
Hidden shared state

Traditional debugging changes thread scheduling, often “fixing” the bug.

Deterministic replay flips the problem: instead of observing races, you force them to happen again.

Making Concurrency Deterministic

Coroutines: Control Dispatchers

Never hardcode Dispatchers.IO or Dispatchers.Main in core logic.

Instead:

data class AppDispatchers(
  val main: CoroutineDispatcher,
  val io: CoroutineDispatcher
)

Production:

val prodDispatchers = AppDispatchers(
  main = Dispatchers.Main,
  io = Dispatchers.IO
)

Replay / test:

val replayDispatchers = AppDispatchers(
  main = StandardTestDispatcher(),
  io = StandardTestDispatcher()
)

Now coroutine execution order is controllable and repeatable.

Recording Scheduling Decisions

For deeper debugging, record when async boundaries are crossed.

suspend fun <T> recordedAsync(
  recorder: EventRecorder,
  block: suspend () -> T
): T {
  recorder.record(
    AppEvent.AsyncBoundary(SystemClock.uptimeMillis())
  )
  return block()
}

During replay, you can pause or advance execution at these boundaries, effectively time-travel debugging for concurrency.

Example: Reproducing a Real Race Condition

The Bug

User taps “Submit”
Network request starts
User rotates the device
ViewModel emits result after Activity recreation
Crash due to stale reference

Why It’s Hard

The rotation timing relative to the network callback determines whether the crash happens.

With Deterministic Replay

Record:
- Click event
- Lifecycle events
- Async boundary before network callback
Replay:
- Inject same timing
- Force callback after recreation

You can now reproduce the crash 100% of the time, locally.

Practical Guidelines for Android Projects

1. Treat Non-Determinism as a Dependency

Time, threading, randomness, and IO should all be injectable. If you can’t inject it, you can’t replay it.

2. Record at the Edges, Not Everywhere

Focus on:

User input
System callbacks
Async boundaries

Avoid noisy logs that don’t affect behavior.

3. Build Replay Into Debug Builds First

Start with:

Debug-only record/replay
Local storage
Simple JSON format

You can evolve to production-safe crash repros later.

4. Determinism Improves Design Even Without Replay

Even if you never build a full replay engine:

Injected clocks improve testability
Controlled dispatchers reduce flakiness
Explicit event modeling clarifies app behavior

Deterministic replay is not just a debugging technique, it’s a design discipline.

Deterministic replay debugging turns “it crashed once on a Samsung device” into a concrete, reproducible execution. For Android developers dealing with concurrency-heavy apps, this approach is not optional; it is the only scalable way to debug race conditions reliably.

You do not need perfect tooling to start. By recording user events, controlling time and dispatchers, and treating non-determinism as a dependency, you can bring determinism into your Android projects today, and permanently retire the phrase “cannot reproduce.”

Accessibility in React Native - The Gotchas That Break Real Apps

2026-03-24T00:00:00+00:00

Accessibility in mobile apps has crossed a line. It is no longer a “nice-to-have,” a checklist item for audits, or something you defer until version 2. Accessibility is now a legal requirement in many jurisdictions, and React Native apps are not exempt. More importantly, accessibility failures are usually not exotic edge cases—they are the result of everyday engineering decisions.

This article focuses on what actually breaks accessibility in real React Native apps, why those failures keep happening, and what developers can do, practically, to fix them without grinding the project to a halt.

Accessibility Is Now a Legal Requirement, Not a Best Practice

Regulations like the European Accessibility Act, ADA (US) enforcement, and WCAG-based national laws have changed the stakes. If your React Native app is used by the public: banking, transportation, healthcare, education, e-commerce—accessibility is enforceable.

The uncomfortable truth: “We didn’t know” is no longer a defense.

For developers, this means accessibility must be treated like:

Security
Performance
Data privacy

You do not “add it later.” You design and implement with it from day one, or you pay down painful accessibility debt indefinitely.

Why Accessibility Fails at the Engineering Level

Accessibility usually fails systemically, not individually.

1. No Ownership

No one “owns” accessibility, so everyone assumes someone else will handle it:

Designers assume devs will fix it
Devs assume QA will catch it
QA assumes it was designed correctly

Result: nobody fixes it.

2. No Feedback Loops

Most teams:

Don’t test with screen readers
Don’t use keyboard navigation
Don’t include accessibility checks in CI

If you never experience the failure, you will keep shipping it.

3. Component Libraries Without Contracts

Teams build design systems that define colors and spacing, but not accessibility behavior.

If a Button component:

Does not enforce labels
Does not expose roles
Does not manage focus

Then every screen built with it is already broken.

The Fundamentals That Matter Most and Are Still Broken in Most Apps

Most accessibility bugs come from ignoring a small set of fundamentals.

1. Semantic Meaning Beats Visual Design

Screen readers do not care how your UI looks. They care about roles, labels, and hierarchy.

Common failures:

Touchable icons with no labels
Custom components that hide semantics
Text that looks like a button but isn’t one

Bad example:

<TouchableOpacity onPress={submit}>
  <Icon name="send"/>
</TouchableOpacity>

Better:

<TouchableOpacity
  onPress={submit}
  accessibilityRole="button"
  accessibilityLabel="Send message"
>
  <Icon name="send"/>
</TouchableOpacity>

If an element is interactive, it must:

Have a role
Have a clear, spoken label
Behave consistently

2. Focus Order Is Not Optional

Keyboard and screen reader users navigate linearly, not spatially. If focus order is wrong, your app is unusable.

Red flags:

Modals that don’t trap focus
Invisible elements receiving focus
Focus jumping unpredictably after navigation

React Native does not automatically fix this for you.

React Native-Specific Pitfalls That Cause Accessibility Regressions

React Native adds its own set of traps that even experienced developers fall into.

1. Custom Components That Strip Accessibility

Wrapping everything in View is a silent killer.

<View onTouchEnd={onPress}>
  <Text>Continue</Text>
</View>

This is not accessible:

No role
No keyboard support
No screen reader hint

Use Pressable, TouchableOpacity, or explicit roles instead.

<Pressable
  onPress={onPress}
  accessibilityRole="button"
>
  <Text>Continue</Text>
</Pressable>

2. Absolute Positioning and Overlays

React Native apps love overlays: bottom sheets, snackbars, custom modals. These often:

Sit visually on top
But remain behind in the accessibility tree

If a modal opens and background elements are still accessible, you have broken the app for screen reader users.

Use:

accessibilityViewIsModal={true}

And explicitly manage focus when the modal opens.

3. Dynamic Content Without Announcements

React Native does not automatically announce state changes.

Examples:

Form errors appearing
Loading states completing
Validation messages updating

You must announce changes explicitly.

import {AccessibilityInfo} from 'react-native';

AccessibilityInfo.announceForAccessibility(
  'Payment successful'
);

If you don’t do this, screen reader users are left guessing.

How to Make Accessibility Achievable in a Real React Native Codebase

Accessibility is not about heroics. It is about constraints, defaults, and automation.

1. Bake Accessibility Into Core Components

Your base components should make it hard to do the wrong thing.

type AccessibleButtonProps = {
  label: string;
  onPress: () => void;
};

export function AccessibleButton({label, onPress}: AccessibleButtonProps) {
  return (
    <Pressable
      accessibilityRole="button"
      accessibilityLabel={label}
      onPress={onPress}
    >
      <Text>{label}</Text>
    </Pressable>
  );
}

If developers must provide a label, accessibility improves by default.

2. Enforce Rules With Tooling

Use lint rules and static analysis:

Disallow View with touch handlers
Warn on missing accessibilityLabel
Flag Pressable without roles

Accessibility should fail builds—not audits months later.

3. Test With Screen Readers (Yes, Really)

Every React Native developer should:

Turn on VoiceOver (iOS)
Turn on TalkBack (Android)
Navigate at least one screen per sprint

This changes behavior fast. You will stop shipping inaccessible UI once you feel how broken it is.

4. Treat Accessibility Bugs as Severity-One

An inaccessible checkout is as broken as a crashing checkout.

If users:

Cannot submit a form
Cannot understand errors
Cannot navigate a modal

The feature does not work. Treat it that way.

Final Thoughts: Accessibility Is a Developer Skill, Not a Compliance Task

React Native does not prevent you from building accessible apps, but it will not save you either. The framework gives you just enough rope to hang your users if you are careless.

The teams that succeed at accessibility:

Design with semantics, not visuals
Build components with constraints
Test continuously
Assign real ownership

Accessibility is not about perfection. It is about not breaking real people’s ability to use your app. And that responsibility sits squarely with the engineers shipping the code.

Building Robust Persistence with Spring

2026-03-19T00:00:00+00:00

Most Spring projects start their persistence story with Spring Data JPA repositories. That is usually the right choice, but many projects stagnate there. Performance issues, unclear transaction behavior, and “mysterious” bugs often come not from JPA itself, but from an incomplete mental model of how it actually works inside the Spring Framework.

This article goes beyond CRUD repositories and focuses on what developers can actively do to improve correctness, performance, and maintainability.

1. JPA Persistence Context and Dirty Checking

At the heart of JPA is the persistence context. It is essentially a first-level cache that tracks managed entities within a transaction.

@Transactional
public void updateEmail(Long userId, String email) {
  User user = entityManager.find(User.class, userId);
  user.setEmail(email);
}

There is no save() call here, yet the update will be flushed to the database. This happens through dirty checking: JPA compares the entity’s current state with the snapshot it took when the entity was loaded.

What developers can do better

Understand what is managed: Only entities loaded within the persistence context are tracked. Detached entities are not dirty-checked.

User user = userRepository.findById(id).get();
entityManager.detach(user);
user.setEmail("x@y.com"); // no update

Control flush timing: Flushing does not mean committing. A flush can happen:

Before query execution
At transaction commit
Explicitly via entityManager.flush()

For write-heavy code paths, delaying flushes avoids unnecessary SQL.

entityManager.setFlushMode(FlushModeType.COMMIT);

Avoid unintended updates: Changing fields on managed entities inside read-only logic is a common source of bugs.

@Transactional(readOnly = true)
public UserDto getUser(Long id) {
  User user = userRepository.findById(id).get();
  user.setLastAccess(Instant.now()); // still flushed in many JPA providers
}

If it should not update, map to DTOs early or detach entities.

2. Transaction Boundaries and Propagation

Spring’s @Transactional is deceptively simple. The real power (and danger) lies in transaction propagation.

Default behavior

@Transactional
public void outer() {
  inner();
}

@Transactional
public void inner() {
  // joins the same transaction
}

Both methods run in the same transaction.

Common propagation modes

REQUIRED (default): join or create
REQUIRES_NEW: suspend current, start new
MANDATORY: fail if none exists
NOT_SUPPORTED: suspend transaction

Real-world example

@Transactional
public void placeOrder(Order order) {
  orderRepository.save(order);
  auditService.logOrder(order); // should never rollback order
}

@Transactional(propagation = Propagation.REQUIRES_NEW)
public void logOrder(Order order) {
  auditRepository.save(new AuditLog(order));
}

Now, even if audit logging fails, the order transaction can still commit.

What developers can do better

Define transaction boundaries at the service layer: Repositories should not own transactions. Services express business intent.
Avoid transactional self-invocation: Spring uses proxies. Calling another @Transactional method in the same class bypasses the proxy.

this.inner(); // no transaction semantics applied

Split responsibilities into separate beans.

Be explicit about read-only: It enables optimizations at both Spring and JPA levels.

@Transactional(readOnly = true)
public List<User> findActiveUsers() { ... }

3. The N+1 Problem (and Real Fixes)

The N+1 problem is not folklore, it is deterministic behavior caused by lazy loading.

List<Order> orders = orderRepository.findAll();
for (Order order : orders) {
  System.out.println(order.getCustomer().getName());
}

One query for orders, N queries for customers.

Real fixes (not myths)

Myth: “Just make everything EAGER” This leads to Cartesian explosions and memory waste.

Fix 1: Fetch joins

@Query("""
  select o from Order o
  join fetch o.customer
""")
List<Order> findAllWithCustomer();

This is the most reliable fix for read use cases.

Fix 2: Entity graphs

@EntityGraph(attributePaths = "customer")
List<Order> findAll();

Cleaner than fetch joins when you want reuse without query duplication.

Fix 3: Batch fetching (Hibernate-specific)

With Hibernate, batching reduces N queries into fewer queries.

hibernate.default_batch_fetch_size=50

This does not eliminate N+1, but makes it N / batch_size + 1.

What developers can do better

Profile SQL early (P6Spy, datasource-proxy)
Design queries around read models, not entities
Use DTO projections when relationships are deep

record OrderView(Long id, String customerName) {}

@Query("""
  select new com.example.OrderView(o.id, c.name)
  from Order o join o.customer c
""")
List<OrderView> findOrderViews();

4. Choosing the Right Persistence Tool

JPA is powerful, but it is not universal. Mature projects mix persistence approaches intentionally.

When to use JPA

Use JPA when:

You need complex domain modeling
Aggregates and invariants matter
Writes and consistency are important

JPA shines when entities reflect business concepts, not tables.

When to use JDBC Template

jdbcTemplate.query(
  "select id, total from orders where status = ?",
  mapper,
  "PAID"
);

Use JDBC Template when:

Queries are complex and hand-tuned
You need predictable SQL
Bulk operations dominate

It avoids persistence context overhead entirely.

When to use R2DBC

R2DBC is not “reactive JPA”. It is a different paradigm.

Use it when:

You have high concurrency with IO-bound workloads
End-to-end reactive stacks are required
You accept simpler mapping models

Do not mix blocking JPA calls into reactive pipelines.

When to use NoSQL integrations

Spring integrates well with MongoDB, Redis, Cassandra, and others.

Use NoSQL when:

Schema flexibility is required
Reads dominate and denormalization is acceptable
Horizontal scaling matters more than transactions

Avoid forcing JPA-style modeling onto document databases.

Conclusion

Going beyond Spring Data JPA does not mean abandoning it. It means understanding:

How the persistence context really behaves
Where transactions begin and end
Why N+1 happens and how to eliminate it
When not to use JPA at all

Teams that master these areas write systems that scale predictably, fail gracefully, and remain understandable years later. Spring gives you the tools, but disciplined usage is what turns them into robust architecture.

Building Bulletproof Navigation in SwiftUI with Typed Graphs

2026-03-17T00:00:00+00:00

Navigation is one of the first things that starts simple in an iOS project, and one of the first things that becomes fragile as the app grows. A couple of NavigationLink’s, some string-based deep links, maybe a few conditionals, and everything looks fine. Until it doesn’t.

SwiftUI gives us powerful primitives for navigation, but it does not enforce how we model navigation. That choice is left to the developer, and most teams default to loosely typed approaches that silently accumulate risk. Typed navigation graphs are, in my opinion, the most impactful architectural upgrade you can make to a SwiftUI codebase once it moves beyond a prototype.

This article focuses on what you, as a developer, can actively do to move from fragile navigation to a system that is safer, refactor-friendly, and validated at compile time.

Many SwiftUI apps start with patterns like these:

NavigationLink("Profile", destination: ProfileView(userId: user.id))

or, for deep links:

enum DeepLink {
  case profile(String)
  case settings
}

Worse, some projects rely on raw strings:

NavigationLink(value: "profile/\(user.id)") { ... }

These approaches have three systemic problems:

No compile-time validation of transitions
No guarantee that a destination still exists after refactors
Invalid deep links are only discovered at runtime

Swift’s type system is being underutilized. Typed navigation graphs fix that.

A typed navigation graph is a closed, explicit model of every navigable state in your app. Instead of navigating to views, strings, or ad-hoc destinations, you navigate to types, usually enums or structs.

At a high level:

Every screen is represented as a case
Associated data is encoded in the type system
Navigation paths are validated at compile time
Deep links cannot point to invalid destinations

This aligns navigation with the same principles we already apply to domain modeling.

The foundation is a strongly typed route definition:

enum AppRoute: Hashable {
  case home
  case profile(userID: User.ID)
  case settings
  case editProfile(userID: User.ID)
}

This immediately eliminates an entire class of bugs:

You cannot navigate to a non-existent screen
You cannot forget required parameters
You cannot pass the wrong data type

This enum is your navigation graph. If a route does not exist here, it does not exist in the app.

SwiftUI’s NavigationStack is designed for typed navigation:

struct RootView: View {
@State private var path = NavigationPath()
  var body: some View {
    NavigationStack(path: $path) {
      HomeView(onNavigate: { route in
        path.append(route)
      })
      .navigationDestination(for: AppRoute.self) { route in
        destination(for: route)
      }
    }
  }

  @ViewBuilder
  private func destination(for route: AppRoute) -> some View {
    switch route {
    case .home:
      HomeView(onNavigate: { path.append($0) })

    case .profile(let userID):
      ProfileView(userID: userID)

    case .settings:
      SettingsView()

    case .editProfile(let userID):
      EditProfileView(userID: userID)
    }
  }
}

This switch statement is critical. It forces you to handle every possible route. If you add a new screen to AppRoute, the compiler will force you to update navigation.

That is not friction, that is safety.

Step 3: Validate Transitions at Compile Time

Typed routes enable something more powerful than just safe destinations: validated transitions.

Instead of letting any screen navigate anywhere, define intent-specific APIs:

protocol ProfileNavigating {
  func goToEditProfile(userID: User.ID)
}

struct ProfileView: View {
  let userID: User.ID
  let navigator: ProfileNavigating

  var body: some View {
    Button("Edit Profile") {
      navigator.goToEditProfile(userID: userID)
    }
  }
}

And implement it centrally:

extension RootView: ProfileNavigating {
  func goToEditProfile(userID: User.ID) {
    path.append(.editProfile(userID: userID))
  }
}

Now:

The profile screen cannot accidentally navigate to settings
The allowed transitions are explicit
Illegal navigation paths are impossible to express

This is compile-time enforcement of navigation rules, something string-based systems simply cannot offer.

Step 4: Eliminate Invalid Deep Links Entirely

Deep linking is where weak navigation systems completely fall apart.

With typed routes, deep links become just another initializer:

extension AppRoute {
  init?(url: URL) {
    guard let host = url.host else { return nil }

    switch host {
    case "profile":
      guard
        let userID = url.pathComponents.dropFirst().first,
        let id = User.ID(uuidString: userID)
      else { return nil }
      self = .profile(userID: id)

    case "settings":
      self = .settings

    default:
      return nil
    }
  }
}

Key improvement: invalid deep links cannot produce a route.

If parsing fails, navigation does not happen. There is no “best effort” fallback, no half-initialized screen, no runtime crash.

Handling the link becomes trivial:

if let route = AppRoute(url: url) {
  path.append(route)
}

Your app either understands the deep link, or it doesn’t. That clarity is a feature.

Step 5: Make Refactors Safe and Cheap

This is where typed navigation graphs pay for themselves. Imagine renaming EditProfileView to ProfileEditorView. With string-based navigation, you are hunting runtime failures. With typed routes:

Rename the view
Fix the compiler errors
You are done

If a screen is removed, the enum case is removed, and the compiler tells you every place that depended on it.

This dramatically lowers the cost of architectural change, which in turn encourages healthier refactors instead of navigation rot.

A strong navigation graph lets views focus on UI and intent, not mechanics.

Bad pattern:

NavigationLink(destination: SettingsView()) {
  Text("Settings")
}

Better pattern:

Button("Settings") {
  onNavigate(.settings)
}

The view declares what it wants, not how navigation works. This separation is essential for:

Testability
Reuse
Predictable navigation flows

Typed navigation graphs act as the contract between views and the app shell.

Why This Is Worth Doing

Typed navigation graphs are not “extra abstraction.” They are the natural extension of Swift’s strengths into an area that is traditionally under-modeled.

The benefits are concrete:

Safer navigation
Compile-time validation of transitions
Impossible invalid deep links
Refactors that don’t break at runtime
Clear ownership of navigation logic

If your SwiftUI project is more than a toy app, relying on strings or ad-hoc navigation is a liability. Encoding navigation in types is not just cleaner, it is the difference between a navigation system you hope works and one the compiler guarantees.

If you care about correctness, long-term velocity, and fearless refactoring, typed navigation graphs are not optional. They are the obvious next step.

Domain-Driven Design on Android - From Buzzword to Working Architecture

2026-03-12T00:00:00+00:00

Domain-Driven Design (DDD) is frequently mentioned in Android projects, conference talks, and architectural diagrams. In practice, however, it is rarely applied. What most Android teams call “DDD” is usually a mix of MVVM, Clean Architecture, and some renamed packages. The result often looks organized but still couples UI, frameworks, and business rules in ways that make the system hard to test and harder to evolve.

This article is opinionated: DDD is absolutely viable on Android, but only if you stop treating it as a layering exercise and start treating it as a modeling discipline. The goal is not prettier diagrams; the goal is portable, testable business logic that survives UI rewrites and platform changes.

Below is what actually applying DDD on Android looks like, and what you can do, concretely, to improve your project.

The Core Problem: Android Projects Fake DDD

Most Android codebases suffer from three recurring issues:

Primitive obsession: IDs, money, dates, and states are passed around as String, Int, or Double.
Business rules in ViewModels: Validation, state transitions, and invariants live next to UI state.
Aggregates ignored: Entities are mutated freely without enforcing consistency boundaries.

Teams say “we use DDD,” but the domain layer is either anemic or nonexistent.

Real DDD on Android means:

The domain layer owns the rules
The UI is a dumb consumer
The domain is framework-free

Correct Usage #1: Value Objects (Stop Passing Primitives)

If your domain methods accept String, Int, or Double directly, you are not modeling a domain; you are passing data around.

Bad (Typical Android Code)

fun placeOrder(
  userId: String,
  totalPrice: Double,
  currency: String
)

Nothing here enforces correctness:

Is totalPrice allowed to be negative?
Is currency valid?
Is userId empty?

All validation is delayed, or forgotten.

Good: Explicit Value Objects

@JvmInline
value class UserId(val value: String) {
  init {
    require(value.isNotBlank())
  }
}

@JvmInline
value class Money(val amount: BigDecimal) {
  init {
    require(amount >= BigDecimal.ZERO)
  }
}

Now your domain API becomes:

fun placeOrder(
  userId: UserId,
  total: Money
)

Why This Matters

Invalid states are unrepresentable
Validation happens once
Tests become trivial
Bugs stop leaking across layers

Actionable improvement: Search your domain code for String, In``t, and Double. Every time one represents a concept, replace it with a value object.

Correct Usage #2: Aggregates Enforced in the Domain Layer

In many Android apps, entities are treated like mutable bags of data. Repositories expose them, ViewModels mutate them, and invariants are violated silently.

That is not DDD.

What an Aggregate Actually Is

An aggregate is:

A consistency boundary
A root entity that controls all modifications
The only entry point for state changes

Example: Order Aggregate

class Order(
  val id: OrderId,
  private val items: MutableList<OrderItem>,
  private var status: OrderStatus
) {
  fun addItem(item: OrderItem) {
    items.add(item)
    require(status == OrderStatus.DRAFT)
  }

  fun confirm() {
    require(items.isNotEmpty())
    status = OrderStatus.CONFIRMED
  }
}

Notice:

No setters
State transitions are explicit
Rules live inside the aggregate

Repository Returns the Aggregate

interface OrderRepository {
  fun load(orderId: OrderId): Order
  fun save(order: Order)
}

The UI never mutates items directly. The ViewModel asks the aggregate to do things.

Actionable improvement: If your entities have public setters or mutable fields accessed from outside the domain layer, your aggregates are broken.

Correct Usage #3: UI Unaware of Business Rules

ViewModels are not the domain layer. They are orchestration code.

If your ViewModel contains logic like:

“If status is X, user can do Y”
“Validate input before saving”
“Calculate totals”

You have already lost.

Bad ViewModel Example

fun onConfirmClicked() {
  if (items.isEmpty()) {
    showError("Order is empty")
    return
  }
  order.status = CONFIRMED
}

This logic is business logic disguised as UI logic.

Correct Approach: Use Cases (Application Services)

class ConfirmOrderUseCase(
  private val repository: OrderRepository
) {
  fun execute(orderId: OrderId) {
    val order = repository.load(orderId)
    order.confirm()
    repository.save(order)
  }
}

ViewModel Becomes Thin

fun onConfirmClicked() {
  confirmOrderUseCase.execute(currentOrderId)
}

The ViewModel:

Does not know why confirmation might fail
Does not enforce rules
Only reacts to outcomes

Actionable improvement: Delete business logic from ViewModels. If a rule affects multiple screens, it does not belong in the UI layer.

Testing Becomes Trivial (And Fast)

Once business rules live in the domain, tests stop depending on Android.

Domain Test Example

@Test
fun `cannot confirm empty order`() {
  val order = Order(
    id = OrderId("123"),
    items = mutableListOf(),
    status = OrderStatus.DRAFT
  )

  assertFailsWith<IllegalStateException> {
    order.confirm()
  }
}

No:

Instrumentation tests
Robolectric
Mocked ViewModels

Just Kotlin and JUnit.

Actionable improvement: If your tests require Android runtime to verify business rules, your architecture is wrong.

The Real Benefit: Portability

When done correctly, your domain layer:

Has zero Android imports
Can run on JVM, backend, or another platform
Survives UI rewrites (XML → Compose → whatever comes next)

This is not theoretical. Teams that apply DDD properly often:

Share domain logic between Android and backend
Rebuild UI layers without touching core rules
Catch bugs earlier with fast unit tests

Practical Migration Strategy

You do not need a rewrite:

Start with value objects: Replace primitives in new code first.
Move rules inward: Every time you see validation in UI, move it to the domain.
Lock down aggregates: Remove setters. Expose behavior, not state.
Enforce boundaries: Domain must not depend on Android, Retrofit, Room, or Compose.

Closing Points

Most Android projects claim to use DDD and do not. They adopt the vocabulary without the discipline. The fix is not another architecture diagram; it is relentless enforcement of modeling rules.

If your UI knows business rules, your domain is anemic. If your domain passes primitives, it is not a model. If your business logic is hard to test, your architecture is lying to you.

Apply DDD properly, and Android becomes just another delivery mechanism, not the center of your system.

React Native Runtime-Generated UI Layouts - From Figma to a Live App

2026-03-10T00:00:00+00:00

Most applications still ship fixed UI layouts: screens compiled into the app binary, updated only when a new version hits the store. This approach is increasingly misaligned with modern product development. Design changes are frequent, experiments are constant, and coordination costs between designers and developers are high.

Runtime-generated UI layouts, where the UI tree is produced dynamically from JSON or design tokens derived from tools like Figma, offer a fundamentally better model. When done well, they turn layout into data, not code, and unlock a level of velocity that static UIs cannot match.

In this article I focus on what developers can do to implement this approach responsibly and effectively.

From Fixed Screens to Runtime UI Trees

The core idea

Instead of shipping precompiled layouts, the app ships a UI renderer. Layouts are described declaratively and delivered at runtime:

JSON schemas describe view hierarchies
Design tokens define spacing, typography, colors
Constraints define how elements size and position themselves

At runtime, the app parses this data and builds a UI tree.

Example (simplified JSON layout):

{
  "type": "Column",
  "padding": "md",
  "children": [
    {
      "type": "Text",
      "token": "heading.lg",
      "value": "Welcome back"
    },
    {
      "type": "Button",
      "variant": "primary",
      "action": "open_profile",
      "label": "View profile"
    }
  ]
}

The app does not know this screen at compile time. It only knows how to render a Column, Text, and Button.

What developers must build

To make this viable, developers need to invest in:

A stable, expressive UI schema
A robust renderer
Clear boundaries between layout and logic

This is not a shortcut, it is infrastructure.

Designers Push Changes Without App Updates

One of the most powerful outcomes of runtime layouts is that design changes no longer require app releases.

Spacing tweaks, copy updates, component rearrangements, and even new screens can be delivered remotely. This shifts the bottleneck from app stores to your backend.

Developer responsibility: enforce safety

Unrestricted runtime UI is dangerous. Developers must:

Validate schemas strictly
Version schemas explicitly
Fail gracefully on unknown nodes

Example schema validation:

type Node =
  | { type: "Text"; value: string; token: string }
  | { type: "Button"; label: string; action: string }
  | { type: "Column"; children: Node[]; padding?: string };

function validateNode(node: any): node is Node {
  if (typeof node !== "object" || !node.type) return false;

  switch (node.type) {
    case "Text":
      return typeof node.value === "string";
    case "Button":
      return typeof node.action === "string";
    case "Column":
      return Array.isArray(node.children);
    default:
      return false;
  }
}

If validation fails, the renderer should display a fallback, not crash the app.

Feature Flags as Layout, Not Just Logic

Most teams treat feature flags as logic toggles:

if (flags.newProfile) {
  showNewProfile();
} else {
  showOldProfile();
}

Runtime UI flips this model. The layout itself is the flag.

Example server response:

{
  "layoutVersion": "profile_v3",
  "tree": {
    ...
  }
}

Developers no longer branch UI logic. They simply render what the backend provides.

Why this is better

No dead UI code paths
No combinatorial explosion of flags
Rollbacks are instant
A/B tests become layout swaps

What developers must do differently

Treat layout selection as data, not conditionals
Move experiment logic server-side
Keep client renderers deterministic

Compiling Figma-Like Constraints to Real Layout Engines

Advanced teams go further: they compile design constraints instead of hand-mapping layouts.

Design tools like Figma define relationships:

Hug contents
Fill container
Fixed ratios
Min/max constraints

These can be translated into real layout systems like Flexbox or Skia.

Constraint → Flexbox

Figma constraint:

Button:
  width: hug
  horizontal: fill

Compiled output:

{
  "type": "Button",
  "style": {
    "flexGrow": 1,
    "alignSelf": "stretch"
  }
}

Developer responsibility: build a constraint compiler

This is not a designer problem. Developers must:

Define a constraint DSL
Map constraints to platform layout primitives
Ensure deterministic output across platforms

This compiler can live:

In CI (preprocessing Figma exports)
On the backend
Or even in the app (less ideal)

The key is one source of truth.

Version UI Schemas Independently from App Code

A common failure mode is tying UI schemas to app releases. This defeats the purpose.

Correct approach

UI schemas have their own versioning
Apps declare supported schema ranges
Backend selects compatible schemas

Example:

{
  "schema": "ui.v2",
  "minAppVersion": "5.4.0",
  "tree": {
    ...
  }
}

On the client:

if (!supportedSchemas.includes(payload.schema)) {
  renderFallback();
}

Why this matters

You can ship new UI without forcing upgrades
Old apps continue to work safely
Deprecation becomes controlled, not rushed

Improving Developer Experience (DX)

Runtime UI systems often fail because developers hate working with them. You can fix that.

Generate types from schemas

If your UI schema is JSON, generate types automatically:

json-schema-to-typescript ui.schema.json > ui.ts

This restores autocomplete, refactoring, and safety.

Snapshot testing for layouts

Treat layouts like code:

test("profile layout v3", () => {
  expect(render(layoutJson)).toMatchSnapshot();
});

This catches accidental breaking changes early.

Local preview tooling

Developers should be able to:

Load a layout JSON locally
Hot-reload changes
Inspect resolved constraints

Without this, iteration speed collapses.

Performance and Caching Are Your Job

Runtime UI skeptics often complain about performance. In practice, performance issues come from bad implementations, not the model.

Developers should:

Cache parsed layouts
Precompute layout trees
Avoid reflection-heavy rendering paths

Example memoization:

const cache = new Map<string, RenderNode>();

function renderLayout(id: string, json: LayoutJson) {
  if (cache.has(id)) return cache.get(id)!;

  const tree = buildTree(json);
  cache.set(id, tree);
  return tree;
}

Runtime does not mean slow. It means dynamic.

Conclusion: This Is a Structural Upgrade

Runtime-generated UI layouts are not a trend or a nice-to-have. They are a structural upgrade to how apps evolve.

Teams that succeed with this model share one trait: developers take ownership.

They define schemas rigorously
They build compilers, not ad-hoc mappers
They protect stability with validation and versioning
They treat UI as data, not magic

If you are serious about speed, experimentation, and long-term maintainability, fixed layouts are technical debt. Runtime UI is the correction, but only if developers do the hard work upfront.

Building Production-Grade Integration Tests with Testcontainers and Spring

2026-03-05T00:00:00+00:00

Integration testing in Spring projects often starts with good intentions and ends with fragile compromises: in-memory databases, mocked brokers, and profiles that behave nothing like production. Testcontainers changes that equation by making real infrastructure cheap, disposable, and automatable. When combined correctly with the Spring Framework, especially Spring Boot, it enables integration tests that are both realistic and fast enough to run continuously.

In this article I talk about what developers can actively do to improve their projects when adopting Testcontainers. The emphasis is not on “how to start,” but on how to structure, optimize, and scale its usage across a mature Spring codebase.

Lifecycle Management & Context Caching

The first mistake teams make with Testcontainers is treating containers as test-local resources. Doing so defeats Spring’s strongest feature: ApplicationContext caching.

The problem

If each test class starts and stops its own container, Spring sees a different environment every time and invalidates the cached context. This leads to:

Slow test suites
Repeated container startups
Inconsistent configuration

The solution: static, shared containers

Containers should usually be:

Static
Started once per test suite
Declared outside individual test methods

@Testcontainers
public abstract class AbstractIntegrationTest {

  @Container
  static PostgreSQLContainer<?> postgres =
      new PostgreSQLContainer<>("postgres:16-alpine")
          .withDatabaseName("testdb")
          .withUsername("test")
          .withPassword("test");
}

Spring will reuse the same ApplicationContext as long as the environment properties remain stable.

Dynamic property registration

Instead of hardcoding properties, register them dynamically:

@DynamicPropertySource
static void registerProperties(DynamicPropertyRegistry registry) {
  registry.add("spring.datasource.url", postgres::getJdbcUrl);
  registry.add("spring.datasource.username", postgres::getUsername);
  registry.add("spring.datasource.password", postgres::getPassword);
}

Developer takeaway: Design your test infrastructure for context reuse first. Containers are infrastructure, not test data.

Integration with Spring Boot Test Infrastructure

Spring Boot’s test infrastructure already solves 80% of integration testing problems, Testcontainers should plug into it, not replace it.

Prefer @SpringBootTest over slicing too early

For infrastructure-heavy tests (databases, messaging, caches), use:

@SpringBootTest
@ActiveProfiles("test")
class OrderServiceIT extends AbstractIntegrationTest {
  // real wiring, real infrastructure
}

Avoid premature test slicing (@DataJpaTest, @WebMvcTest) when your goal is validating system behavior across layers.

Replace @TestPropertySource

With Testcontainers, static property files often become liabilities. Use:

@DynamicPropertySource
or Spring Boot 3.1+ @ServiceConnection

@Container
@ServiceConnection
static PostgreSQLContainer<?> postgres =
  new PostgreSQLContainer<>("postgres:16-alpine");

Spring Boot will auto-configure the datasource without explicit property mapping.

Developer takeaway: Let Spring Boot do the wiring. Testcontainers should provide resources, not configuration logic.

Database Containers & Migration Strategy

Databases are where integration tests most commonly diverge from production, and where Testcontainers delivers the highest return.

Always test against the real engine

If production uses PostgreSQL, do not test with H2 or HSQLDB. Subtle differences in:

SQL dialect
Index behavior
JSON support
Transaction isolation

will surface in production otherwise.

Migrations are part of the test contract

Database migrations should:

Run automatically on test startup
Fail fast if broken
Never be skipped in tests

Using Flyway:

spring:
  flyway:
    enabled: true
    locations: classpath:db/migration

Testcontainers ensures a clean database every time, so migrations become deterministic.

Seed data intentionally

Avoid large SQL dumps. Instead:

Use migration scripts for schema
Use small, explicit fixtures for test data

@Sql("/sql/seed-orders.sql")
  class OrderRepositoryIT extends AbstractIntegrationTest {
}

Developer takeaway: If migrations are not tested continuously, they are untested code.

Messaging & External Dependencies (Kafka, Redis, etc.)

Modern Spring systems rarely depend on a single database. Messaging systems, caches, and external services are just as critical, and just as testable.

Kafka with Testcontainers

@Container
static KafkaContainer kafka =
  new KafkaContainer(DockerImageName.parse("confluentinc/cp-kafka:7.6.0"));

@DynamicPropertySource
static void kafkaProps(DynamicPropertyRegistry registry) {
  registry.add("spring.kafka.bootstrap-servers", kafka::getBootstrapServers);
}

Now your @KafkaListener beans are wired against a real broker.

Redis for caching and locks

@Container
static GenericContainer<?> redis =
  new GenericContainer<>("redis:7-alpine")
    .withExposedPorts(6379);

Avoid embedded Redis or mock caches. Cache invalidation bugs are logic bugs.

Compose dependencies explicitly

For complex setups, consider DockerComposeContainer or multiple containers in a shared base class.

Developer takeaway: If production depends on it, tests should too—especially messaging systems.

CI/CD & Developer Experience Optimization

Testcontainers succeeds or fails based on how well it integrates into daily development and CI pipelines.

Enable container reuse locally

For developers, container startup time matters.

Enable reuse:

testcontainers.reuse.enable=true

Mark containers as reusable:

.withReuse(true)

This dramatically speeds up local test execution.

Parallelize safely

Testcontainers supports parallel test execution if:

Containers are shared
Test data is isolated per test

Avoid global mutable state in tests.

CI considerations

Use Docker-in-Docker or remote Docker daemons
Cache container images aggressively
Fail fast on infrastructure startup issues

Most CI failures related to Testcontainers are environmental, not test-related. Make infrastructure logs visible.

Make tests runnable by default

A developer should be able to run:

./mvnw test

No profiles. No flags. No “read the wiki.”

Developer takeaway: Integration tests only add value if developers actually run them.

Final Opinionated Guidance

Testcontainers is not just a testing library, it is a design constraint that nudges teams toward production realism. Used poorly, it slows test suites and frustrates developers. Used well, it becomes invisible infrastructure that quietly prevents entire classes of bugs.

The winning strategy is consistent:

Share containers
Let Spring manage wiring
Test real dependencies
Optimize for developer feedback loops

If your integration tests still lie to you, the problem is not Testcontainers, it is how you are using it.

Compile-Time Power - Building Cleaner iOS Architectures with Swift Macros

2026-03-03T00:00:00+00:00

Swift Macros fundamentally change how iOS developers can structure, enforce, and scale architecture. Instead of relying on runtime tricks, reflection, or external code generation tools, macros allow you to move architectural concerns directly into the compiler. The result is less boilerplate, stronger guarantees, and codebases that age far better under growth.

This article focuses on what you, as an iOS developer, can actively do today to improve your projects using macro-driven architecture.

What Makes Swift Macros Architecturally Relevant?

Swift Macros operate at compile time. They can inspect declarations, generate new code, emit diagnostics, and even fail builds when architectural rules are violated. This shifts responsibility away from conventions and documentation and into enforceable, automated constraints.

Macros are not syntactic sugar. They are a structural tool. Used well, they allow you to:

Generate infrastructure code once, correctly
Enforce architectural rules consistently
Remove entire runtime layers
Eliminate external code generators
Make architecture explicit and compiler-verified

1. Boilerplate-Free Dependency Injection

Dependency Injection is conceptually simple but mechanically noisy. Initializers, factories, registrations, and wiring dominate files that should express behavior.

With macros, DI becomes declarative.

Traditional Approach

final class UserService {
  private let api: APIClient
  private let cache: Cache

  init(api: APIClient, cache: Cache) {
    self.api = api
    self.cache = cache
  }
}

Multiply this by hundreds of types and the architecture collapses under repetition.

Macro-Driven DI

@AutoInjectable
final class UserService {
  let api: APIClient
  let cache: Cache
}

The macro expands at compile time into:

A synthesized initializer
Optional factory methods
Registration hooks for a container

You can go further:

@AutoInjectable(scope: .singleton)
final class AnalyticsService {
  let tracker: EventTracker
}

Now the compiler generates lifecycle-aware DI without runtime containers, reflection, or string-based keys.

Developer takeaway: Define what a type needs. Let the compiler generate how it is wired.

2. Enforcing Architectural Rules at Compile Time

Most iOS architectures rely on conventions:

“Views shouldn’t talk to networking”
“Repositories must not depend on UI”
“Features cannot import other features”

These rules usually live in README files and are violated quietly over time. Macros make violations impossible.

Example: Enforcing Layer Boundaries

@FeatureModule
struct ProfileFeature {}

Now enforce rules:

@DisallowImport("Networking")
@DisallowImport("Database")
struct ProfileViewModel {}

If someone adds:

import Networking

The build fails with a compiler diagnostic:

❌ ProfileViewModel must not depend on Networking

This is not a lint warning. This is a hard compile error.

You can also enforce protocol usage:

@Service
@MustDependOnProtocolsOnly
final class FeedViewModel {
  let feedService: FeedServiceProtocol
}

If a concrete type sneaks in, the compiler stops the build.

Developer takeaway: If an architectural rule matters, encode it as a macro or it will be broken.

3. Zero-Runtime-Cost Logging, Tracing, and Metrics

Most logging systems:

Add runtime overhead
Require dynamic checks
Pollute business logic
Depend on build flags and global state

Macros eliminate all of that.

Compile-Time Logging

@Trace
func loadProfile(id: UserID) async throws -> Profile {
  ...
}

The macro expands differently depending on configuration:

Debug build:

print("→ loadProfile(id: \(id))")
// original body
print("← loadProfile completed")

Release build:

// original body only

No conditionals. No logging framework. No runtime cost.

Metrics Without Pollution

@MeasureLatency("profile.load")
func loadProfile() async throws -> Profile

The macro injects timing code only when metrics are enabled.

Developer takeaway: Instrumentation belongs at compile time, not inside business logic.

4. Replacing Code Generation Tools Entirely

Many iOS projects depend on:

Sourcery
SwiftGen
Custom build scripts
YAML or JSON config files

These tools:

Break incremental builds
Increase CI complexity
Fail silently
Live outside the compiler’s understanding

Macros replace all of them.

Example: Asset Accessors

@GenerateAssets
enum Assets {}

The macro inspects the asset catalog and generates:

enum Assets {
  static let appIcon = Image("AppIcon")
  static let background = Image("Background")
}

No scripts. No build phases. No file watching.

Example: API Clients

@RESTClient
protocol UserAPI {
  @GET("/users/{id}")
  func user(id: UserID) async throws -> User
}

The macro generates:

URL construction
Encoding/decoding
Error handling
Test stubs

All visible to the compiler, all type-safe.

Developer takeaway: If code can be generated, it should be generated inside the compiler.

5. Cleaner Codebases with Stronger Guarantees

Macro-driven architecture produces a specific kind of cleanliness:

Fewer files
Smaller types
Less repetition
More intent

But the real benefit is confidence.

When architecture is enforced by macros:

Refactors are safer
Reviews focus on behavior, not structure
New developers learn faster
Large-scale changes become feasible

Before

class FeatureViewModel {
  let service: ServiceImpl
  let analytics: AnalyticsImpl
  let logger: Logger

  // manual wiring, unclear contracts
}

After

@FeatureViewModel
final class FeatureViewModel {
  let service: ServiceProtocol
  let analytics: AnalyticsProtocol
}

The compiler now guarantees:

Correct dependencies
Correct lifetimes
Correct layering
Correct instrumentation

This is architecture that does not rot.

Final Opinion

Swift Macros are not an advanced feature for niche metaprogramming. They are a foundational architectural tool. Ignoring them means continuing to solve structural problems at runtime that the compiler is now capable of solving for you.

If you care about:

Long-lived iOS codebases
Architectural consistency
Compile-time correctness
Removing unnecessary abstractions

Then macro-driven architecture should not be optional. It should be the default direction for modern Swift projects.

The future of iOS architecture is not more frameworks. It is fewer runtime decisions and more compile-time guarantees.

Using Kotlin Compiler Plugins in Android Projects

2026-02-26T00:00:00+00:00

Kotlin compiler plugins are one of the most underused yet powerful tools available to Android developers. Most teams rely on conventions, code reviews, and runtime checks to keep large projects healthy. That works, until it doesn’t. Compiler plugins allow you to move entire classes of problems to compile time, where they are cheaper, faster, and impossible to ignore.

This article focuses on what Android developers can practically do with Kotlin compiler plugins to improve long-term maintainability and correctness, with concrete examples and guidance.

What Is a Kotlin Compiler Plugin?

A Kotlin compiler plugin hooks into the compilation pipeline and can:

Inspect Kotlin syntax trees (AST or FIR)
Analyze symbols, types, and module boundaries
Emit compilation errors or warnings
Generate code

Popular examples include kotlinx.serialization, Room, and Compose. But teams can also write custom plugins tailored to their architecture and domain rules.

Enforcing Architectural Rules at Compile Time

The Problem

Architectural rules are often documented but weakly enforced:

“ViewModels must not reference Android framework classes”
“Domain layer must not depend on data or UI”
“Use cases must be pure Kotlin”

These rules are typically enforced via code review or static analysis tools that run after compilation.

The Compiler Plugin Approach

A compiler plugin can analyze symbol usage and fail the build if an architectural rule is violated.

Example: Prevent Android APIs in the Domain Layer

Assume a module structure:

:domain
:data
:ui

We want to ensure :domain never references android.*.

Using the FIR (Frontend IR) API, a plugin can inspect imports and type references:

class DomainAndroidDependencyChecker : FirAnalysisHandlerExtension() {
  override fun analysisCompleted(
    session: FirSession,
    files: List<FirFile>
  ): Boolean {
    files.forEach { file ->
      file.collectTypes().forEach { type ->
        if (type.classId?.packageFqName?.asString()?.startsWith("android.") == true) {
          session.reportError(
            file.source,
            "Android framework dependency is forbidden in domain module"
          )
        }
      }
    }
    return false
  }
}

Now the rule is:

Documented
Automated
Impossible to bypass

This is superior to lint because it runs during compilation, not as a separate phase.

Preventing Forbidden Dependencies Between Modules

The Problem

Gradle enforces dependencies at the module level, but it doesn’t stop you from creating implicit dependencies via shared interfaces, reflection, or generated code.

For example:

UI module depends on a data implementation class
Feature A references Feature B’s internal API
Circular dependencies sneak in via transitive references

Compiler-Level Enforcement

A compiler plugin can inspect symbol origins and module descriptors to block forbidden dependency graphs.

Example: Feature Isolation

Suppose each feature must only depend on:

:core
itself

You can encode this rule directly:

val allowedDependencies = setOf("core", currentModuleName)

if (referencedSymbol.moduleName !in allowedDependencies) {
  error(
    "Module '$currentModuleName' is not allowed to depend on '${referencedSymbol.moduleName}'"
  )
}

This approach:

Catches violations even if Gradle allows them
Detects transitive and indirect dependencies
Scales well for large multi-module apps

In practice, this replaces brittle documentation with enforceable contracts.

Validating Domain Invariants at Compile Time

The Problem

Domain invariants are often enforced at runtime:

Money must not mix currencies
Distances must use consistent units
Percentages must be between 0 and 100

Runtime validation works, but it is too late. The bug has already shipped.

Strong Types + Compiler Plugins

Value classes help, but compiler plugins allow semantic validation.

Example: Currency-Safe Money Arithmetic

@JvmInline
value class Money(val amount: BigDecimal)

@Currency("EUR")
val price: Money = Money(10.toBigDecimal())

@Currency("USD")
val tax: Money = Money(2.toBigDecimal())

A compiler plugin can read the @Currency annotation and reject invalid operations:

val total = price + tax // ❌ compile-time error

Plugin logic:

if (left.currency != right.currency) {
    error("Cannot add Money with different currencies: ${left.currency} and ${right.currency}")
}

This eliminates entire categories of financial bugs and makes illegal states unrepresentable.

Enforcing Correct API Usage

The Problem

APIs are often misused despite documentation:

Calling suspend functions from non-coroutine contexts
Using blocking I/O on the main thread
Forgetting required annotations or preconditions

Compiler Plugin as a Guardrail

Compiler plugins can enforce usage rules that are too contextual for lint.

Example: Repository Access Rules

@Target(AnnotationTarget.FUNCTION)
annotation class IOOnly

@IOOnly
fun fetchUser(): User

Now the plugin ensures:

@IOOnly functions are only called from Dispatchers.IO
or from other @IOOnly functions

If violated:

Error: fetchUser() must only be called from IO context

This approach is stronger than lint because it understands call graphs and coroutine contexts.

Compile-Time Code Generation with Guarantees

Many Android teams use code generation (KSP, kapt). Compiler plugins go further by:

Validating inputs before codegen
Emitting richer diagnostics
Integrating deeply with type inference

Example: Safer Navigation

Instead of runtime-safe args:

navigate("userDetails?id=$id")

A plugin can:

Verify destination exists
Validate argument types
Generate strongly-typed navigation APIs

navigator.goToUserDetails(userId = UserId(42))

Invalid navigation fails at compile time, not at runtime or QA.

Performance and Developer Experience Considerations

Compiler plugins are powerful but not free.

Best Practices:

Fail fast: Stop compilation as soon as a violation is found
Provide actionable errors: Include symbol names and locations
Avoid global scans: Restrict analysis to relevant modules
Document rules clearly: The compiler is strict; humans need context

A bad plugin slows builds and frustrates developers. A good one feels like an intelligent teammate.

When a Compiler Plugin Is Worth It

Use a compiler plugin when:

The rule is non-negotiable
Violations are costly or subtle
Runtime checks are too late
Lint rules are insufficient

Do not use plugins for style or formatting. That belongs elsewhere.

Final Opinion

For medium to large Android projects, Kotlin compiler plugins are a strategic investment. They shift responsibility from humans to tooling, encode architectural intent directly into the build, and dramatically reduce classes of bugs that otherwise survive code review.

Teams that rely only on conventions eventually pay for it. Teams that teach the compiler their rules stop arguing, and start shipping safer code.

Turn on the React Compiler (Where Supported) to Reduce Re-render Costs

2026-02-24T00:00:00+00:00

React performance problems in large React Native and Expo projects almost always trace back to the same root cause: wasted re-renders. As component trees grow, the cost of unnecessary reconciliation quietly compounds. Developers respond with useMemo, useCallback, React.memo, and hand-rolled optimizations, often inconsistently, sometimes incorrectly, and always at a cognitive cost.

The React Compiler changes this equation. When enabled, it can automatically infer memoization boundaries, drastically reducing re-renders without manual intervention. Despite this, it remains significantly underused in React Native and Expo projects.

In this article I explain why enabling the React Compiler is one of the highest-leverage performance improvements you can make today, how it works, where it is supported, and what you should do as a developer to take advantage of it.

The Real Cost of Re-renders in RN and Expo

In React Native, re-renders are more expensive than in web React:

The bridge (or JSI) amplifies render costs
Layout and measurement are non-trivial
Large lists and deeply nested trees are common
Animations often depend on render stability

A single state change near the root can easily trigger hundreds of component re-executions, even when most outputs don’t change.

The traditional mitigation strategy looks like this:

const Item = React.memo(function Item({value}) {
  return <Text>{value} < /Text>
});

const List = ({items}) => {
  const renderItem = useCallback(
    ({item}) => <Item value={item.value}/>,
    []
  );

  return <FlatList data={items} renderItem={renderItem}/>;
};

This works, but it comes with problems:

Developers must predict what should be memoized
Dependency arrays are easy to get wrong
Refactors frequently break memoization
Code becomes harder to read and maintain

Most teams either over-memoize (wasting memory) or under-memoize (wasting CPU). The React Compiler exists to remove this tradeoff.

What the React Compiler Actually Does

The React Compiler is a build-time optimization that analyzes your components and automatically memoizes values, callbacks, and subtrees when it is safe to do so.

Key properties:

Runs at compile time (not runtime)
Preserves React semantics
Understands component purity
Eliminates unnecessary re-renders
Replaces most manual useMemo / useCallback

In other words: React becomes closer to how developers assume it already works.

Why This Is Still Underused in React Native and Expo

Despite its benefits, many RN and Expo projects have not enabled the React Compiler. The reasons are mostly practical, not technical:

Tooling lag: RN projects often trail web React in adopting new compiler features.
Fear of instability: Mobile teams are more conservative about build pipelines.
Legacy Babel configurations: Many projects still use complex, brittle Babel setups.
Habitual over-memoization: Teams have internalized manual memoization as “best practice.”

The result: teams continue paying re-render costs they no longer need to pay.

This is a mistake. On large trees, the compiler routinely removes 30–70% of wasted renders with zero runtime cost.

Where the React Compiler Is Supported

As of now, the React Compiler is supported in:

React 19+ (experimental but stabilizing)
Metro + Babel pipelines (including React Native)
Expo projects using the new Expo CLI and Metro config
Webpack/Vite setups for web

Expo projects are actually well-positioned to adopt it because Expo already standardizes much of the build chain.

Enabling the React Compiler

1. Update React

You must be on a compatible React version:

{
  "dependencies": {
    "react": "^19.0.0",
    "react-native": ">=0.75"
  }
}

2. Enable the Babel Plugin

Add the compiler plugin to your Babel config:

module.exports = {
  presets: ['babel-preset-expo'],
  plugins: [
    ['react-compiler', {target: 'react-native'}]
  ],
};

For non-Expo RN projects, ensure Metro uses this Babel config consistently.

Removing Manual Memoization (Yes, Really)

Once the compiler is enabled, you should actively remove unnecessary memoization.

Before:

const total = useMemo(() => {
  return items.reduce((sum, i) => sum + i.price, 0);
}, [items]);

const onPress = useCallback(() => {
  submit(total);
}, [total]);

After:

const total = items.reduce((sum, i) => sum + i.price, 0);

const onPress = () => {
  submit(total);
};

The compiler will memoize both total and onPress if (and only if) doing so prevents wasted work.

This leads to:

Cleaner components
Fewer hooks
Fewer bugs from stale dependencies
Better long-term maintainability

Manual memoization should now be the exception, not the rule.

Large Component Trees Benefit the Most

Consider a common pattern in RN apps:

<App>
  <Navigation>
    <Screen>
      <Header/>
      <Content>
        <Feed>
          <Post/>
          <Post/>
          <Post/>
        </Feed>
      </Content>
    </Screen>
  </Navigation>
</App>

A state change in Screen often re-renders the entire subtree—even if only Header actually changed.

With the compiler enabled:

Stable subtrees are automatically skipped
Post components do not re-render unless props change
Developers do not need to wrap everything in React.memo

This is particularly impactful in:

Feeds
Dashboards
Forms with many controlled inputs
Navigation-heavy layouts

When You Still Need Manual Control

The React Compiler is powerful, but not magic. You still need to think about:

Side effects (useEffect semantics remain unchanged)
Referential identity for external libraries
Performance-critical animation code
Mutable refs and imperative APIs

If a callback is passed into a non-React system that depends on identity stability, explicit memoization can still be appropriate.

The difference is intent: you now optimize only when necessary.

What Developers Should Do Today

Enable the React Compiler in new projects by default
Audit existing projects for unnecessary memoization
Delete useMemo / useCallback that exist “just in case”
Measure re-renders before and after
Treat manual memoization as a performance escape hatch

If you are maintaining a large RN or Expo codebase and have not tried the compiler, you are almost certainly leaving performance on the table.

Final Words

Manual memoization was always a tax on developer productivity. The React Compiler finally removes that tax.

In React Native and Expo projects, where render costs are higher and trees are deeper, not enabling it is a self-inflicted performance penalty. Turn it on where supported, simplify your components, and let the compiler do the work it was designed to do.

This is one of the rare cases where the best performance move is also the cleanest architectural choice.

First-Class Structured Logging in Spring Boot

2026-02-19T00:00:00+00:00

Logging in Spring Framework projects has traditionally been treated as an afterthought: strings written to files, parsed later by humans or fragile regexes. That approach does not scale. Modern production systems ship logs to centralized backends like ELK or Graylog, correlate them with traces and metrics, and query them programmatically. For that world, plain text logging is a liability.

Spring Boot has quietly evolved to make structured logging a first-class citizen. With built-in support for JSON log formats such as Logstash, ECS, and GELF, Spring Boot allows developers to emit machine-readable logs without custom appenders or ad-hoc conventions. Used correctly, this dramatically improves observability, debuggability, and operational confidence.

In this article I focus on what you, as a developer, can do today to improve a Spring Framework project by adopting structured logging end-to-end.

Why Structured Logging Matters in Spring Projects

Structured logging means emitting logs as data, not formatted prose. Each log entry is a JSON document with well-defined fields: timestamp, level, message, logger, thread, trace IDs, request metadata, and domain-specific attributes.

In a production Spring application, this matters for three reasons:

Search and analytics become reliable: Instead of free-text search, you query fields (http.status:500 AND service.name:orders). This is faster, safer, and composable.
Correlation with traces and requests works automatically: Trace IDs, span IDs, and request IDs become first-class fields instead of embedded strings. This is essential when using OpenTelemetry, Spring Cloud Sleuth (legacy), or Micrometer Tracing.
Logs become backend-agnostic: Whether you ship to Elasticsearch, OpenSearch, Graylog, Datadog, or Loki, structured JSON is the common denominator.

Spring Boot recognizes this reality and provides standardized JSON outputs out of the box.

First-Class JSON Logging in Spring Boot

Spring Boot 3.x ships with native support for JSON logging via Logback. You do not need custom encoders or third-party libraries to get started.

Enabling JSON Logging

The simplest step is configuration. In application.yaml:

logging:
  structured:
    format:
      console: ecs
      file: ecs

This enables ECS-compatible JSON logs for both console and file outputs. Supported formats include:

ecs: Elastic Common Schema (recommended for ELK and OpenSearch)
logstash: Classic Logstash JSON format
gelf: Graylog Extended Log Format

Switching formats does not require code changes, which is a critical design win.

Example Output (ECS)

{
  "@timestamp": "2026-02-07T10:15:30.123Z",
  "log.level": "INFO",
  "message": "Order created",
  "service.name": "order-service",
  "event.dataset": "application",
  "trace.id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span.id": "00f067aa0ba902b7",
  "log.logger": "com.example.orders.OrderService"
}

This is not decoration. This is structured telemetry.

Improving Correlation with Requests and Traces

Spring Boot integrates logging with tracing infrastructure via MDC (Mapped Diagnostic Context). When tracing is enabled, trace and span IDs are automatically injected into log events.

What You Should Do

Enable tracing (Micrometer Tracing / OpenTelemetry)
Avoid manual trace ID logging
Ensure structured output is enabled

Example dependency setup:

<dependency>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-tracing-bridge-otel</artifactId>
</dependency>

With this in place, every log entry emitted during an HTTP request or async operation automatically carries correlation identifiers.

This eliminates patterns like:

log.info("traceId={} processing order {}", traceId, orderId);

Instead, log the domain fact:

log.info("Processing order {}", orderId);

The trace context is already attached as structured metadata.

Logging Domain Data the Right Way

A common mistake is to serialize domain objects into log messages. Structured logging gives you a better option: key-value logging.

Use Structured Arguments

Spring Boot supports structured arguments via Logback and SLF4J.

import static net.logstash.logback.argument.StructuredArguments.keyValue;

log.info("Order created",
  keyValue("orderId", order.getId()),
  keyValue("customerId", order.getCustomerId()),
  keyValue("totalAmount", order.getTotalAmount())
);

This produces fields, not string concatenation:

{
  "message": "Order created",
  "orderId": "A123",
  "customerId": "C456",
  "totalAmount": 149.99
}

Why This Matters

Fields are indexed independently
Numeric values remain numeric
Queries become deterministic

This is a direct improvement you can apply to existing codebases incrementally.

HTTP and Error Logging That Scales

Logging HTTP Requests

Do not log full request/response bodies by default. Instead, log structured metadata:

HTTP method
Path or route template
Status code
Latency

Spring Boot already emits much of this via access logs or filters. If you need application-level logging:

log.info("HTTP request completed",
  keyValue("method", request.getMethod()),
  keyValue("path", request.getRequestURI()),
  keyValue("status", response.getStatus()),
  keyValue("durationMs", duration)
);

Logging Exceptions

Never log stack traces as formatted strings. Let the logging framework handle exceptions:

try {
  process(order);
} catch (OrderException ex) {
  log.error("Order processing failed",
    keyValue("orderId", order.getId()),
    ex
  );

  throw ex;
}

Structured logging preserves:

Exception class
Stack trace
Root cause
Correlation IDs

Backends like Elasticsearch and Graylog understand these fields natively.

Shipping Logs to ELK, Graylog, and Beyond

The target audience for structured logging is any production system shipping logs centrally.

With Spring Boot JSON logging:

ELK / OpenSearch: ECS format aligns directly with index templates and dashboards.
Graylog: GELF output avoids brittle text extractors.
Cloud platforms: JSON logs are parsed automatically by most log agents.

The key insight: Spring Boot emits the data; shipping is an infrastructure concern. Filebeat, Fluent Bit, or platform agents consume JSON without transformation.

This separation of concerns keeps application code clean and portable.

Opinionated Guidance for Spring Developers

If you maintain Spring Framework projects in production, structured logging is no longer optional.

Do this:

Enable JSON logging globally
Use ECS unless you have a strong reason not to
Log domain events, not prose
Prefer key-value arguments over string interpolation
Let tracing handle correlation

Avoid this:

Custom log formats per service
Manual trace ID handling
Logging entire objects or payloads
Regex-based parsing downstream

The result is a system where logs are queryable, analyzable, and trustworthy under load.

Conclusion

Spring Boot’s built-in structured logging support removes the historical friction around JSON logs. What used to require custom encoders and conventions is now a configuration toggle and a few disciplined coding practices.

For Spring Framework projects running in production and shipping logs to ELK, Graylog, or similar backends, structured logging is one of the highest-ROI improvements you can make. It directly improves incident response, debugging speed, and long-term operability, without adding architectural complexity.

Good logging is not about verbosity. It is about emitting facts in a form machines can understand. Spring Boot finally makes that the default.

Beyond Thread Safety - Actor-Centered Domain Modeling for Robust iOS Apps

2026-02-17T00:00:00+00:00

Swift actors are usually introduced to iOS developers as a concurrency primitive: a safer replacement for locks that protects mutable state. That framing is correct, but incomplete. In practice, treating actors merely as “thread-safe boxes” leaves most of their power untapped.

I argue for a stronger position: actors should be first-class domain units. When you move business invariants, state transitions, and decision-making inside actors, you get systems that are easier to reason about, harder to misuse, and more resilient to change. This approach, Actor-Based Domain Modeling, can dramatically improve correctness and reduce cognitive load in iOS projects.

Actors Are Usually Underused

In many codebases, actors look like this:

actor UserCache {
private var users: [UserID: User] = [:]
  func getUser(id: UserID) -> User? {
    users[id]
  }

  func setUser(_ user: User) {
    users[user.id] = user
  }
}

This is better than a DispatchQueue, but it is still lock-oriented thinking. The actor is just a synchronized dictionary. The domain rules live elsewhere, often scattered across view models, services, and coordinators.

That fragmentation causes three recurring problems:

Invariants are not enforced at the boundary
State transitions are implicit and fragile
Developers must remember “how to use it correctly”

Actors can, and should, do more.

Model Business Invariants Inside Actors

A business invariant is a rule that must always hold true. Examples:

An order cannot be paid twice
A download cannot be completed before it starts
A user cannot be logged in and logged out at the same time

If these rules are enforced outside the actor, correctness depends on discipline. That does not scale.

Instead, embed invariants directly into the actor’s API.

Example: Purchase Flow

Naïve approach

struct Purchase {
  var isPaid: Bool
}

func pay(purchase: inout Purchase) {
  guard !purchase.isPaid else { return }
  purchase.isPaid = true
}

This works until concurrency, retries, or UI duplication enter the picture.

Actor-based domain modeling

actor PurchaseSession {
  enum State {
    case pending
    case paid(receipt: Receipt)
  }

  private var state: State = .pending

  func pay() throws -> Receipt {
      switch state {
      case .pending:
        let receipt = Receipt()
        state = .paid(receipt: receipt)
        return receipt

      case .paid:
        throw PurchaseError.alreadyPaid
      }
  }

  func snapshot() -> State {
      state
  }
}

Here, it is impossible to pay twice. The invariant is not documented, it is enforced by construction. No caller can violate it, even accidentally.

This is the single biggest improvement actors bring to iOS domain design.

Treat Actors as Stateful Domain Units, Not Just Locks

When actors are domain units, their public API represents allowed business operations, not raw data access.

Bad signals:

getX(), setX()
Public mutable properties
Actors mirroring database tables or DTOs

Good signals:

Methods named after actions: start(), confirm(), cancel()
Internal state machines
Errors that represent invalid domain transitions

Example: Authentication Session

actor AuthSession {
  enum State {
    case loggedOut
    case loggingIn
    case loggedIn(User)
  }

  private var state: State = .loggedOut

  func login(credentials: Credentials) async throws {
    guard case .loggedOut = state else {
      throw AuthError.invalidState
    }

    state = .loggingIn
    let user = try await authenticate(credentials)
    state = .loggedIn(user)
  }

  func logout() throws {
    guard case .loggedIn = state else {
      throw AuthError.invalidState
    }
    state = .loggedOut
  }

  func snapshot() -> State {
    state
  }
}

Notice what is missing:

No isLoggedIn Boolean
No writable state
No “check-then-act” race conditions

The actor defines what is allowed, and nothing else.

Combine Actors with Value Types for Snapshot-Based UI Rendering

Actors are reference types with isolated mutable state. SwiftUI, on the other hand, thrives on immutable value types. The bridge between them is snapshots.

The pattern is simple:

Actor owns mutable state
Actor exposes immutable snapshots (structs or enums)
UI renders only from snapshots

Example: View Model Integration

struct AuthViewState: Equatable {
  let isLoggedIn: Bool
  let username: String?
}

extension AuthSession {
  func viewState() -> AuthViewState {
    switch snapshot() {
    case .loggedOut:
      return .init(isLoggedIn: false, username: nil)

    case .loggingIn:
      return .init(isLoggedIn: false, username: nil)

    case .loggedIn(let user):
      return .init(isLoggedIn: true, username: user.name)
    }
  }
}

In the UI layer:

@MainActor
final class AuthViewModel: ObservableObject {
  @Published private(set) var state: AuthViewState
  private let session: AuthSession

  func refresh() async {
    state = await session.viewState()
  }
}

This gives you:

Deterministic rendering
Easy diffing and testing
No shared mutable state leaking into SwiftUI

Actors mutate. Views observe values.

Why This Improves Correctness (Dramatically)

Actor-based domain modeling delivers correctness guarantees that are difficult to achieve otherwise:

Illegal states are unrepresentable: By encoding valid transitions in actor methods, entire classes of bugs disappear.
Concurrency is implicit, not managed: You stop reasoning about queues, locks, and reentrancy. The actor model enforces isolation by default.
Call sites are simpler:

Instead of:

if !purchase.isPaid {
  purchase.pay()
}

You write:

try await purchaseSession.pay()

No preconditions. No defensive coding. No duplication.

A Simpler Mental Model for Teams

From experience, this is the most underrated benefit. When actors are domain units, developers can answer questions like:

“Where does this state live?”
“Who is allowed to change it?”
“What happens if this is called twice?”

by opening one file.

That is not true when business rules are split across:

View models
Services
Reducers
Utility functions

Actors concentrate complexity in a controlled, inspectable place.

Practical Guidelines for iOS Projects

To apply this effectively:

Design the actor API first: Model actions, not properties
Keep state private: If something must be mutable, it belongs inside the actor
Expose snapshots, not references: UI and tests consume value types
Prefer enums over booleans: State machines beat flags
Let errors represent invalid transitions: Avoid silent no-ops

If an actor starts looking like a thread-safe struct, redesign it.

Final Take

Using actors only for thread safety is a missed opportunity. In iOS projects, the real payoff comes when actors are treated as authoritative domain objects that own state, enforce invariants, and define legal behavior.

The result is code that is:

Safer by construction
Easier to reason about
Better aligned with SwiftUI and modern concurrency

Actor-based domain modeling is not an abstraction tax, it is a clarity dividend.

Unidirectional Data Flow (UDF) in Android Development

2026-02-12T00:00:00+00:00

As Android projects grow, complexity rarely comes from algorithms; it comes from state. Multiple screens read and mutate the same data, UI reacts inconsistently, and bugs appear only under specific timing conditions. Unidirectional Data Flow (UDF) is one of the most effective architectural principles to control this complexity.

UDF is not a library or a framework. It is a discipline: data moves in one direction, state has a single source of truth, and side effects are controlled. When applied consistently, it dramatically improves predictability, testability, and developer velocity.

This article covers the core concepts of UDF, why it works so well on Android, how to implement it in practice, and common pitfalls to avoid.

What Is Unidirectional Data Flow?

At a high level, UDF means:

State flows down
Events flow up
State is immutable
There is a single source of truth

A simplified loop looks like this:

UI → Event → ViewModel → New State → UI

The UI never mutates state directly. Instead, it emits events (also called actions or intents). The ViewModel processes those events, updates the state, and exposes a new immutable state object. The UI observes that state and renders it.

No shortcuts. No backchannels.

Core Concepts

1. Single Source of Truth

All UI-relevant data lives in one state object, typically owned by a ViewModel.

data class LoginUiState(
  val isLoading: Boolean = false,
  val email: String = "",
  val password: String = "",
  val errorMessage: String? = null
)

This state represents everything the screen needs to render itself. If something affects the UI, it belongs here.

Strong opinion: If your UI reads from multiple mutable sources (LiveData + Flow + callbacks), you are not doing UDF.

2. Events (User Intent)

The UI does not call methods like login() or setLoading(true). It sends events that describe what happened, not what should change.

sealed interface LoginEvent {
  data class EmailChanged(val value: String) : LoginEvent
  data class PasswordChanged(val value: String) : LoginEvent
  object SubmitClicked : LoginEvent
}

This keeps the UI dumb and the business logic centralized.

3. Reducer Logic

The ViewModel receives events and reduces them into new state.

class LoginViewModel : ViewModel() {
    private val _state = MutableStateFlow(LoginUiState())
    val state: StateFlow<LoginUiState> = _state

    fun onEvent(event: LoginEvent) {
        when (event) {
            is LoginEvent.EmailChanged ->
                _state.update { it.copy(email = event.value) }

            is LoginEvent.PasswordChanged ->
                _state.update { it.copy(password = event.value) }

            LoginEvent.SubmitClicked ->
                submitLogin()
        }
    }

    private fun submitLogin() {
        _state.update { it.copy(isLoading = true, errorMessage = null) }
        // Trigger side-effect (network call)
    }
}

This approach ensures:

State transitions are explicit
All mutations happen in one place
Debugging becomes trivial

4. UI as a Pure Function of State

In UDF, the UI does not decide anything. It simply renders state.

@Composable
fun LoginScreen(
  state: LoginUiState,
  onEvent: (LoginEvent) -> Unit
) {
  if (state.isLoading) {
  CircularProgressIndicator()
  }

  state.errorMessage?.let {
    Text(text = it, color = Color.Red)
  }

  TextField(
    value = state.email,
    onValueChange = { onEvent(LoginEvent.EmailChanged(it)) }
  )

  Button(onClick = { onEvent(LoginEvent.SubmitClicked) }) {
    Text("Login")
  }
}

Given the same state, this UI will always render the same output. That is a huge win.

Advantages of UDF in Android Projects

1. Predictability

Because state only changes in response to events, you can replay bugs mentally, or even log and replay them in tests.

This eliminates:

“How did we get here?”
Hidden state mutations
Timing-related UI bugs

2. Testability

Reducer-style logic is extremely easy to test.

@Test
fun `email change updates state`() {
    val vm = LoginViewModel()
    vm.onEvent(LoginEvent.EmailChanged("test@test.com"))

    assertEquals(
        "test@test.com",
        vm.state.value.email
    )
}

No UI. No instrumentation. No mocking frameworks.

3. Scalability

As features grow, UDF prevents architectural decay.

New developers can follow the event → state path
Features remain isolated
Refactoring becomes safe

Opinion: UDF is one of the few patterns that scales down and up. It works for one screen and for a 100-screen app.

4. Compose-Friendly by Design

Jetpack Compose is built around state-driven UI. UDF aligns perfectly with it. If you fight UDF in Compose, you will end up fighting Compose itself.

Common Pitfalls (and How to Avoid Them)

1. Treating State as a Dumping Ground

Putting everything into a single state object without structure leads to bloated, unreadable code.

Fix: Split state by screen and by responsibility. Use nested data classes when needed.

2. One-Off Events in State

Navigation events, toasts, and snackbars should not live permanently in state.

Bad:

val showToast: Boolean

Better:

sealed interface UiEffect {
  data class ShowToast(val message: String) : UiEffect
}

Expose effects via a separate SharedFlow.

3. Overengineering with Redux-Style Abstractions

You do not need a global store, middleware chains, or fancy reducers for most Android apps.

Rule of thumb: If you can explain your UDF implementation in under 2 minutes, it is probably correct.

4. Mutating State Objects

Never mutate state in place.

Bad:

state.user.name = "New Name"

Good:

state.copy(user = state.user.copy(name = "New Name"))

Immutability is non-negotiable.

What Developers Can Do Today to Improve Their Project

Identify one screen with messy state and refactor it to UDF
Replace multiple LiveData objects with a single state model
Introduce explicit UI events
Make UI components stateless where possible
Add reducer-level tests

You do not need a rewrite. UDF can be introduced incrementally.

Final Thoughts

Unidirectional Data Flow is not about following trends or copying patterns from other ecosystems. It is about making state boring; and boring state is reliable state.

In Android development, where lifecycles, configuration changes, and async work are constant sources of bugs, UDF provides a calm, structured approach that pays dividends over time.

If your app feels fragile, unpredictable, or hard to reason about, UDF is not an optional refinement. It is a foundational fix.

React Native Lists - Treat Them as a Performance Subsystem, Not a Component

2026-02-10T00:00:00+00:00

In many React Native codebases, list performance is treated as a local concern; a screen feels slow, so someone tweaks FlatList props until it’s “good enough”. initialNumToRender, windowSize, maybe getItemLayout if someone is feeling ambitious. Then the team moves on.

This approach works, until it doesn’t.

Once your app grows, lists stop being just UI components. They become performance-critical infrastructure. Feeds, chats, search results, product catalogs, lists dominate runtime, memory usage, and perceived speed. At that point, tuning FlatList props is table stakes. The real gains come from treating lists as a subsystem with explicit rules, shared abstractions, and enforcement.

I decided to write this article to argue for that shift and shows what developers can do today to improve an existing React Native project.

The Ceiling of “Just Tune FlatList”

Most experienced teams know the basics:

<FlatList
  data={data}
  keyExtractor={item => item.id}
  initialNumToRender={10}
  maxToRenderPerBatch={5}
  windowSize={5}
  removeClippedSubviews
/>

Sometimes they add:

getItemLayout={(_, index) => ({
  length: ITEM_HEIGHT,
  offset: ITEM_HEIGHT * index,
  index,
})}

This is good practice, but it assumes something rarely true in real apps:

Items have stable, predictable layouts
Data arrives all at once
Every cell can render immediately
All items follow the same composition rules

Once those assumptions break, FlatList tuning alone hits a ceiling. Scroll hitching returns. Memory spikes. Skeletons flash unpredictably. Developers start “fixing” individual screens instead of addressing the root cause.

That’s the signal you need a system.

Lists as a Performance Subsystem

A subsystem has three properties:

Explicit constraints
Shared primitives
Enforcement mechanisms

For lists, this means defining how items are measured, prefetched, rendered, and composed—and making those decisions reusable and reviewable.

Let’s break that down.

1. Item Measurement Is a First-Class Concern

Most teams rely on runtime measurement (onLayout) without realizing the cost. Measuring during scroll is expensive and unpredictable, especially with heterogeneous items.

An advanced approach is to design item measurement up front.

Strategy A: Fixed-height contracts

If an item can be fixed height, enforce it.

export const FEED_ITEM_HEIGHT = 96;

export function FeedItem({item}: Props) {
  return (
    <View style=>
      {/* content */}
    </View>
  );
}

This unlocks cheap, deterministic getItemLayout and eliminates runtime measurement entirely.

Strategy B: Height classes

When fixed height isn’t realistic, define height classes instead of infinite variability.

type ItemHeightClass = 'compact' | 'regular' | 'expanded';

const HEIGHTS: Record<ItemHeightClass, number> = {
  compact: 64,
  regular: 96,
  expanded: 140,
};

Each item declares its class in data:

{
  id: '123',
  heightClass: 'regular',
}

Now getItemLayout is still computable, and layout variance stays bounded.

Actionable rule: No list item ships without an explicit height strategy.

2. Prefetching Is Part of Rendering, Not Networking

Many teams prefetch data globally and hope lists benefit indirectly. That’s backwards. Lists know exactly what the user will see next.

A list subsystem should own prefetching semantics.

Viewport-aware prefetch

const onViewableItemsChanged = useRef(({viewableItems}) => {
  const lastVisible = viewableItems[viewableItems.length - 1];
  if (!lastVisible) return;

  const index = lastVisible.index ?? 0;

  prefetchItems(index + 1, index + 10);
}).current;

<FlatList
  onViewableItemsChanged={onViewableItemsChanged}
  viewabilityConfig=
/>

This shifts prefetching from “when data loads” to “when the user scrolls”.

Asset prefetching

Images, videos, and fonts should follow the same contract:

function prefetchItemAssets(item: FeedItem) {
  Image.prefetch(item.thumbnailUrl);
}

Tie this into the same viewport logic.

Actionable rule: If an item can’t render instantly, it must be prefetched before it enters the viewport.

3. Placeholder Strategy Must Be Deterministic

Skeletons are often implemented ad hoc: a shimmer here, a spinner there. The result is visual noise and layout shifts.

Instead, placeholders should be structurally identical to real cells.

Bad placeholder

Different height
Different layout
Conditional branches everywhere

Good placeholder

function FeedItemPlaceholder() {
  return (
    <View style=>
      <Skeleton width={48} height={48} />
      <Skeleton width="60%" />
    </View>
  );
}

function FeedItemCell({ item }: Props) {
  if (!item.isLoaded) {
    return <FeedItemPlaceholder />;
  }

  return <FeedItem item={item} />;
}

The list doesn’t care whether data is loaded. Layout stays stable. Scroll performance improves because React Native doesn’t need to reflow items mid-scroll.

Actionable rule: Placeholders must match final layout dimensions exactly.

4. Cell Composition Rules Prevent Accidental Slowness

One of the most common performance regressions comes from “harmless” changes inside list items:

Adding a new context provider
Using anonymous inline functions
Mounting a heavy hook per cell
Conditional portals or modals

A list subsystem defines what is allowed inside a cell.

Cell boundary rule

Allowed

Pure components
Memoized callbacks
Presentational hooks

Forbidden

Navigation containers
Global context providers
Data-fetching hooks

Enforce this with structure:

function FeedItemCell(props: Props) {
  return (
    <CellBoundary>
      <FeedItemView {...props} />
    </CellBoundary>
  );
}

const FeedItemView = React.memo(function FeedItemView(props: Props) {
  // rendering only
});

Now performance assumptions are explicit and reviewable.

Actionable rule: Treat list cells like render() in a game engine: no side effects, no surprises.

5. Make the System Visible in Code Review

None of this matters if it lives in someone’s head.

Strong teams encode list rules into the project itself:

Shared ListConfig objects
Centralized useListPerformance() hooks
ESLint rules for forbidden imports in /cells
PR checklist items like:
- “Does this change affect item height?”
- “Are placeholders layout-identical?”
- “Is this hook allowed in a cell?”

Example:

export const FeedListConfig = {
  itemHeight: FEED_ITEM_HEIGHT,
  prefetchAhead: 10,
  placeholder: FeedItemPlaceholder,
};

Now list behavior is discoverable and consistent across screens.

Conclusion: Performance Is a Design Problem

FlatList tuning is necessary, but it’s not sufficient. Real-world React Native apps demand a more disciplined approach.

When you treat lists as a performance subsystem, you:

Reduce regressions
Make performance predictable
Enable teams to move faster without fear

The key insight is simple but uncomfortable: most list performance issues are self-inflicted at the architecture level, not the prop level.

Design the system. Enforce the rules. Then let FlatList do what it does best.

When to choose Spring WebFlux vs. Spring MVC (+ Virtual Threads)

2025-09-04T00:00:00+00:00

Don’t default to WebFlux in your next Spring project with the old argument that it scales better than Spring MVC. In 2025, using Spring MVC + Virtual Threads is the preferred solution for most CRUD-style services that talk to blocking dependencies (JDBC/JPA, legacy SDKs). Reach for WebFlux when you truly need massive concurrent I/O, streaming, or fully reactive backpressure end-to-end.

Below is the opinionated, practical guide I wish every team read before picking a stack:

The Main Differences in Both Models

Spring MVC (Servlet) + Virtual Threads (Java 21): Thread-per-request model, now cheap thanks to virtual threads. Imperative code, simple debugging, first-class transactions with JPA/Hibernate. Great for “do a thing, hit a DB, return JSON.”
Spring WebFlux (Reactive, typically on Netty): Event-loop model with non-blocking I/O. Compositional pipelines (Mono/Flux), backpressure, and streaming (SSE/WebSockets). Shines under extreme concurrency or when you need true streaming across hops.

Use MVC + Virtual Threads When…

Your persistence is relational via JPA/JDBC: JDBC is blocking. JPA/Hibernate is blocking. That’s perfectly fine with virtual threads. You’ll get excellent scalability with fewer moving parts.
Your dependencies block: Cloud SDKs, payment gateways, legacy SOAP/REST clients—many still block internally. Virtual threads let you write normal code without fighting the runtime.
You value debuggability and operational simplicity: Stack traces look like you expect, thread dumps are readable, profilers and tracing are straightforward. Teams ship faster.
You don’t actually need streaming: If your endpoints are standard request/response JSON with modest payloads, backpressure fine-tuning is overkill.
You need mature, transactional semantics: JPA features (entity lifecycle, lazy loading, 2nd-level cache) and declarative transactions are battle-tested in MVC land.

Minimal setup:

# Spring Boot 3.x+
spring.threads.virtual.enabled=true

Or programmatically:

@Bean
TaskExecutor applicationTaskExecutor() {
  return Executors.newVirtualThreadPerTaskExecutor();
}

Typical controller (MVC):

@RestController
@RequestMapping("/orders")
class OrderController {
  private final OrderService service;

  @GetMapping("/{id}")
  public OrderDto get(@PathVariable Long id) {
    return service.find(id); // hits JPA/Hibernate
  }
}

Why I’m opinionated here: with Java 21, the old “blocking doesn’t scale” argument is mostly obsolete for typical workloads. Virtual threads make thread-per-request viable again. You can hit a relational DB at scale without adopting a reactive mental model everywhere.

Use WebFlux When…

You need extreme concurrency or many long-lived connections: Think tens or hundreds of thousands of concurrent clients, server-sent events, WebSockets, long polling, or acting as a proxy/gateway.
You can go reactive end-to-end: Reactive database drivers (R2DBC) or NoSQL (Mongo/Redis reactive), reactive messaging (Kafka/Rabbit), and reactive HTTP clients. Backpressure only works if every hop participates.
Streaming is a first-class requirement: Token streaming for AI, telemetry firehoses, multi-gig downloads where you must control flow and avoid buffering everything in memory.
Your team is fluent in Reactor: Reactor operators, scheduler selection, context propagation, and error handling are not beginners’ topics. If you’re not ready for that, don’t do it half-way.

Typical controller (WebFlux):

@RestController
@RequestMapping("/events")
class EventController {
  private final EventService service;

  @GetMapping(
    value = "/stream",
    produces = MediaType.TEXT_EVENT_STREAM_VALUE)
  public Flux<ServerSentEvent<Event>> stream() {
    // non-blocking stream
    return service.events()
      .map(e -> ServerSentEvent.builder(e).build());
  }
}

Reactive DB example:

@Repository
interface UserRepository extends ReactiveCrudRepository<User, Long> {}

@Service
class UserService {
  private final UserRepository repo;

  Flux<User> findAllActive() {
    return repo.findAll().filter(User::isActive);
  }
}

Why WebFlux still wins sometimes: If you need to hold 50k SSE connections or coordinate complex streaming pipelines with backpressure, an event-loop architecture is designed for that. MVC can fake it, but WebFlux is built for it.

Anti-Patterns (a.k.a. Avoid These Traps)

WebFlux + JPA: JDBC blocks. You’ll end up pushing calls to boundedElastic — which burns threads and erodes the benefits of reactive. If you must hit a blocking thing from WebFlux, isolate it behind well-bounded executor pools and accept the trade-off.
Partial reactivity: Reactive web → blocking DB → reactive again breaks backpressure and complicates everything. Either stay imperative (MVC) or go fully reactive where it matters.
Elastic everywhere: Sprinkling subscribeOn(Schedulers.boundedElastic()) to “fix” blocking calls is a red flag. It hides bottlenecks and creates scheduler contention.

Decision Tree You Can Apply in Minutes

Is your main persistence JPA/JDBC?
- Yes: Choose MVC + Virtual Threads.
- No: continue.
Do you have real streaming/long-lived connection needs (SSE/WebSocket) to thousands of clients?
- Yes: Lean WebFlux.
- No: continue.
Are ALL critical I/O dependencies available as reactive clients/drivers?
- Yes: WebFlux fits.
- No: prefer MVC + VT.
Does the team have Reactor experience and will maintain reactive code responsibly?
- Yes: green light.
- No: don’t learn it on your critical path — MVC + VT.

Performance Reality Check (2025)

MVC + VT: For classic REST that hits a relational DB, virtual threads usually match the throughput of “hand-rolled” reactive stacks with far less complexity. Latency is predictable; code is readable.
WebFlux: Outperforms when connection counts skyrocket or when streaming dominates the workload. Especially good as an edge service (API gateway, BFF, stream fan-out) even if your core services remain MVC.

My rule: if you can’t point to a concrete, measurable scenario where WebFlux’s model is required, you probably don’t need it.

Hybrid Architecture That Works

At the edge (API gateway, streaming endpoints, protocol translation): WebFlux, Netty, SSE/WebSocket, reactive WebClient.
At the core (business services hitting RDBMS): MVC + VT, JPA/Hibernate, transactions.
Between services: keep payloads small and treat streaming as an explicit feature, not a default.

This isolates complexity where it pays off and keeps the bulk of your codebase boring—in a good way.

Production Tips

MVC + VT

# Cap carrier threads if needed (app servers vary; monitor!)
spring.threads.virtual.enabled=true
server.tomcat.threads.max=200  # carrier pool; tune via load testing

Profile with async profilers as usual; thread dumps remain helpful.
Use database connection pools sized to actual DB capacity; virtual threads don’t change RDBMS limits.

WebFlux

reactor:
  netty:
    pool:
      maxConnections: 100000
      acquireTimeout: 45000
spring:
  codec:
    max-in-memory-size: 4MB  # prevent accidental buffering

Define explicit schedulers for bounded blocking work (if you can’t avoid it).
Add timeouts and retries at edges — reactive pipelines can otherwise mask slow consumers.
Ensure observability (Micrometer, tracing) is wired for Reactor context.

Common “What Ifs”

“We might need streaming later”: Don’t pay the complexity tax today. Start with MVC; add a separate WebFlux edge service when streaming becomes real.
“Our SDK is blocking but everything else is reactive”: Either wrap the SDK behind a small MVC microservice or isolate it in WebFlux with a bounded executor and clear SLAs. Don’t sprinkle boundedElastic through your codebase.
“We’re a small team; performance matters”: MVC + VT is the highest ROI path for most teams. Measure first; switch when evidence demands it.

Final Opinion

Default to Spring MVC + Virtual Threads for new REST APIs that touch relational databases or any blocking libraries. It’s simpler, safer, and fast enough for the vast majority of real-world systems. Adopt Spring WebFlux deliberately when you have clear streaming requirements, very high concurrency, and reactive drivers across the stack — plus a team ready to own the reactive model. Choose WebFlux for a reason, not as a reflex.

Swift’s new Observation system - why you should switch (and how)

2025-09-01T00:00:00+00:00

TL;DR: Drop ObservableObject, @StateObject, and @Published for new code.

Apple’s Observation (@Observable, @Bindable, @ObservationIgnored) gives you property-level updates, less boilerplate, better performance, and cleaner bindings — and it meshes perfectly with SwiftData. Below is how to use it to make your app simpler and faster.

Why Observation beats the old model

Finer-grained invalidation (fewer wasted re-renders): ObservableObject is coarse: any change fires objectWillChange and can over-invalidate views. Observation tracks stored properties, so only views that read the changed fields re-render. That means smoother lists, forms, and detail screens.
Way less boilerplate: No ObservableObject, no @Published, no Combine imports, no manual objectWillChange. You write plain stored vars — the compiler synthesizes the tracking.
Works with structs or classes: The old model forced class-based view models. Observation supports structs too, which is great for small models and pure value semantics.
Cleaner bindings: @Bindable gives you $model.name for any @Observable (or SwiftData @Model) instance you pass into a view. It feels like @State, but for your own types.
SwiftData synergy: SwiftData models (@Model) are already observation-ready. You can bind directly to them with @Bindable and query with @Query — zero glue code.
Modern concurrency: You aren’t juggling Combine threads. Mark your view models @MainActor where appropriate and lean on Swift 6 strict concurrency.

When to keep the old stuff: If you must support iOS 14–16 or you’re deeply invested in Combine pipelines today. Otherwise, switch.

Side-by-side: old vs. new

Before (Combine/ObservableObject):

import Combine
import SwiftUI

final class ProfileVM: ObservableObject {
  @Published var name = ""
  @Published var age = 0

  private let api: API
  init(api: API) { self.api = api }

  func load() {
    // fetch, then assign to @Published props
  }
}

struct ProfileView: View {
  @StateObject private var vm: ProfileVM

  init(api: API) {
    _vm = StateObject(wrappedValue: ProfileVM(api: api))
  }

  var body: some View {
    Form {
      TextField("Name", text: $vm.name)
      Stepper("Age \(vm.age)", value: $vm.age)
    }
  }
}

After (Observation):

import Observation
import SwiftUI

@Observable
@MainActor
final class ProfileVM {
  var name = ""
  var age = 0

  @ObservationIgnored private let api: API
  init(api: API) { self.api = api }

  func load() async {
    // await api.fetch()
    // name = ...
    // age  = ...
  }
}

struct ProfileView: View {
  // With Observation you don't need @StateObject.
  // Keep a stable instance using @State to pin identity.
  @State private var vm: ProfileVM

  init(api: API) {
    _vm = State(initialValue: ProfileVM(api: api))
  }

  var body: some View {
    Form {
      // clean bindings via Observation
      TextField("Name", text: $vm.name)
      Stepper("Age \(vm.age)", value: $vm.age)
      Button("Reload") { Task { await vm.load() } }
    }
  }
}

What changed:

No ObservableObject/@Published.
No Combine.
@ObservationIgnored excludes dependencies from the reactive graph.
@State holds the instance; Observation handles the reactivity.

Binding to models with @Bindable (no extra view model)

If your type is the state, pass it straight into the view and mark it @Bindable. You get field bindings for free:

import Observation
import SwiftUI

@Observable
struct Todo: Identifiable {
  var id = UUID()
  var title: String
  var done = false
}

struct TodoRow: View {
  @Bindable var todo: Todo // enables $todo.title, $todo.done
  var body: some View {
    Toggle(todo.title, isOn: $todo.done)
  }
}

struct TodoList: View {
  @State private var items: [Todo] = [
    .init(title: "Ship Observation"),
    .init(title: "Remove @Published")
  ]

  var body: some View {
    List($items) { $item in // bind each element
      TodoRow(todo: item)
    }
    .toolbar {
        Button("Add") { items.append(.init(title: "New")) }
    }
  }
}

Why it’s better: The row invalidates only when that row’s fields change. No global objectWillChange cascade.

SwiftData + Observation = chef’s kiss

SwiftData models are automatically observable. Use @Bindable for editing, @Query for live-updating lists.

import SwiftData
import SwiftUI

@Model
final class Note {
  var title: String
  var body: String
  var createdAt: Date = .now

  init(title: String, body: String) {
    self.title = title; self.body = body
  }
}

struct NotesList: View {
  @Query(sort: \.createdAt, order: .reverse) private var notes: [Note]

  var body: some View {
    List(notes) { note in
    NavigationLink(note.title) { NoteDetail(note: note) }
    }
  }
}

struct NoteDetail: View {
  @Environment(\.modelContext) private var context
  @Bindable var note: Note

  var body: some View {
    Form {
      TextField("Title", text: $note.title)
      TextEditor(text: $note.body)
      Button("Delete") { context.delete(note) }
    }
  }
}

Tip: For UI-only flags on a SwiftData model (expanded rows, selection), mark them @Transient so they’re observable but not persisted.

Migration playbook (incremental and safe)

Start new screens with Observation: Leave old screens on ObservableObject; both models co-exist fine in one app.
Convert VMs opportunistically:
- Replace ObservableObject with @Observable.
- Remove @Published — use stored vars.
- Replace @StateObject with @State (or pass instances through initializers/Environment).
Stabilize lifetimes: Observation won’t keep your instance alive for you. Pin identity with:
```
 @State private var vm = MyVM(dep: dep)
```
or initialize in the view’s init. Do not re-create the VM in body.
Exclude non-state: Wrap services, caches, or tasks with @ObservationIgnored so they don’t affect invalidation or trigger rebuilds.
Batch writes: If a user action flips multiple fields, mutate them within one action and (for SwiftData) save once to reduce churn.
Threading and Swift 6: Mark UI VMs @MainActor. For heavy work, hop to background actors and return results to the main actor for assignment.

Patterns that improve real-world performance

Row-local observation in big lists: Bind list elements (List($items)) and use @Bindable in rows so toggling one item doesn’t repaint the world.
Derived collections computed on demand: Keep source-of-truth arrays as stored vars; compute filtered/sorted views as var computed properties. If expensive, memoize or compute in a lightweight @Observable coordinator.
Avoid “computed observables” that do heavy work: Observation tracks reads. If a computed property is costly, make the inputs observable and cache the result.
Prefer @Observable + SwiftData over “fat view models”: Persisted data in SwiftData, coordination in a slim @Observable VM. Cleaner separation and testability.

Common pitfalls (and quick fixes)

“My view model keeps re-initializing.” - You created it in body. Move creation to init or store it in @State.
“Why did changing a service trigger a re-render?” - You forgot @ObservationIgnored on non-UI dependencies.
“Bindings don’t appear for my type.” - Make the type @Observable (or @Model) and use @Bindable in the receiving view.
“We support iOS 16” - Keep ObservableObject on those screens, or ship alternate implementations via #available. Observation requires iOS 17+.

A small, opinionated template

Use this as your default stack for new features:

// Domain/persistence
@Model final class Entity { /* fields */ }

// Coordination / derived state
@Observable @MainActor
final class FeatureVM {
  @ObservationIgnored private let context: ModelContext
  var query = ""

  init(context: ModelContext) { self.context = context }

  var results: [Entity] {
    // Build a FetchDescriptor based on `query`
    // return (try? context.fetch(desc)) ?? []
    []
  }

  func add(/*…*/) { /* insert + save once */ }
}

// Views
struct FeatureScreen: View {
  @Environment(\.modelContext) private var context
  @State private var vm: FeatureVM

  init(context: ModelContext? = nil) {
    // If not provided, we'll get it from the Environment in body on first run.
    _vm = State(initialValue: FeatureVM(context: context ?? .init()))
  }

  var body: some View {
    VStack {
      TextField("Search…", text: $vm.query)
      List(vm.results) { item in
        NavigationLink(/*…*/) { /* detail */ }
      }
      Button("Add") { vm.add() }
    }
  }
}

Final take

If you’re targeting iOS 17+ Observation is the correct default. It’s simpler than ObservableObject, scales better in lists and forms, and it clicks perfectly with SwiftData. Start migrating screen-by-screen: pin VM lifetimes with @State, mark non-state as @ObservationIgnored, and lean into @Bindable for ergonomic bindings. You’ll ship less code, with fewer bugs, and your UI will feel snappier — what’s not to like?

Local AI on Android - Do More On-Device with LiteRT & MediaPipe

2025-08-28T00:00:00+00:00

Running ML on-device isn’t just a cool demo anymore — it’s how you ship private, fast, resilient features without praying to the network gods. Modern Android hardware is plenty capable, and the tooling around LiteRT (formerly TensorFlow Lite) and MediaPipe has matured to the point where you can add image recognition, text classification, and even AR pipelines with surprisingly little code. Here’s the practical, opinionated guide I wish more apps followed.

What “local ML” means (and where it shines)

Local ML = your model runs entirely on the device CPU/GPU/NPUs via LiteRT or MediaPipe Tasks. No server call, no streaming tensors over the wire. Sweet spots:

Image recognition/segmentation (e.g., “Is this a receipt?” “Where’s the product label?”)
Text classification (moderation, topic/routing, sentiment, intent)
AR/real-time perception (object detection, face/pose landmarks feeding AR overlays)

If you’ve got latency-sensitive UX (camera previews, autocomplete, smart replies), on-device is almost always the right default.

Why now? Devices finally caught up

Mid-range phones ship with efficient NPUs/GPUs and more RAM; Android’s NNAPI has solid coverage; LiteRT/MediaPipe add high-level Task APIs that hide the scary parts. You don’t need a research team to get excellent results. In 2025, shipping on-device is the mature, modern path — not the experimental one.

The Big Wins

Privacy: user data never leaves the phone by default.
Speed: <100ms inference is normal for medium models; camera loops feel instant.
Offline: works on trains, planes, basements, and spotty 3G.

Project setup (do this first)

Add dependencies. I recommend starting with the Task libraries (they wrap preprocessing/postprocessing):

dependencies {
  // Core LiteRT runtime
  implementation("org.tensorflow:tensorflow-lite:<latest>")

  // Task libraries (high-level APIs)
  implementation("org.tensorflow:tensorflow-lite-task-vision:<latest>")
  implementation("org.tensorflow:tensorflow-lite-task-text:<latest>")

  // Or MediaPipe Tasks alternatives (great for vision/AR pipelines)
  implementation("com.google.mediapipe:tasks-vision:<latest>")
}

Bundle your model(s) in app/src/main/assets/models/…. Enable memory-mapping and avoid compression so LiteRT can map the file directly:

android {
  aaptOptions { noCompress "LiteRT" } // AGP older syntax
  // or on newer AGP:
  // packaging { resources { noCompress += ["LiteRT"] } }
}

Opinion: Always memory-map models. It slashes startup time and RAM spikes.

Option A — Vision in minutes with LiteRT Task APIs

Goal: classify a camera frame with a MobileNet-style classifier.

import org.tensorflow.lite.task.core.BaseOptions
import org.tensorflow.lite.task.vision.classifier.ImageClassifier
import org.tensorflow.lite.task.vision.classifier.ImageClassifier.ImageClassifierOptions
import org.tensorflow.lite.task.vision.core.TensorImage

class LocalImageClassifier(private val context: Context) {

  private val classifier: ImageClassifier by lazy {
    val base = BaseOptions.builder()
      .setNumThreads(4)
      .useNnapi() // or .useGpu() depending on device mix
      .build()

    val options = ImageClassifierOptions.builder()
      .setBaseOptions(base)
      .setMaxResults(3)
      .setScoreThreshold(0.5f)
      .build()

    ImageClassifier.createFromFileAndOptions(
      context,
      "models/mobilenet_v3.tflite",
      options
    )
  }

  fun classify(bitmap: Bitmap): List<Pair<String, Float>> {
    val image = TensorImage.fromBitmap(bitmap)
    val results = classifier.classify(image)
    // First head, top categories
    return results.firstOrNull()?.categories?.map {
      it.label to it.score
    } ?: emptyList()
  }
}

Tips that pay off:

Reuse the classifier instance (don’t re-create per frame).
On camera: run on a background dispatcher and throttle (e.g., every 2–3 frames).
Device strategy: NNAPI for Pixels/newer flagships, GPU for mid-range; test both.

Option B — Text classification (routing, moderation, intent)

For small-to-medium classifiers, a quantized BERT-like or CNN/RNN works well:

import org.tensorflow.lite.task.text.nlclassifier.BertNLClassifier

class LocalTextClassifier(context: Context) {
  private val model = BertNLClassifier.createFromFile(
    context, "models/bert_sentiment_int8.tflite"
  )

  fun classify(text: String): List<Pair<String, Float>> =
    model.classify(text).map { it.label to it.score }
}

Pro tips:

Normalize input (lowercase, trim, collapse whitespace) outside the hot path.
Keep sequence length small (e.g., 128 tokens). It’s the quickest lever for speed.

Option C — MediaPipe for perception + AR

MediaPipe Tasks give you production-ready detectors/segmenters with robust tracking—perfect for powering AR overlays.

import com.google.mediapipe.tasks.vision.core.RunningMode
import com.google.mediapipe.tasks.vision.objectdetector.ObjectDetector
import com.google.mediapipe.tasks.vision.objectdetector.ObjectDetectorResult

class LocalObjectDetector(context: Context) {

  private val detector: ObjectDetector

  init {
    val base = com.google.mediapipe.tasks.core.BaseOptions.builder()
      .setModelAssetPath("models/efficientdet_lite_int8.tflite")
      .setDelegate(com.google.mediapipe.tasks.core.Delegate.CPU) // or GPU
      .build()

    val options = ObjectDetector.ObjectDetectorOptions.builder()
      .setBaseOptions(base)
      .setRunningMode(RunningMode.IMAGE) // or LIVE_STREAM for camera
      .setMaxResults(5)
      .setScoreThreshold(0.5f)
      .build()

    detector = ObjectDetector.createFromOptions(context, options)
  }

  fun detect(mpImage: com.google.mediapipe.framework.image.BitmapImage): ObjectDetectorResult {
    return detector.detect(mpImage)
  }
}

Pair it with ARCore (anchors, hit tests) for realistic placement/occlusion while MediaPipe provides the perception signals.

Make models small & fast with selective quantization

You can usually cut model size/latency by 2–4x via quantization — without destroying accuracy — if you’re intentional.

Quick glossary:

Dynamic range (weights-only) int8: fast, easiest; good first step.
Full integer (int8 activations + weights): best for CPU/NNAPI; needs calibration data.
Float16: great for GPU; tiny accuracy drop; still uses float math.
Per-channel quantization: better accuracy for convs; turn it on if available.

Post-training quantization (Python, during build)

Dynamic range (no dataset required):

import tensorflow as tf
converter = tf.lite.tfliteConverter.from_saved_model("exported_model")
converter.optimizations = [tf.lite.Optimize.DEFAULT]
LiteRT_model = converter.convert()
open("model_dr_int8.tflite", "wb").write(LiteRT_model)

Full integer (representative dataset for calibration):

def rep_data():
  for batch in calibration_ds.take(100):
    yield [batch]  # match your model’s input signature

converter = tf.lite.tfliteConverter.from_saved_model("exported_model")
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.representative_dataset = rep_data
converter.target_spec.supported_ops = [
  tf.lite.OpsSet.tflite_BUILTINS_INT8,  # prefer int8
  tf.lite.OpsSet.tflite_BUILTINS        # allow float fallback if needed
]
converter.inference_input_type = tf.int8
converter.inference_output_type = tf.int8
LiteRT_model = converter.convert()
open("model_full_int8.tflite", "wb").write(LiteRT_model)

Selective quantization (the pragmatic way): allow both INT8 and FLOAT ops so layers that quantize poorly (e.g., embeddings, the final softmax) stay float while the rest quantizes. That’s exactly what the supported_ops list above accomplishes—INT8 when possible, transparent float fallback when accuracy demands it. If accuracy still dips, try float16:

converter = tf.lite.tfliteConverter.from_saved_model("exported_model")
converter.target_spec.supported_types = [tf.float16]
LiteRT_model = converter.convert()
open("model_fp16.tflite","wb").write(LiteRT_model)

Opinion: Ship INT8 on CPU/NNAPI, FP16 for GPU paths. Keep a float model around for A/B checks.

If you need low-level control (raw LiteRT Interpreter)

You won’t usually need this with Task APIs, but it’s handy for custom ops:

import org.tensorflow.lite.Interpreter
import org.tensorflow.lite.nnapi.NnApiDelegate
import java.io.FileInputStream
import java.nio.MappedByteBuffer
import java.nio.channels.FileChannel

private fun loadModel(context: Context, path: String): MappedByteBuffer {
  val afd = context.assets.openFd(path)
  FileInputStream(afd.fileDescriptor).channel.use { fc ->
    return fc.map(FileChannel.MapMode.READ_ONLY, afd.startOffset, afd.declaredLength)
  }
}

class RawLiteRT(context: Context) {
  private val delegate = NnApiDelegate()
  private val interpreter = Interpreter(
    loadModel(context, "models/custom_int8.tflite"),
    Interpreter.Options().apply {
      setNumThreads(4)
      addDelegate(delegate)
    }
  )

  fun run(input: ByteBuffer, output: ByteBuffer) {
    interpreter.run(input, output) // Match the model’s tensor shapes/dtypes
  }

  fun close() {
    interpreter.close()
    delegate.close()
  }
}

Gotchas: allocate direct ByteBuffers, reuse them, and never allocate in your 60fps loop.

Performance checklist (these move the needle)

Warm up the model at app start or feature entry (run one dummy inference).
Pin a background thread (e.g., Dispatchers.Default.limitedParallelism(1)) for deterministic latency.
Downscale inputs to the model’s native resolution; avoid runtime resizing to arbitrary sizes.
Batch wisely (often batch=1 is fastest on mobile).
Switch delegates by device (simple heuristic: Pixels/new flagships → NNAPI; others → GPU; fallback CPU).

Shipping & size management

For large models, consider Play Asset Delivery or on-first-run download (signed, checksummed).
Gate features by Device Capability (RAM, NNAPI support) instead of OS version alone.
Store the model version in preferences; expose a hidden debug screen to inspect model/engine/delegate at runtime.

Testing & monitoring

Add a micro-benchmark around inference (log P50/P95).
Compare INT8 vs FP16 vs FLOAT accuracy on a validation slice; don’t guess.
Use androidx.tracing to mark preprocessing → inference → postprocessing spans.

Opinionated TL;DR

Start with LiteRT Task (or MediaPipe Tasks for vision/AR), quantize aggressively but allow float fallback (that’s “selective quantization”), memory-map your .tflite, and pick delegates per device. You’ll get private, fast, offline features that feel magic — and you’ll stop burning cloud budget on requests your users’ phones can handle just fine.

Compile-time styling to kill runtime cost (Tamagui & NativeWind extraction)

2025-08-25T00:00:00+00:00

If you’re still pushing style objects around at runtime in React Native, you’re paying a tax you don’t need to. Inline objects and ad-hoc merges inflate the JS heap, trigger garbage collection, and sabotage memoization because object identity changes on every render. The antidote: compile-time styling. With Tamagui’s compiler and NativeWind’s className transform, your styles become precomputed, atomic/native constants — so your components render faster and your app’s JS stays calm.

Below is a practical, opinionated guide to switch your project to compile-time styling, what to watch out for, and how to structure a future-proof design system.

Why compile-time styling

No style object churn: Inline objects (style={{ padding: 12, color }}) allocate new memory every render. That breaks React.memo/PureComponent shallow comparisons and pressures the GC.
Smaller JS heap: Extracted styles are deduplicated and referenced by small numeric IDs (via StyleSheet.create) or precompiled style constants. Less allocation, less GC.
Faster renders: Less work in the render phase and fewer needless re-renders once styles become stable constants.

What “extraction” means in practice

NativeWind: at build time it compiles Tailwind utility strings into StyleSheet.create objects and precomputes conditional logic, leaving a minimal runtime to apply them.
Tamagui: a compiler analyzes your JSX/styled usage and lowers it to platform-native primitives, flattening view trees and extracting styles (atomic on the web, native constants on RN).

Do this with NativeWind (Expo-friendly)

Install + wire it up

npm i nativewind react-native-reanimated@~3 \
  react-native-safe-area-context
npm i -D tailwindcss prettier-plugin-tailwindcss
npx tailwindcss init

tailwind.config.js

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ['./App.{js,jsx,ts,tsx}',
    './components/**/*.{js,jsx,ts,tsx}'],
  presets: [require('nativewind/preset')],
  theme: { extend: {} },
  plugins: [],
  // optional: ensure rarely-hit classes are always generated
  safelist: ['bg-red-600','bg-blue-600','px-4','py-2']
}

babel.config.js

module.exports = function (api) {
  api.cache(true)
  return {
    presets: [
      ['babel-preset-expo', { jsxImportSource: 'nativewind' }],
      'nativewind/babel',
    ],
  }
}

metro.config.js

const { getDefaultConfig } = require('expo/metro-config')
const { withNativeWind } = require('nativewind/metro')

const config = getDefaultConfig(__dirname)
module.exports = withNativeWind(config, { input: './global.css' })

global.css

@tailwind base;
@tailwind components;
@tailwind utilities;

These steps enable the build-time className→StyleSheet extraction and wire Metro to include the generated CSS for web targets.

Use static classnames, keep conditionals enumerated

Bad (blocks extraction, forces runtime work):

// DO NOT: string interpolation that the compiler
// can’t see at build time
<Text className={`text-${size} bg-${color}-600`} />

Good (enumerate branches with complete strings):

<Text className={isLg ? 'text-lg' : 'text-base'} />

<Pressable
  className={clsx(
    'px-4 py-2 rounded',
    kind === 'primary' ? 'bg-blue-600' : 'bg-gray-600',
    disabled && 'opacity-50'
  )}
/>

Why so strict? Tailwind/NativeWind compilers scan complete, static strings; dynamic string building often isn’t detected, so the style never gets generated/extracted. If you must be dynamic, safelist the full set or map from known tokens.

Keep truly dynamic values in style, not in classes

Some values are genuinely data-driven (e.g., a bar’s width). Keep the base styles extracted, and pass the unextractable bit via style:

<View className="h-2 rounded bg-green-600"
  style={{ width: progress * 2 }} />

This keeps 95% of styles compiled while only a tiny numeric prop changes at runtime.

Do this with Tamagui (RN + Web, design-system forward)

Tamagui shines when you want typed tokens, variants, and shared RN/Web components. The compiler can flatten your trees and precompute variants for you.

Add the compiler

npm i tamagui @tamagui/babel-plugin

babel.config.js

module.exports = {
  plugins: [
    ['@tamagui/babel-plugin', {
      config: './tamagui.config.ts',
      components: ['tamagui'],
      // faster DX if you disable in dev; enable for production
      disableExtraction: process.env.NODE_ENV === 'development',
      // try this on recent versions if you rely on theme tokens
      // on native:
      // experimentalFlattenThemesOnNative: true,
    }],
  ],
}

On RN, the Babel plugin is optional, but turning it on for production is where you harvest the wins. It lowers styled usage to native primitives and precomputes styles.

Co-locate tokens & variants (your design system)

tamagui.config.ts

import { createTamagui } from 'tamagui'

const tokens = {
  color: {
    primary: '#2563eb',
    gray1: '#111827',
    gray5: '#6b7280',
  },
  space: {0: 0, 2: 8, 3: 12, 4: 16},
  radius: {sm: 8, md: 12},
  size: {sm: 32, md: 40},
}

const themes = {
  light: {background: 'white', color: 'gray1'},
  dark: {background: '#0b0b0b', color: 'gray5'},
}

export default createTamagui({
  tokens,
  themes,
  fonts: { /* … */},
})

Button.tsx

import { styled, Stack, Text } from 'tamagui'

export const Button = styled(Stack, {
  name: 'Button',
  ai: 'center',
  jc: 'center',
  br: '$md',
  px: '$4',
  h: '$md',
  variants: {
    size: {
      sm: {h: '$sm', px: '$3'},
      md: {h: '$md', px: '$4'},
    },
    tone: {
      primary: {bg: '$primary'},
      neutral: {bg: '$gray5'},
    },
  } as const,
  defaultVariants: {size: 'md', tone: 'primary'},
})

export function ButtonText(props) {
  return <Text col = "$color" { ...props } />
}

By defining tokens and variants in one place, the compiler can “see” them and extract efficiently. Tamagui’s design-system docs emphasize keeping optimized components in known modules so the compiler can statically analyze them.

Usage:

<Button tone="neutral">
  <ButtonText>Save</ButtonText>
</Button>

Expo/Metro notes

If you’re on Expo, follow the Tamagui Expo guide and add the Babel plugin as above; extraction can be disabled in dev for faster HMR and enabled in CI/releases.

Pitfalls (and how to dodge them)

Dynamic string classnames block extraction: Avoid bg-${color}-600, px- + size, or computed utility names. Prefer enumerated branches (ternaries, clsx with static keys) or safelist the exact final class names in tailwind.config.js. This keeps NativeWind compiling to constants instead of punting to runtime.
Hiding tokens from the compiler: In Tamagui, if you define styled components deep in app code that the compiler doesn’t track, you’ll miss optimizations. Keep your primitives and DS components in a package or folder referenced by the compiler’s components option, and whitelist any constants files (colors, spacing) that should be read at build time.
Mixing too many one-off dynamic styles: If everything is data-driven, you’ll fall back to runtime anyway. Consolidate into variants: tone, size, state (pressed/disabled). Leave only unavoidable values (e.g., width tied to progress) as inline numeric styles.
Forgetting web: Both stacks are great on RN, but the real beauty is RN+Web. NativeWind reuses Tailwind’s CSS on web; Tamagui extracts atomic CSS and flattens the tree. If you care about SSR and TTI on web, this is free performance.

Before vs after (micro example)

Before (runtime churn):

function Card({ color }) {
  // new object each render, breaks memo
  return (
    <View style={{padding: 16, borderRadius: 12,
      backgroundColor: color}}>
        <Text style={{fontWeight: '600'}}>Hello</Text>
    </View>
  )
}

After (extracted): NativeWind

function Card({ tone = 'primary' }) {
  const bg = tone === 'primary' ? 'bg-blue-600' : 'bg-gray-600'
  return (
    <View className={clsx('p-4 rounded-xl', bg)}>
      <Text className="font-semibold">Hello</Text>
    </View>
  )
}

After (extracted): Tamagui

import { Stack, Text } from 'tamagui'

function Card({ tone = 'primary' }) {
  return (
    <Stack p="$4" br="$md"
      bg={tone === 'primary' ? '$primary' : '$gray5'}>
        <Text fontWeight="600">Hello</Text>
    </Stack>
  )
}

Rollout checklist (my recommended order)

Turn on extraction (NativeWind Babel preset + Metro; Tamagui Babel plugin): Ship it behind a branch and profile a few hot screens.
Kill inline objects by replacing them with compile-time classes/props. Keep any truly dynamic numeric values in style.
Introduce variants for repeated patterns (tone, size, state): Co-locate tokens so they’re compiler-visible.
Safelist edge utilities that only appear in rare branches (loading/error) to ensure they’re generated.
Measure: with React DevTools Profiler + Flipper Memory, compare JS heap peaks and commit times before/after. You should see fewer re-renders and smaller GC spikes.

Bottom line: compile-time styling is the cleanest path to removing style churn in React Native. NativeWind gives you Tailwind ergonomics with constant-time styles; Tamagui gives you a typed design system with a smart compiler. Use them together or separately—but stop creating style objects on every render. Your app (and your users) will feel the difference.

Ship smaller, faster and safer JVM apps with custom JREs

2025-08-21T00:00:00+00:00

Far too few teams are using custom Java runtimes. Since Java 9 introduced the Java Platform Module System (JPMS), we’ve had first-class tooling — jdeps and jlink — to trim the JRE down to only what your app actually needs. That means smaller Docker images, faster cold starts, and a tighter attack surface. If you’re still copying a full JDK or a generic JRE into production, you’re leaving wins on the table.

Why bother with custom JREs?

Size: A full JDK image can be 300–400 MB. A jlink runtime for a typical REST service often lands in the 30–80 MB range. That’s a big deal for CI/CD speed and registry egress.
Startup & Memory: Fewer modules to scan and fewer classes to load. It’s not a silver bullet, but you’ll often see a small bump in startup time and memory consumption.
Security: Smaller runtime = smaller attack surface. If you don’t ship jdk.scripting.nashorn (RIP), no one can abuse it. Also fewer CVEs to track.
Determinism: jlink creates a frozen runtime image you can checksum. No “it works on my machine” because of system JRE differences.
Clarity: You learn what your app truly depends on (and sometimes discover surprising transitive deps).

And yes, this has been there since Java 9. We should all be using it by now.

But wait — where did the JRE go?

Rhetorical question time: Why doesn’t the Java team ship a generic, one-size-fits-all JRE anymore (as of the Java 9 era)? The short version: because of this. With JPMS and jlink, the platform pivoted from “download a big JRE” to “compose the runtime your app needs.”

A bit more nuance:

Starting with Java 9, the JDK itself became modular. The classic monolithic “JRE” concept became less compelling.
jlink empowers you to produce application-specific runtimes, which are usually smaller and safer than a generic JRE.
Some vendors still publish JRE-flavored packages (e.g., Temurin offers JDK and JRE builds), but those packages are mostly for testing or non-production use.

So yes, the disappearance (or de-emphasis) of the old bundled JRE is because you’re expected to build your own minimal runtime for production.

The payoff

Move a service from “full JRE in production” to “custom jlink runtime” and you typically get:

30–70% smaller images
Faster pulls & deploys
Slightly quicker startup and memory c
Reduced CVE surface
More predictable runtime behavior

None of this requires heroic refactors—just a couple of Docker stages and two standard tools.

The two tools you need

jdeps — discover module dependencies

jdeps analyzes your application’s JAR(s) and prints the exact set of JDK modules you need.

# Build your app first (e.g., ./gradlew shadowJar or mvn package)
# Then analyze the fat jar (or a dir of jars)
jdeps \
  --multi-release 17 \
  --ignore-missing-deps \
  --print-module-deps \
  build/libs/app-all.jar

That prints something like:

java.base,java.logging,java.net.http,java.sql

If you’re on Java 21, swap the –multi-release accordingly. Add –class-path for any non-JDK deps if needed.

jlink — assemble the runtime

Feed those modules to jlink and it will produce a self-contained runtime image:

jlink \
  --add-modules java.base,java.logging,java.net.http,java.sql \
  --strip-debug \
  --no-man-pages \
  --no-header-files \
  --compress=2 \
  --output build/custom-java

The build/custom-java directory is your custom “JRE” (technically a runtime image) with bin/java inside. Ship that next to your app and you’re done.

A production-grade Dockerfile (multi-stage)

Here’s a clean pattern that builds the app, computes the minimal modules, bakes a custom runtime, then ships only the runtime + app.

# ---- 1) Build stage: compile app ----
FROM eclipse-temurin:21-jdk-jammy AS build
WORKDIR /workspace

# Copy only build files first for better layer caching (Maven example)
COPY pom.xml ./
COPY src ./src

# Build fat jar (adjust for Gradle if you prefer)
RUN mvn -q -DskipTests package

# ---- 2) Analyze stage: compute modules with jdeps ----
FROM eclipse-temurin:21-jdk-jammy AS jdeps
WORKDIR /jdeps
COPY --from=build /workspace/target/*.jar app.jar
# Figure out exactly which JDK modules we need
RUN DEPS=$(jdeps --multi-release 21 --ignore-missing-deps --print-module-deps app.jar) \
&& echo $DEPS > modules.txt

# ---- 3) JLink stage: assemble minimal runtime ----
FROM eclipse-temurin:21-jdk-jammy AS jlink
WORKDIR /jlink
COPY --from=jdeps /jdeps/app.jar /jlink/app.jar
COPY --from=jdeps /jdeps/modules.txt /jlink/modules.txt
# Build the custom runtime
RUN jlink \
--add-modules $(cat modules.txt) \
--strip-debug --no-man-pages --no-header-files --compress=2 \
--output /jre

# ---- 4) Runtime stage: tiny final image ----
# If you don't use native libs, a distroless base is great. Otherwise use debian:bookworm-slim.
FROM gcr.io/distroless/base-debian12:nonroot
WORKDIR /app

# Copy app and the custom Java runtime
COPY --from=build  /workspace/target/*.jar /app/app.jar
COPY --from=jlink  /jre /opt/java

# Non-root by default with distroless; override entrypoint
ENTRYPOINT ["/opt/java/bin/java","-XX:+UseContainerSupport","-jar","/app/app.jar"]

Notes:

For Gradle, replace the Maven build with ./gradlew shadowJar and change the JAR path.
If your app relies on native libraries (e.g., Netty epoll, font rendering, or JNI), start from debian:bookworm-slim instead of distroless to ensure needed system libs exist — or copy them explicitly.
If you prefer Alpine, use musl-based OpenJDK images end-to-end. Mixing glibc and musl builds will hurt.

Handling tricky cases (reflection, ServiceLoader, dynamic features)

jdeps is static analysis. If you load classes dynamically (reflection, ServiceLoader), jdeps might miss some modules. A few strategies:

Start large, then trim: begin with the jdeps set and add modules as runtime errors point them out.
Know the usual suspects:
- JDBC drivers → java.sql
- HTTP clients → java.net.http
- XML / JAXB (legacy) → java.xml / jdk.xml.dom
- SSL/TLS → java.security.sasl, jdk.crypto.ec (for ECDSA)
Unit/integration tests in CI against the custom runtime image to catch missing modules early.
Use --add-modules ALL-SYSTEM in a dev image if you’re exploring, then narrow down.

Make it repeatable

Add a tiny script to your repo so devs and CI can reproduce the runtime:

#!/usr/bin/env bash
set -euo pipefail

JAR=${1:-build/libs/app-all.jar}
JAVA_VERSION=${2:-21}
OUT_DIR=${3:-build/custom-java}

DEPS=$(jdeps --multi-release $JAVA_VERSION --ignore-missing-deps --print-module-deps "$JAR")
echo "Modules: $DEPS"

jlink \
--add-modules "$DEPS" \
--strip-debug --no-man-pages --no-header-files --compress=2 \
--output "$OUT_DIR"

"$OUT_DIR/bin/java" -version

Call it from your Docker build or CI pipeline to ensure the runtime is always derived from the current app.

Opinionated best practices

Target the LTS you deploy (17 or 21 today for most teams) and set –multi-release accordingly when running jdeps.
Compress your runtime (--compress=2) and strip debug symbols for production.
Pin the exact JDK base image in Docker (e.g., eclipse-temurin:21.0.4_7-jdk-jammy) for reproducibility.
Pair jlink with class data sharing (CDS) if you’re squeezing startup; you can generate CDS archives for your app classes as well.
For multi-service repos, cache the jlink output per service; only rebuild when jdeps output changes.
Don’t over-optimize: if you’re shipping native libs or fonts or running headless services that still need java.desktop, accept the extra module and move on.

When not to use jlink

Fat containers with everything baked in (e.g., you’re fine shipping a full JDK, and image size/startup don’t matter). Sure, that’s legit in internal infra.
Rapid prototyping: use a standard JDK image to move fast, and introduce jlink when the app stabilizes.
Complex native dependencies that make the base OS and runtime coupling sensitive—solve the OS packaging first, then jlink.

TL;DR (but please don’t TL;DR)

Since Java 9, you can and should build custom runtimes.
Use jdeps to discover modules and jlink to assemble a minimal, reproducible runtime.
Bake that runtime into your final Docker image and ship only what your app needs.
And yes, that’s why the classic “downloadable JRE” faded away: the platform expects you to compose your own.

If you haven’t tried this on your main service, do it this week. Measure the image size and cold-start delta, share the numbers with your team, and make it the default. The tooling’s been rock-solid for years—time to cash in the benefits.

Swift 6 Strict Concurrency - Eliminate Data Races and Boost iOS Performance

2025-08-18T00:00:00+00:00

Swift 6’s strict concurrency isn’t a “nice to have.” It’s the cleanest, most scalable way to kill data races in your app — at compile time. If you flip it on and actually fix the warnings (don’t silence them), you get a codebase that’s easier to reason about, safer across teams, and faster under load.

Below is a practical, opinionated guide to turn it on, fix the fallout, and come out with a better architecture. Code snippets included.

Turn it on, incrementally, and surface the truth

My take: start with warnings, then graduate to errors. You want signal without breaking your CI on day one.

Xcode projects

In Build Settings → Strict Concurrency Checking, set to Complete. (Equivalent to SWIFT_STRICT_CONCURRENCY = complete in an .xcconfig)

SwiftPM (while still on Swift 5 language mode)

// Package.swift (Swift 6 tools or later)
.target(
  name: "AppCore",
  swiftSettings: [
    .enableUpcomingFeature("StrictConcurrency")
  ]
)

This enables complete actor-isolation and Sendable checking as warnings so you can see the blast radius.

Swift 6 language mode

Xcode: Swift Language Version → 6 (per target).
SwiftPM: using // swift-tools-version: 6.0 will build targets in Swift 6 language mode by default (you can still override per target).

Only move a module to Swift 6 mode after you’ve burned down warnings in that module.

Fix Sendable the right way

Principle: data that crosses concurrency domains must be provably safe to share.

Prefer value types (structs, enums)

If a type is immutable or only holds Sendable fields, the compiler will often infer Sendable. If not, declare it explicitly:

public struct UserSnapshot: Sendable {
  public let id: UUID
  public let name: String
  public let avatarURL: URL?
}

Avoid sprinkling @unchecked Sendable

Use it as a last resort and leave a TODO with a plan to remove. Wrap legacy reference types behind an actor or make them immutable.

final class LegacyThing { /* not thread-safe */ }

// Temporary: contain it
actor LegacyThingBox {
  private let inner = LegacyThing()
  // expose async methods that serialize access to `inner`
}

Fix “capture of non-Sendable in @Sendable closure”

Don’t pass around mutable classes inside parallel tasks. Either:

Snapshot the data into a Sendable value, or
Give the object an actor “front door,” and call it with await.

This is where you pay down the technical debt you’ve been ignoring. It’s worth it.

Actor isolation: be intentional with @MainActor

Hot take: too many projects mark entire view models as @MainActor and then complain the UI is slow. Mark only what must run on the main thread.

UI types and UI entry points

@MainActor
final class ProfileViewModel: ObservableObject {
  @Published private(set) var name: String = ""

  // UI-initiated action (touches UI state) — keep it on main actor
  func load() async {
    // <- cross-actor hop
    let user = await userService.currentUser()
    name = user.name
  }
}

Use nonisolated to avoid unnecessary hops

If something is pure (no access to isolated state), make it nonisolated so it can run anywhere without the main-actor hop:

@MainActor
final class ProfileViewModel: ObservableObject {
  private let formatter = PersonNameComponentsFormatter()
  @Published private(set) var name: String = ""

  // Pure helper: no `self` or isolated state
  nonisolated func format(_ user: UserSnapshot) -> String {
    user.name.uppercased()
  }

  func update(_ user: UserSnapshot) {
    name = format(user) // no hop, no await
  }
}

Rules of thumb

@MainActor on UI entry points (rendering, @Published, SwiftUI actions).
nonisolated for fast paths — formatting, hashing, mapping — as long as they don’t touch isolated state.
Avoid nonisolated(unsafe) unless you truly know what you’re doing and you’re protecting access externally (locks, actors). Treat it as a temporary escape hatch while migrating.

Adopt global actors for shared subsystems

When many types must serialize access to the same resource (disk cache, analytics pipeline, database), global actors shine. They give you a single, app-wide executor for that subsystem — no copy-paste DispatchQueues, no hand-rolled locks.

Define a global actor

@globalActor
actor StorageActor {
  static let shared = StorageActor()
}

This makes @StorageActor a usable attribute across your codebase.

Isolate a subsystem to it

@StorageActor
final class DiskCache {
  private var index: [String: URL] = [:]

  func store(_ data: Data, for key: String) throws {
    let url = /* compute file URL */
    try data.write(to: url)
    index[key] = url
  }

  func load(_ key: String) -> Data? {
    guard let url = index[key] else { return nil }
    return try? Data(contentsOf: url)
  }
}

Now any call into DiskCache synchronizes through StorageActor.shared. You can mark other types (ImageDatabase, FileMover) with @StorageActor and they’ll all share the same serialized executor. This is a clean, declarative way to guarantee “only one thing touches the disk at a time.”

When to use a global actor vs plain actor?

Plain actor: per-instance isolation (each instance protects its own state).
Global actor: one shared executor for the whole subsystem. Use it when multiple types must coordinate.

Protocols, cross-module code, and migration tactics

Strict concurrency will uncover friction where protocols or 3rd-party APIs weren’t annotated.

Tips

If a protocol requirement must be callable off the main actor, don’t force @MainActor on the entire conforming type. Consider a nonisolated requirement or move the isolation to call sites.
For older dependencies, you can temporarily use @preconcurrency import SomeFramework to adopt without tripping over missing annotations — then file issues or PRs upstream to add proper Sendable/actor isolation. (Use sparingly; prefer fixing types.)
If you have global mutable state (singletons, static var), either make it immutable (static let) or move it behind an actor/global actor. Avoid using nonisolated(unsafe) as a permanent fix.

Concrete before/after examples

Example A: Non-Sendable capture → value snapshot

Before

final class Session { var token: String } // not Sendable
let session = Session()

Task.detached { // runs concurrently
// warning: capture non-Sendable
  await api.fetchProfile(token: session.token)
}

After

// snapshot the value
let token = session.token

Task.detached {
  await api.fetchProfile(token: token) // ok: String is Sendable
}

Example B: UI work vs background work

@MainActor
final class PhotosViewModel: ObservableObject {
  @Published private(set) var thumbnails: [UIImage] = []

  func refresh() async {
    // hop off main actor to do CPU work
    // not main-isolated
    let images = await ImagePipeline.shared.loadThumbnails()
    thumbnails = images // back on main
  }
}

@globalActor
actor ImagePipeline {
  static let shared = ImagePipeline()

  func loadThumbnails() async -> [UIImage] {
    // decode/resize here; serialized by the pipeline actor
  }
}

Example C: Nonisolated fast path inside a main-actor type

@MainActor
final class FormatterVM {
  nonisolated func formatCount(_ n: Int) -> String {
    NumberFormatter.localizedString(
      from: n as NSNumber, number: .decimal)
  }

  func updateLabel(_ n: Int) {
    label = formatCount(n) // no actor hop, no await
  }

  @Published private(set) var label = ""
}

Ensure the helper is actually pure—no shared global DateFormatters unless they’re isolated.

Team workflow that works

Flip on “Strict Concurrency: Complete” across modules to surface all warnings. Track counts in CI.
Triage by category: Sendable first (easy wins with value types), then actor-isolation fixes (@MainActor, nonisolated, global actors).
Cut tickets per dependency: libraries missing annotations? Fork or open PRs.
Move modules to Swift 6 language mode once warning-free. Repeat until everything is in Swift 6.

Pitfalls to avoid

Blanket @MainActor on “everything UI-ish.” That kills concurrency. Be precise.
@unchecked Sendable everywhere: It’s a liability; aim to remove it.
nonisolated(unsafe) as a permanent solution: It disables protections—use it only as a temporary bridge with clear exit criteria.

Why this makes your app faster

Strict concurrency isn’t just safety theater. By isolating subsystems and removing accidental main-actor hops, you:

Reduce contention on the main thread → smoother scroll and animations.
Avoid hidden locks and GCD pyramids → less overhead, fewer context switches.
Make parallelism explicit → e.g., async let + actors scale cleanly on modern CPUs.

Final nudge

Turn it on. Fix the warnings. Introduce global actors where you share mutable state. Use @MainActor sparingly and nonisolated aggressively for pure, fast paths. You’ll end up with code that reads like it intends to run correctly — not code that hopefully does.

Jetpack Compose Performance Patterns - Practical Ways to Cut Recomposition and CPU

2025-08-14T00:00:00+00:00

Jetpack Compose is modern, declarative, and fast — when we use it the way it wants to be used. Too many teams still treat Compose like XML-with-data-binding: state scattered, derived values recalculated on every frame, lists reading scroll state per-row… and then wonder why the UI jitters on mid-range phones. Let’s fix that.

Below are opinionated, field-tested patterns that minimize recompositions and keep your frames silky. We’ll focus on four workhorses — derivedStateOf, remember, snapshotFlow, and LazyListState — and end with a simple way to see recompositions in debug via Modifier.recompositionHighlighter().

Golden rule: make fewer things observe fewer things

Recomposition is not evil; unnecessary recomposition is. The trick is to:

Localize state to the smallest scope that needs it.
Stabilize references so Compose doesn’t think parameters have “changed” each frame.
Derive expensive values behind memoization.
Bridge fast-changing state (like scroll) to coroutines and throttle it.

remember: stabilize objects and expensive work

remember keeps objects stable across recompositions. Use it to:

Avoid rebuilding expensive objects (formatters, regexes, painters, Path).
Produce stable lambdas so list rows don’t think callbacks changed.
Cache computations that don’t depend on changing inputs.

Bad (allocates every recomposition):

@Composable
fun Price(amount: Long) {
  val formatter = NumberFormat.getCurrencyInstance() // rebuilt often
  Text(formatter.format(amount / 100.0))
}

Good (stable):

@Composable
fun Price(amount: Long) {
  val formatter = remember { NumberFormat.getCurrencyInstance() }
  Text(formatter.format(amount / 100.0))
}

Stabilize callbacks per-key

@Composable
fun RowItem(item: Item, onClick: (String) -> Unit) {
  val stableOnClick = remember(item.id) { { onClick(item.id) } }
  ListItem(modifier = Modifier.clickable(onClick = stableOnClick)) {
    // ...
  }
}

Use keys when dependencies change

val painter = remember(url) { /* create painter or ImageRequest */ }

Opinion: if you aren’t using remember in list rows and in any constructor-like code, you’re leaving performance on the table.

derivedStateOf: derive once, update only when inputs change

derivedStateOf memoizes a computed value and invalidates it only when the inputs read inside change. This protects you from re-running filters/sorts on every recomposition.

Filtering a list by search query

@Composable
fun UserList(users: List<User>, query: String) {
  val filtered by remember(users, query) {
    derivedStateOf {
      if (query.isBlank()) users
      else users.filter { it.name.contains(query, ignoreCase = true) }
    }
  }
  LazyColumn {
    items(filtered, key = { it.id }) { user -> Text(user.name) }
  }
}

Header elevation based on scroll

@Composable
fun ElevatingTopBar(listState: LazyListState) {
  val elevated by remember {
    derivedStateOf {
      listState.firstVisibleItemIndex > 0 ||
      listState.firstVisibleItemScrollOffset > 0
    }
  }
  TopAppBar(
    title = { Text("Inbox") },
    modifier = Modifier.shadow(if (elevated) 4.dp else 0.dp)
  )
}

Opinion: reach for derivedStateOf anytime you write “filter/sort/map/group/expensive logic inside a composable.” It’s a low-effort, high-impact micro-optimization.

snapshotFlow: turn Compose state into a Flow (and throttle it)

LazyListState changes a lot while you scroll. Reading it directly in many places will cause many recompositions. Instead, transform state to a Flow and react off the main composition.

Show “Scroll to top” only when scrolled

@Composable
fun ScrollAwareFab(listState: LazyListState, onClick: () -> Unit) {
  var show by remember { mutableStateOf(false) }

  LaunchedEffect(listState) {
    snapshotFlow {
      listState.firstVisibleItemIndex > 0 ||
      listState.firstVisibleItemScrollOffset > 0
    }
    .distinctUntilChanged()
    .collect { show = it }
  }

  AnimatedVisibility(visible = show) {
    FloatingActionButton(onClick = onClick) {
      Icon(Icons.Default.ArrowUpward, null)
    }
  }
}

Throttle expensive reactions (e.g., analytics, network)

LaunchedEffect(listState) {
  snapshotFlow { listState.firstVisibleItemIndex }
    .distinctUntilChanged()
    .debounce(150) // don’t spam
    .collect { index -> viewModel.onSectionVisible(index) }
}

Opinion: scroll is a firehose—never let it directly drive composables in a tight loop. snapshotFlow + distinctUntilChanged/debounce is the clean pattern.

LazyListState patterns: isolate, key, and avoid per-row observers

Create it once

val listState = rememberLazyListState()
LazyColumn(state = listState) { /* ... */ }

Don’t read listState in each item. Compute a derived boolean in the parent and pass just that down.

Bad:

items(items) {
  // each row reads!
  val elevated = listState.firstVisibleItemScrollOffset > 10
  Cell(elevated)
}

Good:

val elevated by remember {
  derivedStateOf {
    listState.firstVisibleItemScrollOffset > 10
  }
}

items(items, key = { it.id }, contentType = { "cell" }) { item ->
  Cell(elevated) // stable boolean
}

Always provide a stable key and (when useful) contentType

LazyColumn(state = listState) {
  items(
    items = uiModels,
    key = { it.id },          // keeps item state when reordered
    contentType = { it.type } // lets LazyColumn reuse layouts
  ) { model -> RowFor(model) }
}

Prefer immutable models

@Immutable
data class UiModel(
  val id: String, val title: String, val type: String)

Immutable (or stable) models + proper keys = fewer invalidations across the list.

Compose effects: keep them stable with rememberUpdatedState

When a long-lived effect (like LaunchedEffect(Unit)) needs the latest lambda or value, avoid re-starting the coroutine whenever that value changes. Use rememberUpdatedState.

@Composable
fun EventConsumer(events: Flow<Event>, onEvent: (Event) -> Unit) {
val currentOnEvent by rememberUpdatedState(onEvent)

    LaunchedEffect(events) {
      // no unnecessary restart
      events.collect { e -> currentOnEvent(e) }
    }
}

Putting it together: a smooth list screen

@Composable
fun MessagesScreen(
  all: List<Message>,
  query: String,
  onMessageClick: (String) -> Unit
) {
  val listState = rememberLazyListState()

  // 1) Filter efficiently
  val filtered by remember(all, query) {
    derivedStateOf {
      if (query.isBlank()) all else all.filter { it.matches(query) }
    }
  }

  // 2) Derive scroll info once
  val showElevatedBar by remember {
    derivedStateOf {
      listState.firstVisibleItemIndex > 0 ||
      listState.firstVisibleItemScrollOffset > 0
    }
  }

  // 3) Drive side-effects via snapshotFlow (debounced)
  var showScrollTop by remember { mutableStateOf(false) }
  LaunchedEffect(listState) {
    snapshotFlow { listState.firstVisibleItemIndex > 0 }
      .distinctUntilChanged()
      .debounce(120)
      .collect { showScrollTop = it }
  }

  Column {
    TopAppBar(
      title = { Text("Messages") },
      modifier = Modifier.shadow(if (showElevatedBar) 4.dp else 0.dp)
    )

    LazyColumn(
      state = listState,
      modifier = Modifier.fillMaxSize()
    ) {
      items(
        items = filtered,
        key = { it.id },
        contentType = { "message" }
      ) { msg ->
          val onClick = remember(msg.id) {
            { onMessageClick(msg.id) }
          }
          MessageRow(message = msg, onClick = onClick)
        }
      }

      AnimatedVisibility(showScrollTop,
        modifier = Modifier.align(Alignment.End)) {
          FloatingActionButton(onClick = {
            // Scroll without rebuilding everything
            // (launch in composition scope, doesn’t cause
            // recomposition storm)
            CoroutineScope(Dispatchers.Main).launch {
              listState.animateScrollToItem(0)
            }
          }) {
            Icon(Icons.Default.ArrowUpward, contentDescription = null)
          }
        }
  }
}

Debug: see recompositions with recompositionHighlighter

Turn on the highlighter in debug to visualize what’s rebuilding. Add tooling dep:

dependencies {
  debugImplementation("androidx.compose.ui:ui-tooling")
  // (optional) for Layout Inspector & previews:
  debugImplementation("androidx.compose.ui:ui-tooling-preview")
}

Wrap parts of the UI:

@Composable
fun Debuggable(content: @Composable Modifier.() -> Unit) {
  Box(Modifier.recompositionHighlighter().then(Modifier.content()))
}

Or just sprinkle it where needed:

LazyColumn(
  state = listState,
  modifier = Modifier
    .fillMaxSize()
    .recompositionHighlighter() // watch this region
) { /* ... */ }

When you scroll or type, anything frequently flashing is suspect. Drill down until only the components that must recompose are flashing.

Opinion: make recompositionHighlighter() part of your daily dev build. It’s the quickest feedback loop to catch accidental invalidations.

Extra wins (quick checklist)

Avoid reading fast-changing state in many places. Centralize reads, pass stable derived values down.
Hoist state so siblings don’t observe each other accidentally.
Prefer rememberSaveable for UI state that should survive config changes, remember otherwise.
Use collectAsStateWithLifecycle() + distinctUntilChanged() when observing flows from a ViewModel to reduce redundant recompositions.
Keep parameters stable. Don’t pass new List/Map instances each frame; compute them with remember/derivedStateOf.
Provide keys and content types in lazy lists. Always.

Why this is modern — and why it matters

Compose is young, and the mental model is different from XML. If you treat it like the old view system, you’ll pay in jank and battery. These patterns lean into Compose’s strengths: explicit state, stable inputs, memoized derivations, and coroutine bridges for high-frequency signals. The payoff is immediate: smoother scroll, fewer GC pauses, cooler CPUs, and longer battery life—especially on mid-tier hardware.

Adopt these patterns, keep the highlighter on in debug, and you’ll feel the difference in the first build.

React Native’s New Architecture, End to End - With Expo

2025-08-11T00:00:00+00:00

If you’re starting a new React Native project in 2025 and don’t adopt the New Architecture, you’re signing yourself up for avoidable debt. With Fabric for rendering, TurboModules for native modules, and Bridgeless mode eliminating legacy overhead, you get a faster, more predictable platform that aligns with modern React (Concurrent features, Suspense) and JSI-first interop. Expo makes this shift dramatically easier—frankly, it’s the path of least resistance now.

Why switch (now)?

Lower bridge overhead: The old serialized bridge is gone. JSI enables direct calls between JS and native, which reduces marshalling overhead and unlocks new capabilities. TurboModules and Fabric are built for this.
Faster mounts & more deterministic UI: Fabric refactors the render pipeline; mounting is quicker and behavior is more consistent across platforms. In RN 0.74+, Bridgeless became the default when New Arch is on, further simplifying the stack.
Concurrent React features: The New Architecture is where ongoing work lands—think full Suspense support and new styling capabilities. If you want React 18 features to shine in mobile, this is the highway.
Better interop with JSI: Type-safe native boundaries via codegen from TS/Flow specs mean fewer runtime “gotchas” and faster native calls. Expo Modules also sit naturally alongside TurboModules in this world.

Do this: Expo-first migration plan

Enable the New Architecture (Expo)

On SDK 53+: It’s enabled by default. If you previously turned it off, remove that override.
On SDK 52: Add this to your app config and rebuild:

{
  "expo": {
    "newArchEnabled": true
  }
}

Run a clean prebuild and build:

npx expo prebuild --clean && npx expo run:android
npx expo prebuild --clean && npx expo run:ios
# or with EAS
eas build -p android
eas build -p ios

For bare apps: toggle newArchEnabled=true in android/gradle.properties and enable it via Podfile.properties.json or Podfile on iOS.

What about Bridgeless? With RN 0.74+, New Arch implies Bridgeless by default. Expo SDK 53+ libraries support it; you’ll likely see “(NOBRIDGE)” logs in development—that’s expected.

Migrate UI libraries to Fabric-ready versions

Don’t drag old UI stacks into New Arch. Upgrade deliberately:

Lists: Switch to FlashList v2 — rewritten for the New Architecture, JS-only, smoother scrolling, no item size estimates. It’s a direct FlatList replacement with better perf.
Gestures: Use react-native-gesture-handler 2.3+ (Fabric support) or newer maintained versions.
Animations: Reanimated 4.x targets only the New Architecture; if you were on 2/3, plan the hop—worth it for layout/gesture/scroll performance.
Maps: If you use react-native-maps, target versions marked compatible (or consider expo-maps if you can drop older iOS versions). Expo’s doc tracks current advice here.

Pro tip: run npx expo-doctor@latest - Expo integrates React Native Directory data to flag incompatible deps right in your project. Bake this into CI.

Generate TurboModules from TS/Flow specs

This is the native module story in New Arch:

Create a specs/NativeYourModule.ts:

import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  ping(message: string): string;
}

export default TurboModuleRegistry.getEnforcing('NativeYourModule');

Add codegenConfig to package.json:

{
  "codegenConfig": {
    "name": "YourModuleSpec",
    "type": "modules",
    "jsSrcsDir": "specs",
    "android": {
      "javaPackageName": "com.yourapp.yourmodule"
    }
  }
}

Builds will run Codegen automatically (Gradle task on Android, CocoaPods script phase on iOS). Implement the generated interfaces on each platform, and you get type-safe, JSI-fast bindings.

Using Expo Modules? Great — Expo Modules are New-Arch ready by default and play nicely with TurboModules/Fabric. If you need custom native code, the Expo Modules API is the cleanest on-ramp.

Watch out (and how to handle it)

Upgrade discipline—versions matter.

The New Architecture is unforgiving about mismatched versions across RN, Reanimated, RNGH, and your list component. Pin versions explicitly in package.json, update lockfiles, and upgrade in small steps. Reanimated 4 only supports New Arch; FlashList v2 assumes New Arch; older RNGH versions may break.

Pin native deps that aren’t ready.

Some modules lag behind—especially those with heavy native code. Use Expo’s guidance for known problem libraries (e.g., react-native-maps caveats and alternatives). If a module isn’t ready, either pin a compatible version, swap to an Expo equivalent, or isolate it behind a feature flag until you can replace it.

CI build hygiene.

Adopt separate EAS build profiles for New Arch vs. legacy during migration (only temporarily). Run expo-doctor as a CI step. Fail the build if incompatible packages are detected so issues don’t creep into releases.

iOS/Android platform quirks.

Codegen is sensitive to Pod/Gradle state. When things act weird: clear derived data, pod deintegrate && pod install, ./gradlew clean, or expo prebuild --clean and rebuild. Keep your Podfile properties and Gradle flags in sync with the app config. (Expo’s guide shows the exact toggles for bare projects.)

Expect interop, but don’t rely on it forever.

Interop layers let many old-arch libs “sort of work,” but you’ll hit edges—especially for complex native views/gestures. Treat interop as a bridge to the bridge-less future, not a destination.

A pragmatic Expo rollout checklist

Upgrade to latest Expo SDK (preferably 53+): It’s New Arch by default and has the fewest traps.
Flip expo.newArchEnabled = true (if you’re on SDK 52), clean prebuild, and run a local build. Validate basic navigation, theming, network, and storage flows.
Replace perf-critical UI pieces:
- FlatList ➜ FlashList v2
- Old gesture stacks ➜ current RNGH + Reanimated 4
- Legacy modules ➜ Expo equivalents where possible.
Add expo-doctor to CI and block incompatible deps.
Harden TurboModules you own with TS specs + Codegen; remove any lingering bridge-only shims.
Keep Bridgeless on: It’s the default with New Arch since 0.74; don’t fight it—fix the few APIs that still assumed the legacy bridge.

Opinionated take

In 2025, Expo + New Architecture is the standard. The ecosystem momentum (Reanimated 4, FlashList v2, Expo Modules, RN 0.74+ bridgeless by default) means you’ll spend less time wrestling with the runtime and more time shipping product. If you must support a legacy library that’s not ready, isolate it and keep the rest of your app modern. The payoff—cleaner boundaries, better concurrency, tighter perf on lists/gestures—shows up fast.

Ship the New Architecture. With Expo, it’s finally boring—in the best possible way.