Mac App Store (macOS)

Flutter macOS 앱을 Mac App Store 로 내는 절차입니다. Apple 계정 하나로 App Store 와 Mac App Store 에 모두 올릴 수 있고, 스토어 등록정보 · 앱이 수집하는 개인정보 · 수출 규정 · 연령 등급 · 심사 제출 · 출시 방식은 App Store (iOS · iPadOS) 편의 10~14단계와 같습니다. 이 페이지는 Mac 에서 달라지는 부분 — App Sandbox, 인증서, 프로비저닝 프로필, .pkg 패키지, 업로드 — 에 집중합니다.

준비물

• 끝낸 공통 준비 — 개발자 계정, 식별자와 버전, 아이콘 · 스플래시 · 스크린샷(Mac 스크린샷은 16:10 비율의 규격 크기), 개인정보와 권한.
• Mac 과 Xcode — Flutter 3.47 이 지원하는 macOS 는 Monterey(12) 이상입니다(지원 플랫폼 표). Apple 의 업로드 요건 표는 iOS 앱과 macOS 앱의 Xcode 요건을 따로 적습니다(macOS 앱은 「Xcode 6 or later」). 2026-04-28 부터의 Xcode 26 요건 문장에는 macOS 가 나열되지 않습니다(2026-10-09 확인).
• Mac 에서 시험 — 릴리스 .app 을 직접 실행해 네트워크 · 파일 접근이 샌드박스 안에서 되는지 확인합니다(제출 전 체크리스트).
• (직접 서명할 때) 인증서와 프로필 — 아래 3단계를 보세요. Apple 도움말의 「필요한 역할」 기준으로 배포 인증서는 Account Holder 또는 Admin 이 만듭니다.

Developer ID 직접 배포와의 차이

Mac 앱은 Mac App Store 로 내거나, Developer ID 로 서명해 스토어 밖(웹사이트 등)에서 직접 배포할 수 있습니다. Flutter 문서도 두 경로를 모두 안내하며, 이 가이드는 Mac App Store 경로입니다. 둘의 차이는 다음과 같습니다.

프로젝트에서 바꿀 항목

아래 파일 위치와 기본값은 flutter create 로 만든 Flutter 3.47.6 기본 프로젝트에서 확인한 것입니다(2026-10-09). 프로젝트마다 다를 수 있으니 직접 열어 확인하세요.

단계

앱 등록과 서명 준비

1. 앱 레코드를 정합니다. 계약 상태 확인 · 번들 ID 등록 · 앱 레코드 만들기는 App Store (iOS · iPadOS) 편의 1~3단계와 같고, 플랫폼으로 macOS 를 고릅니다. iOS 앱과 한 번의 구입으로 함께 팔지에 따라 둘 중 하나를 고릅니다.

   • iOS 앱과 한 앱으로 판매(유니버설 구입) — 기존 iOS 앱 레코드의 사이드바에서 「플랫폼 추가(Add Platform)」로 macOS 를 더합니다. Xcode 11.4 부터는 한 App ID 로 iOS · macOS 앱을 모두 빌드할 수 있습니다. macOS 앱은 같은 Apple ID · SKU · 번들 ID 를 쓰고, macos/ 의 번들 ID 를 iOS 와 같게 맞춥니다. 버전 번호와 빌드 번호는 iOS 와 달라도 됩니다. 플랫폼을 추가하면 기존 플랫폼 버전의 메타데이터가 새 플랫폼 버전으로 옮겨지지만 홍보용 텍스트 · 설명 · 스크린샷은 옮겨지지 않습니다. 아직 앱 레코드가 없다면 「신규 앱」 대화창에서 iOS 와 macOS 를 함께 선택해 한 레코드로 만들 수도 있습니다.
   • macOS 만 새 앱 레코드 — iOS 편 3단계처럼 「신규 앱」에서 macOS 를 고릅니다.

   주의

   Apple 은 플랫폼별로 따로 만든 앱 레코드는 합칠 수 없다고 안내합니다. 또 App Review 가 두 플랫폼 버전을 승인하면 유니버설 구입이 되고, 그 뒤에는 앱 레코드에서 플랫폼 버전 하나만 뺄 수 없습니다. 레코드를 만들기 전에 정하세요.

   성공 판정 — 앱 레코드에서 macOS 버전 페이지를 열 수 있습니다.

