App Development Services

Native, Flutter, React Native or Kotlin Multiplatform

This is the first real decision and the one most likely to be made for the wrong reasons. Here is how we actually choose, with the current state of each.

• Native (Swift and SwiftUI, Kotlin and Jetpack Compose) — best performance, immediate access to new OS features, and the only sensible choice when the app leans heavily on the camera, on-device machine learning, background processing or platform-specific hardware. Costs the most because you build twice.
• Flutter — one codebase, pixel-identical UI across platforms, and the largest community by app count. The right pick for design-heavy products where the interface should look the same everywhere rather than native to each platform.
• React Native — now running its New Architecture by default, with Expo as the standard toolchain. Strongest when you already have a React and TypeScript web team, because the same people can build the app. Appfigures found it in more of the top 10,000 iOS apps than Flutter as of late 2025.
• Kotlin Multiplatform — the genuinely interesting 2026 option. Share business logic, networking and persistence while keeping fully native UI on each platform. Present in only 218 of the top 10,000 iOS apps but carrying 27% of the revenue among cross-platform frameworks, because it skews towards enterprise and fintech products where the UI has to feel native and the logic must not be duplicated.

The store deadlines nobody tells you about until they bite

Both app stores impose hard compliance dates every year. Miss one and your app cannot be updated, which for a business-critical product is an outage you cannot fix quickly.

Google Play requires new apps and updates to target Android 16 (API 36) or higher from 31 August 2026, with extensions available to 1 November. Existing apps must target at least API 35 to remain available to new users on newer devices. Separately — and this one is genuinely new — Android now requires developer identity verification for apps installed on certified devices, including sideloaded apps and apps from other stores. Regional enforcement began in Brazil, Indonesia, Singapore and Thailand from 30 September 2026, with global rollout following.

Apple has required since 28 April 2026 that apps uploaded to App Store Connect are built with Xcode 26 or later using the iOS 26 SDK. The age rating questionnaire was rebuilt with new 13+, 16+ and 18+ tiers that had to be answered by 31 January 2026. The November 2025 App Review Guidelines update added a requirement that is easy to miss: you must clearly disclose where personal data is shared with third parties including third-party AI services, and get explicit permission first. If your app calls an LLM API, that clause applies to you.

We maintain a compliance calendar for every app we run and handle these upgrades as routine maintenance rather than emergencies.

Why apps get rejected, and how we avoid it

App review rejection is usually not a judgement on your product. It is nearly always one of a short list of avoidable mistakes, and each one costs a review cycle.

Demo credentials that do not work, or a login wall with no way for a reviewer to get past it. Placeholder content still in the build. No privacy policy accessible inside the app. User-generated content with no way to report, block or moderate. Subscriptions that do not clearly state what is included before purchase. And guideline 4.3 — an app too similar to something already on the store, which catches template-built apps constantly.

Our submission checklist covers all of these before the build goes anywhere near review, along with privacy manifests and Required Reason API declarations, the Data Safety form for Play, App Tracking Transparency where relevant, in-app account deletion (required by both stores), and EU trader status if you are distributing in Europe.

Security and data protection, including India's new rules

We build against the OWASP Mobile Application Security Verification Standard — the industry framework covering storage, cryptography, authentication, network security, platform interaction, code quality, resilience and privacy. In practice that means certificate pinning, secrets in the platform keystore or keychain rather than in the binary, biometric authentication where it fits, proper token rotation, and auditing every third-party SDK you ship, because each one is code you did not write running with your app's permissions.

For anything touching Indian users, the Digital Personal Data Protection Rules were finalised in November 2025 and the timeline is now firm: the Consent Manager framework becomes operational on 13 November 2026, with full compliance required by 13 May 2027. The obligations are concrete — privacy notices and consent capture, breach notification to the Data Protection Board within 72 hours, documented security safeguards and logs, processor agreements, grievance resolution within 90 days, verifiable parental consent for under-18s, and deletion once the purpose is complete.

The penalties are not nominal: up to ₹250 crore for failing to maintain reasonable security safeguards, ₹200 crore for breach-notification failures or violations involving minors. And the Act applies extraterritorially — if you process the personal data of people in India, it applies regardless of where your company sits.

What happens after launch, and what it costs

An app is not finished when it ships. Both platforms release a major OS version annually, SDKs get deprecated, store policies change, dependencies accumulate security advisories, and crash reports arrive from device and OS combinations you never tested on.

The industry planning figure is 15–25% of the original build cost per year for maintenance, and that is a realistic number rather than a padded one. It covers OS compatibility work, the annual store policy deadlines, crash and ANR monitoring, dependency patching, server and cloud costs, and the feature iteration that actually retains users.

Budgeting a build without budgeting maintenance is the most common way an app dies quietly eighteen months after launch — not from failure, but from being allowed to rot until it stops passing review.

App Store Optimisation: the part most developers ignore

Building an app nobody can find is an expensive way to learn about ASO. Store search is where the majority of organic installs come from, and the metadata fields are strictly limited: on Apple, a 30-character app name, a 30-character subtitle and a hidden 100-character keyword field; on Google Play, a 30-character title, an 80-character short description and a 4,000-character long description that is indexed, unlike Apple's.

Two 2025 changes are worth knowing. Apple began OCR-indexing the caption text inside your screenshots in June 2025, which turned screenshot copy into a ranking surface. And Custom Product Pages — up to 70 variants — now rank organically for their assigned keywords, which makes them a genuine acquisition channel rather than just an ad landing page.

Beyond metadata, both stores weight behaviour heavily: download velocity, store listing conversion rate, rating and review velocity, and retention at day 1, 7 and 30. Google Play has shifted noticeably from install volume towards retention and engagement, and Android Vitals — crash rate, ANR rate, startup time — now carries real weight. Which means technical quality is an ASO input, not just an engineering concern.