TECHNOLOGY SERVICE · 03
Mobile App Development
Customer and field-force applications for iOS and Android, together with the backend services and release process that keep them shipping. Built for organisations whose users are outdoors, on the move, or switching between Arabic and English mid-task.
Native or cross-platform, decided on evidence
Cross-platform frameworks are the right default for most business applications and save real money on maintenance. Native becomes the better answer when the app leans on hardware, background location, tight battery budgets or platform features that arrive first on Swift and Kotlin. That call gets made in discovery against your actual requirements, and the reasoning is written down.
- Recommendation backed by your feature list, not a house preference
- Shared backend regardless of the client-side choice
- A migration path if the answer changes in two years
Offline is a requirement, not an edge case
Warehouses, basements, desert sites and lifts all break connectivity, and a field application that stalls when the signal drops will be abandoned by the people who need it most. Local persistence, an outbound queue and conflict rules are designed at the start rather than retrofitted after the first complaint.
Sync behaviour is then tested deliberately: flight mode mid-transaction, a stale device coming back after two days, two users editing the same record.
Arabic is a layout problem before it is a translation problem
Right-to-left support touches navigation direction, icon mirroring, form alignment, date and numeral formatting, and the way names and addresses are captured. Handled at design time it costs very little; bolted on later it means rebuilding screens. Both language directions are checked on real devices before release.
Release trains, not release panics
Store accounts stay in your organisation's name, with your trade licence behind the developer enrolment, and we work inside them as invited members. Builds are automated from the first sprint, so a release is a routine event rather than an afternoon of manual archiving. Crash reporting and staged rollouts are configured before the first public submission, which makes a bad build a rollback instead of an incident.
What you get
- iOS and Android applications, with source in your repository
- Backend services and the APIs the apps depend on
- Automated build and signing pipeline producing store-ready artefacts
- Store listings, screenshots and review submissions under your own accounts
- Offline and sync behaviour documented, with conflict rules stated
- Arabic and English builds verified on physical devices
- Crash reporting, analytics and staged rollout configuration
- Maintenance plan covering annual OS releases and store policy changes
Typical outcomes
10-14 weeks
Discovery to first store submission
2 stores
Shipped from a single automated pipeline
<1%
Crash-free session target at launch
Stack we use
Questions
Yes, and it is worth the paperwork. Organisation enrolment with Apple requires a D-U-N-S number tied to your trade licence, which we will help you obtain, and it keeps ownership of the app with you rather than with a supplier.
Apple usually returns a first decision within a day or two, Google Play a little longer for new accounts. First submissions are the risky ones, so we allow a fortnight of buffer and submit a review build well before any launch date.
Often, though we ask for two weeks to audit it first. The common blockers are lost signing certificates and unsupported framework versions, and we will tell you honestly if a rewrite is cheaper than a rescue.
Yes. Integrations with UAE PASS for identity and with regional payment providers are routine work for us, subject to your own approvals and merchant onboarding with those parties.
Related
Next step
Start with a 20-minute call.
Tell us the roles you need filled, the system you need built, or both. You will speak to someone who has done the work, and leave the call with a route forward.