開発を進めているといつも決まったボイラープレートを書いていることがありませんか?
そこでXcode File Templateの出番です。
このLTではXcode File Templateを利用してコードを自動生成し開発効率をアップさせる方法について話します。
このLTがみなさんの開発効率向上につながれば幸いです。
WWDC21で発表されたObject Capture、皆さん触りましたか?
当時私はObject Captureのために家庭内稟議(YAuth)を通してM1チップ搭載MacBook Airを買いました!
本LTでは発表から1年が経つApple純正フォトグラメトリ機能であるObject Captureを今改めて振り返ります。
Object Captureの実例として、実際に出力した様々なUSDZファイルをご用意しました。
LT中にお手元のスマートフォンを使ってARでお試しいただきます!
Appleプラットフォームのアップデートは、一部を除き、最新OSのみに提供されます。
せっかく待望の新機能が登場しても、サポートOSポリシーによっては、使えるのは数年後...
ならば、自分で作って、来たる日に備えましょう。
実現する上での難易度は高いものかもしれませんが、多くは既存の仕組みを組み合わせることで、ソフトウェアとして解決できるはずです。
自分でバックポート実装を作ってみれば、新API、その周辺の仕組みについて熟知することができます。
このトークでは、2021年に登場したSwiftUI.AsyncImageを、すべてのSwiftUI環境にバックポートした経験を題材に、知見を話します。
似たようなレイアウトのViewがいくつかあった場合に、どのように実装しますか?
enumでtypeを定義してtypeごとにレイアウトを分岐したり、ベースクラスを作ってサブクラス側でレイアウトに必要な処理を行なったりなど、様々な実装方法があるかと思います。
本トークでは、実際にサービスで運用されているデザインを題材に、型パラメータのインジェクトを利用したViewのレイアウト方法についてお話します。
他のレイアウト方法とは、どういった違いがあるかなどもお話できればと思います。
近年、SRE(Site Reliability Engineering)の手法をアプリケーションにまで拡大しようといった動きが盛んです。
しかし、実際にモバイルアプリの可観測性≒オブザーバビリティを向上させるためには、ネイティブエンジニアの専門性が求められる場面が多く、あまり実際に効果のあった事例が共有されていないように感じます。
このトークでは
といった実際にチームで効果のあったプラクティスを紹介したいと思います。
iPhoneが登場して以降、QRコードを読むという行為はありふれた行為となりました。
iOSにおいては
しかし、QRコードを読み込むシーンというのはアプリによって様々です。
例えば
本セッションではシーンに応じてQRコードを気持ちよく読み取るためにした工夫をお話します。
頻繁に使う機能だからこそ体験の良いQRコード読み込みを実現していきましょう!
SwiftUIでViewを構築するのは難しいです。
何も考えずに書くとクソデカViewになります。
複数のViewに分割する場合も、プロパティやメソッドに切り出すのがいいか、構造体を定義するのがいいか迷います。
Viewの命名も迷います。
Atomic Designに沿うのもいいですが、iOSと馴染めない気がします。
UIKitに近い命名はわかりやすいですが、SwiftUIではスマートでないと感じます。
「いきなりぐちってごめんなさい。ウーニャほんとはSwiftUIとなかよくしたいです…!」
このトークは、ウーニャ(私)とみんながSwiftUIのViewの分割と命名について一緒に考えます。
まずはウーニャがViewの分割や命名の考え方を話すので、それについてコメントを頂き、議論してよりいいViewの構築を考えます。
かなりふあんですが、だいじょうぶます。がんばるます。
様々な developer 向けのロードマップを公開している roadmap.sh
ここにはなぜか iOS developer 向けのロードマップが存在しません。これとは別に 2018年に reddit に投稿されたロードマップが存在し、これがよくできているのですが、4年も前なので、 Objective-C, UIKit, DispatchQueue に関しては、 Swift, SwiftUI, Concurrency と置き換わるものが有力になってきていて、こういった変遷を反映したロードマップを提案したいです。
本トークでは、以下の観点からお話ししようと思っています。
Appleが提供している中で最もバックグラウンドタスクが重要なプラットフォーム、それがwatchOSです。
操作は両腕を上げる必要があるので短時間で済ませたいですし、ワークアウトのような長時間のタスクはそもそも待っていられません。
そんなwatchOSのバックグラウンドタスクは2016年に開発者へ解禁されて早6年、日々進歩してきました。
watchOS 9でも新しい機能が追加されるようで、更なる進化が期待できます。
本セッションでは以下のテーマについてお話しすることで、今のwatchOSアプリでどこまで出来るのかを理解する手助けになればと思います。
Xcode Project の Build Settings に潜む知っておきたいけどよく知らないそんなプロパティや Valueについてコールしまくります!
Kernel!Module!Bundle Loder!Build!Assets!Strip!Swift!Symbol!グイグイヨシコイ!🍾
SwiftUIは細かく指定しない限り簡潔にレイアウトを記述できることも多い一方で、
Auto Layoutでは簡単にできていたことが意外と難しかったり、そもそも実現が困難なケースもあります。
このトークでは、VStackやHStackで単にleadingやtopなどを指定するだけでは
実現が難しいレイアウトを攻略するために有効なAlignment Guideについて、次のステップで学ぶことができます。
想定する対象者
ディープリンクは、ブラウザや他のアプリからターゲットとなるアプリへのシームレスな遷移のために重要な技術ですが、まとまった情報が意外なほどありません。
iOS / Androidのアプリをディープリンクに対応させるときに悩んだことと、それにどう対処したかについてお話しします。
アプリのCIサービスとしてBitriseはそれなりに定着してきてますが、アップル自身もXcode Cloudをベータリリースしており、そして今年正式リリースされると予想されます本日のWWDCで正式リリースしました。
ちょうどBitriseが料金体系を改訂して従量課金しかなくなったからトライ&エラーのコストが高くなるからメリットが非常に薄くなるし、何よりアップル本家が作っているという安心感(?)。
というわけで、これまでBitriseで回してたプロジェクトを、試しにXcode Cloudに移行してみたので、その過程をみなさんと共有したいです!
みなさんご存知の通り、Swiftはオープンソースになってから、すでに汎用目的のプログラミング言語としてある程度の発展を遂げてきました。特にサーバサイドでの利用は意外と探せばメジャーなプロダクトでも採用例があったりします。
ところがServer Side Swiftを始めたい時、フレームワークを選ぶ必要がありますが、アップル謹製のいわゆるファーストパーティーライブラリーは存在しないため、複数あるサードパーティーライブラリーから選定する必要があります。
さて、一体どのフレームワークが一番私に適しているかな?一番熱いVapor?一番大きな会社がバックしてるsmoke-framework?それとも一番老舗であるPerfect?
このLTはこれらのフレームワークを一通り試してみた感想を伝えたいと思います!
Storyboard辛い!Auto Layout難しい!でもSwiftUIのおかげでこれらとおさらばだ!!
そんな甘い思い、私にもありました…まさに若さゆえの過ち…
そう、SwiftUIがリリースして3年経った今でも、まだ我々はレイアウトのナイトメアから解放されていません…
この発表は、そのSwiftUIにまつわってよくある落とし穴やぶつかりやすい壁を紹介し、それらの理由と正しい回避策をお伝えしたいと思います!
Storyboard辛い!Auto Layout難しい!でもSwiftUIのおかげでこれらとおさらばだ!!
そんな甘い思い、私にもありました…まさに若さゆえの過ち…
そう、SwiftUIがリリースして3年経った今でも、まだ我々はレイアウトのナイトメアから解放されていません…
このLTは、そのSwiftUIのあるあるな罠を紹介し、そしてそれらの回避策をお伝えしたいと思います!
チーム開発を経験されてるあなた、「静的チェック」は聞いたことあるでしょうか?そう、CIを回す時に、Lintを適用するとか、スペル確認を行うとか、そう言った機械的なチェックを行うことです。
そしてある程度の経験がある方でしたら、DangerというRuby制のツールを聞いたことある、あるいは今でも使っている方もいらっしゃるではないでしょうか。
実はそのDanger、本来はRubyでスクリプトを書かないといけないですが、Swiftでスクリプトを書くDanger-Swiftも存在しているんですよ!
この発表はSwift信者として、そのDanger-Swiftの良さを全力で伝えたいと思います!
みなさん、証明書管理やデプロイなど何使ってます?やはりFastlane?ですよねーFastlane便利ですもんね
でもFastlaneはRubyで書かないといけないからそこ大変ですよね、Rubyは型が保証されないから使うときドキドキするし、初心者がそもそもRubyの導入で躓きやすいので。
というわけでSwiftlaneを使ってみてはいかが?我々iOSエンジニアが使い慣れてるSwiftで書けるからとっても書きやすいですよ!はいこの発表はSwiftlaneの布教です!
Carthageでビルドしたframeworkを共有キャッシュとしてS3などで管理できるツールのRomeがついにXCFrameworkにも対応しました。
Swift Package Manager対応のライブラリも増えてきていますが、まだまだCarthageを利用されている方もいると思います。
今回はRomeに関する以下の内容について、具体的な設定ファイル、スクリプトコードを用いて説明します。
・共有キャッシュの導入することでビルド時間をどれだけ短縮できるか
・XCFrameworkを共有キャッシュとして、S3およびローカルドライブで管理する方法
・(現状のリリース版に残っている)Romeのバグに遭遇した際の対応方法
iOSアプリ開発の周辺技術としてRubyは非常に人気な言語です。パッケージ管理のCocoaPods、静的検査のDanger、そしてCI/CDスクリプトのfastlaneなどなど、Rubyは幅広く使われています。
しかし初心者にとってRubyも一つの鬼門なのです。たとえば誰でもPermission Denied問題に一度は会ったことあるでしょう。右も左も分からない初心者がネットで検索するとすぐ「sudoすれば上手くいくよ」と悪魔の囁きを目にします。怖いですね。
というわけでRubyを開発過程から排除できないか?誰でも簡単にできるより安全な環境構築の仕方ないか?この発表はその脱Rubyの仕方をお伝えします。