Pole wyboru „media społecznościowe" w App Store i jego cena

Dwa pola typu Boolean w API App Store Connect dźwigają cały ciężar wymogu obowiązującego od września: socialMedia oraz socialMediaAgeRestricted.¹ To drugie kosztuje uprawnienie, wdrożenie API i osobną gałąź zachowania w aplikacji.

Apple ogłosiło ten wymóg 8 czerwca 2026 roku: „Starting September 2026, you’ll be required to indicate whether your app or game includes social media capabilities in order to submit new versions or updates to the App Store, or for notarization for distribution on alternative app marketplaces.”² 9 lipca Apple udostępniło zmieniony kwestionariusz i dodało jedno zdanie, które przesądza o tym, jak warto spożytkować tygodnie dzielące nas od terminu: „You can review and answer these questions starting today.”³

W skrócie

• Deklaracja jest już dostępna w App Store Connect, a obowiązkowa staje się we wrześniu 2026 roku — okres między dostępnością a przymusem można przeznaczyć na decyzję, a nie na wyścig z terminem.²³
• Apple faktycznie definiuje „social media capabilities”, i to w czterech miejscach, przy czym trzy z definicji się rozjeżdżają. Czerwcowa zawęża rzecz do kanałów, które „visibly spreads content to many users”; lipcowa pomija tę klauzulę w całości.²³⁴
• API App Store Connect udostępnia odpowiedź jako dwie zapisywalne wartości Boolean, a userGeneratedContent i messagingAndChat pozostają osobnymi pytaniami z osobnymi progami klasyfikacji wiekowej. Media społecznościowe to nowa oś, nie zmiana nazwy.¹⁴
• Uniknięcie kategorii „media społecznościowe” dla użytkowników poniżej 13 lat wymaga spełnienia trzech warunków, nie jednego. Wpis Apple w aktualnościach wymienia API Declared Age Range; pomoc App Store Connect dodaje, że użytkownicy poniżej 13 lat nie mają dostępu w ogóle oraz że „Only age-appropriate UGC is delivered.”²⁴
• API Declared Age Range działa na iOS, iPadOS, Mac Catalyst i macOS — i nigdzie indziej.⁵ Aplikacja na tvOS, visionOS czy watchOS mimo to odpowiada na pytanie we wrześniu, a udokumentowana droga do zakwalifikowania się do wyłączenia na jej platformie po prostu nie istnieje.

Jedyna zmiana w tym cyklu, którą uruchamia kalendarz

Każda inna przełomowa zmiana, którą opisywałem w tym cyklu, czeka, aż to my wykonamy pierwszy ruch. Wymóg dotyczący ekranu startowego uruchamia się przy kompilacji względem SDK iOS 27.0. Makro @State uruchamia się przy otwarciu projektu w Xcode 27. Wycofanie On Demand Resources wywołuje ostrzeżenie kompilatora, które można ignorować w nieskończoność. Wystarczy nie ruszać toolchainu, a żadna z nich nas nie dosięgnie.

Deklaracja o mediach społecznościowych dosięgnie i tak, ponieważ Apple przywiązało ją do miesiąca oraz do czynności, którą i tak wykonujemy. Jednolinijkowa poprawka błędu przechodzi przez tę samą ścieżkę zgłoszeniową co wydanie nowej funkcji, a we wrześniu ta ścieżka zadaje pytanie.

Zakres jest wąski i warto go przeczytać dokładnie. Wymóg obejmuje „new versions or updates to the App Store” oraz „notarization for distribution on alternative app marketplaces.”² Lipiec powtarza tę parę jako „new apps or updates to the App Store” i „apps for notarization for alternative distribution.”³ Żadne z ogłoszeń nie wspomina o wersji SDK, docelowej wersji systemu ani o platformie. Aplikacje już opublikowane sprzedają się dalej. Bramka stoi u progu następnego zgłoszenia.

