Mobile applications
Business, customer service or B2B apps: AXELITES designs and builds your iOS and Android applications, native or cross-platform, connected to your tools. A prototype tested with your users, store publishing in your name, then maintenance that keeps up with each iOS and Android release.
Published, then kept up to date
What we take care of:
A mobile app has to stay easy to use when the screen is small, the network is weak and people act quickly. It is also part of a wider system: APIs, back office, notifications and version management need as much care as the screens. We start from how your customers or teams actually work, choose the technology according to your journeys, then keep the app up to date after publication.
Design, development, APIs, offline use, security, publishing and maintenance: one team follows your app from the first workshop to the next release.
We start from real situations: where, when and on which device the app will be used. Key journeys are prototyped and tested with your users before development.
Native with Swift and Kotlin, or cross-platform with React Native and Flutter to share most of the code between both systems. Device features are used when they serve the journey.
A mobile app is only useful if its data is right. We build the APIs, the administration back office and the exchanges with your software.
Rounds, service visits, inventories: in the field, the network often drops. We define with you what stays available offline and how changes synchronize when the network returns.
Authentication, role-based permissions, encrypted exchanges and protected personal data: security is designed into the architecture, in the app and in the APIs.
We prepare the builds, store listings and checks required by the App Store and Google Play, then maintain the app: fixes, compatibility with new system versions and improvements.
Test builds on your devices at every stage: you see the app take shape and decide the priorities before it is published.
Where, when, on which device, with what connection: usage conditions become requirements for the journey.
Stage: ScopingThe main screens are tested with your users. Their feedback guides adjustments before development.
Stage: DesignNative or cross-platform, according to your journeys, device features and future maintenance. The first release is costed.
Stage: ScopingTest builds delivered regularly and installed on your devices, with the APIs and integrations as they are ready.
Stage: DevelopmentJourneys checked on representative devices: permissions, network outages, session changes.
Stage: AcceptanceSubmission to the App Store and Google Play from your accounts, then follow-up of review feedback.
Stage: PublishingEach approach has its place. Cross-platform is often the best balance of budget, schedule and quality for a business or service app; native suits highly specific interactions; a PWA can be enough when usage stays close to a website.
Swipe to see more
| Criteria | NativeSwift for iOS, Kotlin for Android | Cross-platformReact Native or FlutterOften the right balance | Progressive web appPWA, installed from the browser |
|---|---|---|---|
| Code | One build per system | One codebase shared by iOS and Android | Web code, with no app to install from a store |
| Device features | Full access | Broad access, with native code when needed | Limited access, varying by browser |
| Smoothness and interactions | The best, for highly specific interactions | Suited to most business and service apps | That of a well-built website |
| Offline use | Full | Full | Possible, more limited |
| App Store and Google Play | Yes | Yes | No |
| Budget and maintenance | Two builds to keep alive | One main codebase to maintain | The lightest, alongside a website |
Our recommendation: we compare the options against your priority journeys and explain the choice before development starts. Discuss my mobile application
We build apps for your customers as well as your employees, always connected to your information system.
The budget mainly depends on the number of screens and roles, the device features used, integrations with your software, offline mode and the choice between native and cross-platform. To keep it under control, we recommend starting with a first release focused on essential features, costed after the prototype, then extending the app based on user feedback.
You should also plan for the app’s life after launch: Apple and Google developer accounts, API hosting, adaptation to new versions of iOS and Android, fixes and improvements.
UX/UI, mobile development, back end, testing and hosting are brought together in one team, with no hand-offs between providers.
Our teams in Paris, Montréal and Tunis are coordinated by a project manager who follows your app from scoping to maintenance.
The source code, the Apple and Google publishing accounts, the documentation and the data belong to your company.
The team that developed the app handles its fixes, updates and improvements.
New system versions, new devices, libraries to update, feedback from your users: the team that built the app maintains it, with priorities agreed with you and requests tracked in a shared tool.
Licensed online driving school: 79 branches, 838 state-certified instructors and more than a million students.
Alongside Stych’s team, we set up the training management application, for candidates and driving schools alike.
Native or cross-platform, chosen for your journeys and the team that will maintain the app.
The back end, the integrations, the hosting and the maintenance are handled by the same teams.
Practical answers to help you make the right decisions before starting your project.
Discuss my projectThe choice depends on the device features used, expected performance, offline use and your maintenance capacity. Cross-platform development (React Native, Flutter) shares most of the work between iOS and Android. Native development (Swift, Kotlin) better suits highly specific interactions. We compare the options against your important journeys before choosing a technology.
The main factors are the number of screens, user roles, connected services and features such as notifications or offline synchronization. The budget also needs to cover device testing, publishing and post-launch updates. A prototype validates the journeys and lets us cost the first release before committing to full development.
Timing depends on the scope of the first release, the number of platforms and the integrations with your software. The schedule is set after the prototype, with test builds delivered regularly. You should also allow for App Store and Google Play review times, which are outside our control.
Yes. We prepare the builds, store listings, screenshots and technical checks needed for submission. Publishing accounts are created in your company’s name. Approval and review timing remain under the stores’ control; any feedback is handled within the agreed scope.
Yes, if local storage and synchronization are planned from the design stage. We define with you which data stays available offline, for how long, and how to resolve concurrent changes when the network returns. Operations that depend on a remote service, such as a payment, still require a connection.
You do. The source code, documentation, data and the Apple and Google developer accounts belong to your company. You remain free to hand maintenance or improvements to another team if you wish.
Yes. Maintenance covers bug fixes, compatibility with new versions of iOS and Android, security updates and new features. Scope and priorities are agreed with you, and requests are tracked in a shared tool.
We build native apps with Swift for iOS and Kotlin for Android, and cross-platform apps with React Native or Flutter. The technology is chosen according to your priority journeys, the device features used, the team that will maintain the app and your budget. We explain the choice before development starts.
Yes. We design the APIs and synchronization rules with your existing software: ERP, CRM, online store or business application. Exchanges are secured, permissions are set by role, and behaviour during network outages is planned from the design stage.
A PWA is installed from the browser and can be enough when usage stays close to a website and presence on the App Store and Google Play is not essential. A native or cross-platform app is a better fit when you need broad access to device features, extensive offline use or a presence in the stores. We compare both options against your journeys before recommending one.
Tell us about your users, their devices and what they need to do on the move: we will propose a prototype and a first-release scope.
