Mobile App Development

What is mobile app development, and when do you actually need an app?

Mobile app development covers everything from defining the product and designing it to writing the code, releasing it on the app stores and shipping the updates that follow. An app is more than the screens on a phone: behind it sit a server that holds the data, an API the app talks to and a panel for managing content.

UNIT İstanbul offers mobile app development through its software brand, Unit Software. Because the team works inside an agency that has been doing marketing since 2009, measurement, user acquisition and store visibility are on the table from the first day of the project.

Not every idea needs an app. Commissioning a mobile app usually makes sense when:

• People will use the product often and regularly: ordering, bookings, loyalty programmes or tools for field teams.
• You need device features such as the camera, location, Bluetooth, biometric login or background processing.
• Work has to continue when the connection is weak or missing altogether.
• Push notifications will be the main channel for staying in touch with users.

If customers visit you only a few times a year, a well-built mobile website is often the better investment. For games, see game development; for camera-based augmented reality experiences, see AR and VR. Both pages describe a different approach.

Native, React Native or Flutter?

The technology decision shapes an app's budget, speed and maintenance load for years. Native development means writing each platform in its own language: Swift for iOS and Kotlin for Android. With a cross-platform approach, React Native or Flutter produces apps for both platforms from a single codebase.

For most business apps, cross-platform development gets you into both stores without writing every feature twice. If the app leans heavily on the camera, sensors, background work or the newest platform features, native development tends to cause fewer surprises in the long run. This is not a matter of taste; the decision is made in writing, based on the feature list, the team structure and the maintenance plan.

When is a PWA enough?

A PWA (progressive web app) is a web application that can be added to the home screen, work partly offline thanks to caching and send notifications. It updates without waiting for store approval and runs on every device from a single codebase.

A PWA is a good starting point for internal team tools, campaign-specific experiences and testing an app idea on a small scale first. On the other hand, it does not appear in store searches on its own, its access to some device features and background tasks on iOS is limited, and users have to add the site to their home screen before they can receive notifications. If you need a store presence and deep device integration, a store app is the better choice.

Why do mobile user experience and accessibility matter?

On mobile, people often act with one hand, on the move and with divided attention. A good mobile experience means short flows, buttons within easy reach of the thumb, clear error messages and screens that respond even on a slow connection.

Accessibility is an inseparable part of that experience. Labels that work with the VoiceOver and TalkBack screen readers, screens that hold up at larger text sizes, sufficient colour contrast and comfortable touch targets are planned at the design stage; adding them later takes far more effort.

The invisible half of an app: backend, API and admin panel

Any app with user accounts, orders, content or notifications needs a server side. We design that side with the same care as the screens, because a slow API makes even the best interface feel slow.

• API design: Older versions of the app stay in use for a while, so we version the API and add new features without breaking older releases.
• Admin panel: A web panel where your team can manage content, campaigns, users and notifications without needing a developer.
• Integrations: Steady, traceable data flows with ERP, CRM, inventory, booking or loyalty systems.

How should push notifications be planned?

Push notifications are delivered through Apple's notification service on iOS and Google's on Android. The technical setup is the easy part; the real work is deciding which events trigger a notification, when to ask for permission and how often to send. Asking for permission when the user has seen the value of notifications, rather than the moment the app opens, works out better.

How does an app work offline?

In field work, warehouses, events or travel, a connection is not always available. An app that works offline stores data securely on the device, syncs with the server when the connection returns and, if the same record changed on both sides, resolves which version wins according to a rule defined in advance. If that rule is not written during design, it comes back later as lost data.

How does the App Store and Google Play release process work?

Both stores review the app, and every new version, before it goes live; the review criteria and timelines differ between the two. We check store rules during product definition, not at the end of development.

• Developer accounts are opened in your name. The app and its user data stay in your brand's account; we access them as team members.
• Privacy disclosures: The App Store privacy labels and the Google Play data safety section must match exactly the data collected by the app and by the third-party libraries inside it.
• Account deletion: If users can create an account in the app, both stores require a way for them to delete it.
• Test tracks: Before release, we run trials with real users through TestFlight on iOS and closed testing tracks on Android.
• Staged rollout: We release new versions to a portion of users first and widen the rollout once crash and feedback data look clean.

Which rules apply to in-app purchases?

If you sell digital content, subscriptions or features used inside the app, the stores generally require their own billing systems. For physical goods and services delivered in the real world, you can use your own payment infrastructure. These rules vary by country and change over time, so we recheck the current store policies on every project. We cover the technical and security side of the payment flow separately on our payment architecture page.

How are release management, crash monitoring and performance handled?

On a website, a bug fix goes live straight away; in a mobile app, the fix passes through store review and the old version keeps running until the user installs the update. That is why release management is a discipline of its own on mobile.

• A forced update mechanism, which directs users to update in case of a critical security or compatibility issue, is built in from the start.
• New features ship behind flags that can be switched on and off remotely; if something goes wrong, they are turned off without waiting for a new release.
• Crash reports are collected with tools such as Firebase Crashlytics or Sentry and prioritised with device and operating system version details.
• Startup time, frozen screens, application-not-responding errors on Android, app size and battery use are tracked in every release.

What should you measure in a mobile app?

Install numbers alone are not a measure of success. The real question is whether people who install the app reach meaningful steps such as signing up, placing a first order, coming back or subscribing. That is why we write an event tracking plan before development: which events are recorded, with which parameters and under which names.

On iOS, tracking users across apps requires separate permission, and under data protection law, processing that needs explicit consent is kept apart from the rest. We build measurement around these permissions and keep aggregated, anonymous reporting for users who decline.

This is where our marketing agency roots help most. To get the app found in the stores, turn store page visits into installs and measure app install ads, we work on the same measurement plan as our ASO and app advertising team, so there is no separate setup to start from scratch once the app is live.

How are security and data protection (KVKK) handled in a mobile app?

A phone can be lost, a network can be untrustworthy and an app package can be reverse-engineered. We build security on those assumptions and use OWASP's mobile application security standard, MASVS, as our checklist.

• Session tokens and sensitive data are stored in the operating system's secure areas, such as the iOS Keychain and Android Keystore; secret keys are never written into the app code.
• All traffic runs over encrypted connections; certificate pinning is added on projects that need it.
• The app asks only for the data and permissions its function requires; location or contacts access is never requested without a reason.
• For Turkey's data protection law (KVKK), the privacy notice, processing that requires explicit consent, the server location of the data and the data flows of third-party libraries are documented. Decisions involving cross-border data transfers are settled together with your legal adviser.

What determines the cost of building a mobile app?

Cost depends less on the number of screens than on the business rules behind them. We prepare a written proposal once the following points are clear from discovery:

• One platform or two; native or cross-platform.
• User roles, and the number and complexity of flows.
• Whether the backend is built from scratch or connected to an existing system.
• Integrations such as payments, maps, messaging, ERP or CRM.
• Offline use, real-time data and security requirements.
• The scope of post-launch maintenance and development.

Rather than building a large project in one go, we recommend starting with a first version that launches with the core features and expanding it with real usage data. You can browse our completed software projects on the Unit Software portfolio page.

Why does an app need maintenance after launch?

A mobile app is not finished when it goes live. Apple and Google update their operating systems every year; Google Play requires app updates to target a recent Android version, and the App Store expects builds compiled with current development tools.

A maintenance agreement covers operating system compatibility, library updates, crash tracking, store policy changes and small improvements. Every month we report in writing what was done and what the next release will include. To talk about your project, reach us through our contact page.