WWDC25:開幕、基調講演の感想

今年もWWDCの季節がやってきた。例年と変わらず、2時前に起きて基調講演をリアルタイム(録画だが)で視聴し、5時からの Platforms State of the Union もチェックした。

筆者のWWDC初日の楽しみ方は、前夜から始まっている。コンビニでお菓子など買っておき、早めに就寝。といってもすんなり寝付けた試しはなく、だいたい眠れたかどうか分からないまま、午前 1:45 のアラームで起床。前夜に揃えた食べ物飲み物を準備して、ストリーミングを画面を前に待機、、例年、基調講演は iPad やデスクのモニターに映すのだが、今年は Vision Pro 上で観てみた。WWDC24 期間後に販売開始されたので、初の試みである。

WWDC keynote on Vision Pro

基調講演中は自分用に気になった点をメモしている。外部公開用ではないので、本当に個人的な感想や妄想を書き記している。今年は Vision Pro を被りながらなので、視界の下隅で MacBook の画面を見ながら映像とメモとを行き来してた。基調講演後は、気になったスライドやシーンを写真やスクショにおさめて、それらを日記にまとめるまでが、初日のルーチンになっている。

今年も例に違わず、仕事以外の時間はそんなことをして過ごした初日だった。特に今年は、かねてより噂されていたデザイン刷新をはじめ内容が盛りだくさんだった。


とはいえその大半が、Marc Gurman 氏によって事前にリークされた情報通りであった。日が近づくにつれてリークの頻度とディティールが増していったため、当日はただの答え合わせだけになってツマらないかも、と懸念していたが、蓋を開けるとそれはまったくの杞憂だった。今回の基調講演の内容には、そんな暴かれた筋書きを凌駕するサプライズが詰まっていた。

まず、新デザイン言語の Liquid Glass について。グラス調UIへの転換は今日を迎えるまで数々のリークやモックがインターネット上で量産され続けてきたが、蓋を開けてみればそのすべてが、実際のほんの表面しかなぞらえていなかったことが明らかになった。誰の想像をも圧倒する美しさ、完成度を Liquid Glass は携えていた。

「グラス」モーフィズムとは、iOSのデザイン刷新が噂にのぼるたび、それがいつからか思い出せないほどに長い間ささやかれ続けてきた言葉だが、liquid の名が示すように、このデザイン言語が示したのは只の見た目やあしらいではなかった。実際に beta 版を触ってみて感じたのは、どんなユーザー操作も逃さずにフィードバックしてくれるUIの即応性、それは指によるタッチやドラッグ操作に限らず、アイコンなどのエッジに輝くハイライトがデバイス本体の傾きに追従することも含む。従来スクリーンがアプリ世界だけを映し出していたのに対して、Liquid Glass の表現する世界観は、アプリという物体を如何に実世界に溶け込ませるか、であると感じる。それはまるで visionOS が仮想コンテンツをリアル空間に持ち出したように。そしてこうした視覚的な変化に加えて Liquid Glass の実現した高い精度の光学的表現が、ソフトウェアへ実存感を与えるにとどまらず、むしろ現実を超えてシュールささえもたらすことで、親しみや楽しみを醸成していると感じた。

そういえば、最近気に入ったアプリ、(Not Boring) Camera も、物理を模したUIの影が、デバイス傾きに追従している。

https://twitter.com/p0dee/status/1930867577104044193

いっぽうで今、Xをはじめとして Liquid Glass は手離しで評価されているわけではない。特にグラスマテリアルはその背景に対しコントラスト比が低く視認性が悪い。betaを触っていて、筆者はあまり気にならないが、アクセシビリティの観点では確かに片手落ちに感じた。が、iOS 7の時もそうであったように、Apple は初版ではコンセプチュアルな方向に振り切りつつもマイナーチェンジを重ねながら実用性に擦り合わせていく傾向があると思っているので(Apple Watch や Vision Pro もそう)、9月のリリースには致命的な点は解消されていると思う。

視認性や統一性の課題やバグを多く含み、混迷を極めた iOS 7 の初期 beta

