IPA: co to jest, struktura pliku i zasada działania

Co to jest IPA i do czego służy

IPA (iOS App Store Package) to format pakietu do dystrybucji aplikacji na platformie Apple. Podobnie jak APK, technicznie IPA to archiwum ZIP, ale z własną strukturą podyktowaną wymaganiami iOS dotyczącymi bezpieczeństwa i podpisu.

Historia formatu

Format IPA pojawił się wraz z iPhone OS 2.0 w 2008 roku i App Store. Za podstawę wzięto format pakietu .app z systemu macOS, spakowany w ZIP w celu zmniejszenia rozmiaru podczas przesyłania. Od tego czasu struktura IPA nie uległa radykalnym zmianom — zmieniały się tylko schematy podpisu i metadane.

Scenariusze użycia

App Store — główny kanał. Dystrybucja ad-hoc — do testowania na ograniczonej liczbie urządzeń (do 100). Dystrybucja Enterprise — dla aplikacji korporacyjnych bez publikacji w sklepie. Programiści używają również IPA do testowania na rzeczywistych urządzeniach przez Xcode.

Struktura wewnętrzna pliku IPA

Wewnętrzna struktura IPA to archiwum ZIP zawierające folder Payload z .app bundle i metadane.

Bundle .app

Wewnątrz folderu Payload znajduje się bundle aplikacji z rozszerzeniem .app. To nie jest plik, ale katalog, który iOS rozpoznaje jako aplikację. Wewnątrz znajduje się plik wykonywalny Mach-O (nazwa zgodna z nazwą bundle), Info.plist, zasoby, obrazy i zlokalizowane ciągi znaków.

Plik wykonywalny Mach-O

Kod źródłowy w Swift lub Objective-C jest kompilowany do kodu maszynowego w formacie Mach-O (Mach Object). Plik zawiera segmenty __TEXT (kod), __DATA (dane) i __LINKEDIT (metadane linkowania). Nowoczesne IPA zawierają tylko 64-bitową architekturę arm64.

Proces budowy IPA przez Xcode

Xcode automatyzuje budowę IPA: od kompilacji źródeł po utworzenie podpisanego archiwum gotowego do przesłania do App Store Connect.

Schematy budowy

Debug — do programowania, bez optymalizacji. Release — do publikacji, z optymalizacjami kompilatora. Każdy schemat określa flagi kompilacji, code signing i entitlements. Xcode tworzy archiwum (Archive) przez menu Product → Archive.

// Info.plist — podstawowe metadane aplikacji
<key>CFBundleName</key>
<string>MyApp</string>
<key>CFBundleIdentifier</key>
<string>com.example.myapp</string>
<key>CFBundleVersion</key>
<string>1</string>
<key>CFBundleShortVersionString</key>
<string>1.0.0</string>

Architektura budowy

Xcode kompiluje każdy plik .swift lub .m do pliku obiektowego (.o), a następnie łączy je w jeden Mach-O plik binarny. Zasoby (obrazy, XIB, storyboard) są przetwarzane osobno: storyboard są kompilowane do binarnego formatu .storyboardc, obrazy są optymalizowane w Asset Catalog (.car).

Podpis IPA i Provisioning Profile

Podpis — najtrudniejszy aspekt IPA. Apple wymaga cyfrowego podpisu dla każdej aplikacji uruchamianej na rzeczywistym urządzeniu. System weryfikuje certyfikat programisty, entitlements i zgodność z Provisioning Profile.

Składniki podpisu

Certificate (Development lub Distribution) — poświadcza tożsamość programisty. Provisioning Profile — łączy certyfikat, bundle ID i listę dozwolonych urządzeń (dla ad-hoc). Entitlements — uprawnienia aplikacji (push, iCloud, App Groups).

Proces podpisu

Xcode podpisuje każdą bibliotekę i framework wewnątrz .app bundle, a następnie podpisuje sam bundle. Końcowe IPA jest podpisywane na poziomie archiwum ZIP. Apple sprawdza wszystkie poziomy podpisu podczas instalacji. iOS nie uruchamia aplikacji, jeśli co najmniej jeden komponent ma nieprawidłowy podpis.

// Weryfikacja podpisu przez Security framework
import Security

func checkSignature() -> Bool {
    let url = Bundle.main.bundleURL
    var staticCode: SecStaticCode?

    guard SecStaticCodeCreateWithPath(
        url as CFURL,
        [], &staticCode
    ) == errSecSuccess else {
        return false
    }
    return true
}

Publikacja IPA w App Store Connect

App Store Connect — platforma Apple do zarządzania publikacją aplikacji. Przesyłanie IPA odbywa się przez Xcode Organizer, Transporter lub wiersz poleceń przez xcrun altool.

Proces przesyłania

