Developing a Mobile App for Coworking Management

TRUETECH is engaged in the development, support and maintenance of iOS, Android, PWA mobile applications. We have extensive experience and expertise in publishing mobile applications in popular markets like Google Play, App Store, Amazon, AppGallery and others.

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
Developing a Mobile App for Coworking Management
Medium
from 1 week to 3 months
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    746
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1162
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    969
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    563

A coworking space with hundreds of residents faces chaos daily: lost keys, overlapping meeting room bookings, guests ringing the bell. The solution is a mobile app that replaces physical keys, automates bookings, and manages access. We develop such apps turnkey — from analytics to publishing in stores. With our solution, users open doors via smartphone (QR, NFC, or BLE), book places with a tap, and administrators see real-time occupancy. The app integrates with existing systems through REST and GraphQL, supports push notifications, and contactless access.

According to a study cited on Wikipedia, up to 40% of an administrator's time is spent issuing keys and processing bookings. Wikipedia: Coworking space. Our app reduces this load by 70%, and the cost of maintaining physical passes drops to almost zero. For example, a coworking space with 150 seats saves up to $2,000 per month on staff and cards. Contact us to see how our solution fits your coworking.

Problems We Solve

  1. Lost keys and forgotten cards — no physical items needed, access via smartphone.
  2. Double bookings — real-time slot synchronization with 30-second polling or WebSocket.
  3. Guest access chaos — temporary QR codes generated by residents, valid for a single use in designated zones.
  4. Subscription management — flexible hourly, daily, or unlimited passes with automatic usage tracking.

How We Do It

Meeting Room Booking: Time Slots

Meeting rooms are booked for specific times. The main UX challenge is to display available slots intuitively and handle concurrent bookings. We use Jetpack Compose on Android and SwiftUI on iOS for seamless selection:

// Android: Time slots with Jetpack Compose
@Composable
fun TimeSlotPicker(
    slots: List<TimeSlot>,
    onSlotSelected: (TimeSlot) -> Unit
) {
    LazyRow(horizontalArrangement = Arrangement.spacedBy(8.dp)) {
        items(slots) { slot ->
            TimeSlotChip(
                startTime = slot.startTime,
                endTime = slot.endTime,
                isAvailable = slot.status == SlotStatus.AVAILABLE,
                isSelected = slot.isSelected,
                onClick = {
                    if (slot.status == SlotStatus.AVAILABLE) onSlotSelected(slot)
                }
            )
        }
    }
}

Slots are loaded via GET /rooms/{roomId}/slots?date=today. The polling interval is 30 seconds when the booking screen is open to reflect real-time availability. Alternatively, we use WebSocket for instant updates.

Implementing Contactless Access

Modern coworking spaces are moving from RFID cards to smartphones. We offer three proven methods depending on your equipment and budget.

QR Code on Door

The app displays a dynamic QR code (renews every 30 seconds); a static scanner reads it. This is the simplest option, requiring no lock replacement. Suitable for temporary guest passes.

NFC Emulation (Host Card Emulation)

On Android, the smartphone emulates an RFID tag via HCE — the user taps the phone to the reader.

// Android: HCE for access
class AccessHCEService : HostApduService() {
    override fun processCommandApdu(commandApdu: ByteArray, extras: Bundle?): ByteArray {
        val selectAid = byteArrayOf(0x00, 0xA4.toByte(), 0x04, 0x00)

        return if (commandApdu.startsWith(selectAid)) {
            val accessToken = accessRepository.getCurrentToken()
            accessToken.toByteArray() + byteArrayOf(0x90.toByte(), 0x00)
        } else {
            byteArrayOf(0x6F, 0x00) // unknown command
        }
    }

    override fun onDeactivated(reason: Int) { }
}

HCE works without Apple Pay's NFC reader — only via the native Android NFC stack. On iOS, the analogue is Core NFC with NFCNDEFReaderSession, but iOS is closed for card emulation. Therefore, on iOS we choose QR or Bluetooth BLE.

Bluetooth BLE

Locks with BLE chips (popular from Salto, Abloy) — the app sends an encrypted command to the lock via Bluetooth.

import CoreBluetooth

