Android appsbuilt for thereal device.

Nine years of Android in production. Jetpack Compose that doesn't recompose wastefully, Kotlin coroutines that don't leak, architecture that handles the fragmentation most teams ignore. Three billion users deserve an app that works on a $120 phone.

  • Jetpack Compose
  • Kotlin-first
  • 60fps on low-end
  • Material 3

Why Entalogics for Android

Four things every
Android app
actually needs.

God Activities, XML nobody touches, a networking layer that crashes on config change, and zero thought for budget devices. We've inherited all of it. We fix the architecture before the Play Store reviews do.

Performance01

If it doesn't run smooth on a Pixel 4a, it doesn't ship.

We profile on mid-range hardware from day one. Recomposition tracing, baseline profiles, R8 shrinking. Smooth on budget devices isn't a bonus — it's where most users live.

Architecture02

Feature modules, not a monolithic app package.

Each feature is a Gradle module with its own screen, ViewModel, and tests. Build times drop. Teams don't step on each other.

State03

StateFlow into Compose. No LiveData. No callbacks.

ViewModels expose StateFlow collected with lifecycle awareness. UI state in a sealed interface — Loading, Success, Error. Impossible states stay unrepresentable.

Type safety04

Kotlin's type system used fully, not avoided.

Sealed classes for state machines. Value classes for domain primitives. Kotlin Serialization at every API boundary. When the backend changes a field, the build fails — not the app.

When native, when not

Android native is a tool.
Not always the answer.

Kotlin and Compose give you the deepest platform access. They also cost the most. We'll tell you on the first call if native is genuinely justified.

GO NATIVE WHEN

  • Hardware access matters — Bluetooth LE, camera2, NFC, sensors — where abstraction costs more than it saves
  • Fragmentation is first-class — foldables, tablets, Wear OS, Auto from one Kotlin codebase
  • Low-end device performance is non-negotiable and every extra runtime layer is too expensive
  • Play Store features like Instant Apps or Dynamic Feature Modules are requirements

CONSIDER CROSS-PLATFORM WHEN

  • You need both app stores and budget doesn't support two native teams
  • The app is primarily data display, forms, and navigation
  • Speed to market matters more than platform depth right now

WE SAY NO WHEN

  • "Native because native is always better." That's a belief, not a spec.
  • "Just wrap our website in a WebView." That's not native development.
  • "Ship to the Play Store in three weeks with no design." That ship has sailed.

What we build for Android

Six product surfaces.
One quality bar.

The shapes of native Android work we ship most. Each built for the Play Store — not a hackathon demo.

  • S01

    Consumer Android apps

    Onboarding, Play Billing, FCM push, App Widgets, Dynamic Feature delivery. Consumer polish that survives real user hands.

    JETPACK COMPOSEPLAY BILLINGFCMMATERIAL 3
  • S02

    Enterprise field apps

    Offline-first with Room, barcode scanning, NFC, GPS tracking, MDM compliance. Built for the warehouse and the construction site.

    ROOMCAMERAXWORK MANAGERDATASTORE
  • S03

    Foldable & tablet-adaptive apps

    Adaptive layouts with WindowSizeClass, multi-pane UIs, large-screen optimisation. One app for phone, tablet, and foldable.

    COMPOSE ADAPTIVEWINDOWSIZECLASSMATERIAL 3HILT
  • S04

    Wear OS companion apps

    Tiles, complications, health services. A Wear app that extends your phone app — not a stripped-down afterthought.

    WEAR COMPOSEHEALTH SERVICESTILESPROTOLAYOUT
  • S05

    Internal tooling

    Replace the spreadsheet your field team uses. Offline capture, photo evidence, GPS logging, sync when connectivity returns.

    COMPOSEROOMWORK MANAGERCOIL
  • S06

    XML to Compose migrations

    ComposeView inside existing Fragments. Screen by screen, no flag-day. The current app stays live while we modernise.

    COMPOSECOMPOSEVIEWNAVIGATIONHILT

The playbook

Patterns we
ship on repeat.

Android patterns from production apps — not Codelabs.

  • P01

    Compose-first, XML when earned

    New screens in Jetpack Compose. XML only for legacy screens not yet migrated. No mixed-for-no-reason codebases.

  • P02

    Coroutines + Flow everywhere

    ViewModelScope for screen-scoped work. WorkManager for guaranteed background execution. No AsyncTask, no RxJava on new code.

  • P03

    Gradle module per feature

    Each feature is its own module. Build cache improves. CI parallelises. Two engineers work without touching the same build file.

  • P04

    Design tokens via Compose theme

    Material 3 tokens extended with your brand. Light/dark, dynamic colour, large-screen density from a single token source.

  • P05

    Screenshot + instrumented tests

    Compose screenshot tests for visual regression. Espresso for critical flows. CI runs on every PR against real emulators.

  • P06

    Incremental Compose adoption

    ComposeView inside existing XML layouts. One screen at a time. The app ships continuously.

