Search

LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog

Blog


「サイボウズ × マネーフォワード × LINE iOS Meetup」開催 iOS開発の知見やTipsのLTをサマリーで紹介します

LINE Engineering2023-04-11

LINE Engineering Blog official account

2023年3月24日（金）、LINE Fukuokaオフィスで「【福岡｜オフライン開催】サイボウズ × マネーフォワード × LINE iOS Meetup」を開催しました。当日は福岡および近郊にお住まいの方々にご参加いただきました。 このレポートでは、それぞれのLTで発表されたサービス開発の裏側や技術的取り組みやiOS技術に関するTipsを紹介いたします。

目次

swift-async-algorithmsを導入した話

iOS DeveloperでサイボウズのOffice iOSアプリを開発しているelmetalです。サイボウズ Office iOSアプリではConcurrencyを積極的に使って開発しており、 最近では一部でCombineをswift-async-algorithmsに置き換えました。 この発表では置き換えで考えたこと、踏んだことを簡単にご紹介します。

サイボウズOfficeは、B2Bのアプリケーションで中小企業向けのグループウェアです。「誰でも簡単に使える」をコンセプトに開発されておりiOSアプリも提供しています。このアプリはフルSwiftUIで作られており、iOS 13のマイナーバージョンで不安定な時代から開発をスタートしています。そして現在、Swift Package Managerを利用したマルチモジュールプロジェクトの開発が進められています。

swift-async-algorithmsの導入を検討するきっかけとなったのは、BGTaskで動作する非同期の処理にバグが発覚したことです。該当するモジュールは、@preconcurrencyで並行プログラミングの中でも潜在的な不具合がありそうなコードで構成されていました。このモジュールは依存ツリーの末端に位置していたため、修正しても全体に影響は及ばないと考えられました。不具合を修正する際、潜在的な問題を排除したいという考えから、Structured Concurrencyで静的検査を行いたいという話になりました。同時に、CombineはSwiftでリアクティブプログラミングを行うためのフレームワークで、2019年6月のWWDCで登場しましたが、すでに疑問視されており、Combineを使わない方向に舵を切りたいという意向がありました。そのため、AsyncStreamやAsyncChannelを使った機能が適当であると判断しました。

不具合を修正するためのPublic APIの使用オプションとして「Combineを露出して利用側でpublisher.valuesを使う」もしくは「swift-async-algorithmsのAsyncChannelを露出する」という2つの選択肢がありました。私たちはトレードオフ分析の結果、Combineを使わずにswift-async-algorithmsを採用することにしました。ソースコードがオープンであり、問題が発生した際に全体の問題を特定しやすいと判断されたからです。ただし、swift-async-algorithmsのバージョンは0.0.4であり、破壊的変更や未成熟なAPIによるリスクがあることも認識されていました。

中の実装に関しては、swift-async-algorithmsを利用し、利用側はpublisher.valuesとAsyncChannelの両方を使って混ぜる形にして、全体でStructured Concurrencyの静的検査が行われるように変更を加えました。これにより、静的検査で問題の発見が容易になりましたが、Taskの取り扱いが難しいことが明らかになりました。また、新たにGlobalActorが必要になったため、isolateが必要だったプロパティの存在に気づけました。一方、GlobalActorがdebug buildでコンパイルエラーが起きないという問題が発生し、調査が必要な課題となっています。
最終的には全体として、Structured Concurrencyとswift-async-algorithmsによる既存コードの置き換えは成功し、静的検査で問題を見つけやすくなりました。しかしTaskの扱いの難しさが課題となりました。私たちは引き続き、これらの課題解決に向けて取り組む予定です。

榎原 聖太（elmetal） / Twitter / サイボウズ株式会社 サイボウズ Office iOSアプリ開発チーム

サイボウズ OfficeのiOSアプリ開発を担当。Swiftで本格的にプログラミングを始める。HIGのDesign Principlesに感銘を受け、インターフェースデザインに興味を持つ。好きなギタリストは橘高文彦。

身に覚えのない Apple Developer Program License 違反を通告されたので対応する