その他、iPadOS の macOS 回帰が印象的で、macOS ではおなじみの Exposé 搭載が今このタイミングで発表されたことは、同機能がリリースされた Mac OS X 1.03 からたどった進化の系譜を20年越しに引き継いだという歴史の重みを感じて心が熱くなったし、ここ近年 iPadOS や macOS にばらばらと搭載され無秩序に感じていた、ウインドウマネジメントシステムの数々が、ようやく秩序だって集結したことにも、これまでの「仕込み」の点同士が一気に像を描くようで強く納得感を覚えた。さすがアップルだな、、と。

iOS 18 における Control Center のリデザイン、Apple Intelligence のチグハグ感否めない独特なデザインや使い勝手、唐突なホーム画面のカスタマイズ機能、少し遡るとこれもまた独特な使い勝手の Widget 選択画面に至るまで、、あちこちに散りばめられていたパズルのピースが、すべてこの日のために用意されていたと思うのは、考え過ぎだろうか。

まだ他にもある。macOS の Spotlight 機能が高機能化したのは、⌘+space が手癖となっている Spotlight ヘビーユーザーの筆者としては嬉しいポイント。作業コンテクストに応じてショートカットコマンドを組み込む Quick keys は、Spotlight という羊の皮を被った Shortcuts ないし Apple Intelligence ではなかろうかと思っている笑 完全に、Alfred に代表される 3rd-party ロンチャーアプリキラーだった。

あと、Xcode へのコーディングエージェントの搭載は、筆者が感知した範囲ではリークになかったので、個人的には実質の One more thing… であった。


手元メモにはもっと雑多にいろんな感想を記しているが、キリがないのでここまでとする。最後に基調講演の締めに流れた「Real App Store review」について。レビューを歌に乗せて紹介するというユニークな演出だが、可笑しさとともに Apple の一貫したある姿勢を垣間見て素晴らしいなと思った。 AI が発展し続けるこの先も、作り手である人間が価値創出の中心である、、そんなクリエイターに対する賛美だと感じた。

と、、Apple 信者感全開な投稿になったが、本当は1日1セッション紹介しようと思いつつもまだ何も観れておらず、ありものの情報で書いただけである。明日からはしばらくセッションの内容メモを綴っていきたいと考えている。

聴講メモ:CA.aab #6

Android エンジニアに転身したのもあり、会場に来てみた。ひとつひとつの取り組みが大きく聴き応えがあった。AIエージェントをQAテスト自動化に活用するユースケースはナルホド感ありとても興味惹かれた。画像ベースのE2Eテストは構築コストもメンテコストも掛かるイメージなので、試験項目書に基づく指示通り&実質目視でテストしてくれる未来が来て欲しいし、AIエージェントとの相性も良いと思った。

イベントページ:https://cyberagent.connpass.com/event/353611/


RemoteBuildCacheの導入とビルド時間メトリクス計測のススメ

@zume_poposora さん

  • ビルド時間計測のメトリクス構築
    • ビルド時間の課題:開発生産性体験の悪化、CIコスト増大
    • メトリクス構築 → ボトルネック発見、進捗可視化、改善サイクルの確立
    • measure-builds-gradle-plugin (Automattic) を使用
      • 外部サービスに収集データや分析情報を送信
    • ビルド時間 アーキテクチャ OS情報、ビルド成否、gradle 設定情報 → 環境情報を取得送信することでビルド時間との相関性調査に
    • ローカルビルドキャッシュだけでは効率化に限界(以下ABEMA例)
      • CI runner が分かれており環境ごとでしかキャッシュ活かせない
      • M3/M4 などでもフルビルド2,30分かかり生産性下げている
    • リモートキャッシュにより:
      • 他の開発者のローカルPCでも使えるようにした
      • 大規模やマルチモジュール構成に対し恩恵大きい
  • RBCの導入
    • gcp-gradle-build-cache でリモートキャッシュを導入
      • 導入の前提条件の説明(何が必要か、セキュアの担保)
      • リージョン指定の必要性、キャッシュの自動削除設定について
  • RBCの効果
    • 定性的に「かなり早くなった」
    • 運用費:ABEMA規模でも1万円程度(CIも安くなるので十分payできる)

