Liquid Glass(物理)を購入した

先日の Recap イベントで、temoki さんによって紹介され界隈をどよめかせた、Liquid Glass もどきのガラスペーパーウェイトをようやく手にすることができた。

Amazon にて購入。実は、このペーパーウェイトが紹介されたLTの間に楽天で注文したのだが、欠品連絡があり、しばらく後に再注文したのだった。

誌面の上にペーパーウェイトを乗せてみた

この写真のとおり、垂直に見下ろすと確かにレンズ効果で湾曲して見えるけれど、それだけだとイマイチ Liquid Glass 感がない。一体何が足りないのかと、ズラしてみたり、敷くもの(コンテンツレイヤー)を文字から写真に替えてみたり、試行錯誤の末ふと仰角を浅く覗いてみたところ、黒い印字が虹のようにスペクトラムに分解されて映ることを発見。これこそが Liquid Glass らしさだと気がついた。

ガラスの境界線付近で、黒文字が虹色に分解されている

このドーム状のペーパーウェイトのように、ガラスが設置面(コンテンツレイヤー)に対し垂直に切立つのでは、こうした視覚効果は生まれない。撥水面に垂らした液体のように断面が湾曲することで、色の分解が生み出されるのではないか、、実物(?)を観察したからこそ得られた発見だった。実際、Liquid Glass のイントロダクションビデオでデザインチームが扱っているガラスオブジェクトも、よく見るとそうした形状をしている。


余談だが、ペーパーウェイトの下敷き(コンテンツレイヤー)になっている雑誌は、Wallpaper 誌が Apple Design team を特集した2022年1月号。WWDC25 の基調講演で Liquid Glass を世に紹介した Alan Dye 氏も、もちろん文章と写真の両方で登場する。

Inside Apple Park: the design team shaping future tech | Wallpaper

聴講メモ:try! Swift Tokyo WWDC Recap 2025

今月何度目かわからなくなってきた、Apple Japan での Recap イベントに参加してきた。今回は、筆者も当日スタッフとして参加した try! Swift Tokyo 主催のもの。登壇は visionOS と Foundation Models のふたつとも筆者的関心の高いテーマでありがたかった。特に Foundation Models adapter training は未遂に終わっていたので、実際に触った所感を聞けたのが良かった。

タイムテーブルは筆者が確認していた限り直前まで公開されておらず、個人的に最もサプライズだったのは、 Swift Student Challenge に日本から入賞された学生さんがスピーカーとして登壇されたこと。Apple の Newsroom で取り上げられていたのを拝見していたので、すぐに分かった。入賞とひと言で言っても、世界 TOP50 に選出され WWDC に招待された上に、さらに11名だけが得られる Tim Cook へのピッチ機会も設けられた、とのこと。しかし彼のプレゼンを聞いていて、堂々とした語りと、なにより入賞した花札アプリのコンセプトが素晴らしく、これが世界レベルかと感動。ちなみに花札アプリは実際に触らせていただくこともできた。花札という古典ゲームにオリジナルの概念を盛り込んでいて、サウンドにも見た目にも細かな工夫が凝らしてあり、誰でも楽しみながら花札を覚えられるつくりとなっていた。

イベントページ:https://lu.ma/kd101ho8


visionOS 26 のアップデート内容と所感

satoshi さん

  • What’s new
    • Widget
    • instancing: メモリ効率がかなり上がった
  • 他セッション
  • 実機デモ
    • Enterprise APIでの両眼映像の取得
      • シェーダーを通したリアルタイム画像加工ができる(高速処理のためMetal使った)

Unleashing Foundation Models

