SwiftUI では多数の Modifier が提供されているが、中にはデバッグに役立つものも存在する。

例えば、SwiftUI のレイアウトシステムに慣れていないうちは（あるいは慣れていても）、実際に何が起こっているのか確認するのに border() は非常に役に立つ。

この考えを一歩進めて、デバッグに役立つ Modifier、あるいは View の extension を実装してみたらどうだろう？

例えば、以下のようなサブビュー用の message メソッドがあり、渡される引数について古典的な print デバッグをしたくなったとしよう。

struct ContentView: View {
    var body: some View {
        message("Hello", width: 2)
    }
    
    func message(_ text: String, width: CGFloat) -> some View {
        Text(text)
            .border(.red, width: width)
    }
}

おそらく以下のように書くことになるはずだ。

  func message(_ text: String, width: CGFloat) -> some View {
+     print("text: \(text), width: \(width)")
+     return Text(text)
-     Text(text)
          .border(.red, width: width)
  }

これは大した手間ではないが、return を新たに追加する必要があったことに留意したい。おそらくデバッグ作業が終わったら不要になった return は消すことになるはずだ。

これはわずかなコストだが、この手の作業は繰り返し発生するものであり、こうした積み重ねは大切な時間を奪うことになる。

代わりに以下のような print デバッグ用のメソッドを View の extension として用意したらどうだろう？

extension View {
    func p(_ string: String) -> some View {
        print(string)
        return self
    }
}

これを利用すると以下のように print デバッグのコードを追加することができる。

  func message(_ text: String, width: CGFloat) -> some View {
      Text(text)
          .border(.red, width: width)
+         .p("text: \(text), width: \(width)")
  }

また、以下のように複数行に分けることもできる。

func message(_ text: String, width: CGFloat) -> some View {
    Text(text)
        .border(.red, width: width)
        .p("text: \(text)")
        .p("width: \(width)")
}

おそらく多くの人が、このように書けたほうが心理的なコストが低いと感じるだろう。このように繰り返されるデバッグ用のコードについて、デバッグ用の Modifier を提供することで、日々のデバッグコストの削減につながる可能性がある。

もう1つ、応用的な例を見てみよう。

アプリを操作していて、ある特定の画面でバグが見つかった場合、当然ながら該当するソースファイルがどれかを特定することになるだろう。

その名前をすぐに思い出せれば問題ないが、規模が大きいプロジェクトの場合はすぐに見つけらないこともあり、場合によっては画面上のテキストやボタン名からソースを検索して、該当するソースファイルを探し出すこともあるだろう。

もし、画面上の View に当該ファイル名を表示する Modifier を提供できたなら、該当するソースファイルを探し出す作業はずっと楽になるはずだ。

OSS として開発されている SwiftUI-Simulator （拙作）では、Built-in でその Modifier が提供されており、カスタムデバッグメニューと組み合わせることで表示・非表示が可能となっている。

Debug enabled	Debug disabled

実装の詳細については OSS 側の README に譲るが、大規模なプロジェクトになった場合、これが効果をもたらすであろうことは想像に難くないはずだ。

ここまで汎用的に利用できそうなデバッグ用の Modifier のアイディアを取り上げたが、おそらくあなたのプロジェクトのドメインにおける特有のデバッグ機能が必要なこともあるだろう。

そうした際に、こうしたテクニックを頭の片隅に置いておくと役立つこともあるだろう。

Discussions

ここまで Modifier を利用した例を取り上げてきたが、必ずしも Modifier に限った話ではなく、デバッグ目的での View を提供することも考えることができる。

例えば、画面上に表示された SFSymbols のアイコンから該当する箇所を検索したいケースはよくあると思われるが、実際にはアイコンからシンボル名をすぐに思い出せることは稀で、結果として systemImage: や systemName: などのキーワードで全検索をすることになる。

候補が列挙されたことによって、該当箇所を探す作業はずっと楽になったのは間違いないが、これが”効率的だ”と感じる人は少ないだろう。

1つのアイディアとして、Image を直接利用する代わりにラッパー用の独自 View を用意し、Debug ビルド時のみタップされたらシンボル名が print されるようにしてみたらどうだろう？

struct ContentView: View {
    var body: some View {
        Image(systemName: "square.and.arrow.down.on.square.fill")
        MyImage(systemName: "square.and.arrow.down.on.square.fill")
    }
}

struct MyImage: View {
    private var systemName: String
    
    init(systemName: String) {
        self.systemName = systemName
    }
    
    var body: some View {
        Image(systemName: systemName)
            #if DEBUG
            .onTapGesture {
                print("systemName: \(systemName)")
            }
            #endif
    }
}

MyImage で表示されたシンボル名をタップすると以下のように出力される。

systemName: square.and.arrow.down.on.square.fill

ソースの該当箇所を探すには、このシンボル名で検索するだけでよいため、修正箇所を特定する作業はずっと楽になるはずだ。

こうした Debuggability を付与した専用のラッパーは、デバッグ時などで大いに役立つこともあるはずだ。

Reference

• border()
• SwiftUI-Simulator

Note

SFSymbols のアイコンから該当箇所を探したい場合、SFReadableSymbols といった OSS（拙作）を利用するのも効果的かもしれない。