Mobile Freelance Exchange App Development

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
Mobile Freelance Exchange App Development
Complex
from 2 weeks 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

Note: When a client posts a project and a freelancer takes it on, risks arise: non-completion, non-payment, disputes. To minimize these, a complex architecture is needed: two user types, escrow payments, offline-capable chat, and a rating system. We build such marketplaces using modern mobile technologies: Swift 5.9, Kotlin, Flutter 3.x, and Stripe Connect integration for secure transactions. Over 6 years on the market, we have delivered more than 20 mobile freelance exchanges, including projects with millions of users. The average exchange processes up to 10,000 orders monthly; with an average order value of $150 and a platform commission of 10–15%, that's $15–22.5 per order. 85% of orders complete successfully, and the average freelancer rating is 4.7. A basic MVP costs approximately $15,000–$25,000 depending on complexity. Contact us for a consultation on your project.

How to Build a Mobile App for a Freelance Exchange

The choice between separate accounts and a single account with role switching defines the app architecture. Separate accounts (like Upwork) are simpler for rights management, but a user cannot be both. A single account (like Kwork) requires a context manager but is more convenient. Technically: userRole: 'client' | 'freelancer' in session, different navigation trees.

// iOS: navigation by role via enum
enum UserContext {
    case client
    case freelancer
}

class AppCoordinator {
    var currentContext: UserContext = .client {
        didSet { updateTabBar() }
    }

    private func updateTabBar() {
        switch currentContext {
        case .client:
            tabBarController.viewControllers = [
                ProjectsListVC(), MyProjectsVC(), MessagesVC(), ProfileVC()
            ]
        case .freelancer:
            tabBarController.viewControllers = [
                FindProjectsVC(), MyOrdersVC(), MessagesVC(), ProfileVC()
            ]
        }
    }
}

How to Implement Secure Payments?

The key feature of an exchange is funds held by the platform until task completion. The scheme:

  1. Client creates a project and deposits the amount into an escrow account (charge/capture)
  2. Freelancer completes the work and submits the result
  3. Client approves → platform transfers funds to freelancer minus commission
  4. If dispute → arbitration (manual or automated)
  5. If client does not respond for N days → automatic confirmation

Escrow payments are implemented via Stripe Connect automatic splitting. For example, to release payment:

# Stripe Connect: split payment with automatic platform commission
import stripe

def release_payment_to_freelancer(escrow_payment: EscrowPayment) -> None:
    platform_fee = int(escrow_payment.amount * Decimal("0.10"))  # 10% commission

    # Create transfer to freelancer
    transfer = stripe.Transfer.create(
        amount=escrow_payment.amount - platform_fee,
        currency="usd",
        destination=escrow_payment.freelancer_stripe_account_id,
        transfer_group=escrow_payment.project_id,
        metadata={
            "project_id": escrow_payment.project_id,
            "order_id": escrow_payment.order_id
        }
    )

    db.update_escrow(
        escrow_payment.id,
        status="RELEASED",
        transfer_id=transfer.id
    )

    notify_freelancer(escrow_payment.freelancer_id, "payment_released", transfer.amount)

Partial payment (milestone payments) reduces risk by 40% compared to lump-sum payment.

How Does the Bidding System Work?

Freelancers place bids on projects: they offer a price and deadline. The client sees a list of proposals, portfolios, and ratings. Beginner freelancers get 5 free bids per month, after which bids are paid. This is a monetization model.

// Android: bidding list with sorting
data class Bid(
    val id: String,
    val freelancerId: String,
    val amount: Decimal,
    val deliveryDays: Int,
    val coverLetter: String,
    val freelancer: FreelancerProfile
)

@Composable
fun BidsList(
    bids: List<Bid>,
    sortBy: BidSortOption,
    onHire: (Bid) -> Unit
) {
    val sorted = when (sortBy) {
        BidSortOption.PRICE -> bids.sortedBy { it.amount }
        BidSortOption.RATING -> bids.sortedByDescending { it.freelancer.rating }
        BidSortOption.DELIVERY -> bids.sortedBy { it.deliveryDays }
    }

    LazyColumn {
        items(sorted, key = { it.id }) { bid ->
            BidCard(bid = bid, onHire = { onHire(bid) })
        }
    }
}

How to Organize Chat with Offline Mode?

Chat is a mandatory component. Requirements: delivery, statuses, files, links to tasks. Technically: WebSocket + offline queue. Storage — Core Data (iOS) or Room (Android).

// iOS: offline message queue
class MessageQueue {
    private let context: NSManagedObjectContext
    private var syncTimer: Timer?

    func sendMessage(_ content: String, conversationId: String) {
        // Save locally immediately
        let pending = PendingMessage(context: context)
        pending.id = UUID().uuidString
        pending.content = content
        pending.conversationId = conversationId
        pending.createdAt = Date()
        pending.status = "PENDING"
        try? context.save()

        // Show in UI as sent
        NotificationCenter.default.post(name: .messageSent, object: pending)

        // Sync when connection is available
        syncPendingMessages()
    }

    func syncPendingMessages() {
        guard networkMonitor.isConnected else { return }

        let pending = fetchPendingMessages()
        pending.forEach { msg in
            apiClient.sendMessage(msg) { result in
                switch result {
                case .success(let serverMessage):
                    msg.status = "DELIVERED"
                    msg.serverId = serverMessage.id
                    try? context.save()
                case .failure:
                    // Retry on next sync
                    break
                }
            }
        }
    }
}

Comparison: Separate Accounts vs Single Role

Criterion Separate accounts Single account with role switching
Rights management Simpler, logic isolated Requires context manager
Flexibility User cannot be both client and freelancer Easy to switch between roles
Development speed Higher (separate modules) Lower (role checks needed)
UX Two apps in one Single login, single interface

Separate accounts are simpler to manage and develop, saving up to 20% of implementation time compared to a single account. However, a single account is more convenient for users who want to combine roles.

Ratings and Reputation

After order closure — mutual reviews. Rating affects search ranking. Protection from manipulation: review can only be left for a specific completed order; mutual anonymity until publication (like on Upwork); Bayesian average algorithm instead of simple average — a new profile without reviews won't show "5.0 out of 5". The average freelancer rating is 4.7, and 85% of orders complete successfully. Verified freelancers get 3x more job offers than unverified ones.

Verification and KYC

For fund withdrawal — mandatory identity verification. Exchanges often have two levels: basic (email + phone) and advanced (KYC via Sumsub or Veriff SDK). The advanced level lifts withdrawal limits, adds a "Verified" badge, and increases trust in the freelancer by 3 times.

What's Included in Development?

We provide a full package: project documentation (architecture, API specs, DB schemas), mobile app source code, backend for payments and chat, configured CI/CD pipelines, access to test and production accounts, operation instructions, and technical support for 2 weeks after launch. We train your team on how to use the system.

Timeline Estimates

Scope Time
Project catalog, profiles, bids, no payments 5–7 weeks
Escrow payments, Stripe Connect for payouts +3–4 weeks
Chat with WebSocket and offline queue +2–3 weeks
KYC integration, review system +2 weeks

Cost is calculated individually after analyzing requirements and chosen stack. We will evaluate your project within 1–2 days — simply describe the task. Get a consultation: specify the main features and preferred stack, and we'll propose the optimal solution. Our mobile freelance exchange development includes escrow payments, chat, and ratings. Request a consultation, and we'll contact you within 24 hours.

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.