shu223 さん

  • Tool calling
    • 制約:modalilty – multi-modal ではない
      • テキストのin/outのみ
      • 音声や画像の入出力はない → tool calling でやった
    • Tool calling の処理実装はなんでも実装可能
      • Speech + Image Playground
      • ツールとして渡しているだけなので、使わないという選択をモデルがすることもできる
        • → 画像生成を依頼しなければ使われない
  • Custom adapters
    • モバイルで動く小さめなモデル(Llama, Gemma の同程度のサイズのモデル)と比べてもやや劣る
    • Custom adapter で大幅に性能が向上した:すべてのベンチマークで、はるかに大きなモデルよりも優れた性能を発揮
      • GPT-4.1 や 4o を含む大規模モデルすらも超えるケースも
    • アダプター
      • 特定ケースにチューニングされた追加アダプター
        • e.g. .contentTagging
        • たくさんある?とおもっったら、general / contentTagging しかない
        • ほとんどのユースケースが、general に内包されている
          • tag, entity topic は tagging
    • 概要
      • LoRAを使用
      • ベースモデルの重みは固定し、アダプターの重みのみ更新
      • 必要なデータ量の目安
        • 単純タスク:100-1000 サンプル
        • 複雑タスク:5000サンプル以上
    • ツールキット
      • 必要なサンプルデータやコードが揃っている
      • .fmadapter ファイルがカスタムアダプターの実態
        • Xcode でプレビュー可能
    • Entitlement
      • アダプターのデプロイは、サイズがでかいのでバンドルするのではない、background assets フレームワークを使う
        • テストはアプリに組み込んでOK
    • サンプル(演劇)を使った学習結果のデモ
      • エポック(学習サイクル)を重ねるごとに、タグ構造を学習しフォーマットに沿った台本生成が可能になる(らしい)
      • 学習時間はMBPで10分程度:OSバージョンアップごとの再学習も現実的かも
  • Q&A
    • 回答のばらつきは temperature で指定可能
    • 基本メジャーバージョンごとにモデルが変わる sticky patch で上がることはない
      • 追従できなくてもアダプター自体は通るが、精度が落ちる

WWDC25:Automate your development process with the App Store Connect API

CI/CDにとどまらず、リリース情報、フィードバックの変更をトリガーにした自動化を加速できる。


0:00 – Introduction

  • App Store Connect は開発プロセス自動化のための多くの API を提供
  • 今年は app management や TestFlight など主要分野で API が大幅拡張
  • Webhooks API や Apple-Hosted Background Assets API など新機能も追加
  • Webhook 通知 Build upload API Feedback API などが開発サイクル高速化に寄与

1:56 – Webhook notifications

  • Webhook 通知によってイベント駆動型のワークフローを組むことができる
    • Webhook はサーバー間のプッシュ通信で イベント発生時に App Store Connect から HTTP コールバックを受け取る仕組み
    • Webhook listener の URL を App Store Connect に登録し イベント発生時に POST リクエストを受信
    • 通知 payload にはイベント情報が含まれ 必要に応じて追加 API コールも可能
  • Webhook 通知は Build upload state イベント, Feedback イベント, Build beta state イベントなど多様なイベントに対応
  • Webhook 設定は UI でも API でも可能 シークレットキーで署名検証もサポート
    • Integretions > Workfows の設定方法説明

6:50 – Build upload API

  • Build upload API でビルドのアップロード自動化が可能に
  • 任意の言語やプラットフォームから利用でき 柔軟な自動化が実現
  • BuildUploads を作成し build 情報を登録 → BuildUploadFiles でファイル詳細を通知 → 指示に従いバイナリをアップロード
  • アップロード完了後 PATCH リクエストで完了通知し App Store Connect がビルド処理を開始
  • Webhook 通知で処理完了を即時把握可能、署名検証で信頼性も確保

11:18 – Beta testing builds

  • TestFlight API でビルドのベータ配信も自動化可能
  • ビルドをテスターグループに割り当て、外部テスターには Beta App Review 提出も API で対応
  • Build Beta State Webhook event でベータ審査完了を即時通知
  • 通知 payload でビルド ID や状態を確認し次のステップへ進める

12:51 – Feedback API

  • TestFlight のフィードバック(スクリーンショットやクラッシュ)も API で取得可能
  • Webhook で新規フィードバック到着を即時検知しフィードバックの ID で詳細取得
  • Feedback API でデバイス情報やスクリーンショット URL などを取得 クラッシュログも API でダウンロード可能

15:05 – Additional development APIs

  • Apple-Hosted Background Asset 管理用 API も新登場
  • app version state webhook event で App Store 上の状態変化も通知
  • 既存の多様な API も活用し 開発からテスト リリースまで自動化可能

WWDC25:Customize your app for Assistive Access

先日の Recap イベントにて、LTのひとつで取り上げられていた Assistive Access。発表者の方とお話しし、超高齢化社会を迎えるこれからの日本でこそ有用な機能であると伺いなるほどと思った。Dynamic Type を使って文字を拡大して使われている方は多いが、一定大きくなると表示との整合性を取ることが難しくなる。一定以上の文字サイズ設定のレイアウトを Assistive Access と分離すると良いかもしれない。


