▼ 概要
私たちは「あたらしい旅行を、デザインする。」をミッションに旅行アプリ「NEWT (ニュート)」を日々開発しています。
NEWTは初期の開発初期段階からSwiftUIの導入を行なっており、開発開始から3年が経ちました。
みなさん、SwiftUIでの記法のルールは定めていますか?
宣言的UIの登場で開発のしやすさが増すと同時に、複数人で開発を行うと自由度が高いがゆえに記法揺れが起きると思います。
その一例としてStack.space/padding/Spacerをどのように利用しているか、ルール化しているかをお伝えします。
▼ 内容
【ご案内】
iOSアプリ開発において、SwiftUIを利用することで直感的で効率的なUI構築が可能になります。
しかし、時にはSwiftUIに固執することで、開発が行き詰まることもあります。そんな時はUIKitの力を借りることが有効かもしれません。
本LTでは、上記の案内をもとに、SwiftUIとUIKitを使い分ける8つのパターンを解説します。
ここにトマトがあります。
このトマトを、幅を指定して切るメソッドについて考えてみましょう。
extension Tomato {
public func slice(width: Double)
}
トマトを3cm幅でカットする際は、以下のように書けば良さそうです。
tomato.slice(width: 3)
さてここで、メソッドのシグネチャからwidthを省略したら、メソッドを使う側にどう伝わるでしょうか?
tomato.slice(3)
「トマトを3cm幅でカットする」ではなく、「トマトを3つにカットする」と伝わってしまうかもしれません。
Swift の API Design Guidelinesは、明確で一貫性のあるコードを書くための指針を教えてくれます。しかし、その抽象的な概念を理解し、日々のコーディングに適用するのは難しい場合があります。
本LTでは、身近な「野菜」を使って、これらのガイドラインの理解を深めていきます。野菜を使うことで抽象的な概念を具体的なイメージとして捉え、より実践的な知識として吸収し、より良いコードが書けるようになることを目指します!
Swift Concurrencyは、非同期処理やマルチスレッド処理を便利にするSwiftの新機能です。iOSアプリ開発において、ゼロからこの機能を利用する場合は比較的スムーズに導入できますが、既存のアプリに導入する際にはさまざまな課題が発生します。
我々のチームでは、すでにリリースされているアプリにSwift Concurrencyを全面的に導入しました。まず、API通信のような非同期で結果が返る処理をasync/awaitに変換することから始めました。その過程で、ActorやMainActorの利用も行いました。また、非同期処理にまつわる問題を厳密にチェックするため、SWIFT_STRICT_CONCURRENCYオプションを有効にし、その結果に対する対応策も講じました。
その過程で遭遇した具体的な問題とそれに対する対策の実例を紹介します。
Swift コードの品質を向上させるためには、コードベースが大きくなるほど自動化が不可欠です。CodeQL は GitHub が開発した静的解析ツールで、コードベース全体を検査して脆弱性やエラーを検出することができます。たとえば、データを安全でない方法で利用する、関数に危険な引数を渡す、機密情報を漏洩するなどの、コードにおける潜在的なセキュリティ問題を検出することが可能です。現在は、GoやPython、C++といった様々な言語がサポートされています。
この CodeQL、なんと Swift もベータサポートされています!本LTでは、CodeQL を用いて Swift コードの脆弱性とエラーを検出する方法を紹介します。
現在最新の Swift 5.10 にも対応しています。しかし、いくつかドキュメントにない対応が必要となります。それらを紹介するにあたって、自身のOSSアプリを公開する際「秘匿情報書いたりしてないかな.....」とドキドキしながら公開ボタンを押してどうなったか!!という小話と共に紹介します。
コストがかかって大変ですが、おざなりにはできないセキュリティチェック。まずは数行の設定を書くだけで利用できる便利なCodeQLをみなさんも始めてみませんか?みんなでフィードバックしていくことで安全な Swift コードを増やしていきましょう。
みなさん、UIWindowを最前面に表示したい時どのように表示を行なっていますか?
多くの方が makeKeyAndVisible()
を使っているのではないでしょうか。Developer Guideにも 「自身の windowLevel
以下のUIWindowの中で最前面に表示できる便利メソッド」であることが明記されています。
しかし、同時にDeveloper Guideには「表示だけであれば isHidden
プロパティを false
にすればよい」とも書いてあります。
makeKeyAndVisible()
によってUIWindowが keyWindow
となるため keyWindow
なUIWindowが最前面のUIWindowであると思われがちですが実際にはそうではありません。
この理解が曖昧だと「キー入力は受け付けたいが最前面に表示したくない」といったケースで困ったり、「 makeKeyAndVisible()
を呼んでいるのに別のUIWindowが最前面になってしまった」というケースで困ることがあります。
このLTではUIWindowの表示順決定方法について紹介しつつ、 makeKeyAndVisible()
で何が起こっているのか紹介します。
UndoManagerは、アプリにUndo・Redo機能を提供してくれる強力なクラスです。
特にnote アプリのようなエディタアプリにとって、Undo機能は必須の機能の一つといえます。
しかし、意外とUndoManagerを使いこなしているアプリは少ないのが現状です。
本トークでは、UndoManagerの基礎から、実際のアプリへの導入方法、そしてその際のはまりポイントまで、実体験に基づいて解説します。
[内容]
一緒にUndoManagerをマスターし、アプリのユーザー体験を次のレベルへ引き上げましょう!
Swiftでもシェルスクリプトのようなことができるのは既に知られていることかと思います。
しかし、標準の開発環境であるXcodeではSwiftスクリプトのサポートがほとんどされておらず、標準APIのコード補完すらできないのが現状です。
一方で、VSCode (Visual Studio Code)にSwiftプラグインを導入することでコード補完はもちろん、変数の型の確認が容易になるなどの恩恵を受けられます。
更に、GitHub Copilotも標準サポートされているのである程度の単純作業であればすぐにスクリプト化することができます。
本セッションではSwiftでスクリプトを書く際の注意点を紹介しつつ、実際に使っているシェルスクリプトをVSCode+GitHub CopilotでSwiftに書き直す様子をライブコーディングでお届けします。
シングルトンはGoFのデザインパターンのひとつ。
インスタンスがひとつしか存在しないことを保証したもの。
しかし、とある日、確実に正しいコードのシングルトンなのに、その状態が共有されていないことに気づいたのです。
おかしい、そんなバカな、そう思いながら、恐る恐るシングルトンのインスタンスのメモリアドレスを確認しました。
違うんですよ、アドレスが…
このトークではコードは間違いなく正しいにも関わらず、シングルトンのインスタンスが複数作られてしまう怪奇現象について、iOSのビルド設定の観点から説明します。
あなたのシングルトンは本当にひとつですか...?
iPhone, iPad, Apple Watch, AirTag, AirPods, Mac。
iOSDCに参加されている方なら、これらをたくさんお持ちだと思いますが、自分に合ったちょうどいいスタンドなどのアクセサリを見つけるのはなかなか難しいですよね。実際に使ってみないと、そのアクセサリが本当に良いかどうかわからないので、色々試してみたくなることはありませんか?
購入する以外にも、CADと3Dプリンタを使って自分で作るという選択肢が増えれば、様々なアクセサリを試すことができたり、世界に一つだけのオリジナルなものを作れたりと、日々の生活がさらに楽しくなります。
そこで、Apple公式の「Appleデバイス用アクセサリのデザインガイドライン」を元に、作り方の手順や完成データの探し方、私が実際に作ってみたものを紹介しながら、発表したいと思います!
swiftUIで pull to refresh を実現するにはApple純正のrefreshableを使うのが一般的です。
ただし、私が開発しているアプリでは、この純正機能を使用することで、レイアウト崩れや予期しない動作が発生していました。
具体的には、リフレッシュした後にスクロールview の画面が下にずれる問題が発生していました(詳細はこちら: https://stackoverflow.com/questions/76943913/swiftui-scrollview-refreshable-doesnt-work-appropriately)
他にも対応している、アプリがiOS15以下も対応していたため、そもそもScrollViewのリフレッシュが使えない。
私のUIKit経験値が低いために、UIKitでのリフレッシュバグが起きた際に対応しきれなかった。
そのためswiftUIのみでcustomRefreshableを作ろうと思いました。
私は23新卒iOSエンジニアとしてChatworkに入社し、この1年で多くの対外活動に取り組んできました。
具体的には、
対外活動に取り組んでみると「日々の自分の活動をふりかえることができる」「自分の知見を共有することでフィードバックや思わぬ意見から学びが得られる」「さまざまな経歴を持った社外の方々と交流ができる」など、良いことがたくさんありました。
そして、通常業務と並行して対外活動に取り組むことで、自然と「通常業務での学びをイベントでアウトプット」 → 「アウトプットへの反応からの学びを通常業務に活かす」 → 「通常業務での学びをイベントでアウトプット」 …といったようなサイクルを回すことができたり、対外活動の取り組みが評価され、社内のアワードを受賞することができました。
このLTでは、僕が新卒1年に取り組んできた対外活動の経験を交えながら、そこから得られた学びや通常業務への学びの活用を共有し、対外活動に取り組む良さを紹介したいと思います。
iOS開発者にとって避けて通れない「アプリ審査」。
リリースには「新しい審査基準で審査が通るのか」「どのようなことが確認されるのか」といった疑問を抱えることが多いのではないでしょうか?
そこで、Appleでは審査プロセスをスムーズに進めるために「1 on 1 App Reviewコンサルテーション」を実施しています。
このセッションでは、私自身の経験を基に「1 on 1 App Reviewコンサルテーション」の詳細とその活用方法を紹介します。
具体的な手順や注意点を共有し、iOS開発者がアプリ審査の疑問を解消する手助けとなることを目指します。
アプリ開発において重要な通信系処理ですが、OpenAPI Generatorを利用することで、OpenAPIのAPI定義書からクライアントコードを自動生成することができます。
このトークでは、OpenAPI GeneratorをKotlin Multiplatform環境で活用し、より効率的にアプリを実装する具体的な方法と工夫を紹介します。
以下のポイントに焦点を当ててお話します。
Kotlin MultiplatformでAndroidとiOSの開発を効率化したうえで、更に楽に実装できるようにしていきましょう!
Xcodeのプレビューは動作や表示を簡単に確認することができるため、UIKitやSwiftUIを利用した開発において非常に便利です。
一方、通常の実行時に利用できるCapture View Hierarchyなどのデバッグ機能や、サードパーティのデバッグ用ライブラリを使うことができないため、
プレビュー上では各Viewの位置やサイズの確認が難しいという課題があります。
本トークでは、プレビュー環境特有の制約を回避しながら、Swift Macrosを使うアプローチで、プレビュー上で動作するViewのデバッグ機能を実装する方法について説明します。
このトークで話す内容:
好きなSwift発表ドラゴンが
好きなSwiftの言語機能を発表します
Swiftは2014年にWWDCにて発表された、Appleの開発するオープンソースのプログラミング言語です。
「モダン、安全、高速、インタラクティブ」を特徴とし、iOSやmacOSなどのAppleプラットフォームだけでなく、LinuxやWindowsでも利用でき、アプリケーション開発のみならずCLIやサーバーサイド向けのソフトウェア開発も可能です。現在はSwift 5までバージョンを重ねており、来るSwift 6にて大幅に機能が追加される見込みなど絶賛成長中の言語です。
本LTでは定番の言語機能から正式名称がわからない言語機能まで発表していきます。
Swift初心者の方からベテランの方までSwiftの素敵な言語機能を確認してSwift力を高めていきましょう!
Swiftでのアプリ開発において、CI環境の構築や移行は大変です。しかし、Makefileを活用することで、その作業を簡単に行うことができました。
Swiftでのアプリ開発において、継続的インテグレーション(CI)環境の構築や移行は、多くの開発者にとって悩ましい課題です。特に、目まぐるしく変化するCIツールやプラットフォームに対応するのは容易ではありません。そんな中、Makefileを活用することで、この問題を驚くほど簡単に解決できました。
たとえば、以下のような内容をMakefileに記述しました。
makefile
test:
bash run_tests.sh
coverage:
bash run_coverage.sh
このように、テストやコードカバレッジの実行をMakefileで一元管理することで、CI環境の移行が非常にスムーズになりました。新しいCIツールに移行する際も、.ymlファイルのようなワークフローが記載されてるファイルを変更するだけで済むため、時間と手間を大幅に削減することができました。
この方法は、Swiftでのアプリ開発だけでなく、他の言語やプロジェクトにも応用できるため、CI環境に悩む全ての開発者にとって有益です。ぜひ、Makefileを活用して、より効率的な開発環境を構築してみてください。
私はiOSアプリの多言語化対応において、LinterをRubyで自作して書きました。
本セッションでは、そのLinterを汎用化したGitHub Actionsに進化させ、Marketplaceに公開して使えるようにするまでをお話します。
といってもまだ公開しておらず、もしこのセッションが採択されたら公開に向けて動きます。そうです、登壇駆動開発です。その時間経過も含めてLTらしく話します。
真面目な話をすると、意外と自作で色々スクリプトを作っているiOSプロジェクトは多いんじゃないかと考えており、それらOSSのタネが開花するきっかけになるとよいなと考えています。
チームエンジニアリングでグローバルなメンバーと連携していると、どうしても言語の壁が辛いことが多々あります。そういった壁を今、勢いのある生成AIの力を使って乗り越えられるのではないか。
さまざまな手法を試しました。その中で特に効果的だったのが生成AIのPull Request要約ツールでした。
今回は数あるPull Request要約ツールの中の「PR Agent」を使って、グローバルメンバーとのGitHub上のコミュニケーションを円滑にした話をします。
セキュリティとか大丈夫なの?
Swiftに対応してる?
使うとどうなるのか?
でも生成AIって嘘つくんでしょ?
といったiOSエンジニアにとって気になるポイントを解説します。
このトークを通じて、生成AIがコーディング以外の場面でどのように活用できるかを知っていただき、チームのコミュニケーションがより円滑になる一助となれば幸いです。
結婚したことでパートナーが持っていた電子ピアノが我が家にやってきました!
電子ピアノといえばガジェット!ピアノ未経験とはいえ、エンジニアとしてはこれは触ってみるしかない!
ということで、ピアノ経験者監修の電子ピアノと連携するiPadアプリを実装しました
この電子ピアノはMIDIという規格を通して他のデバイスへ叩いた鍵盤の情報などを連携することができます
今回はこのMIDIをSwiftから利用し、その情報を表示するアプリの実装の概要について紹介します!
具体的には…
発表では実装したアプリが実際にピアノと接続しながら動く様子をお見せします!
この発表を通して、電子楽器とアプリ連携の世界に一歩足を踏み出してみましょう!
またこのデモの中でピアノ完全未経験の発表者がどれほどピアノが上手く弾けるようになっているかにも注目です