縦横無尽に駆け回るフォーカスをユーザーフレンドリーに制御する feat. Compose for TV

@taked_oO さん

“聴講メモ:CA.aab #6” の続きを読む

聴講メモ:Mobile勉強会 #20 ウォンテッドリー × チームラボ × Sansan

コーディングエージェント(AI)による開発の話が3割で時代の流れを感じた。が、がっつりプロダクト開発現場におけるの知見というより、まだ個人利用でのノウハウが中心(開発現場での知見は、AI専門の勉強会の方で聞けるイメージ)。Animatable や Metal などUI開発系の話は作例も見れて楽しい。懇親会でも終始、各社/個人のAI活用について(Devin や Cursor の使い分けなど)情報交換ができて参考になった。Devin について各社どれくらいACUを消費しているのか気になったが、聞き出せなかった。

個人的に深く共感した点として、堤さん発表で言及されていた、0→1が苦手な人間の性質を逆手に取り、AIに任せてしまう、はまさに初手で年々腰が重くなる筆者が同じことを考えており、人間の元来もつ(負の)性質をAIでカバーすることで、いかにして人間の本質であるクリエイティビティを解放するか?そこに夢を見ていきたいと思った。

イベントページ:https://wantedly.connpass.com/event/350442/


SwiftUIにおけるPreferenceの基礎概念

ウォンテッドリー/湊 さん

  • Preference とは
    • 子→親 の情報伝達
    • Binding Environment との比較解説
  • 活用事例
    • 下スクロールでボタン非表示:子ビューで発生したスクロールイベントを親に伝達

入社初期に意識した3つの取り組み

@hikaengineer さん

“聴講メモ:Mobile勉強会 #20 ウォンテッドリー × チームラボ × Sansan” の続きを読む

聴講メモ:Sansan×DMM.com Android Tech Talk

今月から Android 開発の担当もすることになり、勉強し始めたところ。Android のみの勉強会参加は今回が初めて。Google Codelabs で勉強したことが実際にキーワードとして登場するので、あらためて理解が深まった。

イベントページ:https://sansan.connpass.com/event/349010/


CodeRabbitと過ごした1ヶ月 ─ AIコードレビュー導入で実感したチーム開発の進化

mitohato14 さん

  • CodeRabbit 導入の経緯
    • メンバー全員の approveでマージ、朝夕口頭レビュータイム
    • レビューは細かい指摘多め、細かい部分見落としがち、品質が人に依存
    • 時間が掛かり、細かい指摘は相互に負担増
  • CodeRabbitとは
    • リポジトリ全体を考慮したレビュー
    • 概要生成、シーケンス図作成、類似リポジトリ列挙やチャット機能
    • チャットの過去やり取りは将来にも持ち越されどんどんレベルアップ
  • CodeRabbitの設定
    • GitHub アカウントログイン、ダッシュボードで有効化
    • すぐに使える、yaml で追加設定
      • instrucrions でレビュー観点を自然言語で記述可能
  • 導入しての所感
    • PR内容の要約:どのファイルがどういった内容で、まで一覧化
    • シーケンス図の生成:レビューがしやすくなる
    • 不要な指摘は、チャットでフィードバックすることで抑制可能
    • (具体的な指摘内容はスライド参照)
  • 嬉しかったこと
    • 変更要約、チャット形式でのやり取り、レビューの早さ(数秒)
    • やりとりを通じ、背景や議論をログに残せる
    • 人力レビュー前に細かい問題を減らせる
  • 変化したこと
    • 細かい指摘が減り、広い視点での実装改善レビューが可能に
    • 指摘から気づきや議論が生まれる
  • Kotlin/Android 的な指摘
    • あった(スライド参照)

AndroidアプリエンジニアもMCPを触ろう

@kgmyshin さん