0:00 – Welcome

  • Assistive Access は Apple が iOS と iPadOS で提供する 認知障害のある人向けのシンプルな体験
  • アプリやコントロールを本質に絞り込み 誰でも簡単かつ自立してデバイスを操作できるように設計されている
  • iOS と iPadOS 26 では Assistive Access scene type を使ってアプリをこの体験に統合できる

0:59 – Meet Assistive Access

  • Assistive Access は iOS と iPadOS 17 で導入された
  • 認知負荷を減らすために シンプルなインターフェースと一貫したデザインを提供
  • Camera や Messages などのビルトインアプリは 大きなコントロールや視覚的な要素を重視した共通スタイルを持つ
  • 最適化されていないアプリは 画面下部に常に表示される戻るボタンのために縮小フレームで表示される
  • 認知障害向けに設計されたアプリは UISupportsFullScreenInAssistiveAccess キーを Info.plist で true に設定することでフルスクリーン表示が可能
  • SwiftUI や UIKit で Assistive Access セッションの検出も可能
  • フルスクリーン対応アプリは Accessibility 設定の Optimized Apps リストに表示される
  • 一般的なアプリは iOS と iPadOS 26 で Assistive Access scene を作成し 専用の UI 体験を提供できる

4:09 – Create a scene

  • UISupportsAssistiveAccess キーを Info.plist に true で追加し Optimized Apps に表示されるようにする
  • Assistive Access scene を追加し シンプルな UI 階層を設計
  • Assistive Access で起動時 この scene がアタッチされる
  • SwiftUI コントロールは自動的に大きく明確なスタイルで表示され grid や row レイアウトも自動適用
  • SwiftUI preview macro で Assistive Access trait を渡してレイアウトをテスト可能
  • UIKit アプリでも SwiftUI scene を定義し scene delegate でアクティブ化できる

7:08 – Tailor your app

  • アプリの体験を本質に絞り込み 理解しやすくサポート的な UI を設計することが重要
  • 主要な1〜2機能に絞り 他の機能は Assistive Access 外で提供する
  • 画面上の選択肢や要素を減らし 誤操作や混乱を防ぐ
  • 隠れたジェスチャやネストした UI は避け 明確で目立つコントロールを使う
  • タイムアウトによる UI の自動消失や状態変化は避ける
  • ステップバイステップのガイドフローを設計し 一度に多くの選択肢を提示しない
  • 取り消しや削除など回復困難な操作は極力排除し 必要な場合は二重確認を行う
  • テキストだけでなく アイコンや画像など視覚的な情報も併用する
  • SwiftUI の assistive access navigation icon modifiers でナビゲーションタイトルにアイコンを追加
  • ユーザーからのフィードバックを重視し Assistive Access コミュニティでテストを行う

Foundation Models adapter training toolkit を試してみたが

結論から言えば、実行環境がツールキットの必要条件を満たしておらず失敗した。

Foundation Models adapter training – Apple Intelligence – Apple Developer

このページに説明がある通り、adapter training toolkit が必要とするマシンスペックはメモリ32GB。対して筆者私用の MacBook Air (M2) は16GBしか積んでいない、、

Requirements

  • Mac with Apple silicon and at least 32GB memory, or Linux GPU machines
  • Python 3.11 or later

ツールキットのセットアップ自体は、ページの手順に従って難なく完了したのだが、テストコマンド実行で失敗した。

adapter_training_toolkit % python -m examples.generate --prompt "Prompt here"
Traceback (most recent call last):

(省略)

RuntimeError: MPS backend out of memory (MPS allocated: 18.13 GB, other allocations: 384.00 KB, max allowed: 18.13 GB). Tried to allocate 16.00 MB on private pool. Use PYTORCH_MPS_HIGH_WATERMARK_RATIO=0.0 to disable upper limit for memory allocations (may cause system failure).

ChatGPT 先生によると、

メモリ 32 GB 推奨という前提に対して物理メモリ 16 GB の Mac で動かしている ことが、今回の MPS out-of-memory エラーの根本原因と考えてかまいません。

要素おおよそのメモリ消費
7 B パラメータ級モデル (FP16)7 B × 2 bytes ≒ 14 GB
ロード直後の重複バッファ(重み再配置や勾配用の一時領域)+2 〜 4 GB
トークン埋め込み/ KV キャッシュ(推論時)数百 MB 〜 数 GB (入力長/バッチで変動)
Python / PyTorch 自身・OS・他プロセス2 〜 4 GB

