この記事は、Vue.js連載の4本目です。

はじめに

こんにちは。山本竜玄です。

モバイルアプリ開発と聞いて、どのような技術を思い浮かべるでしょうか。iOSならSwift、AndroidならKotlinといったネイティブ開発や、FlutterやReact Nativeといったクロスプラットフォームフレームワークが主流です。実際、2025年のクロスプラットフォーム市場ではFlutterが42%、React Nativeが38%のシェアを占めています¹。

一方で、Vue.jsでもモバイルアプリ開発ができることをご存知でしょうか。Webフロントエンド開発で人気のVue.jsですが、モバイルアプリ開発のフレームワークも複数存在します。既存のVue.jsスキルを活かしてモバイルアプリを開発できるため、Vue.jsの経験者が多いチームでは選択肢となりえます。

本記事では、2025年秋時点でのVue.jsモバイルアプリ開発フレームワークの状況を整理します。プロダクション環境で使える安定したフレームワークから、トレンド技術まで、調べた内容を紹介します。

Vue.jsモバイル開発の全体像

クロスプラットフォーム開発市場は急成長しています。2025年の市場規模は124.5億ドルで、2032年には369.2億ドルに達する見込みです²。

この市場の中で、Vue.jsはWebフロントエンド開発の人気フレームワークとして、モバイル開発にも選択肢を提供しています。FlutterやReact Nativeと比較すると、Vue.jsモバイルフレームワークの市場シェアは小さいものの、既存のWeb開発者チームでの有識者が多い場合には、モバイルアプリ開発への敷居が低いことは大きなメリットです。

本記事では、Vue.jsでモバイルアプリを開発できるフレームワークを調査し、以下のように紹介しています。

主要フレームワーク（4つ）

• Ionic Vue
• Capacitor + Vue
• NativeScript-Vue
• Quasar Framework

これらは継続的にメンテナンスされており、GitHubでも活発な開発が確認できます。

中国市場向け（1つ）

• uni-app

中国のDCloudが開発しており、WeChatなどのミニプログラムとネイティブアプリを同時展開できます。中国国内では900万人の開発者が利用しているらしいです³。

新技術（1つ）

• Lynx + Vue

2025年3月にByteDanceが発表したフレームワークです。TikTokやCapCutの技術スタックから生まれました。Vue統合はプロトタイプ段階ですが、今後の動向は注目したいです。

メンテナンス終了（3つ）

• Weex
• Vue Native
• Onsen UI

これらは開発が停止してます。

主要フレームワーク

主要な4つのフレームワークを紹介します。これらはいずれもVue 3に対応しており、GitHubで継続的に開発されています。

Ionic Vue

Ionicは、Web技術でネイティブアプリを構築するフレームワークです。2013年にAngular向けにスタートし、現在はVue、React、Angularをサポートしています。

基本情報

• 最新バージョン: v8.7.6（2025年10月）
• ライセンス: MIT
• GitHub: 52,101スター（2025年10月時点）⁴
• npm: 週間18,911ダウンロード⁵
• 公式サイト: https://ionicframework.com/docs/vue/overview

特徴

• iOS、Android、Webの3プラットフォーム対応
• Capacitorによるネイティブ機能アクセス
• Vue 3とComposition API対応
• Material DesignとiOSデザインの両対応
• UIコンポーネントライブラリを提供

プロジェクト作成

Ionic CLIを使用することで、すぐに開発を開始できます。

npm install -g @ionic/cli
ionic start myApp tabs --type vue
cd myApp
ionic serve

Vue.jsとの違い

Ionic Vueは、通常のVue.jsプロジェクトにモバイルアプリ特有の機能を追加します。主な違いは以下の3点です。

1. IonicVueプラグインの追加（main.ts）

import { createApp } from 'vue';
import { IonicVue } from '@ionic/vue';
import App from './App.vue';
import router from './router';

/* Core CSS required for Ionic components to work properly */
import '@ionic/vue/css/core.css';

/* Basic CSS for apps built with Ionic */
import '@ionic/vue/css/normalize.css';
import '@ionic/vue/css/structure.css';
import '@ionic/vue/css/typography.css';

/* Theme variables */
import './theme/variables.css';

const app = createApp(App)
  .use(IonicVue)
  .use(router);

router.isReady().then(() => {
  app.mount('#app');
});

2. IonRouterOutletの使用（App.vue）

IonRouterOutletは、複数のページを同じアウトレット内にレンダリングし、ページ遷移アニメーションとライフサイクルを管理します。

<template>
  <ion-app>
    <ion-router-outlet />
  </ion-app>
</template>

<script setup lang="ts">
import { IonApp, IonRouterOutlet } from '@ionic/vue';
</script>

3. @ionic/vue-routerの使用（router/index.ts）

Vue Routerをベースにしつつ、モバイルアプリ特有のページ遷移アニメーションとナビゲーションスタックを実現します。タブは個別のナビゲーションスタックとして扱われます。

import { createRouter, createWebHistory } from '@ionic/vue-router';
import { RouteRecordRaw } from 'vue-router';
import HomePage from '../views/HomePage.vue';

const routes: Array<RouteRecordRaw> = [
  {
    path: '/',
    redirect: '/home',
  },
  {
    path: '/home',
    name: 'Home',
    component: HomePage,
  },
];

const router = createRouter({
  history: createWebHistory(import.meta.env.BASE_URL),
  routes,
});

export default router;

ページコンポーネントの例

ページコンポーネントはIonPageをルート要素として使用します。以下はQuickstartで生成されるHomePage.vueの例です。

<template>
  <ion-page>
    <ion-header :translucent="true">
      <ion-toolbar>
        <ion-title>Blank</ion-title>
      </ion-toolbar>
    </ion-header>
    <ion-content :fullscreen="true">
      <ion-header collapse="condense">
        <ion-toolbar>
          <ion-title size="large">Blank</ion-title>
        </ion-toolbar>
      </ion-header>
      <div id="container">
        <strong>Ready to create an app?</strong>
        <p>
          Start with Ionic
          <a target="_blank" rel="noopener noreferrer" href="https://ionicframework.com/docs/components"
            >UI Components</a
          >
        </p>
      </div>
    </ion-content>
  </ion-page>
</template>

<script setup lang="ts">
import { IonContent, IonHeader, IonPage, IonTitle, IonToolbar } from '@ionic/vue';
</script>

collapse="condense"を使用すると、スクロール時に大きなタイトルが小さく折りたたまれるモバイル特有のUIを実現できます。

参考

• Ionic Vue Quickstart
• Ionic Vue Navigation
• Ionic Vue Overview

Capacitor + Vue

Capacitorは、既存のWebアプリをモバイルアプリに変換するためのランタイムです。Ionic VueもCapacitorを使用していますが、Ionic Vueが専用UIコンポーネントライブラリとセットになっているのに対し、Capacitor単体では既存のVue.jsアプリをそのままモバイル化できる点が特徴です。

基本情報

• 最新バージョン: v7.4.3（2025年10月）
• ライセンス: MIT
• GitHub: 14,200スター（2025年10月時点）⁶
• npm: 週間800,692ダウンロード⁷
• 公式サイト: https://capacitorjs.com/

特徴

• iOS、Android、Web、PWA対応
• 既存のVue.jsアプリをそのままモバイル化可能
• 35以上の公式プラグイン（Camera、Geolocation、Filesystemなど）
• Vite、Vue CLI、Nuxtなど主要ビルドツールに対応
• ネイティブコードとの共存が可能

プロジェクトへの追加

既存のVue.jsプロジェクトにCapacitorを追加する手順です。

npm install @capacitor/core @capacitor/cli
npx cap init [name] [id] --web-dir=dist

ビルド後、プラットフォームを追加します。

npm run build
npm i @capacitor/ios @capacitor/android
npx cap add android
npx cap add ios

Vue.jsでのネイティブAPI呼び出し

CapacitorのAPIは、Vue.jsのコンポーネント内でJavaScriptの標準的な非同期関数として呼び出せます。以下はGeolocation APIの例です。

import { Geolocation } from '@capacitor/geolocation';

const getCurrentPosition = async () => {
  const position = await Geolocation.getCurrentPosition();
  console.log('Current position:', position);
};

Camera APIを使った実装例です。

<script setup lang="ts">
import { ref } from 'vue';
import { Camera, CameraResultType } from '@capacitor/camera';

const imageUrl = ref('');

const capturePhoto = async () => {
  const photo = await Camera.getPhoto({
    quality: 90,
    allowEditing: true,
    resultType: CameraResultType.Uri
  });
  imageUrl.value = photo.webPath || '';
};
</script>

<template>
  <div>
    <button @click="capturePhoto">写真を撮影</button>
    <img v-if="imageUrl" :src="imageUrl" alt="撮影した写真" />
  </div>
</template>

参考

• Capacitor Documentation
• Using Capacitor with Vue
• Capacitor APIs

NativeScript-Vue

NativeScript-Vueは、WebViewを使用せず、真のネイティブUIコンポーネントでアプリを構築するフレームワークです。Vueのテンプレートは、iOSではUILabel、Androidではandroid.widget.TextViewといったネイティブコンポーネントに直接レンダリングされます。

基本情報

• 最新バージョン: v3.0.2（2025年10月17日）
• ライセンス: MIT
• GitHub: 5,900スター（2025年10月時点）⁸
• npm: 週間2,338ダウンロード⁹
• 公式サイト: https://nativescript-vue.org/

特徴

• iOS、Android対応
• WebViewを使用しない真のネイティブUI
• Vue 3完全対応（Options API、Composition API両対応）
• JavaScriptから全てのネイティブAPIに直接アクセス可能
• V8エンジンで実行される埋め込みJavaScript環境
• TypeScript対応の改善とモダンなプラグインシステム

プロジェクト作成

NativeScript CLIを使用してプロジェクトを作成します。

npm install -g nativescript
ns create myAwesomeApp --vue
cd myAwesomeApp
ns run ios
# または
ns run android

注: 2025年10月時点では--template @nativescript-vue/template-blank@latestの使用時にバージョン8.0.0が見つからない場合があります。その場合は--vueフラグを使用してください。

ネイティブUIコンポーネントの使用

NativeScript-Vueでは、Vueのテンプレート内でネイティブUIコンポーネントを直接使用します。以下はリスト表示の例です。

<template>
  <Page>
    <ActionBar title="NativeFlix" />
    <ListView height="100%" separatorColor="transparent" for="item in flicks">
      <v-template>
        <GridLayout height="280" rows="*, auto, auto" columns="*">
          <Image row="0" :src="item.image" />
          <Label row="1" :text="item.title" />
        </GridLayout>
      </v-template>
    </ListView>
  </Page>
</template>

<script>
export default {
  data() {
    return {
      flicks: [
        { id: 1, title: 'Movie 1', image: '~/assets/movie1.jpg' },
        { id: 2, title: 'Movie 2', image: '~/assets/movie2.jpg' },
      ]
    };
  }
};
</script>

ここで使用されているコンポーネントは以下の通りです。

• ActionBar: ページヘッダー
• ListView: スクロール可能なリスト
• GridLayout: グリッドレイアウトコンテナ
• Image: 画像表示
• Label: テキストラベル

これらは全てネイティブUIコンポーネントとしてレンダリングされ、WebViewのオーバーヘッドがありません。

参考

• NativeScript-Vue Getting Started
• Build a master-detail app with Vue

Quasar Framework

Quasarは、単一コードベースで複数プラットフォームに展開できるVue.jsフレームワークです。Web、モバイル、デスクトップアプリを同時に開発できる点が特徴で、エンタープライズ向けのフルスタックソリューションを提供します。

基本情報

• 最新バージョン: v2.18.5（2025年10月）
• ライセンス: MIT
• GitHub: 26,800スター（2025年10月時点）¹⁰
• npm: 週間156,502ダウンロード¹¹
• 公式サイト: https://quasar.dev/

特徴

• Web、iOS、Android、デスクトップ（Electron）、ブラウザ拡張機能対応
• 70以上のMaterial Design準拠のUIコンポーネント
• SSR、PWA、SPAに対応
• Capacitor/Cordovaによるモバイルアプリ化
• Vue 3とComposition API完全対応
• Viteベースの高速開発環境
• CLIツールによる統合開発体験

プロジェクト作成

Quasar CLIを使用することで、対話的にプロジェクトを作成できます。

npm create quasar
# または
yarn create quasar

対話形式で以下を選択します。

• App with Quasar CLI
• Quasar v2
• Vite（推奨）またはWebpack

グローバルCLIをインストールすると、コマンドを直接実行できます。

npm install -g @quasar/cli
quasar dev
quasar build

補足: 対話形式を避けたい場合や、既存のVue 3プロジェクトにQuasarを追加する場合は、以下の手動セットアップも可能です。

# Vue 3プロジェクトを作成 npm create vue@latest my-app cd my-app npm install # Quasarをインストール npm install quasar @quasar/extras npm install -D @quasar/vite-plugin sass # vite.config.tsとmain.tsを設定（詳細は公式ドキュメント参照）

モバイルアプリ化

QuasarはCapacitorまたはCordovaを使用してモバイルアプリに変換します。Capacitorを使用する例です。

quasar mode add capacitor
quasar dev -m capacitor -T android
quasar dev -m capacitor -T ios

Capacitorモードでは、Webアプリとして開発したコードがそのままモバイルアプリになります。

コンポーネントの使用例

Quasarのコンポーネントは、自動インポートに対応しているため、設定なしで使用できます。以下はカードとボタンを使用した例です。

<template>
  <q-page class="flex flex-center">
    <q-card class="q-pa-md" style="min-width: 350px">
      <q-card-section>
        <div class="text-h6">Quasar Framework</div>
        <div class="text-subtitle2">モバイルアプリ開発</div>
      </q-card-section>

      <q-card-section>
        <q-input
          v-model="text"
          label="テキスト入力"
          outlined
        />
      </q-card-section>

      <q-card-actions align="right">
        <q-btn
          label="送信"
          color="primary"
          @click="onSubmit"
        />
      </q-card-actions>
    </q-card>
  </q-page>
</template>

<script setup lang="ts">
import { ref } from 'vue';

const text = ref('');

const onSubmit = () => {
  console.log('送信:', text.value);
};
</script>

レイアウトシステム

QuasarはFlexboxベースの12ポイントグリッドシステムを提供します。レスポンシブデザインに対応し、画面サイズに応じてレイアウトを自動調整できます。

<template>
  <div class="row">
    <div class="col-12 col-sm-6 col-md-4">
      <q-card>カード1</q-card>
    </div>
    <div class="col-12 col-sm-6 col-md-4">
      <q-card>カード2</q-card>
    </div>
    <div class="col-12 col-sm-6 col-md-4">
      <q-card>カード3</q-card>
    </div>
  </div>
</template>

このコードは、小さい画面では縦に並び、中サイズ画面では2列、大きい画面では3列で表示されます。

参考:

• Quasar Framework
• Quasar CLI
• Developing Capacitor Apps
• Flex Grid

uni-app - 中国市場向けフレームワーク

uni-app

uni-appは、中国のDCloudが開発するクロスプラットフォームフレームワークです。ネイティブアプリに加えて、WeChatやAlipayなどのミニプログラム（小程序）に対応している点が最大の特徴です。

基本情報

• 開発元: DCloud
• ライセンス: Apache 2.0
• GitHub: 40,300スター（2025年1月時点）¹²
• 開発者数: 900万人以上
• 月間ユーザー数: 12億人のモバイルユーザー¹³
• 公式サイト: https://en.uniapp.dcloud.io/

特徴

• iOS、Android、HarmonyOS Next対応
• Web（レスポンシブ）対応
• ミニプログラム対応（WeChat、Alipay、Baidu、Douyin、Larkなど）
• Vue.js構文ベース
• WeChatミニプログラムAPIとの互換性
• 条件付きコンパイルによるプラットフォーム別対応
• ネイティブレンダリング対応

なぜ中国で人気なのか

中国市場では、WeChatやAlipayなどのスーパーアプリ内で動作するミニプログラムが普及しています。uni-appは、ミニプログラムとネイティブアプリを単一コードベースで開発できるため、中国市場向けアプリ開発で広く採用されているようです。

参考

• uni-app Official Website
• uni-app History

Lynx + Vue

Lynx

Lynxは、ByteDanceが2025年3月5日にオープンソース化したクロスプラットフォームフレームワークです。TikTokのSearch、Shop、Live機能や、TikTok Studioアプリの開発に使用されている実績があり、ByteDanceの技術スタックから生まれた注目のフレームワークです。

基本情報

• 開発元: ByteDance
• 発表日: 2025年3月5日
• GitHub: 13,300スター（2025年10月時点）¹⁴
• 最新バージョン: v3.4.2（2025年10月9日）
• コミット数: 2,104件
• 貢献者: 82人
• 公式サイト: https://lynxjs.org/

特徴

• iOS、Android、Web対応（OpenHarmony、macOS、Windowsは開発中）
• Rust製の高速レンダリングエンジン
• デュアルスレッドアーキテクチャによる高性能
• フレームワーク非依存設計（React、Vue、Svelteなどに対応）
• PrimJS（QuickJSベース）によるJavaScript実行環境
• 初回フレーム描画の高速化（2〜4倍高速と報告）

Vue統合の状況

Lynxはフレームワーク非依存の設計で、現在はReactLynxが公式に提供されています。ByteDance社内では、Lynxの約半分のプロジェクトでReact以外のフレームワーク（VueやSvelte）が使用されています¹⁵。

Vue.jsの創設者であるEvan Youは、Xでの投稿で以下のように述べ、Vue統合への支援を表明しています¹⁶。

https://x.com/youyuxi/status/1898663514581168173

Lynx発表から、VueコミュニティのメンバーであるRahul Vashishthaがプロトタイプ開発を開始しました。2025年10月時点では、Vue統合はまだプロトタイプ段階であり、正式なリリースには至っていません。

2025年のロードマップ

Lynxチームは2025年に5つの安定版リリースを計画しています¹⁷。

• v3.2（2025年4月）: リリース済み
• v3.3（2025年6月）: リリース済み
• v3.4（2025年10月）: リリース済み、OpenHarmonyサポート
• v3.5（2025年10月）: macOS、Windowsサポート
• v3.6（2025年12月）: 予定

機能面では、input要素、ViewPager、Swiper、SVGサポート、Canvas API、Lottieアニメーション、通知、位置情報などの追加が計画されています。

現状の制約

2025年10月時点で、Lynxには以下の制約があります。

• エコシステムがまだ未成熟
• サードパーティライブラリの不足
• ドキュメントとチュートリアルが限定的
• 標準HTML要素（button、input）非対応（代わりに<view>, <text>, <image>などの独自要素を使用）
• 既存ネイティブアプリへの統合が前提（スタンドアロンビルド非対応）

エコシステムがまだ未成熟であり、開発チームは既存アプリへの段階的な統合を推奨しています。新規アプリをゼロから開発する用途には、エコシステムの成熟を待つことが推奨されます¹⁸。

ByteDanceの技術力と投資規模を考えると、Vue.jsとモバイルアプリの目線でもLynxの将来性は注目に値します。

メンテナンス終了したフレームワーク

かつて使われていたフレームワークですが、現在は開発が停止しています。新規プロジェクトでの採用は推奨しません。

Weex（開発終了）

Weexは、Alibabaが開発したクロスプラットフォームフレームワークで、VueとRaxの構文でモバイルアプリを構築できました。2016年にオープンソース化され、2017年からApache Incubatorプロジェクトとして開発されていましたが、2021年5月にApacheから引退し、開発が事実上停止しています¹⁹。

• GitHub: 13,800スター（アーカイブ化）
• 最終コミット: 4年前（2021年頃）
• 現状: Apache incubator-weexリポジトリはアーカイブ化

Vue Native（非推奨）

Vue Nativeは、React Native上でVue.js構文を使用できるようにしたフレームワークです。Vue.jsのコードをReact Nativeコードに変換する仕組みでしたが、2021年11月に正式に非推奨化されました²⁰。

• 開発元: GeekyAnts
• 非推奨化: 2021年11月
• 理由: メンテナンス継続が困難

Onsen UI（限定的メンテナンス）

Onsen UIは、PWAとハイブリッドアプリ向けのUIフレームワークで、Vue、React、Angularのバインディングを提供しています。Web Componentsベースで設計されており、Cordovaと組み合わせて使用します²¹。

• GitHub: OnsenUI/OnsenUI（最終コミット約1年前）
• Vue 3対応: 公式ドキュメントあり
• 現状: 限定的なメンテナンス

メインリポジトリは2023〜2024年頃まで更新がありましたが、活発な開発は行われていません。

まとめ

本記事では、2025年秋時点でのVue.jsモバイルアプリ開発フレームワークの状況を調べて整理しました。

Vue.jsでのモバイルアプリ開発には、想像以上に豊富な選択肢があります。Ionic Vue、Capacitor、NativeScript-Vue、Quasarの4つの主要フレームワークは、いずれも継続的にメンテナンスされており、プロダクション環境での利用に適しています。中国市場向けにはuni-app、最近のトレンドや将来性としてはLynxという選択肢も存在します。

FlutterやReact Nativeと比較すると市場シェアは小さいものの、既存のVue.jsチームがモバイルアプリ開発に参入する際の敷居は低く、学習コストを抑えられる点が大きなメリットです。

2024〜2025年のVue.jsエコシステムの進化（Vue 3.5のメモリ削減とパフォーマンス改善、Vite 6.0のリリース、Nuxt 4の正式版）は、モバイルアプリ開発にも好影響を与えています。特にVue 3.5のメモリ使用量56%削減と配列操作の高速化は、リソース制約のあるモバイル環境で効果を発揮します。

Vue.jsモバイルアプリ開発の選択肢は今後も拡大していくでしょう。特にLynxのような新技術や、PWA/ハイブリッドアプローチの進化に注目です。