“聴講メモ:Sansan×DMM.com Android Tech Talk” の続きを読む

try! Swift Tokyo 2025 にスタッフ参加した話

プログラミング言語 Swift の国際カンファレンス、try! Swift Tokyo が今年も開催された。2016年の初開催以来、コロナ禍で開催が中止されていた数年を除き毎年皆勤であった筆者が、今年は当日スタッフとして参加した。

今年の try! Swift に関しても、開催が決定した時点で参加するつもりではいたし、現職がカンファレンス参加に寛容で、全日程全日参加もふたつ返事で OK だった。が、同僚後輩と押し並べて同じセッションを聴講するくらいなら、インプットは他に任せて自分は別の角度からカンファレンスを楽しんでみたい、と考えたのがスタッフ参加のきっかけだった。

実は 2018年のiOSDC で一度、当日スタッフを経験しており、とにかく日々ハードワークでへとへとだったのだが、一方で充実感も大きく、もう一度やってみたいと年々思っていたのだった。しかしその翌年以降、コロナ禍を挟みカンファレンス自体が中止またはオンラインへ移行したり、私情では転職を経て業務ががらりと変わったり、ポジションが変わったりと環境の変化が続き、次第にモチベーションも薄れていったのだった。(昨年の try! Swift に至っては、商談やマネージャー業務と両立するために、会場と会社とを行き来しながら参加していて、参加した記憶があまりない)

それが昨年秋に転職したことで時間的にも精神的にも余裕が生まれ、ふたたび当日スタッフに手を挙げることができた。国際カンファレンスである try! Swift には世界中から開発者が集まることから、英語を話す機会が多分にあるだろうという期待も、動機としておおきかった。


さて、スタッフとしては主に受付を担当し、たくさんの思い出をここに書き綴ろうと思っていた(し、下書きもしていた)のだが、結局会社 note の記事が先に公開されたので、リンク掲載にとどめておく。

作り手として見たtry! Swift──当日スタッフとして関わるということ|RIZAPテクノロジーズ株式会社

自分語り:ビッグバンドに入団した話

以前、イントロという店にジャズの演奏をしに、脚繁く通い続けていることについて書いた。あれから4ヶ月弱、今度はビッグバンドに入団することになったので、その経緯を書き残しておく。

イントロの頻度は落ちたものの、相変わらず毎週どこかのセッションには通い続けていて、アドリブでこなすことにはすっかり慣れてきた(それこそロストをすることも、急にアドリブソロを振られて慌てふためくことも滅多になくなった)。今年に入ってからは褒められることがあったり、逆にダメだしを食らうこともあったりと一進一退。自分の思い描く音楽的な成長とは、いつまで経っても程遠い。

セッション演奏に感じる課題として、その場の構成メンバー・選曲という仕組み上、数こそこなせても1曲1曲を深められない点がある。しかし根本的には、飽きるほど練習したフレーズですら客前に立つと頭に浮かびもしない自分の技量では、良い演奏(それも自分基準)の再現性は著しく低いので、仮に満足いく演奏ができたとしても、それを振り返って何が奏功したのかは分析しづらい(大抵はプロの共演者が底上げしてくれたことによる錯覚でしかなかったりする)。そんなフラストレーションの打開策のひとつとして、去年末から検討していたのがビッグバンドへの入団だった。

ビッグバンドで活動するアマチュアは決して珍しくないので、ジャズをやっていると自然と話を聞く機会はあるし、時には誘われることもある。が、そもそも大編成のバンドに興味はなかったし(吹奏楽みたいだし)、週末月2回の練習のために定期かつ長期で予定をおさえなければならないこともハードルが高く、現実的に検討したことはこれまでなかった。

が、今の自分の状況と照らし合わせてみると、同じバンドメンバーと、同じセットリストを本番演奏に向けて繰り返し練習し、曲そのものやジャズへの理解を深める場としては当然魅力的だし、大きなアンサンブルの中に身を置くことで、曲に対する分析や自パートに対する客観視をいちメンバーとして求められ(多分)、結果として音楽的に成長できるのではないか、、と捉え直しはじめていた。

