Reuse real text, URL, and file inputs through the share sheet

Direct answer

How does TestDock test share-sheet flows?

TestDock Pro stores reusable text, URL, and local-file fixtures in the target app profile, then opens the operating system's share sheet with that input. The receiving app is reached through the same share entry point a user would use.

The usual way

Share extensions have to be tested from another app.

An iOS share extension or an Android share target only runs when another app hands it content. To test one, you open Photos, Files, Safari, or Notes, find the right item, tap Share, and scroll to your app. On the next build you do it again, and the test file may have been moved or deleted in the meantime.

On Android, adb shell am start -a android.intent.action.SEND -t text/plain --es android.intent.extra.TEXT "…" can send a share intent from a computer, but it covers simple text and needs a connected device. On iPhone, testers usually do it by hand.

Share fixtures

Keep the exact inputs your app has to handle.

With TestDock Pro, each app profile has a Share tab for share fixtures. A fixture is a named input of one of three types: Text, URL, or File.

When you pick a file, TestDock copies it into its own storage, so the same PDF, image, or document is available on every test run even if the original is later moved.

• Text: any text, including long or multi-line content
• URL: a complete http or https link
• File: a file chosen once, with a Presented file name and a MIME type
• Uniform Type Identifier (optional, iOS only): a type such as com.adobe.pdf that describes the file

Running a share

Open the real system share sheet.

Tap Open share sheet on a fixture and TestDock opens the iOS or Android share sheet with that input. You pick your app in the sheet as a user would, and your extension or share target receives the content through the normal system path.

The MIME type is used to find compatible receiving apps, and on iOS the optional Uniform Type Identifier describes the file type. That lets you check whether your app is offered for the file types it supports and hidden for the ones it does not.

Limits

What TestDock can report after the sheet closes.

When the sheet closes, TestDock notes that it closed. It cannot tell which app was chosen or whether your app processed the input, because that happens outside TestDock. Check the result in your app, or record it as a scenario step.

Profile exports include text and URL fixtures in full. File fixtures keep their settings, but the file itself is not exported and has to be selected again on the other device. Until the file is chosen again, Open share sheet asks you to select it first.

Best for

Where this workflow fits.

• Testing iOS share extensions and Android share targets
• Repeating the same imported URL, text, or file across builds
• Checking whether an app appears in the share sheet for a given file type

Profiles and logs stay on the device, provider credentials use platform secure storage, and exports omit secrets.

Relevant capabilities

What TestDock brings to the job.

Practical workflow

From setup to a reviewed result.

1. Create a fixture

   Choose Text, URL, or File and give the input a name that says what it tests.

2. Set the file details

   For files, set the presented file name and MIME type, and on iOS optionally a Uniform Type Identifier.

3. Open the share sheet

   Tap Open share sheet and choose your app from the system sheet.

4. Check the receiving app

   Confirm your extension or share target handled the input correctly; TestDock only reports that the sheet closed.

Useful in practice

Direct answers

Questions about share-sheet tester.

Go deeper

Configure provider-specific push targets, reuse payload templates, and combine delivery checks with observable manual scenarios.