Mobile App Development

Mobile app development is the process of designing, building, releasing and maintaining an application for iOS and Android, including the backend it depends on and the release pipeline that gets updates to users. The build is the visible part; the scoping before it and the maintenance after it determine whether the app is still useful in two years.

Moon Workshop builds mobile applications from Antalya, Türkiye, for clients in Türkiye and in international markets including Germany, the United Kingdom, the Netherlands and the United States.

Start by deciding what version one is not

Most failed app projects are not failures of engineering. They are failures of scope. A feature list assembled from every stakeholder request produces a product that takes a year, launches without analytics, and cannot be improved because nobody knows which feature mattered.

Our scoping produces two documents: what version one does, and what it deliberately does not do. The second is the more useful one. It converts “we might add that later” into a written decision that stops re-entering the sprint.

We ask three questions before estimating:

1. What specific problem does this app solve that a mobile website cannot?
2. Who opens it, how often, and what do they do in the first thirty seconds?
3. How will we know within eight weeks of launch whether it works?

If the first question has no clear answer, a responsive web application is often the better and cheaper product, and we will say so.

Choosing the technology

For the majority of business applications, a cross-platform build keeps both platforms feature-identical and halves the maintenance surface. We use native modules where a specific capability requires it rather than rewriting the whole application.

Design to platform conventions, not to one mockup

iOS and Android users have different expectations for navigation, back behavior, sharing, permissions and typography. An app that ignores those conventions feels wrong in a way users cannot articulate but do abandon.

Our design work includes navigation patterns appropriate to each platform, complete state coverage — loading, empty, error, offline, permission-denied — and accessibility requirements such as dynamic type support, contrast and touch target sizing.

Handling connectivity honestly

Mobile means intermittent connectivity. We define per screen what happens when the network is unavailable: which data is cached, which actions queue for later, and what the user is told. Apps that show an infinite spinner on a weak connection get uninstalled.

Backend, security and data

The app is usually the smaller half of the system. We design the API around what the app actually needs rather than exposing an existing database structure, which keeps payloads small and screens fast.

Standard practice on our builds:

• Token-based authentication with proper refresh and revocation
• Secure storage using platform keychain and keystore for credentials
• Certificate handling and transport security configured correctly
• Push notification infrastructure with topic and segment support
• Account deletion flows, which both stores now require for apps with accounts
• Privacy declarations that match what the app genuinely collects

Analytics from version one

Shipping without analytics means the next version is guesswork. Before release we define the questions the product team needs answered — activation, retention, feature adoption, drop-off points — and instrument events that answer them.

We also monitor crash-free session rate, cold start time, screen render performance and API error rates. These are engineering metrics with direct product consequences: an app that takes four seconds to open loses users regardless of its features.

Store release is a process, not an event

Both App Store Connect and Google Play Console apply review policies that reject submissions regularly. Common causes include incomplete privacy disclosures, missing account deletion paths, payment handling that bypasses store rules, and screenshots that do not represent the app.

We prepare for review criteria during development rather than at submission, and we use staged rollout on Android and phased release on iOS so that a problem affecting a subset of devices is caught before it reaches everyone.

Maintenance is not optional

Even with no new features, mobile applications require periodic work: annual operating system releases, deprecated APIs, dependency and security updates, certificate and provisioning renewals, and store policy changes. An app left untouched for eighteen months typically needs substantial work before it can ship a small change.

We agree a maintenance scope at handover so this is budgeted rather than encountered as a surprise. You own the source code, the store accounts and the signing credentials, and the handover documentation is written so another team could take over if you chose to.

Last updated: August 2026.