私達はTVerという動画配信サービスを開発・運営しており、昨年4月に一部システムを内製化しました。
しかしモバイルアプリケーションについてはほぼ全ての開発をパートナーのお世話になっており、自社のiOSエンジニアはまだ1人もいません。
内製であれ外部への委託であれ、サービスを提供する以上は私達がサービスへの責任を全て負う必要があります。
本トークではiOSアプリケーション開発への専門知識が無いSREの私がNew Relicを導入し、動画配信サービスならではのサービス品質可視化と改善を行っている話をします。
・ オブザーバビリティの導入を検討しているiOSエンジニアおよびSRE
・ TVerにおけるiOSアプリ開発の課題
・ オブザーバビリティの実装と効果
・ 動画プレイヤーの観測
・ TVerにおける具体的なiOSアプリの実装
タクシーアプリ『GO』では、現在大規模な英語への対応作業を進めています。
日々追加される案件開発や差し込みでの対応と並行しながら、既に存在する大量の画面をPdM・デザイナーと適切に連携を取りながら複数言語に対応させていく作業はかなり難易度の高い作業です。
現在タクシーアプリ『GO』では外部文言ツールとGitHub Actionを組み合わせた文言管理を行っていますが、現在の運用に方法を採用するまでには様々な課題が有りました。
そこで本セッションでは、多言語対応に本格着手した際に発生した課題や問題点に対してどのように対応してきたか、及び現在の運用にしてどのような問題が解決されたのかなど、多言語対応にどのように開発チームが対応してきたのかをお話いたします。
アプリケーション等のプログラムを実行する際最初に呼び出される処理や関数のことをエントリーポイントと呼びます。
Objective-C時代はmain.m
というファイルが必要でしたが、Swiftになって @UIApplicationMain
が登場しエントリーポイントが隠蔽されるようになりました。
更に、SwiftUIや @main
の登場により @UIApplicationMain
を deprecated にしようという動きもあります。
本トークではそんなエントリーポイントの変遷を紐解いていくことで、エントリーポイントについての理解を深めていければと思います。
「エントリーポイントについて理解するとAppDelegate
をモック化できる」
「AppDelegate
をモック化できるとどうなる?」
「知らんのか」
「副作用の少ないテストが書ける」
「お前も Swift Playgrounds を使った開発者にならないか?」(1年ぶり2回目)
昨年の「iPadOSDC Japan 2022」では、Swift Playgrounds を知ってもらうために、 Xcode との機能差分やメリット・デメリットを紹介しました。
本セッションでは、その中でも触れた内容の1つをさらに掘り下げます。
Swift Playgrounds では、プロジェクトファイルを持たずに、Package.swift を起点に開発することになります。
これをうまく活用することで、Xcode と併用して Feature 単位でのマルチモジュール開発が可能になります。
ただし、これは完全に機能するわけではなく、まだ問題点もあるので、実際のプロジェクトを通して経験したことも含めて、お話ししていきます。
最高のユーザ体験は、単に素晴らしいデザインや機能性だけでなく、異なるデバイス間でも一貫性と流動性を持つことが求められます。特にiPhone AppをiPadやMac Catalystに単純に移植するだけでは、ユーザーに違和感を与えることがあります。
本トークでは異なるAppleデバイス間での一貫した体験を提供するためのデザイン戦略と技術的なアプローチを解説します。
ソースコードはSwiftUIを前提とし、UIKitは本トークでは扱わないものとします。
私たちのチームでは品質維持のためにテスト戦略を見直し、その結果、自動テストを導入しました。
半年が経過した現在、自動テストのシナリオ数は35を超えていますが、その過程で多くの課題がありました。
例
上記で挙げた課題に対して行ったことの紹介はもちろん、以下のことについても話します。
技術選定にFlutter、integration_testを使用したプロジェクトのトークになりますが、トーク内容はモバイルアプリ全般に適用できる内容です。
SwiftUIは強力なUI構築手段ですが、アプリ開発にだけ利用するなんて勿体無いと思いませんか?
本トークではSwiftUIで名刺をデザインする方法について、実践的な手順を紹介します。
SwiftUI製の名刺を作ってiOSエンジニアとしてのスキルアピールや個人ブランディングに役立てましょう!!
深層学習モデルの識別処理は学習に比べて軽くモバイル上で実行できるオンデバイス識別の技術があり、端末上で完結するという利点を備えています。
iOSアプリでは深層学習モデルはmlpackageに変換して利用しますが、慣れていないと躓く点があると考えており、以下の内容を軸にトークを進めようと考えています。
対象者:深層学習をデバイス上で識別してみたい人・デバイス上で動作させるためのTipsに興味がある人
WWDC23で発表されたcoremltools 7ではモデル圧縮のAPIに変更が入っており、そちらについてもトーク内で触れようと考えています。
アプリがネットワークなど外部サービスを通じてデータをやり取りする場合、JSONが使われることは多いと思います。
JSONのデータはJSONDecoderを使い、Combineでdecodeと組み合わせてなどの方法でCodableデータモデルに変換し処理することになると思います。
しかし世の中のWeb APIにはJSONではなくXMLでのレスポンスを返すものもあります。
また、データソースの変更で、ネットワーク経由ではなくローカルのcsvやyaml、はたまた独自のデータを変換することになったり…
そうなった場合、decodeは使えないのでしょうか?
否!JSONのデータじゃなければ、自分でDecoderを作ってCodableなデータモデルに変換すればいいのです。
このトークは、JSONではないデータに出くわしても困らない、独自のDecoderを作成するための説明を行うトークとなります。
iOS 16 から Swift Charts という SwiftUIのフレームワークが使えるようになりました。
Swift Charts を使うことで、簡単にグラフを作成することが出来、特に時系列データの可視化に便利です。
一方で、コード上で設定できる項目がかなり多い上、設定項目とグラフの変化が直感的で無い事もあるため、グラフの表示範囲や見た目をカスタマイズするのが難しくなっています。
そこで今回は Swift Charts で「良い感じ」にグラフを表示する方法を紹介します。
具体的には、一般的な2変数を対象にグラフ自体を見やすく表示する方法を紹介しつつ、筋力トレーニングの記録のような3変数を持つデータの表示方法を詳細に説明します。
みなさんはSwiftUIで非同期処理データの状態管理をどう行なっていますか?
enum DataState { case loading; case success(Value); ... }
LoadingContent(fetch: fetch) { Content($0) }
などがあると思いますが
等の要件で、微妙に異なるバリエーションがいくつか存在する上、それらの方法にはメリットとデメリットがあります。
パフォーマンス低下を引き起こしていることも...。
このトークは、このような状態管理方法を複数個、実装ケースと共に紹介・考察し
それぞれの方法がどのような実装ケースに適しているかを分析・分類していく内容となっています。
Apple Payは2016年に日本で使用できるようになり、多くのユーザに使用されています。
フードデリバリーアプリ「出前館」でも2016年よりApple Payを導入しています。
Apple Payを運用していくためには、いくつかの証明書などを管理する必要がありますが
これらの証明書にはAppleのドキュメントを読むだけでは理解が難しい制約が多く、運用時に注意が必要です。
また、2016, 17年時点のApple Pay導入の記事は見かけますが、継続的にApple Payを運用するための記事は少なく、試行錯誤しながらApple Payの運用方針を確立しました。
本発表では出前館でApple Payを安定的に運用するための実践的な苦労話を中心に、Apple Payに関連するAPIの話や、iOS/WebでApple Payを実行するためのTipsをお話しする予定です。
プロジェクトの肥大化により差分ビルドの時間が伸びてしまいます。
私たちのチームはマイクロフレームワーク戦略でしたが、UI関連のフレームワークが肥大化してしまいました。
解決策として、フレームワーク分割が有効です。
差分ビルド対象のフレームワークが減り、ビルド時間が短縮します。
加えて、機能ごとにフレームワークを分けることで特定機能のミニアプリの配布が可能となります。
しかし、コンパイルが成功しても安心できません。
ランタイムクラッシュや参照の不備でリソースが見つけられない問題が生じます
本トークでは、安全なフレームワーク分割の手法を説明します。以下の項目を中心に話す予定です。
アプリ開発に使用するちょっとしたスクリプトは、Shell Scriptでささっと書いてしまうことがあるかと思います。
Shell Scriptは少ない記述で多くのことができる反面、以下のデメリットがあると思います。
本トークでは、実際にチームで運用がされているSwift でのスクリプト開発について詳しく説明したいと思います。
以下にスポットを当てる予定です。
Swift開発者として、より高度なアプリケーションを構築するために新しいプログラミング言語を探求することがあるかもしれません。Mojoの言語は、AIアプリケーションを開発するために使用できる強力な言語であり、Swiftに似た構文を持ってところはいっぱいあります。この講演では、Mojoの基礎と、AIアプリケーションを構築するためにどのように使用できるかを探求します。また、MojoとSwiftの類似点と相違点、およびSwiftのスキルを活用してMojoをより迅速に学習する方法についても説明します。さらに、機械学習やニューラルネットワークの基礎を含むAIコーディングの簡単な紹介を提供します。この講演の終わりまでに、Mojoプログラミング言語とAIアプリケーションの構築方法についての堅固な理解と、AIコーディングの世界へのさらなる探求の基盤を持つことができます。
ネイティブアプリを継続的に開発していると怖いのが、アップデート後のデクレですよね。
CoreData等のローカルDBのデータが消えていないか、特定の動線でクラッシュが起きないかなど、毎回確実に確認しておきたいものですが、準備や実行に手間がかかるのも事実。
こういったものは自動でテストできると安心ですね。
今回はそれをMagicPodとS3、Bitriseを使って自動でテストをする方法を紹介いたします。
CoreDataはクライアントでデータベースを利用する際に欠かせないものです。
しかし、NSManagedObjectはスレッドセーフではなく、NSManagedObjectContext内で原則操作を行う必要がある等、スレッドを意識しながら利用する必要があります。
一方、Swift Concurrencyの普及が進み、データ競合はActorによって制御することが一般的になりました。CoreDataを利用する際も、実行スレッドを考慮することなく全てasyncで安全に操作したいものです。
しかし、CoreDataを実際にそのように利用した例は多くありません。
そこで本トークでは、CoreDataをスレッドを意識することなく利用するための設計方法を解説します。本トークによって、Swift Concurrencyを活用したより安全なCoreDataの利用方法を理解できるようになるでしょう。