support@aleksamiskovic.com
Aleksa MiskovicAleksa.
HomeAboutServicesSolutionsPortalContact
Get a Quote
Services/Mobile Applications
Service · Mobile Applications

iOS and Android, in production.

Native iOS in Swift, native Android in Kotlin. Built for the platform, not flattened across it. Offline-first sync, push, in-app purchase, store submission. Kickoff through a real binary in real users' hands on a timeline scoped to the build.

Book a callSee an example
The stack

The stack.

Swift with SwiftUI for iOS, Kotlin with Jetpack Compose for Android. Native everywhere — no bridge layer, no cross-platform compromises. Each codebase reads like the platform it targets, with full access to system APIs and animation primitives.

Backend in Node or Python with Postgres. Push via APNs and FCM, payments through native IAP and RevenueCat, auth through whatever you already use. Sentry for crashes on each platform.

The process

Five phases,
planning to handoff.

01

Discovery & Scoping

We open with a working session covering the three things that decide a mobile build: who the user is on the bus, what they will do offline, and which platform pays the bills first. Most apps do not need feature parity at launch, and we say so out loud.

We map the device matrix you actually need to support (not the one marketing wishes you supported), the integrations the app must speak to (auth, payments, push, analytics, in-app purchase), and the store-listing constraints that will shape your schedule. App Store and Play Store reviews are a real timeline risk and we plan around them, not against them.

Phase ends with a fixed-fee SOW, a written scope, and a clear MVP cut. We are blunt about what gets shipped on day one and what waits for v1.1. Your CFO will thank us.

Deliverables

  • Signed SOW with fixed fee and timeline
  • MVP cut and v1.1 backlog
  • Device matrix (iOS versions, Android versions, screen sizes)
  • Store-readiness checklist (developer accounts, certificates, privacy policy)
02

Architecture & Design

We commit to native: Swift for iOS, Kotlin for Android. Two codebases, one team, full access to platform APIs and the performance ceiling each platform offers. No cross-platform bridge, no shared abstraction layer that fights you when a feature lands on one OS first.

Design covers iOS and Android side by side. Platform conventions are honored, not flattened: a sheet behaves like a sheet on iOS and like a bottom sheet on Android, navigation respects each platform's back-gesture model, and typography uses each system's text-size accessibility setting.

Engineering produces an architecture spec covering state management, offline-first sync strategy, push topology, deep linking, and the in-app purchase flow on each platform. Decisions get written down with the why.

Deliverables

  • Architecture spec per platform: state, sync, push, deep links, IAP
  • Performance and accessibility budgets per platform
03

Build

Build runs in regular sprints with a TestFlight build at the end of every one and an internal-track Play build alongside it. Your stakeholders install over the air, use the app on their commute, and send feedback through a single email thread.

Every pull request runs through CI: build, lint, and unit tests on each platform. Smoke flows are checked manually on a real device before each TestFlight build. We ship behind feature flags so risky work can land in main without going live, and we keep native binary sizes monitored every build. Bloat is easier to prevent than to remove.

The team works trunk-based. Code review is mandatory, and at least one engineer on the team has shipped to the App Store before. The phrase "that fails review" gets caught in the pull request, not the submission.

Deliverables

  • Weekly TestFlight and Play internal-track builds
  • Sprint changelog and demo
  • CI pipeline: build, lint, unit tests on each platform
  • Native binary size dashboards
04

Testing & QA

Automated tests cover unit logic on both platforms. End-to-end flows are checked manually on real hardware for every release candidate. We hit the slow paths intentionally: cold start on a budget Android, network drop mid-sync, push received in the background, deep link from email while the app is killed.

Manual QA runs on real devices, not simulators. The matrix includes the oldest supported iOS, the newest, a flagship Android, a mid-tier Android (where most of your users actually are), and the worst-network city your users live in. Battery, memory, and frame-rate budgets are checked on hardware before we sign the build off.

Pre-submission, we run through the Apple and Google review checklists line by line: privacy manifest, data-collection disclosures, in-app purchase compliance, rights to logos and content, and the dreaded background-mode justifications. We fix what would fail review before the binary leaves CI.

Deliverables

  • Unit test suite on both platforms, with manual end-to-end QA
  • Real-device QA matrix with battery, memory, frame rate
  • Privacy manifest and data-collection audit
  • App Store and Play Store pre-submission checklist signed off
05

Launch & Handoff

We submit to TestFlight and Play internal track, then to App Store and Play production. Reviews land, sometimes with notes. We have an engineer on call to respond same-day during review windows, because a single back-and-forth can cost a week.

On launch, monitoring is already wired: Sentry for native crashes on each platform, plus a real-user performance feed (cold-start time, frame drops, network-failure rate). For urgent fixes between store releases, we ship through the App Store and Play Store expedited review paths.

Operational handoff covers store listings, signing certificates, and the credentials your team needs day to day. We continue to own and maintain the code, ship updates, and respond to defects. The 30-day post-launch warranty covers any defect against spec at no charge.

Deliverables

  • App Store and Play Store live, listings reviewed
  • Crash reporting and performance monitoring on each platform
  • Signing and store-credentials runbook
  • 30-day post-launch warranty

Typical timeframe

Custom to scope

MVP through App Store and Play Store live.

Build cost

Free

We don't charge for the build.

Monthly maintenance

Subscription

You pay a monthly fee while we keep both platforms shipping.

Frequently asked

Real questions,
answered straight.

Who owns the code?

We do, as the agency. Both repositories sit in our organisation and we maintain the codebases long-term. Your Apple and Google developer accounts and store listings stay in your business entity's name; we manage signing certificates and release submissions on your behalf.

What if we don't have designs?

Common case. Our designer produces the iOS and Android designs as part of the engagement, working from your brand if it exists or building one if it does not. We default to platform-native conventions and only diverge when the brand demands it.

Can you take over an existing app?

Often, yes. We start with a paid one-week audit: codebase read, crash-report review, dependency and platform-deprecation audit, and a written assessment of what to keep, refactor, or rewrite. We are honest when a rewrite is cheaper than a rescue, and we say so on the report.

Do you offer maintenance?

Yes. After the 30-day warranty, you move to a monthly retainer covering OS-version upgrades (iOS and Android both ship yearly), dependency patches, store-policy changes, crash triage, and a fixed bucket of feature work. Mobile platforms shift under your feet, and a retainer keeps the app shipping cleanly.

Ready to ship?

Bring a rough brief or a half-built prototype. Real engineers on the call, no account managers.