Platform compatibility and capture limits
Availability reviewed 2026-10-22. This page separates released integrations, host-app SDK source and planned native apps. Source and synthetic tests do not certify every OS, browser or physical device. See verification for the evidence required before claiming support, and Upcoming for Coming soon work.
Available integrations
The web workspace includes the Kanban board, project analytics, subscribed email and ten task-provider adapters. The app screenshot pilot adds signed-in image import and browser window/display capture without the extension. Native system-picker acceptance remains unverified on the named operating systems.
| Target | Current Feedbacks integration | Boundary and evidence |
|---|---|---|
| Websites in desktop Chrome | Chrome extension: screenshot points, tab video, session replay and debugging evidence | Capture is scoped to the selected website/tab and project. Packaged browser tests and installed-client verification are separate gates. |
| Codex, Claude Code and other MCP clients | MCP and direct plugins | Available agent connections use current server/project grants. Official directory publication and installation in a particular client are separate checks. |
| Your own iOS app | Swift integration kit for paired team reviewers | Captures the host app's supplied view and submits a screenshot/comment. Real-device pairing, capture and upload remain unverified. |
| Your own Android app | Kotlin integration kit, API 26 or newer | Captures the host app's window with PixelCopy. A compile-only host and HTTP contract tests exist; real-device operation remains unverified. |
| Other Windows, Ubuntu or macOS applications | Web app capture/import pilot | The web app offers a browser capture/import pilot; no standalone Feedbacks desktop companion is provided. Running Chrome on an OS does not establish native-app capture support. |
| Other Android or iOS applications | Image import pilot; native apps Coming soon / planned | No standalone Feedbacks mobile companion, share extension or broadcast extension is provided. The existing SDKs capture only their host app. The web app can accept an imported screenshot. |
The extension's session recordings can include DOM replay, activity, console, network, performance and environment evidence. Detailed capture uses Chrome debugger attachment during an explicitly started recording; bounded network bodies are a separate option. Channel coverage, protected pages and browser limits still apply. The legacy opt-in screenshot diagnostic packet has a narrower format. Neither path collects another native application's internal state.
Feasibility of future clients
The following matrix describes what could be built without changing the target app. It is not current Feedbacks availability. Assume a normal production device, explicit user action and OS-approved access, without root, jailbreak or developer-tool privileges.
Capture means a supported OS capture path; Limited means permission, toolkit, file access or additional setup is required; Import means a user supplies an exported file; Integration means cooperation from the target app or backend is needed.
| Evidence | Windows | Ubuntu/Linux | macOS | Android | iOS |
|---|---|---|---|---|---|
| Screenshot | Capture | Capture | Capture | Capture, except protected surfaces | System screenshot shared/imported |
| Screen/window video | Capture | Capture; desktop/backend dependent | Capture | User-approved projection | User-started broadcast or imported recording |
| Pins, arrows and comments on a captured image | Feasible | Feasible | Feasible | Feasible | Feasible |
| Basic OS/device/display context | Feasible | Feasible | Feasible | Feasible | Feasible within public APIs |
| Target app identity/version | Limited | Limited | Limited | Limited by package visibility | Usually supplied by the user/app |
| Structured buttons, text and UI tree | Limited: UI Automation | Limited: AT-SPI/toolkit support | Limited: Accessibility APIs | Limited: enabled Accessibility service and policy requirements | No general cross-app inspection API for an ordinary companion |
| Target app logs | Limited to accessible files/exports | Limited to accessible files/journal/exports | Limited to accessible logs/exports | Import or app integration | Import or app integration |
| Crash report/stack | Limited: configured collection/import | Limited: available reports/import | Limited: available reports/import | Import or developer/app integration | Import or developer/app integration |
| Target process CPU/memory | Limited by process access | Limited by process access | Limited by process access | No general reliable companion access | No general companion access |
| Full HTTPS request/response bodies | Integration or compatible debug proxy setup | Integration or compatible debug proxy setup | Integration or compatible debug proxy setup | Integration or compatible debug proxy setup | Integration or compatible debug proxy setup |
| Backend logs/database context | Backend integration | Backend integration | Backend integration | Backend integration | Backend integration |
Capture can omit secure/system surfaces and protected media. Android's FLAG_SECURE can block screenshots and projection. An Accessibility tree contains only what the target app/toolkit exposes; it is not a universal DOM. Image pins annotate a saved image. Reattaching a pin to the same live native control requires stable identifiers or reliable app-specific matching.
Screen capture does not grant log, filesystem, debugger or network-decryption access. Packet/VPN capture does not itself decrypt HTTPS; trust configuration and certificate pinning can prevent proxy inspection. Desktop crash collection may need deliberate setup: Windows local dump collection, for example, is disabled by default and enabling it requires administrator privileges. Imported dumps and logs still need appropriate parsers and authorization in a future Feedbacks client.
Wide tables scroll horizontally when the page is narrow.
Coming soon: standalone capture clients
Windows, Ubuntu and macOS companions and Android/iOS standalone or sharing apps are planned, not released. The mechanisms below are design candidates, not available downloads or delivery-date commitments. The browser capture/import pilot above is already implemented separately.
| Client | Candidate mechanism | Additional verification |
|---|---|---|
| Windows companion | Windows Graphics Capture; optional UI Automation context | Signed packaging, process/privilege boundaries, protected surfaces and physical desktop acceptance. |
| Ubuntu companion | XDG ScreenCast portal and PipeWire on Wayland; separate X11 handling | Desktop/compositor/backend combinations, window-source availability and packaging. |
| macOS companion | ScreenCaptureKit; optional Accessibility context | OS capture/Accessibility permission paths, signed distribution and actual app windows. |
| Android companion | Screenshot sharing and MediaProjection | Consent for each projection session, foreground-service lifecycle, secure surfaces and real devices. Accessibility is a separate optional design, with policy review. |
| iOS companion | Screenshot/video sharing first; optional ReplayKit broadcast extension | Share/broadcast lifecycle, explicit user start, app/extension storage boundaries and real devices. |
When the target app integrates an SDK
A host integration can supply app/build/screen identity, selected logs and errors, recent navigation/action events, HTTP status/timing/request IDs, and platform-specific crash/performance diagnostics. These need explicit instrumentation and bounded collection. They are future diagnostic work, not features of the existing screenshot-only mobile integration kits.
Network payloads require deliberate selection and redaction. Backend logs need a server integration and request/trace correlation. Crash symbolication needs matching symbols/build metadata. Events that were not recorded cannot be recovered retrospectively. No SDK guarantees every crash, request or performance metric on every platform.
The intended product boundary is a common project/thread/evidence workflow, with platform capture adapters and optional app diagnostics. Native app identity and capture provenance must be represented explicitly; native pixels must not be paired with unrelated browser DOM/network evidence or use fabricated URLs to bypass project authorization.
Primary sources and applicability
Accessed 2026-10-21. These sources establish platform mechanisms and restrictions, not Feedbacks implementation or Store approval.
- Google Chrome, screen-sharing controls: desktop browser window/display selection and recording as a pilot mechanism.
- Microsoft, screen capture, UI Automation security and user-mode dumps: Windows capture, privilege boundaries and deliberate crash-collection setup.
- XDG Desktop Portal maintainers, ScreenCast, and GNOME, accessibility architecture: Linux portal/PipeWire capture and toolkit-provided UI information.
- Apple, ScreenCaptureKit, Accessibility attributes, ReplayKit security and runtime isolation: macOS capture, incomplete Accessibility support, user-approved iOS broadcasts and sandbox boundaries.
- Google Android, MediaProjection, secure activities, log access and network security configuration: per-session consent, protected pixels, restricted logs and TLS trust/pinning.
- Google, Accessibility services and Play Accessibility policy: optional cross-app UI access requires its own consent and distribution review.
- Apple, MetricKit: a host-app diagnostics mechanism, not permission to inspect other apps.