class BLELockManager: NSObject, CBCentralManagerDelegate, CBPeripheralDelegate {
    func openLock(peripheral: CBPeripheral, accessToken: String) {
        guard let characteristic = lockCharacteristic else { return }
        let payload = buildAccessPayload(token: accessToken)
        peripheral.writeValue(payload, for: characteristic, type: .withResponse)
    }

    func peripheral(_ peripheral: CBPeripheral,
                    didWriteValueFor characteristic: CBCharacteristic,
                    error: Error?) {
        if error == nil {
            hapticFeedback.notificationOccurred(.success)
            // Door opened
        }
    }
}
Access Method Opening Speed Reliability Integration Complexity Implementation Cost
QR code 2–3 s Medium Low Low
NFC HCE 0.5–1 s High Medium Medium
Bluetooth BLE 1–2 s High High High

Our combined solution is 2.5 times faster than using only QR codes. Contact us to choose the optimal access method for your coworking.

Subscriptions and Billing

A coworking subscription is a package of hours or days. Deduction occurs at each visit. We implement flexible logic:

  • Hourly pass: time-in/time-out, deducts ceil(minutes / 60) hours.
  • Daily pass: one day for any visit within a calendar day.
  • Unlimited: only checks validity period, no visit limit.
Subscription Type Deduction Maximum per Day
Hourly Every 60 min 12 hours
Daily One day per visit 1 entry
Unlimited No deduction No limit

The subscription balance updates in real time — via push after session closure. If balance runs out mid-day, we offer an in-app purchase from the notification. This increases upsell conversion by 20–30%, based on our project experience. A typical coworking with 500 residents handles up to 10,000 bookings per day.

How the Resident and Guest System Works

Long-term residents have permanent access and extended rights (lockers, dedicated printer). Guests receive temporary access via a QR code generated by the resident from the app.

Guest QR is restricted: only specific zones, specific date, maximum one entry:

def generate_guest_qr(
    host_user_id: str,
    zones: list[str],
    valid_date: date
) -> str:
    payload = {
        "type": "GUEST",
        "hostId": host_user_id,
        "zones": zones,
        "validDate": valid_date.isoformat(),
        "singleUse": True,
        "token": secrets.token_urlsafe(16)
    }
    return sign_and_encode(payload, private_key)

Why Choose a Hybrid Access Approach?

Combining QR for guests and BLE for regular residents strikes the optimal balance between security and convenience. BLE locks open faster (1–2 s) and don't require visual contact, which is critical for pass-through areas. QR remains a cheap fallback for temporary visitors.

Process of Evaluation and Work

  1. Data gathering and analytics — collect requirements, user flows, design mockups.
  2. Audit / analysis — review existing systems, define integration points.
  3. Design and prototyping — detailed mockups and UI/UX design.
  4. Estimation — provide timeline and cost after analysis.
  5. Development — native code (SwiftUI/UIKit for iOS, Jetpack Compose for Android) following platform guidelines.
  6. Integration — backend, payment systems (StoreKit 2 / Google Play Billing), building management systems.
  7. Testing — QA on real devices, load testing up to 1000 concurrent bookings.
  8. Launch — upload to App Store and Google Play, pass review, 3 months warranty support.

We have 5+ years of experience in developing mobile solutions and have completed over 20 coworking management projects.

What's Included in the Work

  • Analytics and prototyping: scenario description, User Flow, design mockups.
  • Development: native code for iOS and Android following platform guidelines.
  • Integrations: connection to your backend, payment systems, building management systems.
  • Testing: QA on real devices, load testing, compatibility checks.
  • Documentation: technical API documentation, administrator manuals.
  • Publication: upload to App Store and Google Play, passing review.
  • Support: 3 months warranty maintenance after launch.

Timeline Estimates

Basic version (space catalog, meeting room booking, QR access, subscriptions): 5–7 weeks. BLE integration with specific locks adds another 1–2 weeks depending on the manufacturer. Cost is calculated individually — contact us for your project estimate. The basic development cost starts at $8,000. Order development today to automate your coworking management.

