トーク

普段bot開発はnode.jsやpythonなどで行われているかと思いますが、swiftでも開発ができることはご存知でしょうか？
aws-lambdaにswiftのruntime用意されているのでそれを利用することで実現が可能です。

bot上でAppstoreConnectAPIを利用することで今までfastlane上やローカル環境で行っていた作業がslackだけで完結できます。
AppstoreConnectAPIだけでなく、GithubやBitriseにも対応ができるので作業の効率化が高められると思います。

今までアプリの審査提出する準備もマウスでポチポチ動かしていた作業やめませんか？

swift製のslack-botを運用し始めて一年ほど経過したのでそこまでの知見などを共有したいと思います。

ARCの登場によって、エンジニアがメモリを意識することは殆どなくなりました。
それでも、ヒューマンエラーは必ず起こるもの...循環参照を完璧に避けることは出来ません。
つまり、「循環参照対策として[weak self]さえつけておけば良い」という状態は準備不足です。

本トークで循環参照による悲劇の話とそのデバッグ方法を聞くことで、
危機意識が高まると共に、実際に起こった際の具体的なアプローチを知ることができます。

実際にデバッグ方法を知らなかった時と知っていた時で、解決までのリードタイムが大きく違ったため
より多くの方に知っていただけたらと思っています。

-概要
UIKit+MVVM+Fluxで実装されたプロダクトコード。
2014年のサービス開始から9年が経ち、特にコア機能のユーザーフリック面において改修コストが無視できなくなってきた。
中長期的な開発コスト・リグレッションテスト・CSコストを下げることを目的として、
コア機能のSwiftUIへのリプレイスを決断。

リプレイスのポイントは次の3点、
①要件をどれだけカバーできるか
②影響範囲をどれだけ小さくすることができるか
③いつでも切り戻しが可能であること

影響範囲が、、、時間が、、、という課題は付きものですが、
このトークセッションで少しでもリプレイスへ踏み出すきっかけとなれば幸いです。

-概要
デザインシステム刷新によって、既存ダイアログを6パターンに定義。
そしてUIKitではなくSwiftUIで実装をすることになりました。
このプロポーザルを聞くことで、負債を小さくするために工夫したことと、
@Stateが更新されないケースを具体的に知ることができます。

-負債
考慮したい負債は次の3点です。
① Viewの処理が呼び出し元に漏れ出す具合
② デザイン確認コストが高い
③ 実装の柔軟性が高い

-対応
負債へと向き合うポイントは次の2点
① Componentの規約を意識しなくて良い状態にすること
実行時に規約に反した実装を落とし、ヒューマンエラーを弾く。
② Viewで完結すること
ダイアログの特性上、どのVCからも呼び出される可能性があるため、
呼び出し元のPresenterとのインターフェースは必要最低限にする。

詳細は発表にて！！！！

-概要
iOSでは、ARCの登場によってメモリ管理への意識は無くなりつつあります。
循環参照とは何なのか、static修飾子をつけたメソッド・プロパティは何故インスタンスを生成しなくてもアクセスできるのか。
逆に、インスタンスからなぜそれにアクセスできないのか。
それを知るには、メモリ領域の種類や割り当ての仕組みから学ぶ必要があります。

このトークセッションでは、
「メモリとアドレス」「メモリへの割り当て」「4種類のメモリ領域」というテーマで深ぼっていくことで、
メモリを意識した開発ができるようになります。

なんとなくweak selfをつけよう、インスタンス化しなくて良いからstaticをつけよう、
そんな意識からの脱却を目指します。

A/Bテストはデータを活用して意思決定をサポートする手法です。
この方法を活用することでモバイルアプリの改善やUIの最適化が可能となります。

今回のトークではモバイルアプリにおけるA/Bテストの基礎や実施方法を解説し、具体例などを交えながら効果的なA/Bテストのデザインや勝ちパターンの見つけ方についてお話します。

・A/Bテストの基礎
・テストの実施とランダムな割り当ての重要性
・データの収集と計測手法の紹介
・データの解釈と結果の活用
・A/Bテストの成功事例と注意点の紹介

本トークを通じてA/Bテストの基本的な概念を理解し、実際のアプリケーションにおいて効果的なテストを実施するための手法やポイントを知ることができます。
アプリケーション開発者にA/Bテストを有効活用していただき、今後の開発に活かしていただけると幸いです。

SwiftUIでTCAを効率的に適用するためのモジュール化の原則を紹介します。