16 GB machines の場合、Unified Memory 全体が 16 GB = GPU が占有できる上限も 16 GB 未満 です。

PyTorch-MPS の既定 “high-watermark” が 90 % なので、確保できるのは最大でも ≈ 14.4 GB 程度。

上の表の時点でオーバーしており、転送途中でエラーになります。


Mac Studio 買うか、、

WWDC25:Wake up to the AlarmKit API

地味に反響の大きな AlarmKit について。筆者は10年以上前にポモドーロタイマーアプリをリリースしたことがあったが、ローカル通知頼りにならざるを得ず、体験的にイマイチだったし、通知が溜まりまくってカオスになってしまっていた。AlarmKit があれば、ポモドーロ以外にも細かなシーンを補えるので嬉しそう。(例えば筋トレアプリだとインターバルの残り時間とか)


0:00 – ようこそ

  • AlarmKit はアプリでアラームを作成できるフレームワーク
  • スケジュール型とカウントダウン型の2方式目立つアラートを提供
  • サイレントモードやフォーカスを突破してアラートを表示
  • カスタムアラームタイトルとアプリ名を表示し、停止やスヌーズ機能を提供
  • StandBy や Apple Watch でもサポート
  • Live Activities を使ったカスタムカウントダウンインターフェースも可能

0:32 – 概要

  • アラーム機能はユーザーが各アプリごとにオプトインで有効化
  • 許可は手動で要求するか、最初のアラーム作成時に自動要求
    • 設定アプリでいつでも許可状態を変更可能
    • NSAlarmKitUsageDescriptioninfo.plist に追加して使用目的を説明
    • AlarmManager.requestAuthorization() で手動許可要求
  • authorizationState で許可状態を確認してからアラームをスケジュール
    • 拒否時の制限明示も重要

1:39 – 作成

  • アラーム作成に必要な要素:
    • カウントダウン時間(pre-alert/post-alert duration)
    • スケジュール(固定日時または相対パターン)
    • 外観設定
    • カスタムアクション処理
    • 関連サウンド
  • スケジュールの指定:
    • 固定スケジュール:特定の未来日時を指定(タイムゾーン変更に影響されない)
    • 相対スケジュール:時刻と週次繰り返しパターンを指定(タイムゾーン変更に対応)
  • アラーム外観のカスタマイズ:
    • AlarmButton でボタンのテキスト、色、アイコンを設定
      • アイコン(SF Symbols)は Dynamic Island 表示に使用
    • AlarmPresentation でアラートタイトルを設定
    • AlarmAttributes でアラーム属性を設定
      • 表示のレンダリングに必要な情報
      • tintColor の設定:アラームとアプリの関連性を伝えるのに役立つ
    • AlarmConfiguration に、duration と attributes を含める
  • カウントダウン表示の設定:
    • 繰り返しボタンを AlarmPresentationsecondaryButton / scondaryButtonBehavior に指定 (.countdown)
    • Live Activities を使ったカウントダウン UI
      • Live Activity を Widget Extension に追加
    • 追加情報の表示設定:
      • AlarmMetadataAlarmAttributesmetadata に指定
      • Live Activity 側で context.attributes.metadata を抽出して表示に活用
    • カウントダウンインターフェイスの表示はシステムが保証:システム表示のカスタマイズ(一時停止/再開ボタン等)
  • カスタムアクション:
    • App Intent を使ったカスタムボタンアクション
    • アプリを開く、詳細表示等の処理
    • アラームに一意の識別子を定義して追跡できるようにする
  • サウンド設定:
    • デフォルトシステムサウンドまたはカスタムサウンド
    • ActivityKit の AlertSound 構造体を使用
      • サウンドファイルはメインバンドルか、Library/Sounds に格納

16:32 – ライフサイクル

  • AlarmManager クラスでアラームのライフサイクルを管理
  • 一意の識別子を使ってアラームを追跡
  • カウントダウン状態への移行、キャンセル、停止、一時停止、再開が可能
  • ベストプラクティス:
    • 特定間隔のカウントダウン(料理タイマー)や繰り返しアラート(目覚まし)に適している
    • 重要な通知や時間敏感な通知の代替ではない
    • アラート表示は明確で理解しやすく(何のアラームか、どのようなアクションが可能か)
    • Live Activities には残り時間、停止ボタン、一時停止/再開ボタンを含める

