Objective-CからSwiftへ、4つの移行ポイント～メルカリの実践例から最適な手法を学ぶ

3つ目のBaseViewControllerとは、Objective-C時代によく作られた、ViewControllerの共通処理を集めた巨大なViewControllerです。複数のViewControllerで使われる共通的な処理をすべて記述したBaseViewControllerを作成し、個別の画面のViewControllerはBaseViewControllerを継承するという構造になります。

このような構造になったのは、Objective-Cが多重継承に対応していなかったことが要因にあると考えています。しかし、この構造は多くの問題をはらんでおり、今日Swiftで記載するコードでは避けるべきアンチパターンの代表と言えます。問題点としては下記が挙げられます。

• ViewControllerに複雑な処理が記載され、ViewControllerが肥大化する
• 必要のない共通処理まで強制的に含まれており、その画面に本当に必要なコードが解読できない
• BaseViewControllerが肥大化すると、共通処理の中で状態により条件分岐が多数入り込み、特定の画面から処理自体を追うことが著しく困難になる
• UITableViewController, UICollectionViewControllerなど標準のUIViewController拡張クラスが使えなくなる

またBaseViewControllerの類似として、複数の画面で同一のViewControllerを使いまわし、ViewControllerの中で状態により処理を変えるというパターンも存在しています。こちらも、ViewController自体の処理の肥大化と、後からその中の1つの画面だけ処理を変更したい場合のメンテナンス性を著しく下げるアンチパターンといえます。

Swiftではこれらの古いアーキテクチャをすべて破棄し、共通処理を分類して機能単位にまとめ、Protocol Extensionを使用して記述することをおすすめします。

共通機能のサンプルとして、ViewControllerと同名のStoryboardのInitial ViewControllerをインスタンス化するメソッドを実装したProtocol Extensionを紹介します。

extension NSObject {
    static var className: String {
        return NSStringFromClass(self).components(separatedBy: ".").last!
    }
}

protocol Instantiatable {}

extension Instantiatable where Self: UIViewController {
    static func instantiateFromStoryboard() -> Self {
        return UIStoryboard(name: className, bundle: Bundle.main).instantiateInitialViewController() as! Self
    }
}

このようにInstantiatable Protocolを定義して、そのExtension内に実際の処理を記載しています。このProtocol ExtensionはProtocolに準拠しているのがUIViewControllerの時のみ適用されます。個別のViewControllerをこのProtocolに準拠させれば上記メソッドが利用可能になります。

ViewControllerがStoryboard上initialのViewControllerではなく、上記メソッドが使えない場合、このProtocolに準拠させなければ誤ってメソッドが呼び出されてアプリがクラッシュすることはありません。このように、必要な共通機能をProtocolとして切り出し、個別のViewControllerは必要な機能のみProtocolに準拠させることで、必要最低限の機能のみが含まれた見通しの良い実装になります。

Objective-CからSwiftを呼び出す場合の注意点

4つ目のポイントはSwiftとObjective-Cの相互変換を前提とした実装だと、Swiftの実装が制限されてしまうことです。SwiftからObjective-Cのコードを参照する場合、Bridging-HeaderのファイルにObjective-Cのヘッダファイルをimportすると、問題なく参照が可能です。逆に、Objective-CからSwiftを呼び出す場合は、各Objective-Cのファイル内で<Project名>-swift.hというファイルをimportします。

これはBuild SettingのSwift CompilerのセクションにあるObjective-C Generated Interface Header Nameという項目で指定されています。このファイルはビルド時にXcodeが自動的に作成するヘッダファイルのため、Objective-Cのコード記述中にSwiftに関わる部分でXcodeの補完機能などがうまく動作しないことがあります。

その場合は一度プロジェクトをビルドします。このファイルには@objcを付与したクラス, メソッド, プロパティなどがObjective-C用に書き出されるため、これをimportしたObjective-Cのファイルから参照することが可能です。

