メモやファイルなど、いくつかのApple純正アプリに搭載されている「マークアップ」機能を利用したことはありますか?
マークアップ機能を用いることで、色・太さなどを自由に操作しながら書類に書き込みを行うことができます。
PencilKitは、マークアップ機能をアプリに組み込むためのフレームワークです。
マークアップ機能に搭載されている以下のような機能は、すべてPencilKitを使うことで実装することができます。
本トークでは、実際に開発したPDFファイルへの手書き注釈を題材に、以下のポイントについて学んだことを発表します。
これらの内容を通じて、PencilKitを用いた実践的なPDF注釈機能の実装方法を詳しく解説します。
チャートはデータの傾向をビジュアルで理解できるため、とても便利です。しかしながら、視覚的に表現されたチャートは目で見る必要があり、視覚障がい者や弱視の人にとっては利用が困難です。チャートが持つたくさんの情報を適切に受け取れないユーザーがいることはコンテンツ提供者側として避けたい事象です。
Apple の API にはオーディオグラフ(Audio Graph)やチャートを説明 (Describe Chart) させるための機能が提供されています。オーディオグラフは視覚的なチャートの情報を音の高低で表現し、Voice Over で読み上げさせることができます。また、チャートの詳細 (Chart Details) を使用すれば、チャートの重要な特徴や傾向を言葉で説明することができます。これらの機能により、視覚に不自由のあるユーザーもチャートの内容を理解することができるようになります。
本トークでは以下の内容をお話しします。
参加者は誰もが利用できるリッチでアクセシビリティの高いチャートを作成するための知見を深め、自分たちのコンテンツに適用していくことができます。
医療アプリの開発においては、患者の安全と利便性の向上が最重要課題となります。一方で、医療制度の変更への迅速な対応や新規機能の実装など、高い生産性も求められます。この2つの要件は相反するものですが、その両立は避けられない課題です。
本セッションでは、メドレーのオンライン診療・服薬指導アプリ「CLINICS」の開発を通じて、いかにして安全性と生産性の両立に取り組んでいるかをご紹介します。
・診療報酬改定などの制度変更に柔軟に対応できる体制
・SPMマルチモジュール、トランクベース開発など生産性向上の工夫
・MagicPodを活用した自動テスト環境での効率的な品質確保
・法律・ガイドライン・制度対応や社内他部門との連携を含む総合的なアプローチ
医療アプリの開発は技術的側面のみならず、適切な規制対応や組織間調整など様々な課題に直面します。本セッションでは、そうした課題への具体的な取り組みをご紹介しつつ、品質と速度の両立に向けた実践的な知見をお話しします。
医療×テクノロジーの最前線で得られた学びを、皆様の開発にも活かしていただければ幸いです。
2024年4月、ANDPAD黒板でオフラインモード機能の提供が開始されました。
これまで、山間部・僻地や地下といった電波の届きにくい場所での工事においては、アプリが十分に利用できない状態でした。特に、電波の届きにくい場所における工事関係の写真撮影に対するニーズは高く、この課題に対処すべく開発されたのがオフラインモード機能です。
オフラインモード機能は大きな機能のため、昨年末から2つのプロダクトチームのメンバーが協力して開発を進めてきました。開発中には様々な課題に直面し、その度にメンバー全員で知恵を振り絞って課題を解決しました。
本セッションでは、そんなANDPAD黒板のオフラインモード機能開発の経緯から、開発の詳細、開発時に遭遇した問題に対してどう解決したのかについてご紹介します。また、開発を通じて得られた iOS 開発に関する知見についてもご紹介します。
newmoは今年の1月に設立された新しい会社です。"移動で地域をカラフルに" をミッションに掲げ、利用者視点に立ったサステナブルな地域交通の実現を目指すスタートアップです。
newmoではAPIのスキーマ定義に、より多くの情報を記述する宣言的なアプリケーション開発を行っています。スキーマからコードを自動生成することで、APIの挙動が理解しやすくなると同時に、各チームが主体的・自律的に開発が進められる状態を実現します。
モバイルアプリとバックエンドAPIとの通信にはGraphQLを採用しました。ディレクティブを活用して、APIクライアントの生成に留まらない、より宣言的なアプリケーション開発を行っています。
本セッションでは、より安全に、高速にiOS開発を進めていくための弊社の取組みをご紹介します。
SwiftDataはCore Dataの後継としてリリースされたAppleの新しいデータ永続化フレームワークです。SwiftDataはCore Dataよりもはるかに簡単で安全に使うことができますが、Swift Concurrencyとともに利用する際はデータ競合に注意が必要です。これは、SwiftDataがCore Dataの上に構築されたAPIであるためです。
そこで本トークでは、SwiftDataをSwift Concurrencyと共に安全に扱う方法を解説します。SwiftDataをこれから利用する方やCore DataでConcurrencyの扱いに苦労した経験を持つ方を主な対象とします。SwiftDataの技術スタックをSwift Concurrencyの観点およびSwiftDataの元であるCore Dataの観点から解説し、SwiftDataを並行安全に扱うための原則、ならびにコーディングにおけるベストプラクティスを紹介します。
本トークによって、参加者の皆さまはSwiftDataをより自信を持って扱えるようになるでしょう。
結婚したことでパートナーが持っていた電子ピアノが我が家にやってきました!
電子ピアノといえばガジェット!ピアノ未経験とはいえ、エンジニアとしてはこれは触ってみるしかない!
ということで、ピアノ経験者監修の電子ピアノと連携するiPadアプリを実装しました
この電子ピアノはMIDIという規格を通して他のデバイスへ叩いた鍵盤の情報などを連携することができます
今回はこのMIDIをSwiftから利用し、その情報を表示するアプリの実装の概要について紹介します!
具体的には…
発表では実装したアプリが実際にピアノと接続しながら動く様子をお見せします!
この発表を通して、電子楽器とアプリ連携の世界に一歩足を踏み出してみましょう!
またこのデモの中でピアノ完全未経験の発表者がどれほどピアノが上手く弾けるようになっているかにも注目です
SwiftのData型はバイナリデータを扱うための型です。
RandomAccessCollectionなどの便利なプロトコルに準拠しているおかげで、気軽にバイナリデータの読み書きができます。
でも「ほぼUInt8の配列でしょ」と思っているとそんなことはなく、Data型にしかない、面白くも「あぶない」特徴がいくつかあります。
それらを知らないとプログラムをクラッシュさせてしまうこともしばしば。
コードレビューでこの関数をLGTMしてしまいそうになったら、ぜひこのトークを聴いてください。
func getUInt32(from data: Data) -> UInt32 {
switch data.count {
case 0:
return 0
case 1:
return UInt32(data[0])
case 2, 3:
return UInt32(data[1]) * 256 + UInt32(data[0])
default:
return data.withUnsafeBytes { $0.load(as: UInt32.self) }
}
}
Swiftが好きだけど何もわからん。自分よりSwiftを愛してて詳しい人ばかり。つらい。
Swiftコンパイラを勉強しようとして返り討ちにあった方は多いでしょう。どこから手をつけるとよいかもわからん!
「型推論ハンズオン」[omochi 2019]はSwiftの型推論にフォーカスして学ぶ合宿用ハンズオンです。未実装の部分に正しいコードを書いて型推論器を完成させ全テストをパスできたらクリアです。SwiftSyntaxを使った本物そっくりの言語が題材で、Swiftを理解したい私にはありがたい教材です。
私は「Swiftの型推論を学ぼう」[omochi 2024]を聞き、発表の元ネタであるというこのハンズオンで勉強することにしました。合宿は5年前に終了しているため1人で挑みます。
あれ?ハンズオン壊れてるよ?テスト通すどころかハンズオンをコンパイルできなくて挑戦できないよ??
果たして私は5年前のハンズオンをSwift 5.10に対応させSwiftの型推論を†完全理解†できるでしょうか?
話すこと
ジオフェンスとは、特定の地理的エリアにデバイスが入ったり出たりしたことを検知できる仕組みです。
iOSでは、中心の緯度経度と半径を指定するだけで簡単にジオフェンスを設置できます。この機能はアプリを起動していなくても検知が可能で、アイデア次第で便利なサービスを提供できます。
しかし、iOS/Android両方開発してみると、各OSごとの挙動の違いがあったり、確認方法にも工夫が必要です。
今回のトークでは、ジオフェンス機能をiOS/Androidの両OS対応した際の経験をもとに、以下のポイントについて詳しくお話しします:
・ ジオフェンス機能の仕様の違い
・ デバッグの際の工夫とTips
・ 開発時に苦労したこと
UndoManagerは、アプリにUndo・Redo機能を提供してくれる強力なクラスです。
特にnote アプリのようなエディタアプリにとって、Undo機能は必須の機能の一つといえます。
しかし、意外とUndoManagerを使いこなしているアプリは少ないのが現状です。
本トークでは、UndoManagerの基礎から、実際のアプリへの導入方法、そしてその際のはまりポイントまで、実体験に基づいて解説します。
[内容]
一緒にUndoManagerをマスターし、アプリのユーザー体験を次のレベルへ引き上げましょう!
WWDCに行くためには多くの壁が存在します。航空券、入国審査、言語、治安、飯が合わない、などなど。やらないとそもそもアメリカ入国もアウトになるものもあれば、ハックすればより自分の旅が快適になるものもあります。また、限られた予算内でどう頑張って渡航するかも重要になります。いろいろと山積みで頭を抱えますよね?
皆さん、大丈夫です。ここに経験者がいます。入国審査のときに審査官に嘲笑され、タイムズスクエアで屈強なアニキに囲まれCDを買わされ、「お前の英語よくわからん」とドライバーに無視され、かの遠い地で日本を懐かしみ枕を濡らした経験のあるのは、この男!安い航空券を取るという特技だけでなく、多くの失敗をアメリカで学んだ男が、今年のWWDCをたのしみつつ、どうハックしてアメリカツーリズムを乗り越えたか。めくるめく5分間で話していきます!
もちろん、来年からWWDCに行く人のためになったり、すでにWWDCに行った人にもプラスになる情報が盛り沢山!ぜひご覧ください
あ、WWDCに行けるかどうかのハックはありません、運です。
シングルトンはGoFのデザインパターンのひとつ。
インスタンスがひとつしか存在しないことを保証したもの。
しかし、とある日、確実に正しいコードのシングルトンなのに、その状態が共有されていないことに気づいたのです。
おかしい、そんなバカな、そう思いながら、恐る恐るシングルトンのインスタンスのメモリアドレスを確認しました。
違うんですよ、アドレスが…
このトークではコードは間違いなく正しいにも関わらず、シングルトンのインスタンスが複数作られてしまう怪奇現象について、iOSのビルド設定の観点から説明します。
あなたのシングルトンは本当にひとつですか...?
皆さんは昨年のiOSDCのロゴは覚えていらっしゃるでしょうか?
同心円とその中心から放射状に伸びる線から構成され、色が塗られている箇所と塗られていない箇所に分かれたあのロゴマークです。
(参照:https://iosdc.jp/2023/)
このデザインを見たときに、ふと思った方もいるのではないでしょうか?
「このデザインには意味があるのではないか?」
「何か隠されたメッセージが潜んでいるのではないか」
と。
かくしてロゴに秘められているであろうメッセージを解読しようと試行錯誤する日々が続いたのです。
仕事の合間に。そしてレギュラートークの準備の合間に。
そしてiOSDC Japan 2023の最終日、ついに私は真実に辿り着くことができました。
本LTではそこに辿り着くまでの試行錯誤と、このLTのために丸一年秘密にしていたロゴに関する真実をお話します。
私はiOSアプリの多言語化対応において、LinterをRubyで自作して書きました。
本セッションでは、そのLinterを汎用化したGitHub Actionsに進化させ、Marketplaceに公開して使えるようにするまでをお話します。
といってもまだ公開しておらず、もしこのセッションが採択されたら公開に向けて動きます。そうです、登壇駆動開発です。その時間経過も含めてLTらしく話します。
真面目な話をすると、意外と自作で色々スクリプトを作っているiOSプロジェクトは多いんじゃないかと考えており、それらOSSのタネが開花するきっかけになるとよいなと考えています。
SFSpeechRecognizerは音声認識を利用して音声をテキストに変換することができます。
この技術を活用して、視聴者のデバイス上で完結する自動字幕起こし機能を実装しました。
本セッションでは、その過程で直面した課題とその解決方法について共有したいと思います。
紹介トピック
手塩にかけて育てたミュージックライブラリがぶっ壊れた経験はありますか?私はあります。
5年前、OSX Catalinaの登場時にiTunesが廃止され機能ごとにアプリが分かれました。
その後、新しいミュージックアプリでは様々な問題が起こりました。
(※全部筆者が経験したことです)
万単位にのぼる楽曲を1個1個精査して正しい状態に復旧するのは当然ながら非現実的です。
更にミュージックアプリの使い勝手の悪さも相まって泣き寝入りを余儀なくされました。
ですが、そこに救世主が現れました。そう、 ScriptingBridge
です。
しかし ScriptingBridge
はObjective-CがベースなのでSwiftで扱うには一工夫が必要です。
本セッションでは、macで他アプリケーションと連携するための仕組みである ScriptingBridge
を使ってミュージックライブラリから楽曲情報を取得・編集する方法と、それによって壊れた楽曲情報を半自動で復旧した話をします。
「Vimは設定している時が一番楽しいんだよ(ウホーレン)」
有名なテキストエディタのひとつに「Vim(ヴィム)」があります。
私はVimが好きです。もっというとVimから派生した「Neovim(ネオヴィム)」が大好きです。
私はNeovimを使ってiOSアプリ開発できないか、日々模索しています。
Microsoftが公開している「LSP(Language Server Protocol)」や「DAP(Debug Adapter Protocol)」などのプロトコルを使い、かなりいい感じにコーディングできるようになってきました。
NeovimにはLSPやDAPのクライアントプラグインが存在します。
それを使うことで、Appleが公開している言語サーバー(SourceKit-LSP)や、サードパーティ製のLLDB拡張(CodeLLDB)をNeovimから呼び出して使えます。
つまり、Neovimで補完やシンタックスハイライト、ブレークポイントを貼ったデバッグなどが可能になります。
本LTでは、まず私のNeovimによるSwiftのライブコーディングをお見せし、次にそれを実現するための技術をキーワードベースで紹介します。
「必要なものはvimrcだけだったのです。必死に積み上げてきたvimrcは決して裏切りません(ウェルン)」