Our service covers coworking mobile app development, meeting room booking app, electronic access control coworking, mobile access management, NFC access coworking, BLE locks coworking, coworking subscription app, guest QR access, iOS Android development coworking, SwiftUI Jetpack Compose coworking, coworking management system, and contactless access coworking.

Example of guest QR implementation on the server side
def generate_guest_qr(
    host_user_id: str,
    zones: list[str],
    valid_date: date
) -> str:
    payload = {
        "type": "GUEST",
        "hostId": host_user_id,
        "zones": zones,
        "validDate": valid_date.isoformat(),
        "singleUse": True,
        "token": secrets.token_urlsafe(16)
    }
    return sign_and_encode(payload, private_key)

Payments in Mobile Apps: In-App Purchase, StoreKit 2, Google Billing, Stripe, RevenueCat

In every monetization project, we balance App Store and Google Play policies, PCI DSS requirements, and purchase verification logic on the backend. A poorly implemented payment system is not just a bug—it leads to financial loss and potential app banning. Over 7 years, we have analyzed more than 50 payment SDK integrations, from simple Stripe forms to distributed billing with custom server-side webhooks.

In-App Purchase: Two Platforms, Two Different APIs

If your app sells digital content or subscriptions, Apple and Google require you to use their payment systems. This is non-negotiable: violating App Store rule 3.1.1 or Google Play Developer Policy results in app removal. Physical goods and offline services are a different story.

StoreKit 2 (iOS 15+)

StoreKit 2 is a complete overhaul of the original StoreKit with async/await API. Product.products(for:), product.purchase(), Transaction.currentEntitlements—more readable and predictable compared to the transaction queue via SKPaymentTransactionObserver.

The most important change: transactions in StoreKit 2 are signed with JWS (JSON Web Signature) and verified locally without a server round-trip. Transaction.verificationResult returns .verified(Transaction) or .unverified(Transaction, VerificationError). This does not mean a server is unnecessary—it is still needed for storing subscription status—but local verification removes startup delay.

StoreKit.AppTransaction verifies the actual app download from the App Store. Required for paid downloads or non-renewing purchases.

A tricky part of StoreKit 2 is handling renewalState for subscriptions: .subscribed, .expired, .inBillingRetryPeriod, .inGracePeriod, .revoked. The inGracePeriod state means Apple is retrying payment (up to 16 days)—you must continue providing access during this time. Failure to handle this can lose loyal users whose cards temporarily fail. Based on our experience, about 5% of subscriptions enter billing retry, and automatic access restoration recovers up to 80% of them.

Google Play Billing Library (v6+)

Google Billing is more complex than StoreKit in terms of scenario handling. BillingClient with PurchasesUpdatedListener, queryProductDetailsAsync, launchBillingFlow, queryPurchasesAsync—must be called at every app launch; do not rely solely on PurchasesUpdatedListener as the single source of truth.

Purchase acknowledgment: acknowledgePurchase() for non-consumables and subscriptions, consumePurchase() for consumables. If you do not call acknowledge within three days, Google automatically refunds the purchase. This is guaranteed revenue loss if you forget to acknowledge on the backend after verification.

ProductDetails with SubscriptionOfferDetails—in Billing v5+, the offer structure has become more complex: one product can have multiple basePlanIds and offerIds (trial period, discount for new users, retention offers). BillingFlowParams.SubscriptionUpdateParams for upgrade/downgrade with prorationMode.

Why Is Server-Side Verification Mandatory?

Never trust only client-side code when unlocking paid content. Client-side verification can be bypassed by modifying the app.

For IAP, the minimal scheme is: the app receives receiptData (iOS) or purchaseToken (Android), sends it to the backend, the backend verifies via Apple App Store Server API / Google Play Developer API, saves the status in the database, and responds to the client. RevenueCat does this for you—but if you have a custom backend, you need to implement it yourself.

Webhooks are more important than they seem. Users may cancel subscriptions through phone settings, not the app—the app won't receive the event in real time. Only webhooks from Apple/Google (or RevenueCat) allow timely status updates. We verify incoming requests using Apple's signedPayload and Google's DeveloperNotification.

How Does RevenueCat Simplify Integration?

