application services · mobile development

Mobile apps that pass store review on the first upload.

Apple and Google change the rules every year. Since 28 April 2026, App Store uploads must be built with Xcode 26, and since 31 August 2026 new Google Play updates must target Android 16. We build apps and keep them shippable through each change.

platforms
application-services / mobile-development 4 platforms
01 · DEVICE 02 · IDENTITY 03 · BACKEND 04 · RELEASE Mobile app: Swift · Kotlin · React Native Mobile app Swift · Kotlin · ReactNative Secure storage: Keychain · Android Keystore Secure storage Keychain · AndroidKeystore App integrity: App Attest · Play Integrity App integrity App Attest · PlayIntegrity Identity platform: Auth0 · Okta · Entra ID Identity platform Auth0 · Okta · EntraID Mobile API: token validation · rate limits Mobile API token validation ·rate limits CRM: Salesforce CRM Salesforce Build and signing: CI · TestFlight · Play testing Build and signing CI · TestFlight · Playtesting
Auth0OktaMicrosoft Entra IDSalesforce
in short·20-second read

Mobile development covers designing, building, releasing and maintaining iOS and Android apps.

Cohash builds native apps in Swift and Kotlin, or cross-platform apps in React Native or Flutter where one codebase makes sense. We handle store submissions, keep apps current with Apple and Google SDK deadlines, and implement sign-in through Auth0, Okta or Entra ID using OAuth with PKCE and tokens held in the Keychain or Android Keystore.

you probably need this if
  • The app has an API key compiled into the binary and anyone can pull it out.
  • A store deadline for a new SDK or target API level is coming and the build won't compile.
  • Two separate teams maintain iOS and Android apps that drift apart feature by feature.
Ask an engineer facts checked 2026-10-20 · 6 sources
how it runs
  1. 01Discovery
  2. 02Design
  3. 03Build and beta
  4. 04Release and maintain
you keep
  • App source code with CI build and signing pipeline
  • Store listings, privacy disclosures and submission support
  • Mobile identity integration and token storage design
+ 2 more documents
who does it
iOS developer (Swift)Android developer (Kotlin)React Native or Flutter developer
platforms
the story · mobile development

From the first call to a setup your own team can run.

Here's what usually prompts a call about your Mobile Development, what we do about it and in which order, and where you end up.

  1. chapter 01 · where it hurts

    Why teams reach out

    • The app has an API key compiled into the binary and anyone can pull it out.
    • A store deadline for a new SDK or target API level is coming and the build won't compile.
    • Two separate teams maintain iOS and Android apps that drift apart feature by feature.
  2. chapter 02 · what we change

    How we solve it

    • Native or cross-platform, decided per app
    • Store compliance calendar
    • Mobile sign-in
    • Backends that assume the app is public
    • Release pipelines
  3. chapter 03 · how it runs

    Our approach

    • Discovery
    • Design
    • Build and beta
    • Release and maintain
  4. chapter 04 · where you end up

    What changes

    • Both stores accept updates again.
    • There's nothing in the binary worth pulling out any more.
    • Updates still reach Google Play after February 2027.
    • App source code with CI build and signing pipeline
what we do

Where we spend the hours

5 areas of work, each one done by an engineer who has run it in production.

  1. We go native with Swift and Kotlin when the app leans on device features or needs real performance. If the screens are mostly forms and lists and one team has to ship both platforms, React Native or Flutter is usually the better call.

  2. Apple requires the iOS 26 SDK for uploads and iOS 13 as a minimum target from 9 September 2026. Google Play requires API level 36 for new apps and updates, with extensions to 1 November 2026 on request.

  3. OAuth authorization code flow with PKCE through the system browser, as the native-apps best practice in RFC 8252 describes. Refresh tokens stored in the Keychain or Keystore, with biometric sign-in and passkeys where your identity provider supports them.

  4. No API keys or client secrets in the binary. Requests carry user tokens with narrow scopes, and App Attest or Play Integrity signals help the backend tell a genuine app from a script.

  5. We automate builds and signing and use TestFlight or Play internal testing tracks. Then we roll releases out in stages with crash monitoring, so a bad one reaches few users.