iOSプロジェクトの規模が大きくなるにつれて、複雑さは指数関数的に増加します。 この複雑さをコントロールするために、高い凝集力と低い結合を持つモジュールの編成方法を紹介します。
このトークでは、Github上のリポジトリを検索するサンプルアプリでTCAプロジェクトをモジュラー化するための実践的な方法について説明します。

堅牢なモジュールを構築するための原則について説明します。

• 高い結合力 低い結合力
• 懸念事項の分離
• 依存関係の逆転
• テスト容易性

対象者

• SwiftUIを使用しているチーム
• TCAの採用を検討しているチーム

本プレゼンテーションでは、以下の内容に焦点を当てます。

• TCAプロジェクトの長所と短所
• モジュール化の利点と注意点
• 堅牢なモジュール構築のための原則

ニフティ株式会社でニフティニュースというサービスの開発リーダーをしている中村です。
ニフティニュースというサービスではアプリ開発も行っているのですが、自分自身は機械学習のエンジニアリングが専門のため、アプリ開発は本職の別のエンジニアにずっと任せていました。
しかし、ある時に一念発起して「アプリ開発を理解できるようになりたいな。まずはiOSアプリ開発なのかな。」と思い立ち、最新のiOSアプリ開発を社内勉強会で勉強し始めました。

今のモダンなアプリ開発とは何なんだろうか？
MVVM、リアクティブプログラミング、SwiftUI、TCAなど、アプリエンジニアではなくWebエンジニア出身のエンジニアがどのようにしてアプリ開発を理解していったのか、その過程を発表します。

Kotlin Multiplatformは、Kotlinで記述したAndroid・iOS向けの共通ソースコードからiOSのFrameworkを出力でき、iOSアプリプロジェクトに取り込むことで利用できます。
しかし、Kotlinで実装しなければならないため、試してみようと思ってもハードルがあるかと思います。

本トークでは、Swiftの任意の機能からKotlinの対応した機能を逆引きして解説しながら、それらの機能がFrameworkとして出力されるとSwiftからどのようにアクセスできるのかについても解説します。
例として、「SwiftのenumのAssociated Valueは、Kotlinだと何になる？」「それがFrameworkとして出力されるとどうなる？」などを話していきます。
皆さんがKotlin Multiplatformに触れるきっかけとなるトークになれば幸いです。

Chatwork株式会社のiOSチームでは、SwiftUIの利用を進めており、宣言的UIであるSwiftUIの恩恵を最大限に享受するため、会社独自のリアクティブな新アーキテクチャを考案し、既存のプロダクトへの導入を進めています。
今年入社した23新卒の私も例外ではありません。
新卒iOSエンジニアのオンボーディングとして学習課題のアプリの作成に取り組む中で、配属1日目からその『新アーキテクチャ』を使って、自分が過去に実装したアプリのリライトを行っています。

このセッションでは、「新卒iOSエンジニア」 「新アーキテクチャ導入の最中でのジョイン」という視点から
・新卒iOSエンジニアのオンボーディングの概要
・どのように課題に取り組んだのか
などを5分で簡単にお話しします。

入れ替わり立ち替わりのフリーランスエンジニアの方々が残してくれた画面ごとに共通化されていない実装！
肥大化していったUIKitのプロジェクト、複雑化するViewModel！
レイアウトを調整する度に発生するビルドの待ち時間！
それらの様々な課題にどう立ち向かい乗り越えてきたか！？
サービスはどんどん成長していく中で、時短勤務のエンジニアがSwiftUIやSwift Concurrencyのような最新技術を調査して取り入れて必ず起きるトラブルに対応する暇はない！
WebやAndroidチームに遅れを取らないよう既存資産をなるべく活かすよう試行錯誤していって出来上がったプロジェクト構成とは！？
まだまだSwiftUIを取り入れられないUIKitのプロジェクトの現場も多いでしょうし、そんな現場で開発ペースをあげるためのきっかけになると幸いです

長らくユーザにご利用いただいている弊社アプリは、これまでの長い歴史の中で多くの追加開発が行われてきました。
その結果、アプリ全体のUI・UXに統一性がない、というデザイン面での課題に直面しました。
そこで私たちは昨年からデザインシステムを導入するプロジェクトを進め、その課題へのアプローチを始めています。

本セッションでは、その構築の過程で見つけた知見を共有させていただきます。
社内でデザインシステムを一緒に作る仲間集めをしていた際の苦労や、実際に作業を始めた際に陥ったデザイントークンの設計に関する落とし穴など、プロジェクトマネジメントやチームビルディング、そしてデザインシステム設計時に試行錯誤した事例をお伝えします。

デザインの話が好きな方、デザインシステムに興味のある方、そしてこれからデザインシステムを作ることを検討している方の参考になれば幸いです。