夏の自由研究2025ブログ連載の6日目です。

はじめに

こんにちは、HealthCare Innovation Group(HIG)¹の永井優斗です。

2025年3月にTikTokの運営会社である、ByteDance社が Lynxというクロスプラットフォームフレームワークを公開しました。

LynxはJavaScriptベースでのマルチプラットフォームフレームワークです。そう書かれると、React Nativeを思い浮かべない人はいないでしょう。React Nativeの競合になりうるフレームワークです。

まだまだLynx自体の知名度は低く、LynxとGoogle検索すると、元の意味であるオオヤマネコが出てきます。リンクスティップ（耳の先から出ている、狩りに役立つ毛）が可愛いですね。

• Lynx lynx, Nationalpark Bayerischer Wald, Deutschland の写真
• 著作者：Martin Mecnarowski
• CC表示-継承 3.0 https://commons.wikimedia.org/wiki/File:Lynx_lynx_1_(Martin_Mecnarowski).jpg による

この記事では、Lynx を触ってみた体験を簡単にまとめます。なお、開発した環境は、私物のMac mini(2020 M1)で、iPhone上での動作を試してみました。

セットアップ

※セットアップにはNode.js 18以上がインストールされている必要があります。

まずは公式の create-rspeedy でプロジェクトを作成します。

npm create rspeedy@latest
cd <project-name>
npm install
npm run dev

• セットアップについては、公式ドキュメントのQuick Startもご確認ください

npm run devでビルド成功後、QRコードとURLがターミナルに表示されます。

動作確認には、「Lynx Explorer」というアプリが必要です。

公式サイトに記載の「Download LynxExplorer-arm64.app.tar.gz.」のリンクから落として解凍し、XCodeのシミュレーターにドロップすることで、アプリをシミュレーターにインストールできます。ターミナルに表示されたURLをシミュレーター上の「Lynx Explorer」のCard URLに入力することで、動作確認ができます。

また、「Lynx Explorer」は、App Storeでも公開されており、スマホ実機にもインストールできます。

同じく、ターミナルに表示されたURLを入力するか、QR コードをアプリで読み込むと、そのままスマホ実機で動作確認できます。
開発している横で、ケーブルに繋ぐこともなく、即実機で試せるのは便利だなと感じました。

カウンターアプリを作ってみた。

あまり時間をかけずに触ってみたいと思ったため、簡単なカウンターアプリを作成することにしました。

Lynx では HTML タグではなく、 <view> や <text> を使います。
イベントハンドラも React っぽくはなく、 bindtap , bindlongpress のように書くのが特徴的です。

<view class="btn" bindtap={() => setCount(c => c + 1)}>
  <text>+1</text>
</view>

CSS もそのまま使えるので、スタイリングは Web の知識でいけそうです。

イベント拡張：「長押し」「ダブルタップ」

次に、イベントAPIを活かしてカウンターを拡張しました。

• +ボタン → タップで +1、長押しで +10
• –ボタン → タップで –1、ダブルタップで –10
• Resetボタン → 0 にリセット

ダブルタップ判定の実装例

const lastTapTimeStampRef = useRef(0);
const singleTapTimeoutIdRef = useRef(null);
const DOUBLE_TAP_GAP = 250;

// -1 ボタンのtapハンドラ
const handleMinusTap = () => {
  const now = Date.now();
  const gap = now - lastTapTimeStampRef.current;

  if(gap < DOUBLE_TAP_GAP){
    // ダブルタップと判定する
    if(singleTapTimeoutIdRef.current) {
      // ダブルタップが成立したらシングルタップ予約をキャンセル
      clearTimeout(singleTapTimeoutIdRef.current);
      singleTapTimeoutIdRef.current = null;
    }

    lastTapTimeStampRef.current = 0;
    setCount((c) => c - 10);
    return;
  }
  // シングルタップかもしれない場合は、少し待って確定する。
  lastTapTimeStampRef.current = now;
  singleTapTimeoutIdRef.current = setTimeout(() => {
    setCount((c) => c - 1);
    lastTapTimeStampRef.current = 0;
    singleTapTimeoutIdRef.current = null;
  }, DOUBLE_TAP_GAP);
};

標準で「ダブルタップ」イベントがあるわけではないので、useRef を使って「直前のタップ時刻」を保存し、一定時間内にもう一度押されたらダブルタップとみなすようにしました。

作成したアプリのUIはこんな感じになりました。

GitHubでソースを公開しています。

触ってみて感じた疎結合感

カウンターアプリを作っていてまず感じたのは、「ReactとLynxががっちり結合しているわけではない」 という点です。

イベントの書き方ひとつ取っても、React Native なら onPress を書くところを Lynx では bindtap を書きます。ReactのクリックイベントがonClickであるのに対してのReact NativeのonPressはとてもわかりやすいなと思いますが、そのまま持ってきたという感じもします。

LynxはReactのAPIをそのまま持ってきたのではなく、Lynx側に独自のインターフェースがあり、それをReactでラップしているんだなと感じました。

また、スタイルが素のCSSで書けるのも印象的です。React Native のように StyleSheet API に閉じていないため、「Webの知識をそのまま活かせる」一方で「別のフロントエンドフレームワークからも同じ描画基盤を使える」余地があると感じました。

React Nativeとの違いとしてのフレームワーク依存性

React NativeはReactに強く結合しており、他のUIフレームワークを載せることはできません。Lynxは描画基盤とフレームワークが、（React Nativeと比較してという意味で）疎結合です。React 以外に他のJSフレームワークを載せることもできるかもしれません。

実際、公式のLynx公開時の説明でもLynxが対応するフレームワークReactに限らないことを表明しています。

We are open-sourcing ReactLynx (“React on Lynx”) as Lynx’s initial frontend framework flavor, enabling componentized, declarative UI on Lynx.
However, Lynx isn’t limited to React. In fact, other frameworks already represent roughly half of Lynx’s overall usage, demonstrating its neutrality in hosting different flavors.

※太字はこちらでつけたものです。

実際、GitHub Issue #193 のとおりVue.jsをLynxに載せられないかというディスカッションはすでに始まっており、今後Vue.jsに対応するかもしれません。その話はまた、別の機会で深掘りしたいと思います。

さいごに

Lynxはまだ3月に出たばかりでもあり、エコシステムの発展やLynx自体も「枯れる」までにはもうちょっと時間がかかるとは思います。
いますぐ業務で使えるというわけではないですが、今後React NativeやFlutterの対抗馬として、マルチプラットフォーム開発に使える日が来るかもしれません。

その頃にはVue.jsにも対応しているといいな。

おまけ

今回Lynxを触るということまでは決めていたのですが、何つくろっかなーと悩んでいました。ChatGPT5と相談することで、簡単に試すことができました。

カウンターアプリを作ることや、作ったカウンターの拡張（長押し、ダブルタップ）はChatGPTのアイデアです。また、ChatGPTが生成したサンプルのソースコードに対して「この行何やってるんだろうか」と質問したり、逆にChatGPTが明らかにおかしいところを指摘しながら、対話を進めるとだいぶ理解が捗りました。

新しいプログラミング言語に入門するとき、LLMは大きなアシスタントになってくれるんだなと感じました。

はじめに

CI/CD連載 4本目です。

HIGの橋本です。

Apple 純正のCI/CDサービスである Xcode Cloud を初めて導入するときに、導入時にまず押さえておきたいポイントを実際に試し、まとめた記事です。

本記事では、次の3つについて述べます。

1. リモートリポジトリへのプッシュをトリガーにCIを実行し、ビルドとテストを行うPull Request Workflow
2. Git タグのPushをトリガーとし、ビルド、テスト、TestFlight へアプリを配信するTestFlight Release Workflow
3. 成功・失敗を Slack へ通知する手順

Xcode Cloud 概要

Xcode Cloud は、Xcode に組み込まれた継続的インテグレーションおよびデリバリーサービスで、Apple デベロッパーのために設計された CI/CD サービスです。署名まわりの煩雑な設定が不要になる点が最大の特徴です。これにより開発者はワークフロー最適化といった本質的な作業に集中でき、結果として開発体験が向上します。

Xcode Cloud - Apple Developer

主に次のような機能、特徴を持っています。

• 自動ワークフロー
  • 開発プロセスに合わせてワークフローをカスタマイズすることが可能できます
    トリガー、アクション（ビルド、テストなど）、通知などを設定できます。
• 並列テスト
  • 複数プラットフォーム・複数デバイスでのテストを並列実行できます
• Xcode への組み込み
  • Xcode から実行状況やクラッシュレポートをまとめて確認できます
• App Store Connect への組み込み
  • App Store Connect でも同じ情報を閲覧でき、Workflow の編集も行えます
• Apple Developer Program メンバーシップ加入者は、毎月25時間分のコンピューティング時間を無料で利用できます

Pull Request Workflow

リモートリポジトリへのプッシュをトリガーにCIを実行し、ビルドとテストを行うPull Request Workflowを作成します。

• Getting started with Xcode Cloud: Pull Request (PR) Workflow

ワークフローの設定

ワークフローで設定できる各種項目は次のとおりです。

以下では、Xcode での設定例を示します。

General

ワークフローの名前や説明を記載し、リポジトリ、プロジェクトを設定します。

Environment

Xcode Version, macOS Version を最新に設定します（自身のプロジェクトに合わせて対象バージョンを修正してください）。

Start Conditions (Pull Request Changes)

feature ブランチで変更をコミットし、リモートブランチに Push したことをトリガーに CI が動作するように設定します。

• Sourceブランチをfeature/で始まるブランチに設定
• Targetブランチをdevelopブランチに設定

Actions

トリガーを検知したときに、実行する内容をここで決めます。本ワークフローではビルドとテストを追加します。

1. Build - iOS
2. Test - iOS

Post-Actions

Actions の実行完了後の処理を定義します。ここでは、指定の Slack チャンネルへ成功・失敗の通知が届くように設定します。

動作イメージ

feature ブランチで改修し、develop ブランチへのPRを作成したときの CI 動作イメージを示します。

まず、 feature ブランチで変更をコミットし、リモートブランチに Push します。

git checkout -b feature/7-modify-title
git add .
git commit -m "fix: modify navigation title"
git push origin feature/7-modify-title

GitHub 上で PR を作成します。

トリガーであるfeature/で始まるブランチからdevelopへのPRが作成されたことを検知し、XcodeとGitHub上でCIが動作していることが確認できます。

Xcode

GitHub

Build と Test が成功すると、Xcode で次のように結果概要が確認できます。

GitHub の PR 上で次のように、Pull Request Workflow が成功していることも確認できます。

また、成功通知が Slack に届いていることも確認できます。

TestFlight Release Workflow

シンプルなGitタグのPushをトリガーとする、ビルド、テスト、アーカイブ、TestFlightリリースする TestFlight Release Workflowを作成します。

ワークフローの設定

ワークフローを次のように設定します。ここでは、Xcode 上から設定する例を示します。
重要な点としては、TestFlight リリースするために、Actions に Archive を必ず追加します。

General

ワークフローの名前をTestFlight Release Workflowとします。

Environment

Xcode Version, macOS Version を最新に設定します（自身のプロジェクトに合わせて対象バージョンを修正してください）。

Start Conditions (Tag Changes)

Git タグの Push をトリガーとするため、Tag Changes を選択します。
ここでは、TagはAny Tag としています（Tag の命名ルールがある場合は、Custom Tags から指定できます）。

Actions

TestFlight リリースする本ワークフローではビルドとテストに加えて、アーカイブも追加します。

1. Build - iOS
2. Test - iOS
3. Archive - iOS

Post-Actions

Slack への通知するNotify、内部テスター向けTest Flight リリースする TestFlight Internal Testing を追加します。

1. Notify - Successes and Failures
2. TestFlight Internal Testing - iOS
   内部テスターグループを選択します。（事前に、App Store Connect上で内部テスターの登録が必要です。）

動作イメージ

releaseブランチにチェックアウトし、タグを作成してPushします。

git checkout release
git tag v1.0.0
git push origin v1.0.0

トリガーを検知し、CI が動作します。

Xcode

App Store Connect

ワークフローが無事成功しました。Xcode, App Store Connect ではそれぞれ次のように成功していることを確認できます。

Xcode

App Store Connect

App Store Connect の TestFlight タブに新しいビルドが作成され、ステータス「テスト中」となり、内部テスターに配信されていることが確認できます。

また、Slack へ本ワークフローが成功したことを伝える通知が届きます。

これで TestFlight リリースしたいブランチにタグを Push するだけで、簡単に TestFlight リリースができるようになりました。

Tips

検証中、Archive は正常に完了しても TestFlight への配信が一向に進まない事象に遭遇しましたが、以下の記事で紹介されている手順で解消できました。

• Xcode CloudでArchiveは成功するのにTestFlightへの配信が進まないとき

原因：

アプリの新しいバージョンを提出するたびに、App Store Connectはコンプライアンスレビューを案内する質問をします。アプリInformation Property Listファイルに必要な情報を提供することで、これらの質問を回避し、提出プロセスを合理化できます。

解決策：

アプリが暗号化を使用していない場合は、Info.plistファイルにITSAppUsesNonExemptEncryptionキーを追加し、値をNOに設定します。

成功・失敗をSlackへ通知する設定手順

次の Apple 公式ドキュメントを参考に、成功・失敗を Slack へ通知するように設定してみます。

• Connecting Xcode Cloud to Slack | Apple Developer Documentation

まず、Slack への通知したい WorkFlow の編集画面を開き、Post-Actions に Notify を追加します。

画面キャプチャ中の Slack の下の「＋」ボタンを押します。

Slackのワークスペースと接続するか問われるダイアログが表示されるので、「Connect…」を押します。

ブラウザが立ち上がり、Xcode Cloud に Slack の任意のワークスペースにアクセスする権限を付与してよいか確認されます。
問題なければ、「許可」をクリックします。

Xcode に戻り、アクセス権限を付与したワークスペースのチャンネルが表示されます。
通知を送信したいチャンネルを選択し、「OK」を押します。

「Save」をクリックして変更を保存します。
これで CI/CD の実行結果が Slack へ通知されるようになります。

成功したときの通知例

とても簡単に設定ができました。
この通知から、App Store Connect の Xcode Cloud のページを直接開いたり、該当の PR を開いたり出来るのもとても便利です。

さいごに

Xcode Cloud でまず作りたい基本的な CI ワークフローとして、2種類のワークフローを作成してみました。

今回作成した Pull Request Workflow と TestFlight Release Workflow や、当社の有志メンバーで作成したGitブランチフロー規約などを参考に、皆さんのプロジェクトで最適な CI/CD ワークフローを考えてみるのはいかがでしょうか。

Xcode Cloud でできることはまだたくさんあるので、知見がたまり次第また記事にしたいと思います。

参考

• Xcode Cloud - Apple Developer
• Configuring your first Xcode Cloud workflow | Apple Developer Documentation
• Getting started with Xcode Cloud: Pull Request (PR) Workflow
• Connecting Xcode Cloud to Slack | Apple Developer Documentation
• Xcode CloudでArchiveは成功するのにTestFlightへの配信が進まないとき

はじめに

.NET MAUIでiOS向けアプリを開発中、WebアプリからiOSアプリを呼び出す必要がでてきたため、ユニバーサルリンクを実装しました。WebサーバーはAzure Blob Storageの静的サイトを利用します。

ユニバーサルリンクとは

ユニバーサルリンク（Universal Links）は、Webサイトへのリンクをクリックしたときに、そのリンクに対応するiOSアプリがインストールされていれば直接アプリを起動し、インストールされていなければWebサイトを表示するという機能です。

• 参考: Allowing apps and websites to link to your content

仕組み

1. WebサーバーにApple App Site Association （以下: AASA）ファイルを置いておきます
2. Apple CDNが定期的にWebサーバーのAASAファイルをクロールします
3. iPhoneが、アプリインストール時にAppleCDNからAASAファイルを取得します
4. Webサイト上で特定のURLを踏むとAASAファイルを使ってアプリを立ち上げる

簡単に図示すると以下のような感じになります。

WebサーバーにAzure Blob Storageを利用する

上記の通り、AppleCDNがアクセスできるWebサーバを準備し、UniversalLink用のAASAファイルを配備する必要があります。

そこで、安価に静的サイトを公開できるAzure BlobStorageの静的サイト機能を使いたいと思います。

• 参考: Azure Storage での静的 Web サイト ホスティング

Azure Storage構築

ストレージアカウントの作成

まずはストレージアカウントを作成します。

ストレージアカウントは基本的にデフォルトで大丈夫だと思いますが、必要に応じて値を変更します。基本情報のプライマリサービスは 「Azure Blob Storage または Azure Data Lake Storage Gen 2」 とします。

作ったものがこちらです。アカウントの種類が StorageV2 (汎用 v2) であることを確認します（上位のものでも大丈夫です）。

静的サイトを有効化

概要の下の方の機能タブから静的Webサイトを選択します。

ここで有効化します。プライマリエンドポイントが今回のUniversalLinkのドメインになります。myapp-universal-link-sample.z11.web.core.windows.net のような感じになると思います。

※ カスタムドメインの使用もできますが、今回はスキップします。

静的サイトを有効化すると、$Web フォルダができます。

AASAファイルを配置

AASAファイルを準備します。

• 参考: Supporting associated domains

内容は JSON ですが、ファイルに拡張子はつけないで保存します。ファイル名は apple-app-site-association です。

今回はリンクURLによる制限はつけずにどんなURLでも呼び出し可能とします。

{
  "webcredentials": {
    "apps": [
      "アプリのID"
    ]
  },
  "applinks": {
    "apps": [],
    "details": [
      {
        "appIDs": [
          "アプリのID"
        ],
        "components": [
          {
            "/": "*"
          }
        ]
      }
    ]
  }
}

$Web コンテナを開いてアップロードします。

右下のアップロード先のフォルダは .well-known にします。フォルダが存在しない場合でも、自動的に作成してくれます。

アップロードしたファイルを確認します。

階層が $Web/.well-known/apple-app-site-association となっていればOKです。

最後に ContentType を指定します。

ファイルをクリックするとプロパティが開くので編集します。application/json; charset=utf-8 にします。application/json は必須だと思います。 charset=utf-8はなくても大丈夫ですが、念の為に指定します。

$WebをPublic化

Apple CDNがアップロードしたAASAファイルを取得できるようにします。 コンテナを選択してアクセスレベルを変更します。 デフォルトだとプライベートになっていると思うので、コンテナしておきます。

AASAファイルを確認します。

先程のプライマリエンドポイントに .well-known/apple-app-site-association つけてURLバーに入れて（例: https://myapp-universal-link-sample/.well-known/apple-app-site-association）、AASAファイルが見えることを確認します。

Apple CDNを確認

アップロード後、しばらくするとAASAファイルをApple CDNが回収してくれます。

そのキャッシュは https://app-site-association.cdn-apple.com/a/v1/myapp-universal-link-sample.z11.web.core.windows.net で確認できます。

以上で環境構築は完了です。

Mauiアプリの設定

MauiプロジェクトのPlatformフォルダのIOSフォルダ直下に Entitlements.plist を作成します。内容は以下の通りです。

先程のプライマリエンドポイントのを記載します。「https://」は不要です。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
      <string>applinks:myapp-universal-link-sample.z11.web.core.windows.net</string>
    </array>
  </dict>
</plist>

Entitlements.plist を作りたくない人はcsprjで設定もできます。

以下は、Apple universal linksより引用したコードです。

<ItemGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios' Or $([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'maccatalyst'">

    <!-- For debugging, use '?mode=developer' for debug to bypass apple's CDN cache -->
    <CustomEntitlements
        Condition="$(Configuration) == 'Debug'"
        Include="com.apple.developer.associated-domains"
        Type="StringArray"
        Value="applinks:myapp-universal-link-sample.z11.web.core.windows.net?mode=developer" />

    <!-- Non-debugging, use normal applinks:url value -->
    <CustomEntitlements
        Condition="$(Configuration) != 'Debug'"
        Include="com.apple.developer.associated-domains"
        Type="StringArray"
        Value="applinks:myapp-universal-link-sample.z11.web.core.windows.net" />

</ItemGroup>

※ ?mode=developer をつけておくとApple CDNをバイパスして、直接WebサーバからAASAファイルを取得するようになります。

次に、UniversalLinkで起動されたときのハンドラーを書きます。

Apple universal links - .NET MAUI | Microsoft Learn を参考にMauiProgram.cs を編集し、ユニバーサルリンク経由でアプリが起動・再開された際にURLを処理するためのライフサイクルイベントを登録します。

using Microsoft.Maui.LifecycleEvents;
using Microsoft.Extensions.Logging;

namespace MyNamespace;

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder
            .UseMauiApp<App>()
            .ConfigureFonts(fonts =>
            {
                fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
                fonts.AddFont("OpenSans-Semibold.ttf", "OpenSansSemibold");
            })
            .ConfigureLifecycleEvents(lifecycle =>
            {
#if IOS || MACCATALYST
                lifecycle.AddiOS(ios =>
                {
                    // Universal link delivered to FinishedLaunching after app launch.
                    ios.FinishedLaunching((app, data) => HandleAppLink(app.UserActivity));

                    // Universal link delivered to ContinueUserActivity when the app is running or suspended.
                    ios.ContinueUserActivity((app, userActivity, handler) => HandleAppLink(userActivity));

                    // Only required if using Scenes for multi-window support.
                    if (OperatingSystem.IsIOSVersionAtLeast(13) || OperatingSystem.IsMacCatalystVersionAtLeast(13))
                    {
                        // Universal link delivered to SceneWillConnect after app launch
                        ios.SceneWillConnect((scene, sceneSession, sceneConnectionOptions)
                            => HandleAppLink(sceneConnectionOptions.UserActivities.ToArray()
                                .FirstOrDefault(a => a.ActivityType == Foundation.NSUserActivityType.BrowsingWeb)));

                        // Universal link delivered to SceneContinueUserActivity when the app is running or suspended
                        ios.SceneContinueUserActivity((scene, userActivity) => HandleAppLink(userActivity));
                    }
                });
#endif
            });