Ceną odpowiedzi jest przypisanie do kategorii, którą rodzice mogą limitować. Time Allowances pojawia się tej jesieni obok Ask to Browse, Schedules i przeprojektowanego Screen Time, dając rodzicom „more flexible ways to manage the time their kids spend in apps across categories, including Entertainment, Games, and Social Media”, z wytycznymi dopasowanymi do wieku jako punktem wyjścia.¹⁶ Przypisanie do Entertainment i Games wynika z kategorii wybranej w App Store Connect. Przypisanie do Social Media wynika wyłącznie z odpowiedzi w kwestionariuszu, „regardless of the category selected in App Store Connect.”² Gra logiczna z kanałem społecznościowym trafia do kategorii, którą rodzic ogranicza w pierwszej kolejności — niezależnie od tego, co głosi strona produktu.

Apple definiuje ten termin, a definicje się rozjeżdżają

Typowa pułapka przy pytaniach o zasady polega na zgadywaniu znaczenia niezdefiniowanego słowa. Apple opublikowało definicję, co ogranicza pole domysłów — tyle że opublikowało ją czterokrotnie, za każdym razem z innymi granicami.

Czerwiec ujmuje rzecz szeroko: „This includes the ability to redistribute, amplify, or interact with user-generated content through a social feed or similar discovery method that visibly spreads content to many users.”²

Lipiec ujmuje ją definicyjnie i krócej: „A social media capability is defined as the ability to redistribute, amplify, or interact with user-generated content through a social feed or similar discovery method.”³ Zastrzeżenie o widocznym rozpowszechnianiu treści wśród wielu użytkowników zniknęło.

Pomoc App Store Connect zawiera wersję najdłuższą, zachowuje zastrzeżenie i dorzuca przykłady: „Redistribution, amplification, or interaction with user-generated content through a social feed or similar discovery method that visibly spreads content to many users. May include: users reposting, liking, commenting, reacting, or making user-generated content more visible through a social feed, community, search, or other sharing and discovery tools.”⁴

Trzy z czterech wersji wymagają szerokiego, widocznego rozpowszechniania. Jedna nie — a dla aplikacji balansującej na granicy właśnie ta różnica przesądza o odpowiedzi. Osobiście traktowałbym stronę pomocy jako rozstrzygającą, ponieważ to do niej odsyła kwestionariusz, a wpisy w aktualnościach się starzeją; taki odczyt to jednak mój wniosek, nie wskazówka Apple. „May include” też ma znaczenie: Apple podaje przykłady, zamiast domykać zbiór, więc funkcja niepodobna do żadnego z pięciu wymienionych czasowników wciąż może się kwalifikować.

Granicę wyostrza towarzystwo, w jakim ten deskryptor występuje. Apple definiuje User-Generated Content osobno, jako „the broad distribution of content created by users as a component of the app’s intended user experience”, a Messaging and Chat jeszcze osobno, jako sytuację, w której użytkownicy „can directly communicate with one another through features within the app.”⁴ API App Store Connect zachowuje ten podział co do joty, utrzymując userGeneratedContent, messagingAndChat i socialMedia jako trzy niezależne wartości Boolean.¹

Klasyfikacje wiekowe rozchodzą się równie wyraźnie. Treści tworzone przez użytkowników oraz wiadomości pojawiają się w definicji Apple dla kategorii 4+. Media społecznościowe pojawiają się dopiero przy 13+.⁴ Aplikacja może hostować treści użytkowników, pozwalać im pisać do siebie i wciąż mieć ocenę 4+; wystarczy dodać kanał, który wzmacnia te same treści wobec obcych osób, a próg podskakuje o dziewięć lat. Oba deskryptory dotyczące mediów społecznościowych istnieją wyłącznie w schemacie klasyfikacji dla systemów OS 26 i nowszych, a tabela Apple dla wcześniejszych wersji nie zawiera żadnej pozycji o mediach społecznościowych przy jakiejkolwiek ocenie.⁴