株式会社マネーフォワードで「マネーフォワード Pay for Business」というサービスのiOSアプリ開発を担当している堺です。今回は個人開発で経験した話をします。
私は「2023年の恵方コンパス」というアプリを個人で開発しています。名前の通り、その年の恵方を向くためのアプリです。 スマホを持って矢印の指す方向を向くことで恵方を探します。 このアプリは節分の日によく使われるため、今年の2月3日はダウンロード数が大幅に増え、App Storeの無料アプリランキングで総合2位になりました。

 

しかし、数日後に「恵方」と検索した際の表示順位が大幅に下がっていることに気付きました。以前は一番上に表示されていたのが一番下まで下がっていたのです。何か一時的な不具合かなと思い何も対応しませんでしたが、それからさらに数日後、AppleからApple Developer Programのライセンス違反を警告するメールが届きました。「App Storeのランキングやユーザーレビュー、検索などを操作している」とのことでした。 しかし私には全く心当たりがなかったので、その旨を返信しました。

1ヶ月経っても返信がなかったため、次の打ち手としてApp Store Connectのお問い合わせフォームから日本語で問い合わせました。今回は数時間後にAppleサポートの方から日本語で返信が来ました。

やり取りの結果、そのお問い合わせフォームから連絡できる部署はApple Developer Programのライセンス違反メールに関連する部署ではないとのことと、担当部署と連絡を取る方法は先に紹介したライセンス違反メールに返信をすることだということが分かりました。その後、再度警告メールに返信し、ライセンス違反に当たることはしていないと主張しました。また、2月3日だけダウンロード数が急増したことが原因ではないかという推測を添え、これには日本の節分という文化が関係していると説明しました。

今回はAppleから返信が届きましたが、その内容は「App Storeのユーザーレビューを操作してはいけない」のみに留まっていました。今後釈明をするにあたり、私がApp Storeのレビューを操作したと判断された理由を知る必要があると考え、その説明を求める旨のメールを送りました。しかしその後のAppleからの返信に明確な回答はなく、私がそれに対して3月19日に送信した最後のメールに対し現時点（3月24日）では返信が届いていません。

現在もAppleからの回答を待っているため個人的な考察にはなりますが、2月3日の一時的なインストール数と利用者数の急増が本件の原因である可能性が高いと考えています。しかし私にはライセンス違反をした心当たりはなく、アプリの検索順位が下がることも納得できていないため、今後も問い合わせを続けるつもりです。この件にアップデートがあれば、またどこかでお話しできればと思っています。最後に宣伝ではありますが、来年の節分には私のアプリをお使いいただければ幸いです。Apple Developer Programのライセンス違反メールが届いた場合、それに対して英語で返信をしましょう。皆様にはそういったメールが届かないことを願っています。

堺 雄之介 / Twitter / 株式会社マネーフォワード Pay事業本部プロダクト開発部 

2022年4月に株式会社マネーフォワードに新卒入社。現在は「マネーフォワード Pay for Business」のiOSアプリ開発を担当。恵方を向くためのコンパスアプリ開発がiOSアプリ開発を始めたきっかけ。また個人で何かリリースしたく、アプリアイデアを考え中。

LINE Sticker Maker iOS Modularization 

LINE FukuokaのSticker Maker App DevチームのWang Lun汪倫です。私たちは、iOSアプリケーションの開発を担当しているチームです。今日は、Sticker Maker iOSのモジュール化の際に解決しようとした問題について話したいと思います。 
まず、私たちが直面した問題点についてお話しします。まず最初にモジュールが1つしかなかったため、すべてのソースコードが一緒になっていたことが挙げられます。これが、依存性逆転の問題を引き起こす主な原因でした。また、CocoaPodsとSwiftPMを「問題なく」ハイブリッドで使用することができました。 

左のグラフをチェックすると、典型的な”誤った依存関係"が発生しています。APIClientは、Appモジュールに属する「baseURL」に依存しています。右のグラフを見ると、この問題を修正するために使用した解決策が表示されます。APIClientを適切な依存性注入で「設定可能」にする必要があります。実際のプロジェクトでは、依存の問題はより複雑になる可能性があります。 

