トーク

新機能リリース後、特定の条件でパースエラーが起きていることがユーザーからの問合せで判明した！という経験はありませんか？
リリースされたアプリのクラッシュを検知する方法としてはXcodeのクラッシュログ・Firebase Crashlyticsなどが多く使われていますが、パースエラーを検知する方法は確立されていないように感じます。
このLTでは、起きてしまったパースエラーを検知するためのログ導入方法や、簡単に分かりやすく確認するために改善していったことをご紹介します。

・パースエラーを検知する方法
・ログ送信で注意するべき点
・原因を把握しやすくするために工夫したこと

アプリ内で起こるエラー検知方法やログ実装にお悩みの方のヒントになれば幸いです。

株式会社KyashではデジタルウォレットアプリKyashを提供しています。

最近、KMM(Kotlin Multiplatform Mobile)を導入しました。
既存プロダクトにKMMを導入して得た知見を共有したいと思います。導入を検討している方の参考になれば幸いです。

・なぜ導入したか
・導入してみてわかったメリット・デメリット
・ぶっちゃけ、導入してみて良かった？

エンジニアは意外にも信心深いところがある。サーバーをお祓いしたり、デバッグ神社を建てたり、リリースするときにお祈りする。
アプリを全面リニューアルがあったので、今までのソースコードへの感謝の気持ちを込めてお焚き上げをすることにした。
お焚き上げの準備から実施するまでを紹介します。

ブログに書いた内容をTL用に作り直して発表する予定です。
https://akuraru.hatenadiary.jp/entry/2022/05/22/200917

「お前も Swift Playgrounds を使った開発者にならないか？」
「見れば解るお前の強さ。Xcode だな？」
「その闘気。練り上げられている。熟練の開発者に近い」
「やはり Swift Playgrounds を使った開発者になれ！俺と iPad で開発を続けよう」

Swift Playgrounds では、昨年末から iPad 上でアプリを開発してリリースできるようになりました。
本セッションではそんな「ならない」と感じている人たちのために、Swift Playgrounds を使った iPad での開発を紹介します。

「死ぬ…！！死んでしまうぞ　Swift Playgrounds を使った開発者になれ！！なると言え！！」

元来、アプリ開発においてマルチモジュール化をしなければアプリをリリース出来ないわけではありません。
既に大きくなったプロダクトを途中からマルチモジュール化するためには、必要な処理を切り出すリファクタリングや影響範囲の考慮したインクリメンタルな対応が発生します。
しかし半強制的にアプリから必要な処理を切り出さなければ機能自体が実現できないケースがあります。

App Extensions対応を行なった際に切り出した必要な処理を紹介し、どのような構成を取ればモジュール化構想をより円滑にできるのかを考察していきます。

SF Symbols 3.3の時点では、3,300を超えるシンボルを備えています。この多種多様なシンボルのおかげで開発者は0からアイコンを作る必要は無く、開発に専念することが出来ます。

でも、どうでしょう？

3,300を超えるシンボルがあるのに、何個のシンボルを使ったことがありますか？実際、日の目を見れていないシンボルたちが沢山あります。

「これ一体いつ使うんだ？」「こんなシンボルまであるんだ！」「これは使えそう！」

個性豊かなシンボルたちが使って欲しそうにこちらを見ています。

このLTでは、そんなシンボルたちを活用したSF Symbolsアートの数々を紹介します。少しでもSF Symbolsのことが好きになっていただければ嬉しいです。

