EEntiko
Start a project
← Services

03 · Service

Mobile apps

A phone app is not a website stuffed in a WebView. People expect push that is not spam, a login that survives a killed process, offline screens when the train loses signal, and a product that still feels like the same company as the site. We ship Android (Kotlin, and Java where the codebase already lives there) and iOS (Swift). When one team should hit both stores at the same cadence, we use React Native or Flutter — not as a slogan, as a written choice. Play Console and App Store Connect sit in accounts you own.

Founders who need a first consumer or staff app that is not a template, operators who need the floor in their pocket, and companies whose customers already live on WhatsApp and Instagram and now need a real product in the stores.

When this is not the work. If you only need a marketing site that works on a phone, that is Website design. If you need dashboards and APIs without a store listing, that is Software development. If the brief is “an app like Uber” with no first loop named, we will send you away until Tuesday is written down.

Start this work
Wireframing a product on a tablet — screens, not scenery

What this usually fixes

The “app” is a bookmark.

Someone wrapped the website. It feels slow, cannot use the camera properly, and dies when the network drops. We build a product that uses the OS — then talk to your API.

Android and iOS drifted in week three.

Two vendors, two design languages, two bugs for every feature. We ship both stores as one product: same copy, same release train, same owner.

Nobody can ship a build.

Certificates live on a laptop. The founder has a ZIP. There is no crash reporting. We put signing, TestFlight, internal testing, and versioned releases into your accounts — then we teach the train.

Push is either silent or a nuisance.

We design when a notification is allowed to interrupt, how it deep-links, and how a person turns it off. Permission prompts that fire on day zero are a product failure.

Pages and screens

What a buyer actually walks through — not a capability matrix.

Onboarding and auth

Phone OTP, email, or the identity you already have. A session that survives a swapped SIM and a killed process. Not a web login squeezed into a sheet.

Home and the daily loop

The screen people open on Tuesday. Queues, catalogues, bookings, chats — designed for a thumb, not a desktop dumped onto a phone.

Detail, pay, confirm

The screens that cost money: orders, UPI, cards, COD rules, receipts. Failures that can be retried without calling support.

Inbox, push, and account

Notifications with a reason. Profile, addresses, devices, delete-my-data. Store review prompts that wait until the product has earned them.

Staff and field apps

The other product: packing, visits, photos, GPS that is honest about battery. Often more valuable than the consumer app.

What we build

Native Android

Play Store products in Kotlin — Java where a codebase already lives there. Notifications, offline-tolerant screens, camera, location, and payments done with the OS, not a guess.

Native iOS

App Store products in Swift. The same product language as Android when we ship both — not a second company that drifted in week three. TestFlight before the public listing.

React Native

One TypeScript codebase for both stores when the product is UI-heavy and the OS features are within reach. Still a store app: signing, crash reporting, a release train.

Flutter

Dart when the UI is custom, the motion is the product, or the team you will inherit already thinks in Flutter. Same store discipline as native.

Staff and field apps

The pocket OS for packing, visits, deliveries, inspections. Offline first. Photos that upload when the signal returns.

App + API as one product

The phone is useless without a backend. Auth, media, push, and admin stay in Software development — same studio — so you are not coordinating three vendors who never speak.

How deep this goes

Native when the OS is the product

Camera pipelines, background location, Bluetooth, wallets, widgets, live activities, Play integrity, App Attest — these are reasons to write Kotlin and Swift. We will say so in the brief. We will not pick native because it sounds expensive.

  • Kotlin and Jetpack on Android; Swift and SwiftUI (or UIKit where the codebase is already there) on iOS
  • Permissions explained in the UI, not only in a system dialog
  • Tablets and foldables considered when the brief actually needs them

One codebase when cadence is the product

React Native or Flutter when you need both stores in the same sprint, with a shared design system. The bar is still a native-feeling app: lists that scroll, keyboards that do not jump, navigation that matches the platform. A WebView of the marketing site is not an app.

  • We write down why RN or Flutter — and what we will drop into native modules if the OS feature appears later
  • Over-the-air updates only where the store rules allow, never as a way to dodge review
  • The same TypeScript or Dart team that can also touch the API

