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.
Mobile appSwift · Kotlin · React NativeSecure storageKeychain · Android KeystoreApp integrityApp Attest · Play Integrity
02 · Identity
Identity platformAuth0 · Okta · Entra ID
03 · Backend
Mobile APItoken validation · rate limitsCRMSalesforce
04 · Release
Build and signingCI · TestFlight · Play testing
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.
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.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · mobile development3 open
openThe app has an API key compiled into the binary and anyone can pull it out.
recurringA store deadline for a new SDK or target API level is coming and the build won't compile.
blockedTwo separate teams maintain iOS and Android apps that drift apart feature by feature.
exposure
Native or cross-platform…Store compliance calendarMobile sign-inBackends that assume the app is…Release pipelines
startrehearsehandover
Discovery
Design
Build and beta
Release and maintain
we are here
ready to hand over
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
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.
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
chapter 03 · how it runs
Our approach
Discovery
Design
Build and beta
Release and maintain
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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
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.
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.
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
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.
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.
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.
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 backendUsers 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 · DEVICE02 · IDENTITY03 · BACKEND04 · RELEASEOAuth with PKCErefresh tokenaccess tokenintegrity verdictscoped callstaged rolloutMobile appSwift · Kotlin · ReactNativeSecure storageKeychain · AndroidKeystoreApp integrityApp Attest · PlayIntegrityIdentity platformAuth0 · Okta · EntraIDMobile APItoken validation · ratelimitsSfCRMSalesforceBuild and signingCI · TestFlight · Playtesting
01 · Device
Mobile appSwift · Kotlin · React Native → Identity platform · OAuth with PKCE→ Mobile API · access token
Secure storageKeychain · Android Keystore
App integrityApp Attest · Play Integrity → Mobile API · integrity verdict
Build and signingCI · TestFlight · Play testing → Mobile app · staged rollout
Read the diagram as text
Mobile app → Identity platform: OAuth with PKCE
Identity platform → Secure storage: refresh token
Mobile app → Mobile API: access token
App integrity → Mobile API: integrity verdict
Mobile API → CRM: scoped call
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.
step 01
Discovery
Users, offline needs, device features, backend APIs and the identity provider confirmed before design.
step 02
Design
Platform-appropriate designs tested with VoiceOver, TalkBack and large text sizes.
step 03
Build and beta
Short iterations shipped to testers through TestFlight and Play testing tracks.
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
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
00:0006:0012:0018:0000:00
roles we staff
iOS developer (Swift)
Android developer (Kotlin)
React Native or Flutter developer
Mobile identity engineer
Mobile QA engineer
due diligence · mobile development
Questions to ask any partner, including us.
Put these to anyone bidding on your Mobile Development work. The ones who've done it answer differently from the ones who've read about it.
Q1
Who will hold the signing keys and the App Store and Play Console accounts?
If the upload key or Apple distribution certificate sits with the partner, you can't ship without them. Keys and store accounts should be yours, with the partner added as a user.
Q2
Which native libraries in our app still lack a 16 KB page size build?
From 1 February 2027, Google Play blocks updates without 16 KB support for apps targeting Android 15 and higher. Third-party native libraries are usually the blocker.
Q3
How will the app sign users in, and where will refresh tokens be stored?
Embedded web views and passwords typed into native screens bypass the identity provider's protections. RFC 8252 recommends the system browser with PKCE, and tokens belong in the Keychain or Keystore.
Q4
What does a staged rollout look like, and who has authority to halt it?
Play staged rollouts and App Store phased releases limit the damage from a bad build. Someone needs crash thresholds and the authority to pause.
Q5
What is budgeted for next year's store requirements?
Apple and Google change SDK and target API rules every year. Leave that out of the maintenance budget and one day the app can't ship an update.
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.