iOSアプリエンジニアとして、ビジネスやデザインの要望にただ従うだけになっていませんか?
iOSプラットフォームは我々の手で育てていくものであり、その中で「iOSらしさ」をどう守り、活かすかが重要です。
このLTでは、ガワネイティブやクラスプラットフォームによる開発が広まる中で、iOSアプリをあえてネイティブで作ることを提案・実現していくための考え方を紹介します。
「これがiOSの良さ」と言えるポイントを明確にし、プロダクトの方向性にiOS開発者として主体的に関わるきっかけになれば幸いです。
皆さん、iOSアプリ開発でTCAを使ったことはありますか?
正直、TCAってめっちゃ難しいですよね...
TCAはiOSアプリ開発において採用されることが多いアーキテクチャパターンの1つです。
単方向データフローにより処理の流れの処理の流れが追いやすく、またアプリの状態管理やコンポーネントごとのテストが実施しやすいという特徴がある一方、コードの書き方が独特で初期学習のコストが高く、規模が小さいアプリではオーバーエンジニアリングになりがちというデメリットもあります。
最近は勉強会や技術記事で取り上げられる機会も多く、また公式のチュートリアルも充実しているため、TCAを導入するハードルはかなり下がりました。
しかし、これらで触れている内容はあくまで「導入」や「コーディング」に関することであって、アプリの「運用・保守」に関する情報はあまり多くないように感じます。
最近はTCAを採用したアプリも多くリリースされており、私も複数のプロジェクトでTCAを使った新規開発や保守・運用を経験してきました。
実務でTCAを使った開発を行う中で、勉強会や技術記事などではあまり触れられていなかったTCAのメリット・デメリットは想像以上に多くありました。
このトークでは、私が実際にTCAを使ってみて率直に感じたホンネを皆さんと共有したいと思います。
アプリのアーキテクチャというものはコードの根幹を支えるものであり、一度決めると変更することはなかなかできません。
現在アーキテクチャ選定に悩んでいる人や、これからアプリ開発を行う人に向けて、このトークを贈りたいと思います。
ベンチャー企業から有名ベンチャー企業への転職を成功させ、年収アップを実現した私の経験とそのコツについてお話しします。
まず、転職を考えた理由ですが、キャリアアップと年収の向上を目指していました。特に35歳を過ぎるとリーダー経験が求められることが多く、転職難易度が上がるため、若いうちに戦略を練ることが重要です。
私が転職を成功させたポイントは以下の通りです:
「技術スキルの向上」
Swift、Objective-C、そして最新のiOSフレームワークを使いこなすことができるようにしました。
特にSwiftUIやCombineなどの新しい技術を積極的に学び、プロジェクトに適用しました。
「問題解決能力」
チーム内でのコミュニケーションを重視し、問題が発生した際には迅速に対応しました。
例えば、アプリのパフォーマンスが低下した際には、コードの最適化とアーキテクチャの見直しを行い、パフォーマンスを30%向上させました。
「職務経歴書の見やすいフォーマット」
職務経歴書は、プロジェクトごとに成果を数字で示し、具体的なエピソードを交えて記載しました。
「面接官との想定問答」
面接官が求める人材や解決したい課題を事前にリサーチし、それに対する解決策を具体的なエピソードで説明しました。
「リーダー経験の積み方」
若いうちからリーダー経験を積むために、プロジェクトリーダーやチームリーダーの役割を積極的に引き受けること。
「会社の情報を洗い出すAIプロンプトの紹介」
転職先の会社がリモートワークに適しているか、出社が求められるかなど、自分に合った働き方ができるかをリサーチするために、AIプロンプトを活用しました(本番で詳細にお伝えいたします)
これらの戦略を駆使して、私は転職を成功させ、年収アップを実現しました。ぜひ参考にしていただきたいです!
In-App Purchases(以下IAP)のサービスを展開していると、様々な問題に遭遇することがあります。
例えば申請内容に不備があってrejectされてしまった、IAPの公開日時が設定できない、求められるアカウント権限が強すぎてやりたい操作ができない、App Storeでエラーが出ているがこれってユーザーに告知していいの、などなど。。。
これらの問題についていろいろ質問したいなぁと思っていたところ、運よくWWDC25に参加できることになりました。
また現地ではApp Storeのオフラインlabが開催されており、実際に参加し色々質問してくることができました。
ただ人気のlabのため事前登録が必要、labの時間は15分のみ、通訳もなく英語に自信がない、Apple Parkは初めていくので色々と不安な自分は色々と準備をしていくことになりました。。
このトークでは、App Store Lab参加までの準備や実際の様子、何を質問し何を得られたのかを共有をします。
labには何を準備していったら良いのか、現地labはどんな様子なのか、labでは何を得られるのか、皆さんのlab参加への一助になるような話ができればと思います。
ゴール:
・Appleのlabに参加するためにやっておいた方が良い準備がわかる
・実際のlabの様子を知り、labに参加する意欲が湧く
アジェンダ:
・何に困っていたのか
・App Store Lab参加のための準備
・labの実際の様子、得られた回答
対象者:
・labの様子や回答内容が知りたい方
・labに参加してみたいがまだ勇気が出ない方
ちょっとそこのあなた、「Swift 6の新機能を使いたいのにSwift Concurrencyの対応をしないとまだSwift 6にはできない」などと思っていませんか?
もしあなたがXcode 16をインストールしXcode CLI ToolsをXcode 16と設定してビルドできている時点で、実はもうSwift 6によってアプリをビルドできているのです。なぜなら、Xcode 16のCLI Toolsに同梱されるSwiftコンパイラバージョンはSwift 6だからです。つまり、あなたはすでにSwift 6の言語機能も使えるんです。
勘違いの原因として、デフォルトでlanguage-modeがSwift 5と設定されていることをSwift 5系でコンパイルしている、と勘違いしている可能性があるんじゃないでしょうか。またはPackage.swiftの最上部に書かれた// swift-tools-version: 5.x
をコンパイルするSwiftのバージョンと勘違いしているということはないでしょうか?
このLTでは、CLI Toolsの基礎、コンパイラバージョンとlanguage-modeの違い、それが提案されたSwift Evolutionのプロポーザルなどについて話します。
Liquid Glass、いいですよね。私もユーザーとして触ってみたいです。
Liquid Glass といえば、Flutter は独自のレンダリングエンジンで画面を描画しているため Liquid Glass を使えず公式も対応を見送っている、という話をご存知でしょうか。ということは Flutter を使っている限り「古い」見た目のアプリしか作れないのでしょうか?
、、と悲観的に見てしまうのはちょっと軽率です。
そもそも Flutter の UI に対する優先度はそこではありません。Flutter の UI に対する姿勢には「プラットフォーム標準」よりも優先したい要素があり、Flutter アプリ開発者にとって Liquid Glass の完全再現はそこまで求めるものでもなかったり、というかそもそも「Liquid Glass が使えない」にも語弊がありまして、、そんな話を 5 分間だけ好き勝手に話させてください!
AVFoundation は高機能なカメラアプリを作る上では欠かすことのできないフレームワークです。
AVFoundation は iPhone のカメラ関連のハードウェアと共に進化してきました。
本トークでは、時系列に iPhone のカメラ機能の進化を見ながら、 AVFoundation のカメラ関連の API がどのように変化してきたのかについて紹介します。
今後のカメラ機能の進化に備え、これまでの歴史を今一度振り返りましょう!
これまでアプリを開発したり、利用してきた方には自動更新サブスクリプション(Auto-renewable Subscription)は馴染みが深いと思います。
その名の通り、特定の期間中で自動で更新・課金されるもので、ユーザーがキャンセルしない限り、自動的に更新されるものです。
では、「非更新サブスクリプション」(Non-renewing Subscription)は聞いたことはありますでしょうか?
これもその名の通り、更新されない課金のことかなと想像ができると思います。
でもAppleの課金種別にはそのほかにも「消耗型」、「非消耗型」というものも存在します。
これらの課金も更新されない課金のように読み取れますが、違いは何になるのでしょうか?
また、自動更新サブスクリプションとの違いは「更新されないこと」だけなのでしょうか?
このトークでは、非更新サブスクリプションに焦点を当てて、他の課金種別とは何が違うのか、どういう時に使えば良いのか実際に運用した実績をもとにを探っていきます。
これからの課金サービス提供を検討する際の一助になれば幸いです。
ゴール:
・「非更新サブスクリプション」についての理解が深まる
・課金サービス提供時にどの種別の課金にすれば良いか判断材料を得ることができる
・「非更新サブスクリプション」での運用方法のノウハウが手に入る
アジェンダ:
・Appleの提供する課金種別について
・「非更新サブスクリプション」でできること・できないこと
・「非更新サブスクリプション」の運用について
・「非更新サブスクリプション」で提供するに適した課金サービスについて
対象者:
・課金サービスの提供を予定するエンジニア・非エンジニア
・課金種別が多すぎて違いがよくわからない方
・課金についてあまり詳しくないが興味がある方
「空間だからこそできる動画編集体験」を目指し、Apple Vision Pro上で直感的に操作できる動画編集UIをRealityKitとSwiftで実装しました。
トリム、プレビューなど従来は2D平面で行っていた操作を、空間上に拡張することで身体感覚と結びついた編集体験を実現しています。
本セッションでは、以下のような実装事例と工夫を、Vision Pro実機でのデモを交えて紹介します:
特に「視線・身体位置・奥行き」という空間コンピューティングならではの要素を活かしたUX設計とその技術的裏付けを解説します。
動画編集に限らず、空間UIで複雑な操作を扱いたい方や、Vision Proで直感的で没入感のあるツール設計を目指す開発者にとって有益な内容です。
SwiftでもProcessingのように気軽にクリエイティブコーディング作品を作りたい、そんな思いから作成したSwiftyCreativesライブラリについて紹介します。
このライブラリではMetalベースの独自レンダラーを実装しており、circle()やpush()など直感的なAPIを用いてiOS/macOS/visionOSアプリ上にリッチな2D/3Dグラフィックスを表示させることが可能になります。
本LTではSwiftyCreativesの設計思想とともに、このライブラリを用いたアート作品制作事例、そして公開アプリでの活用事例を紹介し、Swiftを用いたクリエイティブコーディングの可能性を提示します。
公開URL
https://github.com/yukiny0811/swifty-creatives
内容
・既存のMetalラッパーでは満足できなかった背景
・実際にこのライブラリを用いて作った作品を紹介
・コア設計について
・visionOS対応について
・Swiftでクリエイティブコーディングをすることの良さ
・公開アプリでの活用事例紹介
コード例
class MySketch: Sketch {
override func draw(encoder: SCEncoder) {
color(1, 0, 1, 1)
box(1, 1, 1)
push {
translate(5, 0, 0)
box(1, 1, 1)
}
}
}
struct ContentView: View {
var body: some View {
SketchView(MySketch())
}
}
Swiftには様々な文法があり、それらは明示的・直感的で読みやすいことに定評があります。
一方でSwiftの特定の文法を応用すると一見"奇妙"なプログラムも記述できます。
以下はコンパイルの通る正しいプログラムです。どの文法を用いているのか、どんな結果になるか、みなさんはわかりますか?
[1, 2][{ _ in }]
{String.init}()("a",10)
このような"奇妙"なプログラムにはSwiftの様々なテクニックが含まれており、解き明かすことで様々な発見を得ることができます。
このトークでは、一見"奇妙"なSwiftプログラムを複数個例示し、背景にあるSwiftの文法ルールや応用方法について解説していきます。
このトークを聞くことで、「そんな書き方ができたのか!」と、みなさんの普段の開発にも役立つ発見があることでしょう。
Apple から Swift-Java Interoperability への OSS コントリビュートを広く募っています。筆者が環境構築を行なった際に遭遇した事象から Issue を作成してレポートを行い解決に至った事例を紹介します。
Swiftは年々進化を続け、私たちiOSエンジニアに多くの便利な言語機能を提供してくれています。
しかしながら、普段Swiftを書いていて何気なく使っている言語機能がなんという正式名称なのかも知らないなんてことも多いでしょう。
このトークでは、私が日々の開発の中で「これは便利!」「Swiftらしい!」と感じているお気に入りの言語機能を発表します。
なぜそれらが好きなのか、どんな場面で役立つのか、現場での活用例やTipsも交えながら、短い時間でギュッとお伝えします。
Swiftの言語機能をもっと使いこなしたい方や、他のエンジニアがどんな機能を推しているのか知りたい方におすすめの内容です!一緒にSwiftの楽しさを再発見し愛でましょう!
SwiftUIを用いた宣言的UI開発における状態管理では、ライブラリを活用した巨人の肩に乗るアプローチや、独自実装を選択するアプローチなど、さまざまな選択肢が存在します。
本トークでは、コミュニティで広く適用されているTCA(The Composable Architecture)やMVVMとの比較を簡単に行いながら、Fluxのデータフローを実現するWebフロントエンドライブラリZustandを基にしたSwiftUI実装時の必要最低限のストア実装を紹介します。
Fluxデータフロー、SSoT(Single Source of Truth)を叶えるシンプルな選択肢の一つになれば幸いです!知見をお届けします!
こんな経験ありませんか?
C言語ライブラリのエラーコードをSwift.Errorとして扱えたら楽なのに...
C言語関数を使う際に必要なUnsafeMutablePointerを間違えた操作をしてクラッシュしてしまった...
その不満、関数にattribute(属性)を足すだけで、解決できるかもしれません。
上記の例ではエラーコードの宣言箇所にattribute((ns_error_domain(CustomError))を追加するだけでSwiftではErrorに準拠したCustomErrorとしてモダンに扱えます。
また、Xcode26から導入される__counted_byを使えばコンパイラレベルでC言語関数を安全に呼び出せることを保証できるかもしれません。
本トークでは、そんなSwiftの特徴であるモダンな文法やメモリ安全性を、attributeやannotationをたった1行付与することでCファミリーAPIに持ち込むユースケースを解説・紹介します。
実際の現場での導入事例やXcode26で利用できる新たなアノテーション(counted_by)の使い方を紹介しながら、「書き換えゼロのセーフティ向上」と「API が一気に Swifty になる爽快感」をお届けします。
世の中には、いつの時代も「有償機能を無料で使う方法」に溢れています。
そしてそれはiOSも例外ではありません。
筆者が個人開発をしていたとき、有償で提供していたソフトウェアをクラックされ、世界中に配布された経験があります。
iOSにおいては、レシート検証をすれば、または、レシート検証をしてくれるライブラリを使えば安心、という印象がありますが、果たして本当にそうでしょうか。
このトークでは、実際に課金バイパスを行うダイナミックライブラリの解析内容を交えながら、よくある課金バイパスとその対策を詳しく解説します。
WWDC25 と同時に映画『F1: The Movie』の予告編「Haptic Trailer」が公開され、 iPhone の Apple TV+ アプリで見ると映像に合わせてデバイスが振動し、まるでF1ドライバーになったかのような感覚を体験できると話題になりました。振動による力強いエンジンの再現には、多くの方が驚かれたことでしょう。
iOSエンジニアの皆さんなら、「この機能はどのように実現されているのか?」と興味を持たれたのではないでしょうか。調査の結果、新しい体験と感じられたこれは、1st PartyであるAppleにしかできない事...ではなく、我々3rd Party開発者にも利用可能な AVFoundation や Core Haptics のAPIで実現できることが分かりました。プラットフォームの能力を理解し、最大限に活用することは、優れたユーザー体験の創造において非常に重要です。紐解いていく過程も含めて詳細を共有しますので、皆さんが動画にプラスアルファをして素晴らしい体験を作るための参考になればと思います。
「ブラウザを誰かに見られるのってイヤだな」
と思ったことありませんか?
履歴やブックマークには、
「絶対に他人には見せたくないけど、自分には必要」
そんな黒歴史が潜んでいます。
深夜の勢いで検索した履歴…
ちょっと恥ずかしい趣味のブックマーク…
でもいちいちシークレットモードを切り替えるのは面倒だし、履歴自体は後で見返したい…
ブックマークにも登録したい…
かといってパスワードでロックするのは逆にあからさまに隠してる感があってイヤ…
そこで注目したのが iOS16から利用できるFocus Filterです。
集中モードに合わせて
といった「自然に見せない仕組み」を自作ブラウザで仕込んでみるアイデアです。
このLTでは
「履歴もブックマークも人には見せたくない。でも自分はいつでもアクセスしたい」
というわがままを Focus Filter でどう叶えるかを技術的に語ります。
Focus Filter自体、まだ活用例がほとんど知られていない機能です。
まだ誰も挑戦していない
Focus Filter × 自作ブラウザの世界を
一緒にのぞいてみませんか?
SwiftUIをメインで使っているプロダクトでは、デザイナーやPdMとのやり取りで誰もがこんな経験をしたことがあるのではないでしょうか。
👩💼: 「この機能、〇〇アプリみたいなUIにしてください!」
🧑💻: 「了解です〜!」
(実装中・・・)
🧑💻: 「iOS 15や16だとちょっと上手く動かないんですよね…」
👩💼: 「えっ、〇〇アプリではできてますよ?」
🧑💻: 「ちょっとやり方変えてみますね…(仕方ない、UIKitを使うか…)」
SwiftUIは年々進化していて、新しい表現力やインタラクションを作り出せる強力なツールです。しかし、多くの有名アプリではまだUIKitが使われており、デザイナーやPdMがそれらを参考にすることも多いです。その結果、SwiftUIだけでは再現が難しいUI表現を求められる場面がよくあります。
開発者は、UIViewRepresentableやUIViewControllerRepresentableを使ってUIKitを取り入れる選択を迫られますが、これによりSwiftUI本来の宣言的なスタイルや一貫した状態管理が崩れ、保守性や可読性に新たな課題が生まれます。
このLTでは、実際に「SwiftUIだけでは実装できなかったUI」や、「UIKitを使わざるを得なかったシーン」を例に挙げつつ、そのときに考えた工夫やトレードオフを共有します。たとえば、カスタムトランジションやインタラクティブなスクロール、特殊なジェスチャー処理など、現場でぶつかったリアルな壁を紹介します。
Swift は値型を中心とした言語です。値型を用いてコードを書くと、あるオブジェクトを変更したところ、別のオブジェクトも一緒に変更されてしまった!のような意図しない変更を防ぐことに繋がります。
では、Swiftにおける値型と参照型の違いはなんでしょうか。上記のようなオブジェクトの振る舞いから説明する人もいるでしょう。公式ドキュメントを確認すると、値型は、変数や定数への代入、または関数への引数渡しのときに、値がコピーされる型であると定義があります。一方で参照型は、変数や定数への代入、または関数への引数渡しのときに、コピーされるのではなく、インスタンスへの参照が使用される型であると記載があります。
さて、WWDC24「Consume noncopyable types in Swift」の動画の中で、以下のような言及があります。
「Notice how copying worked the same in both cases. The only difference is whether you're copying a value, or a reference.」
「どちらの場合も(struct も class も)、コピーの動作は同じでした。 唯一違う点は、値をコピーするか、参照をコピーするかという点です。」
あれ?!値型と参照型のコピーの動作って同じなの?!
公式ドキュメントに、参照型はコピーされないって書いてたよ?
一体、どっちが正しいの?!
このLTは、公式ドキュメントとWWDC24のセッション動画との表現上の対立の謎に迫り、そして真理を求める人間が、Swiftの内部実装を紐解きオブジェクトのコピーとは何かを理解することに自らの信念と命を掛けた物語です。「コピーとは何か?」を突き詰めることで、改めて値型と参照型のそれぞれの内部動作の違いに迫ります。