iOSアプリアーキテクチャはさまざま存在しますが、多くはUIKit時代に誕生したものです。これらをSwiftUIで採用すると、SwiftUIの特色である状態管理やEnvironmentの仕組みをフルに活用できず、使い心地の良い設計になかなかなりません。
また、SwiftUIは毎年の変化が激しく、新しいUIコンポーネントはもちろん、ConcurrencyやObservabilityといった新しい言語仕様、ウィジェットやApp Intentsなどの新しい活用場面が登場してきました。これらの変化に対応できる柔軟な設計でないと、新機能の採用に難航してしまうでしょう。
せっかくSwiftUIを使うなら、純正の機能をなるべく活用したいものです。実際の案件や個人アプリの開発経験を元に、SwiftUIの使いやすさを最優先にする設計とは何かを探求します。
本トークでは、以下の点に焦点を当てます。
ソフトウェアエンジニアには、経済産業省のデジタルスキル標準にあるように、「変化の激しい状況の中でも、他のステークホルダーと柔軟に連携し、価値を生み出す」能力が求められます。
AI時代に求められるエンジニアの能力を伸ばすために、私たちは「エンジニアとクリエイターの共創」体験をつくり、たった一人のユーザーに絞って価値創出能力を鍛える「N1エンジニアリング」手法を活用しています。
本トークでは、クリエイターと共に開発を行う「N1エンジニアリング」の実績を基に、自らエンジニアとして共創した実体験と、全国の30名のエンジニアへ開発体験を提供した視点を持って、未来を担うエンジニアの育成手法を共有します。
具体的な内容は以下となります。
・他業種連携を強める共通認識の形成方法:
プランナー・デザイナー・エンジニアの役割を再認識し、共創体験で見えた良き領域侵犯。
・ユーザーの本質理解を深めるためのN=1の分析方法:
ユーザーの悩みにフォーカスし、課題解決に繋げるデプスインタビューと課題の着眼点。
・アイデアをMVP(Minimum Viable Product)に落とし込むプロセス:
独自のフォーマットによるアイデア立案と、MVPへの棚卸し。
このトークが、次世代型エンジニアになりたいと思っている方や、次世代型エンジニアを育てたいと思う方へ、一つの手段として参考となれば幸いです。
音は重要な要素であり、よりリッチな体験を実現するためには不可欠です。
効果音やBGMが鳴ることで、アプリの世界観を強調するだけでなく、使い勝手やユーザーの満足度を高めてくれます。
しかし、タイミングを誤ると、ユーザー体験が損なわれる可能性もあります。
例えば、多く使われているフレームワークとしてAVAudioPlayerがありますが、もしサイレントモードでも音を鳴らしたい場合には他のアプリのバックグラウンド再生を止めてしまうことがあります。また、アプリ内で特定の画面でBGMを鳴らす際には、ライフサイクルを考慮しないとアプリを閉じてもBGMが鳴り続けてしまうこともあります。
本トークでは、iOS / iPadOS アプリにおける音の取り扱いに焦点を当て、ユーザー体験への影響と対処法について解説します。
具体的には以下の内容をお話しします。
このトークが、音の体験について考えるきっかけとなれば幸いです。
Swiftのプロトコルは、異なる型に共通のインターフェースを定義・提供しますが、プロトコル自体は直接的に型として機能しません。プロトコルの利用は、存在型、ジェネリクス、およびOpaque Typeを介して行われます。このトークでは、Swiftにおけるプロトコルの利用方法の違いがコンパイル結果に与える影響を観察し、最終的なパフォーマンスにどう影響するかを解析します。
キーワードは、プロトコルを実装した構造体をコンパイルすると生成される "Protocol Witness Table" です。このテーブルは、プロトコルのメソッドが構造体の具体的な実装にどのように対応するかをマッピングします。このトークでは簡単な例から生成したコンパイル結果をSwiftライクな擬似言語でわかりやすく提示し、このテーブルの具体的な役割を解説します。
特にジェネリクスやOpaque Typeを用いた場合のメソッド呼び出しのインライン化や性能面における存在型の特徴といったパフォーマンスに関わる部分を重点的に解説します。
最後に今回の調査で分かったこれら3つの方法の利点と欠点を簡単にまとめます。
このトークはプロトコルの扱いに慣れてきたSwiftプログラマに向けたものです。
このトークを通じてプロトコルの理解が深まり、自信を持って3つの方法を使い分けられるようになることを目指しています。
iOSで地図を扱うには通常、MapKitが広く利用されています。MapKitを使用すれば地図上の現在位置情報を容易に扱えますが、このトークではMapKitを使用せずに任意の地図画像上に現在位置を表示する方法について解説します。
これを実現するために、以下のポイントについて詳しく説明します。
私はこの春、自社開発の企業に新卒入社しました。
かなり大規模なサービスを扱っているので、はじめはコードを読んでもちんぷんかんぷん。
バグ修正の際も、該当コードを特定するのでさえかなり時間がかかっていました。
すぐさまメンターの方に相談すると、
「自社のサービスに出来るだけ毎日触れてください。仕様書と照らしながら。」 と言われ、 「それだけ?」 と思いながらも実践してみることに。
それ以来、仕事プライベート問わず毎日30分から1時間ほど自社サービスに触れるようにしています。
その際、具体的には以下を意識しました。
この習慣を続けることで、バグ修正のスピードが大幅に向上しただけでなく、サービス全体の理解が深まり、遥かに効率的に業務を進めることができるようになりました。
入社間もない時期に仕様理解をガチるとめっちゃお得だよ!という話を具体例を交えてお話ししたいと思います。
アバター作成・ライブ配信などを楽しめるスマートフォン向けメタバースアプリ「REALITY」では、デザインの一貫性や生産性を向上するためにデザインシステムを導入しています。
デザインシステムを構築するには、タイポグラフィ、カラー、UIコンポーネントなど多くの要素が必要であり、既存のプロダクトに取り入れるのは非常に労力がかかります。
このトークでは、機能開発の傍らでデザインシステムを段階的に導入していった経験と、2年間にわたり続けた結果どのような効果が得られたか、「REALITY」のiOSアプリにおける実例を元に紹介します。
アバター作成・ライブ配信などを楽しめるスマートフォン向けメタバースアプリ「REALITY」では、デザインの一貫性や生産性を向上するためにデザインシステムを導入しています。
デザインシステムを構築するには、タイポグラフィ、カラー、UIコンポーネントなど多くの要素が必要であり、既存のプロダクトに取り入れるのは非常に労力がかかります。
このトークでは、機能開発の傍らでデザインシステムを少しずつ導入していった経験と、その中でも特に効果的だったカラーと画像アセットの自動エクスポートについて、「REALITY」のiOSアプリにおける実例を元に紹介します。
Swiftでのアプリ開発は直感的であり、多くの開発者に支持されていますが、性能や安全性で注目を浴びている言語Rustと組み合わせることによって、プロダクトの移植性や性能をさらに引き上げることができます。このトークでは、Rust製ライブラリをSwiftアプリケーションに組み込む手順を、わかりやすく説明します。
前半は、RustをC言語のライブラリとしてビルドし、ライブラリをSwiftや他のclang系言語で使えるように、適切な設定を施す方法を紹介します。
後半はライブラリをSwiftで使う方法を二つ紹介します。一つはSwiftのコンパイラを使った直接的なアプローチ、もう一つはSwift Package Managerを利用した方法です。各手法の特長と具体的な適用手順を簡潔に説明します。
また、SwiftUIとの組み合わせ例も紹介するので、Rustの機能をフロントエンドにどう活かすことができるか、具体的なイメージを持っていただけるはずです。
このトークは、Rustなど他の言語にも興味があるSwift開発者や、アプリの移植性や性能を高めたい方に向けたものです。RustとSwiftの組み合わせにより、アプリ開発の新しい可能性がどのように広がるかを提示します。
「家族アルバム みてね」(以下「みてね」)では、2023年10月から本格的にSwiftUIを導入し、新規画面の実装を中心にSwiftUIを積極的に使ってきました。現在約15%の画面がSwiftUIで実装されています。
みてねには「職能にとらわれずにタスクを取る」という文化が根付いているため、iOSやSwiftに詳しくない人にもわかりやすくなるよう、以下の特徴を持ったシンプルな設計を採用しています。
本セッションでは、どのようにして上記特徴を実現しているのか、具体的なコードを交えてご紹介します。
OSSのコントリビュートに対して、不安や敷居を不用意に大きくしていないだろうか?
「ましてや、AppleのOSSなんて仮にトライしてもメタメタにされる・・・」、と過剰に ざわざわ・・・ する必要はない。
実際にはオープンで新参者にも公正なスタンスのコミュニティが待っている。
驚くほど小さな修正でも価値がある。
先日、初めてAppleのOSSにコントリビュートした。
内容はself
キーワードが不要な部分を削除するだけ、それでも、レビューを貰いマージすることができた。
小さな修正であっても、どういった構成や方針を元に運用されているかを知るキッカケになり、非常に勉強になった。
具体的なステップとして、以下のポイントを取り上げていく。
・OSSプロジェクトの探し方
・PRを立てるまでの具体的な一例
・取り組んで得られたこと
コントリビュートはPRを送信するだけではない、質問に答えたりバグを報告することも含まれる。(Swift.orgのContributingより)
エンジニアであるなら、人生でOSSにコントリビュートしてみたい気持ちが少なからずあるのではないだろうか?
平凡な自分が踏み出した小さな一歩を共有して、誰か1人の一歩を踏み出すキッカケができたなら嬉しい限りである。
「だがこれでいい!」の精神で、OSSにコントリビュートしよう!
現在、多くのアプリではABテストが広く使われていますが、次のステップとして個別最適化が求められています。
AとBを比較するだけでなく、ユーザーの行動パターンに基づいたセグメント分割を行い、ABテストでは拾えなかったユーザーにもアプローチすることでより高い効果を得ることができます。
私たちのアプリではユーザーごとに異なる最適な課金画面を提供することで、収益の最大化を目指しました。
このセッションでは、複数パターンの課金UI検証を通じて得た以下の内容についてお話しします。
このセッションを通して、皆さんのアプリでも効果的なUIの個別最適化を実現しましょう。
Swiftは型安全な言語です。
しかし、Swiftで書かれたものが全て型安全になるわけではありません。
Swiftで書かれたコードの中にも、より型安全なコード、あまり型安全ではないコード、のように「型安全の度合い」は異なってきます。
型安全性が低いと、安全でないキャストが必要だったり、不正な入力値がコンパイルエラーにならなかったりし、開発者は多くのことを考えコードを書く必要があります。
一方で型安全性が高いと、より多くのことをコンパイラに委ねることができ、開発者が考えるべきことは減ります。
このトークではNotificationCenterのラッパーを題材に型安全性を高める方法を取り上げます。
NotificationCenterはObjective-C由来のインターフェースを持つため、安全でないキャストが要求され、不正な値を渡してもコンパイラエラーにならず、型安全性はあまり高くないといえます。
そんなNotificationCenterのラッパーの作成を題材に、Swiftの言語機能であるジェネリクスやマクロを用いて、型安全性を高めていく技術について紹介します。
題材はNotificationCenterですが、皆さんがこれからデザインするインターフェースにも通じる考え方と技術を紹介します。
このトークを通して、皆さんが"より"型安全なコードを書けるようになることを目指します。
多くのプロジェクトでは何らかのライブラリを活用してアプリの機能開発や自動化等を行っていると思います。
「家族アルバム みてね」でも、現在約30個のライブラリを活用して日々開発を行っております。
しかし、ライブラリのおかげで効率化できている一方で、ライブラリ起因の負債も多々ありました。具体的には、「更新が止まっているライブラリに依存している」「古いバージョンのライブラリを使い続けている」などです。これらの負債によって、Xcodeのアップデートでビルドエラーが発生して予想外に時間を取られたり、ライブラリの新しい機能を使えないことで追加の開発が必要になるなど、作業のスピード感に影響が出てしまっていました。
本セッションでは、依存するライブラリ起因の負債を解消するまでの具体的なステップと、負債を生まないために導入した仕組み、実際に運用してみた成果をお話します。特に以下のポイントについて詳しく説明します。
「Tint Colorをデフォルトのまま使うと、初心者感がありチープに見えるから避ける」
ある日の自分はそう考えていました。しかし、Appleが推奨する色をこのような理由で軽率に変更するのは適切なのでしょうか?いいえ、デフォルトの設定には、それなりの理由が存在するはずです。実際、デザインの一貫性やユーザー体験の向上を考慮した結果として、デフォルトの青色が選ばれている可能性があります。
本トークは、青色が選ばれた背景を以下の観点から考察していきます。
・他OSとの比較から見える共通点
・初代iPhone OSから現在のiOSまでのデザイン変化
・iOSとMac OS のデザインの共通点と違い
・カラーディスプレイの登場による影響
・ハイパーリンクが青色である理由
・青色が持つ視覚的効果と心理的影響について
このトークを通じて、Appleのデザイン哲学や、その背後にある考え方を深く理解することができるようになります。デフォルトの青色を軽視せず、その価値を再評価することで、より洗練されたデザイン選択ができるようになるでしょう。
iOSアプリ開発のCI/CD運用には、どのツールを使用していますか。多くの企業がソース管理にGitHubを利用していると思いますが、GitHub Actionsの利用には無料枠があり、それを超えるとビルド時間に応じて料金が発生します。
本トークでは、GitHubホステッドランナーからセルフホストランナーに切り替えた際のメリットとデメリットについて、具体的な事例を交えてご紹介します。これにより、皆さんがセルフホストランナー環境を構築する際のヒントを提供することを目指しています。
具体的には以下のポイントをカバーします:
今では多くの開発者にとって、APIはアプリ開発の基盤となっています。しかし、個人開発においてニッチな情報を取得したい場合、APIが提供されていないことが少なくありません。このトークでは、APIがない環境でも学生向けの学修サポートアプリを実現するために、WKWebViewによるJavaScriptとの相互通信などの活用事例について経緯を踏まえて紹介します。
APIが当たり前の時代に開発を始められた方々にとって、これらの技術を習得することで、APIがない環境でも柔軟に対応できるようになり、開発の選択肢が大幅に広がるようになります。このトークを通じて、あなたも新たな技術的アイデアを得ることができるでしょう。
また、大学に学生用のアプリがない学生開発者の皆さんへ
「自身で大学のアプリを作り、学生生活を向上させたい!」と思うきっかけなれば嬉しいです!
アプリが成熟してくると、プロユース向けに複雑なジェスチャーを実装することがしばしばあります。
本セッションでは、有名なアプリに組み込まれているユニークなジェスチャーを紹介し、その実装方法について考えます。
また、既存のアプリを壊さないように安全に実装するコツや、アクセシビリティを考慮した設計の重要性についても触れます。
何もやる気がなくのらりくらりと生きてきた人間
1社目(iOSエンジニア)を辞めて2年間ニートした
プライベートで技術を調べることがない(猛省)
操作感とかUI系はちょっと関心がある(勉強はしてない。感性。)
そろそろ本当に年齢やキャリアを考慮してプランを立てなくちゃいけないので、必要なことをちゃんと考えてみる。
・技術面(swift問わず)
・組織での立ち回り
-- 以下すごく大事 --
・足は引っ張りたくない
・仕事してる感は欲しい
・評価もされたい、お金欲しい
・頼られたい、かっこつけたい
アニメーションはアプリケーションのユーザー体験を向上させる重要な要素です。
iOS 17のSwiftUIでサポートされたKeyframe Animationを活用することで、高度で魅力的なアニメーションを効率的に実装できるようになりました。
本トークでは、以下の内容について説明します。
魅力的でインタラクティブなアニメーションを実現するための参考になれば幸いです。