Guideline 2.5.1: publiczne API i aktualny SDK w Expo

Guideline 2.5.1 stawia cztery wymagania: używaj tylko publicznych API, działaj na aktualnej wersji iOS, porzuć to, co Apple oznacza jako przestarzałe, i używaj każdego frameworka zgodnie z jego przeznaczeniem. W Expo ryzyko rzadko bierze się z twojego kodu JavaScript. Bierze się z modułów natywnych, które instalujesz, i z SDK, z którym kompilujesz.

Publikuję Solys, TradaZen i Nolera z Expo SDK 57. Solys korzysta z API Screen Time od Apple, czyli frameworka o ściśle określonym przeznaczeniu. Ten poradnik dotyczy reguły z procesu review. Jeśli dostałeś błąd przy wysyłaniu builda, przeczytaj poradnik o ITMS-90338. Tryby działania w tle, opisane w tej samej sekcji, omawia poradnik o guideline 2.5.4.

Co mówi guideline 2.5.1?

Reguła znajduje się w sekcji 2.5, „Software Requirements”, w App Review Guidelines: „Apps may only use public APIs and must run on the currently shipping OS. Keep your apps up-to-date and make sure you phase out any deprecated features, frameworks or technologies that will no longer be supported in future versions of an OS. Apps should use APIs and frameworks for their intended purposes and indicate that integration in their app description.”

Mówiąc prosto, to cztery obowiązki:

1. Tylko publiczne API, czyli takie, które Apple dokumentuje.
2. Aplikacja działa na bieżącej wersji iOS, od września 2026 to iOS 27.
3. Nic przestarzałego, co zaraz zniknie: wymieniasz to, czemu Apple ogłosiło koniec wsparcia.
4. Każdy framework na swoim miejscu i wspomniany w opisie: HomeKit do inteligentnego domu, HealthKit do zdrowia i sportu, połączony z aplikacją Zdrowie.

Stąd nazwa odrzucenia: „Guideline 2.5.1 - Performance - Software Requirements”.

Publiczne API: gdzie kryje się ryzyko w aplikacji Expo

Prywatne API to funkcja systemu, której Apple nie dokumentuje. Apple nie gwarantuje ani jej działania, ani tego, że będzie dostępna w kolejnej wersji iOS. Dlatego jest zakazana.

Twój kod JavaScript nigdy nie dotyka iOS bezpośrednio: przechodzi przez moduły natywne. Moduły z SDK Expo utrzymuje zespół Expo. Pozostałe zawierają kod, którego nie napisałeś, a Apple sprawdza go tak samo jak twój. Poradnik o ITMS-90683 pokazuje ten sam mechanizm przy opisach uprawnień: Apple ocenia kod obecny w buildzie, a nie to, co aplikacja faktycznie robi.

W Solys, na dzień 15 października 2026, 42 bezpośrednie zależności zawierają natywny kod iOS, z czego 14 spoza SDK Expo. Są wśród nich RevenueCat, Sentry, AppsFlyer i react-native-device-activity, czyli most do API Screen Time.

Prywatne API może zostać wykryte w dwóch momentach. Przy wysyłce automatyczna analiza App Store Connect może zwrócić błąd ITMS-90338. Podczas review recenzent powołuje się na 2.5.1.

Przestarzałe API: od UIWebView do UIScene

Najbardziej znany przykład to UIWebView, stary komponent do wyświetlania stron. Apple przestało go akceptować w nowych aplikacjach w kwietniu 2020, a w aktualizacjach w grudniu 2020. Stara biblioteka, która wciąż się do niego odwoływała, blokowała wysyłkę. W Solys wyszukiwanie z checklisty poniżej nie znajduje żadnego odwołania.

Kolejna zmiana jest już zapowiedziana. Notatka techniczna Apple TN3187 mówi: „In the next major release following iOS 26, UIScene lifecycle will be required when building with the latest SDK; otherwise, your app won't launch.” Czyli aplikacja skompilowana z SDK iOS 27 bez cyklu życia opartego na scenach się nie uruchomi.

