Mobile App Development

What Is Mobile App Development?

Mobile app development turns a product idea or a business process into an app that runs on iPhone and Android devices and is installed from the app stores. The work is more than screens: the servers and APIs the app talks to, user accounts, notifications, services such as payments or maps, store rules and the updates after launch are all part of it. Hatson Tech builds customer-facing product apps, field and operations apps and AI-enabled mobile apps for companies across Türkiye, working from Ankara. We deliver the app together with its back-end software and admin panel as one team.

What the Service Covers

• Product discovery and UX: A flow map that starts from who opens the app, when and for which job, followed by a clickable prototype and interface design.
• iOS and Android app: The same functionality on both platforms, following each platform's familiar behaviour (back gestures, permission prompts, notifications).
• Back end, APIs and admin panel: The server side and web panel for user accounts, content and order management, notifications and reporting.
• Integrations: Connections to ERP, CRM, payment, maps, authentication and notification services.
• Offline operation: A design that keeps data on the device where the connection drops and syncs it safely when the connection returns.
• Store release: App Store and Google Play listings, screenshots and descriptions, privacy disclosures and the review process.
• AI features: Capabilities such as an assistant, extracting information from photos or documents, search and recommendations, added against a measurable goal.
• Maintenance and releases: Keeping up with operating system updates and store policy changes, error monitoring and new versions.

Cross-Platform, Native or Mobile Web?

The right technology depends on what the app has to do. Cross-platform tools such as React Native or Flutter target both platforms from one codebase. Native development in Swift (iOS) and Kotlin (Android) gives the most direct access to device features. For some needs, a mobile-friendly web app that never goes through the stores is enough. We decide using these criteria:

Whether an app that has become hard to maintain should be rewritten or renewed step by step is covered in our application modernisation decision guide.

Delivery Step by Step

1. Discovery: We pin down the users, the moments they use the app, the systems to connect and the success measure. In a field app, for example, the real risk is often not the screen design but making sure data entered without a connection is never lost.
2. Prototype: The main flows are shown to real users as a clickable prototype, so misunderstandings are caught before any code is written.
3. First-release scope: The features of the first store release, its acceptance criteria and what is deferred are written down. Our article on project scoping covers this step in detail.
4. Short development cycles: Each cycle ends with a working build that installs on test devices; feedback goes into the next cycle.
5. Testing: Different screen sizes, old and new operating system versions, weak networks and offline use, denied permissions and returning from the background are tested on real devices.
6. Store release: We handle the store listings, privacy disclosures and review; if needed, the release opens to a small group of users first.
7. Operation and maintenance: Crash and error reports are monitored, and updates follow operating system and store policy changes.

What to Know About Store Release

Store rules affect both the first release date and the maintenance the app needs afterwards. We plan the following together at the start:

• Developer accounts should belong to your company: We recommend opening the App Store and Google Play accounts in your company's name, so the app, its users and its reviews stay with you. Both stores ask for the company's D-U-N-S number for an organisation account. Getting that number can take time, so we start the application at the beginning of the project.
• Closed testing on Google Play: Personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers for 14 consecutive days before the app can go public. The rule applies to personal accounts, which is one more reason to use a company account.
• In-app account deletion: For apps that let people create an account, Apple requires that the account can be deleted from inside the app. Google Play also requires a web link where users who have already uninstalled the app can request deletion. We design this flow in from the start.
• Privacy disclosures: The privacy labels on the App Store and the Data safety form on Google Play must match exactly what the app and its third-party libraries collect.
• Yearly updates: Google Play raises the Android version apps must target every year. Since 31 August 2026, new apps and updates must target Android 16 (API 36), and an existing app must target at least Android 15 (API 35) to stay available to new users on newer Android versions. In short, even a "finished" app needs at least one update a year.

Security, Privacy and Offline Use

• Sessions and keys: Credentials and access tokens are kept in the device's secure storage (iOS Keychain, Android Keystore); no secret keys are embedded in the app package.
• Traffic and authorisation: All traffic between the app and the server is encrypted, and who can see what is enforced on the server, not in the app.
• Permissions: Permissions such as location, camera or contacts are requested only when needed and with the reason explained.
• Personal data: For data covered by KVKK, Türkiye's data protection law, the privacy notice, explicit consent where required, retention periods and the deletion flow are decided at design time. Analytics and advertising tools added to the app fall within the same framework.
• Offline use: In field apps, data is written to the device first and synced with the server when a connection is available. The rule for which change wins when the same record is edited in two places is written down up front.
• Monitoring: Crash reports and error logs are collected without personal data, so problems surface before users complain.

AI in Mobile Apps

An AI feature creates value when it makes a measurable job easier: creating a record from a photo taken in the field, summarising a long document, or answering a user's question from internal company knowledge. Whether the model runs on the server or on the device depends on the balance between privacy, latency, offline use and cost. See our article on small language models for models that can run on the device, and our KVKK and generative AI guide for the rules on sending personal data to a model.

What Drives Cost and Timeline?

We don't publish a fixed price list; the difference between two apps is usually not the number of screens but the rules and integrations behind them. The main factors are:

• The number of screens and workflows, user roles and permission layers.
• Whether the back end the app talks to already exists, and whether an admin panel is needed.
• The systems to integrate: payments, maps, ERP or CRM, authentication.
• Device features such as offline use, background location, camera or Bluetooth.
• Design and animation expectations, the oldest operating system version to support and tablet support.
• Security, KVKK and hosting requirements.
• The maintenance and release plan after launch.

At the end of discovery these factors are itemised, so you can see which assumption each part of the quote rests on. For questions to ask when assessing a software company, see our article on choosing a vendor.

What We Need From You

• A product owner who knows the product and can make decisions.
• A description of the target users and when they use the app; existing screens, forms or apps you like, if any.
• A list of systems to connect and test access to them.
• App Store and Google Play developer accounts in your company's name (we help set them up).
• A few real users to try the test builds.