一方、Objective-CからSwiftを呼び出す場合、SwiftにはObjective-Cにない機能が多数ありますので、参照できる機能に制約があります。代表的なところとしては、structやInt型以外のenumのようなSwiftで積極的に使っていきたい機能が参照できません。そのため、ポイント2で解説したように、Objective-CとSwiftの呼び出しにはWapparを挟み、機能的な制限で冗長に書かざるを得ない部分をWapparで吸収すると良いでしょう。

Swiftらしいコードを書くために

Swiftらしいコードを書こうとすると、iOS SDK標準の実装方法ではうまくいかないケースがあります。UIKitはObjective-Cベースで作成されているため、Swiftから実装するとミスマッチなことがあります。

特に顕著なのが画面遷移です。iOS標準の画面遷移にはUIStoryboardSegueがありますが、これはあまり評判が良くなく、Storyboardは使っていてもSegueは使っていないというケースを多く耳にします。実際、JP版メルカリでもSegueは採用していません。

Segueの一般的な使い方を見てみましょう。

    override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
        if segue.identifier == "showDetail" {
            if let indexPath = tableView.indexPathForSelectedRow {
                let object = objects[indexPath.row] as! NSDate
                let controller = (segue.destination as! UINavigationController).topViewController as! DetailViewController
                controller.detailItem = object
                controller.navigationItem.leftBarButtonItem = splitViewController?.displayModeButtonItem
                controller.navigationItem.leftItemsSupplementBackButton = true
            }
        }
    }

これはiOSの新規ProjectでMastar-Detail Appを選択した際の画面遷移部分の初期コードですが、プロダクトのコードとしては下記のような多数の問題を含んでいます。

• identifierを文字列リテラルと比較している
• ForceDownCastを多用しており、実装を誤るとアプリがクラッシュする実装方法になっている
• MasterViewControllerが遷移先のDetailViewControllerを直接参照し、DetailViewControllerの詳細な実装に依存している
• DetailViewControllerの入力がこれで必要十分なのか分かりにくい

筆者個人としてはSegue自体の考え方はよくできていて、画面遷移においてSegueを仲介することで画面の呼び出し元と呼び出し先の依存関係を分割できるはずだと考えています。

しかし、Segueの標準実装ではそれが実現できません、これをGenericsとProtocol Extensionを利用して改善していきます。

まず、ViewControllerに入力値を挿入可能にするProtocolを定義します。

protocol Injectable {
    associatedtype Input
    func input(_ input: Input)
}

Inputの型が入力データになります。これをSegueを通じて渡せるようにするProtocol Extensionを実装します。

protocol SegueInjectable: Injectable {}

extension SegueInjectable {
    static func input(segue: UIStoryboardSegue, input: Input) -> Self? {
        guard let destination = segue.destination as? Self else { return nil }
        destination.input(input)
        return destination
    }
}

SegueInjectableに準拠したViewControllerでは、上記staticメソッドからsegueを通じてInputデータを渡すことができます。ただ、まだこの状態では遷移元から遷移先のViewControllerの型を参照してstaticメソッドを呼び出すことになります。そこで、UIStoryboardSegueを拡張します。

extension UIStoryboardSegue {
    @discardableResult
    func input(_ input: DetailViewController.Input) -> DetailViewController? {
        return DetailViewController.input(segue: self, input: input)
    }
}

これでSegueを通じてDetailViewControllerに入力値を渡せます。続いてDetailViewControllerをSegueInjectableに準拠させます。

class DetailViewController: UIViewController, SegueInjectable {
    struct Input {
        var text: String = ""
    }
    var input = Input()

    func input(_ input: Input) {
        self.input = input
    }
   ...

これでinputにデータを受け取る準備はできました。viewDidLoadメソッドなどでinputのデータを画面に反映させるロジックを書きます。 そして、画面遷移のコードは下記のように書き換えることができます。

    override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
        if segue.identifier == "showDetail" {
            if let indexPath = tableView.indexPathForSelectedRow {
                let object = objects[indexPath.row] as! NSDate
                segue.input(DetailViewController.Input(text: object.description))
            }
        }
    }

なお、こちらのコードは話を単純にするために、UINavigationContorllerに関する部分は除いています。