2. 샌드박스와 entitlements 를 맞춥니다. Mac App Store 로 내려면 App Sandbox 를 켜야 하고(심사 지침 2.4.5(i)), Flutter macOS 빌드는 기본으로 샌드박스가 적용됩니다. 샌드박스 앱은 네트워크 · 카메라 · 파일 접근 같은 권한을 entitlement 로 밝혀야 하며, 밝히지 않으면 시스템이 런타임에 막습니다. 그래서 macos/Runner/Release.entitlements 와 macos/Runner/DebugProfile.entitlements 두 파일에 앱이 쓰는 권한을 똑같이 더합니다. Flutter 문서는 특별한 이유가 없으면 두 파일을 똑같이 고치라고 하며, 기본 DebugProfile.entitlements 에도 network.client 가 없어 디버그 실행에서도 네트워크 요청이 막힙니다(Flutter 3.47.6 에서 확인).

   xml

   <key>com.apple.security.network.client</key>
   <true/>
   

   com.apple.security.network.client 는 밖으로 나가는 네트워크 연결을 열어 주며, Flutter 문서는 네트워크 요청을 하는 앱이라면 반드시 더하라고 합니다. 파일 선택기(file_selector)를 쓰면 com.apple.security.files.user-selected.read-only 나 read-write 가 필요합니다. 들어오는 연결을 받아야 하면 com.apple.security.network.server 를 릴리스 파일에도 더합니다(기본은 디버그 · 프로파일에만 켜져 있습니다). 파일을 고칠 때는 Xcode 의 capabilities 화면 대신 파일을 직접 편집하라고 Flutter 문서가 권합니다. 샌드박스의 임시 예외(temporary exception) entitlement 를 쓰는 앱은 그 entitlement 마다 정보를 Apple 에 제공해야 합니다(Apple 도움말 「App Sandbox 정보」). 성공 판정은 릴리스 빌드로 만든 앱에서 네트워크 요청과 파일 열기가 동작하는 것입니다.

3. 서명을 정합니다. Xcode 로 올린다면(아래 방법 A) open macos/Runner.xcworkspace 로 Runner 타깃의 Signing & Capabilities 에서 Automatically manage signing 을 켜고 Team 을 고르면 됩니다. Apple 은 자동 서명으로 올리면 Xcode 가 배포 프로비저닝 프로필을 관리한다고 안내합니다. 명령줄로 직접 서명한다면(방법 B) 아래를 준비합니다.

   준비할 것	이름과 만드는 곳
   앱 서명 인증서	Apple 의 Mac 배포 서명 문서는 Mac App Store 앱에 「Apple Distribution」 서명 ID(Apple Distribution: <팀 이름> (<팀 ID>))를 쓰라고 합니다. 인증서 개요에는 「Mac App Distribution」(Mac App Store 에 제출하기 전에 Mac 앱에 서명)도 나열됩니다
   설치 패키지 서명 인증서	「Mac Installer Distribution」. 키체인 이름은 3rd Party Mac Developer Installer: <팀 ID> 로 보입니다
   프로비저닝 프로필	Certificates, Identifiers & Profiles 의 Profiles → 추가 버튼(+) → Distribution 에서 「Mac App Store Connect」(Mac 앱용) → 번들 ID 와 일치하는 App ID → 배포 인증서 → 이름 → Generate → Download. 파일 확장자는 .provisionprofile 입니다. 프로필에는 배포 인증서가 하나만 들어가니 앱 서명에 쓸 인증서(Apple Distribution 또는 Mac App Distribution)를 그대로 고르세요

   Apple 도움말의 「필요한 역할」은 Account Holder 또는 Admin 이고, 배포 인증서는 Developer ID 인증서를 뺀 종류마다 팀당 하나만 허용됩니다. 인증서를 만들 때 필요한 서명 요청(CSR)은 iOS 편 4단계와 같습니다. 성공 판정 — 방법 A 라면 Signing & Capabilities 에 서명 오류가 없습니다. 방법 B 라면 서명 인증서 둘과 프로필 파일(.provisionprofile)이 준비됐습니다.

