Practice 03 · Web, software & digital solutionsMobile app development: an app people open again

An app downloads in seconds and is forgotten just as fast. Between installation and regular use lies a promise kept: a service the phone delivers better than the mobile site does. Before any development, the question to ask is whether there is a recurring use, and then which phone features that use depends on.

Get an estimate for my mobile app

Feasibility and an order of magnitude within 48 hours

See the practice
Web & software illustration: a kopus.net browser window with an interface mock-up and code

Our positionWhy we first check that an app is needed

A well-designed responsive site covers a large share of needs, and it requires neither a download nor store approval. So we begin by checking whether an app is genuinely necessary. It becomes so when a repeated use draws on the phone: notifications, camera, offline mode, speed of access. Building an app simply to exist on the stores, with no recurring use behind it, produces an icon that users delete the first time they tidy their home screen.

Who it is for, and whenWhen a mobile app has a place

Mobile projects that last start from a repeated gesture, not from a wish to be present on the app stores.

  • Your users perform a frequent action, often on the move: taking readings, photographing, signing, clocking in, ordering, checking a balance.
  • The service needs the phone itself: camera, geolocation, notifications, code scanning, Bluetooth connection to a device, offline work.
  • Your technicians, drivers or sales reps fill in paper forms or emails from the field, and the information arrives late and incomplete.
  • You run a loyalty programme, bookings or personalised follow-up, and you want a direct channel to your customers through notifications.

The scopeWhat Kopus designs and develops for your app

  • The approach: native development (for example Swift for iOS or Kotlin for Android) or cross-platform (for example Flutter or React Native), depending on the native features required, the budget and the team that will maintain the app.
  • Screen flows that follow each system’s conventions, work one-handed and cope with interruptions (incoming call, lost signal).
  • Native features: notifications, camera, geolocation, sensors, local storage, background synchronisation.
  • The server and API that feed the app, or the connection to your existing systems.
  • User accounts, authentication, personal data handling and the permissions requested from the phone.
  • Preparation and publication on the App Store and Google Play: developer accounts, listings, screenshots, compliance with review guidelines, responses to store feedback.
  • Usage measurement: screens visited, retention, drop-off points, crashes.
  • Updates and compatibility with new operating system releases.
  • A useful, adopted, well-rated app.
  • A presence on both stores, maintained over time.
  • Usage data to decide on evolutions.

Sample field appThree screens, six phone capabilities

A field-service app shows clearly what sets an app apart from a mobile website: it alerts the technician to a new job, guides them to the address, photographs the finished work and keeps working in a basement with no signal. Each native feature is justified by a repeated action, not by a wish list.

  • Home: today’s jobs, with the time, place and status of each.
  • Job detail: route, checklist, photo and customer signature.
  • Lock screen: notification of a new job and readings waiting to sync while offline.

Native capabilities used

  • Notifications
  • Offline mode
  • Geolocation
  • Camera
  • In-app payment
  • Biometric sign-in

iOSAndroidPublished on both stores

Illustrative example of a fictional app. The features chosen depend on actual use, validated before development.

The methodThe stages of a mobile app project

  1. Validating the use

    Together we check that the need justifies an app rather than a mobile site, listing the native features that are indispensable.

  2. Interactive prototype on a phone

    Screens are tested on a real device by target users to fix navigation before development.

  3. Development in versions

    Features are delivered in batches on test builds distributed internally, for example through TestFlight or Google Play’s testing tracks.

  4. Store preparation

    Listings, visuals, copy, privacy policy, then submission and handling of any rejections.

  5. Launch and follow-up

    Monitoring of retention and crashes, quick fixes, then a plan for the next releases.

Your questionsFrequently asked questions about this service

Mobile app or responsive website?

A responsive site is enough for looking up information and occasional actions. An app is warranted for frequent use, native features and engagement through notifications.

Native or cross-platform?

Cross-platform reduces development and maintenance cost by sharing code between iOS and Android. Native remains preferable for apps with heavy performance or hardware demands.

Who handles publication on the stores?

We prepare and submit the app from developer accounts opened in your company’s name, so that you remain the owner and keep control over updates.

How much does a mobile app cost?

It depends on the number of features and whether a server is needed. We cost it after framing, and often propose a deliberately reduced first version to validate usage.

How long does it take to publish an app on the stores?

Allow one to two weeks of review by Apple and Google after development ends, which Kopus handles, including exchanges in case of rejection.

Let’s bring your projects to lifeYour next project starts here.

Let’s assess your mobile project and the recurring use that justifies an app.

Get an estimate for my mobile app

Feasibility and an order of magnitude within 48 hours