トーク

長い年月と情熱をかけてつくり込んだアプリを満を持してAppStoreにリリースしたものの全くDLされないという経験はありませんか？

多種多様なアプリが膨大に溢れている昨今、個人開発者のアプリが多くのユーザーのiPhoneにDLされるのは非常に難しいと感じています。
しかしながらあまり知られていないだけで「個人でできること」というのは意外とたくさんあります。

この原稿では私が個人開発したアプリの累計が200万DLされるまでに行った取り組みを中心にASO(App Store Optimization)に効果的と思われる手法やアイデアを共有いたします。あなたがつくった素晴らしいアプリをもっと多くの人に使ってもらいましょう！

・効果的なASO(App Store Optimization)
・改善し続ける仕組み
・AppStoreリリース時に意識すること

iOSで着信時氏名表示を実現するためには"Call Directory Extension"を利用する必要がありますが、そもそも別プロセスということもあって、通常のアプリよりデバッグが簡単ではありません。私自身、これまでCall Directory Extensionのデバッグには大変苦労してきましたが、長年の試行錯誤の結果、最近ではデバッグの効率がかなり改善してきました。

本稿では、そんなCall Directory Extensionを利用するアプリを開発する上で知っておくとデバッグ効率が上がるようなデバッグテクニックをご紹介します。

コンテンツ(予定):

1. なぜCall Directory Extensionのデバッグは難しいのか？
2. テクニックその1: デバッガのアタッチしてデバッグする
3. テクニックその2: アプリ側でエラーを検知する
4. テクニックその3: ログを出力する
5. テクニックその4: AppGroupからファイルをコピーする
6. テクニックその5: 着信時氏名表示をエミュレートする

"Swift Atomics" は、Swiftでアトミック操作(不可分操作、英語ではAtomic Operation)を実現するためのライブラリです。アトミック操作とは、マルチスレッド環境下で値の変更時に別のスレッドから操作を割り込まれないようにするために利用されます(簡単に言えばスレッドセーフな変数を作りたい場合に利用されることが多いです)。

Javaなどの言語にはアトミック操作が可能な変数型が公式にサポートされていますが、Swiftにはまだなく、必要な場合は自前で実装するか"Swift Concurrency"といったサードパーティライブライブラリを利用するしかありませんでした。まだバージョン1.0に達してはいませんが、Appleが公式に開発を進めているだけあって、今からでも注目に値するのではないでしょうか。

本稿では、アトミック操作の概要からSwift Atomicsを使ったアトミック操作の実装、さらには(紙面に余裕があれば)ライブラリの内部実装についてご紹介します。

コンテンツ(予定):

1. アトミック操作とは
2. Swift Atomics以前のアトミック操作
3. Swift Atomicsを使ったアトミック操作
4. Swift Atomicsの実装について(紙面に余裕があれば)

Swiftでは、JSONのNullを許容するキーを、Optionalで表現すると思います。
また、現在はJSONのパースにおいて Codable を利用することが多いと思います。
標準のCodableでは Optional.none をエンコードすると、キーを失ってしまいます。
状況によってはキーを失わず、 JSONのnullを出力したいケースもあるのではないでしょうか。
必要な型ごとに encode メソッドを実装することで実現できますが少し面倒です。
再利用できる手段を取りたいですが、エンコード＆デコードを可能にしようと思うと一工夫必要になります。
本稿では、 Property Wrapper と KeyedDecodingContainer を利用した再利用可能な方法をご紹介します。

Playgroundはプログラミング言語を学ぶ上で非常に役に立つツールです。SwiftはXcodeとiPad・Macアプリとして動くとても高品質なPlaygroundを提供しています。公式のSwift Playgroundsはプログラムをインタラクティブに実行し、結果を途中経過も含めてわかりやすく表示してくれます。

Swift以外の言語に目を向けると、最近のプログラミング言語はどれもPlaygroundのような仕組みを提供しています。しかもほとんどのプログラミング言語にはWebで動作するPlaygroundが提供されています。

Webで動くPlaygroundはさらに強力です。Xcodeやアプリをダウンロードすることなく使え、頭に浮かんだことをiPhoneでサッと書いて実行することもできます。書いたコードを共有したりそれを元にディスカッションすることもより簡単にできます。たいていのWebのPlaygroundは「埋め込み機能」があるので、”実際に実行できるサンプルコード”を埋め込んだドキュメントを作ることもできます。

残念ながらSwiftには公式のWeb Playgroundは提供されていません。しかしサーバーサイドSwiftとWebプログラミングの技術を使って自分でSwiftのWeb Playgroundを作れます！

こちらは私が作成したSwiftのWeb Playgroundです。
https://swiftfiddle.com/