capability 01 / 05in production

Native or cross-platform, decided per app

We go native with Swift and Kotlin when the app leans on device features or needs real performance. If the screens are mostly forms and lists and one team has to ship both platforms, React Native or Flutter is usually the better call.

capability 02 / 05in production

Store compliance calendar

Apple requires the iOS 26 SDK for uploads and iOS 13 as a minimum target from 9 September 2026. Google Play requires API level 36 for new apps and updates, with extensions to 1 November 2026 on request.

capability 03 / 05in production

Mobile sign-in

OAuth authorization code flow with PKCE through the system browser, as the native-apps best practice in RFC 8252 describes. Refresh tokens stored in the Keychain or Keystore, with biometric sign-in and passkeys where your identity provider supports them.

capability 04 / 05in production

Backends that assume the app is public

No API keys or client secrets in the binary. Requests carry user tokens with narrow scopes, and App Attest or Play Integrity signals help the backend tell a genuine app from a script.

capability 05 / 05in production

Release pipelines

We automate builds and signing and use TestFlight or Play internal testing tracks. Then we roll releases out in stages with crash monitoring, so a bad one reaches few users.

typical situations

Situations we walk into

We pieced these together from Mobile Development situations that come up a lot. They're patterns. You won't find a specific client in them.

case file 01

React Native app still on API 34 past the Android 16 deadline

composite · not a client story
  1. Beforethe situation

    A React Native app from a few years back still targets API level 34, so Google Play won't take updates without an extension. On top of that, a native card-scanning module no longer compiles and the iOS build fails on Xcode 26.

  2. What we dothe work

    We upgrade React Native step by step on a branch, and replace or fork the native module nobody maintains. targetSdkVersion moves to 36 and we fix the behavior changes that come with it, edge-to-edge display among them. If it won't land by 1 November 2026 we ask for the Play extension. The iOS target gets rebuilt on Xcode 26.

  3. Afterwhere you end up

    Both stores accept updates again. Next year's SDK changes are on a calendar, so the team isn't learning about them at upload time.

case file 02

Backend API key sitting in a field-service app's resources

composite · not a client story
  1. Beforethe situation

    A field-service app ships with a backend API key in its string resources. Anyone with apktool can extract it, and the key can read every customer's job history.

  2. What we dothe work

    Rotate the key today and put a temporary rate limit in front of it. Then move sign-in to OAuth with PKCE in the system browser and require a user token on every endpoint, with the server checking who owns each record. Play Integrity and App Attest verdicts become an extra signal on sensitive calls.

  3. Afterwhere you end up

    There's nothing in the binary worth pulling out any more. The backend knows who is calling and returns only that user's records. Scripted scraping also gets easier to spot.

case file 03

Native SDKs that don't support 16 KB page sizes

composite · not a client story
  1. Beforethe situation

    The Android app bundles a third-party video SDK and an older crypto library. Play Console warns that it doesn't support 16 KB memory page sizes. From 1 February 2027, updates without that support can't be released.

  2. What we dothe work

    Play Console warnings and APK Analyzer show which .so files are unaligned. Where an SDK vendor has a 16 KB build, we update to it. In-house native code is rebuilt with a current NDK, and the app is tested on a 16 KB emulator image before submission.

  3. Afterwhere you end up

    Updates still reach Google Play after February 2027. If an SDK vendor has no 16 KB build, you find out early enough to replace it.

case studies

Mobile Development case studies

All case studies
architecture

How a mobile app signs in and talks to your backend

Users go from the app to the identity platform in the system browser, over OAuth with PKCE, and the tokens then stay in the Keychain or Android Keystore. The backend accepts scoped user tokens plus App Attest or Play Integrity signals, and nothing else.