#if DEBUG
        builder.Logging.AddDebug();
#endif

        return builder.Build();
    }

#if IOS || MACCATALYST
    static bool HandleAppLink(Foundation.NSUserActivity? userActivity)
    {
        if (userActivity is not null && userActivity.ActivityType == Foundation.NSUserActivityType.BrowsingWeb && userActivity.WebPageUrl is not null)
        {
            HandleAppLink(userActivity.WebPageUrl.ToString());
            return true;
        }
        return false;
    }
#endif

    static void HandleAppLink(string url)
    {
        if (Uri.TryCreate(url, UriKind.RelativeOrAbsolute, out var uri))
            App.Current?.SendOnAppLinkRequestReceived(uri);
    }
}

Appクラスの OnAppLinkRequestReceived を呼んでくれるのでOverrideすることで受け取ったURLのハンドルができます。
クエリパラメータもらうときなどはここで処理するとよいと思います。

protected override void OnAppLinkRequestReceived(Uri uri)
{
   //uriの処理が必要であれば
}

Mauiアプリの修正は以上です。

Apple DeveloperアカウントのアプリIDに、関連ドメインの使用を許可

UniversalLinkを使うにはApple上のアプリに使用を許可する必要があります。

手順は以下の通りです（参考: Apple universal links）。

1. Web ブラウザでApple Developer アカウントにログインし、 「証明書、ID、およびプロファイル」ページに移動します
2. 「証明書、識別子、プロファイル」ページで、「識別子」タブを選択します
3. 「識別子」ページで、アプリに対応するアプリ ID を選択します
4. 「App ID 構成の編集」ページで、「関連ドメイン」機能を有効にし、「保存」ボタンを選択します
5. profileに反映させます。Editから先程設定したApp IDを選択します
   Enabled CapacitiesにAssociated DomainがあればOKです
6. 最後にVisual Studioのプロファイルを更新します

アプリをリリースする

あとはアプリをリリースするだけです。デバッグでも大丈夫です。

今回の場合のユニバーサルリンクのURLはブロブストレージのプライマリエンドポイント（例: https://myapp-universal-link-sample.z11.web.core.windows.net/）になります。これをWebサイトに埋め込んでおきます。

アプリがインストールされている状態であれば、iPhoneのメモ帳でも確認ができます。リンク用のURLを打ち込んで長押しするとアプリを開くという選択肢がでてきます。

さいごに

Azure Blob Storageの静的サイト機能で簡単にUniversalLink用のWebサーバを立ち上げられました。

Azure環境がある場合は選択肢に入れてもいいかなと思います。

こんにちは。HealthCare Innovation Group(HIG)の清水雄一郎です。
VSCodeだと思っていたのですが、厳密（？）にはVS Codeであることに気づいた今日この頃です。

春の入門祭り2025 10日目の記事です。

SwiftにおけるiOS開発といえば、やはりXcodeを使っている方が多いと思います。

ただ最近は、VS Codeに魅力的な拡張機能（特に生成AIを活用したもの）が多く、活用していきたいと思うようになりました。

「Xcodeを最小限に抑えて、VS CodeでiOSアプリ開発してみたらどうなるんだろう？」という好奇心から、今回ちょっとした実験をしてみることにしました。

この記事では、VS Code（周辺ツール）だけでどこまでiOSアプリ開発するためにどのような準備が必要か、検証した記録をまとめていきます。

環境

• MacBook Air (M2, 2022)
• macOS 15.4.1
• Xcode 16.3

事前準備

VS Code上で、次の拡張機能をインストールします。

• Swift - Visual Studio Marketplace

また、検証用にXcode上でTechBlogSpring2025というiOSアプリプロジェクトを作成しておきます。

• Creating an Xcode project for an app | Apple Developer Documentation

ゴール

iOSアプリがビルド＆実行できるようになること。
※テストやコード補完などは、本記事では扱いません。

ビルド

まずはビルドです。Xcode上では、⌘ + B に相当するものです。

VS Codeにはそういったショートカットキーはないため、CLIから実行していきます。

Xcodeがインストールされている場合は、xcodebuildコマンドが利用できると思いますので、そちらを利用して実行します。

今回サンプルで用意したプロジェクトを用いてiOSシミュレータ用にアプリをビルドする場合、次のようなコマンドになるかと思います。

xcodebuild -workspace TechBlogSpring2025.xcodeproj/project.xcworkspace \
           -scheme TechBlogSpring2025 \
           -sdk iphonesimulator \
           -configuration Debug \
           build

~~ 省略 ~~

** BUILD SUCCEEDED **

無事ビルド成功しましたが、毎回このコマンドを打つのは手間です。解消するために、VS Codeには外部ツールを実行する方法としてタスクを登録できる¹ため、そちらを用意します。

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "shell",
            "label": "Xcode Build - Debug",
            "detail": "xcodebuild debug",
            "command": "xcodebuild",
            "args": [
                "-workspace",
                "TechBlogSpring2025.xcodeproj/project.xcworkspace",
                "-scheme",
                "TechBlogSpring2025",
                "-sdk",
                "iphonesimulator",
                "-configuration",
                "Debug",
                "build"
            ],
            "group": "build"
        }
    ]
}

タスクを登録しておくと、⌘ + ⇧ + B で簡単にビルドを実行できるようになります🎉

実行

次は実行です。これが結構手間でした。

Xcode上では、⌘ + R に相当するものです。実行するスキーマと端末（今回はシミュレータ）を選択して⌘ + Rを押せばアプリがビルドされ、シミュレータ上でアプリが起動します。

見慣れた光景ではあるのですが、Xcodeなしで同じことをやろうとするといくつかのステップが必要です。

アプリがビルドされ、シミュレータ上でアプリが起動します。

これを分解すると、次のようなステップになります。

1. アプリをビルドする
2. 実行したい機種のシミュレータを起動する
3. 起動したシミュレータにアプリをインストールする
4. シミュレータでアプリを起動する

それぞれ順にCLI上で実行する場合は、次のようになります。

xcodebuild -workspace TechBlogSpring2025.xcodeproj/project.xcworkspace \
           -scheme TechBlogSpring2025 \
           -sdk iphonesimulator \
           -configuration Debug \
           -derivedDataPath .build/ \ # シミュレーターにアプリをインストールする際に必要なので、出力先を任意の場所に指定する
           build
xcrun simctl boot "iPhone 16 Pro" # 実行したい機種のシミュレータを起動する
xcrun simctl install booted build/Debug-iphonesimulator/TechBlogSpring2025.app # 起動したシミュレータにアプリをインストールする
xcrun simctl launch booted "com.example.TechBlogSpring2025" # シミュレータでアプリを起動する

これで晴れてビルドしたアプリをシミュレータ上で確認できます！

ただし、ビルドの時と同様にこれらを毎回実行するのは手間なのでVS Codeのタスクに登録してしまいましょう。

今回は4ステップあったので、4つのタスクを実行する必要があるのか？と思いました。

しかし、VS CodeのタスクにはdependsOnプロパティを利用することで、登録した複数のタスクを1つにまとめて実行できるみたいです👏

以下はtasks.jsonの例です。

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "shell",
            "label": "Xcode Build - Debug",
            "detail": "xcodebuild debug",
            "command": "xcodebuild",
            "args": [
                "-workspace",
                "TechBlogSpring2025.xcodeproj/project.xcworkspace",
                "-scheme",
                "TechBlogSpring2025",
                "-sdk",
                "iphonesimulator",
                "-configuration",
                "Debug",
                "-derivedDataPath",
                ".build/",
                "build"
            ],
            "group": "build"
        },
        {
            "type": "shell",
            "label": "Boot Simulator",
            "command": "xcrun",
            "args": [
                "simctl",
                "boot",
                "iPhone 16 Pro"
            ],
            "group": "test"
        },
        {
            "type": "shell",
            "label": "Run App on Simulator",
            "command": "xcrun",
            "args": [
                "simctl",
                "install",
                "booted",
                ".build/Build/Products/Debug-iphonesimulator/TechBlogSpring2025.app"
            ],
            "group": "test",
            "dependsOn": "Xcode Build - Debug"
        },
        {
            "type": "shell",
            "label": "Launch App on Simulator",
            "command": "xcrun",
            "args": [
                "simctl",
                "launch",
                "booted",
                "yu1Ro5.TechBlogSpring2025"
            ],
            "group": "test",
            "dependsOn": "Run App on Simulator"
        },
        {
            "type": "shell",
            "label": "Build and Run Sequence",
            "dependsOn": [
                "Xcode Build - Debug",
                "Boot Simulator",
                "Run App on Simulator",
                "Launch App on Simulator"
            ],
            "dependsOrder": "sequence",
            "group": "test"
        }
    ]
}

試してみて

今回チャレンジできなかった部分も含めて、XcodeとVS Code(w/ 拡張機能)で開発する場合、次のように使い分けようかと考えています。当初はXcode離れしたいモチベーションがありましたが、PreviewやInstrumentsなど、代替が見つけられなかった機能もあるため、適宜使い分けることができるといいなと思います。

• Xcodeを使う時
  • Preview² 機能を使って、UIを作り込む
  • アプリのアップロードなど、アプリ署名に関わる操作をする時
  • Instruments³ 機能を使って、アプリのパフォーマンスを測定する時
  • アプリの開発用証明書やプロビジョニングプロファイルの管理や設定時
    -> Xcodeのプロジェクトファイルは、人間が目で見てわかるものではないため
• VS Codeを使う時
  • 業務ロジックやテストなどのUI以外の実装時
    -> 生成AI活用した拡張機能使いやすいだけでも、使う価値あると思いました
  • MarkdownやJSON、YAMLなど、Swiftファイル以外を編集する時

まとめ

Xcodeの利用を最小限に抑えて、VS CodeでiOSアプリ開発してみようという話でした。

本記事で挑戦した範囲では、Xcodeを使わずにVS Codeを開発業務に利用するというレベルまでは到達していません。しかし、アプリをビルド＆実行するまでの内部的な仕組みの理解度が高まるいいきっかけになりました。

一方、執筆にあたり試行錯誤する中で、SweetPad⁴という今回準備した諸々をいい感じにセットアップしてくれるVS Code拡張機能に出会いました。この記事で詳しく紹介するまで辿り着けなかったですが、興味ある方はぜひ調べてみてください。

最後まで読んでいただき、ありがとうございました。

はじめに

HealthCare Innovation Group(HIG)¹の橋本です。

初めてtry! Swift Tokyo 2025に参加してきました！

参加報告として、興味深かったセッションや参加して感じたことなどを共有します。

try! Swift Tokyoとは

公式HP の記載の通り、Swiftに関する国際カンファレンスです。今年は、2025年4月9日~11日の3日間で開催されました。

イベントについて
Swiftを使った開発のコツや最新の事例を求めて世界中から開発者が集います。
日頃のSwiftの知識やスキルを披露し、協力しあうことを目的に、2025年4月9日 - 11日の３日間開催します！

開催場所: 立川ステージガーデン

会場は、昭和記念公園が隣にあったり、自然と調和した商業施設も隣接していたり、とてもリラックスできるような場所でした。（立川ステージガーデンの椅子がとても座りやすく、セッションの視聴に集中できました。）

try! Swift Tokyo 2025のアプリ

try! Swift Tokyo 2025を楽しむための公式アプリがありました。

アプリ自体は、フルSwiftUI x TCAというモダンな構成で実装されているとのことなので、GitHubレポジトリから中身も見てみたいなと思います。

• AppStore: https://apps.apple.com/jp/app/try-tokyo-2025/id6479317240
• GitHub: https://github.com/tryswift/try-swift-tokyo

機能としては、スケジュールや会場までのルート、AI通訳などがありました。中でもAI翻訳がとても便利で、英語のセッションもリアルタイムで翻訳してくれていたので、とても助かりました。Flittoさんありがとうございました。

• AI通訳機能画面

visionOS対応もしており、Apple Vision Proユーザーの方は、会場に表示されている壇上のスライドの上に、AI翻訳のウィンドウを表示させて見られてとても便利でしたという声もありました。（自分も体験してみたい。。。）

• 日本語でのSwiftプログラミングのスピーカーFlipByBlink DevさんのXへ投稿より

良かった・役に立った・もっと理解したいと思ったセッション

私が視聴して良かった・役に立った・もっと理解したいと思ったセッションをいくつか紹介します。

iOS17,16,15での新機能(セッション動画はこちら)

タイトルの通り、iOS17,16,15それぞれで新しい利用できるようになったAPIを紹介する発表でした。
WWDCのセッション動画で利用できると知っても、使えるようになるまでにタイムラグがあったりするのでこのタイミングでiOS17,16,15のAPIをいくつかキャッチアップできたのはとても良かったです。具体的には以下のAPIの紹介がありました。

紹介のあったiOS 15.0+で使えるAPI:

• formatted()
  • formatteddate:time:)
  • formatted(_:) → 表示したい桁数を指定できる。こちらは使いどころがありそう
• privacySensitive(_:)
  • privacySensitive(_:) → 適用したViewを非表示にできる
• .toggleStyle()
  • togglestyle(_:) → .toggleStyle(.button)などを使うことで組み込みのボタンの振る舞いが得られる

紹介のあったiOS 16.0+で使えるAPI:

• UIHostingConfiguration
  • UIHostingConfiguration → これにより、SwiftUIを簡単にUIKitに入れ込むことができる
• TextField(_:,text:,axis: .vertical)
  • init(_:text:axis:) → TextField(_:,text:,axis: .vertical)を使うことで、文字数が長くなったときに、テキストを途中で折り返し、テキストを全量表示できる
• Color.gradient
  • gradient → デザイナーからの指定がないようなプロトタイプ作成のようなとりあえずグラデーションをかけたいときに便利

紹介のあったiOS 17.0+で使えるAPI:

• ContentUnavailableView.search
  • ContentUnavailableView → .searchという静的プロパティで、検索結果がないときにViewを簡単に実装できる（ローカライズ対応や検索した文字をViewに簡単に組み込める）
• SubscriptionStoreView
  • SubscriptionStoreView → 簡単にサブスクリプション用のViewを構築できる
• .scrolltargetbehavior
  • scrolltargetbehavior(_:) → ページングなどにスクロールするときの振る舞いを指定できる（.pagedや.viewAlignedなどがある）
• .containerrelativeframe()
  • containerrelativeframe(_:alignment:) → このモディファイアで全体のサイズを計算したうえで、各子Viewのサイズを決定できるため、GeometryReaderを使用せず済ませることができる（参考記事: 【SwiftUI】ScrollView内でframeを指定せず、画面にあったサイズに調整する）
• .visualEffect()
  • visualEffect(_:) → GeometryReaderを使用せずに、視覚効果を与えることができる
• .contentTransition(.numericText())
  • contenttransition(_:)
  • numericText(countsDown:) → 数字のカウントダウン、アップのアニメーションをリッチなものにできる

日本語でのSwiftプログラミング(セッション動画はこちら)

Xcode,Swiftにおいて、日本語の識別子は基本的にサポートしている。パフォーマンス面でも問題ないとのこと。
テスト関数名は、日本語にしてもいいかな何て思ったりもしました。

Swift Testingでは、XCTestのテスト関数で必須であったプレフィックスtestが不要になるので、次のようなイメージで書くのも良いかもと思いました。

