try! Swift Tokyo 2025 1日目に参加したので、雑に感想などを綴ろうと思います。
iOS 17, 16, 15 などの新機能
業務に役立つ新しい API をいくつかご紹介いただきました。個人的に気になったものを以下にまとめます。
formatted
Date型を文字列に変換する際、従来のように DateFormatter を使う必要がなくなり、より簡潔に記述できるようになりました。特殊な変換が必要ない場合には、formatted を使用するだけで十分対応できそうです。
標準 API であるため、ローカライズなども考慮されているのではないかと思います。
UIHostingConfiguration
UIKit の一部に SwiftUI を導入可能にする API です。これまで UIHostingController により ViewController 単位で SwiftUI を導入することは可能でしたが、この API を用いれば、例えば UITableView や UICollectionView の Cell 内部でも SwiftUI を利用できるようになります。
現時点では Cell 単位の適用が主な用途のようですが、将来的にはより広い用途での使用できるようになると嬉しいなと思いました。
ContentUnavailableView
「コンテンツが使用できない」ことをユーザーに明確に伝えるための、典型的な UI を提供する API です。
参考記事：Qiita 記事
公式ドキュメント：ContentUnavailableView
privacySensitive(_:)
アプリがバックグラウンドに遷移した際に、画面の内容を自動的に非表示にするなど、プライバシー保護のための API です。
参考記事：Zenn 記事
公式ドキュメント：privacySensitive(_:)
scrollTargetBehavior(_:)
ScrollView を使用する際、ページング処理などの動作を簡単に制御できる API です。以下の記事にて具体的な実装例が紹介されており、後ほど動かしてみたいと思いました。
参考記事：Zenn 記事
公式ドキュメント：scrollTargetBehavior(_:)
Japan Symbol Quiz による SwiftUI の Path アニメーションの探求
Path を用いたアニメーション表現について紹介されていました。アニメーション表現が大好きなので、とてもワクワクしました。自分でも同様のアニメーションを実装して試してみたくなりました。
Swift WTF: 奇妙な挙動、落とし穴、そして修正策
一見すると普通に見える Swift のコードが、実は意図しない挙動を示すことがあると学びました。
特に印象的だったのは、国旗の絵文字に関する挙動です。実際には REGIONAL INDICATOR SYMBOL LETTER（日本の場合、J + P）として扱われており、文字の置換処理に影響することがあります。絵文字を文字列として扱う際には、注意が必要だと強く感じました。
こういった細かな問題を掘り下げ、原因や修正方法まで調査された内容がとても興味深く、学びが多かったです。
素早く実現する優れたアプリデザイン
非常に高いレベルの内容で、自分には少し早かったと感じつつも印象に残りました。
特に心に残ったフレーズはこちらです：
シンプルにするのが良いデザインというのは誤解。
複雑さから生まれる美しさもある。
複雑さを恐れないで。
Charts API で作るグラフアート – データビジュアライゼーションを超えて
Swift Charts の API を使って、グラフ描画にとどまらず「お絵描き」も可能なほどの表現力を実現できることに驚きました。AI に依頼することで、Swift Charts での描画コードも簡単に生成できるようです。
AI 支援の Swift による iOS アプリのゲーミフィケーション
AI ツールは用途によって適材適所で使い分ける必要があること、また、それぞれに得意分野があるという点を学びました。
中でも印象的だったのは、Alex Sidebar という Xcode に特化した AI 支援ツールです。
プレゼンテーションもゲームの中で説明を受けているような形式で、とても面白く記憶に残りました。
SwiftUI Text を使った特殊効果
TextRenderer と textRenderer(_:) を使うことで、Text を行ごと、単語ごと、さらには文字ごとに装飾できる API が紹介されました。
さらに、Metal を利用したアニメーションを Text に適用することも可能です。
以下のリポジトリが紹介されていました：
日本語での Swift プログラミング
ピュアな Swift コードであれば、日本語でのコーディングも技術的には可能であることが紹介されました。
課題としては以下の点が挙げられます：
- 命名規則により、型名と関数名・変数名の区別がつきにくい
- 外部フレームワークやツールが日本語に対応していない場合がある
テストコード内でのケース名に日本語を使うのは、条件が整えば良い選択だと感じました。仕様を明確に伝えられ、読みやすく保守性の高いテストが書けるという観点では、日本語のほうが開発メンバーの認知的負荷も軽減できると考えています。
HDR を理解する
HDR を理解するには自分の知識が足りなさすぎました。
そのため、HDR に関してはまだ理解が浅い部分も多いのですが、基本的には「より綺麗に表示できる技術」であることがわかりました。
ただし、HDR には以下のようなデメリットもあります：
- HDR 表示に慣れると、非 HDR 画面がくすんで見える
- 消費電力が高く、省電力モードでは自動的に無効になることもある
また、EDR（Extended Dynamic Range） という関連技術もあり、最大輝度を引き上げて明るく表示する技術だそうです。
参考記事：HDR と EDR の違い - Qiita
EDR を簡単に扱える Swift ライブラリ: EDR_Swift
40 万以上 DL された個人開発アプリをサービス終了するためにしたこと
40 万ダウンロードを達成した個人アプリをサービス終了するにあたり、実施された対応や、その際に考慮すべきポイントが紹介されていました。
特に印象的だったのは、サービス終了後の問い合わせにも丁寧に対応されていたという点です。誠実な姿勢が伝わってきました。
また、サービス終了の画面を Remote Config により切り替え可能にしておくことで、柔軟な対応ができる点も非常に参考になりました。
「誠実な終了」は将来にわたり信頼を築くためにも重要であり、自分もサービスを終了させる際には、計画的に進めたいと思いました。
宇宙人を探して
アプリ開発において、些細なコードの改善が大きな影響を与えることがあると実感しました。
例えば：
- 100,000 行のコードがあったとして、1 行あたり 0.000001 秒短縮すれば、全体で 1 秒のパフォーマンス改善になる
- コード行数が多くなるほどバグの発生数も増える傾向にあり、1000 行あたり 1〜25 個という統計もある
パフォーマンスと品質を維持する上で、コード量を抑える努力は重要です。
その点で、Emerge Tools には非常に有効な支援ツールが揃っているようです。
以上、雑な感想でした！
わかっていないことも多いですが、わかっていないことがわかって実になったなと思いました。
ここはこういう意味だよとかのコメントも大歓迎ですので、何かありましたらコメントください！！！