MemoKit, the API we desperately need.

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.

Fake MemoKit API documentation built with Claude Chat. Used for educational illustration under fair use.
Fake MemoKit API documentation built with Claude Chat. Used for educational illustration under fair use.

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:

Image Source: PhotoKit API. © Apple Inc. Used for educational illustration under fair use.
Image Source: PhotoKit API. © Apple Inc. Used for educational illustration under fair use.
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,
            mediaType: asset.mediaType
        )
        photos.append(photo)
    }

    return photos
}

The code structures are nearly identical. The permission model, fetch pattern, metadata access—Apple has already solved this design problem. They just chose not to apply it to Voice Memos.

What We Built Instead

Without API access, we implemented workarounds:

Files App Integration: Users can share audio files through the Files app to Sound Library. It works, but requires manual steps that PhotoKit-style automatic sync wouldn’t need.

Share Sheet Import: Our Share Extension appears in any app that can share audio. Select recordings in Voice Memos, tap Share, choose Sound Library. Functional, but not automatic.

Manual Batch Import: Select multiple files, import them in one action. Better than one-at-a-time, but still requires user initiation.

These workarounds function. They don’t match user expectations shaped by PhotoKit’s automatic library sync. The most requested feature we cannot deliver: “Just sync my Voice Memos automatically.”

Why Some APIs Exist and Others Don’t

Apple’s API decisions follow strategic logic:

PhotoKit exists because photos are socially important. Users share them across platforms, edit them in third-party apps, back them up to competing cloud services. Not providing access would push users to Android.

HealthKit exists because health data interoperability has regulatory implications and partnership value. Hospitals, insurance companies, and fitness brands all need access.

EventKit exists because calendar interoperability is a basic productivity expectation. No one would accept a phone that can’t sync with Google Calendar.

Voice Memos has none of these pressures. Users don’t switch platforms over memo access. No regulatory body mandates voice recording interoperability. No major industry partner demands it.

The Missing Pressures

Three forces typically drive API development:

Regulatory pressure: The EU DMA targets high-impact interoperability—messaging, app stores, payment systems. Voice Memos isn’t on any regulatory agenda.

Competitive pressure: No one chooses iPhone vs. Android based on voice memo portability. The recordings are a feature, not a platform decision.

Market pressure: Most users don’t know such APIs could exist. They accept the limitation as normal rather than recognizing it as a choice Apple made.

The Realistic Assessment

Will Apple build MemosKit? Probably not soon. The strategic incentives aren’t there. But the technical capability clearly exists—PhotoKit proves it.

What could change this:

  • EU expansion of DMA to cover more data portability categories
  • A competitor (Samsung, Google) making voice memo portability a selling point
  • User demand reaching critical mass through App Store reviews and Feedback Assistant

Until then, we build workarounds. We make manual import as smooth as possible. We focus on what we can control—the organization, search, and discovery features that make the import worth doing.

The technical capability exists. The strategic priority doesn’t. And that’s the most honest thing we can say about building on someone else’s platform.