Why We Built for Apple: Privacy, Security, and Trust

When we set out to build KinArchive, we had a fundamental choice: use cross-platform frameworks to reach the widest audience fastest, or build native for a single ecosystem that aligned with our values. We chose Apple—and this article explains why.

KinArchive is built 100% on Apple technologies. No React Native. No Flutter. No Electron web views. Pure Swift, SwiftUI, CloudKit, and the native iOS frameworks that Apple provides. Here's the technical and philosophical reasoning behind that decision.

The Privacy Architecture

Family documents are some of the most sensitive data people have. Passports, medical records, insurance policies, wills—these aren't photos or notes. Mishandling this data isn't just a privacy violation; it could enable identity theft, insurance fraud, or worse.

We needed an architecture where:

• User data never touches our servers
• We can't access user documents even if we wanted to
• Users don't have to trust us—they only have to trust Apple

CloudKit Private Database

When you use KinArchive, your documents are stored in YOUR iCloud account, using YOUR iCloud storage quota, encrypted with YOUR Apple ID. We don't have a server with your documents. We don't have database backups of your sensitive files. We literally cannot access your data.

This isn't a policy choice—it's an architectural constraint. The Private Database is encrypted end-to-end, and only the user's authenticated devices can decrypt it.

No Third-Party Analytics

Many apps include third-party analytics SDKs that track user behavior and send data to external services. These SDKs often collect more than developers realize—device identifiers, location data, usage patterns.

KinArchive includes zero third-party analytics. We don't use Firebase Analytics, Mixpanel, Amplitude, or any other tracking service. The only analytics we receive are Apple's anonymized, aggregate App Store metrics.

Biometric Security: Face ID and the Secure Enclave

KinArchive uses Face ID (or Touch ID on older devices) for authentication. But what does that actually mean technically?

The Secure Enclave

Apple devices contain a dedicated security processor called the Secure Enclave. This is a separate chip with its own encrypted memory, isolated from the main processor. Your biometric data—the mathematical representation of your face or fingerprint—never leaves the Secure Enclave.

This is fundamentally different from apps that implement their own biometric scanning. We don't process, store, or transmit any biometric information. We simply ask iOS: "Is this the authorized user?" and iOS tells us yes or no.

Payment Processing: StoreKit 2

KinArchive offers subscription plans through the App Store. We use StoreKit 2, Apple's latest in-app purchase framework.

What This Means for Your Payment Data

Notice what's missing: we never see your credit card number, billing address, or payment details. Apple handles the entire transaction. We receive a cryptographically signed receipt that proves you have a valid subscription—nothing more.

This is Apple's standard App Store model, but it's worth emphasizing: for an app handling sensitive family documents, never touching payment data is an important security property.

Why Native Matters

Cross-platform frameworks like React Native and Flutter allow developers to write code once and deploy to multiple platforms. They're popular for good reasons—faster development, shared codebases, lower costs.

But for a security-focused app handling sensitive documents, native development offers critical advantages:

Direct Access to Security APIs

Cross-platform frameworks wrap native APIs in abstraction layers. These layers can introduce bugs, lag behind OS updates, and sometimes expose security vulnerabilities that wouldn't exist in native code.

By building native, we have direct access to:

• LocalAuthentication: Face ID/Touch ID with full Secure Enclave integration
• Security.framework: Keychain Services for credential storage
• CloudKit: Direct integration with iCloud's encryption
• CryptoKit: Apple's native cryptography library

No JavaScript Bridge Vulnerabilities

React Native apps communicate between JavaScript and native code through a "bridge." This bridge has historically been a source of security vulnerabilities—JavaScript injection, bridge hijacking, data leakage through the bridge layer.

KinArchive has no JavaScript, no bridge, no web views. It's compiled Swift code running directly on the device.

OS-Level Optimizations

Native apps benefit from OS-level optimizations that cross-platform apps can't fully leverage:

• Background App Refresh: Proper integration with iOS power management
• Memory management: Swift's ARC works seamlessly with iOS memory handling
• Launch performance: No framework initialization overhead
• Widget integration: Native WidgetKit for home screen expiration alerts

The SwiftUI Interface

KinArchive's UI is built entirely in SwiftUI, Apple's modern declarative framework. This means:

• Automatic accessibility: VoiceOver support, Dynamic Type, and other accessibility features work out of the box
• Native look and feel: Buttons, navigation, and interactions match iOS conventions
• Automatic dark mode: System appearance settings are respected automatically
• Performance: SwiftUI is optimized for iOS rendering pipelines

What We Traded Off

Building native for Apple wasn't without costs:

• No Android version: We can't serve Android users (yet)
• No web app: Desktop users can't access documents from a browser
• Higher development costs: Native development takes longer than cross-platform
• Smaller addressable market: iOS is ~27% of the global mobile market

We made these tradeoffs consciously. For an app handling sensitive family documents, we believe the security and privacy properties of the Apple ecosystem outweigh the reach of cross-platform approaches.

The Apple Ecosystem Alignment

Building for Apple isn't just about technology—it's about values alignment.

Apple has staked its brand on privacy. "Privacy is a fundamental human right" isn't just marketing; it's reflected in architectural decisions throughout iOS: App Tracking Transparency, Privacy Nutrition Labels, on-device processing for Siri and Photos, and the Secure Enclave.

When you use KinArchive, you're extending trust to two entities: us (for the app logic) and Apple (for the platform). By building entirely on Apple technologies, we minimize the trust surface. Your data stays in Apple's ecosystem, protected by Apple's security model, encrypted with Apple's cryptography.

We're not asking you to trust a third-party cloud provider, a third-party analytics company, or a third-party payment processor. We're asking you to trust Apple—which you already do by using an iPhone—and us for the application logic that runs on top.

Future-Proofing

Apple's platform continues to evolve. By building native, we can adopt new technologies as they're released:

• New security features: As iOS security improves, KinArchive inherits those improvements
• New APIs: Direct access to new frameworks without waiting for cross-platform support
• Performance improvements: Swift and iOS optimizations benefit us automatically
• New devices: iPad, Mac (via Catalyst or native), Apple Watch integration

Conclusion

Building KinArchive for Apple wasn't the fastest path or the easiest path. But it was the right path for an app entrusted with families' most sensitive documents.

When you store your passport in KinArchive, you're not trusting your data to an unknown cloud provider. You're storing it in your own iCloud account, encrypted with your own Apple ID, protected by your own Face ID. We built the governance layer—the expiration tracking, the permissions, the audit trails—on top of Apple's security foundation.

That's why we built for Apple. That's why your data is safe.