App Thinning — ano ito, sa anong mga komponent ito binubuo at paano ito gumagana

Ano ang App Thinning

App Thinning ay isang komprehensibong teknolohiya ng pag-optimize ng distribusyon ng iOS app na ipinakilala ng Apple kasama ng iOS 9 (Setyembre 2015). Ang layunin ng App Thinning ay mabawasan ang laki ng app na dina-download ng user sa kanilang device, nang hindi binabago ang source code at functionality. Ang teknolohiya ay gumagana sa tatlong antas: sa yugto ng pag-build (compilation), sa panig ng App Store (paghahatid), at sa device (pamamahala ng resource).

Bago ang pagdating ng App Thinning, ang mga developer ay nagsasama ng mga resource para sa lahat ng posibleng device sa binary file — mga @2x at @3x na imahe, 32-bit at 64-bit na code, Metal shader para sa iba't ibang GPU. Ito ay nagdulot ng paglobo ng laki ng app: ang user ng iPhone 6 Plus na may Retina HD display ay nakatatanggap ng vector resource para sa iPad Pro na hindi kailanman ginamit. Apple ay nalutas ang problemang ito sa pamamagitan ng paglipat ng bahagi ng build work sa mga server ng App Store.

Ayon sa pananaliksik ng Apple (WWDC 2015, Session 412), ang isang tipikal na app na may suporta para sa maraming arkitektura at resolusyon ay maaaring bumaba ng 30-50% pagkatapos ilapat ang App Thinning. Para sa mga laro na may maraming high-detail na texture, ang savings ay maaaring umabot ng 70-80%. Patuloy na pinapabuti ng Apple ang teknolohiya: sa iOS 17, idinagdag ang optimization para sa ARM64e at pinabuti ang trabaho sa On-Demand Resources para sa mga app na gumagamit ng Swift Package Manager.

Ang Problema na Nalulutas ng App Thinning

Ang laki ng mga mobile app ay patuloy na lumalaki. Ayon sa datos ng Sensor Tower (2025), ang average na laki ng iOS app ay tumaas ng 45% sa nakaraang 5 taon. Para sa mga user na may limitadong data plan o mabagal na internet, bawat megabyte ay mahalaga. Nalulutas ng App Thinning ang problemang ito nang walang partisipasyon ng developer — sapat na upang i-activate ang suporta sa mga setting ng proyekto at i-upload ang build sa App Store Connect.

Paano Gumagana ang App Thinning

Ang proseso ng App Thinning ay nagsisimula pagkatapos i-upload ang archive ng app sa App Store Connect. App Store sinusuri ang binary file at hinahati ito sa mga segment batay sa arkitektura (armv7, arm64, arm64e), resolusyon ng screen (iPhone, iPad), at mga bersyon ng iOS. Para sa bawat kombinasyon, isang hiwalay na variant ang nilikha. Kapag nag-click ang user ng “I-download”, tinutukoy ng App Store ang modelo ng device, bersyon ng iOS, at uri ng koneksyon (Wi-Fi / mobile network) at nagpapadala lamang ng kaukulang variant.

Para sa user, ang proseso ay transparent — walang pagpipilian ng “light na bersyon” o dialog na may mga setting. App Store awtomatikong pinipili ang pinaka-angkop na variant batay sa metadata ng device na ipinapadala sa server kapag humihiling ng pag-download. Kung ang device ay gumagamit ng Wi-Fi, ang App Store ay maaaring magpadala ng variant na may mas mataas na kalidad na resource (hal., ProRes video para sa iPhone 16 Pro). Kapag nagda-download sa pamamagitan ng mobile network, ang minimum na posibleng set ang ginagamit.

Ang pangalawang antas ng optimization — Bitcode. Sa naka-activate na opsyong ENABLE_BITCODE, kino-compile ng Xcode ang app hindi sa machine code, kundi sa intermediate na LLVM na representasyon. Ang App Store ay muling kino-compile ang Bitcode para sa partikular na arkitektura ng processor ng user, na nagpapahintulot sa Apple na maglapat ng compiler optimization para sa mga bagong henerasyon ng chips (A17, M4) nang hindi ina-update ang app ng developer. Ang Bitcode ay mandatory para sa watchOS at tvOS, ngunit opsyonal para sa iOS.

Mga Komponent ng App Thinning: Slicing, Bitcode, ODR

Ang App Thinning ay binubuo ng tatlong independiyenteng mekanismo, bawat isa ay responsable para sa sarili nitong aspeto ng optimization. Slicing (paghihiwa) hinahati ang binary file sa mga variant batay sa arkitektura at resolusyon ng screen. Kino-configure ng developer ang Slicing sa pamamagitan ng Asset Catalogs — awtomatikong isinasama ng Xcode sa slice ang mga resource lamang na tumutugma sa target na device. Halimbawa, ang iPhone SE (ikatlong henerasyon) ay makakatanggap lamang ng @2x na imahe at arm64 code, habang ang iPad Pro M4 — @3x na imahe at arm64e code.

