Test iOS drag-and-drop data exchange on a cloud Mac

Before a release, the team dragged a task ID from a list into an editor. The drag preview looked right, and dropping it produced no error, but an empty string was saved. The problem was not in the animation: if the data type declared by the drag source, the type accepted by the drop target, or the timing of the asynchronous read does not line up, the interface can give a misleading impression of success. When working remotely on a cloud Mac, use XCTest to check the data contract first, then open Simulator to verify the actual gesture. Neither check replaces the other.

Define a testable drag-and-drop contract

For each kind of draggable content, document three things: the UTType declared by the provider, the types the receiver accepts, and the content expected after a successful read. For example, if a task ID only needs to be pasted into a text field as a string, both sides can agree on UTType.utf8PlainText. Do not register plain text at the source while querying only for image types at the receiver, then treat “the drop action fired” as proof of success.

Define the failure paths too: an unsupported type should not highlight a target as available; a failed read should not insert an empty task; and cancelling a drag should not change the original data. If the application needs to preserve fields beyond the task ID, define a custom data format that both sides can parse rather than hiding structured content in display text.

Completing a drop is a UI event, not a data commit. Update application state only after the types match, the asynchronous read succeeds, and the content passes validation.

Use XCTest to verify the type and payload

Add a test file to the app’s test target. The provider below registers UTF-8 text. The test checks the type, waits for the read callback, and verifies the bytes it receives. It needs neither a mouse nor a graphical desktop, making it a useful fast check in the build pipeline.

import XCTest
import UniformTypeIdentifiers

final class DragPayloadTests: XCTestCase {
    func testPlainTextPayload() {
        let provider = NSItemProvider()
        provider.registerDataRepresentation(
            forTypeIdentifier: UTType.utf8PlainText.identifier,
            visibility: .all
        ) { completion in
            completion(Data("ticket-42".utf8), nil)
            return nil
        }

        XCTAssertTrue(provider.hasItemConformingToTypeIdentifier(
            UTType.plainText.identifier
        ))
        XCTAssertFalse(provider.hasItemConformingToTypeIdentifier(
            UTType.image.identifier
        ))

        let loaded = expectation(description: "Load drag payload")
        provider.loadDataRepresentation(
            forTypeIdentifier: UTType.utf8PlainText.identifier
        ) { data, error in
            XCTAssertNil(error)
            XCTAssertEqual(data.flatMap { String(data: $0, encoding: .utf8) },
                           "ticket-42")
            loaded.fulfill()
        }
        wait(for: [loaded], timeout: 5)
    }
}

Here, plainText checks for a compatible type, while utf8PlainText reads the specific representation that was registered. Once the test passes, use the same type checks and decoding logic in the application code. Otherwise, the test could accept one type while the interface uses a different allowlist. Production code must also handle error, empty data, and UTF-8 decoding failures in the callback. Do not change the UI based on hasItemConformingToTypeIdentifier alone.

Choose a Simulator destination before running the test

First, check the available configurations in the VMCommit console. After the Mac is provisioned, connect over SSH and list its installed simulators. Replace the project, Scheme, and device ID below with your own values. Get the device ID from the first command; the example string is not a real device.

xcrun simctl list devices available
xcodebuild -list -project App.xcodeproj
xcodebuild test \
  -project App.xcodeproj \
  -scheme App \
  -destination 'platform=iOS Simulator,id=YOUR_DEVICE_ID' \
  -only-testing:AppTests/DragPayloadTests

The -only-testing path must match the test target and class name in your project. If the command says the Scheme does not exist, check whether it is shared. If the destination device is unavailable, list the devices on this Mac again rather than reusing an ID from another machine. If the test fails, keep the original output so you can distinguish “Simulator did not start” from “the payload assertion failed.”

Verify the real drop in a graphical session

The contract test bypasses gesture handling, so it cannot prove that UIDragInteraction or UIDropInteraction is wired up correctly. Open Simulator on the graphical desktop, install the test app, and complete the following sequence:

1. Long-press a valid source item and start dragging. Confirm that the preview matches the selected item.
2. Move over an allowed target and check for drop feedback. Move over an area that does not accept the type and confirm that the feedback disappears.
3. Drop the item, wait for the read to finish, then check that the correct task ID appears in the editor exactly once.
4. Start another drag and cancel it before dropping. Confirm that neither the list nor the editor changes.

For larger payloads, treat “loading” as a separate state: prevent duplicate submissions and update the content only when loading finishes. On failure, restore the usable state and show a clear message. Do not display “Imported” before the asynchronous callback returns just to make the animation feel smoother. The graphical check covers the state changes users see; XCTest covers the underlying data. Record the two results separately.

Follow the data flow when debugging failures

If the target does not highlight, check types first. In the development environment, print the identifiers registered by the source and allowed by the receiver. Confirm that the code checks type compatibility rather than comparing display names alone. If the target highlights but no content appears, check whether the load callback runs, then inspect the error, data length, and decoding result. Do not write the entire payload to shared logs. Task content may contain business data, and the type and length are usually enough to locate the failure boundary.

If content is occasionally inserted twice, check whether both the drop callback and the load-completion callback update the model, or whether the same provider is read more than once. Assign an operation ID to each drop and commit only once, after validation succeeds. Discard pending results on cancellation or failure. When adding other payloads, such as images, write separate tests for every accepted type. A passing plain-text test does not establish that every drag-and-drop path works.

Check both sets of results before release

The automated results should cover type matching, rejection of unsupported types, byte-for-byte content, handling of empty values and read errors, and a test failure on timeout. The graphical results should cover an accurate source preview, correct target feedback, a single update after success, no content changes after cancellation, and a failure message that does not falsely report success. Run the former on every commit; revisit the latter especially after changes to the interaction or system version.

Finally, repeat the operation in a clean simulator to confirm that the result does not depend on content left in the editor by a previous run. Keep a record of the types the project actually accepts alongside both checklists. The next time the drag-and-drop format changes, they will help pinpoint whether the problem lies in the data contract, the asynchronous read, or the gesture feedback.

Frequently asked questions