次に、2つ目の問題についてです。SwiftPMとCocoaPodsを同時に利用する際に、課題が発生しました。コードベースをモジュール化していると、SwiftPMライブラリとCocoaPodsライブラリの両方に依存するモジュールを作成することはできないことがわかりました。1つの依存性管理ツールを選択することが、モジュール化には適しているかもしれません。3つ目の問題は、異なるモジュールに属するはずの異なるViewControllersでセルを共有していたことです。これはモジュール化の障害になります。モジュール化はセルを共有するよりも重要です。また、最近はSwiftUIでViewControllerのビューを書き直すことも良いオプションです。 

RxSwiftについて紹介します。5年前の新しい技術でマルチスレッド/UIバインディング/MVVMで便利ですが、私たちは過剰に使いすぎ不適切に使用してしまいました。非常に長いメソッドチェーンを作成し、1つのViewControllerですべてのフローを表しています。最初のViewControllerにはすべてのViewControllerが含まれており、RxSwiftで接続されています。1つのフローには約200行の長いメソッドチェーンがあります。実際のコードを見てみましょう。 

これは、ステッカーを作成するために使用した実際のコードの一部です。すべてのViewControllerを接続するために1つのRx.pushが使用されていることがわかります。そして、各ビューコントローラ内部には、別の10のシグナルがある場合があります。また、20のシグナルをチェーンすることがあるため、コードが非常に読みにくくメンテナンス/デバッグが困難になります。さまざまなモジュールの責任を考慮せずに、「100％」関数型プログラミングを実践しようとしました。 

問題を修正するために、私たちはRxSwiftを捨てることを決定し、Combineとasync/awaitで書き直すリファクタリングを行いました。それから、ロジックを整理し、単一のシグナルチェーンを分解する機会を得ました。最終的に、それらをモジュール化することができました。モジュール化は、ソフトウェア開発において非常に重要なコンセプトであり、コードの責任を理解し、管理する能力を大幅に向上させることができます。コードベースをより小さく、より焦点を絞ったモジュールに分割することにより、機能をより簡単に特定し、分離することができます。つまり、モジュール化は、複雑なソフトウェアシステムを管理し、コードベースを整理し、効率的に保つための明確な構造を提供します。このように、コードをより使いやすく、理解しやすくすることで、開発者はより効率的にソフトウェアを開発し、品質を高めることができます。

Wang Lun汪倫 / GitHub / LINE Fukuoka株式会社 Sticker Maker App Devチーム 

I am iOS engineer now and I was an iOS automation test tool engineer before, I’ve got some interesting experience on automation test tool and reverse engineering of iOS

ブラウザアプリを自作してわかったWebViewの扱い方 

私はサイボウズで、kintoneという製品のモバイルアプリの担当をしているiOSエンジニアのKyomeです。担当しているkintoneには「JavaScriptカスタマイズ」というユーザー独自の機能を追加できる仕組みがあり、その都合上kintoneモバイルはWebViewベースのアプリになっています。しかし、WebViewベースのアプリ開発を担当するにあたって、WebViewを十分に扱ったことがなかったため、ブラウザアプリを丸ごと自作することで扱い方を学ぶことにしました。今回は、実際にブラウザアプリ作成を通して学んだことの中から、SwiftUIでWKWebViewを扱う方法に焦点を当てて紹介します。（作成した成果物のMinBrowserは、App Storeで配信中であり、ソースもGitHubで公開していますので、ぜひ参考にしていただけると嬉しいです。） 

SwiftUIでWKWebViewを扱うには、UIViewRepresentableを使ってWKWebViewをラップし、Viewとして使います。ただし、単純に特定のウェブページを表示するだけでなく、検索や戻る、進む、Pull to refreshなど、インタラクティブなWebViewを作る場合は、UIViewRepresentableの外のViewと連携する必要があります。例えば、検索バーにワードを入れて検索のリクエストを投げ、そのロードの状況をプログレスバーに反映させるようなケースが考えられます。 