Na to pole można odpowiedzieć już dziś

Trzy materiały Apple potwierdzają, że zmiana w kwestionariuszu już weszła w życie — i to jest praktyczna puenta całego wpisu.

Ogłoszenie Apple z 9 lipca mówi, że kwestionariusz „now includes questions about your app’s social media capabilities”, i zachęca do natychmiastowej odpowiedzi.³ API App Store Connect dokumentuje socialMedia jako „A Boolean value that indicates whether the app includes social media features”, a socialMediaAgeRestricted jako „A Boolean value that indicates whether the app’s social media features are age restricted.”¹ Opublikowana przez Apple specyfikacja OpenAPI zawiera oba pola jako zapisywalne wartości Boolean dopuszczające null.¹ Sąsiadują one z ageAssurance, dodanym przy wcześniejszej przebudowie kwestionariusza, którego definicja wymienia „declared age range API” jako mechanizm kwalifikujący.⁴¹⁵ Przyjęcie wyłączenia lokuje więc aplikację również wewnątrz tamtej definicji, co w moim odczycie oznacza drugie pytanie do ponownego przemyślenia, a nie do zostawienia w spokoju.

Każdy, kto automatyzuje zgłoszenia, powinien poznać ten kształt już teraz: deklarację odczytuje się przez GET /v1/appInfos/{id}/ageRatingDeclaration, zapisuje przez PATCH /v1/ageRatingDeclarations/{id}, a obie wartości Boolean można przekazać do parametru fields[ageRatingDeclarations].¹ Potok, który buduje ładunki klasyfikacji wiekowej ręcznie, działa bez zarzutu aż do dnia, w którym przestaje.

Jedna konsekwencja wypłynęła dopiero w lipcu: „Apps with these capabilities will display a new Social Media content descriptor on their App Store product page.”³ Odpowiedź twierdząca zmienia wpis w sklepie, nie tylko przypisanie do kategorii kontroli rodzicielskiej.

Warto więc otworzyć kwestionariusz w tym tygodniu i odczytać ocenę wyliczoną przez App Store Connect. Nie zobowiązuje to do niczego aż do momentu zgłoszenia, a termin zamienia w decyzję już podjętą.

Wyłączenie ma trzy warunki, nie jeden

Wpis Apple w aktualnościach sprawia wrażenie, jakby ścieżka dla dzieci poniżej 13 lat sprowadzała się do jednego wywołania API: „If you indicate that your app or game includes social media capabilities but they are disabled for anyone under 13, it won’t be included in the Time Allowance category for Social Media for users under 13… You’ll also need to use the Declared Age Range API (at a minimum) to check users’ age ranges.”²

Pomoc App Store Connect przedstawia ten sam deskryptor jako trzy wymagania: „Users under 13 don’t have access to social media capabilities. At a minimum, the Declared Age Range API is called to check users’ age ranges before enabling social media features. Only age-appropriate UGC is delivered.”⁴

Trzeciego zdania nikt nie cytuje. „Only age-appropriate UGC is delivered” to obowiązek moderacyjny bez przypisanego API, bez opublikowanego progu i bez testu, który dałoby się przeprowadzić. Apple nie definiuje ani „odpowiedniego do wieku”, ani mechanizmu dostarczania. Zespół, który wdroży bramkę wiekową i pokaże dwunastolatkowi ten sam niefiltrowany kanał, spełnił — wedle samego tekstu strony pomocy — jeden warunek z trzech.

Warto też odnotować, czego wyłączenie nie kupuje. Zdanie Apple ciągnie się dalej: taka aplikacja „will remain in the Social Media category for users 13 and above.”² Zwolnienie obejmuje wyłącznie użytkowników poniżej 13 lat, więc czternastolatka nadal dotyczy limit, który rodzic nałożył na media społecznościowe.

