Yaamlabs
Engineering and AI

Mobile App Development

iOS and Android apps, native or cross-platform, built on the assumption that the device is hostile and the client will be tampered with. Released under your store accounts, not ours.

A mobile app runs on hardware you do not control, often offline, in the hands of anyone who can download it. The binary can be unpacked, the traffic intercepted and the local database copied off a rooted phone. Meanwhile the release itself depends on signing keys, store accounts and review queues that can end up tied to one developer's laptop. Both problems are cheaper to design out than to fix after launch.

We choose native or cross-platform per product, based on what the app needs from the device, not on habit. Secrets stay off the client, sensitive data goes into the Keychain or Keystore, and the backend treats every request as if the app has been modified. Signing, builds and store submission run from a pipeline under your accounts. Before release, the team that runs our mobile penetration tests puts the build on rooted and jailbroken devices.

Usually, one of these is true

  • You have a web product and customers are asking for an app that works offline, sends push notifications or uses the camera.
  • An existing app was built by a contractor, and the signing keys, store accounts or build process are not fully under your control.
  • Your app will handle payments, health records or identity documents, and a partner's security review expects it to meet OWASP MASVS.
  • You are deciding between native and cross-platform and want the trade-off argued against your own feature list rather than in general.

What we build

The app, the parts of the backend it depends on, and the release machinery around it. Each area is built with the mobile threat model in view: a lost phone, a modified binary, an intercepted session.

  • Native and cross-platform. Swift and Kotlin where the app leans on platform APIs or performance, and a cross-platform option such as React Native, Flutter or Kotlin Multiplatform where shared code genuinely fits.
  • Offline and sync. Local persistence, a sync model decided before the screens are built, conflict handling, and what the app shows when the network drops mid-action.
  • On-device data. Keychain and Keystore for credentials, encrypted storage where the threat model calls for it, and nothing sensitive left in logs, caches, screenshots or backups.
  • Auth and the mobile API. OAuth 2.0 with PKCE, token refresh and revocation, and an API that enforces authorisation on the server because the client cannot be trusted to.
  • Push, links and platform services. Notifications, universal and app links, in-app purchases and permission prompts, each with its abuse case considered: a crafted link, a spoofed payload, a replayed receipt.
  • Release engineering. Signing and provisioning, CI builds, TestFlight and Play testing tracks, staged rollouts, crash reporting, and a forced-update path for the day a version has to be retired.

How the build runs

We scope it with you in the chat, then send a written scope with a fixed price and fixed dates. Test builds reach your own phones throughout the build, not only at the end.

  1. Discovery. We work through the user flows, the device capabilities they need, offline requirements and the backend the app talks to, and settle native or cross-platform in writing.
  2. Threat model. We decide what is stored on the device and what never is, how sessions are issued and revoked, and which controls, such as pinning or tamper detection, the risk actually justifies.
  3. Incremental builds. Features land in small increments with unit and UI tests, and each merge produces a signed build on your internal testing tracks to try on real devices.
  4. Security test pass. Before store submission, the build is tested on rooted and jailbroken devices: local storage, transport, deep links, the binary itself and the API behind it. Findings are fixed and verified before release.
  5. Release and handover. We submit under your developer accounts, stage the rollout, and hand over the pipeline, the signing setup and the runbooks so your team can ship the next version without us.

What you get

  • iOS and Android apps. Source code with full history in your repositories, published under your own Apple and Google developer accounts.
  • Release pipeline. CI that builds, signs and uploads to the testing tracks and stores, with signing keys held in your accounts rather than on anyone's laptop.
  • Security test pass report. Pre-release findings mapped to OWASP MASVS, each with a working reproduction, a CWE mapping, a CVSS v4.0 rating and a note of the fix.
  • Mobile API documentation. Reference for the endpoints the app depends on, including authentication, versioning and how older app versions are supported or cut off.
  • Release runbook. Step-by-step instructions for cutting a release, answering a store rejection, renewing certificates and pulling a broken version, for whoever ships next.

What we need from you

  • Apple Developer Program and Google Play Console accounts in your organisation's name, with us added under roles you control.
  • Designs or wireframes if you have them, or a product owner who can decide on flows as they are built.
  • Access to the backend and its API documentation, or a decision that the backend is built as part of the scope.
  • Staff or customers willing to install test builds on their own phones and report what breaks.
  • Your privacy policy, data handling rules and any regulatory constraints on what the app may store or collect.

What we can show you

  • We test mobile apps too. The same team runs mobile penetration tests on rooted and jailbroken hardware and has published 70+ CVEs, so storage, pinning and deep-link handling are built by people who bypass them elsewhere.
  • Store accounts stay yours. Apps ship under your developer accounts with signing keys you hold. You own the code and the release process outright, with no lock-in to us.
  • Pre-release test included. Every app gets a security test pass before store submission, and every finding is reproduced, mapped to CWE and rated with CVSS v4.0.
  • One team, app to API. The app, its API and the cloud behind it are built and tested by one team, so a finding in any layer can become a fix without a hand-over.

Standards we work to

The mobile security standards and store policies the app is built and checked against, so a partner's review or a store rejection has a documented answer.

  • OWASP MASVS
  • OWASP MASTG
  • OWASP Mobile Top 10
  • WCAG 2.2 AA
  • App Store Review Guidelines
  • Google Play Developer Program Policies

Common questions

Native or cross-platform?

It depends on the app. Heavy use of platform APIs, background work, Bluetooth or media usually points to native Swift and Kotlin. A forms-and-data app with a small team to maintain it often suits a cross-platform framework such as React Native, Flutter or Kotlin Multiplatform. We write the recommendation against your feature list, including what it means for hiring and maintenance.

Whose developer accounts do the apps go under?

Yours. We ask you to create the Apple and Google accounts in your organisation's name and add us with limited roles. Signing keys and certificates live in your accounts, and our access is removed at handover.

Do you handle App Store and Google Play submission?

Yes, including store listings, privacy declarations, review notes and test credentials for the reviewers. If a review is rejected, we address the reason and resubmit. We cannot control review outcomes or queue times, so release dates are planned with room for a resubmission.

Do we need certificate pinning, jailbreak detection and obfuscation?

Not by default. They add maintenance cost and can lock out legitimate users, so we recommend them where the threat model justifies it, for example in a payments or banking app. What every app gets is server-side authorisation, secure storage and no secrets in the binary, because those still hold when client-side controls are bypassed.

What happens after the app is live?

Your team gets the code, the pipeline and a release runbook, and can ship updates without us. New operating system versions and store policy changes will need attention over time, and the runbook says where to look. If you want us to keep shipping or reviewing releases, we scope that separately.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.