macOS Application Development — AppKit, SwiftUI & Hardware Integration
Native macOS apps that bridge hardware products to the desktop — companion apps, diagnostic tools, configuration managers, and professional-grade macOS software with hardware-accelerated performance.
What We Build on This Platform
Companion & Configuration Apps
Full-featured macOS companion apps that configure, update firmware on, and visualize data from hardware products over USB, BLE, and Wi-Fi. These are production-grade desktop applications, not web wrappers — native rendering, native controls, and direct hardware access.
AppKit & SwiftUI
Native UI in both AppKit for complex document-based and panel-driven interfaces and SwiftUI for modern declarative layouts with system-consistent design. Hybrid architectures allow existing AppKit code to be incrementally migrated to SwiftUI without a full rewrite.
Core Bluetooth Integration
Central role BLE scanning, connection management, characteristic read/write/notify, and service discovery for hardware accessory configuration and live data visualization. State restoration ensures the app reconnects to paired hardware after macOS wakes from sleep.
IOKit & DriverKit
Kernel-adjacent device drivers for USB HID, CDC, vendor-class, and PCIe peripherals using DriverKit user-space driver extensions. DriverKit replaces legacy KEXTs with a safer, sandboxed model that survives macOS major version upgrades without driver breakage.
Core ML & Metal
On-device inference with Core ML for audio, image, and sensor data, accelerated via the Apple Neural Engine and Metal GPU compute pipelines. Models compiled for Apple Silicon achieve substantially lower latency than cloud-round-trip inference for real-time hardware data processing.
XPC & Background Services
XPC service architecture for privilege separation, background daemons for hardware polling and data logging, and LaunchAgents for auto-start behavior. XPC isolates the privileged hardware communication layer from the UI process, limiting blast radius of any security vulnerability.
OTA Distribution & Notarization
App Store distribution and direct-distribution via Sparkle with Apple notarization, hardened runtime, and code-signing for enterprise deployment. Direct distribution is required for apps that need hardware entitlements incompatible with the App Store sandbox.
Continuity & Handoff
Handoff, Universal Clipboard, and AirDrop integration so hardware workflows that start on iPhone continue seamlessly on Mac. Continuity Camera enables Mac apps to use the iPhone camera as a high-resolution input device without additional hardware.
How Ankh Uses This Platform
Architecture Decision: AppKit vs. SwiftUI vs. Hybrid
Determined by UI complexity, deployment target, and whether the app is document-based. SwiftUI is chosen for modern single-window apps and settings panels; AppKit for complex multi-panel interfaces with inspector drawers, floating tool palettes, and split view hierarchies that have no clean SwiftUI equivalent. Hybrid architecture — SwiftUI views hosted inside NSViewControllers, or NSViewRepresentable wrappers for mature AppKit components — allows teams to adopt SwiftUI incrementally. Deployment target is set from the minimum macOS version the customer's installed base requires, which directly constrains which SwiftUI APIs are available without availability guards.
Hardware Communication Layer
USB communication is implemented via IOKit for user-space access or DriverKit for devices requiring kernel-adjacent control. BLE via Core Bluetooth with state restoration for background operation and reconnection after system wake. Serial/UART over USB CDC is handled through IOKit's IOSerialBSDClient. Network communication to the device's REST API or WebSocket uses URLSession with certificate pinning and mutual TLS for production hardware products where man-in-the-middle interception is a realistic threat. The communication layer is implemented as a standalone Swift package tested independently of the UI, enabling headless integration testing against hardware or simulators.
Data Architecture & Persistence
Core Data schema is designed for the sensor data volume and query patterns the product generates. CloudKit sync is configured for multi-device scenarios where the user's hardware configuration or historical data should appear on both Mac and iPhone. File coordination is implemented for document-based apps to handle concurrent access from multiple processes. iCloud Document storage enables user-owned data — calibration profiles, device configurations, exported session files — to sync transparently to iPhone and iPad without a custom backend.
Distribution & Signing
Mac App Store distribution is chosen for consumer-facing apps where discoverability and in-app purchase are valued and the sandbox entitlement restrictions are acceptable. Direct distribution using Developer ID signing and notarization is required for apps using IOKit, DriverKit, or other hardware entitlements the App Store sandbox prohibits. Sparkle provides an automatic update channel for direct-distribution builds with differential updates and rollback capability. MDM deployment configuration is prepared for enterprise IT teams distributing the app via Jamf or Apple Business Manager.
Performance Profiling with Instruments
CPU, memory, and GPU profiling with Instruments is performed before every major release. Background energy impact is measured with the Energy Log instrument to ensure the app does not appear in the macOS Energy Saver battery usage list. Core Bluetooth scan timing is profiled against battery impact on MacBook hardware — aggressive scan intervals that are acceptable on AC power become problematic on battery. Metal shader performance is verified against the target GPU tier, since shader code that performs well on an M-series GPU may reveal bottlenecks on older Intel-based Macs still within the deployment target range.
Deep Technical Capability
Universal Binary and Rosetta 2 Performance Parity
Universal Binary compilation — fat binaries containing both arm64 and x86_64 slices — is required for any macOS app that must run natively on both Apple Silicon Macs and Intel Macs still within the product's supported hardware range. The critical failure mode is shipping a single-architecture x86_64 binary and assuming Rosetta 2 translation provides adequate performance for hardware-adjacent tasks. Rosetta 2 adds measurable overhead to tight compute loops and serialized I/O operations; apps that decode sensor telemetry, perform DSP on audio data, or run Core ML inference see 20–40% throughput degradation under translation compared to native arm64 execution. At build time, the presence of both slices can be verified with `lipo -info`. At runtime, hardware detection via NXGetLocalArchInfo() lets the app select the appropriate compute path — Metal shader selection, Core ML compute unit preference, and memory-mapped I/O buffer sizing can all be conditioned on the active architecture. Benchmarking on both architectures before release is not optional for hardware-adjacent apps: performance regressions that only appear under Rosetta are the class of issue that generates the most user complaints and the hardest-to-reproduce support tickets.
DriverKit User-Space Drivers for Custom USB Peripherals
DriverKit is Apple's replacement for IOKit kernel extensions (KEXTs), implemented as user-space System Extensions that communicate with the kernel through a restricted IPC channel. The entitlement model is strict: com.apple.developer.driverkit is required at a minimum, and USB-specific entitlements (com.apple.developer.driverkit.transport.usb) must be provisioned through an explicit Apple entitlement request for third-party distribution. Matching dictionaries in the driver's Info.plist define which USB devices the driver binds to by VID/PID, device class, or device subclass. Bulk transfer implementation uses IOUSBHostPipe's asyncIO callbacks rather than synchronous transfer, as synchronous USB operations block the driver dispatch queue and prevent proper handling of device disconnection events. Vendor-class protocol implementation must account for USB reset behavior — the host controller may issue a port reset during device reconnection, and the driver must handle the resulting IOUSBHostDevice invalidation and re-enumeration sequence without crashing. Debugging DriverKit extensions requires attaching lldb to the SystemExtension process via `sudo lldb -p $(pgrep YourDriverExtension)`, since standard Xcode debug attachment does not work for System Extensions.
Hardened Runtime and Notarization for Direct-Distribution macOS Apps
The hardened runtime restricts the process's capabilities to a set of explicitly declared entitlements, and notarization requires that the submitted binary have the hardened runtime enabled. The tension arises for hardware-adjacent apps: IOKit user-client access, DriverKit extension loading, and certain CoreBluetooth behaviors require entitlements that conflict with the App Store sandbox but are permitted under Direct Distribution with Developer ID signing. The notarization submission workflow uses notarytool: the app bundle is archived, submitted with `xcrun notarytool submit`, and the log file inspected for HARD errors vs. informational issues. Common rejection causes include linked dylibs lacking the hardened runtime, embedded scripts that execute unsigned binaries, and use of deprecated code-signing flags. After notarization approval, the ticket is stapled to the app bundle with `xcrun stapler staple`, ensuring Gatekeeper can verify the notarization offline without contacting Apple's servers. The quarantine xattr added by Safari and web-downloaded DMGs triggers Gatekeeper on first launch; a properly stapled and signed app passes this check without user intervention, while an improperly signed app presents the 'unidentified developer' block dialog that most enterprise users cannot dismiss without admin credentials.
Products Built on This Platform
Wearable Electronics
Desktop companion app for device configuration, firmware update, and activity data visualization.
View ProductMedical Devices
Regulatory-grade macOS configuration and diagnostic tools for FDA-class hardware products.
View ProductWireless Communication
RF configuration and spectrum visualization tools using IOKit and Core Bluetooth.
View ProductCustom Audio & Video
Professional macOS apps using Core Audio, Metal, and AVFoundation for hardware A/V products.
View ProductAI Vision Systems
Core ML inference pipelines on macOS for on-device computer vision processing from connected cameras.
View ProductGPS Tracking
macOS fleet management dashboards consuming GPS telemetry from backend APIs.
View ProductHardware-adjacent macOS apps, not standalone consumer software
Every macOS app Ankh builds exists to make a hardware product more capable. We design the USB communication layer alongside the firmware team, align the Core Data schema with the sensor telemetry format, and ensure the macOS app can field-update firmware over DFU without requiring the user to download a separate utility. This means the companion app ships as part of the product — not as an afterthought added six months after hardware launch. We have built macOS apps that talk to hardware over IOKit, DriverKit, Core Bluetooth, and bare TCP sockets, and we know which path is correct for each peripheral class.
Architecture decisions that survive the next three macOS releases
macOS has deprecated IOKit KEXTs, shifted App Store policies, and introduced API availability restrictions on every major release for six consecutive years. Ankh structures macOS apps with explicit deprecation roadmaps: DriverKit replaces any KEXT dependency, SwiftUI adoption is staged against the deployment target, and AppKit APIs with announced deprecations are wrapped behind abstraction layers that can be swapped without UI rewrites. We track the macOS developer beta release notes as a matter of professional discipline, and we version APIs with availability annotations from the first line of code rather than retrofitting them before release.
Distribution paths that actually reach enterprise customers
Enterprise macOS deployment means MDM, Apple Business Manager, and IT departments that will not approve App Store installations for tools requiring hardware entitlements. Ankh produces both distribution paths — App Store and Developer ID — from the same codebase where possible, with a build configuration matrix that adjusts entitlement sets per target. We prepare the MDM configuration profile, the Managed Software Center manifest, and the Jamf policy package. We have navigated the notarization rejection process for apps using IOKit entitlements and know which entitlements require an explicit Apple exception request versus which are self-service.