今年のWWDCでもiOS17の各種アップデート内容について色々と発表され、大いに盛り上がりました。
しかし、その発表内容の多くがiOS17+のAPIのため、実際に実務で開発しているプロダクトへの導入はまだまだ先だなと感じている方も多いでしょう。

しかし、古いiOSをサポートしているプロダクトでも、まだまだ活用しきれていない一昔前の革新的な機能や改善点があるはずです。
このセッションでは、少し前のiOSアップデートにフォーカスし、そういった未発掘のポテンシャルを探ります。
具体的には、iOS 14やiOS15あたりのバージョンにスポットを当て、どういったアップデート内容があったのかを振り返ります。

日本にiPhone 3Gが上陸した2008年から今日までの間でiOSは大きく変化してきました。
App Store、Siri、フラットデザイン、Touch ID/Face ID、ウィジェットなど今では当たり前となった様々な機能がいつリリースされたものか覚えているでしょうか？
そんなiPhone 3Gが日本に上陸してから現在の最新バージョンまでのiOSの歴史を、具体的な例も挙げつつ5分間で振り返ります。

基盤開発やリファクタリングを主に行っているチームで、それまで取り組んでいたアジャイル方式のスクラムからカンバン方式に移行した話をします。
本トークではカンバン方式の説明およびカンバンを取り入れて良かったことなどを具体的な例を用いながらお伝えできればと思います。

AppleのGPU向けプログラミングインターフェースMetalと、画像処理で一般に用いられる形態学（Morphology）を駆使し、麻雀牌の画像からその種類を見分けることに挑戦します。

「分類」と聞くと、機械学習や学習データが必要なのでは？と思う方もいるかもしれませんが、今回はあくまで画像処理だけのアプローチにこだわります。 (学習データなどは使いませんが、いくつかの制約を課します。)

宜しくお願いします。

(本セッションを聞いて下さる方へ: 麻雀のルールを知らなくても全く問題ありません。)

AppleのGPU向けプログラミングインターフェースMetalと、画像処理で一般に用いられる形態学（Morphology）を駆使し、麻雀牌の画像からその種類を見分けることに挑戦します。

「分類」と聞くと、機械学習や学習データが必要なのでは？と思う方もいるかもしれませんが、今回はあくまで画像処理だけのアプローチにこだわります。 (学習データなどは使いませんが、いくつかの制約を課します。)

宜しくお願いします。

(本セッションを聞いて下さる方へ: 麻雀のルールを知らなくても全く問題ありません。)

皆さんは、macOS のスクリーンセーバを自作できることをご存知ですか？
実は、Apple から Screen Saver Framework が提供されており、ScreenSaverView を継承してカスタムスクリーンセーバを Xcode で開発できます。ただし、UIKit や SwiftUI でお馴染みのアニメーションは使えず、フレーム毎の座標計算が求められるなど、スクリーンセーバの開発には独自のテクニックが必要となる一面もあります。

このトークでは、 ScreenSaverView のライフサイクルやレイアウトテクニックを紹介しながら、5分という制限時間内で リアルタイムにスクリーンセーバを構築します。
トーク終了後には、きっと Screen Saver Framework の魅力に取り憑かれることでしょう！

このセッションを通じて、Core ML Stable Diffusionの利用方法を簡単に深く学び、iOS上でAIを活用することができるようになります！
わくわくするAIの世界を楽しく体験しましょう！

1. Core ML Stable Diffusionとは何か？
   　どのように機能するのかを、専門的な言葉をなるべく使わず基本概念やメリットを理解できるように解説します。
2. 手順と実践例
   　具体的な手順と実際のコード例を通じて、iOSアプリに組み込む方法を学びます。
3. デモとエクササイズ
   　参加者が自身のデバイスで手軽に試せるデモやエクササイズを用意します。
4. ユーザーエクスペリエンスのアイデア
   　Core ML Stable Diffusionを使って実現可能なユーザーエクスペリエンスのアイデアを共有します。

iOSではリストの子要素をスワイプするUIをよく見かけます。
SwiftUIでは、Listに子Viewを列挙することでリストを実現でき、その子Viewに対してswipeActionsを利用しスワイプを可能にします。
しかし親ViewがList以外の場合、子ViewにswipeActionsを利用しても、スワイプは適用されません。
よって、親ViewにListを使わずに構築しているリストなどの子Viewにスワイプを適用する場合、swipeActionsを適用できないため独自実装が必要となります。

本トークでは、Listではない親Viewの子Viewにスワイプを適用するために独自実装したSwipeableStackを紹介します。
SwipeableStackの実装内容と使い方を具体的に解説します。