Mobile App Development: Decide Before You Build

Key takeaways

• The native vs cross-platform choice is decided on your key features — scanning, offline, real-time — not on ideology.
• An app is justified by mobile capabilities: stores, push, offline, hardware. Otherwise a web application is often enough.
• The number that matters is not the quote but the total cost of ownership: OS updates, stores and maintenance are part of the budget.
• Publication is not a detail: guidelines, Apple and Google review, compliance — it is prepared from design onwards.
• Ownership — code, repositories, developer accounts — must sit with you from day one.

In short: a successful mobile project starts with an honest relevance question, is priced in TCO, picks its technology on functional criteria, and plans its post-launch life before the first line of code. The rest of this page unfolds those decisions in the order you will meet them.

Table of contents

• Native or cross-platform: the real question
• When a mobile app is justified
• When you should not build an app
• Native, cross-platform, PWA: the comparison
• Cost and total cost of ownership
• App-store publication
• Maintenance and OS updates
• Security and data
• Five questions to ask before signing
• Three apps, three usages
• FAQ

Native or cross-platform: the real question

Cross-platform — React Native, Flutter — writes one codebase for iOS and Android: shorter timelines, a shared budget, synchronized evolutions. Native — Swift on iOS, Kotlin on Android — speaks each platform's language directly: maximum performance, full hardware access, pixel-perfect experience.

The right question is not "which is better?" but "what do your key features demand?". Three signals push toward native: intensive hardware use (scanning, camera, sensors), a true offline mode, and demanding real-time. For the majority of business and consumer apps, cross-platform delivers the essentials for a fraction of the effort — it is the default of our mobile development offer, with native as the tool for the cases that earn it. Between the two frameworks themselves, the choice is decided by your team and your key features — our React Native vs Flutter comparison walks through the criteria.

The choice is not final at product level: an app can be born cross-platform to validate its market, then migrate critical modules to native. The reverse — going native "to be safe" — costs two codebases from day one.

When a mobile app is justified

An app is not a modernity badge: it is a channel that must be earned. It is justified when your usage needs capabilities only mobile offers:

• Your users come back several times a week — the home-screen icon is a shortcut that matters.
• The service lives on push notifications: bookings, order statuses, business alerts.
• The field demands offline: warehouses, construction sites, dead zones.
• The hardware is the service: camera, scanning, continuous geolocation, in-app payment.
• Store presence is an acquisition channel or a client requirement.

FlySpa is the textbook case: a treatment-booking platform whose recurring usage, integrated payment and notifications fully justify the app — we built and then operated it as a product, not a deliverable.

There is a second, often overlooked scenario: the app that already exists. An orphaned application — the agency is gone, the codebase is stale, updates get rejected — is a justified project in its own right. Taking over an existing app starts with a technical audit of the code and its dependencies, then stabilization, then a progressive rebuild where it pays off. It is usually far cheaper than the reflex rewrite, and it protects the store presence and the installed base you already earned.

When you should not build an app

Commercial honesty requires saying it: many app projects should be web applications. Three counter-indications come up constantly.

Usage is occasional. A user who visits once a quarter does not download an app — or deletes it at the first cleanup. A mobile-first site or a web application serves them better, without installation friction.

No mobile capability is required. No push, no offline, no hardware: the app brings only costs — double publication, store reviews, OS maintenance — with no experience benefit.

The budget only covers V1. An app lives at the pace of iOS and Android: without a maintenance budget it degrades until updates get rejected. Better a smaller, living scope than a complete, orphaned app.

Native, cross-platform, PWA: the comparison

These options combine: many products live well with a cross-platform app for recurring users and a polished mobile web for everyone else.

Cost and total cost of ownership

Ranges first: on our service page, published packages start at CHF 29,900 for a tight MVP, CHF 59,900 for a complete application and CHF 99,900 for a complex custom project — the firm number always comes out of scoping, on the real perimeter. Our mobile app cost guide details every factor and the full calculation.

But the quote is only the start of the story. A mobile app's total cost of ownership includes what is specific to mobile: iOS and Android version upgrades, continuous store compliance, fixes on real devices, and product evolutions. The TCO reasoning we detail for custom development applies to mobile with one extra factor: you control neither Apple's pace nor Google's.

Five factors move the number: screens and journeys, native features (payment, scanning, offline, real-time), the back office and integrations with your systems, the expected level of polish, and the real-device testing strategy.

One practical rule keeps mobile budgets honest: demand installable builds every week. A build you can put in testers' hands compresses the feedback loop, exposes device issues early — screen sizes, permissions, performance on older phones — and turns the budget conversation into something you can see. Projects that surface only at the end are where mobile overruns hide.

App-store publication

Publishing is not clicking "submit". The App Store and Google Play enforce guidelines — privacy, purchases, content, permissions — and a review that can reject an app over one poorly justified screen. It is prepared from design onwards: permission choices, privacy texts, store listings, screenshots, compliance.

At PULSE, store release is part of the project: listing preparation, submission, Apple and Google review follow-up, iterations if needed — on your developer accounts, in your name. The store presence belongs to you just like the code.

Maintenance and OS updates

A mobile application is never "done": iOS and Android evolve every year, APIs get deprecated, store requirements tighten. Without maintenance, an app accumulates warnings, then rejected updates — and the initial investment quietly degrades.

That is why post-launch support is part of the offer: fixes, version upgrades, crash monitoring, adaptation to new OS releases. For platforms where the app is only one part — back office, APIs, data — managed operations complete the picture server-side.

Security and data

An app usually carries personal data and talks to APIs: security is designed in, not bolted on. Robust authentication, encryption in transit and at rest, fine-grained permissions, controlled local storage — and on compliance, the Swiss nFADP and GDPR require knowing what is collected, where, and how it is erased. The stores check too: Apple's and Google's privacy labels commit to what your app actually does — a mismatch between the label and the app's behaviour is grounds for rejection, so the privacy answer has to be engineered, not written after the fact.

Five questions to ask before signing

• "Native or cross-platform — and why for my case?" — the answer must cite your key features, not a workshop preference.
• "Who owns the code and the developer accounts?" — you, contractually, from day one.
• "How do you test?" — on real devices, not just simulators; installable builds every week.
• "Who handles store review, and what happens on rejection?" — publication must be the supplier's responsibility, not yours.
• "What does year two cost?" — a quote without maintenance and OS upgrades sells a V1, not an application.

These questions apply to all custom development — our software decision guide goes deeper — but on mobile, platform dependency makes them non-negotiable.

Three apps, three usages

FlySpa is the product app: at-home treatment booking, integrated payment, a fluid journey — built and then operated over time, with the SaaS platform behind it.

RM26 is the audience app: the official Riyad Mahrez application, where brand experience and fan engagement drive the choices — rich content, real-time, robustness under peaks.

Migros Vaud is the event app: a 75th-anniversary application with high traffic over a short window — a case where reliability under load and journey simplicity outrank everything else.

Frequently asked questions