Bitcode ay LLVM IR (Intermediate Representation) — isang representasyon ng program na independiyente sa machine. Kapag naka-activate ang Bitcode, hindi gumagawa ang Xcode ng huling machine code, kundi ini-save ang intermediate na representasyon. App Store Connect kapag nag-u-upload ng build ay tumatanggap ng Bitcode at muling kino-compile ito para sa mga arkitektura ng lahat ng suportadong device. Pinapahintulutan ng Bitcode ang Apple na maglapat ng mga optimization na hindi available sa yugto ng compilation ng developer — halimbawa, paggamit ng mga bagong instruction ng processor (SME, SVE) sa M4 chips.

On-Demand Resources (ODR) — ikatlong mekanismo, na nagpapahintulot sa pagbaba ng mga resource ng app pagkatapos gamitin. Minamarkahan ng developer ang mga resource (level ng laro, onboarding na imahe, video) ng mga ODR tag. iOS ay naglo-load ng mga minarkahang resource on demand sa background at ibinababa ang mga ito kapag kulang ang memory o pagkatapos gamitin. Ang ODR ay lalong epektibo para sa mga laro na may maraming content — ang mga unang level ay maaaring maihatid sa loob ng app, at ang iba ay na-load habang umuusad ang manlalaro.

Kailan Pumili ng Bawat Komponent

Ang pagpili ng mekanismo ng App Thinning ay depende sa uri ng app at target na audience nito. Slicing ay inirerekomenda na laging i-activate — hindi nangangailangan ng karagdagang aksyon ng developer maliban sa tamang organisasyon ng Asset Catalogs at nagbibigay ng stable na 20-30% na pagbawas sa laki. Ang Bitcode ay sulit na i-activate kung ang app ay gumagamit ng custom na Metal shader o nagpaplanong suportahan ang mga bagong arkitektura ng Apple nang hindi nagre-rebuild. ODR ay makatwiran para sa mga app na may malaking volume ng content — mga laro, photo editor, streaming app.

Para sa tipikal na business app (data feeds, forms, REST API), sapat na ang Slicing at minimal na ODR configuration para sa onboarding na imahe. Mga Laro na may 3D graphics ay nakikinabang sa lahat ng tatlong mekanismo: inaalis ng Slicing ang hindi kinakailangang shader, ini-optimize ng Bitcode ang rendering para sa GPU, at ibinababa ng ODR ang natapos na level. Ayon sa Apple (WWDC 2024), ang kombinasyon ng lahat ng tatlong mekanismo ay nagbabawas ng paunang laki ng installation ng average na 45-55% kumpara sa universal binary.

Pag-configure ng App Thinning sa Xcode

Upang i-activate ang App Thinning sa isang Xcode project, kailangan gawin ang ilang hakbang. Slicing ay kino-configure sa pamamagitan ng App Thinning sa build settings: Build Settings → App Thinning. Tatlong value ang available: None (walang optimization), Automatic (default na awtomatikong configuration), at Manual na may pagpili ng partikular na variant para sa pag-test. Inirerekomenda ng Apple ang Automatic para sa karamihan ng proyekto.

Para sa Asset Catalogs, mahalaga ang tamang organisasyon ng resource: ang mga imahe ay inilalagay sa universal catalog na may pagtukoy ng lapad/taas, at awtomatikong gumagawa ang Xcode ng @1x, @2x, at @3x na variant. Xcode kapag nagbu-build ay isinasama lamang ang mga resolusyon na ginagamit sa proyekto. Ang Metal shader ay kino-compile nang hiwalay para sa bawat GPU family — Apple GPU, PowerVR, Mali, na pinamamahalaan din sa pamamagitan ng Asset Catalogs.

Bitcode ay naka-activate sa flag na ENABLE_BITCODE = YES sa Build Settings. Para sa iOS, ang flag na ito ay opsyonal (naka-disable bilang default mula noong Xcode 14), ngunit para sa watchOS at tvOS ay mandatory. Kapag nag-a-activate ng Bitcode sa isang proyekto na gumagamit ng third-party na library, lahat sila ay dapat ding naka-build na may Bitcode, kung hindi ay mabibigo ang build. Bitcode ay nagpapataas ng oras ng compilation ng 20-30%, ngunit nagbibigay ng buong compatibility sa mga arkitektura sa hinaharap.

Pagsusuri ng mga Resulta ng App Thinning