빌드와 업로드

4. flutter build macos 로 릴리스 빌드를 만듭니다.

   bash

   flutter build macos --build-name=1.0.0 --build-number=1
   

   기본이 릴리스 모드이고, 결과 앱은 build/macos/Build/Products/Release/<앱 이름>.app 에 생깁니다. 이 앱은 ad hoc 서명이라(Flutter 3.47.6 에서 확인) Mac App Store 에 내려면 Apple 이 요구하는 배포용 서명(distribution-signed)을 입혀야 합니다. 아래 방법 A 나 B 로 입힙니다. Dart 코드를 난독화하려면 --obfuscate --split-debug-info=<심볼 폴더> 를 함께 줍니다. 성공 판정은 명령이 Built build/macos/Build/Products/Release/….app 을 출력하는 것입니다.

5. 방법 A(권장) — Xcode 로 보관(Archive)하고 올립니다. Flutter 문서가 안내하는 경로입니다. open macos/Runner.xcworkspace 로 연 뒤 다음을 합니다.

   1. Runner 타깃 General → Identity 에서 App Category · Bundle Identifier · 버전과 빌드 번호를 확인합니다.
   2. 메뉴 Product → Archive 로 아카이브를 만듭니다. Archives organizer 에 나타납니다.
   3. 아카이브를 골라 Validate App 으로 제출 전 자동 검증을 합니다. 문제가 있으면 고쳐 다시 빌드합니다.
   4. Distribute App 에서 「TestFlight & App Store」(기본 권장 설정)를 고르거나, Custom 에서 「App Store Connect」를 고르고 대상(destination)으로 업로드를 고릅니다. Xcode 가 처리 · 패키징 · 업로드를 시작합니다.

   Mac 앱에는 Distribute App 의 Release Testing 과 Enterprise 방식은 쓸 수 없습니다. 성공 판정은 Xcode 가 업로드를 마치고 App Store Connect 앱의 빌드 목록에 빌드가 나타나는 것입니다.

