株式会社ヤプリは、ノーコードアプリプラットフォーム「Yappli」を提供しています。
1つのコードベースから約900アプリを生成しているため、レイアウトを含むアプリの構成情報は全てサーバーから取得しています。
その中で、多種多様なデザインニーズに素早く応えるため、より柔軟で再利用性の高い画面構築基盤「Block UI」をゼロから設計し、まるでフルスクラッチでアプリを開発したようなリッチな表現を可能としました。
開発においては、SwiftUIの特性を活かす設計、型安全性と柔軟性の両立など、数多くの技術的課題に向き合ってきました。
本セッションでは、プラットフォームの進化と共に生まれたBlock UIのアーキテクチャについて、以下の観点から実践的な知見を共有します。
Server-Driven UIに興味のあるiOSエンジニア、SwiftUIでの大規模アプリ開発に取り組む方、また汎用アーキテクチャの設計と運用課題に向き合っている方に向けて、実践的で具体的な技術的知見をお届けします。
2024年にリリースされたSwift 6は、iOSアプリ開発者に数多くの恩恵 (と少しの混乱) をもたらしました。
まだXcodeのデフォルト言語バージョンではないものの、すでに対応済みのチーム、鋭意対応中のチーム、様子見をしているチームなど、取り組みはさまざまです。
2016年にリリースした総合医療アプリ「CLINICS」は、病院・薬局の予約からオンライン診療・服薬指導、お薬手帳までをカバーし、9年間にわたり多くの患者様の医療体験を支えてきました。
その裏側では、SwiftUIへの置き換え、複雑化する依存関係の解決、メンテナンスが止まったライブラリの移行など、長期運用ならではの技術的負債と向き合い続けています。
本セッションでは、今秋予定の大規模ブランドリニューアルを見据えて実施した、Swift 6移行プロジェクトの取り組みを紹介します。
「止められないシステム」を支える医療現場のアプリの、既存資産を活かしながら最新技術スタックへ移行した知見をお伝えできれば幸いです。
スマートフォンの登場がエンジニアのキャリアを大きく変えたように、今、私たちはAIという新たな転換点に立っています。
この変革期において、iOSエンジニアは自らのキャリアをどのように設計すべきでしょうか。
そのヒントは、iOS技術やエンジニアのキャリアにおける"先進性"と、転職ドラフトが提唱するマインドセット「探索型キャリア」の融合にあります。
・エンジニアにおけるキャリア理論
・転職ドラフトスカウトデータが示すiOSエンジニアの市場価値
・iOS技術の強みや将来性
上記3つの観点から、先進性をどう武器にし、キャリアを設計していくべきか体系的に紐解きます。
「こんな複雑なUIどうやって実装してるんだろう」と思ったことはありませんか?
UICollectionViewLayoutはその疑問に対する1つの答えとなるかもしれません。
私たち株式会社アンドパッドが提供している施工アプリには「工程表」と呼ばれるガントチャート機能が存在します。ガントチャートとは縦軸に作業項目、横軸に時間をとる棒グラフです。
この機能は従来WebViewで提供してきましたが、いくつかの理由からネイティブUIで作り直すことに決めました。
iOSのデザインにフィットしてスムーズに動作する、複雑なガントチャートUIを作るには…… たどり着いた答えがUICollectionViewLayoutのサブクラス実装による独自レイアウトでした。
本セッションでは以下の内容をお届けします。
UIKitはまだまだ現役のフレームワークです。
UICollectionViewLayoutの圧倒的な応用力を知り、「どんなUIでも作れそう」という万能感をぜひ味わってみてください。
炎上の中リリースされ、
長い間メンテナンスされず、
当時の担当者もチームに不在。
アーキテクチャも成立しておらず、
ソースコードはスパゲッティ、
テストコードはもちろん書けない。
私は、そんなレガシーなアプリのリニューアルプロジェクトにアサインされたAndroidエンジニアです。
iOS未経験の立場でチームのリードとしてiOS版の技術的な意思決定にも関与することとなりました。
Androidエンジニアとしての知見をベースに
・リアーキテクト
・ユニットテストの整備
・SwiftUIの導入
・生成AIとの協働
をiOSアプリで実現するまでの取り組みをお話しする予定です。
少しイロモノなトピックかもしれませんが、レガシーから脱却するために効いた取り組みの事例が、皆さんのエンジニアリングの参考になればと思います。
私たちが日々開発をするなかで、CI/CDはプロダクトの品質を担保し、開発を効率化する上で不可欠な存在です。特に自動テストはバグを早期発見し品質向上に貢献しますが、その一方で、私たちはCI/CDを信頼しすぎていないでしょうか?
「CIが成功しているからOK」と、ビルドやテストにかかる"時間"やテスト成功率といった「不健康なサイン」から無意識に目をそらしていませんか?
実際私の担当するプロジェクトでは導入した自動配布で40分ほどかかっている現状があり、その無視できないサインから、「CIが遅い」という課題に正面から向き合ってみることにしました。
このセッションでは、その小さな気づきから始まったCI/CDが「健康」になっていくまでの改善の過程を、個人と組織、両方の視点からお話しします。
まず、改善の第一歩として「どこに注目すべきか」という観点を整理します。実行時間や安定性といった指標に対して、CircleCIやGitHub Actionsなど各サービスごとの機能を活かしながら、どうボトルネックを特定していくのか。各サービスごとに比較しながら、その分析手法からお話しします。
その上で、ビルドツールのキャッシュ見直しやマルチモジュールによる高速化、そして見落としがちなテストコード自体のアンチパターンやリファクタリングといった具体的な改善アクションをお伝えします。
しかし、個人の改善活動だけでは、プロジェクトやチームを横断した品質の維持には限界があります。より大きな視点で、全社的にCI/CDの健全性を保つためにはどうすればよいでしょうか? 本セッションの後半では、その問いに対する弊社なりの答えとして、組織的な仕組みである「健康診断」や月次レポートについても詳しく解説します。
ウェルスナビでは「ものづくりする金融機関」というビジョンのもと、金融機関でありながら自社サービスのモバイルアプリを内製で開発しています。
しかし在籍するモバイルアプリエンジニアの人数は少ないため、どうしても一人ひとりの負荷が高くなりがちです。
そこで、ウェルスナビのモバイルアプリ開発では開発生産性を高めるために、プロセスの自動化を初めとする様々な取り組みを実施してきました。
本セッションでは、その中でもiOSアプリ開発における以下の取り組みについて紹介します。
本セッションを通じて、モバイルアプリエンジニアのDevEx(Developer Experience)を向上させる参考になれば幸いです。
ビジネスチャット「Chatwork」を提供する株式会社kubell(旧Chatwork株式会社)では、iOSDC Japan 2023で「SVVS」に関する発表を行いました。
あれから2年、Swiftの進化とともに、私たちの実装も大きく前進しています。
本セッションではその続編として、最新のSwiftを活用した「SVVS実装戦略」をお届けします。進化の過程で、私たちは以下のような課題に向き合ってきました。
・アプリ全体で有効なものと、ログイン中にのみ有効なもののライフサイクル設計
・CombineからObservationへの移行とその影響
・DIを用いたUIロジックの単体テスト手法
これらの課題に対するkubellでのアプローチを、具体的なコードの変遷とともにご紹介します。
月間4100万ユーザー、4.5億回再生を誇る民放公式動画配信サービス「TVer」。
そのiOSアプリ開発チームは、2023年のiOSDC登壇時はプロパーiOSエンジニア0人という状況からスタートし、2024年は1人、そして2025年現在は3人体制へと成長しました。
直近は体制を強化していくだけでなく、AI技術を使った業務効率化にもチャレンジしています。
本セッションでは、以下の実践的な事例をご紹介します。
実装・ソースレビューでのAI活用
実際のプロジェクトにおける仕様調整プロセスでのAI活用
Markdownベースの図表作成による劇的な時短効果
「実装でのAI活用は試しているけど、プロジェクト推進や仕様調整など、実装面以外での活用方法がわからない」という方に特におすすめです。明日から使える具体的なノウハウをお持ち帰りください!
『ホットペッパービューティー』のiOSアプリは、UIKitからSwiftUIへの移行を進めており、UIコンポーネントの実装と、単一画面ごとの実装とリリースにフェーズを分け、段階的に移行しています。このアプリは、9年前にObjective-CからSwiftへのリプレイス時にUIKitで実装され、現在では年間2億件近いサロン予約を支えるアプリです。
UIKitからSwiftUIへの移行と聞くと、単にプレゼンテーション層を書き換えて完了と思いきや、そう簡単な話ではありませんでした。
システムがモノリシックな構成であったため、Xcode Previewsの動作は重くSwiftUIの良さが活かせず、マルチモジュール化を進めました。
Figmaで定義されたUIコンポーネントとコードベースとの間には構造上の乖離があり課題でした。そこで、改めてデザイナーの意図が実装に反映され、再利用性が向上する形で各UIコンポーネントをSwiftUIで実装しました。合わせて、命名規則の統一、コンポーネント間の一貫性の担保、不足パターンの追加などデザインガイドラインの整備を行いました。
また、テストやデザインの受け入れなど、周辺の開発プロセスも軽視できません。Xcode Previewsを活用して、自動でスナップショットテストを作成し、UIカタログアプリを配布する仕組みを整えました。
さらに、既存仕様が必ずしも単純とは限りません。多面的なプロダクト仕様をいかに品質を落とさず置き換えるかという観点で、LLM(大規模言語モデル)を活用しました。
本セッションでは、UIKitからSwiftUIへの段階的な移行に関して、背景や目的、直面した課題と方針、コンポーネント実装と画面実装のフェーズ、デザインガイドラインの整備、Previewsを活用したテストやUIカタログの準備、さらにLLMの活用についてお話しします。
サイボウズの大規模組織向けグループウェア製品『Garoon』のiOSアプリは、初回リリースから約2年が経ち、10万人を超えるユーザーに利用されており、現在も活発に機能追加や改善が進められています。
そのような中で、リリース当初から親しまれてきたトップ画面が、だんだんとアプリ進化のスピードについていくことができなくなってきました。
WebViewで特定機能のページを表示する形になっていたため、他の機能まで遷移するのに手間がかかったり、ネイティブで新たな機能を追加しても導線の実装に苦慮したりといった課題を抱えていました。
そこで私たちは、ネイティブで作成した新しいデザインのトップ画面に置き換えることを決定しました。
今までの操作感や体験を損なうことなく、ユーザーがスムーズに移行できるような仕様を考えながら、段階的に移行を進めていきました。
最終的には、ロールバック率5%未満という数字で、多くのユーザーに受け入れられた状態で移行することができました。
このトークでは、Garoonモバイルチームが取り組んできた以下のトピックを紹介します。
このトークが、今後皆さんが大規模なUI刷新を行う際の助けとなれば幸いです。
ABEMAのiOS・Androidモバイルアプリ開発では、2020年頃からKotlin Multiplatform(KMP)の検証を開始し、段階的に導入を進めてきました。現在では、サービスの中心となる画面の多くの実装がKMPによって共通化されている状態になっています。
マルチプラットフォーム開発の選択肢としてKMPが注目される一方で、長期にわたり大規模なサービスで運用してきた事例は多くありません。本セッションでは、私たちのチームにおけるKMP導入と運用の約5年間を振り返り、以下のようなトピックについて具体的な事例を赤裸々にご紹介します。
KMPの導入を検討している方・実際に使われている方はもちろん、アプリ開発へのマルチプラットフォーム技術の導入に関心のある全ての方の参考になるように、具体的で実践的な事例をお話しします。
ウォンテッドリーは、「究極の適材適所によりシゴトでココロオドル人をふやす」をミッションとして、働く人全てに関わるプロダクトを開発しています。モバイルアプリは主にWantedlyアプリを展開し、求職者と企業の最適なマッチングを提供するサービスを提供しています 。
本セッションでは、弊社の開発現場におけるAIの活用状況についてご紹介します。エンジニアリングチームでは、開発効率の向上を目指し、AIツールや手法を日々の業務に取り入れています。
具体的には、コードの生成支援、レビュー補助、ドキュメント作成、さらには技術的負債の解消といった領域でAIを活用しています。これらの取り組みを通じて、AIが開発の様々な段階でどのようにエンジニアの業務を助け、プロセスを改善しているのか、その実態を概要レベルでお話しします。
本セッションを通じて、弊社の事業内容とともに、AIが開発現場にもたらす変化や、エンジニアリング組織がAIをどのように活用しているかについて、皆様に広くお伝えできれば幸いです。
あなたのiOSスキルを使って、もっと多くのユーザーにアプリを届けられたら、素敵だと思いませんか?本セッションでは、私たちがなぜKotlin Multiplatform(KMP)を選択したのか、どのように既存のスキルを最大限活用したのか、そして実際の開発で得られた貴重な学びを詳しくご紹介します。KMPにより、iOSとAndroidの両方で迅速かつ高品質なアプリを実現し、開発の可能性を大きく広げました。
クロスプラットフォーム開発に興味はあるけれども、iOS開発のクオリティを維持したい方に最適な内容となっています。ぜひご参加ください!
「外は暑いのにオフィスは寒い!」毎朝の服選びで失敗する問題を解決するため、ハッカソンで開発したクローゼットアプリにESP32を使った遠隔温度モニタリング機能を組み込みました。家にいながらオフィスの温度がリアルタイムで分かる機能です。
クローゼットアプリを作っていて気づいたのが、天気予報だけじゃ服装選びは完璧にできないということ。特に夏場、外は35度なのにオフィスは極寒の20度とか、もう何着ていけばいいか分からない。ハッカソンメンバーからも「私もオフィスのエアコンで凍えてる」「私も毎朝カーディガン持っていくか悩む」という声があがって、それならESP32でオフィスの温度を取得して、アプリに組み込んじゃえばいいじゃん!と思って実装しました。
技術的にはESP32にDHT11温湿度センサーを接続して、5秒ごとにFirebase Realtime Databaseへデータ送信。クローゼットアプリ側ではDatabaseReferenceの.observe(.value)でリアルタイム監視して、取得した温度データを服装提案アルゴリズムに組み込みました。ESP32側でハマったのがFirebaseの時刻同期問題で、NTPサーバーで時刻合わせしないとトークン発行でエラーになって2時間溶かしました。Firebase.reconnectWiFi(true)の設定で、オフィスのWi-Fiが不安定でも安定動作するようになったのは大きな発見でした。
アプリ側では温度によって服装提案を変える仕組みを実装。オフィス温度20度未満なら「カーディガン必須」、27度以上なら「半袖OK」といった具合に、外気温とオフィス温度の両方を考慮した提案ができるようにする予定です。IoTデバイスとモバイルアプリを連携させることで、身近な課題を解決したいです。
大学の授業で、現実世界のサバゲーをデジタルで再現するシステムを開発しました。ESP32の赤外線センサーで被弾を検知し、BLE通信でiOSアプリに即座に通知。SwiftUIで実装した画面上でリアルタイムに体力が減少する仕組みです。
開発のきっかけは「みんなでサバゲーがしたい、でも痛いのは嫌」という単純な動機でした。ESP32にIRrecvライブラリで赤外線受信機能を実装し、被弾検知時にBLEで"button"メッセージを送信。iOS側ではCoreBluetoothでBLE通知を受信し、@Publishedプロパティで体力を管理することで、撃たれた瞬間に体力ゲージが減る体験を実現しました。
実際に授業で複数人対戦を行った際の発見として、Bluetoothは障害物があっても意外と通信が安定していること、赤外線の直進性とBLEの回り込み特性により予想以上に戦略的なゲームプレイが生まれたことなどがありました。プレイヤーごとに異なるUUIDを設定することで、最大10人程度の同時対戦も可能です。
本セッションでは、Arduino(ESP32)側のBLEサーバー実装とiOS側のCoreBluetoothクライアント実装を中心に、ハードウェアとソフトウェアを連携させる際のポイントや、実際に遊んでみて分かった課題と解決策を共有します。今後はCore Locationによる位置管理機能の追加も計画しており、より本格的なレーザータグ体験の実現を目指しています。
iOSアプリ開発において、アプリのライフサイクルイベントは多岐にわたり、AppDelegateやUISceneDelegateのどのデリゲートメソッドがどのタイミングで呼ばれるのか、またそれぞれの適切な使い所について、混乱したり、意図しない挙動に悩まされたりした経験はありませんか?
本トークでは、起動から終了に至るまでのアプリの様々なライフサイクルイベントを網羅し、デモアプリを用いて各イベントで動作するデリゲートメソッドを視覚的に解説します。メジャーなものから見落とされがちなマイナーなものまで、それぞれのメソッドの正確な呼び出しタイミング、推奨される利用シーン、そして具体的な実装例を交えながら、明日からの開発に役立つ実践的な知識を提供します。このトークを通じて、iOSアプリのライフサイクルを深く理解し、より堅牢でパフォーマンスの高いアプリケーション開発を実現しましょう。
iOSアプリエンジニアとして、ビジネスやデザインの要望にただ従うだけになっていませんか?
iOSプラットフォームは我々の手で育てていくものであり、その中で「iOSらしさ」をどう守り、活かすかが重要です。
このLTでは、ガワネイティブやクラスプラットフォームによる開発が広まる中で、iOSアプリをあえてネイティブで作ることを提案・実現していくための考え方を紹介します。
「これがiOSの良さ」と言えるポイントを明確にし、プロダクトの方向性にiOS開発者として主体的に関わるきっかけになれば幸いです。
皆さん、iOSアプリ開発でTCAを使ったことはありますか?
正直、TCAってめっちゃ難しいですよね...
TCAはiOSアプリ開発において採用されることが多いアーキテクチャパターンの1つです。
単方向データフローにより処理の流れの処理の流れが追いやすく、またアプリの状態管理やコンポーネントごとのテストが実施しやすいという特徴がある一方、コードの書き方が独特で初期学習のコストが高く、規模が小さいアプリではオーバーエンジニアリングになりがちというデメリットもあります。
最近は勉強会や技術記事で取り上げられる機会も多く、また公式のチュートリアルも充実しているため、TCAを導入するハードルはかなり下がりました。
しかし、これらで触れている内容はあくまで「導入」や「コーディング」に関することであって、アプリの「運用・保守」に関する情報はあまり多くないように感じます。
最近はTCAを採用したアプリも多くリリースされており、私も複数のプロジェクトでTCAを使った新規開発や保守・運用を経験してきました。
実務でTCAを使った開発を行う中で、勉強会や技術記事などではあまり触れられていなかったTCAのメリット・デメリットは想像以上に多くありました。
このトークでは、私が実際にTCAを使ってみて率直に感じたホンネを皆さんと共有したいと思います。
アプリのアーキテクチャというものはコードの根幹を支えるものであり、一度決めると変更することはなかなかできません。
現在アーキテクチャ選定に悩んでいる人や、これからアプリ開発を行う人に向けて、このトークを贈りたいと思います。
jpg、 png、gifにwebp
画像の拡張子ってたくさんあるけど、どうしてたくさんあるんだろう??
そんな疑問を感じたことはありませんか?
大学院で画像処理を専攻した私が、なんとか20分足らずでその疑問を解消した気になれるよう解説いたします!!
最後に次世代フォーマットであるavifをiOSで表示させる実験をお見せします