Po utworzeniu archiwum Xcode oferuje Distribute App z wyborem metody: App Store Connect, Ad-hoc, Enterprise lub Development. Wybierając App Store Connect, programista wskazuje zespół i potwierdza przesłanie. Xcode sprawdza podpis, wysyła IPA na serwery Apple i zwraca status przetwarzania.

Wiersz poleceń

Do CI/CD używa się xcrun altool lub nowszego notarytool. Apple wymaga notarialnego poświadczenia dla aplikacji macOS, dla iOS ten krok jest opcjonalny, ale zalecany. xcodebuild -exportArchive tworzy podpisane IPA gotowe do przesłania.

Apple sprawdza każde IPA pod kątem złośliwego kodu, prywatnych API i zgodności z zasadami App Store Review Guidelines. Proces sprawdzania trwa od 1 godziny do 2 dni.

App Thinning: optymalizacja IPA dla urządzeń

Podczas przesyłania IPA do App Store Connect Apple stosuje App Thinning — technologię optymalizacji pliku binarnego dla konkretnych urządzeń. Slicing usuwa z IPA zasoby dla nieobsługiwanych rozdzielczości i architektur. On-Demand Resources umożliwia pobieranie części aplikacji (poziomy gier, wideo) tylko na żądanie użytkownika. Bitcode — pośrednia reprezentacja, którą Apple może przekompilować pod nowe architektury bez udziału programisty.

App Store sprawdza również zgodność IPA z wymaganiami Sandbox: aplikacja nie powinna uzyskiwać dostępu do danych innych aplikacji, do systemu plików poza swoim kontenerem ani do funkcji sprzętowych bez wyraźnej zgody użytkownika.

Testowanie IPA przez TestFlight

TestFlight — oficjalny serwis Apple do beta-testowania aplikacji. Programista przesyła IPA do App Store Connect i zaprasza testerów przez e-mail lub publiczny link.

Testowanie wewnętrzne i zewnętrzne

Internal Testing — do 100 uczestników z zespołu programisty. Nie wymaga sprawdzenia przez Apple. External Testing — do 10 000 uczestników, wymaga przejścia Beta App Review. TestFlight automatycznie dystrybuuje buildy do testerów i zbiera analitykę.

Ograniczenia TestFlight

Build jest dostępny do testowania przez 90 dni po przesłaniu. TestFlight obsługuje do 100 aktywnych buildów jednocześnie. Każdy tester może zainstalować do 30 aplikacji jednocześnie. Crashlytics integruje się z TestFlight w celu zbierania raportów o awariach i błędach niekrytycznych.

IPA i Continuous Integration

Budowa IPA w środowisku CI wymaga runnera macOS. GitHub Actions, GitLab CI i Bitrise zapewniają środowiska macOS do budowy iOS. Fastlane lane `build_app` automatyzuje cały cykl: archiwizację, podpis, eksport IPA i przesłanie do TestFlight. Do zarządzania certyfikatami i profilami używa się Match — narzędzia Fastlane przechowującego podpisy w zaszyfrowanym repozytorium Git.

Typowe problemy z IPA

Programiści napotykają szereg typowych błędów podczas budowy i podpisu IPA. Większość z nich wiąże się z nieprawidłową konfiguracją certyfikatów i profilów.

Błąd podpisu: No matching provisioning profile found

Xcode nie znajduje Provisioning Profile odpowiadającego bundle ID i certyfikatowi. Rozwiązanie — pobrać aktualne profile w Xcode Accounts → Download Manual Profiles lub użyć Automatic Signing.

ITMS-90125: The binary is invalid

Błąd występuje podczas przesyłania IPA z nieprawidłową architekturą. Nowoczesne IPA powinny zawierać tylko arm64. Obecność i386 lub x86_64 w pliku binarnym powoduje odrzucenie. Rozwiązanie — sprawdzić architektury w Build Settings i wykluczyć architektury symulatora.

Invalid Bundle Structure: The bundle is missing the required .app bundle

IPA nie zawiera prawidłowej struktury Payload/App.app. Apple oczekuje dokładnej hierarchii. Rozwiązanie — sprawdzić, czy archiwum zawiera folder Payload z jednym .app bundle, a nie płaską listę plików.

Dystrybucja IPA bez App Store

Do dystrybucji korporacyjnej używa się programu Enterprise Apple (299 USD/rok). IPA jest podpisywane certyfikatem Enterprise i może być instalowane na dowolnych urządzeniach firmy bez ograniczenia ilości. Dystrybucja ad-hoc jest ograniczona do 100 urządzeń na konto programisty (99 USD/rok). Systemy MDM (Mobile Device Management), takie jak Jamf i Microsoft Intune, obsługują masową instalację Enterprise-IPA.