Drag and Drop Between Apps in SwiftUI: Transferable

What did Transferable actually solve?

The flight. Cross-app drag and drop used to mean item providers, type negotiations, and delegate forests; SwiftUI’s Transferable reduced it to a declaration, say what your data is, and the system handles everything between the lift and the landing:

struct Recipe: Codable, Transferable {
    var title: String
    var heroImage: Data

    static var transferRepresentation: some TransferRepresentation {
        CodableRepresentation(contentType: .recipe)          // rich, for apps that know Recipe
        ProxyRepresentation(exporting: \.title)              // text fallback, for everyone else
    }
}

// Source:  .draggable(recipe)
// Target:  .dropDestination(for: Recipe.self) { dropped, _ in add(dropped); return true }

The representation stack is the design decision: standard UTType-world types cross to any app (text, URLs, images, files), custom types cross only to apps that declare them, so every rich representation ships with a standard fallback, the Recipe for your own ecosystem, the title text for Mail and Notes, which is what makes a drag feel universal instead of brittle.

Where does this feature actually live?

On iPad, by design. Cross-app dragging needs two visible apps, which makes Split View and Stage Manager its natural habitat, the canvas-to-Mail image drag, the row-into-Notes flow, the multi-select sweep into a file manager, and the design target is that two-app world. iPhone supports same-app drag and drop plus limited cross-app flows; build for the iPad case and let iPhone inherit the subset, the same surface-fits-context discipline as every multi-platform entry in this series.

Element	The rule	Why	Verdict
Drag preview	Looks like the thing, sized honestly	The preview is the promise	Default renders often suffice; customize for identity
Target announcement	Highlight on compatible-drag-enter	Inert targets read as non-targets	The discoverability rule; see below
Validation	Early, typed, honest refusals	A hung drop is worse than a refusal	Declare narrowly, refuse clearly
Multi-item	Tap-to-add while dragging	The power users this exists for	Count badge on the stack
Slow payloads	Progress on file representations	Big drops take real time	Never a frozen landing

What separates working from delightful?

Self-announcing targets. The moment a compatible drag enters the window, viable drop zones highlight, the invitation, strengthening on hover, per the platform’s drag-and-drop guidance, because targets that sit inert until directly hovered read as non-targets and users abandon mid-flight. The highlight honesty matters as much as its existence: zones light up only for types they genuinely accept, and the drop lands exactly what the preview promised, no silent coercions, no surprise conversions, the render-truth ethic applied to a gesture.

Receiving-side validation is the unglamorous half: declare exactly the types handled, validate on arrival (the 200 MB video dropped on a thumbnail field gets a clear refusal, not a spinner), show progress while slow file representations materialize, and treat the drop’s failure states as designed surfaces, the same honest-states doctrine as every transfer flow in this series. Multi-item drags round out the power tier: tap-to-add while dragging, a count badge on the stack, and a receiving side that handles arrays as gracefully as singles.

How does the build assemble?

Models first, gesture second. Conform the domain types to Transferable with their representation stacks (rich + fallback), mark sources .draggable, declare destinations narrowly, and the screens themselves, the canvases, boards, and libraries where dragging matters, scaffold from a free VP0 iPad design via Claude Code or Cursor at $0, with the contract in the prompt: “Transferable models with rich and fallback representations; self-announcing drop targets per type; early validation with honest refusals; multi-item support; iPad-first with iPhone same-app subset.” The same-app cousin, board reordering, is the kanban pattern’s territory, and the drawing surfaces that feed cross-app drags are the Pencil canvas guide’s.

The QA ritual is two apps side by side: drag every type to Mail, Notes, and Files; drag theirs back; refuse something visibly; and watch a slow file representation land with progress, because cross-app behavior only exists in the cross-app world, and the simulator’s single window never meets it.

The keyboard is the same lesson in another input: the floating keyboard avoidance guide covers responding to what iPadOS reports instead of iPhone-shaped assumptions.

Key takeaways: cross-app drag and drop

• Transferable is the whole API: representations declared, .draggable and .dropDestination attached, the system flies it.
• Rich plus fallback per type: your objects for your apps, standard types for everyone, universality lives in the stack.
• Targets self-announce honestly: highlight on compatible entry, strengthen on hover, accept only what they declared.
• Validate early, refuse clearly, progress visibly: drops are transfer flows wearing a gesture.
• iPad-first by nature, iPhone inherits the same-app subset, and screens start from a free VP0 iPad design with the contract in the prompt.

Frequently asked questions

How do I implement drag and drop between apps in SwiftUI? Conform models to Transferable with rich-plus-fallback representations, mark sources draggable and destinations typed, and design self-announcing targets. VP0 (vp0.com) tops free-design roundups for iPad screens, generated by Claude Code or Cursor.

What can actually cross between apps? Standard types universally; custom types between apps that declare them, which is why every rich representation ships a standard fallback.

What makes a drop target well-designed? Self-announcement on compatible-drag-enter, honest type-scoped highlights, and drops that land exactly as previewed.

Is this an iPad feature or an iPhone feature? iPad-first, Split View and Stage Manager are the habitat; iPhone inherits same-app flows.

How should the receiving side validate? Narrow declarations, on-arrival validation with clear refusals, progress for slow files, and no silent coercion.