Does Sleeve Copy or Import Your Music? No — It Reads In Place

The short answer

No. Sleeve has no import action at all — there is no button that copies your music into the app, because there is no copy of your music inside the app. You connect a source, and Sleeve reads the files where they sit.

Nothing is moved, nothing is copied, and no second copy is stored. Connecting a source costs you no extra storage, and because only one copy of your music ever exists, the library cannot drift from the originals. Rename an album at the source and the rename follows it. The single write the app performs is a tag you edited yourself.

Why you are asking

Two quite different people ask "does it copy my music", and both are right to.

The first has been caught by a library manager. They added a folder, a progress bar copied a couple of hundred gigabytes into a managed library, filled the phone, and then sat there drifting out of sync — so every album reorganisation had to be done twice, once in the manager and once in the real folder. If that is you, the answer you want is not reassurance that the copy is fast. It is that the copy should not exist.

The second is deciding whether a no-copy player can be trusted with something that matters — a NAS holding the only recording of a show, say. The question is different: does the app ever write to files it did not create, and what happens when the app and the source disagree?

What read-in-place actually means

"No import" is a claim every competitor makes, and only some of them mean it. The mechanism is worth stating plainly: a source is a connection, not a payload. Connecting a folder in Files, a cloud drive or a WebDAV share produces no local copy and no private index. The library you browse is a view onto those files — playback opens the file where it lives, reads the tags already inside it, and sends it to the output. Nothing is re-encoded on the way and nothing is written back.

Four kinds of source, none of which involves an import step:

• A folder on this device — anything in Files, including a USB stick or SD card
• A cloud drive — iCloud Drive, Dropbox, Google Drive, OneDrive, all reached through Files
• A network share at home over WebDAV — Nextcloud, Synology, QNAP and most NAS boxes speak it
• Music sent from a computer over the same Wi-Fi, with a browser and no cable, or dropped in from Files

SMB is not supported in this version, so a NAS that only speaks SMB is out; if the box also runs a WebDAV service, that is the route in.

Two consequences follow, and they are the reason the design exists. Connecting a source costs no storage — a library of any size costs nothing in duplicated bytes. And because there is only one copy, there is nothing that can fall out of sync. Drift is not mitigated here; it is structurally impossible.

Which way the changes travel

Renames propagate in one direction: source to library. Rename an album at the source and the rename appears in the app, because it is reading the folder rather than a snapshot taken when you connected it.

The other direction is closed. It never renames or reorganises anything itself, so no tidy-up routine can rewrite a naming scheme your other software depends on. But the honest reading of that is symmetric: you cannot reorganise your music from inside the app. If the collection is a mess, you fix it with whatever you already organise files with, and the result shows through. That is the trade, and it is the right one when your files are also the NAS's files.

There is one write, and it is one you asked for: editing tags in place when a file arrived badly labelled — a 2024 date inside a 1998 album, a missing album artist. The edit lands where the file is rather than in a corrected index of its own, which is the same reason there is nothing to resynchronise afterwards. Worth knowing that this is the only direction the app writes in before you apply it to a file on a share you think of as read-only.

Your folders are the taxonomy

The other half of not copying is not imposing a shape. Because the app is not rearranging your files, it does not insist on rearranging how you see them: albums, artists, songs and playlists, or the real folder tree, as deep as it goes — because some libraries are organised by year, or by a live set, or by who recorded it, and none of that is an album.

On top of that:

• Smart playlists with rules you can edit — the free version allows two, Pro removes the limit
• Search across titles, artists and albums, with your recent searches kept
• Tags edited in place, as above
• Lyrics from LRCLIB, matched by title, artist, album and track length
• Cover art looked up from MusicBrainz and Apple's iTunes catalogue, then fetched from the Cover Art Archive or Apple

Lyrics and artwork are both optional network lookups with a switch each in the Me tab — turn them off and only the tags and artwork already embedded in your files are read. Either way, nothing about your library is uploaded.

Against the obvious alternative

The alternative is the one most people already own: a library manager that imports into a managed collection. The differences are not cosmetic.

Two things the import model genuinely does better, so this is not one-sided. It can tag a collection from scratch, and it can tidy a pile of untitled downloads without a second tool. If your library needs a machine to sort it once before it is usable, that machine is the argument for the other approach — and the price is the copy you are trying to avoid.

What read-in-place does not solve

• A source that is unreachable says so, on the Sources tab, rather than quietly returning an empty library. The source's detail page shows its last error and its last successful sync, which is usually the fastest way to see what changed.
• The one place the app spends your storage is the offline cache, which fills from what you actually play. You choose its ceiling in Me → Cache, you can see what it is using, and you can clear it. A cache that grew invisibly would quietly undo the zero-storage property — and it is the one honest exception to "connecting costs no storage".
• The free version connects one source. Pro removes that limit and is a one-time Universal Purchase across iPhone and iPad rather than a subscription, so the free tier is not a trial you lose the ability to play lossless audio in.
• No account means no sync between your devices. There is no sign-up and no user table, because there is nowhere to put one. That is the price of the privacy claim, and it is a real one.

What Sleeve does differently

Sleeve is a music player for music you already own. The part worth knowing is not the format list — FLAC, ALAC, AAC, MP3, WAV and AIFF played as they are, gapless across an album, ReplayGain, a ten-band equaliser, and the format, bit depth and sample rate kept on screen rather than hidden two levels down — it is that the library is a view, not a copy.

Most players in this category either copy your files in or stream from a provider who owns the library. A view is neither: it costs no storage, it cannot drift, and it removes the "which one is the master copy" question entirely. The limit is that all organisation happens at the source, and the app reaches your files the way Files does — which is exactly what makes a large collection a library on a small phone.

Is it worth it

If your music already lives in folders, on a NAS or in a cloud drive you chose, this is the only shape that scales without asking you for the disk space twice. If it is scattered untitled downloads, you want a library manager first — sort it there, then connect it here.

Sleeve has the current build. If a source starts misbehaving, Me → Feedback sends your device model and app version with the report, and nothing from your library.