WWDC25:Meet PaperKit

新登場の PaperKit。がっつり UIKit ベースの実装で懐かしさを感じた。Apple Pencil 結局使いこなせていない、、空間アクセサリとして対応する日が来たら、また変わるのかもしれない。


0:00 – イントロダクション

  • PaperKit は Apple のシステム全体で使われているマークアップ体験を支えるフレームワーク
  • Notes やスクリーンショット、QuickLook、Journal アプリなどで利用
  • キャンバス上で描画や多様なマークアップ要素(図形、画像、テキストボックス等)を追加できる
  • macOS Tahoe でも同様のリッチなマークアップ体験を提供

1:36 – PaperKitの基本知識

  1. PaperKit の主な3コンポーネント
    1. PaperMarkupViewController:インタラクティブなマークアップ・描画の提供
    2. PaperMarkup:データモデルコンテナ・PaperKit マークアップ、PincilKit 描画データの保存・読み込み、レンダリング
    3. MarkupEditViewController or MarkupToolbarViewController(macOS):挿入メニュー

3:35 – PaperKitの導入

  • iOSアプリへの導入例:
    • UIViewControllerviewDidLoad() 内で PaperMarkupPaperMarkupViewController を初期化
      • PaperMarkup は初期化時に bounds を指定
    • PencilKit のツールピッカー(PKToolPicker)と連携し、ツールの表示や操作を制御
      • paperViewController と紐づけツールピッカーの状態変化に動的に応答
    • UIResponder.pencilKitResponderState.activeToolPicker / .toolPickerVisibility
    • アクセサリボタンから挿入メニューを呼び出し、マークアップ要素を追加
      • MarkupEditViewController
  • macOS アプリでも同様の手順で導入可能。ツールバーUIで挿入メニューを提供
  • SwiftUI 環境でも UI/NSViewControllerRepresentable で統合可能
  • デリゲートや Observable 対応で状態管理や自動保存も柔軟
  • ディスク読み込みのデータに対し、前方互換性のためコンテンツバージョンの検証が必要
    • 不一致時はアラートでアップグレードを訴求/あらかじめレンダリングされたサムネイル表示
    • PaperKit の前方互換性担保の仕組み:CGContextmarkupModel.draw(…)

8:37 – 機能セットのカスタマイズ

  • PaperKit の全機能は FeatureSet で管理
  • FeatureSet.latest で最新機能を一括利用可能
  • remove/insert で利用可能なツールやインクを細かく制御
  • HDR対応も可能(colorMaximumLinearExposure プロパティで設定)
  • カスタマイズした FeatureSet を各コントローラに適用し、アプリ全体で一貫した体験を実現
  • paperViewController.contentView のカスタマイズで独自テンプレートや背景も設定可能(カスタムビューを指定することで、マークアップの下のレイヤーとしてレンダリングされる)

WWDC25:Explore Swift and Java interoperability

先日の Recap イベント で知った SwiftJava について。

話されているこの方、try! Swift 2025 でもご登壇されていた。あいにく筆者はスタッフをしていたので聴講できなかったが、会場で何度もお見かけしていたので、サムネからすぐにピンときた。


0:00 – Introduction & Agenda

  • SwiftとJavaの相互運用(インターオペラビリティ)を紹介
  • Swiftを他言語の既存コードベースに段階的に導入できるメリット
    • 書き換えずそのままに、Swiftでの新しい機能追加や置き換えが可能
    • Swiftで多言語のライブラリ、多言語でSwiftのライブラリを利用可能
  • Swiftと他言語の連携は言語だけでなく、CMakeやGradleなど各エコシステムのビルドツールとも統合
  • SwiftのC言語はじめ多言語との相互運用の歴史
  • 相互運用の方向性:Java interoperability は両方向に対応
    • Call Java from Swift
    • Call Swift from Java

2:41 – Runtime differences

  • JavaとSwiftのランタイムの違いを解説
  • 両言語ともクラス継承、メモリ管理、ジェネリクス、例外処理など多くの共通点がある
  • 違いを意識しつつAPIを設計すれば、相互運用が可能