Tabele klasyfikacji kryją sprzeczność, której nie udało mi się rozstrzygnąć. Wpis Apple w aktualnościach mówi, że przy opcji z ograniczeniem o ocenie decydują „overall responses in the age rating questionnaire”, co „may result in a rating lower than 13+.”² A jednak globalna tabela Apple umieszcza zarówno „Social media”, jak i „Social media disabled for users under 13” w sekcji Capabilities przy 13+, a tabele regionalne stawiają je razem przy 16+ w Australii, A16 w Brazylii, 15+ w Korei i 16+ w Wietnamie.⁴ Czytane tak jak każdy inny wiersz — gdzie deskryptor wyznacza próg — opcja z ograniczeniem również wygląda na próg 13+. Apple niczego nie uzgadnia, a ja nie zamierzam zgadywać, który dokument implementuje kalkulator. Warto wybrać tę opcję w działającym kwestionariuszu, odczytać wyliczoną ocenę i zaufać kalkulatorowi bardziej niż obu dokumentom.

Za polem wyboru, w głąb aplikacji

Załóżmy, że sięgamy po wyłączenie. Włącza się wtedy funkcję Declared Age Range dla targetu w Xcode, co dodaje uprawnienie com.apple.developer.declared-age-range: „A Boolean value indicating whether your app may request a person’s age range.”⁶ Następnie wywołuje się API z interesującymi nas progami, co w SwiftUI przybiera postać akcji środowiskowej:⁵

Apple wiąże z tą akcją regułę umiejscowienia: należy jej używać „in response to user interactions”, a własny przykład Apple umieszcza wywołanie za przyciskiem.⁵ Żądanie może wyświetlić systemowy arkusz, więc odpalenie go z .task albo onAppear rzuca prośbę o zgodę w twarz komuś, kto o nic jeszcze nie prosił. Lepiej podpiąć je pod dotknięcie, które prowadzi na bramkowaną powierzchnię.

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
    }
}

O tym, czy bramka wytrzyma, przesądzają cztery szczegóły tego listingu.

Progów dostaje się najwyżej trzy. Obie wersje metody kończą się na trzech progach: akcja SwiftUI to callAsFunction(ageGates threshold1: Int, _ threshold2: Int? = nil, _ threshold3: Int? = nil), a metoda UIKit dokłada wyłącznie kotwicę prezentacji.⁷ Cztery przedziały to sufit. Wystarczy, że reguła Apple wymaga progu 13, a prawo australijskie 16 — i trzy z czterech przedziałów są zużyte, zanim cokolwiek zostanie zaprojektowane.

Wartość nil dolnej granicy to odpowiedź, a nie błąd. AgeRange.lowerBound i upperBound są oba typu Int?, a Apple stawia sprawę jasno: „When this value is nil, the person’s age range is below your lowest specified age, indicating they are under your minimum age requirement.”⁸ Kod, który optymistycznie rozpakowuje tę wartość, odwraca działanie bramki dokładnie wobec tej grupy, dla której ochrony powstała.

Odmowa to realna gałąź, a Apple nie mówi, co z nią zrobić. AgeRangeService.Response niesie .sharing(range:) oraz .declinedSharing.⁹ W niektórych regulowanych regionach „the system automatically provides the person’s age range”, a ludzie „can’t decline sharing”; w regionach nieregulowanych „If the person declines, you receive a declinedSharing response.”¹⁰ Odmowy nie da się odróżnić od decyzji dorosłego, który ceni prywatność: potraktowanie jej jako „poniżej 13 lat” blokuje dorosłych, a potraktowanie jako „dorosły” otwiera bramkę, którą obiecaliśmy zamknąć. Apple zostawia wybór domyślnego zachowania deweloperowi. Ja domykałbym bramkę i mówił o tym wprost w interfejsie.