Pagkatapos mag-upload sa App Store Connect, maaari mong suriin ang laki ng mga slice sa seksyong Activity → Build Metric. App Store Connect ay nagpapakita ng Estimated App Store Size para sa iba't ibang device. Para sa lokal na pagsusuri, nagbibigay ang Xcode ng command na xcodebuild na may flag na -exportArchive at opsyong thinning upang gumawa ng mga slice sa lokal na makina. Ang resulta ng Slicing ay makikita sa Organizer (Window → Organizer) pagkatapos ng pag-archive — ang tab na App Thinning Profiles ay nagpapakita ng laki para sa iba't ibang device.

# Lokal na pagsusuri ng Slicing
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "export/" \
  -exportOptionsPlist "export.plist" \
  -thinning "<thin-for-all-variants>"

Xcodebuild na may flag na -thinning ay gumagawa ng .app file para sa bawat kombinasyon ng arkitektura, bit, at GPU. Ang parameter na <thin-for-all-variants> ay gumagawa ng lahat ng posibleng variant — kapaki-pakinabang para sa pagsusuri. Para sa CI pipelines, isang partikular na kombinasyon ang ginagamit, halimbawa iPhone14,4 (iPhone SE 3). Ang resultang .app file ay maaaring suriin gamit ang app-size utility.

Mga Benepisyo at Epekto ng App Thinning

Ang pangunahing benepisyo ng App Thinning ay pagbawas ng laki ng pag-download para sa end user. Ayon sa Apple (WWDC 2024), isang tipikal na app na gumagamit ng lahat ng tatlong mekanismo ng App Thinning ay dina-download nang average na 40% mas mabilis sa pamamagitan ng mobile network at kumukuha ng 35% mas kaunting espasyo sa disk. Ito ay direktang nakakaapekto sa conversion ng pag-install: ayon sa Sensor Tower, bawat 10 MB ng laki ng app ay nagbabawas ng conversion ng 1%.

Ang pangalawang benepisyo — optimization para sa hinaharap na device salamat sa Bitcode. Maaaring muling i-compile ng Apple ang Bitcode app para sa mga bagong arkitektura nang walang partisipasyon ng developer. Halimbawa, sa paglipat mula Intel patungong Apple Silicon (M1), ang Bitcode app ay gumana sa macOS sa pamamagitan ng Rosetta 2 nang walang karagdagang compilation. Ang mga developer na hindi nag-activate ng Bitcode ay napilitang mag-rebuild ng app para sa arm64.

Ang ikatlong benepisyo — ODR (On-Demand Resources) ay nagbabawas ng karga sa storage ng device. Ang mga laro na may dose-dosenang level, tulad ng Asphalt 8: Airborne, ay gumagamit ng ODR upang mag-load ng mga bagong track habang umuusad ang manlalaro. Ang developer ay maaaring mag-set ng Initial Install Tags para sa mga resource na na-load kasama ng app at Prefetch Tags para sa content na na-load sa background pagkatapos ng pag-install. Kinokontrol ng Apple ang ODR limits: hanggang 512 MB bawat request at hanggang 20 GB total cache sa device.

Mga Limitasyon ng App Thinning

Ang App Thinning ay may ilang mahalagang limitasyon na dapat isaalang-alang kapag nagdi-design ng app. Una, ang Slicing ay hindi inilalapat sa mga app na ipinamamahagi sa pamamagitan ng Enterprise (in-house) o Ad Hoc — ang mga build na ito ay naglalaman ng lahat ng variant at hindi dumadaan sa App Store. Para sa pag-test ng Slicing, ang developer ay maaaring gumamit ng TestFlight, na nagpro-process din ng Slicing sa panig ng mga server ng Apple.

Pangalawa, ang Bitcode ay nagpapataas ng oras ng pag-build at laki ng .xcarchive archive ng humigit-kumulang 30-50%. Hindi lahat ng third-party na library ay sumusuporta sa Bitcode — kung kahit isang dependency ay naka-build nang walang Bitcode, ang pag-build ng proyekto na may ENABLE_BITCODE ay mabibigo. Inirerekomenda ng Apple na suriin ang compatibility ng library bago i-activate ang Bitcode. Bukod dito, hindi ganap na sinusuportahan ng Bitcode ang Swift Package Manager — ang ilang Swift package ay maaaring makasira ng Bitcode build.

Pangatlo, ang On-Demand Resources ay hindi ginagarantiya ang agarang availability ng content — ang pag-load ng ODR ay nangyayari sa background at maaaring maantala kung ang device ay nasa low battery mode o mahinang signal ng network. Developer ay dapat mag-implement ng pag-handle ng ODR loading status sa pamamagitan ng NSBundleResourceRequest at magpakita ng progress indicator sa user. Ang pagkabigo ng ODR loading ay hindi dapat harangan ang functionality ng app — kinakailangan ang graceful fallback.