Must the application be developed twice for iPhone and Android?

Not necessarily. Cross-platform technologies allow most of the application to be written once while retaining complete access to device hardware. Separate native development is justified when responsiveness or specialised hardware use requires it.

Must we publish through the App Store and Google Play?

No. Applications reserved for employees can use internal distribution methods that avoid public review and its delays. Public applications must go through the stores.

How long until the first release?

It depends on the number of journeys and the extent of offline operation. One factor is often missing from plans: development time is followed by Apple and Google review, including the possibility that the first submission is rejected.

Will the application work without a network?

Yes, when the business requires it. Offline behaviour is designed from the start, with written rules for conflicts when two people change the same information while disconnected. Adding it later requires substantial rework.

What does maintenance cover after launch?

It covers error monitoring, mobile operating-system changes, security, API compatibility and release planning. iOS and Android issue major versions annually, and they occasionally break existing functions.

Field work and customer journeys

Enterprise mobile applications

An application used standing up, outdoors, with one hand and sometimes without a network. We design mobile business applications for field teams, partners and customers—products that must remain dependable where connectivity does not.

From definition through publication in application stores, working from Tarbes, Marrakech and Dover.

Which technology

A mobile application—but which kind?

It is the first question, and the answer affects budget, timing and what the product can do later. These are the real options.

Native development

A separate application for iOS and Android. It provides the best responsiveness and complete access to device hardware. It also costs the most because two applications must be built and maintained.

Cross-platform development

React Native or Flutter: one codebase for both systems with access to device hardware. It is the compromise chosen for many business applications.

An installable web application

A mobile website added to the home screen. No store, immediate updates and a lower budget. In return, hardware access is limited and offline operation remains basic.

We compare experience needs, device capabilities, offline operation, distribution and long-term maintenance cost—not technology preferences.

Offline operation

Working without a network—and what happens when it returns

Making an application work offline is the easy part: data can be kept on the device. The difficult part begins when connectivity returns. Two people changed the same record while disconnected. Which version wins?

There is no universal answer, only an answer appropriate to your operation. The latest entry may win for a field report. That is unsuitable for inventory, where movements must be combined. A signed quotation may need to reject the change and alert someone.

Data, synchronisation rules, conflicts and offline boundaries are therefore defined from the outset. Silent synchronisation that loses an entry destroys trust in a week.

Security

Phones get lost

A mobile application is an entry point into your system, and it travels in a pocket. We limit what leaves your servers and enforce authorisation on the service side—never only inside an application that can be inspected.

Exchanges with your services explicitly handle real conditions: several application versions installed at once, connectivity lost during transmission and recovery after failure. A phone losing its network mid-transfer is normal, not exceptional.

In the field

The real field, not the office

An application tested only on a recent phone over office Wi-Fi creates a false impression. Journeys are evaluated on representative devices and networks. Priority screens, transfer size, resource use and degraded states are monitored.

We pay particular attention to degraded states: what the application shows when something does not work. A clear message at the right moment avoids an incorrect entry and a call to support.

Release

What nobody tells you about application stores

Apple and Google review every version before publication. It usually takes several hours to several days, and a release may be rejected because permission text is unclear, a function is considered non-compliant or a rule changed in the meantime.

An urgent correction will not be available within the hour.
You need developer accounts in your own name with Apple and Google, paid annually.
Users do not all update at once: multiple versions coexist, and your services must support them.

Release preparation, checks, store material and post-publication monitoring can all be included in the engagement.

From idea to store

Discovery

Who uses it, where, on which devices, with what connectivity and what must work offline.

Prototyping

Priority journeys are modelled and tested on a phone—not a desktop display. Technical risks are resolved here.

Delivery

Increments that you install and genuinely use on real devices.

Publication

Store submission, monitoring reported errors, usage measurement and maintenance.

Investment

What determines the budget

The target operating systems and chosen approach.
The number and complexity of journeys.
Hardware use: photography, scanning, continuous location and Bluetooth.
The extent of offline operation—usually the most underestimated item.
Connections to your existing systems.
Your security requirements.
The distribution strategy: public stores or internal distribution.

Definition separates what belongs in the first release, capabilities that can wait and the lasting maintenance responsibilities.

Applications delivered

ATMO Grand Est

Portable sensors collect readings, the mobile application gathers and transmits them, then the information is centralised and processed. Android SDK, Ruby on Rails and Python processing. Delivered for the Grand Est Region through INTERREG.

LDLC, wind farms

A SaaS application for teams working on site. React and React Native, an AI assistant and Python algorithms on a Node.js back end.

“Always attentive and ready to help. That is rare.”

Questions

Must the application be developed twice for iPhone and Android?: Not necessarily. Cross-platform technologies allow most of the application to be written once while retaining complete access to device hardware. Separate native development is justified when responsiveness or specialised hardware use requires it.
Must we publish through the App Store and Google Play?: No. Applications reserved for employees can use internal distribution methods that avoid public review and its delays. Public applications must go through the stores.
How long until the first release?: It depends on the number of journeys and the extent of offline operation. One factor is often missing from plans: development time is followed by Apple and Google review, including the possibility that the first submission is rejected.
Will the application work without a network?: Yes, when the business requires it. Offline behaviour is designed from the start, with written rules for conflicts when two people change the same information while disconnected. Adding it later requires substantial rework.
What does maintenance cover after launch?: It covers error monitoring, mobile operating-system changes, security, API compatibility and release planning. iOS and Android issue major versions annually, and they occasionally break existing functions.

Assess the real constraints behind your mobile product

Share the use cases, operating environments, integrations and distribution goals. We will prepare a conversation focused on the decisions that matter.