The portable-library work has now turned into something much more practical: plug a USB drive into an iPad or iPhone, pick the folder that contains a .kanora library, and browse that library without copying the music onto the device. On the current branch, the drive can also be treated as a first-class library in the normal Kanora browser, and playback resolves back to the files on the drive.
That is the product version of the architecture I wanted. The .kanora/ catalog carries the library's identity and metadata, the device builds a temporary local index, and the media files stay on the drive. The iPad gets enough structure to browse artists, albums, tracks, and playlists, but it does not have to become the permanent home for the music.
For me, this is not an abstract portability story. I live in Cornwall, where mobile signal can be theoretical once you leave the easy places, and we spend a lot of time in our VW T4 camper in the middle of nowhere. That is exactly the situation where a streaming-first music setup becomes irritating. The albums are yours, the files are sitting on a drive, and the device in your hand has a perfectly good screen and audio output, but the software often assumes the network is part of the room.
Kanora should not assume that. If the music is on a drive and the device can read the drive, that should be enough.
What the branch does
The first slice was the mount and resolve engine. Given a folder with .kanora/, Kanora reads the portable catalog, builds an isolated in-memory index, and checks which primary track files can be resolved on the mounted drive. It holds security-scoped access for the lifetime of the mount and releases it when the drive library is dismissed or switched away from. The device's own library is not modified.
The next slice made that visible. With the portable-drive feature flag enabled, iOS and iPadOS expose a portable drive entry from library management. The user picks a folder through the Files picker, including an attached USB-C volume on iPad, and Kanora mounts the catalog.
The current branch goes further. A mounted drive can appear in the same library switcher as the local iPad library and connected hosts. Switching to it points the existing Artists, Albums, Tracks, and Playlists surfaces at the drive's temporary index. That mattered more than adding another special screen. The normal browser already knows how Kanora libraries should feel, and the drive library should not be second-class just because it came from a sidecar folder five seconds ago.
The latest playback work then closes the obvious gap. When the active context is an external drive library, playback resolution rewrites the track's file location to the on-drive URL using the mounted root and the portable path hints. In plain English: press play on a track from the drive library, and Kanora plays the file from the drive.
What does not happen
Kanora does not import the drive library into the device library. It does not copy the albums onto the iPhone or iPad just because you wanted to listen for a weekend. It does not write play stats or edits back to the drive in this branch. It does not try to reopen the drive automatically after a relaunch, and it does not yet handle every physical-world case like pulling the cable halfway through playback.
Those boundaries are intentional. External-drive support has a lot of sharp edges on Apple platforms, especially once security-scoped access, Files picker grants, removable media, and playback lifetime all meet in the same feature. The current work keeps the drive read-only and treats the mounted library as a temporary session. Switch away, and the mount is torn down. The device store is left alone.
That is the right first contract: browse and play the music on the drive without pretending that a removable volume is the same as permanent local storage.
Why this changes the shape of Kanora
Before .kanora, an external drive was mostly a pile of files. Kanora could scan it, but scanning alone cannot recreate playlists, ratings, play history, root identity, artwork choices, or which track file is the lossless original versus a companion file. With .kanora, the drive carries the library's memory and the iPad only needs to build a local working view of it.
The off-grid use case is the easy one to picture. A camper, a USB-C drive, an iPad, headphones or a speaker, and no useful signal. The less romantic version is just as important: a phone with limited free space, an iPad used around the house, a library too large to duplicate everywhere, or a user who does not want their music app to require a network, account, or subscription before it becomes useful.
This is the part of Kanora that I am particularly pleased with, because it makes the ownership idea more concrete. "Own your music" is not just a slogan if the files still have to sit inside one device or one app database to be usable. The files should be able to travel, the metadata should travel with them, and the app should read the library where it is.
There is still work to do. Drive auto-detection, mid-playback eject recovery, persisted reopen, CarPlay and Watch surfacing, and write-back decisions all need separate care. But the central path is now there on the branch: a .kanora library on an external drive can become a browsable Kanora library on iOS, and the music can play from the drive.