Mobile App Development for Food Delivery

We are a mobile development team with extensive experience in foodtech. Over that time, we have delivered 20+ projects — from single-restaurant apps to full-scale aggregators with hundreds of venues. According to our data, 70% of users expect real-time tracking, and its absence increases support load by 30–40%. We embed these nuances into the architecture from day one.

Food delivery is technically similar to ride-hailing: geolocation, real-time tracking, payment gateway. But there are significant differences — a menu catalog with options and modifiers, restaurant logic with schedules and stop-lists, preparation time as a separate variable in delivery ETA, and delivery zones with varying prices based on distance. On average, a restaurant processes 150–300 orders per day, with peak load reaching 50 orders per minute.

Get a free project estimate in 2–3 days. Discuss your task with our engineers — they will help you choose the optimal architecture.

Architecture and Key Modules

Which Architecture Suits Your Business?

We develop three architectural approaches to fit any budget.

Aggregator (like Delivery Club) — many restaurants, a shared pool of couriers, the customer chooses from multiple venues. Complex dispatching, API for restaurant onboarding, own courier fleet or outsourcing. Development timeline: from 5 months.

Restaurant's own delivery — one restaurant or chain, own couriers. Architecturally simpler, but an admin panel for the restaurant manager is needed. MVP: from 8 weeks.

White-label platform — same architecture as the aggregator, but tailored for a specific restaurant or small chain. A middle ground.

Menu and Cart

A restaurant menu is not just a list of dishes. Categories, subcategories, items with options (pizza size, doneness, extras). The data structure must support modifiers: "add cheese +80₽", "choose sauce" (required single choice), "remove onion" (optional). The number of modifiers per dish can reach 10, and conversion after selecting items is 65%.

{
  "id": 42,
  "name": "Margherita Pizza",
  "base_price": 590,
  "modifier_groups": [
    {
      "id": 1,
      "name": "Size",
      "required": true,
      "min_select": 1,
      "max_select": 1,
      "options": [
        {"id": 11, "name": "25 cm", "price_delta": 0},
        {"id": 12, "name": "35 cm", "price_delta": 150}
      ]
    },
    {
      "id": 2,
      "name": "Extras",
      "required": false,
      "max_select": 3,
      "options": [
        {"id": 21, "name": "Extra cheese", "price_delta": 80},
        {"id": 22, "name": "Chili", "price_delta": 0}
      ]
    }
  ]
}

Cart logic on the client: each line item stores the base product_id plus selected modifier_ids. The price is calculated client-side for display, and server-side for the final order. The cart is saved locally when the app is closed.

Why Is Server-Side Validation of Delivery Zones Important?

A restaurant does not deliver everywhere, and prices vary by zone. Zones are defined by polygons — not simple circles. When the user enters a delivery address, we check if it falls within a polygon: client-side check (via Google Maps containsLocation(point, polygon) or a port of turf.js in Dart/Swift/Kotlin) for quick UX, and server-side check as the final arbiter when creating the order.

PostGIS on the server: ST_Contains(zone.polygon, ST_MakePoint(:lon, :lat)) — reliable and accurate. PostGIS is 10x better than client-side geo libraries and ensures data consistency.

Each zone is a separate row in the table with its own delivery fee and minimum order. If the address does not fall into any zone, we show the message: "Unfortunately, we do not deliver to your area yet."

Order Time and Statuses

The user wants to know: "when will it be ready and when will it arrive?" Preparation time is a restaurant parameter that can vary based on load. The admin sets the current time in the control panel. Delivery time is estimated based on distance and courier speed. Average delivery time in a zone is 15–30 minutes. Final display: "~45 min" (cooking 25 + delivery 20). Avoid promising exact time without integration with a real dispatcher.

Push notifications on every status transition. Firebase Cloud Messaging — data notifications for background processing, notification for display. On iOS — UNNotificationContent with category ORDER_UPDATE, on Android — a dedicated NotificationChannel.

How Does Courier Tracking Reduce Support Load?

Without real-time tracking, users call support — each call costs the restaurant an average of 50₽. An app with a map and animation reduces call center load by 30–40% and increases NPS by 15 points.

Payment Gateway

Online payments (CloudPayments / YooKassa / Tinkoff Acquiring) + cash on delivery + Apple Pay / Google Pay. Pre-authorization (hold) is standard practice for delivery: the amount is held when the order is created, captured when confirmed. If the restaurant does not accept the order, the hold is automatically released. Promo codes and loyalty system — a separate module. Applied at the order confirmation stage, discount calculated server-side.