GitHub上でこのようなインタラクティブな機能を実装しているものを調べると、enumのプロパティを監視し、WKWebViewのアクションを制御し、UIViewRepresentableのCoordinatorでWKWebViewの状態を監視する手法がよく使われています。具体的には、UIViewRepresentableの中でActionのようなenumを用意し、外部で変更があった場合、updateUIView()の中で監視して、Coordinatorを介してWKWebViewをハンドリングします。また、CoordinatorでWKWebViewの状態を監視するために、makeCoordinator()のタイミングでWebViewのインスタンスをCoordinatorに渡したり、外部にBindingしたいプロパティをここで紐付けたりします。そして、WKWebViewのもつ状態はCombineなどで購読してBindingしているプロパティに流します。 

一見、この手法は良さそうに見えますが、実はかなり問題があります。例えば、ワード検索後にロード処理が終わらず、何度もロードし直すような現象が発生します。しかも、Xcode上では大量の警告が表示され続ける状態になります。問題点は警告にある通りで、Viewの更新中にバインドされた値の更新が大量に行われることです。これは、WebView自体がViewであるにも関わらず、状態を持っており、Viewの外部から状態が変更されたり監視されたりする必要があることが原因です。つまり、WebViewは宣言的UIとの相性が悪く、馴染みづらいという問題があります。 

そこで考えた解決策は、UIViewRepresentableで完結するのをやめ、外部にWKWebViewのインスタンスを持たせ、そちらで状態の監視と制御を行うことです。例えば、WebViewModelにWKWebViewのインスタンスを渡し、モデル側で状態の監視と制御を行い、UIViewRepresentableのWKWebViewには描画だけを任せます。 

この場合、UIViewRepresentableは非常にすっきりと書けます。WKWebViewのインスタンスを外に渡すためのハンドラをクロージャで用意して、makeUIView()のタイミングで使う点が要です。WebViewModelの方では、WKWebViewのインスタンスを受け取れるようにしておき、受け取った際に状態を監視します。この実装方針であれば、UIViewRepresentableにWebViewの状態を伺いに行く必要がなくなり、WebViewへのアクションはWebViewModelに要求すればよくなります。 UIViewRepresentableを使う際も、宣言的UIの特性に合わせて「状態の監視・制御」と「描画」の責務を分割し、実装することが大事だという学びでした。 

中村 拓人 (Kyome) / Twitter / サイボウズ株式会社 kintone(開発)チーム

kintoneモバイルアプリの開発を担当。GitHub Actionsでの業務効率化や自社OSSライブラリの開発運用に積極的。個人ではRunCatをはじめとしたmacOS向けのユーティリティアプリの開発を行なっている。好物はカレーうどん。

大量のアプリをお世話するHOW TO

株式会社マネーフォワードの松元麗美と申します。早速ですが、私は普段の業務でいくつのアプリを運用しているでしょうか。正解は26です。2つのプロダクトから派生したアプリがそれぞれ13個ずつあり、合計26個という形になっています。図にするとこんな感じです。通帳のアプリや家計簿のアプリを作成しており、それぞれクライアントさん向けにカスタマイズされたものをビルドしています。そのアプリが下に並んでいます。

どちらのプロダクトも同じコードから複数のアプリを作成しています。どのクライアントさん向けに作っているアプリかというのを切り替えてビルドしています。切り替え方が2つのプロダクトで異なっているので、どうやって切り替えているかを説明していきたいと思います。元々同じ構図なのですが、それぞれのクライアントさん向けに作るにあたって、少し定義やアイコン、色、オプション機能の有効化などの差分がどうしても発生してしまいます。今日はこの辺の扱い方についてお話ししようと思います。

それでは、1つ目の方法をご紹介します。これは、差分管理用のフレームワークを作成する方法です。 現在、本体があり、その下に「forXXX」と記載されていますが、ここにこのフレームワークを作成し、差分となる設定値を入れています。 本体では、クライアントの数だけターゲットを作成しています。実際の画面は、上にプロダクト本体があり、その次に本体とは別のプロジェクトが作られており、差分が集まっている様子です。 本体側では、多数のアプリを持ち、そこから他のフレームワークを参照する形で、同様に差分定義用のフレームワークを参照しています。

