App Thinning — چیست، از چه اجزایی تشکیل شده و چگونه کار می‌کند

App Thinning چیست

App Thinning یک فناوری جامع بهینه‌سازی توزیع اپلیکیشن‌های iOS است که توسط اپل همراه با iOS 9 (سپتامبر 2015) معرفی شد. هدف App Thinning به حداقل رساندن اندازه اپلیکیشنی است که کاربر روی دستگاه خود دانلود می‌کند، بدون تغییر کد منبع و قابلیت‌ها. این فناوری در سه سطح کار می‌کند: در مرحله ساخت (کامپایل)، در سمت App Store (تحویل) و روی دستگاه (مدیریت منابع).

پیش از ظهور App Thinning، توسعه‌دهندگان منابع را برای تمام دستگاه‌های ممکن در فایل باینری قرار می‌دادند — تصاویر @2x و @3x، کد 32 بیتی و 64 بیتی، شیدرهای Metal برای GPUهای مختلف. این کار منجر به افزایش حجم اپلیکیشن می‌شد: کاربر iPhone 6 Plus با صفحه نمایش Retina HD منابع برداری را برای iPad Pro دریافت می‌کرد که هرگز استفاده نمی‌شد. اپل این مشکل را با انتقال بخشی از کار ساخت به سرورهای App Store حل کرد.

بر اساس تحقیقات اپل (WWDC 2015، جلسه 412)، یک اپلیکیشن معمولی با پشتیبانی از چندین معماری و رزولوشن می‌تواند پس از اعمال App Thinning 30-50٪ کاهش یابد. برای بازی‌های با تعداد زیادی بافت با جزئیات بالا، صرفه‌جویی می‌تواند به 70-80٪ برسد. اپل به بهبود این فناوری ادامه می‌دهد: در iOS 17 بهینه‌سازی برای ARM64e اضافه شد و کار با On-Demand Resources برای اپلیکیشن‌های استفاده‌کننده از Swift Package Manager بهبود یافت.

مشکلی که App Thinning حل می‌کند

اندازه اپلیکیشن‌های موبایل دائماً در حال افزایش است. بر اساس داده‌های Sensor Tower (2025)، میانگین اندازه اپلیکیشن iOS در 5 سال گذشته 45٪ افزایش یافته است. برای کاربران با طرح تعرفه محدود یا اینترنت کند، هر مگابایت اهمیت دارد. App Thinning این مشکل را بدون مشارکت توسعه‌دهنده حل می‌کند — فقط کافی است پشتیبانی را در تنظیمات پروژه فعال کرده و بیلد را در App Store Connect آپلود کنید.

App Thinning چگونه کار می‌کند

فرآیند App Thinning پس از آپلود بایگانی اپلیکیشن در App Store Connect آغاز می‌شود. App Store فایل باینری را تحلیل کرده و آن را به بخش‌هایی بر اساس معماری‌ها (armv7، arm64، arm64e)، رزولوشن صفحه (iPhone، iPad) و نسخه‌های iOS تقسیم می‌کند. برای هر ترکیب یک نسخه جداگانه (variant) ایجاد می‌شود. وقتی کاربر روی «دانلود» کلیک می‌کند، App Store مدل دستگاه، نسخه iOS و نوع اتصال (Wi-Fi / شبکه موبایل) را تعیین کرده و تنها نسخه مربوطه را ارسال می‌کند.

برای کاربر فرآیند شفاف است — گزینه‌ای برای «نسخه سبک» یا دیالوگی با تنظیمات وجود ندارد. App Store به طور خودکار مناسب‌ترین نسخه را بر اساس متادیتای دستگاه که در زمان درخواست دانلود به سرور ارسال می‌شود، انتخاب می‌کند. اگر دستگاه از Wi-Fi استفاده کند، App Store می‌تواند نسخه‌ای با منابع با کیفیت بالاتر ارسال کند (مثلاً ویدئوی ProRes برای iPhone 16 Pro). هنگام دانلود از طریق شبکه موبایل از حداقل مجموعه ممکن استفاده می‌شود.