Restaurant Admin App

Without it, the system cannot work in production. Minimal set of screens:

• Current orders (list with timers, statuses)
• Stop-list management (button "item out of stock")
• Current preparation time (input field, applied immediately)
• Operating hours

It can be a web panel — not necessarily a mobile app for the first stage.

How We Develop? Step-by-Step Plan

1. Analysis — study business processes, delivery zones, menu requirements. Document in a technical specification.
2. Design — create architecture (ERD, flow diagrams), define the tech stack.
3. UI/UX Design — produce mockups adhering to platform guidelines.
4. Development — 2-week sprints, daily demos to the client.
5. Testing — unit, integration, UI, load testing (up to 1000 orders/min).
6. Deployment — publish to App Store and Google Play, set up CI/CD.
7. Support — bug fixes, warranty improvements.

What's Included

Upon project completion, we deliver:

• Source code of the app (iOS/Android/Flutter)
• API documentation (Swagger/OpenAPI)
• Backend deployment instructions
• Access to App Store Connect and Google Play Console
• Restaurant admin panel
• Team training (2–3 hours)
• 3-month code warranty

Get a free consultation for your project. Contact our engineers — we'll discuss the details.

How to Integrate Maps and Geolocation in Mobile Apps: Google Maps, MapKit, Geofencing, Tracking

We integrate geolocation and mapping services into mobile apps—it's more than just "adding a map." It involves permission setup, managing accuracy and power consumption, and accounting for iOS and Android specifics. Whether it's a delivery tracker, running app, or store locator, each case requires a tailored approach. Contact us for a free project assessment within 2 hours.

Permissions: One of the Most Common Sources of Bad Reviews

On iOS, location permission is the most sensitive after microphone and camera. Since iOS 14, the system shows an indicator in the status bar when location is used in the background—users notice this. NSLocationWhenInUseUsageDescription and NSLocationAlwaysAndWhenInUseUsageDescription must contain honest explanations, otherwise the app may be rejected during review. Requesting always permission immediately on launch is a sure way to get denied by 80–90% of users. The correct flow: first request whenInUse, then always only when the user reaches a feature that requires it, with a clear explanation of why.

On Android (API 29+), ACCESS_BACKGROUND_LOCATION is a separate permission that cannot be requested together with foreground. First request foreground permission, then background separately. Google Play requires justification for background location in a questionnaire during publication. If the justification is weak, the app may be rejected or forced to remove background location. Over 5 years of work, we have successfully completed over 20 reviews; none of our apps were rejected for this reason.

Accuracy and Power Consumption: How to Avoid Battery Drain

Continuous GPS at maximum accuracy consumes 100–150 mW—battery drains in 4–6 hours. For most tasks, this is excessive.

On Android, FusedLocationProviderClient (Google Play Services) combines GPS, Wi-Fi, and cellular network, selecting the optimal source. LocationRequest.Builder with priorities:

• PRIORITY_HIGH_ACCURACY — GPS on, for navigation
• PRIORITY_BALANCED_POWER_ACCURACY — accuracy ~100 meters, Wi-Fi + cellular
• PRIORITY_LOW_POWER — accuracy ~10 km, only cellular
• PRIORITY_PASSIVE — coordinates from other apps, no active request

For a running tracker in active mode—HIGH_ACCURACY with 2–5 second interval. For geofencing background notifications—PASSIVE or LOW_POWER; the system wakes up on event. GPS accuracy is well-documented.

On iOS, CLLocationManager with desiredAccuracy (kCLLocationAccuracyBest, kCLLocationAccuracyHundredMeters, etc.) and distanceFilter—minimum movement in meters before next update. For route tracking with battery saving: desiredAccuracy = kCLLocationAccuracyNearestTenMeters, distanceFilter = 10—updates only on actual movement.

Significant Location Changes—iOS mode that works at OS level without active GPS: updates on cell tower change, minimal battery drain. Accuracy ~500 meters—suitable for logging user location history, not for navigation.

How to Choose a Mapping SDK? Comparative Analysis

Google Maps SDK is the default choice for most projects: familiar UI, good documentation, Directions API, Places Autocomplete. Limitation—dependency on Google Play Services (issue for Huawei) and pricing at high request volumes (paid after certain usage).