Signature case

An enterprise field app,
rebuilt from Java XML to Kotlin Compose.

An enterprise logistics app — 8s cold start on target devices, Activities averaging 4,000 lines, no offline despite warehouse use with spotty connectivity. Rebuilt in Kotlin Compose with Room and WorkManager in 11 weeks. Rating went from 2.8 to 4.5.

Before

Java XML · cold start 8s · avg Activity 4,000 lines · no offline · rating 2.8★

After

Kotlin Compose · cold start 1.8s · avg screen 320 lines · offline-first · rating 4.5★

  • Cold start improvement−78%
  • Play Store rating+61%
  • To fully rebuilt11wk
  • Shipped regressions0

Engagement shape

Eight to ten weeks
to a measurable ship.

A typical Android engagement. We build screen by screen — never a six-month rewrite. The current app stays on the Play Store while we work.

  • W01

    Audit + RFC

    Two senior Android engineers. Baseline profile analysis, recomposition tracing, module audit. A ranked, dollarized RFC.

  • W02–03

    Foundation + first screen

    Compose baseline, Gradle modularisation, Hilt wired in, one production screen end-to-end. Real numbers on a mid-range device.

  • W04–08

    Build screen by screen

    Feature by feature under feature flags. Internal track releases weekly. Your roadmap keeps moving.

  • W09+

    Play Store submission + handoff

    Store listing, compliance, first submission. Runbook handed to your team — or we stay on retainer.

Stack

Tools we
reach for first.

Picked for production Android — not tutorial starters.

  • LanguageKotlin · Jetpack Compose · Kotlin Serialization · Coroutines + Flow
  • DataRoom · DataStore · Ktor · Retrofit
  • DIHilt · Koin
  • TestingJUnit 5 · Compose Test · Espresso · Turbine
  • ToolingGradle KTS · Baseline Profiles · R8 · Detekt
  • InfraFirebase · Play Console · Sentry · Datadog

Engagement

Three ways
to work with us.

No hourly retainer that bills for "thinking time." Pick a lane that matches your stage; everything is fixed-quote or transparently rated.

FIXED SCOPEone-off build

Ship an Android app, end-to-end.

A defined product, a fixed price, a senior-only team. From RFC to Play Store submission in 8–14 weeks.

$15k–$30k

FIXED SCOPE

  • Senior engineers only
  • Fixed quote in week 1
  • Code, infra, runbook — yours
Plan a fixed build
DEDICATED TEAMmonthly

Hire dedicated Android developers.

Embedded engineers in your Slack, your Linear, your standups. Senior Kotlin engineers. Pause, resize, end with 30 days' notice.

$5k / eng / mo

PER ENGINEER

  • Same senior bar as fixed-scope
  • Embedded in your team
  • Founder-direct escalation
Hire dedicated Android devs
ENGAGEMENTcustom

Strategic Android partnership.

A long-term partner for product orgs shipping across Google's ecosystem — phone, tablet, foldable, Wear OS.

custom

PROCUREMENT-FRIENDLY

  • Multi-quarter roadmap
  • Architecture & hiring partner
  • Procurement-friendly paper
Speak to the founder
FAQ

Sharp questions,
straight answers.

Compose vs XML, native vs cross-platform, migrations — the questions we get on every Android discovery call.
Compose for all new projects — it's Google's recommended path and significantly faster to build with. XML when you're inside an existing codebase and a rewrite isn't justified. We migrate incrementally — Compose screens inside XML navigation, one at a time.
Native when you need deep platform access or low-end device performance is non-negotiable. Cross-platform when you need both stores and the app is primarily data-driven UI. We'll tell you on the first call.
Yes. ComposeView lets Compose live inside existing Fragments. Screen by screen, the app ships continuously. No freeze.
Yes. The engineers who write the RFC ship the code. No handoff mid-engagement. Direct access throughout.
Yes. We adapt to your navigation, DI, and CI setup. If something needs changing, we flag it in the RFC. If it works, we build on top of it.

Founder-direct

Tell us whatyou're building.

Thirty minutes with the founder. We'll bring a senior Android engineer, the relevant playbook, and a candid read on whether native Kotlin is the right call — or whether cross-platform gets you there faster.