- @Test func foodTruckExists() {
+ @Test func フードトラックが存在する() {
  // Test logic goes here.
}

⚡️ Swift × Android: Skipが切り拓くクロスプラットフォーム開発の未来(セッション動画はこちら)

SwiftとXcodeを使って、iOSとAndroidのアプリを作成できるツールSkipの実用性と今後クロスプラットフォーム対応の主流となるかについて、スピーカーが実際にアプリを作成したときの経験が紹介されていました。

• 基本的にはSkipによって変換、生成されたコードでAndroidアプリのUIは期待通りになる。
• 2つのモードのうち、Native Modeを使うことをおすすめするとのこと。主な理由としては、もう一方のモードTranspile ModeではSwiftからKotlinに変換ができないAPIをがいくつかあるため。
• 既存で開発しているiOSアプリにSkipをそのまま適用は難しいとのこと。理由としては、iOSアプリで使用しているライブラリの一部がAndroidでサポートされていない。しかし、UIに関してはSwiftUIもそのままAndroidアプリに変換できるようにコンパイルできるようになってきている。
• スピーカーは、Skipがクロスプラットフォームのメインストリームに数年でなるのではとのこと。

skiptools/skip-uiのSupported SwiftUIをみても多くのものがFull Supportになっているのも確認できました。これを見ても、純粋？なiOSエンジニアがクロスプラットフォーム対応するときには、Skipも有力候補に入ってきそうだなと感じました。
私自身は、Kotlinを書いたことがないので、SwiftのコードをそのままAndroid対応できるSkipはとても魅力的に映るために、時間をみつけてSkipを触ってみたいと思いました。

参考資料:

• Skip
• https://github.com/skiptools
• https://github.com/skiptools/skip-ui

Foreign FunctionとMemory APIとSwift/Java相互運用性(セッション動画はこちら)

SwiftとJavaを相互に利用する方法について紹介がありました。
開発段階であるライブラリswiftlang/swift-javaをAppleのエンジニアでContributorであるKonradさんがお話されていました。

swiftlang/swift-javaでは、SwiftとJavaを相互運用するために次の２つのアプローチがあります。

• JavaKit
• JavaのAPIを直接呼ぶことが可能にするSwiftライブラリ
• jextract-swift
• jextractと類似したSwiftからJavaを効率的に呼び出すために使用するJavaソースを抽出するツール

内容は私には理解が難しい部分が多々あったが、弊社ではJavaを使う案件が多いので、該当レポジトリの内容とセッションを見直したいと思いました。セッションの中で、UIをSwiftUIで残りの内部ロジック等をJavaに寄せることができるようなお話もあり、とても興味深いものでした。

SwiftUI を最適化するためのレンダーループの理解(セッション動画はこちら)

SwiftUIを最適化するために、理解が必要なSwiftUIのレンダリングの仕組みや具体的な例を用いて表示遅延が起こる原因や解決策についての紹介がありました。

SwiftUIViewがどのようにレンダリングされているかという質問に対しては、レンダーループを理解することが近道です。

レンダーループ(Render loop)

レンダーループ(Render loop)とは、アプリのUIがどのように更新され、画面に表示するかを管理する継続的なサイクルを指します。

レンダーループのサイクル:

1. Event Phase
   • 何かしらのイベント/状態変化を検知する
2. View Update Phase
   • Event Phaseでの変更を元に、新しいView階層を構築する
   • そのとき、以前のView階層と比較し、UIを更新するために必要な最小限の変更セットを作成する（この機能は、UIKitにはなく、SwiftUI独自のものであり、これによりViewの描画が最適化されている）
3. Render phase
   • SwiftUIが新しいView階層をGPUで処理可能な形式に変換する（これには、色、形、画像などの視覚に関するプロパティが含まれる）
4. Display Buffer
   • Render PhaseでDisplay Bufferが作成される
5. Display
   • Diplay Bufferのピクセルデータをユーザー用の最終的な視覚情報に変換する

サンプルプロジェクトによる例示

サンプルコード: https://github.com/pradnya-nikam/trySwiftTokyoPrad2025

サンプルコードの雲をたくさん描画するViewでは、動く雲の数が多くなるにつれて動きもっさりしてきます。描画時のCPUの状況を見ると、徐々にCPUの使用率が上昇していくことが紹介されていました。これはRender Phaseですべての雲の位置を計算、雲の形を描画し、視覚効果を適用しているためです。このため、Render Phaseに割り当てられているフレーム内で処理がしきれなくなってしまい、ラグが発生してしまいます。

そこで、.drawingGroup()を適用して、ラグを解消します。

  CloudView()
      .drawingGroup() // これを加えるだけ

drawinggroup(opaque:colormode:)

このメソッドを使うことで、画面上には見えないオフスクリーン上でMetal APIを使用して、1つのイメージにまとめて描画することでパフォーマンスを改善させています。
実際に、CPUの使用率も、適用前の112%から33%ほどまで下がっていました。

Cherry Blossoms! App:

反対に、桜が散っていくアニメーションがあるViewでは、.drawingGroup()を適用することで逆に、動きが遅くなり、不安定になってしまいました。この理由はこのアプリの花びらは削除と作成を繰り返すため、このメソッドで解決するようなシチュエーションではないとのことです。

このように、drawingGroup()を使わない方よい例は以下の4つです。

1. Views with Dynaminc Content → Viewのコンテンツが頻繁に変更されるもの
2. Text Views → テキストを表示するときのレンダリングは複数なレイアウトとグリフ管理があるため
3. Views with interactions → 予期しない変更が生じる可能性がある
4. Special Visual effect like some blending modes maynot work properly

本セッション内容は、SwiftUIを普段使っている私にはとても勉強になりました。レンダーループについては、サンプルコードを手元で動かしつつ、Instruments等を使ってパフォーマンスに関して色々実際に検証してみたいと思いました。

参考資料:

• https://developer.apple.com/videos/play/tech-talks/10855/
• https://developer.apple.com/videos/play/wwdc2018/219/
• https://developer.apple.com/videos/play/wwdc2020/10077/
• https://developer.apple.com/videos/play/tech-talks/10857/?time=1091
• (My own talk that talks about Rendering on UIKit) https://www.youtube.com/watch?v=gbAjrPqFLUY

さいごに

今回は一般参加で、try! Swift Tokyo2025に参加しました!

次回は別の形(スタッフやスピーカーなど)で参加してtry! Swiftのコミュニティの発展に貢献したいと感じました。

英語話者が多いイベントということで、久しぶりに英語を聞いたり、話したりしましたが学生時代より聞き取れなかったり、言葉が出ないということがあったので英会話をまた始めたいなと思うきっかけになりました。

セッションでは、技術的な知識だけではなく、取り組む姿勢や心持ちみたいなことも話されている方でいて、様々な面で良い刺激を受けることができました。来年の開催も楽しみにしています！

HealthCare Innovation Group(HIG)¹の橋本です。

先日参加したSwiftZoomin#20の内容から、Swift6移行に向けて理解が必要なSwift Concurrencyの重要な概念について簡単にまとめました。

SwiftZoomin#20の動画は、次のリンク先からYouTube上で視聴可能です。

• 感覚的に理解するConcurrency: Swift 6はIsolationとSendableを用いてどのようにデータ競合を防止するか

Swift6移行に向けて、重要な概念3つ

以下３つの概念についてまとめいきます。

• Isolation domain
• Isolation boundary
• Sendable

Isolation domain

隔離=Isolationする領域のことをIsolation domainと呼びます。
Isolation domainの重要な特性は、一つのIsolation domainのなかでは同時に一つの処理しか実行されないことです（＝1つのIsolation domainの中で並行実行されることはないことと同義）

参考

• Isolation Domains | Migrating to Swift 6

actor

actorというのは、1つの領域で隔離(Isolation)することでデータ競合を防いでいます。

最も馴染み深いのは、MainActorのIsolation domainであり、actorのインスタンスに紐づいたIsolation domainも存在します。

MainActorのIsolation domainはMain Actorで保護された領域を表します。
Actorの場合は、ActorのインスタンスごとにIsolation domainをもち、同じactorでもインスタンスが異なれば、それぞれ異なるIsolation domainを持ちます。

actor Counter {...}

let a = Counter() // aのIsolation domain、aとbは別のIsolation domainである。
let b = Counter() // bのIsolation domain、aとbは別のIsolation domainである。

参考

• Actor | Apple Developer Documentation

Isolation boundary

Isolation domainが複数存在しているときのそれぞれのIsolation domainの間の境界のことをIsolation boundaryと呼びます。

アプリにおいては、それぞれのIsolation domain間でIsolation boundaryを超えて情報のやり取りをしないといけない場面が多々あります。

このIsolation boundaryを超えて値を受け渡すために、次のSendableが必要になってきます。

Sendable

Sendable 並行にアクセスされても安全な型だけが準拠できるプロトコル
Sendableの特徴は、Sendableに準拠した型の値だけがIsolation boudnaryを超えられるようになります。
つまり、Sendableを使うことで実行時にデータ競合が起こらないことをコンパイル時にチェックできるように、型の問題とすることで実現しています。

non-Sendable

Sendableに対して、non-Sendableな値は、Isolation boundaryを超えることができません。

• Sendable | Apple Developer Documentation
• Sendable Types | Migrating to Swift 6
• Sendable Types | The Swift Programming Language

Sendableを体感する

上記のBoxクラスをSendableに準拠させて、並行にアクセス可能にさせてみる。

final class Box: Sendable {
    var value: Int = 0 // ここでエラー(Stored property 'value' of 'Sendable'-conforming class 'Box' is mutable)
}

そうすると、次のようにSendableに準拠すること自体がエラーであることがわかります。
Box型のプロパティValueが可変状態のため、並行にアクセスすると危険である旨のメッセージが出てきます。

Stored property 'value' of 'Sendable'-conforming class 'Box' is mutable

ここで、varではなく、letだったらどうなるか考えてみます。

final class Box: Sendable {
    let value: Int = 0
}

letにすることで、Boxクラスのエラーは解消されます。

valueプロパティが定数になるため、run()メソッド内でbox.balue = -1で書き込みをしていた箇所がコンパイルエラーになります。

この部分を読み込むだけのprint(box.value)とすれば、データ競合を起こさない安全なコードとすることができます。データ競合は、並行にアクセスする少なくとも１つで書き換えが起こっているときに生じるものであるため、今回のように読み込むだけであれば、データ競合の危険性はありません。

func run() {
    let box: Box = .init()

    Task {
        // box.value = -1 // Cannot assign to property: 'value' is a 'let' constant
        print(box.value)
    }

    Task {
        print(box.value)
    }
}

Isolation boundaryを体感する

Sendableに準拠していないnon-SendableなBoxクラスがIsolation boundaryを超えるとコンパイルエラーが出る例を示します。

final class Box {
    var value: Int = 0
}


actor A {
    var box: Box?
    func setBox(_ box: Box) {
        self.box = box
    }
}


func run() async {
    let box: Box = .init()
    let a: A = .init() // actor A のインスタンスa

   await a.setBox(box) // actor A のインスタンスaにboxを渡す　⇐ boxがIsolation bounadaryを超えて、actor AのインスタンスaのIsolation domainに入る。
// ここで次のエラーメッセージが出る。
// Sending 'box' risks causing data races

    print(box.value)
}

Sendableに準拠していないBoxクラスのboxインスタンスがIsolaton boudaryを超えたため、このエラーがでてきます。

このように、Isolaton boudaryが存在していることを体験できました。

おわりに

SwiftZoomin#20（感覚的に理解するConcurrency: Swift 6はIsolationとSendableを用いてどのようにデータ競合を防止するか）動画前半の内容について私なりにまとめさせていただきました（@koherさん、大変わかりやすく説明いただきありがとうございました）。

Swift6への移行は、コンパイル時にデータ競合が起こる可能性のある箇所を事前につぶすことができるので、アプリの品質向上に直結するため、ビジネス的にもとても有用なものだと思っております。

本記事がSwift6移行に向けて、少しでも参考になれば幸いです。

はじめに

HealthCare Innovation Group(HIG)¹の橋本です。

初めてiOSDC Japan 2024にオフライン参加してきました！

参加報告として、いくつかのセッションとその内容を紹介したいと思います！

iOSDC Japanとは

国内を中心に多くのiOS開発に関わる多くの人々が集まるiOSのDeveloper Conference（開発者会議）です。

公式サイトの説明は次のようになっており、技術的な話題から開発者同士の繋がりを持てるパーティや懇親会などの様々なイベントがあります。

iOSDC Japan 2024はiOS関連技術をコアのテーマとしたソフトウェア技術者のためのカンファレンスです。今年もリアル会場とオンライン配信のハイブリッド開催を予定しています。
日本中、世界中から公募した知的好奇心を刺激するトークの他にも、パンフレットに掲載された技術記事、自分のペースでゆっくり参加できるポスターセッション、気持ちを盛り上げるネイルアートやフェイスペインティング、オープニングパーティ & 懇親会などなど、初心者から上級者まで楽しめるコンテンツがみなさんを待っています。
8月22日（木）〜 8月24日（土）はお祭りです！お楽しみに！！

公式HP: https://iosdc.jp/2024/

特に気になったセッションの紹介

視聴したセッションの中で、印象に残ったものの紹介と感想を記載します。

• 座談会 「Strict ConcurrencyとSwift 6が開く新時代: 私たちはどう生きるか？」 by shiz
• MV State PatternでSwiftUIを受け入れる by Hiroma Tsuchiya
• Swift 6のTyped throwsとSwiftにおけるエラーハンドリングの全体像を学ぶ by koher

座談会 「Strict ConcurrencyとSwift 6が開く新時代: 私たちはどう生きるか？」 by shiz

発表資料: https://speakerdeck.com/shiz/zuo-tan-hui-strict-concurrencytoswift-6gakai-kuxin-shi-dai-si-tatihadousheng-kiruka

発表概要と感想

iOS界隈の強強エンジニアの方々の座談会で、Swift6への移行に向けてのStrict Concurrency対応についてお話されていました。

Swift 6では、Actorを使ったデータ競合防止の仕組みがさらに強化されます。特に、Actor間で扱うデータの安全性がコンパイラで厳密にチェックされるため、既存のコードがコンパイルエラーとなる可能性があります。これにより、並行処理の安全性が一層向上しますが、我々はコードの修正が必要になってくるケースがあります。

『いつまでにStrict Concurrency 対応をするべきか。』
この問いに答えとしては、Xcode 16でもSwift5言語モードを利用可能であるため、ひとまずは直ぐにコンパイルエラーまみれになって急に動かなくなるということは避けられそうです。

この座談会でお聞きして、Swift6への移行に向けて以下の知識をしっかりと理解する必要があると感じました。

• Swift Concurrency
  • Sendable
  • Actor
  • isolation

私や開発チームとしては、Complete Strict Concurrency Checkを使って、まずは既存のコードでSwift6にあげるとどこがコンパイルエラーになるかを洗い出しをするところから作戦を立てて行きたいと思います。

本セッション内で紹介のあった事例別！Strict Concurrency対応方法やSwiftコミュニティのSwift6へのマイグレーションガイド（Migrating to Swift 6）を参考にしたいです。また、日本語訳版についてもSwift 6への移行も既にまとめて頂いており、めちゃくちゃありがたいです。次のApple公式ドキュメントやサンプルコードも参考にしたいと思います。

• Adopting strict concurrency in Swift 6 apps
• Updating an app to use strict concurrency | Apple Developer Documentation

MV State PatternでSwiftUIを受け入れる by Hiroma Tsuchiya

発表概要と感想

発表内容は、MV State Patternというアーキテクチャに関する説明と、採用理由とその実装方法について紹介しているセッションでした。

MVVM x SwiftUIの組み合わせで感じた違和感

発表者の開発チームでは、MVVMとSwiftUIでの開発経験がありその中でいくつかの違和感や課題を感じていたとのことです。
具体的に、感じていた違和感は次の２つがあったとのことです。

1. ViewModelを精密に構築するほど、SwiftUIフレームワークの機能(各種プロパティラッパー)を捨てるというジレンマがあった
2. データバインディングの機能はSwiftUIにおいてすでにViewに組み込まれているため、UIKit時代の役割のままViewModelを持ち込む必要性に疑問視

2.に関して、発表者の話にあったようにSwiftUIはそもそも@State・@Binding・@ObservedObjectなどを使うことで、ビューとデータの間に自動的な連携が行われれる機能があります。状態が変わればUIが更新され、UIでユーザーが入力した内容がデータに反映される、という関係が自動的に保たれているので、ユースケースによってはViewModelの必要性は低くなることには納得しました。

また、Apple公式ドキュメントでも、次のように言及されています。

https://developer.apple.com/documentation/swiftui/monitoring-model-data-changes-in-your-app

Traditionally, you use a view controller to move data back and forth between the model and the UI, but SwiftUI handles most of this synchronization for you. To update views when data changes, you make your data model classes observable objects, publish their properties, and declare instances of them using property wrappers.

MV State Patternとは

Appleの公式ドキュメントやサンプルコードで使われていたアーキテクチャに対して、開発者コミュニティがMV State Patternと名前をつけてあげたアーキテクチャみたいです。
このMVState Patternのデータフローパターンのコンセプトは次のようになっています。

• SwiftUIがどのように、StateとViewを結びつけているかという構造と全く同じです。具体的には次のような特徴を持ちます。
  • ユーザーがアクションを実行することで状態が更新され、再レンダリングを起こす
  • 単方向のループのように動作し、状態が更新されればいつでも新しいバージョンのViewが作られる
  • ユーザーの入力に限定されず、タイマーや通知などの外部からの状態変更もループに組み入れられる

これは、WWDC2019のData Flow Through SwiftUIのセッションで登場した図と同じ内容です。

https://developer.apple.com/videos/play/wwdc2019/226/

Viewにバリデーションや特定のコンポーネントにのための処理を含み、MVVMでいうViewModelの役割も持ちます。しかし、ViewModelで書くような処理をすべて、Viewに持たせるため、コードが長くなる傾向がありました。

Viewが大きくなることに対する対応策

1. MARKの活用

   • Main View, SubView, ViewLogicを次のようにコード上に目印として記載する。（ミニマップからMARKの箇所に飛べるのも便利。）

     // MARK: MainView ... // MARK: SubView ... // MARK: ViewLogic ...

2. ViewからViewLogicへ切り出す

   • メリット: Viewプロトコル準拠ではなくなるため、テストコードも容易にかける

     final class SomeViewLogic { ... init(...) { } var title: String? { ... } }

MV State Patternのメリット・デメリット

主なメリットは、SwiftUIのシンプルさに従ったアーキテクチャであることによる学習コストの低さとシンプルさであり、
デメリットは、(MVVMと比べると、)プレゼンテーション層の関心の分離が甘く、境界が曖昧になりやすいこととの紹介がありました。つまり、Fat Viewに陥る可能性が高いといえます。先程紹介したように、この問題には、MARKの活用とViewLogicへの切り出しを行い、コードをクリーンに保つ必要があります。

Viewが大きくなることに対する対応策は、アーキテクチャの種類にかかわらず、Fat-viewに対応する方法として有効であるため、私の関わるアプリにおいても参考にしたいと思いました。

Swift 6のTyped throwsとSwiftにおけるエラーハンドリングの全体像を学ぶ by koher

発表資料: https://speakerdeck.com/ridwy/kong-jian-bideohuomatuto-mv-hevcgaxie-sicuo-rushi-jie

発表概要と感想

こちらのセッションでは、Swift 6から導入されるTyped throwsとSwiftにおけるエラーハンドリングの全体像を知ることができました。

ここでは、発表内容から大変わかりやすかったTyped Throwsが解決する問題とその解決方法を簡単に紹介したいと思います。

Untyped throwsの問題

これまでのthrowsのUntyped throwsの問題点を解決する方法として、Typed throwsが導入されます。

次のようなparseIntを関数をエラーハンドリングする例を考えます。

// Stringを受け取って、Intを返す関数
func parseInt(_ value: String) throws -> int
    if value.isEmpty {throw ParseError.emptyValue }
        guard let number = Int(value) else {
            if value.contains(/^[-]\d+$/) {
                throw ParseError.outOfBounds(value)
            } else {
                throw ParseError.illegalFormat(value)
            }
        }
    return number
}

enum ParseError: Error {
    case emptyValue
    case illegalFormat(String)
    case outOfBounds(String)
}

上記の関数をdo-catchを使ってハンドリングすると次のようになります。

// ハンドリングする側
do {
    let number: Int = try parseInt(string) //　ParseErrorしか返さない関数
    print(number)
} catch {
    print(error) // 暗黙のerrorはany Error型になってしまう。
}

この書き方だと、catch節の中のerrorはany Error型となってしまいます。
次に、ParseError型でハンドリングするように書き直します。

ParserErrorハンドリングできるように、変更

