Diet for iOS App size (feat. App Thinning)

안녕하세요. 그린입니다 🍏
이번 포스팅은 iOS 앱 크기를 효과적으로 줄이는 방법에 대해 정리해보겠습니다 🙋🏻

---

iOS App Size Optimization Deep Dive

앱스토어에 앱을 올리고 나서 이런 생각 해보신 적 있나요?

 

"어? 내 앱이 200MB가 넘어가네? 사용자들이 셀룰러로 다운로드 못 받겠는데..." 😱

 

또는 리뷰에서 이런 피드백을 받아보신 적이 있을 거예요.

• "앱 용량이 너무 커요"
• "다운로드가 오래 걸려요"
• "저장공간을 너무 많이 차지해요"

 

앱 크기가 큰 것은 단순히 사용자 경험만의 문제가 아닙니다.
다운로드 전환율, 사용자 유지율, 그리고 궁극적으로는 비즈니스 성과에 직접적인 영향을 미치죠.

 

---

Why App Size Matters?

📱 사용자 다운로드 행동 분석

한 Google의 연구에서는 이렇게 말을 합니다.

• 앱 크기가 10MB 증가할 때마다 다운로드 전환율이 약 5% 감소
• 100MB를 넘어가면 사용자들이 현저히 다운로드를 꺼려함
• 저사양 기기 사용자들은 더욱 민감하게 반응

📶 Apple의 셀룰러 다운로드 제한

Apple이 설정한 중요한 임계점들이 있어요.

• 200MB: 셀룰러 데이터로 다운로드 가능한 최대 크기 (iOS 13+)
• 이전에는 150MB → 100MB였지만 점차 늘어나는 추세
• 사용자가 설정에서 "Always Allow"로 변경 가능하지만, 대부분은 기본 설정 유지

💾 기기 저장공간 압박

• 16GB, 32GB 기기 사용자들은 여전히 많음
• 앱 크기가 클수록 삭제 우선순위에 오를 가능성 ↑
• iOS 시스템이 자동으로 앱을 오프로드하는 기준에도 영향

---

Apple의 App Thinning 이해하기

Apple이 iOS 9부터 도입한 App Thinning은 앱 크기 최적화의 핵심 기술이에요.

 

1️⃣ App Slicing

사용자의 기기에 맞는 리소스만 다운로드하는 기술

Universal App (업로드할 때): 150MB
│
├── iPhone 15 Pro 다운로드: 95MB (3x 이미지만 포함)
├── iPhone SE 다운로드: 78MB (2x 이미지만 포함)  
└── iPad Pro 다운로드: 120MB (iPad 전용 리소스 포함)

핵심 포인트: Asset Catalog을 사용해야만 앱 슬라이싱이 적용될 수 있어요!

 

2️⃣ Bitcode

Apple이 서버에서 앱을 재컴파일하여 최적화하는 기술

// 업로드한 바이너리: 범용 최적화
// ↓ Apple 서버에서 재컴파일
// 각 기기별 최적화된 바이너리 생성

주의: iOS 14부터 Bitcode는 선택사항이 되었고, 최신 Xcode에서는 기본적으로 비활성화

 

3️⃣ On-Demand Resources (ODR)

필요할 때만 다운로드하는 리소스 관리

// 게임 예시: 스테이지별 리소스를 ODR로 관리
let resourceRequest = NSBundleResourceRequest(tags: ["stage-2-assets"])
resourceRequest.beginAccessingResources { error in
    if error == nil {
        // 스테이지 2 리소스 사용 가능
    }
}

 

---

실제 앱 크기 측정하기

최적화를 시작하기 전에 정확한 측정이 필요해요.

 

Xcode에서 App Size Report 생성

# 1. Archive 생성
# 2. Organizer에서 "Export App" 선택
# 3. Distribution method: "Ad Hoc"
# 4. App Thinning: "All compatible device variants"
# 5. Rebuild from Bitcode: 체크

이 과정을 거치면 App Thinning Size Report.txt 파일이 생성돼요:

App Thinning Size Report for All Apps of My App

Variant: iPhone15,2-iOS-18.0
  - Uncompressed size: 45.2 MB (설치 후 크기)
  - Compressed size: 32.1 MB (다운로드 크기)