Trzy daty, które warto połączyć:

• Od kwietnia 2026 Apple wymaga Xcode 26: o tym jest poradnik o ITMS-90725.
• W kwietniu 2027, według strony Apple o wysyłaniu aplikacji, SDK iOS 27 stanie się obowiązkowy.
• Expo SDK 58, w becie od 15 września 2026, już generuje obsługę scen, zgodnie z ogłoszeniem Expo.

Z Expo SDK 57 i Xcode 26 nadal kompilujesz z SDK iOS 26: dziś nic się nie psuje. Moduły, które modyfikują AppDelegate, będą musiały się dostosować przed kwietniem 2027.

Frameworki używane niezgodnie z przeznaczeniem

Recenzent sprawdza, czy wrażliwy framework obsługuje widoczną funkcję i czy twoja strona w sklepie o niej wspomina.

• HealthKit służy do zdrowia i sportu. Wytyczne Apple dotyczące interfejsu mówią: „If your app doesn't provide health and fitness functionality, don't request access to people's private health data.”
• HomeKit służy do inteligentnego domu i do niczego innego.
• PushKit służy do połączeń głosowych przez IP. Dokumentacja PushKit jest jednoznaczna: „If you are unable to support CallKit in your app, you cannot use PushKit to handle push notifications.” Powiadomienie VoIP, które budzi aplikację bez połączenia, to nadużycie.
• Family Controls, czyli API Screen Time, wymaga specjalnego uprawnienia. Jego dokumentacja precyzuje: „Before submitting your app to the App Store, you must request permission to use the entitlement.”

Dla Solys poprosiłem o to uprawnienie dystrybucyjne 23 września 2026 i Apple przyznało je tego samego dnia. Użycie pasuje do frameworka: użytkownik wybiera aplikacje do wstrzymania, a Solys blokuje je na 30, 45 lub 60 minut po przebudzeniu. Opis w sklepie mówi to jednym zdaniem: „Solys korzysta z uprawnienia Screen Time od Apple, aby wstrzymywać wybrane aplikacje.” Właśnie tego wymaga końcówka 2.5.1: wspomnienia o integracji w opisie.

Wersje beta: TestFlight tak, App Store nie

Informacje o wydaniach App Store Connect pokazują tę regułę w praktyce. 14 października 2026 buildy zrobione w Xcode 27.2 beta 3 są akceptowane „for internal and external testing”, czyli do TestFlight. 5 października buildy z Xcode 27.1 RC zostały dopuszczone „for the App Store”.

Build skompilowany betą Xcode trafia do TestFlight, nigdy do review. Żeby wysłać aplikację do sprawdzenia, potrzebujesz wersji finalnej albo RC, którą Apple dopuściło do App Store.

Dwie uwagi dla aplikacji w Expo:

• Beta Expo to nie beta Apple. Apple kontroluje wersję Xcode i SDK iOS, a nie wersję Expo. Ogłoszenie SDK 58 dodawało, że obrazy EAS z Xcode 27 pojawią się wkrótce.
• Testowanie na aktualnym iOS nadal jest obowiązkowe, nawet jeśli kompilujesz z SDK iOS 26. Uruchom aplikację od zera na aktualnym iPhonie lub symulatorze.

Checklista: zależności natywne przed wysłaniem

Przejdź ją przed każdym buildem produkcyjnym. Komendy uruchamiasz w katalogu głównym projektu Expo:

npx expo-doctor
npx expo install --check
grep -rlw "UIWebView" node_modules --include='*.m' --include='*.mm' --include='*.swift' --include='*.h'