コードは以下のようになります。差分が発生する部分で、差分管理用のフレームワークをインポートし、実際に使用する箇所でフレームワークのconfigを確認して、機能が有効か無効かといった差分をチェックしています。メリットは、アプリの数だけターゲットが並ぶため、直感的で分かりやすいです。デメリットとしては、差分管理用フレームワークに収められないもの（Image assetやEntitlementなど）は本体に配置し、ターゲットメンバーシップのチェックが必要になるため、チェックミスが起こりやすく、少し面倒です。リリース時には、ターゲットごとにバージョン番号を手動で設定しております。

この作業を毎回行うのは面倒なので、先日社内勉強会にて技術顧問のgiginetさんからSwift Package Pluginを教えてもらい、一括更新ができるよう挑戦しています。 興味のある方は、マネーフォワードのデベロッパーブログをご覧ください。

それでは、2つ目の方法について説明します。この方法では、プロジェクト本体内に差分をまとめたディレクトリを作成します。そして、スクリプトを使ってこのディレクトリの参照先を一括で入れ替えるような仕組みです。プロジェクト構成は以下の通りです。

プロジェクト上では、差分ディレクトリは1つになりますが、実際のフォルダ構成では、このディレクトリがクライアント数だけ存在し、どれを参照するかはスクリプトで決定されています。メリットは、アプリ毎の差分を完全にまとめることができる点です。デメリットは、検索が若干弱い点です。Xcodeで検索を行うと、選択中でないリージョンとの差分ファイルは通常の検索で見つからないため、Xcodeの検索遷移からSearch Scopeを作成すると良いでしょう。リリース方法については、ビルド時に外部からバージョン番号とビルド番号を指定しています。現状では手動で番号を渡していますが、自動でインクリメントできるように改善すると良いと考えています。

最後にまとめます。 2つのプロダクトでは、それぞれ歴史的経緯から異なる方法が採用されており、現在も両方の方法で保守が行われています。Bの方法では差分がまとまりやすく、見栄えも良いですが、個人的には最初に説明したAの方法の方が、説明しやすく理解しやすいと感じています。以上が発表内容です。これで皆さんも大量のアプリを管理できるようになります。

松元 麗美 / 株式会社マネーフォワードエックスカンパニー ソリューションデザイン本部

2021年12月に株式会社マネーフォワードに中途入社。現在は地方銀行向けOEMアプリのiOS版の開発を担当。日本全国を飛び回る旅行趣味を活かし、日本各地のクライアントに思いを馳せながら日々活動中。

UI/UX Analytics

LINE FukuokaでiOS開発をしているBibekです。私は日頃からモバイルエンジニアとして、新しいUIがどのように有効かを測定する方法について常に疑問を抱いてきました。また、時には企画担当者から見た目の良いUIに変更するよう依頼されたりすることがあり、ユーザーにとって良いUI/UXについて考えることがありました。このセッションでは、そのプロセスについて簡単に説明します。

全ては以下のような質問から始まります。

  • 新しいUIが有効かどうかはどうやって測定できるのか？
  • 最後にデプロイされた機能はどのように使用されているのか？ユーザーのコンバージョンパターンは何か？
  • ユーザーは機能に到達しているのか？
  • ユーザーの困りポイントは何か？UI/UXの問題がユーザーをイライラさせているのか？

以上の質問に答える最も効果的な方法はUI/UX Analyticsを用いることです。では、どのように行うかについて見ていきましょう。まず、データを収集する必要があります。以下はそのための例です。

  • スワイプなどのジェスチャー。
  • 画面遷移やカスタムイベントなどのイベント。
  • ビューとその位置のスナップショット。

これらのデータを収集するための設定を行うと、ユーザーから効果的なデータを収集することができるでしょう。次に、いくつかの可視化技術について説明し、これらのデータを形にしましょう。

Graphs/Charts：これは基本的ながら効果的な可視化形式です。日毎のアクティブユーザーやユーザーのリテンション率などを簡単に表現できます。
Funnels and Journey：ユーザーの変換を追跡するための人気のあるツールです。
Heatmap：ユーザーがアプリを開いてから閉じるまでの画面/イベントから次の情報を入手できます

・チェックアウトまで到達したユーザーの数。
・ユーザーが到達するまでに異なるパス。
・どの画面でユーザーが離脱したか。

