System services let other apps invoke a function without switching

What it is

Select some words in any app, open Services, and choose “New Email with Selection” or “Look Up in Dictionary.” The current window need not yield the foreground; the other app’s capability has already acted on that selection. A system services menu registers one app’s capability as an item other apps can invoke in place, so people need not copy, switch, paste, and switch back. It is not a share sheet that “sends content away,” and not an implicit clipboard buffer. It is an explicit call table hung on a system menu. Windows cousins include Send To, some Open With targets, and later share targets. The mechanism is the same family: capability follows the selection, rather than the person following the app.

Why it happens

The desktop treats the current selection as a parameter that can be handed to someone else. A provider declares what types it eats and what it produces (rewrite the selection, open a result window, write a file). The call happens in the source app’s menu; the source need not implement the feature or know how the provider works. What is saved is one app switch and one round trip through a channel: data does not have to be put somewhere and fetched somewhere else. Failure modes come from the table going invisible—too many items, names that sound like modules, or the whole item vanishing when the selection’s type does not match, so people conclude the system has no dictionary and no “make a new mail.” If a service processes the selection in the background and does not change the current window, people think nothing happened. If it steals the foreground, it destroys the “without switching” half of the claim.

Where it stops holding

Commands with no selection (“back up the whole disk now”) do not belong on a services menu; that is the app’s own entrance. If touch and keyboard-only users cannot open that system layer, the service does not exist for them and the source app needs another door. A sandbox will limit what selection a provider can read; an over-broad service is simply omitted by the system. Remote desktops and web-wrapped desktops often have no such table; cross-app invocation falls back to the clipboard or share. When a service hands data to a third-party app, the leak radius is not the same problem as clipboard history—this is an intentional click on a menu.

Applying it

• Register “do one complete thing to the current selection” as a service, and declare whether it eats text, rich text, or files. Do not use internal module names as menu titles.
• When the selection’s type does not match, disable the item and leave it, or say what must be selected first; do not let the whole services list appear and vanish with the selection.
• After a call, write the result back into the selection by default, or show a result without stealing the foreground; bring a window forward only if the person must keep editing there.
• Verify: in an app that does not contain the feature, select text and complete “look up / new mail / send to a given tool” only through system services. The path must not require copy then switch. Change the selection (plain image, empty) and check that the menu can still explain why an item is unavailable.

Related

• Within the group: K2.10.1 The clipboard is an implicit inter-app channel whose behavior must be predictable · K2.10.2 Copied formats determine what the paste target can accept · K2.10.4 Clipboard history and cloud sync widen the leak radius of secrets
• Adjacent: K2.03 Menu Bar · K1.07 System Share Sheet
• Search terms: Services menu · in-place invocation · selected-content services