そもそもジャムセッションで演奏するようなモダンジャズの歴史的源流には、ビッグバンドやスイングジャズがあるという理解なので、ビッグバンドを知ることとジャズを知ることとは、切っても切り離せないという気づきもあった。

“自分語り:ビッグバンドに入団した話” の続きを読む

聴講メモ:CA.swift #22 〜Swiftの進化を活かした技術基盤への挑戦〜

設計実装のみならず技術浸透のための取り組みも含めて解像度高く紹介されており、どのプレゼンも非常に濃い内容だった。ひとつめのTCAに関するプレゼンは、すでに自社プロダクトにTCAを導入している身としては復習要素もありつつ、Reducerの採用/非採用について感覚的だった部分が言語化されていたため、学びになった。

イベントページ:https://cyberagent.connpass.com/event/342952/


The Composable Architecture (TCA) を用いたAmebaのリアーキテクチャ

@devdazy さん

  • 従来:MVVM + RxSwift、VMは状態持たずデータを流すハブだけ
  • 課題:ロジックの複雑さ。モデル肥大化、可読性低下、保守性拡張性の低下とともに開発速度が低下
  • VM が状態を保持せず SwiftUI と相性悪い、RxSwift 依存が Concurrency と相性悪
  • TCA の概要
  • メリット・デメリット
    • Good:ロジックが明確になり、見通しが良くなる
      • すべてのイベントが列挙される。非同期処理のEffectで状態更新できないため、成功失敗を網羅的に書かざるを得ない
      • テストの網羅生にもつながる
      • e.g. 読み込みだけでなく、読み込み完了後の処理もテスト書かなければ失敗する
    • Good:画面遷移をシームレスに移行できる
      • SwiftUI → UIViewControllerへの遷移
      • TCA x UIKitでは、ほとんど SwiftUI と同じインターフェイスで実現できる
    • Good:ロジック分割が簡単にできる
      • ロジックである Reducer を別の Reducer に分割・合成したりできる
      • Action / State は親からも観測できる
    • Bad:学習コストが高い
      • フレームワーク丸々ひとつに対する理解が必要
      • TCA独自の記法
      • 例を作り、マイグレーションドキュメントを作り、テンプレ機能を活用する
    • Bad:パフォーマンスが最良ではない
      • Reducer を分割しやすい反面、不要な View にも Reducerをつけがち。(Action送る処理は負荷が高い)
      • Action を極力減らすよう吟味が必要
      • View 側での処理完結も選択肢に
    • Bad:Point Freeに依存
      • RxSwiftの例に同じ
    • 記法のブレがかなり抑制されるのは Good

Q&A

  • 分割粒度について:画面の量にもよるが、スクロールしない画面では基本的に1画面 1 Reducer だが、セクション持つような単位ではセクションごとに分割する
  • ロジック持たない限りは Reducer 持たせない(ボタン置いてあるだけとか)、通信して自身を更新するばあいは Reducer を持たせる

SwiftUI導入から1年、SwiftUI導入とVueFluxライクな状態管理

@TyrionJP さん

“聴講メモ:CA.swift #22 〜Swiftの進化を活かした技術基盤への挑戦〜” の続きを読む

聴講メモ:potatotips #90 iOS/Android開発Tips共有会

同僚と物理参加。ネイティブアプリへのFlutter組み込みで、Add-to-app の存在は知っていたが具体的な手法を知れて良かったし懇親会でも詳しく話を聞くことができた。ほかiOSDC運営の方ともお話しでき、今年のiOSDCでは5、6年ぶりに当日スタッフで参加しようかと考えていたところなので、その熱意をお伝えした。

イベントページ:https://potatotips.connpass.com/event/341264/


Flutter の Add-to-app でナビゲーションスタックが Flutter → ネイティブ → Flutter になってしまう場合の技術選定事例