3:31 – Java Native methods

  • Java Native Interface(JNI)を使ったJavaからネイティブコード(Swift)呼び出しの仕組み
    • Java のネイティブメソッドは JNI API に含まれている
    • JNIは歴史が長く、パフォーマンス向上や既存ネイティブライブラリ利用のために使われる
  • ライブラリやツールを使わない従来手順で JNI を使うデモ
    • Java でネイティブ関数を定義、ネイティブコードを浸かって実装
    • 例では、Java オブジェクトである Integer を引数・戻り値に使用
    • Java コンパイラを使用:-h フラグ → Cヘッダーファイルが生成
      • JVM が呼び出すファイル
      • インターフェイスの命名が長い
    • これを Swift で実装
  • JNIの利用は手順が多く、Cヘッダーやシグネチャの一致などミスが起きやすい
  • オブジェクトのライフタイム管理も難しい

6:29 – SwiftJava

  • Swift と Java の相互運用を支援する新プロジェクト「SwiftJava」を紹介
    • Swift パッケージ(JavaKit)
    • Javaライブラリ(SwiftKit)
    • コマンドラインツール (swift-java) で構成
  • swift-java コマンドによる生成結果(Swift ファイル)
    • インポートされたJavaクラスの定義が含まれている
    • @JavaMethod マクロで示される Java 型のメンバーメソッド経由で、Swift コードからアクセスできる
    • JNIExampleNativeMethods プロトコル:C ヘッダの代わり
    • @JavaImplementation でネイティブ関数を実装。必要な関数シグネチャはコンパイラが実装
    • @JavaMethod マクロの関数定義内で、Swift コード/Swift ライブラリを利用した実装が可能
  • JNI の煩雑さを解消し、ボイラープレートを削減し、安全かつ効率的な連携を実現
  • SwiftJava を使うことで、型安全なコード生成やオブジェクト管理が容易に

10:13 – Call Java from Swift

  • Swift から Java ライブラリを利用する方法
  • Gradle 連携で Java の依存解決も自動化
  • 依存関係の3つの要素:Artifact ID, Group ID, Version をコロンで繋ぎ、 swift-java.config の dependencies に追加
  • Swift Package Manager プラグインやコマンドラインツールで Java ライブラリを Swift から簡単に呼び出せる(トレードオフあり)
    • swift build --disable-sandbox : セキュリティサンドボックス無効化が必要
    • swift-java resolve --module-name <module_name> : 依存関係の解決を手動起動する必要あり
  • JavaKit による JDK ラッパー型やオブジェクトのライフタイム管理もサポート
    • Swift プロセスで JVM 起動
      • let jvm = try JavaVirtualMachine.shared()

14:01 – Call Swift from Java

  • Java から Swift ライブラリを利用する方法
  • Swift の型や関数を Java クラスとして自動生成し、Java からシームレスに呼び出し可能
  • JNIではなく、Java 22 以降の Foreign Function and Memory API を活用
  • 例:struct SwiftyBusiness – 構造体定義で、プロパティ、イニシャライザ、メソッドを持つ
    • struct は値型で、安定したオブジェクトIDがない → Java オブジェクトで表現不可
    • swift-java コマンド:Swift 型ヘのアクセサである .java ファイル(Java クラス)生成
    • .swift も含めた .jar ファイルが生成
    • 構造体が Java クラスとして実装され、メソッドも Java シグネチャで定義される
      • 内部的に Foreign Function API でネイティブ呼び出しされる
  • Confined な SwiftArena(メモリ管理、有効期限管理)の使用で、安全かつ効率的なリソース解放を実現
    • SwiftArena.ofConfined() による、try-with-resource を使用したメモリ管理
    • GCに依存せず最善のパフォーマンスを実現可能

おまけ

ChatGPT が案出ししてくれた、SwiftJava の実験案10選。

iOS兼Androidアプリエンジニアとしては、Android 開発と連動できれば嬉しいが、、Kotlin が主流な昨今において果たして。Jetpack Compose のコード生成はできないと思う、、

1. “書いた Swift をそのまま Android でも”
  • ドメインロジックやアルゴリズムを Swift で実装し、SwiftJava CLI で Java ラッパを吐き出して Android に組み込む。Gradle が依存解決・ビルドを面倒見てくれるので iOS ⇄ Android の 100 % 共有コード が現実的に。 
2. Java ライブラリをサクッと呼ぶ Swift サーバー
  • Vapor や Hummingbird など Swift サーバーアプリから Apache Lucene/Kafka/Spark まで JAR ごとインポート。swift-java resolve がトランジティブ依存を丸ごと解決し、Swift 側は import JavaLucene で即検索エンジン化。 