Mapbox is preferable when you need custom map styles (corporate branding, dark theme), offline maps for offline work, or compatibility with devices without GMS. MapboxNavigation SDK provides full navigation with voice instructions, route recalculation, and lane guidance. Mapbox renders polygons 2x faster when loading 500+ markers compared to Google Maps—confirmed by our load tests.

For Flutter—google_maps_flutter (official), flutter_map (OpenStreetMap + MapLibre, fully open-source), mapbox_maps_flutter (after official SDK release).

Example: App with Offline Maps and Geofences for 100+ Points

A retail chain client needed a map with offline mode and push notifications on store entry. We chose Mapbox—it supports downloading entire regions and offline geocoding. Result: zero network failures, 30% battery reduction due to PASSIVE mode.

Why Does Geofencing Have Delays?

Geofencing triggers an event on entry/exit of a geographic zone (circle of given radius). In practice, delay can be 1–3 minutes—the cost of energy efficiency.

On Android—GeofencingClient from Google Location Services. Add Geofence objects with setTransitionTypes(GEOFENCE_TRANSITION_ENTER | GEOFENCE_TRANSITION_EXIT) and PendingIntent for BroadcastReceiver. Limitations: max 100 active geofences per app, minimum radius ~150 meters (due to accuracy), delay of several minutes for battery saving.

On iOS—CLCircularRegion + CLLocationManager.startMonitoring(for:). Limit: 20 regions per app. The OS decides when to check—developer cannot control delay. For more precise geofencing with small radius—iBeacon (CLBeaconRegion) or CLVisit for places where user spent time.

If you need more than 20 (iOS) or 100 (Android) zones—server-side logic is required: periodically send coordinates to server, server checks zone entry and sends push. Less time-accurate but scales to thousands of zones. Geozone working principles are well-documented.

Route Tracking and Background Geolocation

Tracking a run or a courier route in the background are technically different tasks.

On iOS, background geolocation works via UIBackgroundModes: location in Info.plist. Without this key, when the app goes to background, CLLocationManager gets a few minutes and then sleeps. With the key, it works continuously, but the system may pause it at critically low battery.

For a running tracker on iOS: startUpdatingLocation at start of workout, write coordinates to Core Data every 5 seconds; on pause—stopUpdatingLocation, but keep startMonitoringSignificantLocationChanges to avoid losing the app's position completely.

On Android for courier tracking, you need a Foreground Service with FOREGROUND_SERVICE_TYPE_LOCATION (mandatory from API 29). Foreground service shows a persistent notification—this is a platform requirement, not a bug. Without it, Android Doze will kill location updates. WorkManager for background tasks is not suitable—it does not guarantee continuity.

Algorithmic part of route tracking: raw GPS coordinates are noisy. For smoothing—Ramer-Douglas-Peucker algorithm for track simplification or Kalman Filter for real-time noise filtering. Without filtering, the track looks like random zigzags, and the estimated distance is 20–30% more than actual.

How We Implement Maps and Geolocation: Step-by-Step Process

1. Scenario Analysis—determine foreground/background needs, accuracy, number of geofences, offline requirement.
2. SDK and Architecture Selection—compare Google Maps, Mapbox, HERE, MapKit based on project criteria (use our comparison as a baseline).
3. Integration and Permission Setup—configure Info.plist / AndroidManifest.xml, test review checks (App Store Review Guidelines Sections 4.2/5.1, Google Play policy).
4. Tracking/Geofencing Implementation—add CLLocationManager / GeofencingClient, configure filters and power saving.
5. Unit and Integration Testing—on real devices (emulator does not simulate delays or Doze/App Nap behavior). Test at least 50 scenarios.
6. Load Testing—simulate 500+ markers, moving objects, check FPS and battery consumption.
7. Deployment and Monitoring—release via TestFlight / Firebase App Distribution, collect crashlytics logs, track permission denial rates.

Timeline and Deliverables

What you get in any case:

• Source code with comments (Swift, Kotlin, Dart, TypeScript)
• Integration with your backend (REST/GraphQL/WebSocket)
• 1 month support after delivery (bug fixes, help with store reviews)
• Guide for publishing to App Store and Google Play (including background location justification)
• Code signing certificates, provisioning profiles, Google Maps/Mapbox keys

Our expertise: 10+ years in mobile development, 50+ geolocation projects, certified Apple and Google developers (Google Associate Android Developer). Every app undergoes triple code review and load testing.

Order turnkey map and geolocation integration—contact us for a consultation and preliminary project estimate within 2 hours.