Multi device

Multi-device

• 🖧 Devices — scan localhost (or add host:port, single ports 9500, lists 9500,9600 or ranges 9400-9420) to find other instances of the same app, then every property edit, structural action and mock-rule change is mirrored to the checked targets.
• Device picker — the header dropdown re-points the whole panel (tree, properties, mirror, resources) at another running app, so the phone layout can be inspected from the tablet's portal without a second tab.
• Targets are addressed by XAML source identity, not by element ids — one edit reaches every device rendering that line, including every instance of a DataTemplate.
• When a device renders a different template or a different page variant (an AdaptiveTemplateView-style control, OnIdiom layouts, or whole pages picked per form factor such as Main_iPhone_Page / Main_iPad_Page), that source line does not exist there, so the edit falls back to an identifier of the same type: AutomationId first (it exists to identify one element), then StyleId — which is also what MAUI fills from x:Name. The fallback is confined to the counterpart page: page type names are normalised by stripping form-factor tokens, so Main_iPad_Page, Main_Android_Tablet_Page and MainPage all count as Main and a same-named element on an unrelated screen is never touched.
• StyleId is a weak key — it doubles as the MAUI CSS #id selector and nothing keeps it unique, so two unrelated controls can share one. Several matches are therefore accepted only when they all come from the same XAML line (the rows of one DataTemplate, which is exactly what fan-out should hit); matches from different lines are a name collision and are refused rather than guessed. No match, or an ambiguous one, is reported as —.
• ⧉ all instances of this template (next to the source path) re-applies the edit locally through the same matcher, so all rows of a DataTemplate update at once, not just the selected one.