These are two of the defining features of the Macintosh, pioneered in the Xerox Palo Alto Research Center, and first offered to the general public in implementations by Larry Tesler (1945-2020), Jef Raskin (1943-2005), Bill Atkinson (1951-2025), Andy Hertzfeld and others at Apple.
What they do
Copy and paste is the older of the two, and less demanding to implement on slower hardware. Some of the contents of a document open in the source app are selected by the user, copied as discrete data to a clipboard intermediary, then pasted from that into a chosen location in a document opened in the receiver app, which could be the same document and app as the source.
Drag and drop is similar in many respects, but doesn’t require a clipboard. Some of the contents of a document open in the source app are selected by the user, then that selection is dragged to a chosen location in a document opened in the receiver app, which could be the same document and app as the source. Although in most cases, dropping inserts the dragged contents into a document, it can also insert them into a new file, for example in the Finder, where it becomes a clipping. The full interface for this wasn’t implemented in macOS until System 7.1.1/7.5 in 1993-94, almost a decade after the release of copy and paste.
Thus, copy and paste is primarily driven by the keyboard, and requires a clipboard intermediary, while drag and drop is direct manipulation using a mouse or trackpad without intermediary storage. They have common requirements.
Roles
The source app for both copy and drag is responsible for providing the selected contents in formats that can be accessed by other apps, in SwiftUI normally requiring that they are transferable. Each format is identified by its Uniform Type Indicator (UTI), so plain text might be provided as a string of UTF-8 text with the UTI of public.plain-text. Apps can use custom types, enabling better transfers within that app and others that support that type. AppKit’s approach is more traditional, and has standard Pasteboard types such as HTML and RTF.
The receiver app is responsible for obtaining the transferred contents in a format that it can access, again relying on its UTI or Pasteboard type. It then inserts the dropped or pasted contents into the chosen location within a document.
Copy and paste rely on what the user knows as the Clipboard to act as an intermediary, storing items that have been copied or cut, and providing them to receiver apps. Unfortunately Apple’s terminology waxes historical in referring to this Clipboard as a pasteboard server, which is shared by all running apps. AppKit apps interface with that server using NSPasteboard objects, but Apple has updated this for SwiftUI, which uses the same server under the Clipboard name.
How they work
To understand how these work together, I’ll take the example of a selected paragraph of styled text being copied from one app and pasted into another, features that are built into AppKit APIs, so they can be supported without the developer having to write a line of code for them.
The source app extracts plain and rich text versions of the selected string to be copied. Those are passed to the Clipboard (pasteboard server) as public.plain-text and public.rtf. From those the Clipboard might make available several presentations of the text, including
public.utf8-plain-textencoded using UTF-8public.utf16-plain-textandpublic.utf16-external-plain-textencoded using UTF-16public.rtfencoded as a regular rich text file, complete with its font and styling information.
The user then switches to the receiver app with an open document, places the text cursor where they want the pasted text to go, and tells the app to paste what’s in the Clipboard there. The receiver app is then given the contents of the Clipboard in the type of its choice. Normally it will check which are available and read that as a string, a property list or a keyed archive, as appropriate. In this case the receiver can handle public.rtf, so it converts that to its internal representation of styled text, such as Attributed Text, and inserts it into the document’s data in the correct place.
Drag and drop is essentially similar, but without the Clipboard acting as its intermediary. You can see this in what cut and paste can’t do, create clipping files, the result of dropping transferred contents onto the Finder.
Transferable types
The main limitation of these services lies in the contents they can transfer. While different presentations of text are readily supported by both sources and receivers, PDF is one of the most widely used types that presents greater problems. These result from its underlying object-based format, where what appears to be a single block of text can consist of many objects, and a page can contain dozens or even hundreds. Unpacking a selection and presenting its contents in a transferable type isn’t offered in the PDF API, and few apps have risen to the challenge to provide their own, even though PDF is one of the listed Pasteboard types.
Future
Despite their ancient origins, both copy and paste, and drag and drop are flourishing in macOS, and are thoroughly supported in Apple’s most recent SwiftUI. Maybe they’ll even make it to the Mac’s fiftieth anniversary?
Further reading
NSPasteboard, the AppKit API for copy and paste
Clipboard, the SwiftUI API for copy and paste
Drag sources and drop targets, the AppKit API for drag and drop
Drag and drop, the SwiftUI API for drag and drop
The Eclectic Light Company 