6. 방법 B — 명령줄로 서명하고 .pkg 를 만들어 올립니다. CI 처럼 Xcode 화면을 쓸 수 없을 때의 경로입니다. Mac App Store 는 앱을 설치 패키지(.pkg) 로 받습니다.

   주의

   이 경로는 서명 · entitlements · 프로파일을 직접 책임집니다. Apple 이 Flutter 앱용으로 완성된 명령 한 벌을 주지는 않아서, 아래는 Apple 문서의 규칙을 순서대로 옮긴 것입니다. 같은 일을 하는 CI 예시는 Flutter 문서의 「Create a build archive with Codemagic CLI tools」 절에 있습니다(서드파티 도구를 씁니다). 막히면 방법 A 를 쓰세요.

   1. entitlements 파일을 준비합니다. 배포용 .app 에 넣을 entitlements 를 만듭니다. Apple 은 Xcode 로 개발 서명한 앱에서 codesign -d --entitlements - --xml <앱> | plutil -convert xml1 -o - - 로 entitlements 를 출력해 배포용 파일의 바탕으로 쓸 수 있다고 안내하고, 디버거 연결을 허용하는 com.apple.security.get-task-allow 는 배포용에는 거의 쓰지 않는다고 합니다. Flutter 가 만든 릴리스 .app 에서 이렇게 뽑으면 com.apple.security.app-sandbox 와 함께 com.apple.security.get-task-allow 가 들어 있습니다(Flutter 3.47.6 에서 확인). 배포용 파일에서는 이 키를 빼는 쪽이 Apple 안내에 맞으니, 2단계에서 정한 앱 권한만 남기세요. 파일은 표준 XML 속성 목록(LF 줄바꿈, 주석 없음, BOM 없음)이어야 합니다.

   2. 배포 프로비저닝 프로필을 앱 번들에 넣습니다. 3단계에서 받은 프로필을 <앱>.app/Contents/embedded.provisionprofile 로 복사합니다. 앱 번들을 고치면 서명이 깨지므로 아래 서명 전에 합니다. TestFlight 대상이 되려면 프로비저닝 프로필에 application identifier 가 있어야 합니다.

   3. com.apple.quarantine 확장 속성을 없앱니다. 프로필을 복사한 뒤, 서명과 .pkg 만들기 전에 합니다. macOS 에서 cp · ditto 로 복사하면 원본의 com.apple.quarantine 속성이 복사본에도 붙으므로(macOS 에서 확인) 내려받은 프로필의 속성이 앱 번들로 따라 들어올 수 있습니다. xattr -lr "<앱>.app" 으로 com.apple.quarantine 이 있는지 보고, 있으면 xattr -dr com.apple.quarantine "<앱>.app" 로 지웁니다. Apple 은 2025-02-18 부터 앱 안의 모든 파일에서 이 속성을 지워야 App Store Connect 에 올릴 수 있다고 안내합니다. .pkg 를 만든 뒤에 지우면 이미 만든 .pkg 안에는 속성이 남으니(macOS 에서 확인) 그때는 .pkg 를 다시 만드세요.

   4. 안쪽 코드부터 서명합니다. 번들 안의 프레임워크 등 모든 실행 코드를 안쪽부터 서명하고 마지막에 .app 을 서명합니다. 이미 서명된 코드를 다시 서명하려면 -f, 메인 실행 파일에는 --entitlements 를 더합니다. --deep 은 쓰지 말라고 Apple 이 권고합니다. 빌드 산출물 .app 을 다른 폴더로 옮겨 서명한다면 cp -R 대신 ditto 를 쓰세요. ditto 는 Mac 프레임워크 구조에 중요한 심볼릭 링크를 보존합니다.

      bash

      codesign -s "Apple Distribution: <팀 이름> (<팀 ID>)" -f \
        "<앱>.app/Contents/Frameworks/<프레임워크>.framework"
      codesign -s "Apple Distribution: <팀 이름> (<팀 ID>)" -f \
        --entitlements "<배포용>.entitlements" "<앱>.app"
      

      예시의 서명 ID 이름은 Apple 문서의 표기입니다. 실제 이름은 security find-identity -v 출력에서 그대로 복사하고, 같은 이름이 여러 개면 이름 대신 그 줄의 SHA-1 해시로 지정하세요. 성공 판정 — codesign --verify --deep --strict -vv "<앱>.app" 가 valid on disk 와 satisfies its Designated Requirement 를 출력합니다(서명을 만들 때는 --deep 을 쓰지 말라는 것이지 검증에는 써도 됩니다).

   5. .pkg 를 만듭니다. 앱 하나뿐이면 productbuild 의 가장 단순한 형태가 Mac App Store 제출에 충분하다고 Apple 이 안내합니다. Mac App Store 용 패키지는 --component 방식만 써야 합니다(man productbuild).

      bash

      productbuild --sign "3rd Party Mac Developer Installer: <팀 ID>" \
        --component "<앱>.app" /Applications "<앱>.pkg"
      

      설치 패키지 서명 ID 는 코드 서명 ID 와 달라서 security find-identity -v 로 찾아야 합니다(-p codesigning 으로 거르면 나오지 않습니다). 성공 판정 — pkgutil --check-signature "<앱>.pkg" 가 설치 패키지 서명 인증서를 보여 줍니다.

   6. 업로드합니다. Apple 은 서명한 설치 패키지를 altool 명령줄 도구나 Transporter 앱으로 제출하라고 안내합니다. Transporter 는 Mac App Store 에서 받는 macOS 앱입니다. 명령줄은 iOS 편 7단계와 같은 방식(API 키 또는 사용자 이름과 앱 암호)으로 인증하고, 형식은 다음과 같습니다.

      bash

      xcrun altool --upload-package "<앱>.pkg" \
        --apple-id <앱의 Apple ID> --bundle-id <번들 ID> \
        --bundle-short-version-string <버전> --bundle-version <빌드 번호> \
        --apiKey <키 ID> --apiIssuer <발급자 ID>
      

      --upload-app 형식의 deprecated 안내와 옵션 이름 확인은 iOS 편 7단계의 알림을 따르세요. -t(플랫폼)는 선택 사항이며(altool 가이드) 값 이름이 가이드(osx · ios · appletvos)와 Xcode 27.0 의 altool --help(macos · ios · appletvos · visionos)에서 다르니 쓰려면 도움말로 확인하세요.

   성공 판정 — 방법 B 의 각 명령이 오류 없이 끝나고, 업로드 도구가 끝난 뒤 7단계에서 빌드가 나타납니다.

