view --output fails when the Simulator window isn't visible

[webcoyote]

iosef view has two code paths that produce differently-sized images and have different window-visibility requirements:

Invocation	Capture source	Output size	Limitations
view (no --output)	IOSurface framebuffer (via captureSimulator)	iOS points (1 px = 1 point)	-
view --output <path>	CGWindowListCreateImage (via captureToFile)	window pixels (Retina ~3×)	window must be visible

So the same command prints differently-sized images depending on whether --output is passed, and --output silently fails when the Simulator window is hidden. This type of problem occurs for CI build servers and for my own project, sandvault, where I do iOS automation from within a sandbox to hidden iOS Simulator windows.

Proposed fix

Two new subcommands that capture via the framebuffer in both no-output and file modes, so they work regardless of window state:

• iosef snap-points — 1 px = 1 iOS point (coordinate-aligned with tap / describe), matches the contract view's base64 path already provides
• iosef snap-pixels — native device pixel resolution, for OCR and visual diffing

Both accept --output and --type png|jpeg|tiff|bmp|gif, exposed over MCP as snap_points / snap_pixels. view is kept unchanged for backward compatibility.

Internally this shares a captureFramebufferCGImage helper (IOSurface → simctl fallback), so the existing view base64 fast path doesn't regress.

PR

I've put together a draft PR for this at webcoyote#1 — this repo's settings restrict PRs to collaborators, so I can't open it here directly. Happy to rework the approach if you'd prefer a different shape (e.g. keeping to one command with a --framebuffer flag, or making the new behavior the default for view --output).

[riwsky]

Oh, hey @webcoyote ! Thanks for opening this and the feedback! I've added you as a collaborator opened that permission to non-collaborators. Sorry for the delay in responding here. Will leave a further comment with thoughts on the actual fix/implementation.

[riwsky]

My main take would be "making the new behavior the default for view --output"; the fact that the output dimensions and input targets varied with the mere output location is surprising enough to classify outright as a bug. I can go push an update to fix that. That leaves one, maybe two features from your PR: control of resolution (points vs pixels) and control of mechanism (--framebuffer). Are we able to get the higher resolution while sticking to the IOSurface? Presumably OCR and visual diffing don't care beyond having that resolution right, but if I were perfectly familiar with the distinctions then we wouldn't have this bug in the first place.

[riwsky]

Cut https://github.com/riwsky/iosef/releases/tag/v0.2.6 with the fix for --output

[webcoyote]

My main take would be "making the new behavior the default for view --output"; the fact that the output dimensions and input targets varied with the mere output location is surprising enough to classify outright as a bug. I can go push an update to fix that.
Cut https://github.com/riwsky/iosef/releases/tag/v0.2.6 with the fix for --output

Thanks for the fix

That leaves one, maybe two features from your PR: control of resolution (points vs pixels) and control of mechanism (--framebuffer). Are we able to get the higher resolution while sticking to the IOSurface? Presumably OCR and visual diffing don't care beyond having that resolution right, but if I were perfectly familiar with the distinctions then we wouldn't have this bug in the first place.

The device framebuffer (captureFramebufferCGImage) has a full-resolution, native-device resolution of the images. snap-pixels outputs that, while snap-points gets the scaling factor and uses that to reduce the image by that factor (e.g. retina = 3x, so 1/3 the pixels).