Zadeklarowane progi mają charakter doradczy. System „może zwracać przedziały wiekowe nadpisujące progi wiekowe zadeklarowane w aplikacji, na podstawie lokalizacji danej osoby i obowiązujących przepisów”, a gdy lokalne przepisy wymagają określonych progów wiekowych, „zwrócony przedział wiekowy odzwierciedla wymogi regulacyjne, a nie granice progów zadeklarowanych w aplikacji.”⁷ Kod zakładający, że zwrócone granice odpowiadają żądaniu, zawiedzie najpierw w najsurowszych jurysdykcjach.

Do projektu należy dopisać jeszcze jedno zachowanie, po którym spodziewam się zgłoszeń do wsparcia. Apple buforuje odpowiedź: „When a person’s age crosses into a new range (for example, when they turn 13), the API continues returning the previous range until the anniversary of their original declaration.”¹⁰ Dziecko, które kończy 13 lat w poniedziałek, przez wiele miesięcy może być odczytywane jako młodsze. Lekarstwem jest ścieżka w Ustawieniach, którą użytkownik przechodzi samodzielnie: pod swoim imieniem, dalej Dane osobowe, dalej Przedział wiekowy dla aplikacji.¹⁰ Każda aplikacja bramkująca na 13 latach potrzebuje tej instrukcji we własnym UI, bo inaczej nikt jej nie znajdzie.

Dwa drobniejsze szczegóły mają znaczenie na etapie projektowania. isEligibleForAgeFeatures informuje, czy dana osoba znajduje się w regionie wymagającym potwierdzania wieku, a na macOS „returns false because the system doesn’t require Age Assurance for the person or device”, więc aplikacja na Maca wywołuje requestAgeRange bezpośrednio.¹¹ Z kolei AgeRangeDeclaration, które informuje o sposobie ustalenia wieku, zdążyło już się zmienić: sześć szczegółowych przypadków w 26.2, nazywających płatność, dokument tożsamości i inne metody dla osoby oraz opiekuna, zwinięto w 26.5 do jednego przypadku confirmed.¹² Na pytanie, która metoda zweryfikowała użytkownika, obecne API już nie odpowiada.

Zostaje jeszcze próg platformowy, o którym mówią metadane dostępności, a milczy każde źródło pisane prozą. Declared Age Range publikuje iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0 i macOS 26.0 — i nic więcej: brak wiersza tvOS, brak visionOS, brak watchOS.⁵ Time Allowances trafia do tych samych rodzin systemów, „iOS 27, iPadOS 27, and macOS 27, or later”, podczas gdy wymóg deklaracji nie zawiera żadnego zastrzeżenia platformowego.²³ Aplikacja na tvOS lub visionOS z kanałem społecznościowym odpowiada więc we wrześniu i nie jest w stanie spełnić udokumentowanego minimum wyłączenia, bo wskazane w nim API tam nie istnieje. Odczytanie tej rozbieżności jako luki, a nie celowego zwolnienia, to mój wniosek; Apple nie opublikowało niczego w żadną stronę.

Co deklaruje osiem moich własnych aplikacji

Przegląd przeprowadziłem, zanim zabrałem się za pisanie o cudzym kodzie: osiem projektów Xcode, 491 plików Swift.¹³ Żaden nie zawiera CKShare, UICloudSharingController, współdzielonej ani publicznej bazy CloudKit, GameKit czy jakiegokolwiek symbolu Declared Age Range. Żadna aplikacja z tego zestawu w ogóle nie przenosi treści od jednej osoby do drugiej. Cztery projekty nie mają ani jednej oflagowanej powierzchni. Pozostałe cztery mają powierzchnie, nad którymi ostrożna osoba mogłaby się zawahać — a występują w trzech odmianach wartych przemyślenia na głos.