سطح دوم بهینه‌سازی — Bitcode. با فعال بودن گزینه ENABLE_BITCODE، Xcode اپلیکیشن را نه به کد ماشین، بلکه به نمایش میانی LLVM کامپایل می‌کند. App Store Bitcode را برای معماری خاص پردازنده کاربر دوباره کامپایل می‌کند که به اپل اجازه می‌دهد بهینه‌سازی‌های کامپایلر را برای نسل‌های جدید تراشه‌ها (A17، M4) بدون بروزرسانی اپلیکیشن توسط توسعه‌دهنده اعمال کند. Bitcode برای watchOS و tvOS اجباری است، اما برای iOS اختیاری است.

اجزای App Thinning: Slicing، Bitcode، ODR

App Thinning از سه مکانیزم مستقل تشکیل شده است که هر کدام مسئول جنبه خاصی از بهینه‌سازی هستند. Slicing (برش) فایل باینری را بر اساس معماری و رزولوشن صفحه به نسخه‌هایی تقسیم می‌کند. توسعه‌دهنده Slicing را از طریق Asset Catalogs پیکربندی می‌کند — Xcode به طور خودکار تنها منابعی را که با دستگاه هدف مطابقت دارند در برش قرار می‌دهد. به عنوان مثال، iPhone SE (نسل سوم) تنها تصاویر @2x و کد arm64 را دریافت می‌کند، در حالی که iPad Pro M4 تصاویر @3x و کد arm64e را دریافت می‌کند.

Bitcode LLVM IR (Intermediate Representation) — نمایش مستقل از ماشین برنامه است. با فعال شدن Bitcode، Xcode کد ماشین نهایی را تولید نمی‌کند، بلکه نمایش میانی را ذخیره می‌کند. App Store Connect هنگام آپلود بیلد، Bitcode را دریافت کرده و آن را برای معماری‌های تمام دستگاه‌های پشتیبانی‌شده دوباره کامپایل می‌کند. Bitcode به اپل اجازه می‌دهد بهینه‌سازی‌هایی را اعمال کند که در مرحله کامپایل توسط توسعه‌دهنده در دسترس نیستند — به عنوان مثال، استفاده از دستورالعمل‌های جدید پردازنده (SME، SVE) در تراشه‌های M4.

On-Demand Resources (ODR) — سومین مکانیزم که امکان تخلیه منابع اپلیکیشن پس از استفاده را فراهم می‌کند. توسعه‌دهنده منابع (مراحل بازی، تصاویر راه‌اندازی، ویدئو) را با برچسب‌های ODR علامت‌گذاری می‌کند. iOS منابع علامت‌گذاری‌شده را در صورت نیاز در پس‌زمینه بارگیری کرده و در صورت کمبود حافظه یا پس از استفاده آنها را تخلیه می‌کند. ODR به ویژه برای بازی‌های با محتوای زیاد مؤثر است — مراحل اولیه را می‌توان در داخل اپلیکیشن ارائه کرد و بقیه را با پیشرفت بازی بارگیری کرد.

چه زمانی هر مؤلفه را انتخاب کنیم

انتخاب مکانیزم‌های App Thinning به نوع اپلیکیشن و مخاطب هدف آن بستگی دارد. Slicing توصیه می‌شود همیشه فعال باشد — به جز سازماندهی صحیح Asset Catalogs به اقدامات اضافی توسعه‌دهنده نیاز ندارد و کاهش پایدار 20-30٪ اندازه را فراهم می‌کند. Bitcode در صورتی که اپلیکیشن از شیدرهای سفارشی Metal استفاده کند یا قصد پشتیبانی از معماری‌های جدید اپل بدون بازسازی را داشته باشد، ارزش فعال کردن دارد. ODR برای اپلیکیشن‌های با حجم محتوای زیاد توجیه‌پذیر است — بازی‌ها، ویرایشگرهای عکس، اپلیکیشن‌های استریمینگ.