ユーザーのジェスチャーとスクリーンショットを統合することで、ヒートマップを作成できます。これにより、ユーザーがUIとのやり取りをしている方法を知ることができます。レイジータップ、ジェスチャーの衝突、反応しないタッチなどの問題を特定できます。

Session Recording：これは非常に豊富なツールです。スナップショット、ジェスチャー、イベントを組み合わせて、ユーザーがアプリや機能をどのように使用しているかのムービーを作成して視聴できます。実際のクリックとナビゲーションもわかります。

これらの可視化をすべて活用すると、多くの質問の回答を早期に得ることができます。ユーザーの困りポイントを特定することもできます。UI/UX分析を適切に活用すれば、A/Bテストの技術をより充実させることができます。今回は収集できるデータと、それらがどのように形成されて有意義な洞察を与えるかについてご紹介しました。

Bibek / LinkdIn / LINE Fukuoka株式会社 LINE Client Dev A Team

iOS Engineer. Just a learner.

英会話講師がマネフォでiOSエンジニアになってみた

株式会社マネーフォワードのクラウド経費本部プロダクト開発部で「マネーフォワード クラウド経費」のiOSアプリ開発を担当している篠原です。私自身開発にはまだまだ未熟なところがあり、コメントやレビュー指摘を受けることがありますが、私自身が持つ経験を生かして、マネーフォワードで英語に関するワークショップを開催しています。

マネーフォワードでは、2024年度までにエンジニア組織を完全英語化する計画を進めており、海外のエンジニアを受け入れるための取り組みも進めています。私たちのワークショップは、このような目的に向けたものであり、英語の文法事項を取り上げ、ライティングやスピーキングのアウトプットを練習しています。

参加者からは、ポジティブなフィードバックをいただいており、将来的には、アップルのドキュメントを使った勉強会を英語で開催したり、ヒューマンインタフェースの輪読会を英語で行うことも検討しています。また、WWDCの解説を日本語から英語に翻訳する前に、社内で英語で解説することも目標としています。これらの取り組みによって、私たちのエンジニアチームはさらにレベルアップできると考えています。

最後に、私自身は未熟なところが多いですが、マネーフォワードの英語化に貢献するために、英会話のワークショップを開催しています。私たちのチームがよりレベルアップし、成長していくために、iOSエンジニアを募集しています。

篠原 裕貴 / Twitter / 株式会社マネーフォワード クラウド経費本部プロダクト開発部

2022年10月に株式会社マネーフォワードに中途入社。現在は「マネーフォワード クラウド経費」のiOSアプリ開発を担当。地方公務員・フリーター・英会話講師を経験し、ある日iOSアプリ開発者を志し本日にいたる。

Go Beyond the Actor Boundary

LINE株式会社 Developer Experience開発チームでiOS基盤開発をしているgiginetです。
今回はSwift 6.0のリリースが予想される来年以降に備え、現在のSwift 5.8から対応しておくことの重要性について紹介します。Swift 6.0では、非同期処理のチェックが厳格化され、スレッドセーフではないコードやSendableに適合しない型をプロセスを超えて共有することが許されなくなる予定です。この変更により、今までビルドできていたコードが動作しなくなる可能性があります。

非同期処理では、Race Conditions、すなわち複数のプロセスが共有リソースにアクセスすることで問題が発生することがありますが、Swift 6.0ではこれらの問題をビルド時にある程度検出できるようになります。ただし、自動検出に対応したコードを書かないとビルドが通らなくなるため注意が必要です。

Swift 6.0への移行を確認するためには、オプションが用意されており、それを有効にすることで、Swift 6.0の挙動をエミュレーションすることができます。このオプションには3つのモードがあり、それぞれ3段階設定できます。徐々にレベルを上げて、最高レベルでビルドが通るようにすることで、Swift 6.0への対応ができます。

Swift 6.0では、Race Conditionsを防ぐために、データ競合を起こしうる型をスレッド間で共有できなくなります。これを示すために、SwiftではSendableというプロトコルが導入されています。これは、数のプロセスから値を共有しても安全であることを示すプロトコルです。詳しくは、以下のWWDCのセッションをご覧ください。