Get Bananas ma współdzieloną listę zakupów, a „współdzielona” znaczy tu mniej, niż brzmi. Aplikacja zapisuje dokument JSON do kontenera ubiquity iCloud i odczytuje go na iPhonie, Apple Watch oraz Macu, przy com.apple.developer.icloud-services ustawionym na CloudDocuments i bez śladu współdzielenia CloudKit w projekcie.¹³ Lista jest współdzielona między urządzeniami jednej osoby, nie między ludźmi, więc nic się nie redystrybuuje i nie ma drugiego użytkownika, do którego cokolwiek mogłoby się rozejść. Odpowiedź zmieni się w dniu, w którym dodam CKShare na potrzeby współpracy domowników — i nawet wtedy zmieni się na treści tworzone przez użytkowników, a nie na media społecznościowe, bo dwuosobowa lista zakupów nie ma ani kanału, ani powierzchni odkrywania. Linia warta obserwacji leży dalej: współdzielone listy plus publiczna galeria szablonów plus polubienia to już kanał społecznościowy, tyle że okrężną drogą.

Trzy aplikacje pokazują arkusz udostępniania, a arkusz udostępniania nie jest funkcją społecznościową. Get Bananas, Water oraz aplikacja ResumeGeni na iOS opakowują UIActivityViewController, by przekazać własne treści użytkownika do dowolnej wybranej przez niego aplikacji.¹³ Treść odchodzi do Wiadomości albo Maila i nigdy nie wraca na powierzchnię kontrolowaną przez moją aplikację, a definicja Apple opiera się na redystrybucji „through a social feed or similar discovery method” — czym systemowy arkusz udostępniania nie jest.⁴ To rozumowanie obejmuje sporą część App Store: eksportowanie to nie publikowanie.

Watch Connectivity wygląda jak wiadomości, a nią nie jest. Get Bananas i Reps korzystają z WCSession, które przenosi dane między telefonem a zegarkiem sparowanym z tą samą osobą, podczas gdy deskryptor Messaging and Chat wymaga, by „Users can directly communicate with one another.”⁴¹³ Po obu stronach siedzi jeden użytkownik.

Wynik negatywny daje się uogólnić — i to jest część warta zapożyczenia. Każda aplikacja z tego zestawu przechowuje treść dla osoby, która ją stworzyła, i pokazuje ją z powrotem tej samej osobie. Kwestionariusz pyta o coś zupełnie innego: czy aplikacja bierze treść jednej osoby i stawia ją przed innymi za pośrednictwem czegoś, co ją rozpowszechnia. Trackery, minutniki i narzędzia do nauki odpowiadają „nie” z racji architektury, a nie z lektury zasad. Zastanawiać muszą się te aplikacje, które mają jakąkolwiek powierzchnię, gdzie użytkownicy widzą nawzajem swoją pracę.

Drugą liczbą, którą warto sprawdzić w pierwszej kolejności, są docelowe wersje systemu. Sześć z siedmiu projektów z targetem iOS ma iOS 26.0 lub nowszy; Ace Citizenship wciąż deklaruje 17.0 i 17.5 na części targetów.¹³ Cokolwiek poniżej 26.0 nie może w ogóle wywołać API, co usuwa wyłączenie z gry i zostawia zwykłą deklarację jako jedyną zgodną z prawdą odpowiedź.

Luka platformowa ujawnia się w tym samym przeglądzie, i to szerzej niż luka wersji. Cztery z ośmiu projektów deklarują xros xrsimulator w SUPPORTED_PLATFORMS: Reps, Return, Water i Yawara. Reps dokłada appletvos appletvsimulator i wypuszcza osobny target watchos watchsimulator; Return i Banana List mają również targety watchOS.¹³ Declared Age Range publikuje dostępność dla iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0 i macOS 26.0, bez wiersza dla tvOS, visionOS czy watchOS.⁵ Każdy z tych targetów podlega wrześniowej deklaracji, a na którymkolwiek z nich odpowiedź twierdząca stawia wyłączenie poza zasięgiem, bo API, na którym się ono opiera, tam nie występuje.