Stores, signing, and a release train

Play Console and App Store Connect in your organisation. Signing keys you hold. Internal testing, TestFlight, staged rollouts, crash reporting (Firebase Crashlytics or equivalent), and a version that support can name on a call. Not a ZIP emailed to the founder.

  • Listings, screenshots, privacy nutrition labels, and data-safety forms that are true
  • Review notes for the first submission — Apple will ask; we answer in the file
  • A calendar: what ships this week versus what waits for the next train

Push, offline, and the ugly middle

Notifications with deep links into the right screen. Queues that retry. Images that wait for wifi. Auth tokens that refresh without logging the person out. Analytics that show where people drop — not a vanity install count.

  • FCM and APNs as infrastructure, not a plugin afterthought
  • Offline-tolerant reads; honest errors when a write cannot complete
  • Delete-account and data-export paths the stores now expect

India on a mid-range phone

We check on real Android hardware in the price band your customer actually buys — not only a studio iPhone. Hindi or regional copy when the buyer needs it. UPI in the pay sheet. WhatsApp as a share target, not the database.

  • Install size treated as a constraint
  • Dark mode when the OS asks, not as a costume
  • A first session that works on a spotty 4G

Languages, platforms, tools

The names people search for belong on a service page, not in a footer buzzword strip. This is what we actually ship in.

Android

  • Kotlin
  • Java
  • Jetpack
  • Compose

iOS

  • Swift
  • SwiftUI
  • UIKit

Cross-platform

  • React Native
  • Flutter
  • TypeScript
  • Dart

Stores & quality

  • Play Console
  • App Store Connect
  • TestFlight
  • Firebase
  • Crashlytics
  • Fastlane

What you walk away with

A build you can install

Internal testing or TestFlight in the first slice — not a six-month dark room. Then we widen the loop.

Store accounts and signing

Play Console, App Store Connect, certificates, and provisioning in your organisation. We are not on the listing as the owner.

Source and runbook

Repositories, how to cut a release, how to roll back, what the push certificates do at 2am.

Care after the listing

The first crashes, the first review rejection, and the first “can it also” are part of the job.

How the work runs

A named owner, a written brief, and something you can click early. The longer studio sequence is on Approach.

  1. 01

    Name the first loop

    Who opens the app on Tuesday, and what they must finish. Consumer, staff, or both. Native vs RN vs Flutter written down with reasons.

  2. 02

    Thin slice on a device

    Auth + one job-to-be-done on a real phone. You use it. Then we add pay, push, and the rest.

  3. 03

    Stores and a train

    Listings, privacy forms, staged rollout, crash reporting. Launch is not the last conversation.

Questions we hear

Do you build both Android and iOS?+

Yes. Native Kotlin/Java and Swift when the OS features are the product. React Native or Flutter when one codebase should serve both stores. We will say which, and why, before we write a screen.

Can you take an existing app in the stores?+

Often. We start with the repo, the certificates, the crash list, and the last rejected review. If it is safer to wrap than to rewrite, we say so.

Will we own the listing?+

Yes. Developer accounts, signing, and the product pages sit with you. We are not a hostage vendor.

How long until something is on a phone?+

A first installable slice is weeks, not a weekend — once the loop is named. Store review is extra calendar time we cannot fake. We will not quote “an app in seven days.”

Do we need a website as well?+

Usually yes: listings, support, privacy, and the pages Google expects. That is Website design, same studio. The API and admin are Software development. We will not make you hire three firms.

What about tablets, watches, or TV?+

Phone first unless the brief is honestly a tablet product (field, retail, kitchen). Watch and TV are a different scope — we will not hide them inside a phone quote.

Push notifications — can you just turn them on?+

We can technically. We will not, as a default. Permission on day zero and a blast to everyone is how apps get deleted. We design when a notification is allowed to interrupt.

Other capabilities

If this is the work, send the brief.

Contact