برای یک اپلیکیشن تجاری معمولی (خوراک داده، فرم‌ها، REST API) Slicing و حداقل تنظیمات ODR برای تصاویر راه‌اندازی کافی است. بازی‌ها با گرافیک سه بعدی از هر سه مکانیزم بهره می‌برند: Slicing شیدرهای اضافی را حذف می‌کند، Bitcode رندرینگ را برای GPU بهینه می‌کند و ODR مراحل تکمیل‌شده را تخلیه می‌کند. به گفته اپل (WWDC 2024)، ترکیب هر سه مکانیزم اندازه نصب اولیه را به طور متوسط 45-55٪ در مقایسه با باینری جهانی کاهش می‌دهد.

تنظیم App Thinning در Xcode

برای فعال کردن App Thinning در پروژه Xcode باید چند مرحله انجام داد. Slicing از طریق App Thinning در تنظیمات ساخت پیکربندی می‌شود: Build Settings → App Thinning. سه مقدار در دسترس است: None (بدون بهینه‌سازی)، Automatic (پیکربندی پیش‌فرض خودکار) و Manual با انتخاب نسخه‌های خاص برای آزمایش. اپل Automatic را برای اکثر پروژه‌ها توصیه می‌کند.

برای Asset Catalogs سازماندهی صحیح منابع مهم است: تصاویر در کاتالوگ جهانی با مشخص کردن عرض/ارتفاع قرار می‌گیرند و Xcode به طور خودکار نسخه‌های @1x، @2x و @3x را ایجاد می‌کند. Xcode هنگام ساخت تنها رزولوشن‌هایی را که در پروژه استفاده می‌شوند شامل می‌کند. شیدرهای Metal برای هر خانواده GPU جداگانه کامپایل می‌شوند — Apple GPU، PowerVR، Mali که این نیز از طریق Asset Catalogs مدیریت می‌شود.

Bitcode با پرچم ENABLE_BITCODE = YES در Build Settings فعال می‌شود. برای iOS این پرچم اختیاری است (از Xcode 14 به طور پیش‌فرض غیرفعال است)، اما برای watchOS و tvOS اجباری است. هنگام فعال کردن Bitcode در پروژه‌ای که از کتابخانه‌های شخص ثالث استفاده می‌کند، همه آنها نیز باید با Bitcode ساخته شده باشند، در غیر این صورت ساخت با خطا مواجه می‌شود. Bitcode زمان کامپایل را 20-30٪ افزایش می‌دهد اما سازگاری کامل با معماری‌های آینده را فراهم می‌کند.

بررسی نتایج App Thinning

پس از آپلود در App Store Connect می‌توان اندازه برش‌ها را در بخش Activity → Build Metric بررسی کرد. App Store Connect Estimated App Store Size را برای دستگاه‌های مختلف نمایش می‌دهد. برای بررسی محلی، Xcode دستور xcodebuild با پرچم -exportArchive و گزینه thinning را برای ایجاد برش‌ها در ماشین محلی فراهم می‌کند. نتیجه Slicing را می‌توان پس از بایگانی در Organizer (Window → Organizer) مشاهده کرد — برگه App Thinning Profiles اندازه‌ها را برای دستگاه‌های مختلف نشان می‌دهد.

# بررسی محلی Slicing
xcodebuild -exportArchive \
  -archivePath "App.xcarchive" \
  -exportPath "export/" \
  -exportOptionsPlist "export.plist" \
  -thinning "<thin-for-all-variants>"

Xcodebuild با پرچم -thinning فایل‌های .app را برای هر ترکیب معماری، بیتی و GPU ایجاد می‌کند. پارامتر <thin-for-all-variants> همه نسخه‌های ممکن را ایجاد می‌کند — برای بررسی مفید است. برای خطوط لوله CI از ترکیب خاصی استفاده می‌شود، مثلاً iPhone14,4 (iPhone SE 3). فایل‌های .app حاصل را می‌توان با ابزار app-size تحلیل کرد.

مزایا و تأثیر App Thinning