Uwaga metodologiczna, skoro sam pomyliłem się przy pierwszym podejściu. XROS_DEPLOYMENT_TARGET pojawia się w projektach, które w ogóle nie mają docelowej platformy visionOS, ponieważ Xcode wpisuje to ustawienie do konfiguracji niezależnie od wszystkiego. ResumeGeni ma XROS_DEPLOYMENT_TARGET = 26.2 i buduje wyłącznie iphoneos iphonesimulator.¹³ Czytać należy SUPPORTED_PLATFORMS, a nie klucze docelowych wersji systemu — inaczej naliczy się platformy, na które aplikacja wcale nie trafia.

Gdzie odpowiedź przestaje być kwestią techniczną

Apple dołącza do dokumentacji Declared Age Range zastrzeżenie warte dwukrotnej lektury: dane „is based on information declared by an end user, or their parent or guardian”, a „You are solely responsible for ensuring compliance with associated laws or regulations that may apply to your app.”¹⁴

To zdanie wyznacza granicę, na której ten wpis się zatrzymuje. Kwestionariusz Apple produkuje ocenę wiekową i przypisanie do kategorii Time Allowance, a zgodności z jakimikolwiek przepisami nie zapewnia. Prawo australijskie wymaga od określonych platform społecznościowych uniemożliwienia osobom poniżej 16 lat posiadania konta od 10 grudnia 2025 roku, a wytyczne Apple dotyczące tej ustawy wymieniają API Declared Age Range jako jedno z pięciu narzędzi.¹⁵ Kwestionariusz i ustawa zachodzą na siebie, nie pokrywając się: jeden pyta o 13 lat, druga o 16, a do obsłużenia obu zostają trzy progi.

To, czy dana aplikacja jest platformą mediów społecznościowych w rozumieniu konkretnego prawa, to pytanie do prawnika w danej jurysdykcji. To, czy ma funkcje społecznościowe w rozumieniu kwestionariusza Apple, pozostaje pytaniem do jej twórcy — i można na nie odpowiedzieć już dziś, w oparciu o opublikowaną definicję Apple.

FAQ

Czy pytanie o media społecznościowe jest już aktywne w App Store Connect?

Tak. Ogłoszenie Apple z 9 lipca 2026 roku stwierdza, że kwestionariusz „now includes questions about your app’s social media capabilities” oraz że „You can review and answer these questions starting today.”³ API App Store Connect potwierdza to niezależnie, dokumentując socialMedia i socialMediaAgeRestricted jako atrybuty zasobu AgeRatingDeclaration, oba zapisywalne przez PATCH /v1/ageRatingDeclarations/{id}.¹ Odpowiedź udzielona teraz do niczego nie zobowiązuje: odpowiedzi wiążą w momencie zgłoszenia, a wrzesień 2026 roku to moment, w którym zgłaszanie bez nich przestaje działać.²

Czy Apple definiuje „social media capabilities”?

Tak, w czterech miejscach i w dwóch różnych zakresach. Pomoc App Store Connect podaje wersję najpełniejszą, wymagającą „Redistribution, amplification, or interaction with user-generated content through a social feed or similar discovery method that visibly spreads content to many users”, po czym wymienia jako przykłady repostowanie, polubienia, komentowanie, reagowanie i podbijanie widoczności.⁴ Czerwiec zawiera tę samą klauzulę zakresową; lipiec ją pomija.²³ Ponieważ przykłady mają charakter ilustracyjny, a nie wyczerpujący, klasyfikacja własnej aplikacji nadal spoczywa na deweloperze — ja klasyfikowałbym ją względem strony pomocy.

Moja aplikacja ma treści tworzone przez użytkowników. Czy to automatycznie media społecznościowe?

Nie. Apple traktuje je jako osobne pytania, z osobnymi definicjami i osobnymi konsekwencjami dla klasyfikacji wiekowej. User-Generated Content obejmuje „the broad distribution of content created by users as a component of the app’s intended user experience” i pojawia się w definicji Apple dla 4+.⁴ Media społecznościowe wymagają redystrybucji, wzmacniania lub interakcji poprzez kanał albo porównywalną powierzchnię odkrywania i pojawiają się dopiero przy 13+.⁴ API odzwierciedla ten podział niezależnymi wartościami Boolean userGeneratedContent i socialMedia.¹ Aplikacja, w której ludzie tworzą treści widoczne wyłącznie dla nich samych, nie jest ani jednym, ani drugim.

