モジュールの視点からSwiftを読み解く #iosdc

https://fortee.jp/iosdc-japan-2026/proposal/08515687-40e9-4fed-adb4-f7b99bc02a93

1. iOSDC Japan 2026 モジュールの視点から Swift を読み解く S_Shimotori
2. @S_Shimotori_pub みんなの書いた大量のSwiftをひとつのバイナリにする係 SwiftのきもちになってSwiftを書けると楽しい パンフレット記事『Swift Concurrency考古学のすすめ』 読んでね！ 1
4. 本トークで学ぶこと 今日はこれを学びます！ モジュールとは何かをなんとなく 「見かけたことはあるけれど使いかたがわからない言語機能」の真相 今日のゴール！ モジュールに少し詳しくなって、Swiftを自信持って読み書きできるようになる！ 3
5. 本日のコンテンツ モジュール @unknown default 暗黙の Sendable 最適化と @inlinable と @usableFromInline ｢import して使える｣ とは swiftinterface について詳しく 4
6. 本日のコンテンツ モジュール @unknown default 暗黙の Sendable 最適化と @inlinable と @usableFromInline ｢import して使える｣ とは swiftinterface について詳しく 5
7. そもそもの話 モジュール 6
8. Swift におけるモジュール モジュールは､ コード配布の単位で､ 単体で構築および配布され､ import キーワードを使用して別のモジュールによってインポートできる フレームワークまたはアプリケーションです。 by TSPL日本語版 import xxx の xxx に書けるものがモジュール｡ たとえば： Xcode上で見かけるフレームワーク、アプリケーション Package.swift に書いた targets: [...]たち 7
9. よく聞くワード：マルチモジュール構成 1つのアプリを作るために、複数のモジュールへ小分けにして開発する モジュールごとに違う設定を入れて徐々にConcurrency対応する + モジュールごとにキャッシュを効かせてビルド速度を速くする それぞれのモジュールを別々に扱う､ 異なるタイミングでコンパイルする 責務ごとにモジュールを分けたうえで疎結合にする open/public な API はきちんと設計する マルチモジュール構成が知りたい人はこちらへ： iOSDC Japan 2021 大規模なアプリのマルチモジュール構成の実践 by ぎぎにゃんさん iOSDC Japan 2026 巨大モノリシックアプリ モダ ン化大作戦 by Ryomm さん 8
10. ここまでのまとめ これだけ知っておけば大丈夫！ モジュールとはimportできるもののこと 各モジュールは別々に扱われるかも public APIは他の人のことを考えて真面目に設計して実装しよう 9
11. 本日のコンテンツ モジュール @unknown default 暗黙の Sendable 最適化と @inlinable と @usableFromInline ｢import して使える｣ とは swiftinterface について詳しく 10
12. ケース 1 @unknown default 11
13. UNAuthorizationStatus import UserNotifications // UserNotificationsモジュールを使用 let settings = await UNUserNotificationCenter .current().notificationSettings() switch settings.authorizationStatus { case .notDetermined: /* すきなように */ case .denied: /* 結果に応じた */ case .authorized: /* 処理を */ case .provisional: /* 書こう */ case .ephemeral: /* ！！！ */ } 12
14. なんかエラー出た ※Swift 6 言語モードの場合 error: switch covers known cases, but 'UNAuthorizationStatus' may have additional unknown values, possibly added in future versions note: handle unknown values using "@unknown default" 意訳 将来追加される未知の値に対応できてないからエラーにするよ。 @unknown defaultで対応しよう！ 13
15. 言われるがままに修正する import UserNotifications // UserNotificationsモジュールを使用 let settings = await UNUserNotificationCenter .current().notificationSettings() switch settings.authorizationStatus { case .notDetermined: /* ... */ case .denied: /* ... */ case .authorized: /* ... */ case .provisional: /* ... */ case .ephemeral: /* ... */ + @unknown default: /* 言われるがままにこれを書き足す…… */ } 14
16. 解答編 15
17. なぜ"possibly added in future versions"と言われるか 新しく追加されたUNAuthorizationStatusの値が 古いアプリに渡されるケース UNAuthorizationStatusの事例： iOS 14 で新しいステータス ｢case ephemeral｣ が増えた！ 16
18. 毎夏の恒例行事 iOS 14 へのアップデート前 OS 同梱の UserNotifications iOS 13 までを想定して作ったアプリ // iOS 13 import UserNotifications enum UNAuthorizationStatus { case notDetermined case denied case authorized case provisional switch settings.authorizationStatus { case .notDetermined: /* ... */ case .denied: /* ... */ case .authorized: /* ... */ case .provisional: /* ... */ } } 17
19. 毎夏の恒例行事 iOS 14 へのアップデート完了！ OS 同梱の UserNotifications // iOS 14 enum UNAuthorizationStatus { case notDetermined case denied case authorized case provisional + case ephemeral } iOS 13 までを想定して作ったアプリ import UserNotifications switch settings.authorizationStatus { case .notDetermined: /* ... */ case .denied: /* ... */ case .authorized: /* ... */ case .provisional: /* ... */ } 17
20. 依存モジュールとアプリの間に情報格差があるかも iOS 14が入ってるiPhone： iOS 14 に App Clip が導入された ユーザの選択次第でステータスが.ephemeral になる可能性がある｡ iOS 13で作ったアプリ： まだ iOS 14 対応していない or アップデートやめた case ephemeral のことは全く知らない｡ switch 文にも書いてない｡ 18
21. .ephemeral はどこに行けばいいんだ？？？ iOS 14 対応が済んでないアプリには case ephemeral がない import UserNotifications switch authorizationStatus { case .notDetermined: /* ... */ case .denied: /* ... */ case .authorized: /* ... */ case .provisional: /* ... */ } Objective-C の enum なのでクラッシュ｡ 19
22. @unknown defaultがあれば安心！ 未知の値が来ても対処できる！ import UserNotifications switch authorizationStatus { case .notDetermined: /* ... */ case .denied: /* ... */ case .authorized: /* ... */ case .provisional: /* ... */ + @unknown default: /* ephemeralを受け取ってごまかす！ */ } 20
23. 補足：実際のところ .ephemeral のせいで意図しない動作をすることはない iOS 13 以前のアプリには App Clip が存在しないのでこいつも飛んでこない 同じ理屈で､ Apple Glass 仮 ができて UIUserInterfaceIdiom に 新しいものが増えても既存のアプリに影響はないはず きっと互換モードで動いて既存の値が渡されるよたぶん 21
24. @unknown default を書かされるとき Objective-C 定義の enum の場合： NS_ENUM を使って定義したもの 大多数の enum はこれ！ Swift 定義の enum の場合： Library Evolution モードを有効にすれば出る SwiftUI は Swift 実装かつ Library Evolution 有効 他にも C 言語の場合とか SE-0487 とかある 22
25. Library Evolution とは モジュールの作者がモジュールに対して設定できるモード あとから新バージョンに差しかわる前提で話を進めるようになる これがあれば SwiftUI だけを iOS 27 にアップデートしても安心！ 具体的な効果 あとから差しかえる前提でモジュールが生成され､ 動作する あとからアップデートされる前提での利用をアプリ側にうながす 例：@unknown default で未知の値を処理するよう強制する 23
26. アップデート予定のない enum まで警戒するのはめんどい！ 「アップデートで差しかわるかも」という警戒を解いて楽をしたい！ 未来永劫変えるつもりのないenum、structには@frozen属性をつける 具体的な効果： @unknown default を要求されなくなる 処理が遅くならない 24
27. SE-0192 と SE-0260 と SE-0487 の違い SE-0192 Handling Future Enum Cases (Swift 5.0) このころはまだfrozenの設定手段が限定的だったみたい SE-0260 (Swift 5.1) Library Evolution有効時に出まくるようになった 目的はバイナリ互換性 SE-0487 Nonexhaustive enums (Swift 6.3.2) @nonexhaustive の導入 目的はソース互換性 25
28. Objective-C製enumも@unknown defaultを止めたい！ NS_CLOSED_ENUMを使う 「後からcaseを足しません」の意思表示 26
29. @frozen ってつけたのにあとから case を足したらどうなるか バイナリ互換性を破壊する行為だがモジュールのコンパイル自体は通る モジュールを差しかえて新規追加したcaseを渡すとcaseの1つ目に行くなどする swift-api-digesterで新旧のabi.jsonを比較すれば検知可能 27
30. @unknown default から学べること Swiftはアプリをリリースしたあとのことも考えている Swiftをすみずみまで理解するにはアプリをリリースしたあとのことも 知っておくとよい 「OSアップデートの際にモジュールだけ差し変わる」は便利だけど、 ちゃんと理解して備える必要がある 部分的に差しかえられるのはモジュールのおかげ 28
31. 本日のコンテンツ モジュール @unknown default 暗黙の Sendable 最適化と @inlinable と @usableFromInline ｢import して使える｣ とは swiftinterface について詳しく 29
32. ケース 2 暗黙の Sendable 30
33. 突然ですが ここでクイズ！ 31
34. Swift Concurrency の問題です！ 非隔離の struct が Sendable って書かなくても勝手に Sendable になるときって どんなとき？ 答え： その struct が internal 以下で､ プロパティも Sendable なとき！ 32
35. 正確な答え プロパティが Sendable かつ、 勝手にSendableにしても他のモジュールに直接の影響がないもの 他のモジュールから import して使う struct を Sendable にするかどうかは 自分で責任もって判断しましょう｡ 33
36. あとから非 Sendable になっちゃうとめんどい！ Sendable として運用するつもりのなかった struct かも あとからうっかり非 Sendable プロパティを足しちゃうかも…… public struct MyStructure { + var value: NonSendableValue } var s = MyStructure() await doOnAnotherActor(s) s.doSomething() error: sending 's' risks causing data races [#SendingRisksDataRace] 34
37. あとからプロパティが増えないとわかっている struct なら… あとから stored property プロパティが増えないなら､ あとから非 Sendable にひっくり返されることもない 暗黙的に Sendable にしても import された先で問題を起こさない！ 例えば @frozen public struct とか｡ 35
38. 暗黙的な Sendable？ いろんな struct 暗黙的に Sendable にしていい？ internal 直接の影響はないから OK public 安易な Sendable 化はリスク高い @frozen public あとから変更しないから迷惑かけない @usableFromInline internal ？？？ 36
39. 暗黙の Sendable から学べること Swiftはモジュール同士の責任や関係性も考えて言語機能を決めている これらの知識でマルチモジュール構成への理解が深まる……かも？？ モジュールの話が巡り巡って Swift Concurrency の仕様にも影響している 37
40. 本日のコンテンツ モジュール @unknown default 暗黙の Sendable 最適化と @inlinable と @usableFromInline ｢import して使える｣ とは swiftinterface について詳しく 38
41. ケース 3 最適化と @inlinable と @usableFromInline 39
42. そもそも：最適化とは 効率のよいプログラムを生成すること Swift コンパイラが自動的に工夫してやってくれる プログラムのサイズを小さくする 実行したときにかかる時間を短くする 最適化の参考にできる情報があるとよい よそのモジュールの情報も知ることができたらうれしい 呼び出す対象の関数が具体的に何をしているか、など 40
43. @inlinable 関数や計算プロパティなどに設定できる属性 実装を別のモジュールに公開して､ 最適化をするときに参考にしてもらう 公開することでできる最適化の手法 インライン化 特殊化 ほかにもいろいろあるみたいetc 41
44. @inlinableとはいうけれど 名前こそ"インライン"だが､ 必ずインライン化されるわけではない 実際どんな最適化をするかはオプティマイザ次第 特殊化などの別の最適化手法が行われる可能性もある 42
45. 実装を公開して最適化に役立ててもらおう！ Array や swift-algorithm でよく見られる public struct Container<Value> { private let value: Value public func calculate() -> Int { value.doSomething() } } 43
46. インライン化 calculate() の呼び出しコストを削減できる が､ 中身の value がよそのモジュールに丸見えになっちゃう！ let container = Container(/* ... */) let answer = container.calculate() + container.value.doSomething() 44
47. @inlinable なものから使っていいもの open または public なもの @usableFromInline 属性をつけた internal インライン化された先のモジュールから呼ばれるのは許す それ以外のケースで好き勝手に使われたくない 45
48. @inlinable と @usableFromInline の設定例 public struct Container<Value> { @usableFromInline internal let value: Value @inlinable public func calculate() -> Int { value.doSomething() } } 46
49. 暗黙的な Sendable？ いろんな struct 他のモジュールに 影響ある？ internal ない public ある @frozen public ない 仕様が変わらない @usableFromInline internal ある インライン化された先で 使われる 暗黙的に Sendable になれる？ 47
50. Q. マクロとどう違うの どこかにソースコードを展開するという手段？結果？は似ている…かも……？ 目的や対象は全然ちがうよ｡ マクロ： 複雑な処理を何度も手書きするのがめんどいので､ 楽するために使う インライン化： 単純で何回も行う処理の関数呼び出しコストをちまちま削る感じ 大きい関数をインライン化するのは逆に重くなりそう､ サイズが 48
51. @usableFromInline から学べること 最適化やモジュールの話がめぐりめぐって Swift Concurrency の仕様へ影響している あせらず少しずつ勉強していきましょう……！ internal なものも時には他のモジュールから使える､ 影響を与えることがある 49
52. 本日のコンテンツ モジュール @unknown default 暗黙の Sendable 最適化と @inlinable と @usableFromInline ｢import して使える｣ とは swiftinterface について詳しく 50
53. 発展 ｢import して使える｣ とは 51
54. import したモジュールの中の関数を使う 一般的な理解：import をしても internal 以下のものは使えない internal アクセスにより､ エンティティを定義するモジュールの任意のソース ファイル内で使用できますが､ そのモジュールの外部のソースファイルでは使用 できません｡ by TSPL 日本語版 実際のところ… @usableFromInline internal のものが最適化の一環で使える @testable import すると internal のものが呼べる､ テストできる 52
55. モジュールの現物を見てみよう！ ファイル名 何者？ SwiftUI.framework/ 入れ物 SwiftUI.tbd モジュールの核のハリボテ ◯◯.swiftinterface ↑ には target triple が入る 取扱説明書 兼 カタログ 53
56. ライブラリ モジュールの核 "モジュールの核"とは言っているが要はライブラリのこと 本トークでは動的ライブラリdylibの話をしています .tbdはtext-based descriptionのこと リンク時はシンボル情報のみを持つ軽量なyamlでじゅうぶん足りる （frameworkはXcode同梱のものとiOS同梱のもので中身が違う） 54
57. import したモジュールの中の struct や関数が使える条件 モジュールの核（SwiftUI.tbd）が、対象を他モジュールから利用可能にしている アクセス修飾子の区別なく、外部から使えるか、使わせないか、ただそれだけ AND "取扱説明書 兼 カタログ"の記載通りの使いかたを守る アクセス修飾子の制限をかけているのはこちらのファイル 自由に呼べるのは public 以上 @usableFromInline internal を使えるのは最適化のときだけ @testable import が許されているかどうかも書いてある 55
58. 余談：SwiftUI は @testable import できない SwiftUI.framework 生成時に Apple がテスト機能を有効化しなかった その結果､ モジュールが @testable import できるように作られない @testable import SwiftUI error: module 'SwiftUI' was not compiled for testing [#ModuleNotTestable] 56
59. ここまでで一旦まとめ モジュールは主に2つのファイルから成り立っている モジュールの核となるファイル 取説兼カタログの役割を果たすファイル アクセス修飾子や属性による利用制限を指示しているのはこっち 57
60. 本日のコンテンツ モジュール @unknown default 暗黙の Sendable 最適化と @inlinable と @usableFromInline ｢import して使える｣ とは swiftinterface について詳しく 58
61. オマケ swiftinterface について詳しく 59
62. "取扱説明書 兼 カタログ" .swiftinterface以外にもいくつかの形式がある ひとつの"モジュールの核"に対して複数の"取扱説明書 兼 カタログ"を用意できる 複数ある場合はその中から適切なものを選んで使う 60
63. 2 種類の"取扱説明書 兼 カタログ" . .swiftmodule .swiftinterface 生成方法 デフォルト 要フラグ 形式 バイナリ テキスト 有益な情報の量 たくさん 少ない 互換性 違うコンパイラから読める？ のようなエラーが出る error: module compiled with Swift 6.3 cannot be imported by the Swift 6.4 compiler 61
64. swiftinterface ファイル "取扱説明書 兼 カタログ"の一種 バージョンが違っても読める！そのかわり互換性はない 人間による読み書きがしやすいテキスト形式 書き換えてしまえば、アクセス修飾子や属性が原因の利用制限を外せる！ 62
65. 何を使えるようにする？ @usableFromInline internal ……は微妙かも よそ者からの直接利用は想定されていない不変条件を破壊しそう 勝手に使うとバグるかも Appleさんちのprivate APIなら使えそう！（技術的な観点だけでいえば） 63
66. public API と private API アクセス制御の話じゃないよ public API アプリ開発で使っていいAPIのこと Document APIとも呼ばれる private API アクセス制御的にはopenやpublicだが使ってはいけない（使えない）API Appleの人しか使えない、無理やり使ったらリジェクトされちゃうかも！？ non-public APIとも呼ばれる 64
67. Swift における private API とは Library Evolution有効時に@_spiで作ることができる裏メニュー 裏メニューは.private.swiftinterfaceというスペシャルなカタログにのみ掲載される @_spi(Internal) public func doSomething() { /* ... */ } 65
68. 実例：WebKit WebKitの例： #if USE_APPLE_INTERNAL_SDK @_weakLinked @_spi(Private) @_spi(ForAppKitOnly) import SwiftUI #else 66
69. 厳密には 1+2 種類の"取扱説明書 兼 カタログ" . .swiftmodule .swiftinterface .private.swiftinterface 生成方法 デフォルト 要フラグ さらにもう 1 つフラグ 形式 バイナリ テキスト テキスト 少ない 同じく少ない が､ 裏メニュー付き！ 有益な情報の量 たくさん 互換性 67
70. .swiftinterface に裏メニューを載せる .swiftinterfaceの内容を書き換える "モジュールの核"側の変更は不要 ゆるめのアクセス修飾子に書き換えたり、 本来private.swiftinterfaceにしかないものを.swiftinterfaceへ書き足したりする - @usableFromInline - internal func doSomething() -> Swift.String + public func doSomething() -> Swift.String 68
71. 補足：SwiftUI.swiftinterface の用意 SwiftUI.swiftinterfaceを探し当ててシンボルを書き足すのは面倒くさい ラッパー役のモジュールを用意して@_exported importでSwiftUIを取り込み、 そのモジュールの.swiftinterfaceにprivate APIを書くといける SwiftUIをvisibleにして、目当てのシンボルとmangled nameが一致すればオッケー 69
72. 裏メニューの探し方 いろんなやり方がある、たぶん SwiftUIファイルがさまざまな情報を持っており、そこから探すことも可能 ※実行時に使う真のSwiftUIライブラリのこと。今回紹介したSwiftUI.tbd（ハリボテ）ではない 要：ライブラリの知識 70
73. export trie Mach-Oイメージ内部の、エクスポートするシンボルを管理しているトライ木 シンボルの名前とシンボルの実体へのオフセットを持っている dyldがシンボル解決時に読む 「"モジュールの核"が関数を外部から利用可能にしている」 は、正確には 「シンボルがdylib内のexport trieに載っている」 （たぶん） 71
74. .swiftinterface を書き換える話のまとめ .swiftinterfaceは取扱説明書 兼 カタログ（テキスト形式） 内容を書きかえることで利用制限を外しprivate APIを使えるようになる モジュールのしくみを知っていれば、 private APIのしくみも利用制限のしくみもわかる！ でもprivate APIは使っちゃダメだよ。マジで。 72
75. Wrap up まとめ 73
76. Wrap up モジュールとはimportできるもののこと あとからアップデートして差しかえることもある importしてくる他のモジュールのことを考慮するとよい モジュールのことを知っていれば自信持ってSwiftを読み書きできそう！ private APIは使っちゃダメだよ。 74
77. 参考文献 - モジュール アクセス制御 (Access Control) https://www.swiftlangjp.com/language-guide/access-control.html Introducing Packages https://docs.swift.org/latest/documentation/packagemanagerdocs/introducingpackages/ Target https://developer.apple.com/documentation/packagedescription/target Swift Compiler https://www.swift.org/documentation/swift-compiler/ Whole-Module Optimization in Swift 3 https://www.swift.org/blog/whole-module-optimizations/ 75
78. 参考文献 - フレームワークとバンドル What are Frameworks? https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/ Concepts/WhatAreFrameworks.html Placing content in a bundle https://developer.apple.com/documentation/bundleresources/placing-content-in-a-bundle 76
79. 参考文献 - 互換性と安定性 ABI Stability and More https://www.swift.org/blog/abi-stability-and-more/ [SE-0192] Handling Future Enum Cases https://github.com/swiftlang/swift-evolution/blob/main/proposals/0192-non-exhaustive-enums.md Xcode 14+ creates arm64-apple-ios.abi.json by default https://forums.swift.org/t/xcode-14-creates-arm64-apple-ios-abi-json-by-default/65380/2 77
80. 参考文献 - Library Evolution [SE-0260] Library Evolution for Stable ABIs https://github.com/swiftlang/swift-evolution/blob/main/proposals/0260-library-evolution.md Library Evolution in Swift https://www.swift.org/blog/library-evolution/ Library Evolution Support in Swift ("Resilience") https://github.com/swiftlang/swift/blob/main/docs/LibraryEvolution.rst 78
81. 参考文献 - @unknown default と NS_ENUM Grouping Related Objective-C Constants https://developer.apple.com/documentation/Swift/grouping-related-objective-c-constants Foundation Release Notes https://developer.apple.com/documentation/macos-release-notes/foundation-release-notes SE-0487 Nonexhaustive enums https://github.com/swiftlang/swift-evolution/blob/main/proposals/0487-extensible-enums.md 79
82. 参考文献 - 暗黙の Sendable [SE-0302] Sendable and @Sendable closures https://github.com/swiftlang/swift-evolution/blob/main/proposals/0302-concurrent-value-andconcurrent-closures.md 80
83. 参考文献 - 最適化 SE-0193 Cross-module inlining and specialization https://github.com/swiftlang/swift-evolution/blob/main/proposals/0193-cross-module-inliningand-specialization.md Explore Swift performance https://developer.apple.com/videos/play/wwdc2024/10217/ 属性 (Attributes) https://www.swiftlangjp.com/language-reference/attributes.html swift-algorithms https://github.com/apple/swift-algorithms マクロ (Macros) https://www.swiftlangjp.com/language-guide/macros.html 81
84. 参考文献 - import [SE-0409] Access-level modifiers on import declarations https://github.com/swiftlang/swift-evolution/blob/main/proposals/0409-access-levelon-imports.md [SE-0444] Member import visibility https://github.com/swiftlang/swift-evolution/blob/main/proposals/0444-member-importvisibility.md 82
85. 参考文献 - swiftinterface Plan for module stability https://forums.swift.org/t/plan-for-module-stability/14551 what's in the file of .swiftmodule?how to open it? https://forums.swift.org/t/whats-in-the-file-of-swiftmodule-how-to-open-it/1032/2 Underscored Attributes Reference https://github.com/swiftlang/swift/blob/main/docs/ReferenceGuides/UnderscoredAttributes.md A Swift Guide (WebKit Wiki) https://github.com/WebKit/WebKit/wiki/A-Swift-Guide 83
86. 参考文献 - ライブラリ An Apple Library Primer https://developer.apple.com/forums/thread/715385 Missing librairies in /usr/lib on Big Sur? https://developer.apple.com/forums/thread/655588 Dynamic Library Design Guidelines https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/ DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html 84
87. 参考文献 - シンボルと export trie ld64/src/mach_o/ExportsTrie.h https://github.com/apple-oss-distributions/ld64/blob/main/src/mach_o/ExportsTrie.h ld64/src/ld/LinkEdit.hpp https://github.com/apple-oss-distributions/ld64/blob/main/src/ld/LinkEdit.hpp dyld/dyld/Loader.cpp https://github.com/apple-oss-distributions/dyld/blob/main/dyld/Loader.cpp 85
88. 参考文献 - Private API Code Naming Basics https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CodingGuidelines/ Articles/NamingBasics.html Try-Swift-Playgrounds https://github.com/Private-Playgrounds/Try-Swift-Playgrounds RuntimeViewer https://github.com/MxIris-Reverse-Engineering/RuntimeViewer 86
89. 参考文献 - サンプルで使ったもの UNAuthorizationStatus https://developer.apple.com/documentation/usernotifications/unauthorizationstatus UIUserInterfaceIdiom https://developer.apple.com/documentation/uikit/uiuserinterfaceidiom Optional https://developer.apple.com/documentation/swift/optional Enabling notifications in App Clips https://developer.apple.com/documentation/appclip/enabling-notifications-in-app-clips 87
90. いつもありがとうございます！ mtj0928/SlideKit: SwiftUI framework for presentation slides https://github.com/mtj0928/SlideKit SwiftFiddle - Swift Online Playground https://swiftfiddle.com/ いらすとや https://www.irasutoya.com/ twemoji https://github.com/twitter/twemoji 88