مزیت اصلی App Thinning کاهش اندازه دانلود برای کاربر نهایی است. به گفته اپل (WWDC 2024)، یک اپلیکیشن معمولی با استفاده از هر سه مکانیزم App Thinning به طور متوسط 40٪ سریع‌تر از طریق شبکه موبایل دانلود می‌شود و 35٪ فضای کمتری روی دیسک اشغال می‌کند. این به طور مستقیم بر نرخ تبدیل نصب تأثیر می‌گذارد: به گفته Sensor Tower، هر 10 مگابایت اندازه اپلیکیشن نرخ تبدیل را 1٪ کاهش می‌دهد.

مزیت دوم — بهینه‌سازی برای دستگاه‌های آینده به لطف Bitcode است. اپل می‌تواند اپلیکیشن‌های Bitcode را برای معماری‌های جدید بدون مشارکت توسعه‌دهنده دوباره کامپایل کند. به عنوان مثال، در انتقال از Intel به Apple Silicon (M1)، اپلیکیشن‌های Bitcode از طریق Rosetta 2 در macOS بدون ساخت اضافی کار می‌کردند. توسعه‌دهندگانی که Bitcode را فعال نکرده بودند مجبور به بازسازی اپلیکیشن‌ها برای arm64 شدند.

مزیت سوم — ODR (On-Demand Resources) بار روی حافظه دستگاه را کاهش می‌دهد. بازی‌های با ده‌ها مرحله، مانند Asphalt 8: Airborne، از ODR برای بارگیری مسیرهای جدید با پیشرفت بازی استفاده می‌کنند. توسعه‌دهنده می‌تواند برچسب‌های Initial Install Tags را برای منابعی که همراه با اپلیکیشن بارگیری می‌شوند و Prefetch Tags را برای محتوایی که پس از نصب در پس‌زمینه بارگیری می‌شود تنظیم کند. اپل محدودیت‌های ODR را کنترل می‌کند: حداکثر 512 مگابایت در هر درخواست و حداکثر 20 گیگابایت حافظه نهان کل روی دستگاه.

محدودیت‌های App Thinning

App Thinning چند محدودیت مهم دارد که باید در طراحی اپلیکیشن در نظر گرفته شوند. اولاً، Slicing برای اپلیکیشن‌های توزیع‌شده از طریق Enterprise (in-house) یا Ad Hoc اعمال نمی‌شود — این بیلدها شامل همه نسخه‌ها هستند و از App Store عبور نمی‌کنند. برای آزمایش Slicing، توسعه‌دهنده می‌تواند از TestFlight استفاده کند که Slicing را در سمت سرورهای اپل پردازش می‌کند.

ثانیاً، Bitcode زمان ساخت و اندازه بایگانی .xcarchive را حدود 30-50٪ افزایش می‌دهد. همه کتابخانه‌های شخص ثالث از Bitcode پشتیبانی نمی‌کنند — اگر حداقل یک وابستگی بدون Bitcode ساخته شده باشد، ساخت پروژه با ENABLE_BITCODE با خطا مواجه می‌شود. اپل توصیه می‌کند قبل از فعال کردن Bitcode سازگاری کتابخانه‌ها را بررسی کنید. علاوه بر این، Bitcode از Swift Package Manager به طور کامل پشتیبانی نمی‌کند — برخی بسته‌های Swift ممکن است ساخت Bitcode را خراب کنند.

ثالثاً، On-Demand Resources دسترسی فوری به محتوا را تضمین نمی‌کنند — بارگیری ODR در پس‌زمینه انجام می‌شود و ممکن است در صورت کم بودن باتری یا سیگنال ضعیف شبکه به تأخیر بیفتد. توسعه‌دهنده باید پردازش وضعیت‌های بارگیری ODR را از طریق NSBundleResourceRequest پیاده‌سازی کند و نشانگر پیشرفت را به کاربر نشان دهد. شکست بارگیری ODR نباید عملکرد اپلیکیشن را مسدود کند — یک graceful fallback ضروری است.