3. Swift 製暗号モジュールを Java へ“輸出”
  • セキュアかつ GC フリーな Swift ライブラリを生成し、JVM とは Java 22 の Foreign Function & Memory API で橋渡し。Java 側は try-with-resources で自動メモリ管理、Swift 側は Arena で安全――金融/ブロックチェーン案件に映える。 
4. Jetpack Compose コンポーネントを Swift マクロで自動生成
  • SwiftUI ライクな DSL → マクロ展開で Compose UI を吐くツールチェインを自作。デザイナーが SwiftUI プレビューで確認 → ボタン一発で Android 版 UI を生成、という“プラットフォーム超えデザインシステム”を実現。
5. JVM 大規模データ処理をローカル ML 推論に転用
  • Java の Deeplearning4j モデルを iOS アプリに同梱し、Swift から呼び出して 完全オフラインの画像分類。モバイルでも GDPR/個人情報保護の要件をクリアしつつ高精度推論。
6. Minecraft/IntelliJ プラグインを Swift で書く
  • プラグイン API は Java だが、Swift 側でコアロジックを書くことで Swift Concurrency で並列 AIResult Builders で DSL などモダン機能をプラグインにも注入。
7. Spring Boot × Swift で“二刀流”マイクロサービス
  • コントローラ層は Java(Spring)、ドメイン層を Swift で実装。Swift の値型 & 不変データでビジネスロジックを堅牢にしつつ、既存の Spring インフラ(Actuator/Observability)をそのまま享受。
8. JUnit ↔︎ XCTest 相互呼び出しでクロスプラットフォーム CI
  • SwiftJava で JUnit テストから Swift の XCTest を直接呼び出し、“片方落ちたら両方真っ赤”な 一体化テストレポート を生成。モノレポの CI をシンプルに。
9. SwiftArena × Project Loom で“協調コルーチン”
  • Java 側の仮想スレッド(Loom)と Swift の Structured Concurrency を相互ラップし、クロスランタイムの高スループット IO を研究。フルスタック並列処理オタク歓喜。
10. “Swift 製 DSL→JVM バイトコード”コンパイラ
  • Swift Macro で DSL を解析、SwiftJava で ASM(Java バイトコード生成ライブラリ)を呼び出して ネイティブに JVM バイトコードを吐く。Swift 製ビルドツールやスクリプトエンジンだって夢じゃない。

Foundation Models は追加学習できるらしい

Foundation Models について、セッションメモや実践についていくつかまとめてきた。

これらを通して筆者は、Foundation Models のコンセプトは Apple の用意したモデルを受動的に使うもので、追加学習する方法は提供されていないものだと理解していた。実際、Foundation Models の API には、外部情報と連携する tool calling の仕組みはあっても、モデルをファインチューニングする手段は提供されていない。

それが、先日参加した WWDC25 Recap イベントにて、近くの方から「できる」という情報をいただいて驚いた。その後、Apple の Technology Evangelist の方にも確認したところ、やはりできるとのこと。以下のページにその手順がまとまっていると教えてくださった。

Foundation Models adapter training – Apple Intelligence – Apple Developer

Adapters are an advanced technique that *adapt* a large language model (LLM) with new skills or domains. With the adapter training toolkit, you can train adapters to specialize the on-device system LLM’s abilities, and then use your adapter with the Foundation Models framework.

トレーニングには Adapter training toolkit なるものを用いるらしい。ローカルマシンと Python コードでトレーニングしたり、別途 Entitlement をリクエストする必要があったり。マシンスペックもメモリ32GB以上とそれなり。事前学習させたモデルをアプリに組み込むので、例えばユーザー生成コンテンツをもとに Foundation Models のレスポンスを生成することはできないだろう。

Foundation Models は OS と共にバージョンアップされ続けるが、聞いた話ではその都度学習がリセットされ、その度に再学習させ直す必要があるとのこと。


ちなみに、このアダプターについてはセッション内に言及あったようで、それをいちからビデオを見直して探すのは大変なので、これまで見たセッションの transcript を溜めていたフォルダから Cursor に探させた。その答えが以下。

「Meet the Foundation Models framework」セッション

  • 該当箇所: 3:47〜3:57付近
  • 内容要約:
  • 「特定のユースケース(例:コンテンツタグ付け)向けに、モデルの能力を最大化するためのspecialized adapters(専用アダプター)を提供している」と明記。
  • さらに「今後もモデルを継続的に改善していく」と述べており、アダプターを使った拡張性やカスタマイズ性に触れています。
  • 原文抜粋:

