MemoKit, the API we desperately need.
Or What Google's AirDrop Hack Taught Me About Apple's Walled Garden
When Google reverse-engineered AirDrop, it clarified something about building on Apple’s platforms: some walls can be climbed with enough resources. Others exist because Apple chooses to maintain them.
We’re a small team about to launch an audio organization app for iOS. We’ve spent the past three years building features that Voice Memos doesn’t offer—tags, smart collections, advanced search. Features that no one asked but we wanted. Our beta users so far love the organization capabilities, but one question for us and for our users keeps popping up: “Why can’t this just automatically import my Voice Memos recordings like I can with Photos?”
The answer reveals a pattern in how Apple controls platform access. On November 20, 2025, Google shipped AirDrop compatibility to Android devices by reverse-engineering Apple’s proprietary AWDL protocol. It required significant resources—dedicated engineering teams, legal expertise, security audits, and EU regulatory cover. But Google succeeded because AirDrop is a network protocol they could implement independently on Android.
Voice Memos is different. The files sit in /private/var/mobile/Media/Recordings/ completely inaccessible to third-party apps through iOS sandboxing. No amount of reverse-engineering changes this. The only way Voice Memos becomes accessible is if Apple builds an API. After 16 years, they haven’t.
Building an Audio Organization App
Voice Memos is intentionally simple: record, play, basic editing. For users recording dozens or hundreds of memos, this becomes unmanageable. Our app addresses this with organization features:
Tags and categories: Label recordings by project, topic, or custom taxonomy
Smart collections: Auto-populate collections based on rules (recordings from last week, all tagged “meeting,” recordings over 10 minutes)
Advanced search: Filter by metadata, date ranges, duration, or tag combinations
Library management: Tools for organizing large audio collections similar to how Photos manages images
We built these features for beta users who record extensively—researchers, journalists, students, professionals who accumulate hundreds of voice notes. Voice Memos lacks organization tools beyond a chronological list with basic text search.
The technical challenge isn’t building these features. It’s accessing Voice Memos recordings in the first place.
The API That Doesn’t Exist
Here’s what we wish we could write:
| import MemosKit | |
| func syncVoiceMemos() async throws -> [Recording] { | |
| let status = await VMMemoLibrary.requestAuthorization() | |
| guard status == .authorized else { return [] } | |
| let fetchOptions = VMMemoFetchOptions() | |
| fetchOptions.sortDescriptors = [ | |
| NSSortDescriptor(key: "creationDate", ascending: false) | |
| ] | |
| let memos = VMMemo.fetchMemos(with: fetchOptions) | |
| var recordings: [Recording] = [] | |
| for memo in memos { | |
| let recording = Recording( | |
| id: memo.localIdentifier, | |
| title: memo.title, | |
| duration: memo.duration, | |
| creationDate: memo.creationDate, | |
| fileURL: memo.fileURL | |
| ) | |
| recordings.append(recording) | |
| } | |
| return recordings | |
| } |
This framework doesn’t exist. There’s no `MemosKit`, no permission system, no programmatic access to Voice Memos metadata or files. Apple already built exactly this API—for photos. PhotoKit provides comprehensive, privacy-preserving access to the Photos library:
| import Photos | |
| func syncPhotos() async throws -> [Photo] { | |
| let status = await PHPhotoLibrary.requestAuthorization(for: .readWrite) | |
| guard status == .authorized else { return [] } | |
| let fetchOptions = PHFetchOptions() | |
| fetchOptions.predicate = NSPredicate( | |
| format: "creationDate >= %@", | |
| Calendar.current.startOfDay(for: Date()) as CVarArg | |
| ) | |
| fetchOptions.sortDescriptors = [ | |
| NSSortDescriptor(key: "creationDate", ascending: false) | |
| ] | |
| let assets = PHAsset.fetchAssets(with: fetchOptions) | |
| var photos: [Photo] = [] | |
| assets.enumerateObjects { asset, _, _ in | |
| let photo = Photo( | |
| id: asset.localIdentifier, | |
| creationDate: asset.creationDate, | |
| location: asset.location, | |
| width: asset.pixelWidth, | |
| height: asset.pixelHeight | |
| ) | |
| photos.append(photo) | |
| } | |
| return photos | |
| } |
This code works. PhotoKit queries thousands of photos instantly by reading only metadata—actual image files stay on disk until explicitly requested. The framework provides:
Permission model: Users explicitly grant library access (read-only, read-write, or limited selection)
Metadata-first architecture: Apps query without loading full files
Change notifications: Apps observe library changes without polling
Optimized delivery: Request images at specific sizes, PhotoKit handles transcoding
All of this could apply to Voice Memos. Apple demonstrates they know how to build privacy-preserving media APIs. They built PhotoKit for photos. They haven’t built an equivalent for voice recordings.
What We Built Instead
We solved importing through the mechanisms iOS provides: Files app integration and Share Sheet. Users can import Voice Memos recordings through iOS’s document picker or by sharing directly from Voice Memos to our app. We built duplicate detection and handle the metadata extraction from the M4A files themselves.
These workarounds function, but they require manual steps. Users expect automatic sync—they record in Voice Memos throughout the day, then open our app expecting to see those recordings organized. Instead, they must manually import.
The import process works reliably. But the fundamental limitation remains: no programmatic discovery of Voice Memos recordings. Every import requires explicit user action per session.
The AirDrop Parallel
Google’s AirDrop achievement provides context for understanding platform control.
AirDrop uses AWDL (Apple Wireless Direct Link), Apple’s proprietary mesh networking protocol. It was completely undocumented until 2018, when researchers at TU Darmstadt—Milan Stute, David Kreitschmann, and Matthias Hollick—published comprehensive reverse-engineering research. Their MobiCom 2018 paper, “One Billion Apples’ Secret Sauce: Recipe for the Apple Wireless Direct Link Ad hoc Protocol,” documented AWDL’s time-synchronized Availability Windows, mesh networking architecture, and integration with Bluetooth LE and Wi-Fi Direct.
Google used this research to build production AirDrop compatibility for Android.
This required resources individual developers don’t have: dedicated engineering teams, legal expertise, ability to modify Android’s core networking, and months of development time. Google succeeded because they had these resources and because AirDrop is a network protocol they could implement independently on Android.
Apple’s silence on Google’s implementation likely relates to regulatory pressure. The EU’s Digital Markets Act Article 6(7) requires gatekeepers to “allow providers of services and providers of hardware, free of charge, effective interoperability” with iOS features. The June 1, 2026 deadline specifically includes “close-range wireless file transfers,” making AirDrop interoperability a regulatory requirement, not a courtesy.
Technical Barriers as Economic Barriers
The AirDrop case demonstrates that technical barriers often reflect economic barriers.
What made AirDrop “impossible” to reverse-engineer wasn’t technical complexity. The protocol uses open standards (Bluetooth LE, Wi-Fi Direct) with a proprietary coordination layer that academic researchers documented. What made it impossible for most was cost:
- Engineering resources for months of development
- Legal expertise for clean-room implementation
- System-level access to modify networking stacks
- Security audit capabilities
- Ongoing maintenance when Apple updates the protocol
Google had all of these. Most developers have none.
Voice Memos represents a different barrier. Even with Google’s resources, iOS sandboxing prevents third-party access to /private/var/mobile/Media/Recordings/. The files aren’t protected by obscure protocols—they’re protected by iOS’s fundamental security architecture. No reverse-engineering overcomes this. The only solution is Apple building an API.
The Pattern: Strategic API Availability
Examining which APIs exist reveals a pattern. Comprehensive APIs exist for:
Photos (PhotoKit): Photos are social, shared, and central to user experience. Locking them down completely would drive users to competitors.
Health (HealthKit): Apple positioned health as an ecosystem differentiator. Third-party apps make the Health app more valuable.
Calendar/Reminders (EventKit): Required for Siri integration and productivity workflows.
No APIs exist for:
Voice Memos: No strategic pressure for 16 years
Notes: Limited sharing extensions only, no query API for bulk access
The dividing line appears to be strategic value rather than technical capability or privacy concerns. PhotoKit proves Apple can build privacy-preserving frameworks for user-generated media. The architecture exists. The question is priority.
What Would Need to Change
For Voice Memos, the forces that drove AirDrop interoperability don’t exist:
No regulatory pressure: The EU DMA targets high-impact interoperability (messaging, file sharing, app stores). Voice Memos APIs aren’t on regulatory agendas.
There is no competitive pressure: Users don’t switch platforms over voice memo access.
There is no market pressure: Most users don’t know these APIs could exist.
The API gap will likely persist until one of these forces changes. Based on 16 years without movement, this seems unlikely.
We’ve built an audio organization app that solves real problems for users who manage large voice recording collections. We’ve implemented reliable importing through the mechanisms iOS provides. But the fundamental limitation remains: Voice Memos has no programmatic API.
Google’s AirDrop reverse-engineering clarified that platform restrictions are often choices rather than technical necessities. Apple built PhotoKit for photos, proving they know how to create privacy-preserving media APIs. They could build the same for Voice Memos.
The difference is strategic priority. Photos required comprehensive APIs because of their social importance. Voice Memos hasn’t required APIs because no sufficient pressure exists to justify the development cost.
For our team, this means building around the gaps. We’ve solved importing through manual workflows that function reliably. Our beta users appreciate the organization features enough to accept the import limitation. But automatic sync remains the most requested feature we can’t build.
The technical capability exists. The strategic priority doesn’t.
References
Google AirDrop Compatibility:
AWDL Research:
Stute, M., Kreitschmann, D., & Hollick, M. (2018). “One Billion Apples’ Secret Sauce: Recipe for the Apple Wireless Direct Link Ad hoc Protocol.” *Proceedings of the 24th Annual International Conference on Mobile Computing and Networking (MobiCom ‘18)*, 529-543. DOI: 10.1145/3241539.3241566
Stute, M., Kreitschmann, D., & Hollick, M. (2019). “A Billion Open Interfaces for Eve and Mallory: MitM, DoS, and Tracking Attacks on iOS and macOS Through Apple Wireless Direct Link.” 28th USENIX Security Symposium.
Open Source AWDL Implementation:
EU Digital Markets Act:
Apple PhotoKit: