トーク

初めまして！
株式会社ゆめみの2023年卒のFlutterエンジニアで、心理学系の大学院に通っていて、大学院では心理学の観点からVRの研究を行っております！！
私の趣味は、個人開発とサッカー観戦です！

Apple Vision Proは、Appleが初の空間コンピュータとして販売する発売予定の複合現実ヘッドセット型PCである。これは2023年のWorldwide Developers Conferenceで2023年6月5日に発表され、米国では2024年初旬に購入可能になる予定です。
今回のApple Vision Proの発表は世界に影響を与えるものだと私は思います。値段が高すぎるなどの意見もあると思いますが、機能面で見るととても納得できるものがあります。

心理学系の大学院生の視点からみたApple Vision Proの発売による世界への影響を話していこうと思います！！！

初めまして！
株式会社ゆめみの2023年卒のFlutterエンジニアで、心理学系の大学院に通っていて、大学院では心理学の観点からVRの研究を行っております！！
Apple Vision Proは、Appleが初の空間コンピュータとして販売する発売予定の複合現実ヘッドセット型PCである。これは2023年のWorldwide Developers Conferenceで2023年6月5日に発表され、米国では2024年初旬に購入可能になる予定です。
Apple Vision Proの機能がAppleから公開され、一部には他にはない機能が発表されました。VRのコンテンツの構想のなかで今回のApple Vision Proはとても革新的だと思っています。
このプロポーザルでは、心理学部の大学院生の視点からみたApple Vision Proの将来性とVRの発展について話していこうと思います。

はじめまして！
株式会社ゆめみの2023年卒のFlutterエンジニアで、同時に心理学の大学院生でもあるいせりゅーと申します。私の趣味は、個人開発とサッカー観戦です！

「FlutterはiOSに勝てないのか：クロスプラットフォームとネイティブのパワーバランス」では、FlutterとiOSネイティブの競争力を比較し、それぞれの特性nなどを掘り下げます。パフォーマンス指標（CPU使用率、メモリ使用量、レンダリング速度）を用いて両者を評価し、iOSネイティブの全機能がFlutterでも実現可能か、その逆が成り立つか明らかにします!
また、iOS特有の機能（例：Face ID、ARKit）がFlutterでどのように扱われるか、開発体験の観点からも比較します。このプロポーザルを通じて、読者はFlutterとiOSネイティブのパワーバランスについて深い理解を得られるような話をします！

はじめまして！！！

株式会社ゆめみの2023年卒のFlutterエンジニアで、同時に心理学の大学院生でもあるいせりゅーと申します。私の趣味は、個人開発とサッカー観戦です！！！

Flutterエンジニアとして、我々は頻繁に「iOS固有の機能」を再現する問題に直面します。本プロポーザルでは、これら独特なiOSの機能とFlutterの能力のギャップを詳しく分析し、明らかにします。具体的には、フレームワークやユーザー体験といった、Flutterが完全には再現できない機能について深く検討します。また、この比較を通じて、Flutterがどのようにこれらの制約を克服または回避するためのさまざまな手段や戦略を探求します。

Flutterエンジニア視点だからこそわかるiOSにしかできないことをしっかりと話していこうと思います！！！

業務でモダンなアプリ開発がしたい！それっぽいことがしたい！
でも製品への新機能を提案できるほど知識も経験も足りてない。おまけに当分はアプリ開発に割けるリソースもなさげ。。。

ならば社内勉強会を立ち上げて知識も経験も傘増ししてしまえ！とノリと勢いで始まった勉強会立ち上げ計画。

ひよっこエンジニアがアプリの勉強会を運営していく中で、

• どうやったら知識だけでなく経験を身につけることができるか？
• どうしたら個人の勉強では得られない価値を生み出せるか？

と、試行錯誤してきた取り組みをご紹介します。

リファクタリングやマルチモジュール化などを行う際に、そもそも現状どういう依存関係が存在するのかを把握してから議論する必要があると考えています。
本LTでは、依存関係をグラフなどで表す方法の検討過程と、実際にグラフ作成のために作成したツールの紹介とその活用についてお話しします。