私はこのSwift Playgroundを作成してWebプログラミングやサーバーサイドのテクノロジーについて非常に多くのことを学びました。
本稿ではブラウザで動くコードエディタ、UIの作り方、SwiftによるWebプログラミング、仮想化によるサンドボックス化など私が得たさまざまな知見をお伝えします。

「あ、ここは UIKit じゃないと要件満たせないなぁ」
SwiftUI でアプリを開発していて必ず1回はこのように思ったことがあるのではないでしょうか。

事前にドキュメントを熟読し、実装方針を固めてからコーディングを始めるという流れであれば問題ありませんが、コーディング途中で要件を満たせない事実を目の当たりにした場合、時間の浪費に悔しさを覚えることでしょう。

そんな思いをする SwiftUI チャレンジャーをゼロにすべく、UIKit・SwiftUI のどちらを使えばよいかを一瞬で判断できるフローチャートをご紹介します。（極論 UIKit のみで開発すれば解決するとも考えることが可能ですが、ここでは SwiftUI をできるだけ採用するという方針を前提として解説いたします）
例えば UITextField（UIKit）と TextField（SwiftUI）の場合以下のような条件分岐で利用すべきフレームワークを判断可能です。
＝＝＝＝＝＝
バリデーションは入力完了後に一度だけで良い
→YES: SwiftUI（v1, v2）
→NO: UIKit（TextField には入力文字の変化を随時ハンドリングする方法がありません）
＝＝＝＝＝＝

この原稿を元に工数見積の精度向上、開発中の後戻り削減、SwiftUI の現状理解が可能になるでしょう。

iOSフレームワークのAPIを使ってアプリをコーディングする際に、どのようにAPIを呼び出すコードを書けばいいのかを悩むことはありませんか？
そんなとき、GitHubなどのリポジトリにあるソースコードを参考にするために、コードリーディングする事でしょう。しかし、コードリーディングは非常に手間や労力のかかる作業です。
そこで、Swiftソースコード内でプログラマが気になるAPI 呼び出しの記述箇所を指定すれば、それ以外に関連がある箇所をハイライトするコードリーディング支援ツール「CSExtractor for Swift」を開発しました。
CSExtractorを使えば、開発者は多くのソースコードから自らが利用したいAPIの実装例を気軽に得ることができることでしょう。

CSExtractorは、ソースコードに対して構文解析を行って得られたデータの依存関係に基づいて、関連のあるステートメント同士を抽出します。
CSExtractorでは、Swiftの構文解析であるSwiftSyntax、WebアプリケーションフレームワークであるVaporなどを使って実装しています。
そして、CSExtractorのデモ用アプリケーションはWeb上で公開されています。

本稿では、CSExtratorの使い方やシステム構成、及びソースコード解析のアルゴリズムなどをご紹介します。
最後に、開発者の皆様が煩わしい作業から解放されてクリエイティブな開発活動ができるように、これからもさまざまな開発支援ツールを提案していきます。

AppleのCore Dataは古くからあるオブジェクト永続化フレームワークですが、細かな設定ができるために多様なコンポーネントが存在する複雑なフレームワークとなっています。さらにAPIドキュメントの説明は短く設定のバリエーションに対する公式サンプルも存在しないことで、使ってみなければ分からない部分も多く、難解なフレームワークだと敬遠する開発者ばかりでしょう。

本原稿ではCore Dataのセットアップに関するCore Data Stackの構成とデータ読み書きのためのContextの取得と作成について、iOS SDK 10.0から登場したNSPersistentContainerで多様なコンポーネントを知らなくても簡単に利用できることを説明し、それらがどのように構成されているかを図解します。

本原稿によって、iOSアプリ開発でデータを永続化する必要に迫られた際、安易にOSSを導入せず公式が提供する基礎を探るための原稿となれば幸いです。

楽天グループが運営するラクマでは、旧フリルから含めて今年の7月末で9周年を迎え、10年目に突入します。

振り返ってみると、さまざまな歴史があり、そして弊害もありました。
旧ラクマとのアプリ統合、大企業ならでは開発スピード、ビジネス側との折り合い など...
いろんな要因が重なり、アプリにはレガシーな部分がたくさん残っています。

そんな長寿のアプリですが、ここ半年程でソースコードのObjective-Cを25%駆逐し、Swiftの占める割合が90%近くになりました。また、最新のOSとその１つ前しかサポートをしない方針のため、Combine、SwiftUI、Compositional Layoutといった新しいAPIを導入を積極的に行ってきました。

そんなラクマのiOS開発における、リファクタリングと挑戦を紹介したいと思います。

これまでのiOSアプリにおいて、主にUIKitを利用したUI実装とそれに付随する機能開発を担当する機会が多くあり、また直近数年間に私が経験してきた中では、機能を実現するための実装だけではなく、デザイナーをはじめ様々な職種の方々を巻き込みつつもデザインも絡めた仕様部分から考え抜く機会にも多く恵まれたようにも感じております。
本稿では、チームの皆様（プロダクトマネージャー/デザイナー/エンジニア）を巻き込みながら、アプリUI実装と機能ロジックをコラボして仕上げていく際に、