Co tak naprawdę trzeba zbudować, żeby skorzystać z opcji dla dzieci poniżej 13 lat?

Trzy rzeczy, z czego tylko druga to API. Pomoc App Store Connect wymaga, by użytkownicy poniżej 13 lat nie mieli dostępu do funkcji społecznościowych, by „At a minimum, the Declared Age Range API is called to check users’ age ranges before enabling social media features” oraz by „Only age-appropriate UGC is delivered.”⁴ Dodaje się zatem uprawnienie com.apple.developer.declared-age-range, wywołuje requestAgeRange z progiem 13 wśród pozostałych, zanim pojawi się jakakolwiek powierzchnia społecznościowa, rozgałęzia logikę na odpowiedzi — łącznie z przypadkiem odmowy, którego Apple nie definiuje — i osobno dba o to, by treści dostarczane nieletnim były odpowiednie do wieku.⁵⁶ API ogranicza liczbę progów do trzech i buforuje przedział wiekowy osoby aż do rocznicy jej deklaracji, więc użytkownik, który kończy 13 lat, wciąż jest odczytywany jako młodszy, dopóki nie zaktualizuje Ustawień.⁷¹⁰

Najważniejsze wnioski

Dla programistów iOS: - Warto wypełnić kwestionariusz w tym tygodniu, a nie we wrześniu. Pole jest aktywne, odpowiedzi wiążą dopiero przy zgłoszeniu, a odczytanie wyliczonej oceny rozstrzyga kwestię 13+, której żadne z ogłoszeń nie domyka jednoznacznie.³⁴ - Sięgając po wyłączenie dla dzieci poniżej 13 lat, należy zaplanować trzy warunki, a nie jedno wywołanie API, i świadomie napisać gałąź odmowy. .declinedSharing wygląda identycznie jak dorosły dbający o prywatność, a Apple nie publikuje żadnej wskazówki, w którą stronę zawodzić.⁴⁹

Dla zespołów pracujących na tvOS, visionOS lub watchOS: - Dostępność warto sprawdzić przed planowaniem. Declared Age Range publikuje wiersze dla iOS, iPadOS, Mac Catalyst i macOS, i nic poza tym, więc udokumentowane minimum wyłączenia jest na tych platformach niedostępne, podczas gdy wrześniowa deklaracja i tak obejmuje każde zgłoszenie.²⁵ - Ta sama luka dopada każdy target poniżej iOS 26.0, choć z innego powodu: brak API, brak wyłączenia, a zwykła deklaracja jako jedyna zgodna z prawdą odpowiedź.⁵

Dla osób odpowiedzialnych za wydania: - Wyzwalaczem jest tu data — inaczej niż w reszcie tego cyklu. Klucz ekranu startowego i makro @State odpalają się na ustawieniu kompilacji i toolchainie, które sami kontrolujemy; wrzesień odpala się na zgłoszeniu, które i tak wykonujemy.² - Odpowiedź warto skierować do osoby odpowiedzialnej za stronę produktu. Zadeklarowanie funkcji społecznościowych dodaje deskryptor treści Social Media do wpisu w App Store — konsekwencję, którą Apple ujawniło dopiero w lipcu.³

Cykl 27 wciąż porządkuje swoje zmiany według tego, co je uruchamia: ustawienie kompilacji, toolchain, ostrzeżenie kompilatora, a teraz kalendarz. O wycofaniu z tego samego cyklu, które ma najsłabsze zęby i najobszerniejszą migrację za sobą, piszę w tekście On Demand Resources i cena Background Assets. Centrum całej serii to Seria o ekosystemie Apple.

Bibliografia