App Store의 소셜 미디어 체크박스, 그리고 그 대가
9월부터 시작되는 제출 요건의 무게 전체를 App Store Connect API의 Boolean 필드 두 개가 짊어집니다. socialMedia와 socialMediaAgeRestricted입니다.1 이 중 두 번째 필드는 entitlement 하나, API 도입, 그리고 앱 동작의 분기 처리라는 대가를 요구합니다.
Apple은 2026년 6월 8일에 이 요건을 발표했습니다. “2026년 9월부터 App Store에 새 버전이나 업데이트를 제출하거나 대체 앱 마켓플레이스 배포를 위한 공증(notarization)을 받으려면, 앱 또는 게임에 소셜 미디어 기능이 포함되어 있는지 표시해야 합니다.”2 그리고 7월 9일에 Apple은 설문 변경을 실제로 반영하면서, 그때까지 남은 기간을 어떻게 써야 할지를 결정짓는 한 문장을 덧붙였습니다. “오늘부터 이 질문들을 검토하고 답변할 수 있습니다.”3
핵심 요약
- 이 신고 항목은 지금 App Store Connect에서 이미 답변할 수 있고, 2026년 9월부터 필수가 됩니다. 답변 가능해진 시점과 필수가 되는 시점 사이의 간격은 마감에 쫓기는 시간이 아니라 판단을 내리는 데 쓸 수 있는 여유입니다.23
- Apple은 “소셜 미디어 기능”을 실제로 정의합니다. 네 군데에 정의가 있고, 그 내용이 서로 일치하지 않습니다. 6월 발표는 “콘텐츠가 다수의 사용자에게 눈에 띄게 확산되는” 피드로 범위를 한정하지만, 7월 발표는 그 문구를 통째로 뺐습니다.234
- App Store Connect API는 이 답변을 쓰기 가능한 Boolean 두 개로 노출하고,
userGeneratedContent와messagingAndChat은 각각 다른 등급 하한을 갖는 별개의 질문으로 유지합니다. 소셜 미디어는 이름만 바뀐 항목이 아니라 새로운 축입니다.14 - 13세 미만 소셜 미디어 분류에서 빠지려면 조건 하나가 아니라 세 가지를 충족해야 합니다. Apple 뉴스 게시물은 Declared Age Range API를 언급하고, App Store Connect 도움말은 여기에 13세 미만 사용자는 아예 접근할 수 없어야 한다는 점과 “연령에 적합한 UGC만 제공된다”는 조건을 더합니다.24
- Declared Age Range API는 iOS, iPadOS, Mac Catalyst, macOS에만 제공되고 그 외에는 없습니다.5 tvOS, visionOS, watchOS 앱도 9월에는 똑같이 이 질문에 답해야 하지만, 예외 조항의 자격을 얻는 문서화된 방법이 해당 플랫폼에는 존재하지 않습니다.
이번 주기에서 유일하게 달력이 방아쇠를 당기는 변화
이번 주기에 제가 다룬 다른 모든 파괴적 변경은 개발자가 먼저 움직이기를 기다립니다. 실행 화면 요건은 iOS 27.0 SDK로 빌드할 때 발동합니다. @State 매크로는 Xcode 27에서 프로젝트를 열 때 발동합니다. On Demand Resources 지원 중단은 무기한 무시해도 되는 컴파일러 경고를 띄울 뿐입니다. 툴체인을 그대로 두면 셋 중 어느 것도 개발자에게 닿지 않습니다.
하지만 소셜 미디어 신고는 어떻게든 도달합니다. Apple이 이를 특정 달과, 어차피 하고 있던 행위에 묶어 두었기 때문입니다. 한 줄짜리 버그 수정도 기능 릴리스와 똑같은 제출 경로를 탑니다. 그리고 9월이 되면 그 경로가 이 질문을 던집니다.
적용 범위는 좁고, 문구 그대로 정확히 읽을 가치가 있습니다. 이 요건은 “App Store에 제출하는 새 버전 또는 업데이트”와 “대체 앱 마켓플레이스 배포를 위한 공증”을 대상으로 합니다.2 7월 발표는 같은 쌍을 “App Store에 제출하는 새 앱 또는 업데이트”와 “대체 배포를 위해 공증에 제출하는 앱”으로 다시 표현합니다.3 두 발표 어디에도 SDK 버전이나 배포 대상 버전, 플랫폼에 대한 언급은 없습니다. 이미 출시된 앱은 계속 판매됩니다. 관문은 다음 제출의 문턱에 서 있습니다.
이 답변의 대가는 부모가 사용 시간을 제한할 수 있는 분류에 편입된다는 점입니다. Time Allowances는 올가을 Ask to Browse, Schedules, 새로 디자인된 Screen Time과 함께 등장하며, 부모에게 “엔터테인먼트, 게임, 소셜 미디어를 포함한 여러 카테고리 전반에서 자녀가 앱에 쓰는 시간을 관리할 더 유연한 방법”을 제공합니다. 연령에 맞춘 안내가 그 출발점입니다.16 엔터테인먼트와 게임 분류는 App Store Connect에서 선택한 카테고리를 따릅니다. 반면 소셜 미디어 분류는 오직 설문 답변만을 따르며, “App Store Connect에서 선택한 카테고리와 무관”합니다.2 피드를 갖춘 퍼즐 게임은 제품 페이지에 뭐라고 적혀 있든, 부모가 가장 먼저 조이는 분류에 들어갑니다.
Apple은 용어를 정의하지만, 그 정의가 서로 어긋납니다
정책 관련 질문에서 흔한 실패는 정의되지 않은 단어를 두고 짐작하는 것입니다. Apple은 정의를 공개했고, 덕분에 짐작의 폭은 좁아집니다. 다만 그 정의를 경계가 서로 다른 네 가지 형태로 공개했습니다.
6월 발표는 포괄적으로 서술합니다. “여기에는 소셜 피드 또는 이와 유사한 발견 수단을 통해 사용자 제작 콘텐츠를 재배포, 증폭하거나 그와 상호작용하여 콘텐츠가 다수의 사용자에게 눈에 띄게 확산되도록 하는 기능이 포함됩니다.”2
7월 발표는 더 짧게, 정의문의 형태로 서술합니다. “소셜 미디어 기능이란 소셜 피드 또는 이와 유사한 발견 수단을 통해 사용자 제작 콘텐츠를 재배포, 증폭하거나 그와 상호작용하는 기능을 말합니다.”3 콘텐츠가 다수의 사용자에게 눈에 띄게 확산된다는 한정 문구가 사라졌습니다.
App Store Connect 도움말은 가장 긴 판본을 싣고 있으며, 한정 문구를 유지하고 예시를 덧붙입니다. “소셜 피드 또는 이와 유사한 발견 수단을 통해 사용자 제작 콘텐츠를 재배포, 증폭하거나 그와 상호작용하여 콘텐츠가 다수의 사용자에게 눈에 띄게 확산되는 경우. 여기에는 사용자가 소셜 피드, 커뮤니티, 검색 또는 기타 공유·발견 도구를 통해 사용자 제작 콘텐츠를 재게시하거나, 좋아요를 누르거나, 댓글을 달거나, 반응하거나, 더 잘 보이게 만드는 행위가 포함될 수 있습니다.”4
네 가지 중 셋은 광범위하고 눈에 띄는 확산을 요구합니다. 하나는 요구하지 않는데, 경계선에 걸친 앱이라면 이 차이가 답을 결정합니다. 저라면 도움말 페이지를 기준으로 삼겠습니다. 설문이 그 페이지로 연결되고, 뉴스 게시물은 시간이 지나면 낡기 때문입니다. 다만 이렇게 읽는 것은 Apple의 지시가 아니라 제 판단입니다. “포함될 수 있습니다”라는 표현도 중요합니다. Apple은 목록을 닫아 두지 않고 예시만 나열했으므로, 열거된 다섯 가지 동사 중 무엇과도 닮지 않은 기능이라도 여전히 해당될 수 있습니다.
경계를 더 또렷하게 만드는 것은 이 표시가 어떤 항목들과 나란히 놓여 있는가입니다. Apple은 사용자 제작 콘텐츠(User-Generated Content)를 별도로 “앱이 의도한 사용자 경험의 구성 요소로서 사용자가 만든 콘텐츠를 광범위하게 배포하는 것”이라고 정의하고, 메시지 및 채팅(Messaging and Chat)은 또 따로 사용자가 “앱 내 기능을 통해 서로 직접 소통할 수 있는” 경우로 정의합니다.4 App Store Connect API는 이 구분을 그대로 유지해 userGeneratedContent, messagingAndChat, socialMedia를 서로 독립적인 Boolean 세 개로 둡니다.1
등급도 그만큼 뚜렷하게 갈립니다. 사용자 제작 콘텐츠와 메시지는 둘 다 Apple의 4+ 정의에 들어 있습니다. 소셜 미디어는 13+에서 처음 등장합니다.4 어떤 앱이 사용자 콘텐츠를 담고 사람들이 서로 메시지를 주고받게 해도 여전히 4+ 등급을 받을 수 있습니다. 그러나 같은 콘텐츠를 낯선 이들에게까지 증폭하는 피드를 더하는 순간 하한이 아홉 살 위로 뜁니다. 두 소셜 미디어 표시는 모두 OS 26 이상의 등급 체계에만 존재하며, 그 이전 OS 버전을 위한 Apple의 표에는 어떤 등급에도 소셜 미디어 항목이 없습니다.4
오늘 바로 답할 수 있는 항목입니다
Apple이 내놓은 세 가지 자료가 설문 변경이 이미 반영되었음을 확인해 줍니다. 이 글 전체의 실질적인 요점이 바로 여기에 있습니다.
7월 9일 Apple 발표는 설문에 “이제 앱의 소셜 미디어 기능에 관한 질문이 포함된다”고 밝히며 지금 바로 답변할 것을 권합니다.3 App Store Connect API 문서는 socialMedia를 “앱에 소셜 미디어 기능이 포함되어 있는지를 나타내는 Boolean 값”으로, socialMediaAgeRestricted를 “앱의 소셜 미디어 기능이 연령 제한을 받는지를 나타내는 Boolean 값”으로 기술합니다.1 Apple이 공개한 OpenAPI 명세에도 두 필드 모두 쓰기 가능하고 null을 허용하는 Boolean으로 들어 있습니다.1 이 둘은 Apple이 앞서 설문을 전면 개편하며 추가한 ageAssurance 옆에 놓여 있는데, ageAssurance의 정의는 “declared age range API”를 자격 요건을 충족하는 수단 중 하나로 명시합니다.415 따라서 예외 조항을 택하면 그 정의 안에도 함께 들어가게 됩니다. 제가 보기에 이는 그대로 두어도 되는 질문이 아니라 다시 살펴봐야 할 두 번째 질문입니다.
제출을 자동화하고 있다면 지금 그 형태를 익혀 두어야 합니다. 신고 내용은 GET /v1/appInfos/{id}/ageRatingDeclaration으로 읽고, PATCH /v1/ageRatingDeclarations/{id}로 쓰며, 두 Boolean 중 어느 쪽이든 fields[ageRatingDeclarations] 파라미터로 전달할 수 있습니다.1 연령 등급 페이로드를 손으로 조립하는 자동화 경로는 어느 날 갑자기 실패하기 전까지는 계속 통과합니다.
7월에야 드러난 결과가 하나 있습니다. “이러한 기능을 갖춘 앱은 App Store 제품 페이지에 새로운 소셜 미디어 콘텐츠 표시가 노출됩니다.”3 ‘예’라고 답하면 자녀 보호 기능의 분류만 바뀌는 것이 아니라 스토어 등록 정보 자체가 바뀝니다.
그러니 이번 주에 설문을 열어 App Store Connect가 계산해 주는 등급을 확인하세요. 제출하기 전까지는 아무것도 확정되지 않으며, 이렇게 해 두면 다가오는 기한이 이미 내려 둔 판단으로 바뀝니다.
예외 조항의 조건은 하나가 아니라 셋입니다
Apple 뉴스 게시물은 13세 미만 경로를 API 호출 한 번이면 되는 일처럼 들리게 합니다. “앱 또는 게임에 소셜 미디어 기능이 포함되어 있으나 13세 미만에게는 비활성화되어 있다고 표시하면, 13세 미만 사용자에 대해서는 소셜 미디어 Time Allowance 카테고리에 포함되지 않습니다… 또한 사용자의 연령대를 확인하기 위해 최소한 Declared Age Range API를 사용해야 합니다.”2
App Store Connect 도움말은 같은 표시를 세 가지 요건으로 서술합니다. “13세 미만 사용자는 소셜 미디어 기능에 접근할 수 없습니다. 소셜 미디어 기능을 활성화하기 전에 사용자의 연령대를 확인하기 위해 최소한 Declared Age Range API를 호출합니다. 연령에 적합한 UGC만 제공됩니다.”4
아무도 인용하지 않는 문장은 세 번째입니다. “연령에 적합한 UGC만 제공됩니다”는 딸린 API도 없고, 공개된 기준선도 없으며, 돌려 볼 수 있는 테스트도 없는 콘텐츠 관리 의무입니다. Apple은 ‘연령에 적합함’도, 그 전달 방식도 정의하지 않습니다. 연령 확인 관문만 도입하고 12세 아이에게도 걸러지지 않은 똑같은 피드를 그대로 내보내는 팀은, 도움말 페이지의 문장 그대로 따지면 세 조건 중 하나만 충족한 셈입니다.
이 예외 조항으로 얻지 못하는 것도 함께 봐야 합니다. Apple의 같은 문장은 그런 앱도 “13세 이상 사용자에 대해서는 소셜 미디어 카테고리에 그대로 남는다”고 이어집니다.2 면제는 13세 미만 사용자에게만 적용되므로, 14세 사용자는 부모가 소셜 미디어에 걸어 둔 제한을 그대로 적용받습니다.
등급 표에는 제가 끝내 해소하지 못한 모순이 있습니다. Apple 뉴스 게시물은 제한 옵션을 선택하면 “연령 등급 설문에 대한 전체 응답”이 등급을 결정하며 “13+보다 낮은 등급이 나올 수도 있다”고 말합니다.2 그런데 Apple의 글로벌 표는 “소셜 미디어”와 “13세 미만 사용자에 대해 비활성화된 소셜 미디어”를 모두 기능(Capabilities) 항목의 13+에 올려 두었고, 지역별 표에서도 둘을 나란히 호주 16+, 브라질 A16, 한국 15세 이용가, 베트남 16+에 배치합니다.4 다른 모든 행이 그렇듯 표시가 하한을 정한다고 읽으면, 제한 옵션 역시 13+ 하한처럼 보입니다. Apple은 이 둘을 조율해 주지 않고, 저 역시 계산기가 어느 문서를 구현했는지 추측하지 않겠습니다. 실제 설문에서 해당 옵션을 선택하고, 계산된 등급을 읽고, 두 문서보다 계산기를 믿으세요.
체크박스를 따라 앱 안까지 들어가 보기
예외 조항을 택한다고 해 봅시다. Xcode에서 대상 타깃에 Declared Age Range capability를 켜면 com.apple.developer.declared-age-range entitlement가 추가됩니다. “앱이 사용자의 연령대를 요청할 수 있는지를 나타내는 Boolean 값”입니다.6 그다음 필요한 기준 연령을 넣어 API를 호출하는데, SwiftUI에서는 환경 액션의 형태로 제공됩니다.5
Apple은 이 액션에 호출 위치에 관한 규칙을 붙여 두었습니다. “사용자 상호작용에 대한 응답으로” 사용하라는 것이고, Apple이 제공하는 예제 코드도 호출을 버튼 뒤에 둡니다.5 이 요청은 시스템 시트를 띄울 수 있으므로, .task나 onAppear에서 호출하면 아직 아무것도 요청하지 않은 사용자에게 권한 요청 화면을 들이미는 꼴이 됩니다. 대신 제한된 화면으로 들어가는 탭 동작에 걸어 두세요.
import SwiftUI
import DeclaredAgeRange
@available(iOS 26.0, *)
struct SocialFeedGate: View {
@Environment(\.requestAgeRange) private var requestAgeRange
@State private var feedEnabled = false
@State private var checking = false
var body: some View {
if feedEnabled {
FeedView()
} else {
Button("Open community feed") {
checking = true
Task {
feedEnabled = await resolveGate()
checking = false
}
}
.disabled(checking)
}
}
private func resolveGate() async -> Bool {
guard let response = try? await requestAgeRange(ageGates: 13) else {
return false // AgeRangeService.Error: your default, not Apple's
}
guard case let .sharing(ageRange) = response else {
return false // .declinedSharing
}
guard let lowerBound = ageRange.lowerBound else {
return false // nil lower bound means below your lowest gate
}
return lowerBound >= 13
}
}
이 코드에서 관문이 제대로 버티는지를 좌우하는 지점은 네 군데입니다.
기준 연령은 최대 세 개까지입니다. 두 오버로드 모두 기준값 세 개에서 멈춥니다. SwiftUI 액션은 callAsFunction(ageGates threshold1: Int, _ threshold2: Int? = nil, _ threshold3: Int? = nil)이고, UIKit 메서드는 여기에 표시 앵커만 더합니다.7 구간은 최대 네 개가 한계입니다. Apple 규칙을 위한 13세와 호주 법을 위한 16세가 필요하다면, 무엇을 설계하기도 전에 네 구간 중 셋을 이미 써 버린 셈입니다.
lowerBound가 nil인 것은 오류가 아니라 답입니다. AgeRange.lowerBound와 upperBound는 둘 다 Int?이고, Apple은 nil인 경우를 분명하게 밝힙니다. “이 값이 nil이면 해당 사용자의 연령대가 지정한 가장 낮은 연령보다 아래라는 뜻이며, 개발자가 요구하는 최소 연령에 미치지 못함을 나타냅니다.”8 낙관적으로 옵셔널을 해제하는 코드는 하필 이 관문이 보호하려는 바로 그 대상에게 관문을 거꾸로 열어 줍니다.
거부는 실제로 처리해야 하는 분기이며, Apple은 어떻게 다루라고 말해 주지 않습니다. AgeRangeService.Response는 .sharing(range:)와 .declinedSharing을 갖습니다.9 일부 규제 지역에서는 “시스템이 자동으로 해당 사용자의 연령대를 제공”하며 사용자는 “공유를 거부할 수 없습니다”. 규제 대상이 아닌 지역에서는 “사용자가 거부하면 declinedSharing 응답을 받습니다.”10 거부는 프라이버시를 중시하는 성인과 구별되지 않습니다. 13세 미만으로 간주하면 성인을 막게 되고, 성인으로 간주하면 닫아 두겠다고 약속한 관문을 열게 됩니다. Apple은 기본 처리를 개발자에게 맡깁니다. 저라면 닫히는 쪽으로 처리하고, 그 사실을 화면에 밝히겠습니다.
개발자가 지정한 기준 연령은 권고에 가깝습니다. 시스템은 “사용자의 위치와 적용 법규에 따라 지정한 기준 연령을 무시하는 연령대를 반환할 수 있으며”, 현지 법규가 특정 기준 연령을 요구하는 경우 “반환되는 연령대는 개발자가 지정한 기준의 범위가 아니라 규제 요건을 반영합니다.”7 반환값이 요청과 일치한다고 가정한 코드는 규제가 가장 엄격한 관할 지역에서 가장 먼저 오작동합니다.
설계에 반드시 반영해야 할 동작이 하나 더 있는데, 저는 이것이 고객 문의를 부를 것이라고 봅니다. Apple은 답변을 캐시합니다. “시스템은 프라이버시 보호를 위해 연령대 응답을 캐시합니다. 사용자의 나이가 새로운 연령대로 넘어가더라도(예: 만 13세가 되는 경우) API는 최초 선언 시점의 기념일이 될 때까지 이전 연령대를 계속 반환합니다.”10 월요일에 13세가 된 아이가 몇 달 동안 13세 미만으로 읽힐 수 있다는 뜻입니다. 해결책은 사용자가 혼자 찾아 들어가야 하는 설정 경로입니다. iPhone·iPad의 설정 또는 Mac의 시스템 설정에서 본인 이름, 그다음 개인 정보, 그다음 앱용 연령대 순으로 들어가야 합니다.10 13세를 기준으로 관문을 두는 앱이라면 이 안내를 자체 UI 안에 넣어야 합니다. 그러지 않으면 아무도 찾아내지 못합니다.
설계 단계에서 챙겨야 할 더 작은 세부 사항이 둘 있습니다. isEligibleForAgeFeatures는 해당 사용자가 연령 확인을 요구하는 지역에 있는지를 알려 주는데, macOS에서는 “시스템이 해당 사용자나 기기에 대해 연령 확인을 요구하지 않으므로 false를 반환”합니다. 따라서 Mac 앱은 대신 requestAgeRange를 바로 호출합니다.11 그리고 연령이 어떤 방식으로 설정되었는지를 알려 주는 AgeRangeDeclaration은 이미 한 차례 뒤집혔습니다. 26.2에서 결제 수단, 정부 발급 신분증 등 본인과 보호자별 확인 방식을 구분하던 여섯 개의 세분화된 case가 26.5에서 confirmed 하나로 통합되었습니다.12 어떤 방식으로 사용자를 확인했는지 물으면, 지금의 API는 더 이상 답해 주지 않습니다.
그다음은 플랫폼 하한인데, 이는 availability 메타데이터에만 적혀 있을 뿐 어떤 서술형 문서에도 나오지 않습니다. Declared Age Range는 iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0, macOS 26.0만 게시하고 그 외에는 없습니다. tvOS 항목도, visionOS 항목도, watchOS 항목도 없습니다.5 Time Allowances 역시 같은 계열, 즉 “iOS 27, iPadOS 27, macOS 27 이상”에 도착하는 반면, 신고 요건에는 플랫폼 단서가 전혀 붙어 있지 않습니다.23 따라서 소셜 피드를 갖춘 tvOS 또는 visionOS 앱은 9월에 답변해야 하면서도 예외 조항의 문서화된 최소 요건을 충족할 수 없습니다. 그 조항이 지목하는 API가 거기에는 존재하지 않기 때문입니다. 이 어긋남을 의도적인 면제가 아니라 빈틈으로 읽는 것은 제 추론이며, Apple은 어느 쪽으로도 아무것도 밝히지 않았습니다.
제 앱 여덟 개는 어떻게 답하게 되는가
남의 코드를 논하기 전에 제 코드부터 조사했습니다. Xcode 프로젝트 여덟 개, Swift 파일 491개입니다.13 그중 CKShare, UICloudSharingController, 공유 또는 공개 CloudKit 데이터베이스, GameKit, Declared Age Range 관련 심볼을 포함한 것은 하나도 없습니다. 이 집합의 어떤 앱도 콘텐츠를 한 사람에게서 다른 사람에게로 옮기지 않습니다. 네 개 프로젝트는 문제 될 만한 화면이 아예 없습니다. 나머지 넷은 신중한 사람이라면 망설일 법한 화면을 갖고 있는데, 크게 세 종류로 나뉘고 각각 소리 내어 따져 볼 가치가 있습니다.
Get Bananas에는 공유 장보기 목록이 있는데, 여기서 ‘공유’는 들리는 것보다 좁은 의미입니다. 이 앱은 JSON 문서를 iCloud ubiquity 컨테이너에 쓰고 iPhone, Apple Watch, Mac에서 다시 읽어 들입니다. com.apple.developer.icloud-services는 CloudDocuments로 설정되어 있고, 프로젝트 어디에도 CloudKit 공유는 없습니다.13 목록은 사람들 사이가 아니라 한 사람의 여러 기기 사이에서 공유되므로, 재배포되는 것도 없고 확산될 상대 사용자도 없습니다. 가족 협업을 위해 CKShare를 넣는 날 답이 뒤집히겠지만, 그때조차 소셜 미디어가 아니라 사용자 제작 콘텐츠 쪽으로 뒤집힙니다. 두 사람짜리 장보기 목록에는 피드도, 발견 화면도 없기 때문입니다. 정작 주시해야 할 선은 그보다 더 바깥에 있습니다. 공유 목록에 공개 템플릿 갤러리와 좋아요가 더해지면, 그것은 단계만 몇 개 더 거친 피드입니다.
세 개 앱은 공유 시트를 띄우는데, 공유 시트는 소셜 기능이 아닙니다. Get Bananas, Water, ResumeGeni의 iOS 앱은 각각 UIActivityViewController를 감싸서 사용자 본인의 콘텐츠를 사용자가 고른 앱에 넘깁니다.13 그 콘텐츠는 메시지나 메일로 떠나 버리고, 제 앱이 통제하는 화면으로 돌아오지 않습니다. 그리고 Apple의 정의는 “소셜 피드 또는 이와 유사한 발견 수단을 통한” 재배포를 기준으로 삼는데, 시스템 공유 시트는 거기에 해당하지 않습니다.4 이 논리는 App Store의 상당 부분에 그대로 적용됩니다. 내보내기는 게시가 아닙니다.
Watch Connectivity는 메시지처럼 보이지만 메시지가 아닙니다. Get Bananas와 Reps는 둘 다 WCSession을 쓰는데, 이는 같은 사람에게 페어링된 iPhone과 Apple Watch 사이에서 데이터를 옮깁니다. 반면 Apple의 메시지 및 채팅 표시는 “사용자가 서로 직접 소통할 수 있을 것”을 요구합니다.413 여기서는 양쪽 끝에 같은 사용자 한 명이 앉아 있습니다.
아무것도 걸리지 않았다는 결과 자체가 일반화할 만하며, 바로 그 점이 가져다 쓸 만한 부분입니다. 이 집합의 모든 앱은 콘텐츠를 만든 사람을 위해 저장하고, 그 사람에게 다시 보여 줍니다. 설문이 묻는 것은 전혀 다른 질문입니다. 이 앱이 한 사람의 콘텐츠를 가져다가, 확산시키는 무언가를 통해 다른 사람들 앞에 놓느냐는 것입니다. 트래커, 타이머, 학습 도구는 정책 해석이 아니라 구조상 ‘아니오’로 답하게 됩니다. 고민해야 하는 쪽은 사용자들이 서로의 결과물을 볼 수 있는 화면이 하나라도 있는 앱입니다.
가장 먼저 확인해야 할 또 다른 숫자는 배포 대상 버전입니다. iOS 타깃이 있는 일곱 개 프로젝트 중 여섯은 iOS 26.0 이상이고, Ace Citizenship만 일부 타깃에서 여전히 17.0과 17.5를 선언하고 있습니다.13 26.0 미만이면 API를 아예 호출할 수 없고, 그러면 예외 조항도 사라져 평범한 신고만이 유일하게 정확한 답이 됩니다.
플랫폼 격차도 같은 조사에서 드러나는데, 버전 문제보다 더 넓게 퍼져 있습니다. 여덟 개 프로젝트 중 넷이 SUPPORTED_PLATFORMS에 xros xrsimulator를 선언합니다. Reps, Return, Water, Yawara입니다. Reps는 여기에 appletvos appletvsimulator를 더하고 별도의 watchos watchsimulator 타깃도 출시하며, Return과 Banana List도 watchOS 타깃을 갖고 있습니다.13 Declared Age Range는 iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0, macOS 26.0에 대한 availability만 게시하고 tvOS, visionOS, watchOS 항목은 없습니다.5 이 타깃들은 모두 9월 신고 의무를 지지만, 그중 어느 것에서든 ‘예’라고 답하는 순간 예외 조항은 손이 닿지 않는 곳으로 갑니다. 예외 조항이 기대는 API가 거기에는 제공되지 않기 때문입니다.
조사 방법에 관한 주의 사항 하나. 저도 첫 시도에서 이 부분을 틀렸습니다. XROS_DEPLOYMENT_TARGET은 visionOS 대상이 전혀 없는 프로젝트에도 나타납니다. Xcode가 그와 무관하게 이 설정을 구성에 써 넣기 때문입니다. ResumeGeni는 XROS_DEPLOYMENT_TARGET = 26.2를 갖고 있지만 iphoneos iphonesimulator만 빌드합니다.13 배포 대상 키가 아니라 SUPPORTED_PLATFORMS를 읽으세요. 그러지 않으면 앱이 출시하지도 않는 플랫폼까지 세게 됩니다.
답이 기술의 영역을 벗어나는 지점
Apple은 Declared Age Range 문서에 두 번 읽어 볼 만한 면책 문구를 붙여 두었습니다. 이 데이터는 “최종 사용자 또는 그 부모나 보호자가 선언한 정보에 기반”하며, “앱에 적용될 수 있는 관련 법률 또는 규정의 준수 책임은 전적으로 개발자에게 있습니다.”14
이 문장이 이 글이 멈춰 서는 선을 긋습니다. Apple의 설문은 등급과 Time Allowance 분류를 만들어 낼 뿐, 어떤 법규 준수도 보장하지 않습니다. 호주에서는 2025년 12월 10일부터 특정 소셜 미디어 플랫폼이 16세 미만의 계정 보유를 막도록 법으로 요구하고 있으며, 이 법에 관한 Apple의 안내는 Declared Age Range API를 다섯 가지 수단 중 하나로 언급합니다.15 설문과 법률은 겹치기는 하지만 맞아떨어지지는 않습니다. 한쪽은 13세를 묻고 다른 쪽은 16세를 묻는데, 둘 다 감당하기 위해 쓸 수 있는 기준 연령은 세 개뿐입니다.
특정 법률상 여러분의 앱이 소셜 미디어 플랫폼에 해당하는지는 그 관할 지역의 변호사에게 물을 질문입니다. Apple의 설문 기준으로 소셜 미디어 기능을 갖고 있는지는 여러분의 질문이며, Apple이 공개한 정의에 비추어 오늘 바로 답할 수 있습니다.
자주 묻는 질문
소셜 미디어 질문은 지금 App Store Connect에서 답할 수 있나요?
답할 수 있습니다. 2026년 7월 9일 Apple 발표는 설문에 “이제 앱의 소셜 미디어 기능에 관한 질문이 포함된다”고, 그리고 “오늘부터 이 질문들을 검토하고 답변할 수 있다”고 밝힙니다.3 App Store Connect API도 이를 독립적으로 확인해 주며, socialMedia와 socialMediaAgeRestricted를 AgeRatingDeclaration 리소스의 속성으로 기술하고 둘 다 PATCH /v1/ageRatingDeclarations/{id}로 수정할 수 있다고 명시합니다.1 지금 답한다고 해서 확정되는 것은 없습니다. 응답은 제출할 때 구속력을 갖고, 2026년 9월은 응답 없이 제출하는 것이 더 이상 통하지 않게 되는 시점입니다.2
Apple은 “소셜 미디어 기능”을 정의하고 있나요?
정의합니다. 네 군데에서, 서로 다른 두 가지 범위로 정의합니다. App Store Connect 도움말이 가장 완전한 판본을 제시하는데, “소셜 피드 또는 이와 유사한 발견 수단을 통해 사용자 제작 콘텐츠를 재배포, 증폭하거나 그와 상호작용하여 콘텐츠가 다수의 사용자에게 눈에 띄게 확산되는 경우”를 요구하고, 재게시, 좋아요, 댓글, 반응, 노출 확대를 예시로 나열합니다.4 6월 발표에는 같은 범위 한정 문구가 있지만, 7월 발표는 이를 뺐습니다.23 예시는 전부를 열거한 것이 아니라 말 그대로 예시일 뿐이므로 결국 자기 앱은 스스로 분류해야 하며, 저라면 도움말 페이지를 기준으로 분류하겠습니다.
제 앱에는 사용자 제작 콘텐츠가 있습니다. 그러면 자동으로 소셜 미디어인가요?
아닙니다. Apple은 이 둘을 별도의 질문으로, 각각 다른 정의와 다른 등급 결과를 갖도록 유지합니다. 사용자 제작 콘텐츠는 “앱이 의도한 사용자 경험의 구성 요소로서 사용자가 만든 콘텐츠를 광범위하게 배포하는 것”을 뜻하며 Apple의 4+ 정의에 등장합니다.4 소셜 미디어는 피드나 그에 준하는 발견 화면을 통한 재배포, 증폭, 상호작용을 요구하며 13+에서 처음 등장합니다.4 API도 이 구분을 그대로 반영해 userGeneratedContent와 socialMedia를 서로 독립적인 Boolean으로 둡니다.1 사용자가 만든 콘텐츠를 본인만 볼 수 있는 앱은 둘 중 어느 쪽도 아닙니다.
13세 미만 옵션을 택하면 실제로 무엇을 만들어야 하나요?
세 가지이고, 그중 API에 해당하는 것은 두 번째뿐입니다. App Store Connect 도움말은 13세 미만 사용자가 소셜 미디어 기능에 접근할 수 없어야 하고, “소셜 미디어 기능을 활성화하기 전에 사용자의 연령대를 확인하기 위해 최소한 Declared Age Range API를 호출”해야 하며, “연령에 적합한 UGC만 제공”되어야 한다고 요구합니다.4 따라서 com.apple.developer.declared-age-range entitlement를 추가하고, 소셜 관련 화면이 나타나기 전에 기준 연령에 13을 포함해 requestAgeRange를 호출하며, Apple이 정의해 두지 않은 거부 케이스까지 포함해 응답에 따라 분기하고, 그와 별개로 미성년자에게 전달하는 콘텐츠를 연령에 맞게 관리해야 합니다.56 API는 기준 연령을 세 개로 제한하고 사용자의 연령대를 선언 기념일까지 캐시하므로, 13세가 된 사용자는 설정을 갱신하기 전까지 계속 더 어린 것으로 읽힙니다.710
핵심 정리
iOS 개발자를 위한 정리
- 9월이 아니라 이번 주에 설문에 답하세요. 항목은 이미 열려 있고, 응답은 제출 시점에만 구속력을 가지며, 계산된 등급을 확인하면 두 발표문 어느 쪽도 깔끔하게 정리해 주지 않는 13+ 문제가 해결됩니다.34
- 13세 미만 예외 조항을 택한다면 API 호출 한 번이 아니라 세 가지 조건을 감안해 계획하고, 거부 분기를 의도를 갖고 작성하세요. .declinedSharing은 프라이버시를 중시하는 성인과 구별되지 않으며, Apple은 어느 쪽으로 처리해야 하는지에 대한 지침을 내놓지 않았습니다.49
tvOS, visionOS, watchOS를 다루는 팀을 위한 정리 - 계획을 세우기 전에 availability부터 확인하세요. Declared Age Range는 iOS, iPadOS, Mac Catalyst, macOS 항목만 게시하고 그 외에는 없으므로, 여러분의 플랫폼에서는 예외 조항의 문서화된 최소 요건을 충족할 수 없는데도 9월 신고 의무는 그대로 제출에 적용됩니다.25 - iOS 26.0 미만 타깃도 이유는 다르지만 같은 함정에 걸립니다. API가 없으니 예외 조항도 없고, 평범한 신고만이 유일하게 정확한 답이 됩니다.5
릴리스 담당자를 위한 정리
- 이번 주기의 다른 변경과 달리, 이번에는 날짜 자체가 방아쇠라고 생각하세요. 실행 화면 키와 @State 매크로는 여러분이 통제하는 SDK와 툴체인에서 발동하지만, 9월은 어차피 하고 있던 제출에서 발동합니다.2
- 이 답변은 제품 페이지를 관리하는 사람에게도 반드시 전달하세요. 소셜 미디어 기능이 있다고 신고하면 App Store 등록 정보에 소셜 미디어 콘텐츠 표시가 추가되는데, Apple은 이 결과를 7월에야 공개했습니다.3
27 주기는 계속해서 변화를 무엇이 발동시키는가로 분류하고 있습니다. 빌드 설정, 툴체인, 컴파일러 경고, 그리고 이제는 달력입니다. 같은 주기에서 강제력은 가장 약하면서도 뒤따르는 마이그레이션 부담은 가장 큰 지원 중단 사례가 궁금하다면 On Demand Resources와 Background Assets의 대가를 보세요. 시리즈 전체 허브는 Apple 생태계 시리즈입니다.
참고 자료
-
Apple, AgeRatingDeclaration.Attributes, App Store Connect API. “앱에 소셜 미디어 기능이 포함되어 있는지를 나타내는 Boolean 값”(
socialMedia), “앱의 소셜 미디어 기능이 연령 제한을 받는지를 나타내는 Boolean 값”(socialMediaAgeRestricted), “앱이 사용자의 나이를 확인하기 위해 연령 확인을 사용하는지를 나타내는 Boolean 값”(ageAssurance), 그리고 별개 속성인userGeneratedContent와messagingAndChat의 출처. 엔드포인트 경로, 쓰기 가능 여부, sparse fieldset 값은 Apple이 공개한 App Store Connect OpenAPI 명세 버전 4.4.1(2026년 7월 25일 다운로드, 아카이브 타임스탬프 2026년 7월 15일)과 대조해 확인했습니다.AgeRatingDeclaration은 속성 29개를 가지며,AgeRatingDeclarationUpdateRequest는socialMedia,socialMediaAgeRestricted,ageAssurance를 포함한 29개 전부를 null 허용 쓰기 가능 필드로 노출하고, 경로는GET /v1/appInfos/{id}/ageRatingDeclaration과PATCH /v1/ageRatingDeclarations/{id}입니다. ↩↩↩↩↩↩↩↩ -
Apple, Introducing Time Allowances, Apple Developer News, 2026년 6월 8일. 9월 요건(“2026년 9월부터 App Store에 새 버전이나 업데이트를 제출하거나 대체 앱 마켓플레이스 배포를 위한 공증을 받으려면, 앱 또는 게임에 소셜 미디어 기능이 포함되어 있는지 표시해야 합니다”), 플랫폼 목록(“iOS 27, iPadOS 27, macOS 27 이상의 새로운 Time Allowances”), 6월 정의(“여기에는 소셜 피드 또는 이와 유사한 발견 수단을 통해 사용자 제작 콘텐츠를 재배포, 증폭하거나 그와 상호작용하여 콘텐츠가 다수의 사용자에게 눈에 띄게 확산되도록 하는 기능이 포함됩니다”), 설문 변경 예고(“2026년 7월부터 연령 등급 설문이 업데이트되어 앱 또는 게임에 소셜 미디어 기능이 포함되어 있는지 표시할 수 있게 됩니다”), 평범한 신고에 적용되는 13+ 하한, 그리고 제한 옵션에 관한 문구(“사용자의 연령대를 확인하기 위해 최소한 Declared Age Range API를 사용해야 합니다”, “이 옵션을 선택하면 연령 등급 설문에 대한 전체 응답이 연령 등급을 결정하며 13+보다 낮은 등급이 나올 수도 있습니다”)의 출처. “Time Allowance 카테고리는 App Store에서 사용자 발견을 위한 카테고리와 다릅니다”라는 문장의 출처이기도 합니다. 2026년 7월 25일에 페이지 HTML과 대조해 원문 그대로 확인했습니다. ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩
-
Apple, Age rating questionnaire now includes social media questions, Apple Developer News, 2026년 7월 9일. 실제로 반영된 설문 변경(“App Store Connect의 연령 등급 설문에 이제 앱의 소셜 미디어 기능에 관한 질문이 포함됩니다”), 짧아진 정의(“소셜 미디어 기능이란 소셜 피드 또는 이와 유사한 발견 수단을 통해 사용자 제작 콘텐츠를 재배포, 증폭하거나 그와 상호작용하는 기능을 말합니다”), 제품 페이지에 미치는 영향(“이러한 기능을 갖춘 앱은 App Store 제품 페이지에 새로운 소셜 미디어 콘텐츠 표시가 노출됩니다”), 답변 가능 시점(“오늘부터 이 질문들을 검토하고 답변할 수 있습니다”), 그리고 다시 언급된 9월 적용 범위(“2026년 9월부터 App Store에 새 앱이나 업데이트를 제출할 때, 또는 대체 배포를 위해 앱을 공증에 제출할 때 응답이 필수가 됩니다”)의 출처. 2026년 7월 25일에 페이지 HTML과 대조해 원문 그대로 확인했습니다. 같은 날 Apple Developer News를 검색한 결과, Time Allowances, 연령 등급, 소셜 미디어 신고에 관해 이보다 나중에 올라온 항목은 없었습니다. ↩↩↩↩↩↩↩↩↩↩↩↩
-
Apple, Age ratings values and definitions, App Store Connect Help. 이 글에 인용된 기능(Capabilities) 정의, 즉 소셜 미디어, 13세 미만 사용자에 대해 비활성화된 소셜 미디어(“13세 미만 사용자는 소셜 미디어 기능에 접근할 수 없습니다. 소셜 미디어 기능을 활성화하기 전에 사용자의 연령대를 확인하기 위해 최소한 Declared Age Range API를 호출합니다. 연령에 적합한 UGC만 제공됩니다”), 사용자 제작 콘텐츠, 메시지 및 채팅과, 앱 내 제어(In-App Controls)의 연령 확인(Age Assurance) 정의의 출처. 등급 표의 출처이기도 하며, 이 표들은 모두 최소 iOS 26, iPadOS 26, macOS Tahoe 26, tvOS 26, visionOS 26, watchOS 26을 실행하는 기기에 적용됩니다. “Age rating values” 항목 아래에서 Apple의 글로벌 표는 사용자 제작 콘텐츠, 메시지 및 채팅, 광고, 자녀 보호 기능, 연령 확인을 4+에 두고, 소셜 미디어와 13세 미만 사용자에 대해 비활성화된 소셜 미디어는 둘 다 기능 항목의 13+에 둡니다. 네 개의 지역별 표는 두 소셜 미디어 표시를 함께 “Australia age rating values”의 16+, “Brazil age rating values”의 A16, “Republic of Korea age rating values”의 15세 이용가, “Vietnam age rating values”의 16+에 배치합니다. 별도의 “Age ratings on OS versions earlier than 26” 항목에는 어떤 등급에도 소셜 미디어 표시가 없습니다. 2026년 7월 25일에 페이지 HTML에서 읽었습니다. ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩
-
Apple, Declared Age Range, 프레임워크 문서. Availability는 iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0, macOS 26.0이며 tvOS, visionOS, watchOS 항목은 없습니다. 프레임워크 개요(“Declared Age Range API를 사용해 사용자가 자신의 연령대를 앱과 공유하도록 요청하세요”)와, 부모·보호자 또는 가족 구성원 관리자가 “자녀의 연령 정보를 앱과 항상 공유하거나, 매번 자녀에게 묻거나, 전혀 공유하지 않도록” 설정할 수 있는 가족 공유 동작의 출처. SwiftUI 환경 액션은 DeclaredAgeRangeAction에 문서화되어 있고, 이 글의 코드 예제에 쓰인
@Environment(\.requestAgeRange)사용법은 AgeRangeService 예제에 있는 Apple 자체 코드입니다. HTML이 JavaScript로 렌더링되므로, availability는 2026년 7월 25일에 Apple 문서의 JSON에서 읽었습니다. ↩↩↩↩↩↩↩↩ -
Apple, com.apple.developer.declared-age-range, Entitlements 레퍼런스. “앱이 사용자의 연령대를 요청할 수 있는지를 나타내는 Boolean 값.” Availability는 iOS 26.0, iPadOS 26.0, macOS 26.0입니다. Apple의 안내는 “Xcode에서 타깃에 Declared Age Range capability를 켜서” 추가하라는 것입니다. 프레임워크 문서에는 Mac Catalyst 항목이 있는 반면 entitlement 페이지에는 없다는 점에 유의하세요. 이 불일치는 Apple의 메타데이터 쪽에 있으며, 어느 쪽이 맞는지는 직접 검증하지 않았습니다. ↩↩
-
Apple,
DeclaredAgeRangeAction의 callAsFunction(ageGates:::)와AgeRangeService의 requestAgeRange(ageGates:::in:), Declared Age Range. SwiftUI 액션은func callAsFunction(ageGates threshold1: Int, _ threshold2: Int? = nil, _ threshold3: Int? = nil) async throws -> AgeRangeService.Response로 선언되고, UIKit 메서드는 같은 기준값 세 개에in viewController: UIViewController를 더해 선언됩니다. 기준값 세 개가 양쪽 모두의 한계입니다. UIKit 페이지는 지역 규정에 따른 재정의의 출처이기도 합니다. “시스템은 사용자의 위치와 적용 법규에 따라 개발자가 지정한 기준 연령을 무시하는 연령대를 반환할 수 있습니다. 현지 법규가 특정 기준 연령을 요구하는 경우, 반환되는 연령대는 개발자가 지정한 기준의 범위가 아니라 규제 요건을 반영합니다.” 이 액션은 iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0, macOS 26.0에서 사용할 수 있고,in viewController:오버로드는 iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0을 표기하며 macOS는NSWindow변형이 담당합니다. ↩↩↩ -
Apple, AgeRangeService.AgeRange와 lowerBound, Declared Age Range. 프라이버시 관점의 설명(“정확한 나이를 받는 대신, 지정한 기준 연령에 대응하는 연령대 범위를 받습니다”), 속성 선언
var lowerBound: Int?와var upperBound: Int?(둘 다 iOS 26.0 도입), 그리고 이 글에 인용된 nil 의미의 출처입니다. “이 값이nil이면 해당 사용자의 연령대가 지정한 가장 낮은 연령보다 아래라는 뜻이며, 개발자가 요구하는 최소 연령에 미치지 못함을 나타냅니다. 값이 존재하면, 해당 사용자가 충족하거나 넘어선 가장 낮은 연령을 나타냅니다.” 같은 페이지에 있는 Apple의 예시는 이렇습니다. 기준 연령을 13, 16, 18로 두었을 때lowerBound가 16이면 그 사용자는 최소 16세이지만 “18이상일 수도, 아닐 수도 있습니다.” 이 구조체는ageRangeDeclaration과activeParentalControls도 노출합니다. ↩ -
Apple, AgeRangeService.Response, Declared Age Range. case는 둘입니다. “해당 사용자가 공유한 연령대 정보를 담는”
sharing(range:)와, “해당 사용자가 앱과 연령대를 공유하기를 거부했음을 나타내는”declinedSharing입니다. 사용자가 거부했을 때 앱이 어느 쪽을 기본값으로 삼아야 하는지에 대해 Apple은 어떤 지침도 내놓지 않았습니다. 닫히는 쪽으로 처리하고 그 동작을 화면에 밝히라는 권고는 필자의 견해입니다. ↩↩ -
Apple, Requesting people’s age range information in your app, Declared Age Range. 캐시 동작(“시스템은 프라이버시 보호를 위해 연령대 응답을 캐시합니다. 사용자의 나이가 새로운 연령대로 넘어가더라도(예: 만 13세가 되는 경우) API는 최초 선언 시점의 기념일이 될 때까지 이전 연령대를 계속 반환합니다”), 설정을 통한 해결 경로(iPhone·iPad의 설정 또는 Mac의 시스템 설정 → 본인 이름 → 개인 정보 → 앱용 연령대), “시스템이 자동으로 해당 사용자의 연령대를 제공”하고 사용자가 “공유를 거부할 수 없는” 규제 지역 동작, 그리고 규제 대상이 아닌 지역의 동작(“사용자가 거부하면
declinedSharing응답을 받습니다”)의 출처입니다. ↩↩↩↩ -
Apple, isEligibleForAgeFeatures, Declared Age Range.
var isEligibleForAgeFeatures: Bool { get async throws }이며 iOS 26.2, iPadOS 26.2, Mac Catalyst 26.2, macOS 26.2부터 사용할 수 있습니다. 다음 문장의 출처입니다. “macOS에서는 시스템이 해당 사용자나 기기에 대해 연령 확인을 요구하지 않으므로isEligibleForAgeFeatures가false를 반환합니다. 다만 macOS에서도requestAgeRange를 호출해 선언된 연령대를 받을 수는 있습니다.” ↩ -
Apple, AgeRangeService.AgeRangeDeclaration, Declared Age Range. 현재 case는
selfDeclared와guardianDeclared(iOS 26.0), 그리고confirmed(iOS 26.5)이며, 마지막 항목은 “사용자의 연령대가 신용카드나 정부 발급 신분증처럼 엄밀한 방식으로 설정되었음을 나타낸다”고 설명됩니다. Apple 문서는 나머지 여섯 개 case를 Deprecated 항목 아래에 묶어 두었습니다.paymentChecked,governmentIDChecked,checkedByOtherMethod와 이에 대응하는 보호자용 세 가지이며, 모두 iOS 26.2에 도입되었습니다. Availability는 2026년 7월 25일에 Apple 문서의 JSON에서 읽었습니다. 개별 case 페이지의 플랫폼 메타데이터에는deprecatedAt버전이 없으므로, 지원 중단은 availability 주석이 아니라 문서 자체의 분류로 표시된 것입니다. ↩ -
2026년 7월 25일 macOS 26.5.2 및 Xcode 26.6(빌드 17F113) 환경에서 필자가 Xcode 프로젝트 여덟 개를 조사한 결과. 프로젝트 디렉터리는
~/Projects아래에 있으며, 둘은 혼동하기 쉬워 정확히 이름을 밝힙니다.Banana List(Get Bananas라는 이름으로 출시),Reps,Return,Ace-Citizenship,Water,Yawara,Cels, 그리고ResumeGeniApp입니다. 마지막 항목은 SwiftUI iOS 앱이며, 그 옆에 있는 파일 네 개짜리 별개 프로젝트인ResumeGeniSafari 웹 확장 프로그램과는 다릅니다.build,DerivedData,.build,Pods,.git,worktrees를 제외한 Swift 파일 수는 순서대로 55, 77, 57, 26, 34, 143, 29, 70개로 총 491개입니다. 모든 Swift 파일, entitlements 파일, 프로퍼티 목록에서CKShare,UICloudSharingController,CKAllowedSharingOptions,sharedCloudDatabase,publicCloudDatabase,GKLeaderboard,GKLocalPlayer,GKMatch,MFMessageComposeViewController,MSMessagesAppViewController,DeclaredAgeRange,AgeRangeService,requestAgeRange,declared-age-range를 검색했습니다. 모든 프로젝트에서 모든 패턴이 0건입니다.UIActivityViewController는 Get Bananas, Water, ResumeGeni의 iOS 앱에 나타나고,WCSession은 Get Bananas와 Reps에,ASAuthorizationAppleID는 ResumeGeni의 iOS 앱에만 나타납니다. Get Bananas는FileManager.default.url(forUbiquityContainerIdentifier:)로 접근하는 iCloud ubiquity 컨테이너에 목록을 JSON으로 저장하며, entitlements에서com.apple.developer.icloud-services가CloudDocuments로 설정되어 있고 프로젝트 어디에도 CloudKit 공유는 없습니다. 배포 대상 버전은 각project.pbxproj에서 읽었습니다. 일곱 개 프로젝트가IPHONEOS_DEPLOYMENT_TARGET을 선언하며(Get Bananas 26.0, Reps 26.0과 26.2, Return 26.1, Water 26.0, Yawara 26.5, ResumeGeni의 iOS 앱 26.2, Ace Citizenship은 타깃별로 17.0, 17.5, 26.1), Cels는MACOSX_DEPLOYMENT_TARGET = 26.0만 선언하고 iOS 타깃은 출시하지 않습니다. 플랫폼 값은 배포 대상 키가 아니라 각 프로젝트의SUPPORTED_PLATFORMS빌드 설정에서 읽었습니다. 여덟 개 모두 Blake가 App Store에 출시 중인 프로젝트입니다. ↩↩↩↩↩↩↩ -
Apple, Declared Age Range, 프레임워크 개요의 Important 안내문. “Declared Age Range API의 데이터는 최종 사용자 또는 그 부모나 보호자가 선언한 정보에 기반하며, 신용카드와 같은 결제 수단, 정부 발급 신분증 또는 그 밖의 방법으로 확인될 수 있습니다. 앱에 적용될 수 있는 관련 법률 또는 규정의 준수 책임은 전적으로 개발자에게 있습니다.” ↩
-
Apple, New Requirements for Social Media Apps in Australia, Apple Developer News, 2025년 12월 8일. 호주 요건(“2025년 12월 10일부터 호주에서 운영되는 특정 소셜 미디어 플랫폼은 16세 미만이 소셜 미디어 계정을 보유하지 못하도록 해야 한다는 새 호주 법이 시행됩니다”)과, 이에 대응해 Apple이 제시한 다섯 가지 수단, 즉 Declared Age Range API, App Store 앱 설명, 제품 페이지에 표시되는 앱 내 제어, 개발자가 직접 높게 설정한 최소 연령 등급, Age Suitability URL의 출처입니다. Apple은 “영향을 받는 개발자는 새 법의 요건을 준수할 책임이 있다”고 밝힙니다. 연령 확인 질문이 소셜 미디어 질문보다 먼저 도입되었음을 확인해 주는 근거이기도 합니다. “올해 Apple은 모든 앱에 필수인 연령 등급 설문을 업데이트했습니다. 이 업데이트에는 연령 확인과 자녀 보호 기능의 유무 등 앱 내 제어에 관한 새로운 질문이 추가되었습니다.” ↩↩
-
Apple, Apple previews new child safety features, Apple Newsroom, 2026년 6월 8일. Ask to Browse, Schedules, 새로 디자인된 Screen Time과 함께 제공되는 Time Allowances의 사용자 관점 설명의 출처입니다. “Time Allowances는 엔터테인먼트, 게임, 소셜 미디어를 포함한 여러 카테고리 전반에서 자녀가 앱에 쓰는 시간을 관리할 더 유연한 방법을 부모에게 제공합니다. Time Allowances를 설정할 때 부모는 전문가 연구에 기반해 자녀의 연령에 맞춘 안내를 받습니다.” ↩