Repository navigation
[camera] Add macOS support #41708
Description
Since laptops commonly have cameras built in, this would be potentially useful.
Blocked on #30717
Since laptops commonly have cameras built in, this would be potentially useful.
Blocked on #30717
Activity
larryaasen commentedon Oct 21, 2020
larryaasen commentedon Oct 19, 2021
stuartmorgan-g commentedon Oct 19, 2021
larryaasen commentedon Oct 19, 2021
stuartmorgan-g commentedon Oct 19, 2021
larryaasen commentedon Oct 19, 2021
stuartmorgan-g commentedon Oct 19, 2021
mykola-blu commentedon Jun 6, 2022
moham96 commentedon Aug 19, 2022
20 remaining items
naedx commentedon Jun 10, 2024
cdeil commentedon Mar 12, 2026
@stuartmorgan-g - Should camera MacOS support be implemented by extending
camera_avfoundation? Are there any blockers/refactors that should be done before adding it? Is it possible to only support MacOS 26 or would we have to make it work and test on older versions to be accepted?stuartmorgan-g commentedon Mar 12, 2026
Yes. See the diffs from my comment above as an (outdated) example of the expected approach.
I'm not aware of any blockers, but the issues with my initial WIP were never investigated so it's possible there's an unknown issue. I would not expect one though, given the other plugins that are already support macOS.
I am not aware of anything that has changed since my initial prototype, which compiled all the way back to 10.15, that would make limiting support to 26 useful.
cdeil commentedon Mar 13, 2026
I'll take a stab at this. I only have a MacBook with MacOS 26 locally, so can't do real-device testing on older platforms.
cdeil commentedon Mar 13, 2026
I did a spike with a coding agent to add MacOS support. Branch is HERE .
It's partially working on MacOS. Photos and preview is showing but preview is rotated by 90 deg (and photo 90 deg rotated the other direction for iPhone continuity camera shown in MacOS) for so far unknown reason. Haven't tested yet at audio or recorded videos.
@stuartmorgan-g - I presume one huge PR isn't a good idea? Maybe refactor to shared Darwin layout and refactoring core
camera_avfoundationclasses that are iOS specific as first step? Or some other approach?stuartmorgan-g commentedon Mar 13, 2026
Converting from
ios/todarwin/should be its own PR without any other changes, because combining moves with non-trivial edits causesgitto think files are being deleted and created, destroying history.Without knowing anything about the scope of the changes beyond that, I don't know if one PR or multiple PRs makes more sense. If you are asking me to review the branch you linked to make that determination, please see our AI contribution guidelines; we aren't going to review raw AI output.
cdeil commentedon Mar 13, 2026
Rotation issue fixed ( flutter/packages@afb6179 ) by using
AVCaptureConnection.videoRotationAngle(available macOS 14.0+) instead of the deprecatedvideoOrientationenum. For me in the example app now everything basic seems to work (images, videos, preview, audio for internal/USB/continuity cameras).That branch was just an exploration if I can get it to work and if the shared
darwinapproach is a good one. I think the answer is "yes" so I'll start with a PR that just does theiostodarwinconversion to hopefully preserve git history on every file.stuartmorgan-g commentedon Mar 16, 2026
Shared
darwinsource is still how we handle plugins that can share most of their source code, yes.Mairramer commentedon May 31, 2026
@cdeil Are you still working on this?
I'm currently building a PoC for camera effects on both iOS and Android, and while investigating it I ran into the lack of camera support on macOS. Your implementation looks promising, so I was curious whether it's still being actively developed.
Mairramer commentedon Jun 1, 2026
Hello @stuartmorgan,
I'm currently working locally on adding macOS support to
camera_avfoundationbased on the previous experiments. To make this migration as safe and reviewable as possible, I'd like to propose splitting the work into three focused PRs instead of one large PR. This structure could also be useful if someone else decides to contribute the same effort in the future.The goal is to preserve Git history where possible and isolate risk:
PR 1: Directory Rename Only (
ios→darwin)This PR would contain only the directory move (
git mv ios darwin) and the correspondingsharedDarwinSource: trueconfiguration change, with no functional code changes.PR 2: iOS Platform/UI Abstractions
This PR would introduce the necessary
#if os(iOS)guards to isolate UIKit-specific dependencies (such asUIDeviceOrientation) from the core AVFoundation logic. It could be validated entirely on iOS, ensuring that existing behavior remains unchanged and minimizing the risk of regressions.PR 3: macOS Implementation
The final PR would add the macOS deployment configuration, camera entitlements, and macOS-specific handling for hardware rotation (
videoRotationAngle). If any unexpected macOS issues arise, this PR could be reverted independently without affecting the directory modernization introduced in the previous PRs.WDYT?
stuartmorgan-g commentedon Jun 1, 2026
As established in the comments just above, what you labelled as PR 1 must be a separate PR. PR 2 sounds fine as well.
As I said above, whether what you describe as PR 3 should actually be one PR or multiple PRs depends on how large that is, and how separable the parts are.
cdeil commentedon Jun 4, 2026
@Mairramer - thanks for taking this on! I didn't submit PRs for this since I'm still learning about AVFoundation and Flutter and didn't feel that I met the bar set by the AI contribution guideline. My impression was that coding agents give a good solution directly here, but I wasn't sure e.g. if there's some non-obvious differences in MacOS vs iOS lifecycles or cases that would need to be handled.
[camera_avfoundation] Move camera_avfoundation to Darwin (#11847)
[camera_avfoundation] Move camera_avfoundation to Darwin (flutter#11847)