・デザイナーとの仕様すり合わせの際に心がけているポイントと習慣
・デザインデータから実装における勘所を紐解く
・機能ロジックとUI実装を合わせる際に違和感を感じた場合
・自前で準備する？ライブラリを使う？の切り分けと判断
・Webでは頻出での表現をiOSアプリで実現する際に気をつけている事
・Androidアプリで良くお目にかかるUI表現をiOSアプリで実現する場合の勘所

等を紙面が許す限り、そして私自身が業務で利用してきた設計ノート等も交えながらご紹介できればと考えております。
決して特別な事はありませんが、ほんの少しでも皆様のご参考になる事ができれば嬉しく思います。

ソフトウェアは一度作ったら終わりではなく，その後もソースコードを保守管理しなければいけないというのは今では常識になりつつあります．
積極的に大きなビジネスインパクトを狙い，日々ソースコードの編集を繰り返し，頻繁にリリースを行うことも珍しくはありません．
このようにソースコードへ頻繁に手を加える必要がある際に，レガシーコードは大きなボトルネックとなります．
そしてそんなレガシーコードに頭を抱える時間が1日の大半を占めるようになったとき，私達はリファクタリングという選択肢を考えはじめるのかもしれません．

本稿では約3年に渡る大規模なリファクタリングを入社直後に引き継いだ筆者の体験を基に，直面した課題と解決策，および安全にリファクタリングを進めるために意識したコーディングスタイルを示します．
また，引き継いだ実装から見えてきた，スプラウトクラス等のリファクタリング手法の有用性についても考察します．
考察や説明には、iOSエンジニアに馴染み深いSwiftのコードやリファクタリングに関する文献を適宜引用します。

なお，具体的には以下のようなトピックについて執筆する予定です．
【トピックプラン】

• レガシーコードはクラッシュしてくれてサンキュー．
• リファクタリング中に機能追加が必要！考えられる手段。
• 宗教戦争？privateなメソッドの自動テストを書きたいときにどうすればよいか．
• 解体したい神クラス，でもテストが書けないから下手な修正はできない．そんなときの折衷案．

Swift のリアクティブフレームワーク Combine についての解説記事です。特に、Operator について詳しく解説します。

Publisher と Subscriber との間のデータ変換処理を行う Operator は、Combine フレームワークの重要な要素のひとつです。Operator は種類が多く、できることが様々であるため、把握するのは案外大変です。この様々な Operator たちを整理して、具体的な動作や使いみちを紹介します。

筆者はこれまで、「Combineをはじめよう」と「CombineとUIKitによるiOSアプリ開発」の2冊の技術同人誌を発行してきました（ https://usami-k.github.io/techbook/ ）。今回の記事では、これらの本ではあまり詳しく書かなかった内容について扱います。

数百枚の画像をデータ化し、 CSV ファイルとして書き出すプログラムを Swift で書きました。
え、 Ruby とか Python でサクッとやればええやん。
間違いない、用途に合わせて言語・ツール・環境を臨機応変に変えることがエンジニアには求められています。
にもかかわらず “愛” を優先した独身男性の実話を元にノウハウをご紹介いたします。

１．Xcode Playground 上で実行
２．画像を OCR API の仕様に合わせてエンコード
３．API 実行＆データをメモリ上に格納
４．CSV 形式に変換＆ CSV ファイル出力

ポイントはこの4点になります。
Xcode Playground を利用する中で API 通信・ファイル入力・出力を行う方法を中心に実際のソースコードを元に解説いたします。
また、 仕様を満たすプログラムを “Swift 以外” で実装した例も複数ご紹介いたします。

“Swift 愛” によって思考停止技術選定をした男の末路を知ると共に、仕様に対する最適な技術選定方法を実例を元に学ぶことができます。

iOSアプリ開発でよくあること（俗にいう「あるある」）を4コママンガでめちゃくちゃ面白く表現します。
昨年掲載された4コママンガはXcodeがアップデートできないだけで終わったので、今年は実際の開発のあるあるが言いたいです。

事業の成長とともにアプリに求められる機能は日々拡張され、その実装は複雑化していきます。サービス拡大に伴いアプリ開発に関わるエンジニアの数も増え、当初の設計や実装では今後の開発・運用に支障をきたすケースもあります。そうした場合、リアーキテクチャなど大規模なリファクタリングによる設計変更が必要となります。

このトークでは、JapanTaxi と GO アプリにおける二度のリアーキテクチャの経験から得られた知見を話します。