//
do {
    let number: Int = try parseInt(string) //　ParseErrorしか返さない関数
    print(number)
} catch let error as ParseError {
    switch error { // ParseErrorを返す
    print(error) // any Error型になってしまう。
    case .emptyValue: ...
    case .illegalFormat(let value): ...
}

しかし、このコードだとcatchが網羅的ではないよと次のエラーがでます。

　Errors thrown from here are not handled because the enclosing catch is not exhaustive

parseInt()はParseErrorしかthrowしないが、コンパイラからはそれがわからないため、あらゆるエラーをスローすると判断します。catch節でParseErrorをハンドルしているが、コンパイラ側からはany Errorが投げられると判断され、網羅的ではないよとエラーがでます。これのワークアラウンドとして次の方法があります。

// ParserErrorハンドリングするように`preconditionFailure()`を追加するように、変更します。

do {
    let number: Int = try parseInt(string) //　ParseErrorしか返さない関数
    print(number)
} catch let error as ParseError {
    switch error { // ParseErrorを返す
    print(error) // any Error型になってしまう。
    case .emptyValue: ...
    case .illegalFormat(let value): ...
    }
} catch {
    preconditionFailure("Never reaches here.")
}

これがUntyped Throwsの問題であり、これを解決するのがTyped Throwsになります。

Typed throwsによる上記の問題の解決方法

Typed throwsでは、さきほどの関数parseIntを次のようにして、エラーの型を指定できるようになります。

func parseInt(_ value: String) throws(ParseError) -> Int

do {
    let number = try parseInt(string)
    print(number)
} catch {
    switch error { // typed throwsにより、any Error型ではなく、ParseError型を解釈できるようになる。
    ...
}

最後に、Typed throwsはswift-evolution上で安易に使うべきではないと繰り返し記載されているので、本当に使う必要があるのかをよく考える必要があることを学びました。swift-evolutionのwhen to use typed throwsの内容を確認してみたいと思います。

本セッションでは、安易に使うべきではない理由として次の２つが挙げられていました。

1. エラーの型は変化しやすい
2. エラーが網羅的にハンドリングされることは少ない

Typed throwsの詳細を確認したい方は、次のswift-evolutionのSE-0413: Typed throwsを確認してみてください。

また、Typed throwsのお話だけではなく、後半のエラーハンドリングの全体像のお話は大変参考になりました。
エラーハンドリングの考え方が詳しく記されている次のドキュメントをもとにお話をされていましたので、時間があるときに目を通しておきたいと思います。このドキュメントは、swift2がリリースされたときの公開されたもののようです。

• Error Handling Rationale and Proposal

エラー処理を書くときに全体像を一度思い出して、この書き方で良いだろうかと自問自答したいなと思いました。koherさんがiOSDC2017年のセッションiOSDC Japan 2017 09/16 Track B 11:20 / 具体例とクイズで学ぶ、Swiftの4種類のエラーの使い分け / Yuta Koshizawaでも同じようにエラーハンドリングの全体像のお話をされていたので、こちらも合わせて視聴することをおすすめします。

上記以外で面白かった、参考になったセッション

Appleの新しいプライバシー要件対応：ノーコード アプリプラットフォームの実践事例 by Nao-RandD / ナオランド

私自身、担当している案件でプライバシーマニフェスト対応を進めており、再度プライバシーマニフェストの対応方法について歴史や今後についてまで紹介されており大変参考になりました。

発表資料: https://speakerdeck.com/nao_randd/applenoxin-siipuraibasiyao-jian-dui-ying-nokodoapuri-puratutohuomunoshi-jian-shi-li

ヤプリさんのテックブロクにもプライバシーマニフェスト対応について大変詳しく記載されているので、これからプライバシーマニフェスト対応を進める方にはとても参考になると思います。

• ヤプリiOSエンジニアの新プライバシー要件対応① | 時系列で振り返り、関連用語を理解する
• ヤプリiOSエンジニアの新プライバシー要件対応② | 実際に取り組んだ内容を大公開！
• ヤプリiOSエンジニアの新プライバシー要件対応③ | ノーコードアプリプラットフォームの運用体制も大公開！

現状は、プライバシーマニフェストのApple側のレビューはそこまで厳しくないようなので、今後段階的に厳しくなっていく可能性もあると思うのでプライバシーマニフェストに関する動向は引き続きウォッチしていきたいと思います。

空間ビデオフォーマット、MV-HEVCが写し撮る世界 by なめき　ちはる

Apple Vision Proでの空間ビデオフォーマットについてやどうやって立体視を実現しているかなど、人の目の仕組みにも触れていてとても興味深いセッションでした。

• 発表資料: https://speakerdeck.com/ridwy/kong-jian-bideohuomatuto-mv-hevcgaxie-sicuo-rushi-jie

これからの時代の新標準！Apple製テストフレームワーク「SwiftTesting」への移行とトラブルシューティング

新しいテストフレームワークSwiftTestingの概要とXCTestからの移行作業についてお話されていて、大変参考になるセッションでした。

移行作業の全体像だったり、XCTestをSwiftTestingの記法に置き換えてくれるツール(giginet/swift-testing-revolutionary)も知れたので、大変有意義な5分間でした。

発表資料: https://speakerdeck.com/uetyo/korekaranoshi-dai-noxin-biao-zhun-swifttestinghenoyi-xing-totoraburusiyuteingu

医療アプリ開発の最前線 - 安全性と生産性の両立への挑戦 by Shogo Yoshida

医療アプリ開発を通じて得た安全性と生産性の両立に関する知見を共有頂いたありがたいセッションでした。

具体的には、次のような知見が紹介されました。

• 継続的なリファクタリングに取り組みつつ、Architecture Decision Record(ADR)を残すこと
• トランクベース開発を採用
• OpenAPI Generatorを使ったAPI仕様に合わせたリクエスト、モデルのコードの自動生成
• Renovateを使用してライブラリの自動アップデートの管理
• テスト自動化サービスMagicPodの活用

やはり、品質を高めつつ、生産性を高める方法は自動化することがとても大事だなとしみじみ感じました。

発表資料: https://speakerdeck.com/medley/yi-liao-apurikai-fa-nozui-qian-xian-an-quan-xing-tosheng-chan-xing-noliang-li-henotiao-zhan

さいごに

はじめてオフライン参加した今年のiOSDCは、現地参加ならではのコンテンツを楽しめたり、Xで会話したことがあるiOSエンジニアの方にお会いしてお話ができたりできたと、とても有意義な時間でした。

また、他の企業さんのプロダクトのコードをアンカンファレンスで、実際に見させて頂く機会をもらったり、貴重な経験ができました。

2025年は私自身なにかしらの形でiOSDC Japanに貢献できればと思っています。今から来年のiOSDC Japan 2025が楽しみです〜！

参考

• iOSDC Japan 2024
• 座談会 「Strict ConcurrencyとSwift 6が開く新時代: 私たちはどう生きるか？」 by shiz
• 座談会 「Strict ConcurrencyとSwift 6が開く新時代: 私たちはどう生きるか？」
• 事例別！Strict Concurrency対応方法
• Migrating to Swift 6
• Swift 6への移行
• Adopting strict concurrency in Swift 6 apps
• Updating an app to use strict concurrency | Apple Developer Documentation
• MV State PatternでSwiftUIを受け入れる by Hiroma Tsuchiya
• Monitoring model data changes in your app | Apple Developer Documentation
• Data Flow Through SwiftUI - WWDC19 - Videos - Apple Developer
• Swift 6のTyped throwsとSwiftにおけるエラーハンドリングの全体像を学ぶ by koher
• Swift 6のTyped throwsとSwiftにおけるエラーハンドリングの全体像を学ぶ
• SE-0413: Typed throws
• Error Handling Rationale and Proposal
• iOSDC Japan 2017 09/16 Track B 11:20 / 具体例とクイズで学ぶ、Swiftの4種類のエラーの使い分け / Yuta Koshizawa
• Appleの新しいプライバシー要件対応：ノーコード アプリプラットフォームの実践事例 by Nao-RandD / ナオランド
• Appleの新しいプライバシー要件対応： ノーコードアプリ プラットフォームの実践事例
• ヤプリiOSエンジニアの新プライバシー要件対応① | 時系列で振り返り、関連用語を理解する
• ヤプリiOSエンジニアの新プライバシー要件対応② | 実際に取り組んだ内容を大公開！
• ヤプリiOSエンジニアの新プライバシー要件対応③ | ノーコードアプリプラットフォームの運用体制も大公開！
• 空間ビデオフォーマット、MV-HEVCが写し撮る世界 by なめき　ちはる
• 空間ビデオフォーマット、MV-HEVCが写し撮る世界 | Speaker Deck
• これからの時代の新標準！Apple製テストフレームワーク「SwiftTesting」への移行とトラブルシューティング
• これからの時代の新標準！SwiftTestingへの移行とトラブルシューティング
• giginet/swift-testing-revolutionary
• 医療アプリ開発の最前線 - 安全性と生産性の両立への挑戦 by Shogo Yoshida
• 医療アプリ開発の最前線 - 安全性と生産性の両立への挑戦 -

はじめに

HealthCare Innovation Group(HIG)¹の橋本です。

先週末注文していたAirPods Pro第2世代が今日手元に届きました!

約4年間使っていたAirPods Pro第1世代の調子が悪くなってしまったため、買い換えました。

せっかく新しいAirPods Proが届いたので、なにかできることないかな〜と思いながら、AirPods Proの機能一覧を見ていました。

私はその中の1つ、空間オーディオ機能でヘッドトラッキングしていることに目をつけ、頭の角度の取得をしてみました。

環境

• OS: macOS Sonoma 14.5
• Xcode: 15.4 (15F31d)
• Swift: 5.10
• AirPods Pro(第2世代)

※ 空間オーディオ機能搭載端末
AirPods(第３世代)、AirPods Pro(全世代)、AirPods Max
(参考URL: AirPodsユーザガイド 空間オーディオとヘッドトラッキングを操作する)

今回作ったもの

AirPodsProで取得した頭の角度でリアルタイムにキャラクター動かせるミニアプリ。

キャラクターが動いている部分は、次のように、私がAirPods Proをつけた状態で頭を傾けたり、回転したりしています。かなりよい感度で表示できているなと感じます。

このミニアプリで使用したフレームワークや各種APIを紹介していきたいと思います。

CoreMotionフレームワークとは

CoreMotionとは、各種Appleが提供するハードウェア（iOS, iPadOS, watchOS, visionOS device）のモーションデータを取得できるフレームワークです。

CoreMotionフレームワークのひとつのクラスとして、CMHeadphoneMotionManagerがあります。

CMHeadphoneMotionManager

このクラスを使うことで名前の通り、ヘッドフォンのモーション情報をアプリに提供することが可能になります。

使用するためには、Info.plistでNSMotionUsageDescriptionキーを追加し、モーションデータを使用する具体的な理由を記載する必要があります。

今回使用するCMHeadphoneMotionManagerが持つ主なメソッドについて、説明します。

isDeviceMotionAvailable

接続している端末でCoreMotionが使えるか否かをBool値で返すメソッド。

startDeviceMotionUpdates(to:withHandler)

モーションデータの更新を開始し、データの更新を指定のキューに送信するメソッド。

stopDeviceMotionUpdate()

モーションデータの更新を停止するメソッド。

実際にアプリを作ってみる

事前準備

CoreMotionフレームワークが使えるように、Info.plistにNSMotionUsageDescriptionキーを追加、説明を記載します。

Info.plist

project.pbxproj

INFOPLIST_KEY_NSMotionUsageDescription = "To sync the movements of the character’s head on the screen with your head movements for an enhanced interactive experience.";

これで、次のようにモーションデータを取得する前に、許可を求められるポップアップが表示されます。

HeadTrackingを管理するクラスを用意する

HeadTrackingを監視するために、HeadTrackingManagerクラスを定義します。このクラスを使うことで、モーションデータを取得し、リアルタイムでSwiftUIビューに反映させることができます。

次に、コード全体を共有します。

import CoreMotion
import Foundation

class HeadTrackingManager: ObservableObject {
    private var motionManager: CMHeadphoneMotionManager
    @Published var pitch: Double = 0.0
    @Published var roll: Double = 0.0
    @Published var yaw: Double = 0.0

    init() {
        motionManager = CMHeadphoneMotionManager()
    }
    // モーションデータのトラッキングを開始する
    func startTracking() {
        // 接続している端末でCoreMotionが使えるか否かを確認する
        guard motionManager.isDeviceMotionAvailable else {
            print("Headphone motion data is not available.")
            return
        }

        // モーションデータの更新を開始し、メインキューに送信する。
        motionManager.startDeviceMotionUpdates(to: .main) { [weak self] (motion, error) in
            guard let self = self, let motion = motion, error == nil else {
                print("Error: \(String(describing: error))")
                return
            }

            // 正常にモーションデータ取得後、頭の角度を取得する
            Task {
                await self.updateMotionData(motion)
            }
        }
    }

    // モーションデータの更新を停止する
    func stopTracking() {
        motionManager.stopDeviceMotionUpdates()
    }

    // モーションデータから頭の角度（ピッチ、ロール、ヨー）を取得する
    private func updateMotionData(_ motion: CMDeviceMotion) async {
        await MainActor.run {
            self.pitch = motion.attitude.pitch
            self.roll = motion.attitude.roll
            self.yaw = motion.attitude.yaw
        }
    }
}

全体概要

このクラスはObservableObjectプロトコルに準拠させ、SwiftUIビューと連携して動作させるようにしています。

各プロパティの説明

• motionManager: CMHeadphoneMotionManager
  MHeadphoneMotionManager のインスタンスで、ヘッドモーションデータの取得を管理する。
• @Published var pitch: Double
  頭のピッチ（上下の回転角度）を表す。
• @Published var roll: Double
  頭のロール（左右の傾き角度）を表す。
• @Published var yaw: Double
  頭のヨー（水平面内の回転角度）を表す。
  これらのプロパティは、　@Publishedが付与されているので、変更があったときにはビューを自動的に更新する。

次に、各メソッドを説明します。

startTracking()

モーションデータの取得を開始するメソッド。

func startTracking() {
        // 接続している端末でCoreMotionが使えるか否かを確認する
        guard motionManager.isDeviceMotionAvailable else {
            print("Headphone motion data is not available.")
            return
        }

        // モーションデータの更新を開始し、メインキューに送信する。
        motionManager.startDeviceMotionUpdates(to: .main) { [weak self] (motion, error) in
            guard let self = self, let motion = motion, error == nil else {
                print("Error: \(String(describing: error))")
                return
            }

            // 正常にモーションデータ取得後、頭の角度を取得する
            Task {
                await self.updateMotionData(motion)
            }
        }
    }

モーションデータを提供できるかどうかをisDeviceMotionAvailableで確認します。その後、モーションデータの更新を開始し、データが取得されるたびにTaskクロージャ内で、updateMotionData(_:)メソッドを呼び出します。

stopTracking()

モーションデータの取得を停止するメソッド。stopDeviceMotionUpdates() メソッドを呼び、モーションデータの取得を停止します。

func stopTracking() {
    motionManager.stopDeviceMotionUpdates()
}

updateMotionData(_ motion: CMDeviceMotion) async

モーションデータを取得・更新するメソッド。

private func updateMotionData(_ motion: CMDeviceMotion) async {
        await MainActor.run {
            self.pitch = motion.attitude.pitch
            self.roll = motion.attitude.roll
            self.yaw = motion.attitude.yaw
        }
    }

UIを安全に更新するために、MainActor.run内でUIを更新することでUIスレッドの競合が発生しないようにしています。

取得した姿勢データattitudeを使用して、pitch、roll、yawを更新します。

Viewに反映させる

最後に、取得したデータを元にキャラクターを３次元空間でぐりぐり動かせるようにします。

Image()をロール、ピッチ、ヨーで３次元回転させるように、.rotation3DEffect()を使用します。

ヨーに関しては、内側のカメラで自分を撮影するときと同様に、キャラクターが動くようにY軸周りの回転角を負の値に設定しています。

Image("monster")
    .resizable()
    .aspectRatio(contentMode: .fit)
    .frame(width: 250, height: 250)
    .rotation3DEffect(Angle(radians: headTrackingManager.roll), axis: (x: 0, y: 0, z: 1))
    .rotation3DEffect(Angle(radians: headTrackingManager.pitch), axis: (x: 1, y: 0, z: 0))
    .rotation3DEffect(Angle(radians: -(headTrackingManager.yaw)), axis: (x: 0, y: 1, z: 0))

ボタンを押下するごとにHeadTrackingの計測状態と停止状態が入れ替わるようにします。

Button {
    if isTracking {
        headTrackingManager.stopTracking()
    } else {
        headTrackingManager.startTracking()
    }
    isTracking.toggle()
} label: {
    Text(isTracking ? "Stop Tracking" : "Start Tracking")
        .padding()
        .background(isTracking ? Color.red : Color.green)
        .foregroundColor(.white)
        .cornerRadius(8)
}

このボタンを押下することで、HeadTrackingが開始します。

全体のコードは次に記載しているので、手元で試してみてください。

コード全体

import SwiftUI

@main
struct HeadTrackingApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

import CoreMotion
import Foundation

class HeadTrackingManager: ObservableObject {
    private var motionManager: CMHeadphoneMotionManager
    @Published var pitch: Double = 0.0
    @Published var roll: Double = 0.0
    @Published var yaw: Double = 0.0

    init() {
        motionManager = CMHeadphoneMotionManager()
    }

    func startTracking() {
        guard motionManager.isDeviceMotionAvailable else {
            print("Headphone motion data is not available.")
            return
        }

        motionManager.startDeviceMotionUpdates(to: .main) { [weak self] (motion, error) in
            guard let self = self, let motion = motion, error == nil else {
                print("Error: \(String(describing: error))")
                return
            }

            Task {
                await self.updateMotionData(motion)
            }
        }
    }

    func stopTracking() {
        motionManager.stopDeviceMotionUpdates()
    }

    private func updateMotionData(_ motion: CMDeviceMotion) async {
        await MainActor.run {
            self.pitch = motion.attitude.pitch
            self.roll = motion.attitude.roll
            self.yaw = motion.attitude.yaw
        }
    }
}

import SwiftUI

struct ContentView: View {
    @StateObject private var headTrackingManager = HeadTrackingManager()
    @State private var isTracking = false

    var body: some View {
        VStack(alignment: .center) {
            Text("Your head position")
                .font(.largeTitle)

            Image("monster")
                .resizable()
                .aspectRatio(contentMode: .fit)
                .frame(width: 250, height: 250)
                .rotation3DEffect(Angle(radians: headTrackingManager.roll), axis: (x: 0, y: 0, z: 1))
                .rotation3DEffect(Angle(radians: headTrackingManager.pitch), axis: (x: 1, y: 0, z: 0))
                .rotation3DEffect(Angle(radians: -(headTrackingManager.yaw)), axis: (x: 0, y: 1, z: 0))

            HStack {
                VStack() {
                    Text("Head Tracking Data")
                        .font(.title)
                    Text("Pitch: \(headTrackingManager.pitch)")
                    Text("Roll: \(headTrackingManager.roll)")
                    Text("Yaw: \(headTrackingManager.yaw)")
                }
            }
        }
        HStack {
            Button {
                if isTracking {
                    headTrackingManager.stopTracking()
                } else {
                    headTrackingManager.startTracking()
                }
                isTracking.toggle()
            } label: {
                Text(isTracking ? "Stop Tracking" : "Start Tracking")
                    .padding()
                    .background(isTracking ? Color.red : Color.green)
                    .foregroundColor(.white)
                    .cornerRadius(8)
            }
        }
    }
}

さいごに

CMHeadphoneMotionManagerを使うことでとても簡単にHeadTrackingを行うことができました！

今後は、今回取得した頭の角度データを時系列データとして扱い、HealthKitフレームワークのHKHealthStoreに保存したりして健康促進に活用できないか等、色々検討したいと思います。

参考

• AirPods Pro（第2世代）
  https://www.apple.com/jp/airpods-pro/
• 空間オーディオとヘッドトラッキングを操作する
  https://support.apple.com/ja-jp/guide/airpods/dev00eb7e0a3/web
• AirPods Proの加速度センサーの値を取得する【iOS14】
  https://qiita.com/tukutuku_tukuyo/items/ea949ee2dbb499d6e7ca
• Core Motion | Apple Developer Documentation
  https://developer.apple.com/documentation/coremotion
• CMHeadphoneMotionManager | Apple Developer Documentation
  https://developer.apple.com/documentation/coremotion/cmheadphonemotionmanager
• isDeviceMotionAvailable | Apple Developer Documentation
  https://developer.apple.com/documentation/coremotion/cmmotionmanager/1616094-isdevicemotionavailable
• stopDeviceMotionUpdates() | Apple Developer Documentation
  https://developer.apple.com/documentation/coremotion/cmmotionmanager/1616115-stopdevicemotionupdates
• startDeviceMotionUpdates(to:withHandler) | Apple Developer Documentation
  https://developer.apple.com/documentation/coremotion/cmmotionmanager/1616048-startdevicemotionupdates
• かわいいフリー素材集『いらすとや』
  https://www.irasutoya.com/

はじめに

HealthCare Innovation Group(HIG)¹の橋本です。

新しく登場した公式チュートリアルDevelop in SwiftのModels and persistence、Data editing and navigation、Relationships and queriesという3つのセクションでSwiftDataを学べるとのことで実際にやってみました。

今回は、1つ目の Models and persistence編 です。Models and persistenceセクションで学んだこと、Wrap-upのExtend your appの追加課題をやってみたので、これらについてまとめています。

本記事でわかること

• SwiftDataの基本的な使い方
  • SwiftDataの導入
  • @Model, @Queryの使い方
  • SwiftUIのViewとの連携
• Wrap-upのExtend your appの追加課題の解答例を知ることができる

環境

• OS: macOS Sonoma 14.4.1
• Xcode: 15.3 (15E204a)
• Swift: 5.10

SwiftDataとは

SwiftDataとは、データモデリングとデータの永続化のフレームワークです。
これまで主に使われていたCoreDataの後継として期待されています。
SwiftDataの主な特徴としては、

• SwiftUIとの連携
  • SwiftUIと深く統合されており、ユーザーインターフェースのためのデータバインディングが非常にスムーズ
• 宣言的データモデリング:
  • 属性、関係性、オブジェクトのバリデーションなどを宣言的に定義できること
• データ永続化:
  • オブジェクトが自動的に保存され、データ永続化が容易であること
• パフォーマンス最適化:
  • Appleのエコシステムに合わせて最適化されており、効率的なクエリ実行が可能

Save data

Models and persistenceセクションのSave dataを進めていきます。

Section 1~3(UI等のSwiftDataに直接関係のない事前準備)

以下は、Section1~3まで対応後のコードです。この時点ではSwiftDataを使用していないため、誕生日を登録しても、アプリキルすると登録したデータは削除されてしまいます。

import SwiftUI

@main
struct BirthdaysApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

import Foundation

struct Friend {
    let name: String
    let birthday: Date
}

import SwiftUI

struct ContentView: View {
    @State private var friends: [Friend] = [
        Friend(name: "Elton", birthday: .now),
        Friend(name: "Jenny Court", birthday: Date(timeIntervalSince1970: 0))
    ]

    @State private var newName = ""
    @State private var newDate = Date.now

    var body: some View {
        NavigationStack {
            List(friends, id: \.name) { friend in
                HStack {
                    Text(friend.name)
                    Spacer()
                    Text(friend.birthday, format: .dateTime.month(.wide).day().year())
                }
            }
            .navigationTitle("Birthdays")
            .safeAreaInset(edge: .bottom) {
                VStack(alignment: .center, spacing: 20) {
                    Text("New Birthday")
                        .font(.headline)
                    DatePicker(selection: $newDate, in: Date.distantPast...Date.now, displayedComponents: .date) {
                        TextField("Name", text: $newName)
                            .textFieldStyle(.roundedBorder)
                    }
                    Button("Save") {
                        let newFriend = Friend(name: newName, birthday: newDate)
                        friends.append(newFriend)
                        newName = ""
                        newDate = .now
                    }
                    .bold()
                }
                .padding()
                .background(.bar)
            }
        }
    }
}

Section４: Convert your structure to a SwiftData model

先程作成したFriend構造体をSwiftDataモデルに変換します。

以下、4点を対応します。

• SwiftDataフレームワークをインポートします
• モデルに対して、@Modelマクロのアノテーションを付与します
• structからclassに書き換えます
• classはstructと異なり、自動でイニシャライザが生成されないため、イニシャライザを用意します

Friend.swift

import Foundation
+ import SwiftData

+ @Model
- struct Friend {
+ class Frined {
    let name: String
    let birthday: Date

+    init(name: String, birthday: Date) {
+    self.name = name
+    self.birthday = birthday
}

Section5: Connect SwiftData and SwiftUI

SwiftDataとSwiftUIのViewを連携させます。
SwiftUIにおけるエントリーポイントである~App.swiftに次のコードを追加することで、SwiftDataによって永続化させたデータの保存場所とViewを連携させることができます。

BirthdaysApp.swift

import SwiftUI
+ import SwiftData

@main
struct BirthdaysApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
+                .modelContainer(for: Friend.self)
        }
    }
}

ContentView.swift

• friends配列を@Stateから@Queryに変更することで、@Queryマクロによって、モデルに変更があったときにSwiftUIViewに自動的に変更を伝えることができます。
• modelContextを環境変数として宣言します。
  • SwiftDataにおいて、ModelContextによってビューとモデルコンテナ間を接続し、データの取得、挿入、削除が可能になります。

import SwiftUI
+ import SwiftData

struct ContentView: View {
+   @Query private var friends: [Friend]
-   @State private var friends: [Friend] = [
-       Friend(name: "Elton", birthday: .now),
-       Friend(name: "Jenny Court", birthday: Date(timeIntervalSince1970: 0))
-   ]
+   @Environment(\.modelContext) private var context

    @State private var newName = ""
    @State private var newDate = Date.now

    var body: some View {
        NavigationStack {
            List(friends, id: \.name) { friend in
                HStack {
                    Text(friend.name)
                    Spacer()
                    Text(friend.birthday, format: .dateTime.month(.wide).day().year())
                }
            }
            .navigationTitle("Birthdays")
            .safeAreaInset(edge: .bottom) {
                VStack(alignment: .center, spacing: 20) {
                    Text("New Birthday")
                        .font(.headline)
                    DatePicker(selection: $newDate, in: Date.distantPast...Date.now, displayedComponents: .date) {
                        TextField("Name", text: $newName)
                            .textFieldStyle(.roundedBorder)
                    }
                    Button("Save") {
                        let newFriend = Friend(name: newName, birthday: newDate)
+                       context.insert(newFriend)
-                       friends.append(newFriend)
                        newName = ""
                        newDate = .now
                    }
                    .bold()
                }
                .padding()
                .background(.bar)
            }
        }
    }
}

Section6: Use model data to fill out the UI

モデルデータを使ってUIをいい感じに整えていきます。
主に以下2点を実現させます。

• 登録されているデータを日付順でソートする。
• 誕生日当日の人は、ケーキのマークがつくようにする。

BirthDayApp.swift
Section5から追加の修正なし。

Friend.swift

今日が誕生日かどうかを表すために、コンピューテッドプロパティとして、Bool型のisBirthdayTodayを用意します。

import Foundation
import SwiftData

@Model
class Frined {
    let name: String
    let birthday: Date

    init(name: String, birthday: Date) {
    self.name = name
    self.birthday = birthday

+   var isBirthdayToday: Bool {
+       Calendar.current.isDateInToday(birthday)
+   }
}

ContentView.swift

• 追加された人の誕生日を降順で並ぶように、@Queryを@Query(sort: \Friend.birthday)に修正します。@Query だけの場合は、いつも同じ並び順にはならないことに注意してください。
• SwiftDataは各モデルインスタンスに独自のIDを提供します。Listでは、@Model が提供する識別子を使うため、明示的なIDを削除します。つまり、List()の引数であるKeyPathを削除します。

import SwiftUI
import SwiftData

struct ContentView: View {
+   @Query(sort: \Friend.birthday) private var friends: [Friend]
-   @Query private var friends: [Friend]
    @Environment(\.modelContext) private var context

    @State private var newName = ""
    @State private var newDate = Date.now

    var body: some View {
        NavigationStack {
+           List(friends) { friend in
-           List(friends, id: \.name) { friend in
                HStack {
                    Text(friend.name)
                    Spacer()
                    Text(friend.birthday, format: .dateTime.month(.wide).day().year())
                }
            }
            .navigationTitle("Birthdays")
            .safeAreaInset(edge: .bottom) {
                VStack(alignment: .center, spacing: 20) {
                    Text("New Birthday")
                        .font(.headline)
                    DatePicker(selection: $newDate, in: Date.distantPast...Date.now, displayedComponents: .date) {
                        TextField("Name", text: $newName)
                            .textFieldStyle(.roundedBorder)
                    }
                    Button("Save") {
                        let newFriend = Friend(name: newName, birthday: newDate)
                        context.insert(newFriend)
                        newName = ""
                        newDate = .now
                    }
                    .bold()
                }
                .padding()
                .background(.bar)
            }
        }
    }
}

Wrap-up: Models and persistence

次のページのExtend your appの次の２つのお題に取り組みたいと思います。

https://developer.apple.com/tutorials/develop-in-swift/models-and-persistence-conclusion

Extend your app（ソートする基準の変更、降順or昇順）

Sort the birthday list by name instead of birthday.

これはとても簡単に修正できます。
@Query(sort: \Friend.birthday)を@Query(sort: \Friend.name)に変えるだけです。

@Query(sort: \Friend.name) private var friends: [Friend]

これで、誕生日順ではなく、名前の降順にできました。これを昇順にする場合は、引数order: .reverseを与えるだけで実現できます。

@Query(sort: \Friend.name, order: .reverse) private var friends: [Friend]

Add a notes property to Friend to plan how you’ll celebrate a friend’s birthday.

これもおまけ的な内容ですが、簡単に実装してみます。

import Foundation
import SwiftData

@Model
class Frined {
    let name: String
    let birthday: Date
+   let notes: String

+   init(name: String, birthday: Date, notes: String) {
-   init(name: String, birthday: Date) {
    self.name = name
    self.birthday = birthday
+   self.notes = notes

    var isBirthdayToday: Bool {
        Calendar.current.isDateInToday(birthday)
    }
}

import SwiftUI
import SwiftData

struct ContentView: View {
    @Query(sort: \Friend.birthday) private var friends: [Friend]
    @Environment(\.modelContext) private var context

    @State private var newName = ""
    @State private var newDate = Date.now
+   @State private var newNotes = ""

    var body: some View {
        NavigationStack {
            List(friends) { friend in
                HStack {
                    if friend.isBirthdayToday {
                        Image(systemName: "birthday.cake")
                    }
                    VStack {
                        Text(friend.name)
                            .bold(friend.isBirthdayToday)
+                       Text(friend.notes)
+                           .font(.caption2)
                    }
                    Spacer()
                    Text(friend.birthday, format: .dateTime.month(.wide).day().year())
                }
            }
            .navigationTitle("Birthdays")
            .safeAreaInset(edge: .bottom) {
                VStack(alignment: .center, spacing: 20) {
                    Text("New Birthday")
                        .font(.headline)
                    DatePicker(selection: $newDate, in: Date.distantPast...Date.now, displayedComponents: .date) {
                        TextField("Name", text: $newName)
                            .textFieldStyle(.roundedBorder)
                    }
+                   TextField("Notes", text: $newNotes)
+                       .textFieldStyle(.roundedBorder)
                    Button("Save") {
                        let newFriend = Friend(name: newName, birthday: newDate, notes: newNotes)
                        context.insert(newFriend)
                        newName = ""
                        newDate = .now
+                       newNotes = ""
                    }
                    .bold()
                }
                .padding()
                .background(.bar)
            }
        }
    }
}

完成したサンプルアプリ

追加した友達の誕生日のデータがアプリをキルしても、再度立ち上げると残っていることが確認できました！
SwiftDataを使って、データを永続化させることに成功！！

おわりに

公式チュートリアルDevelop in Swiftを使ってSwiftDataの基本的な使い方を学びました。気になった方は、実際にチュートリアルを1つずつ実際にコードを書きながら、進めることをおすすめします。

次回は、公式チュートリアルDevelop in SwiftのData editing and navigation編を公開したいと思います。

参考

• SwiftData | Apple Developer Document https://developer.apple.com/documentation/swiftdata
• Meet SwiftData https://developer.apple.com/videos/play/wwdc2023/10187/
• Develop in Swift https://developer.apple.com/tutorials/develop-in-swift
• Meet SwiftData - WWDC2023 https://developer.apple.com/videos/play/wwdc2023/10187/
• SwiftData入門 https://zenn.dev/yumemi_inc/articles/2a929c839b2000

ドローンを利用して自動操縦（Autopilot）のロジックを組みたいですが、自宅でドローンを飛ばしたら家が壊されてしまう恐れがあるので、シミュレータを使いたいなと思いました。

調査した結果、DJI Assistant 2というアプリがあり、開発PCでデバッグしながら動きを見ることができるそうです。

早速、作業に入りましょー！

必要なもの

• DJI Phantom 4
• リモートコントローラー(以下、RC)
• USBケーブル数本

バージョン

• 開発PC
  • Android Studio Hedgedog
  • Android SDK API Level 31
  • Gradle 7.5
  • Gradle JDK Correcto-11
• シミュレータ用PC
  • DJI Assistant 2 for Phantom
• Bridge App用携帯
  • DJI Bridge App

システム構成

手順

１（開発PC）DJI Mobile SDK V4をクローン

https://github.com/dji-sdk/Mobile-SDK-Android/tree/master

２（開発PC）DJI DeveloperでAPIキーを発行

• DJI Developerでログイン
• 「CREATE APP」でアプリケーションを登録する

※Package Nameはサンプルコード内のパッケージ名（各パッケージが存在するパス：Sample Code/app/src/main/java）。その他の項目は適当に記載

３（開発PC）サンプリコード内にAPIキーを入力

AndroidManifest.xml（パス：Sample Code/app/src/main/main）

４（開発PC）Sample Codeフォルダーを開いてビルドする

• gradle-wrapper.properties(パス：Sample Code/gradle/wrapper)で一度「Sync」OR「build」
  ※まず最初からSyncするといいと思うが、大抵の場合ビルドエラーが起こる。こんな感じ

• 「Change Gradle version in Gradle wrapper to 7.5….」を押すと、自動的にgradle-wrapper.propertiesの中身を書き換えてくれて、ビルドする

５（開発PC）エミュレータを起動

• 起動後に「Register App」を押すと、DJI SDK利用が可能になる

６（BridgeApp用携帯）携帯にBridgeAppをインストール

• iOSはApp Storeからダウンロードする
• Andriodはdji-sdk/Android-Bridge-Appからapk経由でインストール

７（BridgeApp用携帯）Bridge AppでRCに接続

• 携帯は開発者モードをONにし、USB DebuggingをONにする
• RCの電源をON、Phantom 4の電源をONにする
• Bridge Appを立ち上げて、USBでRCに繋ぐ

• 画面のIPアドレスをメモる(こちらの端末では192.168.1.35)

８（開発PC）IPアドレスをエミュレータ画面に入力

• 「WSBridge IP」欄にIPアドレスを入力

(開発PC画面)

(BridgeApp用携帯画面)

９（シミュレータ用PC）DJI Assistant 2でPhantom 4に接続

• DJI Assistant 2 for Phantomを立ち上げて、USBでPhantom 4に繋ぐ

• このアプリを使うには、以下の制限と設定が必要です（少し面倒ですね…）

  • ※新し目のMACで使えない
  • ※USBドライブにアクセス制限あるPCはそれを解除する必要

• 検知できると、こんな画面が出てくる

• 「Simulator」＞「Start Simulating」を押すと、Simulatorが立ち上がる
  ※ファイアウォールを無効化にする必要！ そうしないとRCからの信号が到達できない。

１０．🍷🍷🍷操作できました🍷🍷🍷

結論

シミュレーターを動かすことができました。ドローンにUSBで繋ぐところはなぜファイアウォールを無効化する必要があるのか理解できていないため、今後の調査課題とします。

シミュレータで学んだ後は、ドローン本体を調達して動かしていきましょう！

こんにちは、2014年フューチャーに新卒入社した李守智です。金融・アパレル・医療等分野で、システム構築系のプロジェクトに上流から下流まで一貫して携わってきました。

アプリ配信の前提となるアプリストア規約の調査とその結果をアプリへ反映する流れについて話します。このお話は、2021年ごろにスマホアプリ（Android、iOS）を一般配信するために行っていた経験を土台にしています。

GoogleとAppleのアプリストア規約

どのアプリストアからアプリを配信するかは決まっていますか？ AndroidアプリはGoogle Play、iOSアプリはApp Storeからの配信が一般的ですよね。配信先ごとに規約を確認する必要があります。

開発が完了したアプリをGoogle Play ConsoleやApp Store Connectに登録したら、同じ規約に基づいてアプリストア側の審査を受けることになります。

Google Playのポリシー
https://play.google.com/intl/ja/about/developer-content-policy/

App Reviewガイドライン
https://developer.apple.com/jp/app-store/review/guidelines/

アプリストア規約は誰がいつ確認するか

アプリストア規約は、デベロッパーが確認するものだけでなく、事業者が確認するものもあります。デベロッパーまたは事業者からアプリストア側へ問い合わせをする必要が出てくるようなものもあります。

プロジェクト開始／計画の段階で顧客とそれぞれの持分を認識合わせし、工数を確保しておくと良いでしょう。開発が完了してからやろうとすると、後述するような変更等から手戻りが発生する恐れがあります。アプリ配信の実績のない事業者の場合、アプリストア規約に違反するサービスを考えている可能性もあります。

また、規約は随時更新されているので、開発中はもちろん、運用保守の中でもウォッチできるようにしましょう。

アプリストア規約はどのように確認するか

当時私たちがやっていた方法を共有すると、規約の本文1文を1行のチェック項目とするチェックリストを作成して管理していました。

対象の規約、規約のバージョン、チェック項目（規約本文）、確認者、確認日、判定、コメント等を書き、チェックリストそのもののバージョン管理も行いました。

このチェックリストで判定OKとならなかったものが、課題チケットやタスクチケット等になっていきました。

アプリストア規約がアプリ開発に影響を及ぼした例

事例（1）アカウント削除機能の追加

App Reviewガイドラインによると、アカウント作成に対応したアプリの場合、ユーザ自身がそのアプリ内でアカウントを削除できるようにする必要があります。

例えばあるアプリはアカウントを作成してログインした状態での利用を前提とするものであるとします。もちろん、このケースではこの規約をクリアする必要があります。ここで問題になるのは、最小限の機能だけ実装したMVPをまずリリースしようとしたときで、アカウント削除機能は優先度的にスコープから漏れがちということです。実際にはファーストリリース時点で必須であるため、アカウント削除機能とその導線追加などをの考慮を、最初からスケジュールに組み込んでおきましょう。

機能定義前にこの対応が行われていたら手戻りは防げます。一方で、仮に開発完了後にこの対応をしようとすると、機能定義への追加はもちろん、アカウント削除機能への導線から発生する画面遷移の更新、開発・単体テスト、結合テストやシナリオテストなどなど、広範囲の変更が生じることになります。

事例（2）ユーザーデータの使用制限

ユーザーデータを収集するアプリの場合、ユーザーデータの使用をプライバシーポリシーに準拠した目的に制限する必要があります。これは、Google PlayのポリシーでもApp Reviewガイドラインでも謳われています。

この規約は、事例（1）とは違って、直感的にどんな対応をすれば良いか分かりにくいものでした。そこでまず、対応内容を決める前に以下のような思考の段階を経ました。

1. システムの中のユーザーデータの出番を洗い出した上で
2. その必要性がプライバシーポリシーに準拠しているかの評価をする

「プライバシーポリシーに準拠しているか」も、もう一段と解釈が必要かも知れません。プライバシーポリシーはユーザが承諾するアプリの利用規約の1つにもなるので、ざっくり表現すると「ユーザがその使い方をされると認識し、良いと了承している」ことと言えるかなと思います。

そうした検討結果としてユーザーデータのログ出力はプライバシーポリシーに準拠していないと自ら判断することもあります。例えばあるアプリで操作データを未加工でログ出力したとします。このケースでは、ユーザーデータが思わぬ使い方をされる可能性があります。なぜならログは容易に取得ができ、集計分析等が可能な一方で、その都度プライバシーポリシーに準拠した使い方がされることを、プロダクトのライフサイクルのすべての期間で保証することは難しいと想定できるからです。

そのため、運用保守の問い合わせ対応に必要な、ユーザを特定する情報以外のユーザーデータはマスキングしてログ出力するといった対応が必要です。もちろん、この対応をすると障害対応などでログを用いた追跡の難易度が上がります。そのため、プロジェクト計画の段階で対応時期等をチームで合意して進められるようにすることが重要です。

その他の事例

詳細は省略しますが、他にも「アプリを使い始めた後でも、ユーザが利用規約への同意を撤回できるようにする」とか、「iPhone向けのアプリがiPadでもうまく動作するか」など、対応検討の必要な規約は複数ありました。

まとめ

どちらかというと、Google Playのポリシーよりも、App Reviewガイドラインからの方が、対応が難しい印象です。

規約の内容によって対応が簡単に決められるものもあれば、課題管理が必要なものもありました。アプリストア規約を基点とせずとも、プロジェクトのスコープに既に入っている対応もありました。いずれにせよ、品質の高いサービスを世の中に配信することにつながれば良いと思います。適時にアプリストア規約を調査し、プロジェクト品質に役立てましょう。

はじめに

HealthCare Innovation Group(HIG)¹所属の橋本です。

みなさん、お使いのiPhoneではダークモードorライトモードどちらに設定していますか。

それとも、Automaticに設定していますか。

私は、単純に黒っぽい画面にテンションが上がるタイプなので常時ダークモードで使っています。

目に優しいのはダークモードではなく、ライトモードみたいな記事も拝見したことがあり、一度ダークモードからライトモードに変更したこともありますが、結局ダークモードに落ち着いています。

そんなiPhoneにおけるダークモード・ライトモードの切り替えをアプリ内から行う方法の例を紹介したいと思います。

環境

• OS：macOS Sonoma 14.4.1
• Xcode：15.3 (15E204a)
• Swift：5.10

ゴールイメージ

今回作成する表示モードをピッカーで選択できる設定画面です。

実装方法

まず、切り替えたい３つの表示モードを列挙型で定義しておきます。

enum DisplayMode: String {
    case light
    case dark
    case system
}

続いて、アプリ全体に対して、表示モードを適用させたいと思います。

このときに、.preferredColorSchemeと三項演算子を用いて条件分岐します。
displayModeが.systemのときに、nilを返すことでシステムのデフォルトの設定を反映できるようにしています。また、displayModeが.systemではないときは、diplayModeが’.dark’であるときは、ColorSchemeの.darkが適用され、そうでないときは.lightが適用されます。

.preferredColorScheme(displayMode == .system ? nil : (displayMode == .dark ? .dark : .light))

これをエントリーポイントである〜App.swiftファイルに次のように記載します。

import SwiftUI

@main
struct displayModeApp: App {
    @AppStorage("displayMode") var displayMode: DisplayMode = .system

    var body: some Scene {
        WindowGroup {
            ContentView()
                .preferredColorScheme(
                    displayMode == .system ? nil : (displayMode == .dark ? .dark : .light)
                )
        }
    }
}

最後に、Pickerを用いて、表示モードを変更させるViewを作成します。

Pickerのselection:パラメータには$displayModeがバインドさせています。これは、選択された値が直接displayModeプロパティに保存されることを意味します。
それぞれのtag()メソッドにDisplayModeの対応する値が設定されています。これにより、ユーザーがピッカーで選択した表示モードが、DisplayMode型のdisplayModeに適切に保存することが可能になります。

struct ContentView: View {
    @AppStorage("displayMode") var displayMode: DisplayMode = .system

    var body: some View {
        NavigationStack {
            List {
                Section("App Settings") {
                    Picker("Theme Color", selection: $displayMode) {
                        Text("Light")
                            .tag(DisplayMode.light)
                        Text("Dark")
                            .tag(DisplayMode.dark)
                        Text("System")
                            .tag(DisplayMode.system)
                    }
                    .pickerStyle(.automatic)
                }
            }
            .navigationTitle("Settings")
        }
    }
}

Done！

これでアプリ内から強制的に、ダークモード、ライトモードに変更させることができるようになりました。

触れていませんでしたが、@AppStoregeで端末内部にDisplayModeを記憶させているので、アプリキル後に立ち上げた際には、以前の設定値が保存されるようにもなっています。

おわりに

ダークモード・ライトモード・端末の設定のモードにアプリ内から切り替える方法を扱いました。

このようにダークモード、ライトモードを変えること自体は簡単ですが、それぞれの色を各画面に対応させるほうが大変ですね。色の管理にはAsset Catalogを使うことでダークモード、ライトモードの色を設定しておく方法がありますが、このあたりについても、うまいやり方があればご紹介したいと思います。

参考

• https://developer.apple.com/documentation/uikit/uisplitviewcontroller/1623194-displaymode
• https://developer.apple.com/documentation/swiftui/view/preferredcolorscheme(_:)
• https://developer.apple.com/documentation/swiftui/colorscheme

はじめに

こんにちは。HealthCare Innovation Group(HIG)¹所属の清水です。
春の入門連載2024、7本目の記事です。

SwiftにおけるWebフレームワークを取り上げます。Swift²はiOSアプリ開発のイメージが強いと思いますが、iOSアプリ開発以外でも利用できることを紹介します。
（macOS以外でもSwiftが動かせたら楽しいなというモチベーションで記事を執筆しております）。

Swift における Web フレームワーク

そもそもSwiftにおけるWebフレームワークは、何があるでしょうか？

Swift.org³のSwift on Server内で紹介されているWeb フレームワークは以下2つです。

• Hummingbird
• Vapor

GitHub Star 数を比較した図を以下に示します。

先発のフレームワークであるVaporの方が人気で、検索すると日本語記事もいくつかヒットします。Swift.org内のWebフレームワークチュートリアル⁴として取り上げられていることからも、Vaporが主流となっていることが伺えます。Vaporについては記事になっているものも多いため、後発のHummingbirdを試します。

Hummingbird とは

軽量で依存関係が少ないことを売りとしているフレームワークの1つです。

Hummingbird の README にも以下の記載があります。

Lightweight, flexible, modern server framework written in Swift.

Hummingbird は、最小限のコアフレームワークのみを提供して、個別で拡張していくことができるようになっています。前述の Vapor の方が機能自体は豊富だと思いますが、サクッと使いたい場合は Hummingbird なのかなと認識しています。

また、公式ドキュメントがAppleのDeveloper向けのドキュメント⁵そっくりなので、ぜひ覗いてみてほしいです。

https://docs.hummingbird.codes/2.0/documentation/hummingbird/

セットアップ

環境情報

本記事は、以下の環境で実施を確認しています。

• Windows Subsystem for Linux （以下、WSL）に関するバージョン情報

  >wsl -v WSL バージョン: 2.1.5.0 カーネル バージョン: 5.15.146.1-2 WSLg バージョン: 1.0.60 MSRDC バージョン: 1.2.5105 Direct3D バージョン: 1.611.1-81528511 DXCore バージョン: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows バージョン: 10.0.19045.4170

• Ubuntu のバージョン: 22.04.4 LTS

• Swift のバージョン: 5.10

Swift のインストール

まずは、SwiftをUbuntu上にインストールします。
Hummingbirdの公式ドキュメントにはSwift自体のインストールに関する記載はなかったため、Vaporの公式ドキュメントを参考にSwiftly⁶を用いてインストールしました。
Swiftly は、Swift Server Workgroup⁷ が提供するCLIツールで異なるバージョンのSwiftを使い分けることができます。
記載の手順通り、実行していきます。

# swiftly のインストール
> curl -L https://swift-server.github.io/swiftly/swiftly-install.sh | bash
~~~
Select one of the following:
1) Proceed with the installation (default)
2) Customize the installation
3) Cancel
> 1
~~~
# `swiftly` を有効化するため、PATH へ追加
> . $HOME/.local/share/swiftly/env.sh

# 最新バージョンの Swift をインストール
> swiftly install latest
~~~
Set the active toolchain to Swift 5.10.0
Swift 5.10.0 installed successfully!

# Swift がインストールされていることを確認する
> swift --version
Swift version 5.10 (swift-5.10-RELEASE)
Target: x86_64-unknown-linux-gnu

Hummingbird を用いたToDoアプリの構築（公式チュートリアル）

ここから先は、Hummingbird 公式ドキュメント記載のチュートリアルを元に Hummingbird のセットアップからToDoアプリの構築までのハンズオンを試してみます。

https://docs.hummingbird.codes/2.0/tutorials/todos/

Hummingbird のセットアップ

# プロジェクトDirectoryの作成
> mkdir Todos
> cd Todos
# パッケージに必要なテンプレートで初期化
> swift package init --type tool
# ディレクトリ構成の確認
>  tree
.
├── Package.resolved # パッケージの依存関係解決を記録
├── Package.swift # 依存パッケージを記載
└── Sources
    └── Todos.swift # 本体

> swift package init --type executable
Creating executable package: Sample
Creating Package.swift
Creating .gitignore
Creating Sources/
Creating Sources/main.swift

// swift-tools-version: 5.10
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription

let package = Package(
    name: "Sample",
    targets: [
        // Targets are the basic building blocks of a package, defining a module or a test suite.
        // Targets can depend on other targets in this package and products from dependencies.
        .executableTarget(
            name: "Sample"),
    ]
)

Hummingbird を利用するため、Package.swift に必要な情報を追加します。

// swift-tools-version: 5.10
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription

let package = Package(
    name: "Todos",
++  // macOS 上で動かさないため、コメントアウトしているが問題なく動作した。
++  // platforms: [.macOS(.v14)],
    dependencies: [
        .package(url: "https://github.com/apple/swift-argument-parser.git", from: "1.2.0"),
++      .package(url: "https://github.com/hummingbird-project/hummingbird.git", from: "2.0.0-alpha.1"),
    ],
    targets: [
        .executableTarget(
            name: "Todos",
            dependencies: [
                .product(name: "ArgumentParser", package: "swift-argument-parser"),
++              .product(name: "Hummingbird", package: "hummingbird"),
            ]
        ),
    ]
)

GET リクエストを叩いた際に”Hello”を返すように以下のように Todos.swift を書き換えます。

import ArgumentParser
import Hummingbird

@main
struct Todos: AsyncParsableCommand {
    func run() async throws {
        // create router
        let router = Router()
        // add hello route
        router.get("/") { request, context in
            "Hello\n"
        }
        // create application
        let app = Application(router: router)
        // run application
        try await app.runService()
    }
}

一連の修正が完了すると、アプリケーションが正常に動くことを確認できます。

> swift run
Building for debugging...
[8/8] Linking Todos
Build complete! (6.58s)
2024-04-16T15:18:49+0900 info Hummingbird : [HummingbirdCore] Server started and listening on 127.0.0.1:8080

# 別タブで動作確認
> curl localhost:8080
Hello

簡単ですね🎉

ToDoアプリの構築

ここでは、Hummingbird を利用してToDoをDBに登録するところまで試してみます。
PostgresNIO⁸ というPostgreSQL用のSwiftクライアントを利用することで、ToDoをPostgreSQLに登録します。

Hummingbird 同様に、PostgresNIO を Package.swift に追加します。

// swift-tools-version: 5.10
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription

let package = Package(
    name: "Todos",
    // macOS 上で動かさないため、コメントアウトしているが問題なく動作した。
    // platforms: [.macOS(.v14)],
    dependencies: [
        .package(url: "https://github.com/apple/swift-argument-parser.git", from: "1.2.0"),
        .package(url: "https://github.com/hummingbird-project/hummingbird.git", from: "2.0.0-alpha.1"),
++      .package(url: "https://github.com/vapor/postgres-nio.git", from: "1.21.0"),
    ],
    targets: [
        .executableTarget(
            name: "Todos",
            dependencies: [
                .product(name: "ArgumentParser", package: "swift-argument-parser"),
                .product(name: "Hummingbird", package: "hummingbird"),
++              .product(name: "PostgresNIO", package: "postgres-nio"),
            ]
        ),
    ]
)

PostgreSQL をインストールします。
チュートリアルでは（おそらくmacOS前提で） brew 経由でインストールしていたのですが、今回は apt 経由でインストールします。

> sudo apt update
> sudo apt install postgresql postgresql-contrib
> psql --version
psql (PostgreSQL) 14.11 (Ubuntu 14.11-0ubuntu0.22.04.1)

インストールが完了したので、チュートリアルの続きを実施します。

> psql postgres
psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
        Is the server running locally and accepting connections on that socket?

エラーで進めません。
エラーについて調べると .conf ファイルを確認しよう⁹、などとありますが、そもそも.confファイルを含んだディレクトリ（/etc/postgresql/14/main/）がないことに気が付きました。

> ls -la /etc/postgresql/
total 8
drwxr-xr-x  2 postgres postgres 4096 Feb 10  2022 .
drwxr-xr-x 84 root     root     4096 Apr 17 06:54 ..

別の記事¹⁰を参考に、PostgreSQL のクラスタを追加します。

> sudo pg_createcluster --start 14 main
> ls -la /etc/postgresql/14/main/
conf.d/          pg_ctl.conf      pg_ident.conf    start.conf
environment      pg_hba.conf      postgresql.conf

動くようになったので、チュートリアルの続きに戻ります。
まずは、データベースを準備します。

> postgres psql
psql (14.11 (Ubuntu 14.11-0ubuntu0.22.04.1))
Type "help" for help.

postgres=# create database hummingbird;
CREATE DATABASE
postgres=# \c hummingbird
You are now connected to database "hummingbird" as user "postgres".
hummingbird=# create role todos createrole login password 'todos';
CREATE ROLE
hummingbird=# \q

次に、ToDoアプリの実装です。
チュートリアルの通りに実装していきます。完成形は、公式のサンプルがあるため、そちらをご確認ください。

https://github.com/hummingbird-project/hummingbird-examples/tree/main/todos-postgres-tutorial

動作確認

これまで構築したものの動作確認を行います。

> swift run

# 別タブで動作確認
# TODO を登録
> curl -i -X POST localhost:8080/todos -d'{"title": "Wash my hair"}'
HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8
Content-Length: 145
Date: Tue, 16 Apr 2024 23:54:54 GMT

{"id":"A4672369-753C-49AD-A41C-849AE5A7CF1E","url":"http:\/\/localhost:8080\/todos\/A4672369-753C-49AD-A41C-849AE5A7CF1E","title":"Wash my hair"}
> curl -i -X POST localhost:8080/todos -d'{"title": "Brush my teeth"}'
HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8
Content-Length: 147
Date: Tue, 16 Apr 2024 23:55:03 GMT

{"url":"http:\/\/localhost:8080\/todos\/435A9B4F-BD4A-42E2-8EA9-5A5560378BBA","id":"435A9B4F-BD4A-42E2-8EA9-5A5560378BBA","title":"Brush my teeth"}

# DB の登録状態を確認
> psql hummingbird
psql (14.11 (Ubuntu 14.11-0ubuntu0.22.04.1))
Type "help" for help.

hummingbird=# select * from todos;
                  id                  |     title      | order | completed |                               url
--------------------------------------+----------------+-------+-----------+------------------------------------------------------------------
 a4672369-753c-49ad-a41c-849ae5a7cf1e | Wash my hair   |       |           | http://localhost:8080/todos/A4672369-753C-49AD-A41C-849AE5A7CF1E
 435a9b4f-bd4a-42e2-8ea9-5a5560378bba | Brush my teeth |       |           | http://localhost:8080/todos/435A9B4F-BD4A-42E2-8EA9-5A5560378BBA
(2 rows)

POSTしたToDoが、DB側に登録されていることを確認できました🎉

さいごに

Swift の Web フレームワークの1つである、Hummingbird をセットアップから紹介しました。

個人的には、macOS以外でもSwiftが書けて、かつ、サーバーアプリ開発に利用できることが知れて楽しかったです。WSL 上でセットアップしたので手順が多めだったのですが、普段SwiftでiOSアプリ開発している方がサーバサイドの開発を試したいときに便利だと思いました。

今回は試せませんでしたが、Xcode のシミュレータとバックエンドの接続までをどこかで試してみたいと考えています。

はじめに

こんにちは。最近スギ花粉耐性がないことを実感しつつある山本です。

2024/2/1、GDG Tokyo主催の「【Firebase】GDG Tokyo Monthly Online Tech Talks」に「Flutter×Firebaseサービス達で高速でモバイルアプリを開発した話」というタイトルで登壇してきたので、その事後レポートです。

登壇資料：

GDG Tokyo Monthly Online Tech Talksとは？

Google Developers Group (GDG) Tokyo は主にGoogleのテクノロジーに興味のある人たちで情報を共有しあう集いです

GDG Tokyoが毎月開催する「GDG Tokyo Monthly Online Tech Talks」は、Googleの技術に関心を持つ人々が集うオンラインMeetupです。このイベントは、Android、Google Cloud、Web、Firebase、Machine Learning（ML）、Flutter、Goなど、多様なGoogleの技術に焦点を当てています。参加者は、技術情報をキャッチアップし、エンジニア同士のコミュニケーションと交流の場としてご活用いただけます。

(※GDG Tokyoのconnpassページより引用)

「GDG Tokyo」および「GDG Tokyo Monthly Online Tech Talks」についてはGDG Tokyoのグループの説明として上記が記載されています。

今回のイベントのテーマは「Firebase」に関わることで、15分枠 or 5分枠の登壇枠で開催されていました。

登壇

最近お仕事でFirebaseに携わっていたこともあり、社内の人におすすめされたので登壇を申し込んでみました。(会社アカウントとしては初の登壇です…！ )

登壇内容としては、新規事業プロジェクト周りでFlutterとFirebaseを活用していたのでそのユースケースの紹介をしてみました。

以下内容を一部抜粋して紹介していきます。

アーキテクチャ紹介

今回紹介したユースケースとしてはモバイルアプリ側はFlutter、バックエンドサービス側をFirebaseのサービスを活用したものです。

どちらもGoogle製ということもあり、親和性がある&ドキュメントが豊富ということでこのアーキテクチャが選定されています。

使用したサービスを一覧で並べてみると、Firebaseを主としたかなりモダンな構成と言えるのではないでしょうか？
自分は開発チームにあとから参画したのですが、なかなか良い経験となっています。

ログ&アラートについて

Firebaseでログ・アラート周りに使用できるサービスとしては以下の2つがあります。

• Firebase Crashlytics
• Google Analytics for Firebase

構成としてはいろいろなものが考えられますが、今回はCrashlyticsについては主にクラッシュor致命的なエラーを通知するように、Google Analyticsにはユーザーログを出したりBigQueryに連携したりしてユーザーの操作の追跡や広告効果の測定といったことを行っていました。

※BigQueryへの連携については松井さんが以下記事で解説してます。

Firebaseで取得したログをBigQueryに連携してユーザー操作をトラッキングする

Firebase Remote Configについて

その他に活用していてユニークだったサービスとしては、Remote Configがあります。

https://firebase.google.com/docs/remote-config?hl=ja

詳しくは上記の公式ページを見ていただきたいですが、Remote Config Serverでパラメータ値などを管理することで、アプリストアへのリリースすることなくユーザーアプリの画面切り替えや強制アップデートなども行えます。

まだ導入できていませんが、A/B testingなども行うことができるようなので将来的には触ってみたいですね。

まとめ

今回はGDG Tokyoにて、最近触ったFirebaseサービスとFlutterの活用事例について登壇してきました！
会社アカウントで登壇することは初めてだったのですが、登壇になれた方やチームメンバーに手厚くフォロー頂き楽しく発表してくることができました。

今後もどんどん登壇やアウトプットできるようにがんばります。
※スギ花粉とも頑張って生きていこうと思います。

参考文献

• https://firebase.google.com/docs/remote-config?hl=ja

はじめに

2023年の秋、スマートフォンやタブレットは私たちの日常生活に欠かせない存在となっています。

これらのデバイスに対するアプリケーション開発の中でも、UI(User Interface)とUX(User Experience)設計の議論については欠かすことができません。

「UI」という単語は広範囲にわたる意味を持ちますが、今回は「モバイルアプリのUI設計」という文脈に焦点を絞り、その理論の歴史とトレンドについて調べてみました。

モバイルアプリのUI設計について

優れた「モバイルアプリのUI」は、どのようなものがあるでしょうか？

イメージしやすいものだと、以下のようなものがあります。

• ボタンの色や配置がわかりやすい。ホームボタンであれば家の形をしていたり、検索ボタンでは虫眼鏡の形をしているなど
• タップしたときに何が起こるのか、ユーザーにわかりやすいこと。アプリヘッダーに「←」(左矢印)が表示されていれば、前の画面に戻るなど
• 通信が発生するボタンを押したときに、スピナー(通常は回転するアイコン)が表示され、かつ短時間で処理が終わり待ち時間が少ないこと

逆に、優れていないUIについては以下のような報告もあります。

• モバイルショッピングアプリのUIの使いやすさがユーザーの購買意欲に直接影響するといったことを示唆する研究
• ユーザーの90％がパフォーマンスの低下でアプリの使用を停止したとする調査レポート

せっかく良い内容のアプリを作っても、UIがその価値を下げては台無しです。

では、良いUIとはどのようなものでしょうか？ その設計とは？

次の項からは、モバイルアプリのUI設計の理論や思想について、どのようなものがあるのか。また、その歴史について書籍や論文などから調べてみました。

モバイルアプリUI設計理論・思想の歴史

モバイルアプリのUI設計の歴史を振り返ると、2007年のApple初代iPhoneの発表が大きなマイルストーンとして挙げられます。

それ以前にも、モバイルデバイスは存在していました。パーソナルデジタルアシスタント（PDA）やタッチスクリーン携帯電話と呼ばれるようなものです。これらのデバイスの中にはタッチスクリーンを備えたものもありましたが、多くはスタイラスによって操作されるもので、指タッチによる操作はあまり前提としていないものが多かったようです。

初代iPhoneでは、現在ではモバイルデバイス操作の標準となっている指タッチでの操作が導入され、それが世界的な流行を引き起こしました。これにより、モバイルデバイスの操作方法は劇的に変化し、モバイルアプリのUI設計についても新たな時代を迎えました。

そこからも、マルチタッチ技術の進化、Android,iOSなどのプラットフォームの進化、折りたたみデバイスの登場、あるいはユーザー自体の期待の向上など、様々な変化が起こってきました。それらに応じるように、近年のモバイルアプリのUI設計に至るまで、様々な理論や思想が議論され、そして進化し続けています。

以下では、今回調べたモバイルアプリUI設計理論や思想に関わる書籍・論文について、いくつかピックアップして時系列順に紹介していきます。

1. Human Interface Guidelines(1977-現在)
2. Mobile Design and Development: Practical concepts and techniques for creating mobile sites and web apps(2009)
3. Brave NUI World: Designing Natural User Interfaces for Touch and Gesture by Daniel Wigdor and Dennis Wixon (2011)
4. Mobile First(2011)
5. Microinteractions: Designing with Details (2013)
6. Material Design (2014)

※総務省の調査によると、日本のスマートフォン普及率は以下のような推移をたどっているようです。
時系列と普及率を見比べてご覧いただければと思います。

1. Human Interface Guidelines(1977-現在)

https://developer.apple.com/design/human-interface-guidelines

時系列順に紹介すると、最初に来るのはAppleが提唱した「HumanInterface Guidelines(HIG)」です。こちらは、Appleが定期的にアップデートをしているインターフェースのガイドラインで、歴史を遡ると初版である「The Apple II Human Interface Guidelines」は1977年のものとなります。

とはいえ、「Macintosh GUI」についての原則と設計哲学が記載されたものとなり、モバイルデバイスに関わるものとしては、「iPhone Human Interface Guidelines」が初代iPhoneの発売と同年である2007年に公表されています。

このHIGは現在に至るまで様々な製品、OSのアップデートに伴い改定され続けており、iOSの普及や統一されたインターフェースに大きな貢献をしているのではないでしょうか？

※余談ですが、弊社にもHIG(Healthcare Innovation Group)があって時々まぎらわしかったりします。

2. Mobile Design and Development: Practical concepts and techniques for creating mobile sites and web apps(2009)

https://www.oreilly.com/library/view/mobile-design-and/9780596806231/

次に紹介するのはBrian Flingによる執筆、O’Reilly Mediaから出版されている「Mobile Design and Development」です。この書籍では、モバイルアプリの設計や開発について網羅的に解説されています。

目次としては、以下のようになっており、記載当時のモバイルアプリ開発の状況についてや、モバイルUI設計の状況について知る上でとてもわかりやすいものでした。

Chapter 1, A Brief History of Mobile
Chapter 2, The Mobile Ecosystem
Chapter 3, Why Mobile?
Chapter 4, Designing for Context
Chapter 5, Developing a Mobile Strategy
Chapter 6, Types of Mobile Applications
Chapter 7, Mobile Information Architecture
Chapter 8, Mobile Design
Chapter 9, Mobile Web Apps Versus Native Applications
Chapter 10, Mobile 2.0
Chapter 11, Mobile Web Development
Chapter 12, iPhone Web Apps
Chapter 13, Adapting to Devices
Chapter 14, Making Money in Mobile
Chapter 15, Supporting Devices
Chapter 16, The Future of Mobile

目次を見るだけでも、当時のモバイルアプリ開発としてはネイティブアプリが絶対的な選択肢とはならず、Webアプリとどちらを選択するのかといったことも大きな議論の対象のひとつであったことが伺えます。

また、この書籍だけでなく、2011年ごろの論文6,7でも、ネイティブアプリ vs ウェブアプリといった文脈で盛んに議論がかわされていたようです。

2023年の現時点においても、ネイティブアプリとWebページをネイティブアプリのように表示できるPWA(Progressive Web Apps)の比較について議論されることがありますが、当時の状況では議論の内容が少々異なったようです。

The mobile web historically has been so horrendous to deal with that
the only way to create a compelling experience was to go native.
(p.156を引用)

本書では上記で記載されているように、筆者によるとモバイルWebアプリケーションを開発すること自体に一定のハードルがあったようです。

背景として、当時のMobile SafariではCSSのposition:fixedの動作に課題があったり8、特定のOS標準のブラウザでは描画に課題があったり9したように、モバイルブラウザ自体の技術が成熟していなかったことが考えられます。

次に、本記事のテーマであるUIについて触れられている項を見てみましょう。

Although information architecture has become a common discipline in
the web industry, unfortunately, the mobile industry—like software—has
only a handful of specialized mobile information architects. Although
mobile information architecture is hardly a discipline in its own right,
it certainly ought to be. This is not because it is so dissimilar from its
desktop cousin, but because of context, added technical constraints, and
needing to display on a smaller screen as much information as we would on
a desktop.
(p.104を引用)

とあるように、モバイルに限らないUI/UXといった議論は行われていたようですが10、モバイルアプリのUI設計に特異な議論はまだ主流でなかったことが考えられます。

本書においては、「Chapter 7, Mobile Information Architecture」のセクションでは、モバイルアプリの情報アーキテクトとして、サイトマップやクリックストリームについて記載されています。既存のWebサイト構築とは異なるTipsとして、ユーザーの操作タスクが短いことがあげられています。

また、2023年と異なる興味深い点として、間違ったページに遷移しやすい構成である場合にユーザーに与える悪影響として以下が挙げられています。

• ユーザーが前のページに迅速に戻るための信頼性のあるブロードバンド接続を持っているとは限らないことを想定する必要があること
• 通信が発生することで、通信料金が発生すること

「Chapter 8, Mobile Design」のセクションでは、モバイルアプリのデザイン構築についてのTipsが網羅的にわかりやすく記載されていました。特に、モバイルデバイスは通常のWebサイトとは違い、画面が小さいことを意識することの重要性について述べられている部分が多かったように感じます。

今ではResponsible Designと呼ばれる概念に近いですが、「Responsive Web Design」という単語自体が2010年にEthan Marcotteによって提唱されたものだそうで6、記事執筆時に単語としては普及していなかった可能性もあります。

モバイルデバイスも考慮したレイアウトの議論についても、盛んに行われていたようです。

3. Brave NUI World: Designing Natural User Interfaces for Touch and Gesture by Daniel Wigdor and Dennis Wixon (2011)

https://www.amazon.co.jp/Brave-NUI-World-Designing-Interfaces/dp/0123822319

次に紹介するのはDaniel Wigdorによる執筆、Morgan Kaufmannから出版されている「Brave NUI World」です。この書籍では、タッチとジェスチャーを中心としたナチュラルユーザーインターフェース(NUI)の設計について記載されています。

NUI自体は、モバイルデバイスの文脈に閉じる話ではなく、あらゆる入力テクノロジーを活用して構築された自然なインターフェースに意味が及びます。ですが、本書では特にタッチとジェスチャーの相互作用に重点が置かれて紹介されており、この時期に盛んとなっているタッチジェスチャーに関する文献の中でも著名なものであったので本記事でピックアップします。

目次としては、以下のようになっています。(なかなかボリュームある本でした)

PartⅠ Introducing the NUI
CHAPTER 1 Introduction
CHAPTER 2 The Natural User Interface
CHAPTER 3 Ecological Niche: Computing, the Social Environment, and Ways of Working
Part Ⅱ Design Ethos of NUI
CHAPTER 4 Less Is More
CHAPTER 5 Contextual Environments
CHAPTER 6 The Spatial NUI
CHAPTER 7 The Social NUI
CHAPTER 8 Seamless
CHAPTER 9 Super Real
CHAPTER 10 Scaffolding
CHAPTER 11 User Defferentiation
Part Ⅲ NewTechnologies: Understanding and Technological Artifacts
CHAPTER 12 The State-Transition Model Of Input
CHAPTER 13 Fat Fingers
CHAPTER 14 No Touch Left Behind: Feedback Is Essential
CHAPTER 15 Touch versus In-Air Gestures
Part Ⅳ Creating an Interaction Language
CHAPTER 16 Mechanics, Dynamics, and Aesthetics: The Application of MDA
CHAPTER 17 New Primitives
CHAPTER 18 The Anatomy of a Gesture
CHAPTER 19 Properties of a Gesture Language
CHAPTER 20 Self-Revealing Gesture
CHAPTER 21 A Model of the Mode and Flow of a Gesture System
Part Ⅴ No Such Thing as Touch
CHAPTER 22 Know Your Platform
CHAPTER 23 The Fundamentals Have to Work
CHAPTER 24 Numbers of Contents
CHAPTER 25 Contact Data: Shape, Pressure, and Hover
CHAPTER 26 Vertical, Horizontal, and Mobile
Part Ⅵ Process: How Do You Get There?
CHAPTER 27 The User-Derived Interface(UDI)
CHAPTER 28 Lessons in False-Gesture Recognition
CHAPTER 29 RITE with a Purpose
CHAPTER 30 A Word About Engineering

本書では、GUIを中心とした既存のマウス入力と、タッチ入力を中心としたデバイス操作には大きな違いがあることを認識した上で設計をする必要性を強く主張しています。

具体的なタッチとジェスチャーに関する項目はPart Ⅲ以降から様々な角度、考え方から科学的に記載をされています。

全編通して参考になる本でしたが、1つ興味深い例を上げるとするのであれば「CHAPTER 13 Fat Fingers」が挙げられます。このセクションでは、指タッチで生じる課題として、（1）指はマウスよりも大きな領域で接触するため、画面のピクセル単位での正確なタッチが難しいこと（2）タッチしている箇所が指自体で見えなくなること、を課題として挙げています。言われてみれば当然と思う方もいるかもしれませんが、自身としてはUIを考える上であまり意識していなかった部分であったので興味深かったです。

この課題への対応として、（1）タッチオブジェクトを十分に大きくすることや、（2）「Iceberg Targets」と呼ばれる、画面領域をいくつかに分割し、タッチポイントに最も近いオブジェクトに対してアクションを発生させること、などが記載されていました。

現在のモバイルデバイスでは一般的となっていて、ユーザーとしても慣れ親しんでいるタッチ入力ですが、タッチ、タップ、フリック、ピンチ操作など、基本的な操作方法としては大きな変化はないように感じます。そういった意味でも、本書はそれらの基本操作をいかにユーザーに自然に操作できるように設計できるかという部分で大きく勉強になる本でした。

この書籍と同時期に、タッチジェスチャーに関する研究・書籍についても多く出ているようです。iPad (第1世代)も本書の出版と同年の2010年に発売され、他にもタッチスクリーン採用のモバイルデバイスが次々発売されていた時期のようで、タッチ入力がより普及していたことが伺えます。

4. Mobile First(2011)

https://www.amazon.co.jp/Mobile-First-Luke-Wroblewski/dp/1937557022

次に紹介するのは、Luke Wroblewskiによる執筆、Ingramから出版された「Mobile First」です。統計的にはモバイルデバイスの普及が爆発的に始まった2010年近辺の出版であり、いよいよモバイルアプリの立ち位置が向上したことを思わせるタイトルです。

この書籍の内容としては、タイトル通り「モバイルファースト」、ウェブサイトやアプリケーションをまずモバイル向けに設計・構築することを推奨するものです。

目次は以下のようなものです。

Part1 Why Mobile First?
CHAPTER1 Growth
CHAPTER2 Contstraints
CHAPTER3 Capabilities
Part2 How to go Mobile
CHAPTER4 Organization
CHAPTER5 Actions
CHAPTER6 Inputs
CHAPTER7 Layout

「Part1 Why Mobile First?」では、当時のモバイルデバイスのシェア率の拡大を背景に、「モバイルファースト」とするメリットをさまざまな角度から論じています。

So it’s not hard to imagine how another bold prediction
like “mobile phones will overtake PCs as the most common
web access devices worldwide by 2013” will happen much
earlier than predicted as well (http://bkaprt.com/mf/10).
(p.8を引用)

上記では、「したがって、「モバイル電話は2013年までに世界中で最も一般的なウェブアクセスデバイスとしてPCを上回るだろう」というような大胆な予測が、予想よりもはるかに早く実現するのは難しくありません」と言った趣旨の内容が記載されており、「2013年までに」こそ日本では実現しましたが、現時点では実際にスマートフォンの普及率がPCと逆転していることもあり感慨深いです。

また、UI設計に関するセクションとしては、CHATPTER5 ~ 7が具体的な内容に踏み込んでいます。

「CHAPTER5 Actions」では、タップ操作を始めとしたタッチ対象オブジェクトのサイズについてや、タッチジェスチャーについて言及されています。また、本記事の前項で紹介したNUIが紹介されていますが、GUIとNUIの過渡期にあることを念頭にインターフェースデザインを考える必要があると記載されてもいます。

「CHAPTER6 Inputs」では、モバイルアプリでの入力タイプについて言及されています。ウェブサイトで使用されてきた、チェックボックスやラジオボタン、パスワード、ドロップダウン、ファイルの選択、送信ボタン、プレーンテキストなどについて、モバイルデバイス特有の意識すべきことなどが記載されています。

「CHAPTER7 Layout」では、モバイルデバイス特有のレイアウトについて言及されています。レスポンシブルの必要性や、シンプルに作ることの重要性については、今も変わらない重要なことであると感じさせられました。

本書では、モバイルデバイスの急速な普及を背景に、「モバイルファースト」の思想について記載されていました。優れたUIについて言及する中で、様々な既存アプリの比較も行っており、モバイルアプリの発展自体が背景にあるようにも考えられる内容で興味深かったです。

5. Microinteractions (2013)

https://www.oreilly.com/library/view/microinteractions/9781449342760/

次はこちらのDan Safferによる執筆、O’Reilly Media出版の書籍を紹介します。
本書は以下の目次で構成されています。

Chapter 1, Designing Microinteractions
Chapter 2, Triggers
Chapter 3, Rules
Chapter 4, Feedback
Chapter 5, Loops and Modes
Chapter 6, Putting It All Together

本書では、「Microinteractions」を製品の機能的のうち細部のインタラクティブなものを示しています。例えば、パスワードのバリデーションチェック(今入力しているのものが、OKなのか、文字数不足なのかのリアルタイム表示)が挙げられます。

詳細については本書を読んでいただきたいのですが、マイクロインタラクションについて、本書では「Triggers」「Rules」「Feedback」「Loop&Modes」の４つで構成される、として定義し、それぞれの定義や原則について詳細に記載されています。

ユーザーが直感的に操作する上で、明確なフィードバックがあることは重要で、常に意識して設計していきたい要素であると感じました。

6. Material Design (2014/2018/2021)

https://m1.material.io/
https://m2.material.io/
https://m3.material.io/

モバイルアプリに固有の内容ではありませんが、こちらは2014年にGoogleが提唱したUI/UXのデザインである「Material Design」の紹介です。

※Material DesignはM1,M2,M3の3つが存在しますが、2014年に提唱された最初のものがM1となります。

当時提唱されたMaterial Designの目標としては、以下の2つが記載されています。

Create a visual language that synthesizes classic principles of good design with the innovation and possibility of technology and science.
(直訳: 良いデザインの古典的な原則と技術や科学の革新と可能性を統合する視覚言語を作成する。)

Develop a single underlying system that allows for a unified experience across platforms and device sizes. Mobile precepts are fundamental, but touch, voice, mouse, and keyboard are all first-class input methods.
(直訳: プラットフォームやデバイスのサイズを問わず、統一された体験を可能にする単一の基盤となるシステムを開発する。モバイルの原則は基本的であるが、タッチ、音声、マウス、キーボードすべてが第一級の入力方法である。)

また、原則として以下の3つも掲げており、次が特徴として記載されています。

1. Material is the metaphor
   • 紙のような物理的性質を持つインターフェースを意識し、ユーザーが直感的に操作しやすいUIを作る基盤となること
2. Bold, graphic, intentional
   • 意図的な色の選択、エッジツーエッジの画像、大規模なタイポグラフィ、意図的な空白は、ユーザーをエクスペリエンスに没頭させる大胆でグラフィックなインターフェースを作成すること
3. Motion provides meaning
   • モーションが意味があり適切であり、注意を集中させ、継続性を維持させること

これらの思想だけではなく、Material Designに沿ったダイアログ、カードを始めとした多様なコンポーネントを例示していることも大きな特徴です。これらの導入により、特にAndroidではモバイルアプリのUI設計においても一貫性が強調できたのではないでしょうか？

2023年時点ではMaterial Design 3が最新となっていますが、アプリ開発をする上で個人的にも多用させていただいているものとなります。

近年・将来のモバイルアプリUI設計のトレンドについて考察

前のセクションでは、モバイルアプリUI設計に関する理論や代表的な書籍を選び、簡単に紹介させていただきました。

このセクションでは、将来のトレンドに焦点を当てて、私の個人的な考えを共有します。

まず、モバイルアプリUI設計の過去の推移を振り返ると、2007年のiPhone登場以降、初期段階では既存のウェブサイトのレイアウトをモバイルに適応・進化させる試みが盛んに行われました。その後、モバイルデバイスのシェアが急速に拡大する中、「モバイルファースト」「レスポンシブデザイン」「NUI（Natural User Interface）」といった理論が発展し、ガイドラインが整備され、設計プロセスが成熟していきました。

これらの理論の中でも、「タッチ入力」によるユーザーインターフェースの進化が中心的な役割を果たしていると考えることができます。

それでは、これからのトレンドはどのようなものが考えられるでしょうか？

1つ目のトレンドとして、デバイスの進化、特に「タッチ入力」を補完または置き換える新しい入力方法の登場が考えられます。例えば、SiriやAlexa、Google Assistantに挙げられるような、音声ユーザーインターフェース（VUI）や、Meta Quest3に搭載されている視線追跡技術などがあげられます。これらの技術がモバイルデバイスで「あたりまえ」になれば、「タッチ入力」が時代を変えたように、モバイルアプリUI設計も大きく変わるかもしれません。

2つ目のトレンドとして、AIを活用したモバイルアプリUI設計の変革が考えられます。ChatGPTをはじめとする近年のAI技術の進化は著しく、実際に以下のような、強化学習を用いた適応型UI、AUI(Adapting User Interface)の研究もされています。これにより、ユーザーの行動を学習し、UIを自動で最適化したり、あるいは個々のユーザーに合わせたUIを提供できる時代が来るかもしれません。

• Adapting User Interfaces with Model-based Reinforcement Learning
• MARLUI: Multi-Agent Reinforcement Learning for Adaptive UIs

まとめ

本記事では、モバイルアプリUI設計に関わる書籍や理論をいくつかピックアップし、簡単に紹介しました。

現在では、これらの設計・理論・技術を基盤として、新たな入力インターフェースや、AIを用いたUIの最適化などが研究・議論されています。

本記事が、モバイルアプリのUI設計についてなにか考えるきっかけになれば幸いです。

次は真野さんの 設計ドキュメント腐る問題、Git管理で運用してみた結果 です。

参考文献

1. Wonjin Jung. “The Effect of Representational UI Design Quality of Mobile Shopping Applications on Users’ Intention to Shop”. Procedia Computer Science, Volume 121, 2017, Pages 166-169, 2017
2. Designers. “Know Your User – UX Statistics and Insights (with Infographic)”. https://www.toptal.com/designers/ux/ux-statistics-insights-infographic
3. 情報通信統計データベース.”通信利用動向調査”. https://www.soumu.go.jp/johotsusintokei/statistics/statistics05.html
4. Apple. “Human Interface Guidelines”. https://developer.apple.com/design/human-interface-guidelines
5. Brian Fling.『Mobile Design and Development: Practical concepts and techniques for creating mobile sites and web apps』. O’Reilly Media. 2009
6. Andre Charland, Brian LeRoux. “Mobile Application Development: Web vs. Native: Web apps are cheaper to develop and deploy than native apps, but can they match the native user experience?”. Queue. Volume 9, Issue 4. 2011
7. Andre Charland, Brian LeRoux, Nitobi.”Mobile Application Development:Web vs. Native”. Queue.
8. stack overflow. “Fixed positioning in Mobile Safari” .https://stackoverflow.com/questions/743123/fixed-positioning-in-mobile-safari
9. ANANDTECH. “BlackBerry Torch 9800 Review: Keeping RIM’s Flame Alive”.https://www.anandtech.com/show/3880/blackberry-torch-9800-review-keeping-rims-flame-alive/7
10. Jesse James Garrett. “The Elements of User Experience”.http://www.jjg.net/elements/pdf/elements.pdf
11. A LIST APART.Ethan Marcotte. “Responsive Web Design”. 2010
12. Daniel Wigdor, Dennis Wixon. 『Brave NUI World: Designing Natural User Interfaces for Touch and Gesture by Daniel Wigdor and Dennis Wixon』. Morgan Kaufmann. 2011.
13. Luke Wroblewski.『Mobile First』.Ingram. 2011
14. Dan Saffer.『Microinteractions』. O’Reilly Media. 2013
15. Google. “Material Design”. https://m1.material.io/
16. Kashyap Todi,Gilles Bailly, Luis A. Leiva, Antti Oulasvirta. “Adapting User Interfaces with Model-based Reinforcement Learning”. 2021
17. Thomas Langerak, Sammy Christen, Mert Albaba, Christoph Gebhardt, Otmar Hilliges. “Thomas Langerak, Sammy Christen, Mert Albaba, Christoph Gebhardt, Otmar Hilliges”. arxiv. 2022

こんにちは。思い出をショートムービーとして残すアプリ、PostPixを作っている後藤田です。

PostPixはFlutterで作っています。ぜひ、ダウンロードしてあなたの思い出をショートムービーにしてみてください！

Androidエミュレータからプロキシサーバを超えてインターネットに出たい

プロキシが存在するネットワーク内で、Androidエミュレータからインターネット接続ができず、頭を悩ませたことはありませんか？

私たちは、この課題に対する解決策として、middleproxy（社内のエンジニアが作ってくれたツール）とFlutterのnative_flutter_proxyライブラリを活用しています。

この記事ではそれらについて解説します。

最終的な構成は次のようになります。

なお、開発環境はWindows。プロキシは認証つきで、独自の証明書を利用する前提とします。

1. Android仮想デバイスの作成

まずは、Android仮想デバイス（AVD）を作成します。今回は Pixel_4_XL を利用するとします。

%UserProfile%\AppData\Local\Android\sdk\emulator\emulator -writable-system -avd Pixel_4_XL_API_30

%USERPROFILE%/.androidに advancedFeatures.ini を作成し、以下の2行を追加します。

Vulkan = off
GLDirectMem = on

2. adbのインストール

Android Debug Bridge（adb）をインストールします。

必要に応じて、adbにPATHは通しておきます。

以下のように出力されればOKです。

> adb --version
Android Debug Bridge version 1.0.41
Version 33.0.3-8952118
Installed as C:\Program Files\platform-tools\adb.exe

3. CA証明書のエミュレータへの転送

プロキシが要求する証明書が custom_ca.cer であり、その証明書をDesktop直下に配備したとします。

これをホストPCから、Androidエミュレータ側の、 /sdcard/Download にパスに転送します。

$ cd %USERPROFILE%\Desktop
$ adb root
$ adb disable-verity
$ adb shell avbctl disable-verification
$ adb reboot
# reboot 後に待機
$ adb root
$ adb remount
$ adb push custom_ca.cer /sdcard/Download

4. 証明書の読み込み

エミュレータ上のAndroidを操作します。

歯車マーク > Security > Advanced > Encryption & credentials > Install a certificate > CA certificate > Install anyway > 上のハンバーガーメニューから Android SDK build for x86 を選択 > Download を開く

…すると、先ほど追加した、custom_ca.cer があるので、クリックして読み込みます。

5. ローカルプロキシ起動

middleproxyから middleproxy_0.0.3_Windows_i386.tar.gz をダウンロード & 解凍（ご自身の環境に合わせてダウンロードしてください）します。

次のようにプロキシ情報を環境変数に設定して、起動します。

set http_proxy=http://{username}:{password}@proxy.example.com:8000
set http_proxy_username={username}
set http_proxy_password={password}
middleproxy.exe #起動してもログは出ません。

6. エミュレータ上のプロキシ設定

WiFiマークを長押し > AndroidWifi の歯車マーク > 右上の鉛筆マーク > Advanced options > Proxy > Manual

• Proxy hostname 10.0.2.2
• Proxy port: 9000

を入力して保存します。

補足ですが、 10.0.2.2 はエミュレータ上のAndroidからみた、ホスト側のIPです。

7. アプリ側の設定をする

設定ファイルに以下のネットワーク・セキュリティ設定を加えます。

<application
   android:networkSecurityConfig="@xml/network_security_config"

res/xml/network_security_config.xml を作成し、次を追加します。

<?xml version="1.0" encoding="utf-8"?>
<network-security-config xmlns:tools="http://schemas.android.com/tools">
    <debug-overrides>
        <trust-anchors>
            <certificates src="@raw/custom_ca"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

res/raw に custom_ca.cer を配備して参照できるようにします。

8. native_flutter_proxy

さて、やっとDartのコードです。native_flutter_proxy ライブラリの力を借りて、エミュレータ上のAndroidアプリからもインターネット接続を可能にします。

// Flutterのmain.dartや適当な初期化箇所に以下を追加
import 'package:native_flutter_proxy/custom_proxy.dart';
import 'package:native_flutter_proxy/native_proxy_reader.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();

  bool enabled = false;
  String? host;
  int? port;
  try {
    ProxySetting settings = await NativeProxyReader.proxySetting;
    enabled = settings.enabled;
    host = settings.host;
    port = settings.port;
  } catch (e) {
    print(e);
  }
  if (enabled && host != null) {
    final proxy = CustomProxy(ipAddress: host, port: port);
    proxy.enable();
    print("proxy enabled");
  }

  runApp(MyApp());
}

native_flutter_proxy ですが、エミュレータの端末に設定されたシステムのプロキシ設定を読み込み、インターネット接続を行えるようにしてくれます。

※それでもインターネット接続できない場合

1. Androidエミュレータ側のプロキシ設定を外してみる（direct）
2. localhost:9000 にmiddleproxyが起動しているか確認する（例： ホスト側のプロキシをproxy.example.com:8000 から、 localhost:9000 に変えてみて、ホスト側のブラウザが起動するか、もしくはcurlが通るか、確認してみる）

（任意）AndroidエミュレータへのChromeインストール

ここは任意ですが、エミュレータAndroid上にChromeをインストールしておくと、疎通などで便利なことがあるので合わせて設定しておくことをオススメします。

こちらからapkをダウンロードし、エミュレータ画面にdrag & dropします。

おわりに

本記事では、Flutterにおけるプロキシが存在するネットワーク環境での、Androidエミュレータのインターネット接続方法について紹介しました。

この手順を参考に、効果的にエミュレータを利用し、みなさんの開発に役立てれば幸いです。

最後にまた宣伝させてください！！

PostPixであなたの思い出をショートムービーという新しい形で残してみませんか？？
PostPixはFlutterで作成しています。ぜひダウンロードのほどお願いします！

こんにちは。HealthCare Innovation Group(HIG)¹所属の清水です。

本記事は、夏の自由研究ブログ連載2023の5本目です。

SwiftUIにおけるアラートダイアログを自作で実装する場合、どんな方法があるか考えてみました。

Swiftを用いたiOSアプリ開発で、アラートを自作したいと考えたことはありませんか？ Webアプリでもモバイルアプリでも、ユーザに問題を報告したり動作による影響を警告したりする上で、アラートは重要です。

SwiftUIでもalertが標準で用意されています。ただし、フォントサイズやダイアログのサイズが変更できないため、iPadで利用する場合画面に対してかなり小さく扱いづらいです。

SwiftUI標準のalertをシミュレータ iPad Pro (12.9-inch) で表示した際の図

画面に対してかなり小さい・・・。

そこで、「自由にカスタマイズできるアラートダイアログを自作する場合、どのような実装方法があるか」を自由研究の題材とすることにしました。

今回試してみた3種類のカスタムアラートを、実装方法と共に紹介したいと思います。
※もっと良い実装方法をご存知でしたら、教えていただきたいです！

検証内容

アラートは、通常の画面より手前（通常画面に重なる形）に表示します。
今回は、重ねて表示するためのコンポーネントの中から、以下の3種類の実装方法で比較していきたいと思います。

1. fullScreenCoverを利用した方法
2. overlayを利用した方法
3. ZStackを利用した方法

事前準備

画面に重ねて表示するためのダイアログをViewとして用意しています。SwiftUI標準のalertに見た目を寄せたアラートViewを、iPad Pro (12.9-inch) 向けにサイズ調整したViewがこちらです。このViewをいくつかの方法で重ねていきます。

※実装は、記事後半に記載しています。

1. fullScreenCoverを利用した方法

1つ目は、fullScreenCoverを利用した方法です。

引数に渡したフラグがtrueの時、全画面を覆うViewをモーダル表示します。

他の方法と比較

• メリット
  • 画面全体にモーダル表示するため、アラート表示中に他の動作ができないように制限しやすい。
• デメリット
  • fullScreenCover は表示時に画面下から上まで覆うアニメーションを伴って表示するため、アニメーションのカスタマイズが難しい（調べた限りほぼできない）。
    アニメーションを非活性にすることはできる。²

2. overlayを利用した方法

2つ目は、overlayを利用した方法です。
名前の通り、親Viewより手前に指定したViewを重ねて表示します。アラートの使用用途を考えるとちょうど良さそうです。

他の方法と比較

• メリット
  • overlay自体は重ねて表示するだけなので、アニメーションなどをカスタマイズしやすい。
• デメリット
  • あくまでも元となるViewに重ねるため、重ねて表示する範囲は呼び出すViewに依存する。
    例えば、VStackに紐づけるとVStackの範囲が重ねるViewの表示範囲となり、表示範囲外は操作できてしまう（下のgif参照）

3. ZStackを利用した方法

3つ目は、ZStackを利用した方法です。
fullScreenCoverやoverlayはViewのInstance Methodを利用していたのですが、こちらは内包するViewの表示順を制御するものなので、毛色が異なります。

他の方法と比較

• メリット
  • アプリ大元のViewに重ねることで、画面全体を覆って表示制御できる。
• デメリット
  • ダイアログ表示を制御するフラグやダイアログに表示する内容をApp階層まで伝える必要があるため、単一のView内で状態管理が完結しない。

コード実装例

今回利用したソースコードは、こちらです。

App

struct IsShowAlert: EnvironmentKey {
    static let defaultValue: Binding<Bool> = .constant(false)
}

extension EnvironmentValues {
    var isShowAlert: Binding<Bool> {
        get { self[IsShowAlert.self] }
        set { self[IsShowAlert.self] = newValue }
    }
}

@main
struct SampleApp: App {
    @State private var isShowAlert: Bool = false

    var body: some Scene {
        WindowGroup {
            ZStack {
                ContentView()
                    .environment(\.isShowAlert, $isShowAlert)
                /// 3. `ZStack`を利用した実装方法
                if isShowAlert {
                    CustomAlertView(alertTitle: Text("タイトル")) {
                        Button("OK") {
                            $isShowAlert.wrappedValue.toggle()
                        }
                    } message: {
                        Text("メッセージ")
                    }
                }
            }
        }
    }
}