1. npx expo-doctor nie zgłasza żadnego błędu. W Solys, 15 października 2026: 20 z 21 testów zaliczonych. Błąd wynikał z 13 pakietów Expo spóźnionych o jedną poprawkę, które wyrównuje npx expo install --check.
2. Każdy moduł spoza SDK Expo jest w React Native Directory. Expo Doctor sprawdza to domyślnie, jak podaje dokumentacja Expo. Nieznany pakiet zasługuje na przeczytanie jego kodu iOS.
3. Każdy moduł natywny nadąża za twoją wersją React Native. Tabela wersji Expo łączy SDK 57 z React Native 0.86. Moduł bez wydania od kilku wersji to sygnał ostrzegawczy.
4. Wyszukiwanie UIWebView nic nie zwraca. Zrób to samo dla każdego API, któremu Apple ogłosiło koniec wsparcia.
5. Każdy wrażliwy framework ma widoczną funkcję: zdrowie, Screen Time, połączenia, dom. Opis o niej wspomina, a specjalne uprawnienie zostało przyznane.
6. Build pochodzi z finalnego Xcode. Sprawdź wersję w logach buildu EAS.
7. Aplikacja uruchamia się od zera na aktualnej wersji iOS, z nowym kontem.
8. Moduły, które dotykają AppDelegate, deklarują obsługę UIScene przed twoim przejściem na SDK iOS 27.

Jak odpowiedzieć na odrzucenie z 2.5.1?

Wiadomość zwykle wskazuje API lub framework, o który chodzi. Są dwa przypadki:

• Framework nie obsługuje niczego widocznego: usuń moduł lub capability, zrób nowy build i odpowiedz w dwóch zdaniach.
• Framework obsługuje prawdziwą funkcję: podaj dokładną ścieżkę, zrzut ekranu lub krótkie wideo i wspomnij o integracji w opisie aplikacji.

Usunięcie modułu natywnego zmienia plik binarny: aktualizacja zdalna nie wystarczy. Poradnik o guideline 2.1 wyjaśnia, dlaczego recenzent widzi tylko kod zawarty w buildzie. Dalsza rozmowa toczy się w App Store Connect, jak w poradniku o tym, jak odpowiedzieć App Review.

Sprawdź swój projekt przed wysłaniem

Review Kit zawiera moją checklistę przed wysłaniem, moje poprawione odrzucenia i skille Claude Code, które przeglądają twój projekt Expo. Jeśli chcesz, żeby spojrzał na to człowiek, zarezerwuj godzinę ze mną: razem przeczytamy wiadomość od Apple i twoje zależności. Cały proces opisuję na stronie aplikacja odrzucona przez Apple.

Przygotowujesz swoje pierwsze wydanie? Zrób darmową diagnozę: dostaniesz moją checklistę przeciw odrzuceniom Apple.

Najczęściej zadawane pytania

Co oznacza „Guideline 2.5.1 - Performance - Software Requirements”?

To nazwa odrzucenia, gdy Apple uzna, że twoja aplikacja używa niepublicznego API, przestarzałej technologii lub frameworka niezgodnie z przeznaczeniem. Wiadomość zwykle wskazuje problematyczny element.

Czym różni się guideline 2.5.1 od błędu ITMS-90338?

ITMS-90338 to automatyczny błąd przy wysyłaniu builda, gdy analiza wykryje niepubliczny symbol. 2.5.1 to reguła stosowana przez człowieka podczas review, która obejmuje też frameworki użyte niezgodnie z przeznaczeniem i przestarzałe technologie.

Czy można wysłać do review aplikację skompilowaną betą Xcode?

Nie. App Store Connect akceptuje takie buildy tylko do TestFlight. Do review kompiluj finalną wersją Xcode albo RC, którą Apple dopuściło do App Store w swoich informacjach o wydaniach.

Czy aplikacja Expo może nieświadomie używać prywatnego API?

Tak, przez zewnętrzny moduł natywny. Twój kod JavaScript sam nie wywołuje iOS, ale każdy pakiet natywny zawiera kod w Objective-C lub Swift. Przejrzyj listę modułów spoza SDK Expo przed każdą wersją.

Czy trzeba od razu przejść na Expo SDK 58?

Nie ze względu na 2.5.1 na dzień 15 października 2026: SDK 57 kompiluje z SDK iOS 26, który jest nadal akceptowany. Zaplanuj aktualizację przed kwietniem 2027, kiedy Apple zacznie wymagać SDK iOS 27 i cyklu życia opartego na scenach.