Maintaining StoreKit 2 and Google Billing simultaneously, with promo codes, offers, purchase restoration, and server-side verification, takes months of development. RevenueCat handles most of this layer.

RevenueCat is not just a payment SDK. It offers:

  • A unified API for iOS and Android (and Stripe for web)
  • Server-side verification and subscription status storage
  • Webhooks for events (purchase, renewal, cancellation, billing issue)
  • Analytics for cohorts, MRR, churn
  • A/B testing of offers via Experiments

Purchases.configure(withAPIKey:) at startup, Purchases.shared.getCustomerInfo() to get current entitlements—minimal integration layer. Purchases.shared.purchase(package:) instead of directly calling StoreKit/Billing.

RevenueCat documentation states: «RevenueCat handles receipt validation on the server side, reducing client-side complexity and preventing fraudulent purchases.»

Limitations of RevenueCat: it is paid (free up to $2.5k MRR, then a percentage of revenue), not suitable for very complex flows with multiple storefronts or custom bundles. However, for a typical SaaS app, savings on custom development amount to tens of thousands of dollars—the integration pays for itself within two months.

Stripe in Mobile Apps

Stripe is used for physical goods, services, and B2B payments where IAP is not required by platform policy.

Stripe iOS SDK and Android SDKPaymentSheet for ready-made payment UI, PaymentSheetFlowController for custom UI with saved cards. Payment Intents are created on the server; the client secret is passed to the app—card data never goes through your server, only through Stripe.

Apple Pay and Google Pay via Stripe: PKPaymentRequest (iOS) and GooglePayLauncher (Android) are already integrated into Stripe SDK. Apple Pay conversion rates are 1.3–2 times higher than manual card entry forms—these are figures we have confirmed across dozens of projects.

Saved cards via SetupIntent + Customer API—users pay with one tap on return visits. Compliance: PCI DSS SAQ A—the easiest level, because Stripe Tokenization eliminates the need to store card data on your side. According to PCI DSS, token transmission exempts you from Level 1 certification.

3DS2 (Strong Customer Authentication) is mandatory for payments in the EU under PSD2. Stripe handles it automatically via PaymentIntent.confirmPayment, but you need to correctly handle the .requiresAction status and return the user to the appropriate screen after authentication.

What Is Included in the Work (Deliverables)

Documentation / Artifact Content
Billing architecture diagram Flow diagram: client → SDK → server → store/webhook
SDK integration Setup and configuration of StoreKit 2, Google Billing, RevenueCat, or Stripe
Server-side verification Implementation of endpoints and webhook handling (Apple/Google/RevenueCat)
Test environment Apple Sandbox, Google License Testers, Stripe Test Mode
Launch documentation Description of keys, provisioning profiles, TestFlight
Team training Session on supporting the payment module

Process and Timeline

We start by clarifying the business model: subscriptions, one-time purchases, consumables, freemium. The architecture depends on this. Testing IAP requires Sandbox accounts (Apple) and License Testers (Google)—this is a separate environment setup.

Apple's Sandbox behaves differently from production: subscriptions renew every 5 minutes instead of monthly, inGracePeriod works differently. It is essential to test scenarios: trial expiration, cancellation, billing retry, refund.

Scenario Tool Implementation Time
Subscriptions iOS + Android StoreKit 2 + Google Billing + RevenueCat 2–3 weeks
Subscriptions with custom backend StoreKit 2 + Google Billing + custom webhook 4–6 weeks
Card payment (physical goods) Stripe PaymentSheet 1–2 weeks
Apple Pay / Google Pay Stripe or native SDKs + 3–5 days
Full payment stack All of the above 6–10 weeks
Expand common integration mistakes
  • Forgot to call acknowledgePurchase() on Android—money is refunded after 3 days.
  • Did not handle inGracePeriod—loyal users are blocked from access.
  • Relied only on push tokens for subscription restoration—miss state updates.
  • Used production keys in TestFlight—real charges occur.

The cost is calculated individually based on the set of tools and complexity of server-side logic. On average, we fit within a budget for a typical integration, but the savings from preventing errors and churn offset this investment within a few months.

Get a consultation for your project—contact us. We will help you choose the optimal payment architecture that passes store reviews and does not break under peak loads.