はじめに
ヤプリで iOS エンジニアをしている 菅（@Nao_RandD | ナオランド）です。
今年も国内最大級のiOSエンジニア向けカンファレンス iOSDC Japan 2025 に参加してきました。
本記事では、特に印象に残ったセッションやスポンサー活動について紹介します。
今年初の企業ブース出展
今年はヤプリとして 初めて企業ブースを出展 しました。
おはようございます！ #iosdc day1始まりましたね！
今日もYappliの製品デモとヤプリらしいノベルティをご用意してお待ちしております🙌
少し涼しいので、気を付けてお越しくださいね #yapplitech pic.twitter.com/R4x8mNkFST— Yappli Developers / ヤプリDev公式 (@yappli_dev) 2025年9月20日
いつかヤプリのブースを出して、イベントを楽しんでみたいと思っていた自身にとって嬉しいアップデートでした。
来場者に立ち寄ってもらうきっかけづくりとして、X（旧Twitter）のフォロワー増加施策を兼ねた くじ引きキャンペーン を実施しました。景品にはクライアント企業の製品を活用し、Xでのフォロー とあわせて良い反響を得ることができました。
調整たいへんそうだけど良いアイデアですよね〜。 #iosdc https://t.co/xF5pM1HqVL
— Tomoki Hasegawa (@tomzoh) 2025年9月29日
単なるノベルティ配布にとどまらず、Yappli で制作されたクライアントのアプリを通して、プロダクトの表現力や事業の広がりを来場者に感じてもらえた点も効果的でした。
リアルな場でのコミュニケーションと、オンラインでの情報拡散をうまく組み合わせた取り組みとして手応えを感じています。
レギュラートーク：カスタムUIを作る覚悟
まず取り上げたいのは、まつじさんの「カスタムUIを作る覚悟」というメッセージが強く印象に残ったセッションです。
カスタムUIを作る覚悟 by まつじ | トーク | iOSDC Japan 2025 #iosdc – fortee.jp
標準 API で期待する UI 表現ができないからカスタム UI を採用しよう、とすぐに考えてしまう思考を一新するセッション内容でした。
カスタムUIを採用すると自由度は高まる一方で、標準 API が対応している
- ダイナミックタイプ
- 多言語対応
- VoiceOver
- ラージコンテンツビューワー（長押しで説明と画像を表示できる）
etc..
といった様々な機能を自前で実装することになります。
それを踏まえると、「一部のデザイン差分をなくすためにカスタムUIを採用することは本当に適切か？」という思考を持つことが重要になってくるかと思います。
標準APIで提供されている様々なユーザー体験を犠牲にするかもしれず、またそれを補うための開発コストに見合う効果はないかもしれない、と考えていくことが大切だとセッションを通して改めて感じました。
他にもセッションでは、どういう場合にカスタムUIを作るべきか、そしてデザイナーとエンジニアでどういった役割を持って議論を進めていくべきかが整理して紹介されています。
特に「UIデザイナーとエンジニアで境界を引きすぎない」という視点は、エンジニアだけでなく PdM やデザイナーにとっても大きな学びになる内容だと感じました。
レギュラートーク：作って学ぶWebP入門
次は、ヤプリの岸川さん（kishikawa katsumi）のセッションです。
作って学ぶWebP入門 by 岸川克己 | トーク | iOSDC Japan 2025 #iosdc – fortee.jp
WebP という画像に対する高品質な圧縮を実現する形式について、フォーマットから圧縮の仕組みまでわかりやすく解説されています。
圧縮の仕組みは、「どうやって思いつくんだろう…」という驚きと共に、「そうやって圧縮されていたのか！」という感動があり、非常に楽しい内容でした。
（昔読んだ、世界でもっとも強力な9のアルゴリズムでも感じたが、アルゴリズムは興味深くて面白いですね）
ハフマン符号化について
WebP 圧縮に利用されている方法の一つであるハフマン符号化について、自身の理解の限りでざっくりご紹介したいと思います。
例えば、以下のような並びのデータがあるケースから考えてみましょう。
AAAAABBCC（9文字）
圧縮なし（ASCII 表現）
アルファベットの並びなので、まずは圧縮なしでASCII 表現で考えてみます。
そうすると、ASCII ではアルファベット1文字は全て8ビット（= 1バイト）で表現されます。
そのため、文字数は9文字であることを踏まえると、9文字 × 8ビット = 72ビットが必要になります。
圧縮あり（ハフマン符号化）
ハフマン符号化では、ASCII のようにあらかじめ決められた文字コードに変換するのではなく、データにある頻度が高いものを短い符号に割り当てることでデータ量を削減します。
AAAAABBCC（Aが5回、Bが2回、Cが2回）
最も頻度が高い「A」を1、次に多い「B」を00、「C」を01というように割り当てると、次のようになります。
そうすると、ASCII 表現では72ビット必要だったものが、13ビット（約82%減）まで削減できています。
共通の割り当て表（文字コード）を持つASCII表現と異なり、ハフマン符号化したデータを元に戻す（復号する）には、この割り当てのルールを記した表も必要になりますが、それでも圧縮効果を考えると遥かにデータ量を削減できるということですね。
頻度の計算や割り当てはハフマン木というデータ構造を作って行うのですが、その詳細についてはセッションで順を追って解説されていますので、ぜひそちらをご覧ください。
セッションにある実装
WebP を実際に作成する実装については、GitHub で公開されています。
ご興味ある方は、この実装を読むことでより深い理解に繋げていただけるかと思います。（自身も理解度チェックかねて読んでみてます）
最後に
iOSDC Japan 2025 では、技術的な学びに加えて、チームや企業としての新しい挑戦も数多く得ることができました。
オンライン参加も含めて今年で4回目の参加でしたが、変わらず iOS エンジニアを続けられていることに幸せを感じます。
来年もまた、新しい知見や仲間と出会える場として参加できることを楽しみにしています！
ヤプリでは、iOSDCのようなカンファレンスへの参加も積極的にサポートしています。ご興味がある方は、ぜひ一度カジュアル面談でお話ししましょう！
コメント