@tfandkusu さん

  • Add-to-app : ネイティブの一部だけをFlutter実装
  • 3つの概念
    • FlutterEngine:ネイティブから作成、複数可
    • FlutterFragment (or FlutterViewController)
    • MethodChannle:ネイティブ間との情報受け渡し
  • 2つの問題
    • 以前の表示が一瞬残る
    • 1つのFlutterEngine x 複数の FlutterFragment で古い方が真っ白
  • 解決方法:FlutterFragment の付け外しをせず複数使う
    • アプリの性質上 Fragment 間の連携なさそうだったのでOK

iOSアプリの定期リリースとそのための自動化

@hiragram さん

“聴講メモ:potatotips #90 iOS/Android開発Tips共有会” の続きを読む

聴講メモ:Sansan x DMM.swift

大規模なSwift移行プロジェクトから、最新のiPadOS対応のテクニックまで。
Pro SwiftUIは、発表を聞くに4、5年前に読んだ「Thinking in SwiftUI」と重なる内容も多いと推測されるが、あらためて最新情報を体系的に学びたいため、プレゼン終わり即購入した。

イベントページ:https://dmm.connpass.com/event/336359/


DMMオンラインサロンのSwift移行

大門 弘明 さん

  • SwiftUI アプリで Redux を採用
    • VIPER での課題を解決したい
    • RN 時代の設計を流用、宣言的 UI や SSOT な状態管理を実現したい
  • Redux を SwiftUI でどう実装したか
    • Redux+Saga
    • SelectStateUseDispatch
  • 状態の更新が View に即座反映され、共通処理の一元化ができるようになった
  • 処理順序が旧アプリと同じのため、移行時にビジネスロジックの考慮漏れを防げた
    • が、同時にイケてない部分の解消ができなかった
  • パフォーマンスに課題があり(メモ化検討)

Q&A

  • TCA 採用に至らなかった理由
    • 流行り始めたのが Swift 化のあと、キャッチアップに時間が掛かる
    • 外部ライブラリへの依存をしたくなかった(RxSwift の二の舞)
    • Redux であれば Web でも使っているし、薄く作れるものとして採用
  • 既存実装の再利用について
    • アーキテクチャは全て捨てたが、API クライアントやコンポーネントなどは再利用した

DMMブックスへのTipKit導入

宗像 恒 さん

“聴講メモ:Sansan x DMM.swift” の続きを読む

聴講メモ:Ebisu.mobile #8 大忘年会 STORES kubell Kyash asken

良いユニットテストの書き方、イベントログの確認方法とaskenさんおふたりの発表内容が自社課題にダイレクトヒットして明日から実践したいと思える内容だった。失敗談から導かれた「コト」に向かう組織作りの取り組みも、目指したい効果に立ち返ってトライしたいと思った。

イベントページ:https://hey.connpass.com/event/335971/


開発生産性から振り返るエンジニアリングマネジメントの失敗2選

@sudo5in5k さん

  • Four Keys の計測結果から得られたEMとしての失敗
  • ドメイン知識に対するメンバー間の知識差から、組織体制変更の影響が発生 → 誰が欠けても生産性を出し続ける仕組みづくり
  • 組織で「コト」へ向かうために
    • モブプロ/ドキュメント作成/プロセス標準化(担当が変わっても取り組めるくらい丁寧に。チケット、PR、docs)
  • Four Keys 測定意図のすり合わせ
    • 本来の意図は健康状態の測定だったが手段と目的が逆転
    • 共通理解・共通価値観の設定が大事 → パフォーマンスを出すにはケイパビリティを変えよ(DORA Core Model から)
  • 個人の価値観にブレはあるが、会社のバリューは絶対的価値観
    • バリューに即した価値観や行動の洗い出し

いいね問題に対する技術選定事例

@tfandkusu さん

“聴講メモ:Ebisu.mobile #8 大忘年会 STORES kubell Kyash asken” の続きを読む

This website stores cookies on your computer. These cookies are used to provide a more personalized experience and to track your whereabouts around our website in compliance with the European General Data Protection Regulation. If you decide to to opt-out of any future tracking, a cookie will be setup in your browser to remember this choice for one year.

Accept or Deny