・なぜリアーキテクチャを行う必要があったのか
・案件開発と並行して大規模なリファクタリングをどのように進めたのか
・リファクタリングに向けた 2ヶ月におよぶ下準備について
・機械的な作業を自動化し、リファクタリング自体に集中する仕組みの構築
・リファクタリング時のコーディング Tips
・リリースに向けた取り組み

ここ1・2年いろんなサービスで実装されてるライブ配信機能。実装を検討されているサービスも多いのではないのでしょうか？

我が社もそんなビックウェーブにのるべく始まったライブ配信プロジェクトですが、エンジニアはバックエンド2人・iOS2人。
少ないリソース、少ない開発期間でリリースすべく、Clubhouseも使っているagoraというサービスを使用することにしました。

4人の戦士が1ヶ月半でリリースした知見をお話しします。

1. ライブ配信機能一覧と分担
   ・agoraで用意されてる機能
   ・自社で担う部分とagoraに任せる部分
2. コメント機能の設計といろんな使い方
   ・通常コメント
   ・ブロック機能
   ・ギフティング
3. 発生した課題・問題たち
   ・難1 配信開始・配信終了の検知どうするの問題
   ・難2 画面レイアウトの設計複雑すぎ問題
   ・難3 リアルタイムで配信一覧を更新したい問題
4. 小咄 ユーザーの推し機能

「Firestoreの導入を検討しているけど、実際どうなんだろう...？」
「導入事例は、新規アプリとか個人アプリばかりで、大きめのアプリで話はあまりないな...」
と思っているみなさまのためのトークを用意しました。

株式会社mikanでは、2020年夏ごろから9カ月以上の時間を費やし、
英単語アプリmikanのiOS版のクライアント側で使用しているDBを、SQLiteからFirestoreに移行しました。
（現在Androidも移行中です）

このトークでは、9カ月を超えるプロジェクトを振り返り、

そもそもなぜDBの移行が必要だったのか、どんなことに失敗して、どんなことはうまくいって、
同じようなこと企む方々が少しでも僕たちよりもうまくできるようにするためには何を意識すればいいか、という話、
そして、そもそも何故SQLiteを使っていたの？なぜFirestoreを選んだの？実際に使ってみてどう？みたいな部分も赤裸々に話していこうと思います！

• なぜSQLiteからFirestoreへ移行したのか
  • SQLiteが採用された歴史的経緯
  • SQLiteのツラミ
  • Firestoreを採用した理由
• 移行によって変わること
  • スタンドアローン型DB→ネットワーク型DB
  • RDB→KVS
• どのように移行を進めたのか
  • ダブルライト
  • マイグレーション
  • クライアントロジックの移行
• うまく行ったこと
• 難しかったこと
• 実際Firestore使ってみてどう！？
• プロジェクトをやってみての学び・同じことを考えている人へのアドバイス

オーディオのデータは時間に対しての量が多いので何も考えずに波形を表示しようとすると、綺麗に表示されなかったりパフォーマンスが十分に出なかったりメモリを簡単に使い切ってしまったりします。

単に一つの短い数秒のオーディオの波形を表示するだけでも気にすべきことはありますが、大量のファイルの波形を表示したかったりリアルタイムにスムーズなスクロールをしたいとなると、より一層の工夫が必要です。

このトークでは、オーディオ再生アプリを実装した時の知見を元に、場合に応じてオーディオ波形表示をどのように実装すべきかのヒントとなるお話しをします。

以下のような内容を予定しています。

・オーディオデータの仕組みついて
・様々なアプリの波形表示方法を比べてみる
・波形表示のためのオーディオデータの間引き方・扱い方
・パフォーマンスを考慮した波形表示

SwiftUIが発表され早2年が経ちました。そんなSwiftUIですが、本番アプリで採用されているケースはまだまだ少ないかと思います。
お友だちやご家族と一緒にシェア買いができるアプリ「KAUCHE（カウシェ）」は、大部分がSwiftUI,Combineを活用して作られており、2020年9月にリリースしました。
そして、リリースから1年運用しています。
・SwiftUI,Combineを活用し、どのようなアーキテクチャで開発・運用しているのか
・SwiftUIで開発中に問題となった点
・運用している中でわかった良かった点・悪かった点
などをお話したいと思います。

I will explain stack memory basics using Swift, and highlight some of the pitfalls even experienced programmers may encounter when working with the stack.

Since stack memory is automatically managed, and Swift mostly uses heap allocated objects, most programmers don't require a deep knowledge of stack memory, despite using sites like "Stack Overflow" every day.

Being oblivious to stack memory is usually not a problem, however it is worth learning about, especially if interfacing with C code.

In my talk I will cover the following:

• What is the stack?
• Simple example of stack usage in C, with equivalents in Swift
• Why do we care about the stack in Swift?
• Examples of bad stack usage in Swift
• How to debug and avoid stack issues