The Company App: One Business System Across Every Apple Device

Context

Small businesses operating with 8–25 employees across warehouse, office, and field environments face a compounding coordination problem: operations, finances, and team communication live in separate systems that do not talk to each other. Warehouse staff track stock in a spreadsheet. Finance runs another for accounting. Orders live somewhere else. Team communication happens in messaging apps. Dispatch is logged on paper.

The result is stale data, fulfilment errors, missed payments, and a management layer that spends its time reconciling systems instead of running the business. No single source of truth exists.

Problem

The team operated across 6–8 tools: spreadsheets for inventory and accounting, messaging apps for team coordination, a separate purchase-order system, paper dispatch logs, and email for customer communication. No tool communicated with another. Finance could not see order status, warehouse staff could not see what was on order, and dispatch did not know what had been received.

The instinct is to solve this with a web platform and a shared database. The problem: warehouse connectivity is unreliable. A system that requires a server connection to function would fail at the point where it matters most — on the warehouse floor during a stock count or dispatch run.

Constraints

• —Warehouse connectivity is unreliable — fully offline operation was required, with automatic sync on reconnection
• —Multi-user concurrent writes required conflict resolution without a custom backend
• —Sensitive business data (supplier contacts, pricing, order volumes) could not transit third-party services
• —No IT department on the client side — zero-maintenance sync infrastructure was a hard requirement
• —iPad form factor needed to work in warehouse scanning contexts: large tap targets, minimal navigation depth

Architecture Approach

The constraint that shaped everything: warehouse staff cannot wait for a server response. Offline-first was not a feature request — it was the design premise. Every architectural decision flows from that.

Implementation: Offline-Aware UI State

Every view that shows synced data needs to communicate its sync state to the user — not as a banner, but inline. The pattern used across the app surfaces pending changes count and last-sync timestamp as lightweight metadata attached to each list item:

// Observe CloudKit sync events via NotificationCenter
// and surface pending record count to UI without blocking

class SyncMonitor: ObservableObject {
    @Published var pendingCount: Int = 0
    @Published var lastSyncDate: Date?

    init(container: NSPersistentCloudKitContainer) {
        NotificationCenter.default.addObserver(
            forName: NSPersistentCloudKitContainer
                .eventChangedNotification,
            object: container,
            queue: .main
        ) { [weak self] notification in
            guard let event = notification.userInfo?[
                NSPersistentCloudKitContainer.eventNotificationUserInfoKey
            ] as? NSPersistentCloudKitContainer.Event else { return }

            if event.succeeded {
                self?.lastSyncDate = event.endDate
            }
        }
    }
}

// In SwiftUI view: show offline badge when pending > 0
struct InventoryRowView: View {
    let item: InventoryItem
    @ObservedObject var syncMonitor: SyncMonitor

    var body: some View {
        HStack {
            VStack(alignment: .leading) {
                Text(item.name)
                Text("\(item.quantity) units")
                    .foregroundStyle(.secondary)
            }
            Spacer()
            if syncMonitor.pendingCount > 0 {
                Image(systemName: "arrow.triangle.2.circlepath")
                    .foregroundStyle(.orange)
                    .imageScale(.small)
            }
        }
    }
}

Solution Highlights

• •NSPersistentCloudKitContainer — zero-backend sync through Apple infrastructure, no server costs
• •Separate private/shared CloudKit stores with participant-role enforcement at the persistence layer
• •Unified schema for inventory, sales, purchase orders, accounting, dispatch, contacts, calendar, and chat
• •Accounting figures derived automatically from sales, purchase, receipt, and expense records
• •Team Chat and shared calendar synced through the same CloudKit container as operational data
• •Operations hub for cargo, warehouse assignments, dispatches, returns, defects, and expenses
• •Log-structured stock movements for conflict-safe concurrent inventory updates
• •Partial sync: field staff receive only their assigned dispatch subset via CloudKit record zones
• •iPad split-view layouts with large tap targets and offline-aware status indicators
• •Zero third-party dependencies — every SDK is a first-party Apple framework

CloudKit Sharing and Role Enforcement

Team members join through an iCloud sharing invitation. Their access level—contributor or viewer—is enforced through CloudKit participant roles at the persistence layer, not only by hiding controls in the interface.

The owner’s private store and shared company store use separate NSPersistentCloudKitContainer configurations. Operational data lives in the shared store while personal preferences remain private. Once a participant accepts, the shared zone mirrors to their device automatically, with no separate account system or sign-in flow beyond iCloud.

Key Technical Learnings

Technical FAQ