(参考: https://twitter.com/littleossa/status/1516540893142347778)

iOSにはHealthKitが備わっており、各種健康データや運動量などを入力しておくことができます。
入力できる項目の中には栄養素の項目があり、摂取した食べ物などから栄養素を入力したりできます。
中には特殊なもの、わかりにくいものなど、ソースコード上でどうやって入力すればいいか戸惑う栄養素もあります。

そんな一癖も二癖もある栄養素の面々を、HealthKitのTIPSと共に、開発者にとって思わず「あるある」と思っちゃう独断と偏見のランキング形式でご紹介していきます。

人間にとって、健康は日々の生活においてとても重要です。
エンジニアにとって、新しい技術のキャッチアップは日々の開発を行う上でとても重要です。

いつも物事が長く続かなかった私が、健康と新しい技術のキャッチアップ、この両方のモチベーションを1年間保ち続けて得たことを紹介します。

以下のテーマをお届けします。

• 健康と技術、両方を数値化して定量的にモチベーションを維持
• HealthKitを使ったワークアウト管理のカスタマイズ
• HealthKitでSwift Concurrencyを学ぶきっかけ作り

iBeaconと連携するアプリの機能実装は簡単そうに見えて、やってみたら意外と難しい、という経験がある人は何人かいらっしゃるでしょう。
そうiBeaconを使った機能の実装は意外と難しいのです。
開発環境ではきちんと動いたので安心していたのに、実際にビーコンを動作させる環境で動かしてみると期待通り動かない、なんてのはよくある話です。
そうなる原因は電波環境の違いという見えない罠が存在することです。
その罠に気がつくのが遅くなるほど、開発に致命的な影響が出て慌てふためくことでしょう。

本LTでは後から慌てる状況にならないため、iBeaconを扱う機能を実装し始めるよりも前に知っておきたいテストのTipsをお話します。

※iBeaconと言ってますがAndroid側でのBLE実装も視野に入れた一般的な話をする予定です

【概要】
Google I/O 2022にてFirebaseの新機能が発表されましたがその中でもiOSのSDKが正式にSwift対応となりFirebase Apple SDK 9.0.0となって発表されました。
今回は特にその中でもよく使用される認証機能のAuthenticationとデータ管理機能のFirestoreについて、何が良くなったのかサクッと5分でご紹介したいと思います。
【目次】(予定)
・Firebase Apple SDKの概要
・Authenticationは以前と比べて何が良くなったのか
　・async/awaitに対応した実装例の紹介
・Firestoreは以前と比べて何が良くなったのか　
　・async/awaitに対応した実装例の紹介
　・Codableに対応した実装例の紹介(ベータ版でなくなった話)
・所感

東急株式会社・東急電鉄株式会社では東急東横線や田園都市線などの鉄道をより便利にお使いいただくために「東急線アプリ」を提供しています。

このLTでは

• アプリと連携する駅、線路、車両などのハードウェアについて
• アプリと連携する線路信号システム、運行情報システムの技術
• アプリ上でリアルタイムデータ更新するためのアーキテクチャ

など
普段知る機会の少ない鉄道のテクノロジーとiOSアプリでの活用についてご紹介します。

RealityKitはWWDC2019で発表されたARのレンダリングフレームワークです。年々機能も改善されています。
今回は、そのRealityKitでMetalを書いてカスタムシェーダーをレンダリングしてみようと思います。
カスタムシェーダーを書けるようになればRealityKitでできる表現の幅が広くなると思います。

サンプルとして顔認識を行い、顔の表面にカスタムシェーダーをかけるアプリをつくりました。
このアプリのソースコードを使いながらRealityKitとMetalの連携の仕方、カスタムシェーダーの書き方を紹介できればと思います。

内容:
RealityKitとMetalを連携する大まかな流れ
Metal側のコード
Swift側のコード
Appleのカスタムシェーダーのドキュメント紹介

このLTを聞いて少しでもRealityKitに興味を持っていただければ嬉しいです。

「Feel free to cut a new tag/release」
（自由にリリースしていいよ）

こちらはある著名ライブラリへPull requestを送ったときに、突然言われた言葉です。
私はこの言葉とともにコラボレーター（共同開発者）へ招待され、自由にリリースできる権限を与えられました。

「なんで、私がコラボレーターに！？」

このライブラリは海外の著名な企業が提供しています。
海外で何の実績もない私がいきなりコラボレーターに招待され、何が起きたか理解できませんでした。

しかし慌てません。
最初のコメントへ冷静に :+1: の絵文字を付け、リリースを試みることに…
そこで経験したこととは！？

本トークでは、私が著名ライブラリのコラボレーターとしてどんな感じで動き、何をしたかざっくり紹介します。
私と同じく、突然コラボレーターになって慌てている人にオススメです。

昔はiOSのJailBreakはよく行われていましたが、最近はiOSのアップデートによりJailBreakは少なくなったような印象です。
とはいえ何もしないのではなく、やれることはやっておいたほうがいいと思います。

本LTでは、JailBreakはどのような手段があるのか、アプリはどのような対策ができるのか、自分なりに調べた結果を共有したいと思います。

株式会社エクサウィザーズが提供する介護記録アプリ「CareWiz ハナスト」ではAPIサーバーとの通信にGraphQLとRESTを使用しています。

便利なGraphQLですが、Firebase Performance Monitoringで通信時間を計測しようとすると問題が発生します。
Firebaseコンソール上ではGraphQLクライアントからのリクエストが全て同一のものとして扱われてしまうのです。
なぜならGraphQLのリクエストは基本的に同一エンドポイントへのPOSTリクエストとなるからです。

本 LTではそのような問題にどのように対処したのか、具体的な実装を交え解説します。