시험과 출시

7. 처리를 기다리고 TestFlight 로 시험합니다. 처리가 끝나면 이메일이 오고 빌드가 나타납니다. TestFlight 는 Mac 앱도 지원하며, Mac 용 TestFlight 를 쓰려면 macOS 앱을 Xcode 13 이상으로 빌드하라고 Apple 이 안내합니다. 빌드가 TestFlight 대상이 되려면 프로비저닝 프로필 안에 application identifier 가 있어야 합니다. 내부 · 외부 테스트 방법은 iOS 편 8~9단계와 같습니다. App Store 로 내기 전에 Apple 이 공증한 빌드를 직접 나눠 줘 시험할 수도 있습니다. 성공 판정 — 빌드가 앱의 TestFlight 탭에 나타나고 테스터가 설치해 실행합니다.
8. 심사에 제출하고 출시합니다. iOS 편 10~14단계와 같은 항목을 채우고 빌드를 골라 제출합니다. 이름 · 연령 등급처럼 플랫폼이 함께 쓰는 앱 정보는 앱 레코드에 한 번만 채우고, 지원 URL · 저작권 · 앱 심사 정보 · 버전 출시 설정 같은 버전 정보는 macOS 버전 페이지에서 채웁니다(Apple 의 필수 속성 표). 플랫폼마다 앱 버전을 따로 제출하고, 한 플랫폼 버전의 상태가 다른 플랫폼 버전의 상태에 영향을 주지 않습니다. 수동 출시를 골랐다면 macOS 버전도 따로 「이 버전 출시」를 눌러야 합니다. 성공 판정 — macOS 버전의 상태가 「심사 대기 중」으로 바뀝니다.

확인

• 샌드박스: 릴리스 .app 에서 codesign -d --entitlements - <앱> 출력에 com.apple.security.app-sandbox 가 true 로 있습니다. 앱을 실행한 뒤 Activity Monitor 의 View → Columns → Sandbox 열에서 앱이 「Yes」입니다.
• 권한: 릴리스 빌드에서 네트워크 요청 · 파일 열기 같은 기능이 동작합니다.
• 업로드: 앱의 빌드 목록(TestFlight 탭)에 macOS 빌드가 나타나고 빌드 번호가 방금 올린 값과 같습니다.
• 제출: macOS 버전의 상태가 「심사 대기 중」으로 바뀌었습니다. 심사가 시작되면 「심사 중」이 됩니다.
• 출시: 상태가 「배포 준비됨(Ready for Distribution)」이고 Mac App Store 에서 앱 제품 페이지가 열립니다.

자주 겪는 문제

다음 단계

Mac 앱까지 준비됐다면 제출 직전에 제출 전 체크리스트의 Mac App Store 구역을 훑으세요. iPhone · iPad 앱은 App Store (iOS · iPadOS) 편에서, 다른 스토어는 스토어별 안내에서 고릅니다. 출시한 뒤의 업데이트와 거절 대응은 출시 후 운영에서 다룹니다.