オンボーディングでこのような課題に直面したことはありませんか?
私たちのチームではこれらの課題を解決するために、本番のプロジェクトに近いアーキテクチャと構成を持つチュートリアルプロジェクトを作成し、実際の開発に近いフローでのオンボーディングを行なっています。
また、新メンバー向け以外にも課金やCI/CDなどの難易度の高い知識のキャッチアップや新しく公開されたAPIのPlaygroundとしても活用しています。
本トークでは、技術のキャッチアップを促進するためのチュートリアルプロジェクトの具体的な活用方法を紹介します!
このトークが少しでも皆様のチームのオンボーディングの参考になれば幸いです。
業務でモダンなアプリ開発がしたい!それっぽいことがしたい!
でも製品への新機能を提案できるほど知識も経験も足りてない。おまけに当分はアプリ開発に割けるリソースもなさげ。。。
ならば社内勉強会を立ち上げて知識も経験も傘増ししてしまえ!とノリと勢いで始まった勉強会立ち上げ計画。
ひよっこエンジニアがアプリの勉強会を運営していく中で、
と、試行錯誤してきた取り組みをご紹介します。
SwiftUIは、iOSアプリを簡単に作成することができるフレームワークで、最近ではiOSアプリ開発の主流となりつつあります。
SwiftUIを使うことで、コードの可読性が高くなり、アプリ開発の効率も上がります。
このトークでは、SwiftUIをUIKitで作られたアプリに上手に取り込んで、より簡単にアプリ開発を行う方法を紹介します。
トークの内容は、スピーカーの開発しているSNSアプリ「Nightfox DAWN for Mastodon」の実際の開発を通して得た情報をベースにしています。
そのため、データのバインディングや、ビューやレイアウトの共存などの基本的なところから、SwiftUIを使うべきで無い部分などの実践的を具体例を踏まえてお話しします。
質疑応答では、あなたの作っているアプリに関してSwiftUIをどのように取り込めば良いのかをディスカッションします。
iOSアプリを開発する中でユニットテストを書く時に、モックを使う機会は多いのではないでしょうか。
例えばモックを使うことで実際の通信を伴わないテストを書くことができ、テストが実行しやすくなります。
しかしモックすることで実際のプロダクションコードでの動作をテストしていない、保守性が下がるなどの問題もあります。
そのためモックの使い所を見極め、効果的に使う必要があります。
モックの扱いではTDDの文脈でロンドン学派、古典学派という2種類のアプローチがあります。
ロンドン学派はモックを積極的に使い、古典学派ではモックを可能な限り使いません。
この両者の議論を元に、プレゼンテーションロジックが多いなどiOSアプリ開発ならではの要素を考慮した上で、モックの効果的な使い方と使い分けについて品質保証、保守性等複数の観点から検証し、紹介します。
一緒により良いユニットテストのための議論をしましょう!
リファクタリングやマルチモジュール化などを行う際に、そもそも現状どういう依存関係が存在するのかを把握してから議論する必要があると考えています。
本LTでは、依存関係をグラフなどで表す方法の検討過程と、実際にグラフ作成のために作成したツールの紹介とその活用についてお話しします。
「せっかく買ったiPadを活用できないまま放置している」、「SwiftUI触る機会がない」、「Macは持ってないけどiPadならある」、「iPadでプログラミング学習をしたい」
そんな方にオススメしたいのがiPadでアプリ開発です!
ついこの前まで私自身もiPadを活用できずに放置ぎみで、SwiftUIも書いたことがない状況でした。
このままiPadをろくに使わずに手放すのは悔しかったので、iPadだけでアイコン作成、スクリーンショット作成、アプリの開発・公開まで全てを完結させるチャレンジをしてみました。
使用したツールや難所の紹介、得られた学びをお伝えできたらと思っています。
これを見て是非皆さんにもチャレンジしてみていただきたいです。
「STORES ブランドアプリ」は、アパレルショップやコーヒーショップなど、各ブランド毎のオリジナルアプリを構築・提供するサービスです。
毎月複数の新規アプリ作成を行いリリース、また新機能を実装するたびに既存のアプリのアップデートを頻繁に行なっています。
これらを自動化するために、XcodeGenに環境変数を用いることで一つのリポジトリからアプリ毎のxcodeprojファイルを動的に作成しビルドする仕組みをCI/CDパイプライン上に構築しました。
このトークでは、一般的なアプリ開発にも応用できるXcodeGenとCI/CDを駆使した効率的なアプリ開発・リリース手法を解説します。
内容:
「二次元コードがアプリで読み込めません!」
ある日舞い込んだお問い合わせ。
聞いたところ、ある店舗に設置してあるQRコードだけが読み込めないらしい。
他のお店や手元の環境では全く再現しない。
現地に行って試してみると、確かに読み込めない。
気になる点はというと、どうも画面がチカチカしている。
試しに他社の二次元コードリーダーのあるアプリで試してみても、多くのアプリで同様に読み込めない。
これはなんだろう…
上記は実際に運用中のプロダクトで遭遇した、フリッカー現象の事例になります。
このトークでは、FrameRateとフリッカー現象について説明し、二次元コードのスムーズな読み取りのためのFrameRateの設定を提案します。
内容:
「外部のECサイトをアプリに組み込んで、会員情報・認証情報をアプリと同期させたい」
上記は「STORES ブランドアプリ」で実際に行ったEC連携の事例ですが、WebViewとネイティブ間のデータ連携は珍しくない要件だと思います。
このような場合、WebView内の特定アクションや遷移をネイティブ側でフックする必要があります。
登録・ログイン・SNS連携などの挙動ごとのハンドリングに加え、バックエンドとの連携も重なると、とても複雑な状態管理が求められます。
このトークでは、WebView-ネイティブ間連携を必要とする多くのアプリの複雑な状態管理の荒波を、ステートマシンという羅針盤を駆使することで乗り越える指針を示します。
内容:
iOS, Android両プラットフォームでアプリを長期間運用していると、OS間での画像や文言の差分、異なる名称でのリソース追加などによって細かな修正やコミュニケーションが必要なケースが多くあります。
このトークでは、これらの問題を解決する手法としてテキスト・カラー・画像のリソースをKotlin Multiplatform Mobileを利用し、iOSとAndroidのロジックを共通化することで、OS間でリソースを共有する方法について紹介します。
さらに、共通化するにあたっての技術選定~導入方法やそれぞれのOSから見たメリット・デメリットについてもお話しします。
本トークを通じてリソース管理の複雑さを軽減する手法の提案や、Kotlin Multiplatform Mobileを利用するメリットについてお伝えすることができれば幸いです。
デザイントークンは、色やタイポグラフィなど、UIを構成する最小単位となるものである。
デザイントークンを用いることで、職種やプラットフォームの壁を越えて、アプリUIの設計・実装を円滑に進めることができる。
本トークでは、デザイントークンの概要とその構造(Global tokenとAlias token)について説明する。
また、Asanaにおけるデザイントークンの運用を参考に、カラートークンの設計方法についても述べる。
加えて、実践的な内容として、Token Studio for Figma と Style Dictionaryを用いた、アプリ開発への組み込み方法と注意点についても解説する。
SnackbarはMaterial Designでも定義されているコンポーネントである。一方でHuman Interface Guidelines には定義されていない。
Snackbarには、ユーザの操作に応じた短いメッセージを素早く表示するのに適しているといった利点があり、iOSアプリにも組み込むことで、操作完了時やエラー時のメッセージのやり取りをスムーズに行える効果が期待できる。
本トークでは、Snackbarの基礎や効果を整理して解説するとともに、VIPERアーキテクチャをベースとしたiOSアプリにおけるSnackbarの設計・実装のポイントについて解説する。
SnackbarはMaterial Designでも定義されているコンポーネントである。一方でHuman Interface Guidelines には定義されていない。
Snackbarには、ユーザの操作に応じた短いメッセージを素早く表示するのに適しているといった利点があり、iOSアプリにも組み込むことで、操作完了時やエラー時のメッセージのやり取りをスムーズに行える効果が期待できる。
本トークでは、Snackbarの基礎や効果を整理して解説するとともに、VIPERアーキテクチャをベースとしたiOSアプリにおけるSnackbarの設計・実装のポイントについて解説する。
iOSアプリケーション開発において、ソースコード・自動テスト・開発規模が大きくなっていくと、CI/CD におけるビルド・テストの実行時間は長くなってしまい、結果として開発スピードを低下させてしまいます。
特に XCUITest などのUIテストでは、iOS 実機や iOS Simulator を動かしてテストを実行する必要があるため、実行時間が長くなりがちです。
このセッションでは、iOS Simulator を使ったUIテスト(XCUITest)をCircleCIで分割・並列実行することによって、実行時間を大幅に短縮する方法についてご紹介します。
・UIテスト(テストピラミッド) / XCUITest とは?
・UIテストをメンテナンスする上での課題とは?(環境、実行時間、不安定、メンテナンスなど)
・CircleCIを使って UIテスト(XCUITest) を分割・並列実行する方法
現在、趣味として徳島大学生向けの学修サポートアプリを個人で開発・運用を行っている大学生です!
このアプリは、講義情報やレポート提出、そして学内情報などの一元化を目的としており、それにはJavaScriptインジェクション、Webスクレイピング、そしてRSSフィードを活用し、学生生活のほとんどが一つのアプリで完結するという形で実現しました。
現在、AppStoreで公開しており、徳島大学生の3人に1人が利用しています。
このLTではAPIが全盛の今、なぜこのアプリではJavaScriptインジェクション、Webスクレイピングといった技術を採用するに至ったのか、その背景や技術・運用について紹介しますので、エンターテイメントとしてお楽しみいただければ幸いです。
また、学生の皆さんに対して「不便だと感じたら、自分で変えてみよう」と少しでも思っていただければ嬉しいなと思います。
Appleはユーザーのプライバシーは大事だとWWDCで毎年のようにその重要性を話してきました。
また例年様々なアップデート・セッションが用意されてきました。
そして、今年もPrivacy Manifestsなど新しいアップデートがあり、app・SDKの情報のトラッキング状態などの把握が簡単になった、許可プロセスが変わったなどがあります。
ではこれまで一体どれくらいの&今年はどんなアップデートがあったのでしょうか。
このLTではこれまでのプライバシー関係のアップデート内容を振り返り、WWDC23の発表内容について探っていきます。
「ゴール」
Appleがどれだけプライバシーを大切にしてきたかを体感でき、今年のアップデート概要が把握できる
「アジェンダ」(検討中)
・プライバシーの考え方の柱について
・これまでのプライバシーアップデート内容
・WWDC23でのプライバシーアップデート内容
みなさん、iOSアプリは何で開発していますか?
大半の方は、こう答えるでしょう。「Xcodeで開発している」とッ!
このLTでは、開発効率が上がるかも?しれないXcodeの機能やショートカットコマンドを中心に紹介します。
すでにご存知の方は、「あー、これあるよね、使う使う」ってテンションで見ていただき、
初めて知る人は「あ、こんな機能あったんだ!」と新しい発見をして、使えるとこはご自身の開発に取り入れていただけると幸いです。
▼お品書き
・Xcodeの便利機能 〜個人的おすすめ設定を添えて〜
・Xcodeでショートカットコマンド 〜個人的よく使うショートカットコマンド風〜
新規プロジェクトでSwiftUIが採用されるケースが増えてきました。
UIKitで運用してきた既存プロジェクトにおいては、部分的導入から進めているでしょうか?
SwiftUIは細かいところに手が届かないから...既存の設計と相性が...と導入を諦めていますでしょうか?
弊社では、積極的にSwiftUIへの置き換えやリアーキを行っています。
・VCからもViewからも呼び出し可能
・カスタムアニメーション付き
・画像の取得があれば成功したら表示
など、これらの条件に従いつつ実装した経験を元に、
UIKitで作られたダイアログと比べてどの点が便利に感じたのか、不便に感じたのかを発表します。
このトークセッションを通して、
SwiftUIの部分的導入の選択肢にダイアログが増えれば幸いです。
「エディタを好きになることなんて私分からなくてさ」
嘘か本当か知り得ない
そんな言葉にまた一人堕ちる
また好きにさせる
誰もが目を奪われてく
君は 完璧で究極の
エディター!!!!!
「Neovim」とは、Vimから派生したテキストエディタです。
素晴らしいエディタですが、SwiftをNeovimで書いている人は世界的にも非常に少ないです。
私はNeovimが好き過ぎて、SwiftをNeovimで書くことに挑戦しています。
そこで見えてきたXcodeとの違いを紹介しつつ、Neovimの魅力を思う存分に語ります。
【話すこと】
・Neovimの概要と魅力
・Xcodeとの比較
・私のNeovim環境紹介とライブコーディング(ここがメイン)
Neovimは私にとってのアイドルです。
この気持ちは絶対嘘じゃない!
概要
iOS と Android のクロスプラットフォーム開発の手段として、これまでに「Flutter」や「KMM」が選ばれてきました。
これに加え、「Compose for iOS」というものがJetBrainsから出てきたことはご存知でしょうか?
iOSアプリのUIをComposeで実現できるとなると、今後のiOS・Androidの垣根はどうなっていくのでしょうか?
そこで、今後の技術選定の選択肢に入りうるのか、という議題を元に
「Compose for iOS がどこまで表現できるのか」 に焦点を当てて発表します。
逆に言えば、「iOSでしか表現できないものはあるのか」というiOSエンジニアとしての危機意識でもあります。
トークセッションを通して、1人でも多くの方に選択肢の1つとして残り、
より知見が溜まっていく流れになると幸いです。