Variant: iPad13,1-iOS-18.0  
  - Uncompressed size: 52.8 MB
  - Compressed size: 37.4 MB

 

커맨드라인으로 빠른 측정

# IPA 파일 크기 확인
ls -lh YourApp.ipa

# IPA 내용물 분석
unzip YourApp.ipa
du -sh Payload/YourApp.app/*

 

---

Optimization Strategies

🎯 Build Settings 최적화

// Build Settings에서 반드시 확인할 항목들

// 1. Optimization Level
Debug: None [-O0]
Release: Fastest, Smallest [-Os]

// 2. Dead Code Stripping  
DEAD_CODE_STRIPPING = YES

// 3. Symbols Hidden by Default
SYMBOLS_HIDDEN_BY_DEFAULT = YES

// 4. Strip Debug Symbols During Copy
STRIP_DEBUG_SYMBOLS_DURING_COPY = YES

 

🎯 Asset Catalog 활용

🚫 잘못된 방식: Bundle에 직접 이미지 포함
YourApp.app/
├── icon@2x.png
├── icon@3x.png  
└── background@2x.png
    background@3x.png

✅ 올바른 방식: Asset Catalog 사용
Assets.xcassets/
├── AppIcon.appiconset/
├── Background.imageset/
└── Icons.imageset/

 

🎯 이미지 최적화

// 1. 적절한 이미지 포맷 선택
Vector Graphics: PDF 또는 SVG (아이콘용)
Photos: HEIF (iOS 11+) 또는 JPEG  
Graphics: PNG (투명도 필요시), WebP (iOS 14+)

// 2. 이미지 압축 설정
Asset Catalog → Image Set → 속성에서:
- Compression: Lossless 또는 Lossy
- Memory Usage: 적절한 설정 선택

Pro Tip: ImageOptim, TinyPNG 같은 도구로 사전 압축 후 Asset Catalog에 추가하면 더 큰 효과!

 

🎯 코드 레벨 최적화

사용하지 않는 코드 제거

# Periphery 도구 설치 및 사용
brew install peripheryapp/periphery/periphery

# 프로젝트 스캔
periphery scan --project YourProject.xcodeproj \
               --schemes YourScheme \
               --targets YourTarget \
               --format xcode

 

사용하지 않는 리소스 정리

// LSUnusedResources 같은 도구 활용
// 또는 수동으로 확인:

// 1. IPA 압축 해제
// 2. Show Package Contents
// 3. 각 리소스 파일의 크기 확인
// 4. 프로젝트에서 검색하여 사용 여부 확인

 

라이브러리 최적화

// 🚫 전체 라이브러리 import
import Alamofire
import Kingfisher

// ✅ 필요한 부분만 import (가능한 경우)
import struct Alamofire.HTTPMethod
import class Kingfisher.ImageDownloader

 

---

Another Optimization Strategies

🚀 On-Demand Resources 활용

특히 게임이나 교육 앱에서 효과적입니다.

// ODR 태그 설정 (Xcode에서)
// Build Phases → Copy Bundle Resources → 각 리소스에 태그 추가

class GameLevelManager {
    func loadLevel(_ levelNumber: Int) {
        let tags = ["level-\(levelNumber)"]
        let request = NSBundleResourceRequest(tags: Set(tags))
        
        request.beginAccessingResources { [weak self] error in
            guard error == nil else {
                print("리소스 로드 실패: \(error!)")
                return
            }
            
            // 레벨 리소스 사용
            self?.setupLevel(levelNumber)
        }
    }
    
    func finishLevel(_ levelNumber: Int) {
        let tags = ["level-\(levelNumber)"]
        let request = NSBundleResourceRequest(tags: Set(tags))
        request.endAccessingResources()
    }
}

 

🚀 Dynamic Framework 활용

// Static Library 대신 Dynamic Framework 사용
// (필요할 때만 로드되므로 메모리 효율적)

// Framework 모듈화
MyApp/
├── Core.framework (필수 기능)
├── Analytics.framework (선택적 로드)
└── Premium.framework (프리미엄 기능용)

 

🚀 Server-Side 리소스 이동

// 자주 변경되는 리소스는 서버로 이동
class ConfigManager {
    func loadRemoteConfig() {
        // 서버에서 설정 파일 다운로드
        // 앱 업데이트 없이도 리소스 변경 가능
    }
}

// 예시: 
// - 이벤트 배너 이미지
// - 다국어 문자열 (자주 변경되는 것들)
// - 튜토리얼 동영상

 

---

Measurement And Monitoring

📊 지속적인 사이즈 모니터링

# CI/CD 파이프라인에 크기 체크 추가
#!/bin/bash

# 이전 버전 크기
PREVIOUS_SIZE=$(cat app_size_history.txt | tail -1)

# 현재 빌드 크기  
CURRENT_SIZE=$(du -sk "YourApp.ipa" | cut -f1)

# 증가율 계산
INCREASE_PERCENT=$(echo "scale=2; ($CURRENT_SIZE - $PREVIOUS_SIZE) * 100 / $PREVIOUS_SIZE" | bc)

if (( $(echo "$INCREASE_PERCENT > 5" | bc -l) )); then
    echo "⚠️ 앱 크기가 5% 이상 증가했습니다!"
    exit 1
fi

 

📊 Emerge Tools 같은 전문 도구 활용

# 앱 크기 분석 전문 서비스들
- Emerge Tools: 상세한 크기 분석과 추적
- App Store Connect: 공식 크기 정보
- 자체 빌드 스크립트: CI/CD 통합

 

💡 최적화 우선순위

1. Asset Catalog 이전 (가장 큰 효과, 낮은 리스크)
2. 이미지 압축 및 포맷 최적화
3. Build Settings 최적화
4. 사용하지 않는 리소스 제거
5. 라이브러리 정리
6. ODR 도입 (복잡하지만 큰 효과)

---

Troubleshooting And Caution

⚠️ 흔한 실수들

// 🚫 Asset Catalog 밖에 스케일 이미지 두기
Bundle에 icon@2x.png, icon@3x.png 직접 포함
→ 모든 기기에 모든 해상도 이미지 다운로드

// ✅ 올바른 방법
Asset Catalog의 Image Set 사용
→ 기기별 필요한 해상도만 다운로드

 

⚠️ 과도한 최적화 경고

// 너무 공격적인 이미지 압축
JPEG Quality: 30% → 사용자 경험 저하
→ 적절한 균형점 찾기 (70-80% 권장)

// 필요한 리소스까지 ODR로 이동
첫 실행에 필요한 핵심 리소스 → 절대 ODR 적용 금지
→ 앱 실행 실패 원인

 

⚠️ 플랫폼별 고려사항

// Apple Watch 앱
최대 크기: 75MB (더 엄격한 제한)

// App Clip
최대 크기: 10MB (매우 엄격)
→ 극도로 최적화된 코드와 리소스 필요

 

---

Conclusion

iOS 앱 크기 최적화는 한 번 하고 끝나는 작업이 아니라 지속적인 관리가 필요한 프로세스입니다.

 

핵심 포인트를 정리해보면,

1. Asset Catalog 사용은 선택이 아닌 필수
2. 측정 → 분석 → 최적화 → 모니터링의 반복 사이클 구축
3. 사용자 경험과 앱 크기의 균형점 찾기
4. 팀 전체의 크기 인식 문화 만들기

 

200MB 셀룰러 제한을 넘어서는 순간 사용자 접근성이 크게 떨어집니다.
하지만 적절한 최적화 전략을 통해 기능은 유지하면서도 크기는 크게 줄일 수 있어요.

 

가장 중요한 것은 개발 초기부터 크기를 고려한 아키텍처를 설계하는 것입니다.
나중에 최적화하려면 훨씬 더 많은 비용과 노력이 들어가거든요 😃

 

---

References

Reducing your app’s size | Apple Developer Documentation

On-Demand Resources Guide: On-Demand Resources Essentials

Emerge Tools | What is app thinning?

iOS App File Size Developer Limits: Maximum Build Info - SimplyMac

GitHub - peripheryapp/periphery: A tool to identify unused code in Swift projects.