廃止APIの置き換えが複数OSバージョンサポートで膨らむ理由──段階的対応の設計パターン

現場で頻繁に起こる「後付け対応」の泥沼

モバイルアプリの開発では、OSバージョンによって利用可能なAPIが異なります。古いバージョンのサポートを続けている限り、新しいOS側で廃止されたAPIを使い続けるか、条件分岐で複数の実装を持つかのいずれかを選ぶ必要があります。

この判断を開発初期に明確にしていないと、運用フェーズで「このAPIはいつまで使えるのか」「新しいOSではどう対応するのか」という問い合わせが頻繁に発生し、その都度アドホックな修正が積み重なっていきます。特に複数のOSバージョンをサポートしているアプリほど、この負担が指数関数的に増えていくのです。

なぜ「廃止予告」の段階で対応が後回しになるのか

OSのメジャーアップデートが発表されると、新機能の追加やパフォーマンス改善に目が向きがちです。廃止予告されたAPIについては「まだ使えるから」と判断が先延ばしになり、実際に廃止されるまでは優先度が低いままになることが多いです。

しかし、ここが落とし穴です。廃止されたAPIを使い続けると以下の問題が連鎖します。

• 新しいOS版のアプリがリジェクトされる：アプリストアの審査で廃止API使用を理由に却下される
• ユーザーの更新がブロックされる：古いOSユーザーは新機能が得られず、新しいOSユーザーは更新できない
• 保守コストが二重化する：廃止API版と新API版の両方の実装を並行して保守しなければならない
• テスト負荷が増加する：複数の条件分岐を全パターン検証する必要が生じる

複数バージョン対応時の実装パターン

実務では、廃止APIの置き換えを段階的に進める設計が有効です。以下のような構造を検討してください。

1. APIラッパー層の導入

廃止APIを直接呼び出すのではなく、中間層を挟むことで、後の置き換えを容易にします。

// 悪い例：廃止APIを直接呼び出し
func fetchUserLocation() {
    let location = CLLocationManager.startUpdatingLocation()
    // 複数の場所で同じ廃止APIが散在
}

// 良い例：ラッパー層を経由
class LocationService {
    func getCurrentLocation(completion: @escaping (CLLocationCoordinate2D?) -> Void) {
        if #available(iOS 14.0, *) {
            // 新しいAPIを使用
            locationManager.requestLocation()
        } else {
            // 古いAPIで互換性を保つ
            locationManager.startUpdatingLocation()
        }
    }
}

この設計により、廃止APIの置き換え時に修正箇所が集約され、複数箇所での変更リスクが減ります。

2. バージョン対応マトリクスの明文化

どのOSバージョンでどのAPIを使うかを、事前に明確にしておくことが重要です。

機能: ユーザー位置情報取得
- iOS 14以上 → CLLocationManager.requestLocation()
- iOS 13以下 → CLLocationManager.startUpdatingLocation()
- サポート終了予定: iOS 13 (次のメジャー更新時)

機能: バックグラウンド処理
- iOS 13以上 → BackgroundTasks framework
- iOS 12以下 → UIApplication.shared.beginBackgroundTask()
- サポート終了予定: iOS 12 (2年以内)

この表を持つことで、開発チーム全体が統一した判断基準を持つことができます。

3. 段階的な廃止スケジュール

廃止APIへの対応を「いつまでに終わらせるか」を事前に決めておくことで、運用負荷を予測可能にします。

運用フェーズで陥りやすい落とし穴

「古いOSユーザーが少ないから放置」の判断

使用ユーザーが1%未満だからといって放置すると、その1%から継続的にバグ報告が来ます。特に法人利用や特定地域での需要が高い場合、統計的には少なくても実務的には無視できません。

テスト環境の不備

実機またはシミュレータで複数バージョンを同時にテストしていないと、廃止API対応時に予期しない不具合が本番で発生します。CI/CDパイプラインに複数OS版のテストを組み込むことが現実的です。

ドキュメントの不更新

廃止API対応の判断基準がドキュメント化されていないと、後から参画した開発者が古い実装パターンを踏襲してしまいます。

小規模チームでの現実的な対応

予算や人員が限られている場合は、以下の優先順位で進めることをお勧めします。

1. 最初の1ヶ月：廃止予告されたAPIをコード内で検索し、使用箇所を一覧化する
2. 次の2ヶ月：最も影響が大きい機能から順に、ラッパー層の導入と新API対応を進める
3. 並行して：サポート終了予定のOSバージョンを社内で決定し、チーム全体で共有する

完璧を目指さず、「今のサポート範囲では何が必須か」を判断することが、持続可能な保守につながります。

まとめ

廃止APIの置き換えは、個別の技術課題ではなく、OSバージョンサポート戦略の一部として設計する必要があります。開発初期に「どのバージョンまでサポートするか」「いつまでにAPI置き換えを完了させるか」を決めておくことで、運用フェーズでの急な対応や二重保守を避けることができます。

既存のアプリであれば、まずは現在の廃止API使用状況を把握し、段階的な置き換え計画を立てることから始めるのが現実的です。