iOS, Android両プラットフォームでアプリを長期間運用していると、OS間での画像や文言の差分、異なる名称でのリソース追加などによって細かな修正やコミュニケーションが必要なケースが多くあります。

このトークでは、これらの問題を解決する手法としてテキスト・カラー・画像のリソースをKotlin Multiplatform Mobileを利用し、iOSとAndroidのロジックを共通化することで、OS間でリソースを共有する方法について紹介します。
さらに、共通化するにあたっての技術選定~導入方法やそれぞれのOSから見たメリット・デメリットについてもお話しします。

本トークを通じてリソース管理の複雑さを軽減する手法の提案や、Kotlin Multiplatform Mobileを利用するメリットについてお伝えすることができれば幸いです。

現在、趣味として徳島大学生向けの学修サポートアプリを個人で開発・運用を行っている大学生です！
このアプリは、講義情報やレポート提出、そして学内情報などの一元化を目的としており、それにはJavaScriptインジェクション、Webスクレイピング、そしてRSSフィードを活用し、学生生活のほとんどが一つのアプリで完結するという形で実現しました。
現在、AppStoreで公開しており、徳島大学生の3人に1人が利用しています。
このLTではAPIが全盛の今、なぜこのアプリではJavaScriptインジェクション、Webスクレイピングといった技術を採用するに至ったのか、その背景や技術・運用について紹介しますので、エンターテイメントとしてお楽しみいただければ幸いです。
また、学生の皆さんに対して「不便だと感じたら、自分で変えてみよう」と少しでも思っていただければ嬉しいなと思います。

みなさん、iOSアプリは何で開発していますか？
大半の方は、こう答えるでしょう。「Xcodeで開発している」とッ！
このLTでは、開発効率が上がるかも？しれないXcodeの機能やショートカットコマンドを中心に紹介します。
すでにご存知の方は、「あー、これあるよね、使う使う」ってテンションで見ていただき、
初めて知る人は「あ、こんな機能あったんだ！」と新しい発見をして、使えるとこはご自身の開発に取り入れていただけると幸いです。

▼お品書き
・Xcodeの便利機能 〜個人的おすすめ設定を添えて〜
・Xcodeでショートカットコマンド 〜個人的よく使うショートカットコマンド風〜

新規プロジェクトでSwiftUIが採用されるケースが増えてきました。
UIKitで運用してきた既存プロジェクトにおいては、部分的導入から進めているでしょうか？
SwiftUIは細かいところに手が届かないから...既存の設計と相性が...と導入を諦めていますでしょうか？

弊社では、積極的にSwiftUIへの置き換えやリアーキを行っています。
・VCからもViewからも呼び出し可能
・カスタムアニメーション付き
・画像の取得があれば成功したら表示
など、これらの条件に従いつつ実装した経験を元に、
UIKitで作られたダイアログと比べてどの点が便利に感じたのか、不便に感じたのかを発表します。

このトークセッションを通して、
SwiftUIの部分的導入の選択肢にダイアログが増えれば幸いです。

概要
iOS と Android のクロスプラットフォーム開発の手段として、これまでに「Flutter」や「KMM」が選ばれてきました。
これに加え、「Compose for iOS」というものがJetBrainsから出てきたことはご存知でしょうか？
iOSアプリのUIをComposeで実現できるとなると、今後のiOS・Androidの垣根はどうなっていくのでしょうか？

そこで、今後の技術選定の選択肢に入りうるのか、という議題を元に
「Compose for iOS がどこまで表現できるのか」 に焦点を当てて発表します。
逆に言えば、「iOSでしか表現できないものはあるのか」というiOSエンジニアとしての危機意識でもあります。

トークセッションを通して、1人でも多くの方に選択肢の1つとして残り、
より知見が溜まっていく流れになると幸いです。

普段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テストを有効活用していただき、今後の開発に活かしていただけると幸いです。

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

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

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

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

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