How a mobile app signs in and talks to your backend Users go from the app to the identity platform in the system browser, over OAuth with PKCE, and the tokens then stay in the Keychain or Android Keystore. The backend accepts scoped user tokens plus App Attest or Play Integrity signals, and nothing else. 01 · DEVICE 02 · IDENTITY 03 · BACKEND 04 · RELEASE OAuth with PKCE refresh token access token integrity verdict scoped call staged rollout Mobile app Swift · Kotlin · ReactNative Secure storage Keychain · AndroidKeystore App integrity App Attest · PlayIntegrity Identity platform Auth0 · Okta · EntraID Mobile API token validation · ratelimits Sf CRM Salesforce Build and signing CI · TestFlight · Playtesting
Read the diagram as text
  1. Mobile app → Identity platform: OAuth with PKCE
  2. Identity platform → Secure storage: refresh token
  3. Mobile app → Mobile API: access token
  4. App integrity → Mobile API: integrity verdict
  5. Mobile API → CRM: scoped call
  6. Build and signing → Mobile app: staged rollout
how it runs

A typical engagement

We don't start a step until the last one has produced something you can check.

  1. step 01

    Discovery

    Users, offline needs, device features, backend APIs and the identity provider confirmed before design.

  2. step 02

    Design

    Platform-appropriate designs tested with VoiceOver, TalkBack and large text sizes.

  3. step 03

    Build and beta

    Short iterations shipped to testers through TestFlight and Play testing tracks.

  4. step 04

    Release and maintain

    Store submission, staged rollout, then a yearly plan for SDK and target API changes.

you keep

What you're left with

We write these for your Mobile Development setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.

  • code01

    App source code with CI build and signing pipeline

    yours to keep
  • document02

    Store listings, privacy disclosures and submission support

    yours to keep
  • design03

    Mobile identity integration and token storage design

    yours to keep
  • tests04

    Accessibility test results for iOS and Android

    yours to keep
  • plan05

    Yearly platform requirements calendar

    yours to keep
talent and delivery · mobile development

Certified engineers, wherever you need them.

Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.

Onsite

Engineers at your sites in the US

Nearshore

Overlapping hours with US teams

Offshore

Overnight progress on your backlog

All time zones

Coverage handed over across time zones

24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
roles we staff
  • iOS developer (Swift)
  • Android developer (Kotlin)
  • React Native or Flutter developer
  • Mobile identity engineer
  • Mobile QA engineer
01Should we build native or cross-platform?

It depends on device features, performance needs and who'll maintain the app. Cross-platform saves effort on apps that are mostly forms. Native is the safer choice for camera, Bluetooth, background processing or heavy graphics. We decide app by app, not as a company-wide rule.

02Google Play says our app must target a newer API level. What happens if we wait?

From 31 August 2026, you can't submit new apps or updates that target below API level 36 unless you have an extension, which runs to 1 November 2026. Existing apps must target at least API level 35 to stay available to new users on newer Android versions.

03How much does a mobile app cost?

Cost mostly comes down to how many backend integrations you have, what has to work offline, which device features you need and whether both platforms ship at launch. After launch there's the yearly round of SDK and store-policy updates, and you can't skip it.

04Can you take over an app another team built?

Yes. We start by building it from a clean machine, checking signing keys and store access, and reviewing how it stores tokens and secrets.

05Do you build internal apps for employees as well as customer apps?

Yes. Internal apps usually sign in through Entra ID or Okta, run under Intune or another MDM platform, and need app protection policies. Store rules still apply unless you distribute the app privately.

related

Often paired with

Projects on Mobile Development usually end up touching one of these, so they're worth a look.

sources 6 sources linked last checked 2026-10-20 content fingerprint d8356c06
  1. 01Apple Developer: Upcoming requirementsdeveloper.apple.com ↗
  2. 02Android Developers: Target API level requirementsdeveloper.android.com ↗
  3. 03IETF RFC 8252: OAuth 2.0 for Native Appsdatatracker.ietf.org ↗
  4. 04Apple Developer: Establishing your app's integrity (App Attest)developer.apple.com ↗
  5. 05Android Developers: Play Integrity APIdeveloper.android.com ↗
  6. 06Android Developers: Support 16 KB page sizesdeveloper.android.com ↗
Reviewed by the Cohash team Product names are trademarks of their owners. how we handle facts and data →
next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it