iOS and Android apps for dealers, field teams and catalogues
Enterprise mobile app development is the work of moving a business process onto a phone and keeping that software publishable in both stores. We build dealer ordering, field service, stock tracking and catalogue scenarios so that the app and the website read from a single content source.
Who owns which part of a corporate mobile app?
Three jobs are regularly left unowned in corporate mobile projects: keeping app and website content fed from one source, managing store listing texts and screenshots, and planning releases when operating systems or store rules change. We name all three in the contract instead of leaving them in the gap between a marketing agency and a software team.
| Responsibility | Marketing agency | Software agency | Baki Bilisim |
|---|---|---|---|
| Are app content and website content fed from a single source? | Out of scope | Partly | Yes |
| Whose job are store listing texts, screenshots and the privacy declaration? | Partly | Out of scope | Yes |
| Who plans the release when an OS version or a store rule changes? | Out of scope | Partly | Yes |
We set out why this division of work belongs in one contract on the Why Baki Bilisim page.
Where does the work pile up when there is no app?
When dealer orders arrive by phone and messaging apps, field reports come back on paper and stock lives in spreadsheets, the data is keyed into the system afterwards. The loss accumulates in two places: hours spent on re-entry, and decisions taken on late, unverified figures. A corporate app digitises the flow at its source instead of collecting it later.
Dealer ordering and catalogue
A dealer sees the price list assigned to them, their account balance and stock availability inside the app, builds an order from the catalogue, repeats a previous order and follows the shipment. One distinction matters: price and stock are not stored in the app, they are read from the ERP. When catalogue copy is fed from the same source as the product pages on the website, two channels stop carrying two different product descriptions.
Field teams and technical service
A service engineer receives the work order in the app, scans the device or serial number, completes the fault form, attaches photographs and captures the customer signature on screen. Inside a plant, where the mobile network is weak in parts of the building, offline working and synchronisation on reconnection are mandatory. That single requirement is the first item that drives the technology decision.
Production and stock tracking
On the warehouse and production floor, goods movements, counts and production steps are recorded by scanning a barcode or QR code. What decides success here is not the number of screens but scan speed and data accuracy. If phones are used instead of rugged handheld terminals, camera-based scanning performance and device compatibility are tested on the real floor before development starts.
Internal communication and training
In multi-site organisations, announcements, procedures, training material and form flows are collected into one app. Content management stays with your internal team; a new store release is not required for every announcement. Content is updated from inside the app, and a store update is needed only when functionality changes. Without that separation, the communications team depends on the software team for every text edit.
Publishing an app is a commitment to maintaining it
iOS and Android each ship a major release every year, and the stores update target API levels, permission rationales and privacy declaration rules on that calendar. An app with no maintenance plan first degrades in notifications, camera and location permissions, and then reaches a state where it can no longer meet store requirements at all.
1 year
Google Play requires new apps and updates to target an API level no more than one year behind the latest major Android release. Apps that do not meet the requirement cannot publish new versions.
Source: Android Developers — Google Play target API level requirement (opens in a new tab) · Accessed: 2026-07-29
What exactly is delivered in an enterprise mobile app project?
Nine items are delivered: scenario and screen inventory, the technology decision, data model and API contract, interface design with the token file, source code for both platforms, test distribution, the store release file, measurement setup, and the maintenance and handover document. The format and delivery week of each item is written into the contract.
| # | Deliverable | Format | When |
|---|---|---|---|
| 01 | Scenario, user roles and screen inventory | Document + screen list | Week 2 |
| 02 | Technology selection decision and rationale | Decision note | Week 3 |
| 03 | Data model and API contract | OpenAPI schema | Week 5 |
| 04 | Interface design and design tokens | Design file + token file | Week 6 |
| 05 | iOS and Android application source code | Access to the repository in your account | Continuously, at each sprint end |
| 06 | Test distribution and device test report | Invite-only test build + report | From week 9 |
| 07 | Store release file: listing texts, screenshots, privacy and data safety declarations | Ready inside your store account | Two weeks before release |
| 08 | Measurement setup: crash reporting, release and performance monitoring | Dashboard access | Before release |
| 09 | Maintenance plan, release calendar and technical handover document | Written plan + handover session | At delivery |
Native or cross-platform: how is the decision made?
The decision rests on four criteria: device API needs, release frequency, the team that will maintain the app, and budget with timeline. Heavy sensor use, offline synchronisation and background work point to native; forms, lists, catalogues and ordering flows point to a single codebase. We deliver the decision in writing, with the reasoning behind it.
| Decision criterion | Points to native | A single codebase is sufficient |
|---|---|---|
| Device API | BLE, NFC, background location, on-camera processing | Standard camera, notifications, location and file access |
| Release frequency | A few major releases a year, platform-specific features | Frequent small releases, both platforms at once |
| Team and handover | You have iOS and Android developers in-house | One team will maintain both platforms together |
| Budget and timeline | Two codebases and two maintenance budgets are affordable | One budget; separate effort planned for store differences |
| Performance profile | Continuous sensors, heavy graphics, long background tasks | Form, list, catalogue and ordering screens |
| Long-term ownership | You can follow the platform roadmap directly | Framework upgrades are written into the maintenance plan |
What stages does the project go through?
There are six stages: scenario and scope, architecture and technology decision, interface and design system, development and integration, testing and store preparation, then release with version management. Each stage has its own deliverable, measurement criterion and accountable party; none of them is left to be sorted out later.
-
01
Scenario and scope
We write down who uses the app and during which task, role by role. We observe the dealer or field side on site, and the out-of-scope list is agreed openly in this first stage.
-
02
Architecture and technology decision
Native or single codebase is decided against four criteria. The integration surface towards ERP, stock and identity systems, and any offline requirement, become concrete at this stage.
-
03
Interface and design system
Screens are built from design tokens while respecting each platform's own interface guidelines. If you have a corporate identity, the token file comes from there; if not, it is produced in this project.
-
04
Development and integration
We work in two-week cycles and each cycle ends with a test build. ERP and stock connections, authentication, offline storage and synchronisation are implemented in this stage.
-
05
Testing and store preparation
Testing runs across a device matrix, and closed testing is opened to real users on the field or dealer side. Store files and privacy declarations are ready two weeks before release.
-
06
Release, maintenance and version management
The release is rolled out in stages, and crash and performance data is watched from day one. As operating systems and store rules change, the release plan is updated; the call is yours.
The App Store and Play Store release process, step by step
Release runs in seven steps: account enrolment, app registration, privacy declarations, the listing file, closed testing, review submission and staged rollout. Store accounts remain in the client company's legal name at every step; we are added to those accounts only as an authorised developer.
- Account enrolment. Apple Developer Program and Google Play Console memberships are opened in your company's legal name. Apple asks organisations for a D-U-N-S number during enrolment; Google Play runs identity verification on organisation accounts. This step sometimes takes more than a week, which is why it starts in the first months of the project.
- App registration and bundle identifier. The app name, bundle identifier and signing certificates are created. Certificates are generated inside your account and are not stored in an agency account.
- Privacy and data safety declarations. Which data is collected for which purpose is declared in each store's own format and kept consistent with your privacy and KVKK notice — KVKK being Turkish data protection law. Rejections follow when the declaration and the app's actual behaviour diverge.
- Listing file. Title, subtitle, description, search terms, screenshots and promotional text are prepared, separately for each language if the app is published multilingually.
- Closed testing. The build is distributed to real users through TestFlight and Play closed testing tracks. In dealer and field scenarios this step is never skipped, because it is the only way to see real network conditions.
- Review submission. The most frequent rejection reasons are a missing demo account for the review team, unexplained permission rationales, and a privacy declaration that does not match behaviour. We check those three against a list before every submission.
- Staged rollout. The release opens to a share of users first; crash rate and error logs are watched, and the rollout widens only if nothing surfaces.
90%
Apple states that on average 90 per cent of apps submitted to the App Store are reviewed in less than 24 hours. The calendar is therefore set by account and declaration preparation, not by review itself.
Source: Apple Developer — App Review (opens in a new tab) · Accessed: 2026-07-29
Which measurements decide that the app is accepted?
Seven measurements: crash-free session rate, application not responding rate, cold start time, download size, store review rejection count, accessibility compliance and data declaration completeness. The threshold and the measuring tool for each are written into the contract, and the tool's output is attached to the delivery report.
| Criterion | Threshold | Measurement tool |
|---|---|---|
| Crash-free session rate | ≥ 99.5% | Crash reporting dashboard · Play Console Android vitals |
| Application not responding (ANR) rate | ≤ 0.3% | Play Console Android vitals |
| Cold start time (mid-range Android device) | < 2.0 s | Play Console Android vitals · on-device measurement |
| Download size | ≤ 40 MB | App Store Connect · Play Console |
| Store review rejections (first release) | ≤ 2 | Store review record |
| Accessibility: contrast and touch targets | WCAG 2.1 AA | Accessibility Scanner · Accessibility Inspector |
| Data safety declaration and permission rationales | Complete | Play data safety form · Apple privacy labels |
5 s
Google Play Console flags sessions with a cold start of five seconds or more as excessive. That is the ceiling of what is tolerated; we set the acceptance threshold below two seconds.
Source: Android Developers — App startup time (opens in a new tab) · Accessed: 2026-07-29
These thresholds are the mobile counterpart of the Core Web Vitals acceptance criteria we use on the web side: a target that cannot be measured does not go into a contract.
In which industries does a mobile app earn its cost?
Wherever there is repeated daily use: dealer networks, manufacturing plants, retail chains, exporting industrial companies and multi-company holdings. The common factor is that the app carries a daily job rather than a brand message. Each of the five pages below sets out the scenario for that segment in detail.
- 01 Manufacturing and Factories When floor and warehouse data moves off paper, production steps, counts and dispatch records reach the system the same day.
- 02 Retail Chains Stock lookup and ordering for staff, loyalty and a store finder for customers: all three read the same store record.
- 03 Franchise Networks Ordering, price lists and campaign announcements sit in one app, with head office controlling which franchisee sees what.
- 04 Export Industry Multilingual product catalogues and technical documents open at a trade fair or a customer site even without a connection.
- 05 Corporate Holdings Announcements, procedures and training flows across subsidiaries run in one app while permission boundaries are preserved.
Frequently asked questions about enterprise mobile apps
Should we choose native or cross-platform?
The decision follows four criteria: device API needs, release frequency, who will maintain the app afterwards, and budget with timeline. Heavy sensor use, offline synchronisation and background work point to native; forms, lists, catalogues and ordering flows are well served by a single codebase. We deliver the decision in writing with its rationale, and we rewrite it if the criteria change.
How long do the App Store and Play Store processes take?
Review itself is usually resolved within one working day; Apple states that on average 90 per cent of submissions are reviewed in less than 24 hours. The real time is spent before review: account enrolment and identity verification, privacy declarations, listing texts and screenshots. We complete that preparation two weeks before release. A rejection on first submission is ordinary; the reason is addressed and the build is resubmitted.
Whose name are the store accounts opened under?
Store accounts are opened in the client company's own legal name. Apple asks organisations for a D-U-N-S number during Developer Program enrolment, and Google Play verifies the identity of organisation accounts. We are added to those accounts as an authorised developer. The app, the signing certificates and the store assets are never held in an agency account.
How is app maintenance and release cost calculated?
Maintenance has three line items: platform obligations, defect fixing and new feature work. Platform obligations are what keep the app publishable and are planned on a fixed monthly rhythm — annual operating system releases, target API level requirements and privacy declaration updates sit here. New feature work is planned separately as it is requested. Store membership fees are paid directly from the client's own account.
Can the app connect to our existing ERP or stock system?
Yes, but the connection is made through a defined API rather than straight into the database. If the ERP has no service layer, we write a middle layer between the app and the ERP. Stock, price, account and order data stays in the ERP; the app only reads and writes. Which field flows in which direction is written line by line in the API contract.
Is a mobile website enough without an app?
For most corporate needs it is. An app is justified when at least one of three conditions holds: repeated daily use, a hard dependency on device capability, or an authenticated closed user group. An app built only to present a brand or a catalogue returns less than a well-built mobile site, because it carries download and update friction. We say this before the project starts, not after.
Do you work with companies based outside Türkiye?
Yes. We deliver in English and Turkish, work remotely with fixed weekly review calls, and travel to site for scenario observation when the app covers field or production work. Contracts, deliverable lists and acceptance criteria are issued in English. Store accounts, source code repositories and analytics panels stay in your organisation's name in every case.
See the measured state of your website within five working days.
The audit is free and creates no obligation to work with us. The report itemises findings on AEO answerability, AI crawler access, lab-measured Core Web Vitals, structured data validity and accessibility (automated scan).
We work with corporate-scale, multi-location or multilingual organisations. One-off small jobs fall outside our scope; in that case we point you to smaller studios.