さて、まだidentifierを文字列リテラルと比較している問題が残っています。文字列リテラルとの比較は文字列のタイプミスがコンパイラでチェックできず、補完機能のサポートもありません。また、identifierはStoryboard上で定義するため、こちらでもタイプミスの危険性があります。

そもそも上記のコードでidentifierを判定するif文は必要なのでしょうか。 segue.destinationがDetailViewControllerでなければsegue.inputは何もしないので、このif文はなくても動作はします。しかし、その場合他のSegueのアクションがあった場合でもobjectを取り出す処理が実行され、ムダな処理が実行されることになります。

ということで、この部分の処理を他のSegueの場合には実行させないようにしていきましょう。まず、SegueInjectableに下記のメソッドを追加します。

extension SegueInjectable {
    ...
    static func input(segue: UIStoryboardSegue, input: () -> Input?) -> Self? {
        guard let destination = segue.topDestination as? Self,
            let input = input() else { return nil }
        destination.input(input)
        return destination
    }
}

入力値であるInputの値そのものではなく、Inputを返すClosureのメソッドを追加しました。UIStoryboardSegueのExtensionを以下のようにClosureのメソッドを使用するように変更します。

extension UIStoryboardSegue {
    @discardableResult
    func input(_ input: () -> DetailViewController.Input?) -> DetailViewController? {
        return DetailViewController.input(segue: self, input: input)
    }
}

すると、画面遷移のコードを以下のように変更できます。

    override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
        segue.input { () -> DetailViewController.Input? in
            guard let indexPath = tableView.indexPathForSelectedRow,
                let object = objects[indexPath.row] as? NSDate else { return nil }
            return .init(text: object.description)
        }
    }

SegueがDetailViewControllerへの遷移でない場合は、segue.destinationがDetailViewContollerへの型変換に失敗し、segue.inputメソッドの引数であるClosureは実行されません。また、このClosureがnilを返した場合は、DetailViewControllerへの値の引き渡しが行われません。

上記のコードは

• Segueの条件判定が型によって行われているため、タイプミスの危険性がなく、IDEの補完機能の助けを得られる
• ForceDownCastを使用していないので、実行時のクラッシュが起きない
• 入力値がInputにまとめられているため、入力値の全体が一目でわかる
• DetailViewControllerを参照していない（参照しているのはDetailViewController.Input）ため、DetailViewControllerの実装から切り離されている

といった改善ができていることがわかります。

このように、Protocol Extensionで容易にUIKitの既存クラスを拡張し、Swiftらしいコードが書けるよう、フレームワークを構築することができます。

まとめ

Objective-CとSwiftでは言語思想が大きく違うため、アプリを移行するためには基本的なアーキテクチャを大きく変更しなくてはなりません。

近年iOSプログラミングのアーキテクチャは単純なMVCモデルを使うことが減ってきています。今回は言及していませんが、MVPやMVVM、VIPER、Flux、Redux, Clean Architectureなど多くのアーキテクチャが提唱され、さまざまなアプリで導入されています。また、RxSwiftやReactiveSwiftを導入したReactive Programingも多くのアプリで導入されています。

JP版メルカリでは現状はMVVMとReactiveSwiftを採用しています。さらに、MicroViewControllerを提案し、JP版メルカリの極めて複雑な画面をできる限りシンプルに保つように取り組んでいます。

実際にSwiftへの移行を取り組む前にこれらのアーキテクチャやプログラミングスタイルについて調べ、自分の環境とアプリケーションに合ったものを採用することが、移行を成功させ、長期的なメンテナンスを継続する秘訣だと思います。本記事がそのきっかけになれば幸いです。

小林晋士（こばやし・しんじ） @gentlejkov

SIerに8年間勤務後、メドピア株式会社でWebエンジニアとして勤務。その後、TOPLOG株式会社にてiOS兼Webエンジニアとして従事したのち、2018年2月から株式会社メルカリにてiOSエンジニアとして勤務。現在はJP版メルカリの出品系のサービス改善に携わっている。