> For certain common use cases, such as content tagging, we also provide specialized adapters that maximize the model’s capability in specific domains.

ついでに ChatGPT o3 に解説させた。

https://chatgpt.com/share/686d278b-cf78-8005-a273-061117f3d216

WWDC25:Create icons with Icon Composer

前回に続き、新たなアイコンデザインを出力するための Icon Composer の使い方。視覚的効果や配色は Icon Composer で完結。デザイナーがこのツールにキャッチアップするのももちろん良いが、開発者も触ってみてどのような調整が可能かを理解するのも重要そう。


0:51 – Overview

  • アイコン作成の歴史的変遷:従来は様々なサイズで作成が必要だったが、解像度向上によりひとつの解像度で完結するよう簡素化
  • 2025年、ダークモード・ティントモードの拡張により、再度プロセス簡素化の転換点
  • Icon Composer により、1つのファイルで全てのプラットフォーム・外観に対応可能
    • 図解的、複雑なアイコンは従来通り個別画像でXcodeにアップロード可能:鏡面ハイライトが自動適用
  • よりグラフィックなアイコンは Icon Composer で Liquid Glass の新機能を活用可能
    • アートワークひとつから、各プラットフォームで一貫したデザインが提供可能
    • 動的なグラスプロパティを活かした、リアルタイムな見た目の確認
    • 6種のアピアランスのチェック(Default, Dark, Clear light/dark,  Tinted light/dark)

3:55 – Design

  • ベクターツール(SVG出力可能)の使用を推奨
  • Apple Design Resources からアイコンテンプレート(Figma、Sketch、Photoshop、Illustrator対応)をダウンロード
    • iPhone、iPad、Mac は 1024px、Watch は 1088px のキャンバスサイズ
    • グリッドは共通、デザインの流用が容易
  • レイヤー設計:Z深度で背景から前面へ積層、色分けも重要
    • レイヤー分け、色分けをしておくと、Icon Composer でコントロール可能な幅が広がる
    • 例:Translate アイコンでは吹き出しとテキストを別レイヤーに分離 → レイヤごとのぼかし・影を、鏡面、透過度/不透明度と同様に、動的プロパティで設定
  • グラフィックエッセンスを重視(フラット、不透明、制御しやすい状態)

6:10 – Export Layers

  • レイヤーをSVG形式でエクスポート(Z順で番号付けしネーミング)
  • Illustrator 用のレイヤー → SVG自動変換スクリプトを提供。
  • 背景色・グラデーションは Icon Composer で直接追加するためエクスポート不要
  • テキストはアウトライン化してからエクスポート(SVGではフォント維持できない)
  • カスタムグラデーション・ラスター画像はPNG形式でエクスポート(透明な背景も維持可能)
  • 角丸矩形・円形マスクは含めない(後で自動トリミングされるため)

7:22 – Icon Composer

  • 3つのパネル構成:左側(キャンバス・グループ・レイヤー)、中央(プレビュー)、右側(インスペクター)。
  • 背景色設定:システムプリセット(最適化済み)またはカスタム色・グラデーション
  • グループ:最大4つまで(視覚的複雑さの適切な範囲)
  • 外観モード:Default、Dark、Mono
  • Liquid Glass プロパティ:レイヤーレベルとグループレベルで制御可能
  • プロパティ設定:外観別・全体共通の設定が可能
    • Color
    • Composition
    • モードを跨いで一貫性を保つために予備設定してあるが、詳細コントロールも可能
  • シャドウ:Neutral(汎用)とChromatic(色付き)から選択
    • CHromaticで、素材の明るさや物理特性が際立つ
  • Dark モード:フィル・不透明度・ブレンドモードの調整で最適化
  • Mono モード:少なくとも一番目立つ/みやすい要素を白に設定
  • プラットフォーム間調整:Watch 用の円形と他の角丸矩形の光学調整
    • Composition で円形に合うよう見た目の調整

13:16 – Delivery

  • .icon ファイルとして保存し、Xcode にドラッグ&ドロップ
  • プロジェクトエディターでアイコンを選択
  • ビルド・実行でプラットフォーム・外観への適応を確認
  • Icon Composer はベータ版で提供、Feedback Assistant でフィードバック可能