Swift 6.0では、Sendableが必要な箇所での適応が必須となるSendable制約、また、特定のスレッドでの動作を強制するActor Isolation Checkingが必須となります。これにより、今まで動いていたコードがビルドできなくなる可能性があります。Swift 6.0がリリースされた際に慌てないように、今のうちに備えていきましょう。

移行方法については、以下の安全な非同期処理チェックのためのマイグレーション手法を提案したproposalで述べられています。

Swift 6.0からエラーになる項目を警告してくれるビルドオプションとして`-strict-concurrency=LEVEL` オプションで警告レベルを選ぶことができます。これらのオプションには、minimal、targeted、completeの3段階があり、それぞれ異なるレベルのチェックが行われます。Swift 6互換モードであるcompleteモードは、従来の-warn-concurrencyと同等です。

この設定はXcode 14.0以降から利用可能です。各レベルの違いは、-strict-concurrency=LEVELオプションが導入されたPRやswiftcの実装を参照することで知ることができます。

最終的には、Swift 6.0までにcompleteの警告が解消されないとビルドが通らなくなるため、段階的なマイグレーションを進めていくことが重要です。また、ほとんどアプリケーションでは、UIKitの大部分の実装がMainActorでの実行を強制されるため、多くのビルドエラーが発生するでしょう。以下の記事が参考になります。

実際にConcurrencyを理解して、コードを安全に修正していく方法の説明にこの5分の発表では足りません。様々な言語仕様や非同期処理への理解が必要です。これらの知識を習得することで、より効果的な並行処理の実装が可能になります。Swift 6.0の変更点や非同期処理に関連する機能を理解し、段階的なマイグレーションを進めていくことで、Swift 6.0に備えましょう。

三木 康暉（giginet） / Twitter | GitHub / LINE株式会社 ディベロッパーエクスペリエンス開発チーム

LINEアプリのビルド環境の高速化や、全社の共通基盤開発を通して、日夜DX改善に取り組む。株式会社マネーフォワードや株式会社ユビレジなどでiOS領域の技術顧問も務める。著書に『cocos2d-xではじめるスマートフォンゲーム開発』(技術評論社)など。趣味はゲーム開発。

一般公募枠からの発表

当日は福岡近辺にお住まいのエンジニアの方にも会場にお越しいただき発表をしていただきました。

Unity as a LibraryでiOSネイティブアプリからUnityのARを使ってみる

発表資料
https://docs.google.com/presentation/d/1k6wB7Kj8gZBqSbN856W30r_lxLGYcm7O1J2r6bD9klI/edit#slide=id.p

長峰 慶三 (KzoNag) / Twitter / 株式会社ホロラボ／福岡XR部

現実とバーチャルが混じった体験が好きなXRエンジニア。株式会社ホロラボ所属。仕事でも趣味でも実験やプロトタイピング開発など日々何かを作って遊んでいる。福岡を中心にXR好きが集まるコミュニティ「福岡XR部」を運営。

ChatGPTを使ったiOSアプリ開発支援

発表資料
https://speakerdeck.com/mitsuharu/chatgptwoshi-tutaiosahurikai-fa-zhi-yuan

関連記事
https://mthr.hatenablog.com/entry/2023/03/25/084826

江本 光晴 / Twitter / 株式会社ゆめみ 

2022年6月に株式会社ゆめみに中途入社。iOSテックリードとして、開発チームの後方支援を行う。iOSの他にクロスプラットフォームや機械学習にも興味あり。当日は隣県の山口県から関門海峡を渡って参加します。

マンデルブロ集合を見るためだけのアプリを作った話

発表資料
https://drive.google.com/file/d/1vxVgjKukCHO2qGLOEwFaKOSWujSP-gPr/view

鈴木 智久(tomoq) / Twitter / 九州工業大学情報工学部1年，C3(Composite Computer Club)

最近iOSアプリの開発に興味を持ち始めた九州工業大学情報工学部生。JavaScriptでゲームを作ったりしていた。今年中には何かしらのiOSアプリを個人でリリースしたいと考えている。

懇親会 

懇親会では、LT発表の質疑応答や現地参加されたエンジニア同士の交流が行われました。