- DI Helper for swift
- Xcode Source Editor Extension
- Mac App Store にある「コード自動生成ツール」 → ローカルの Xcode に設置するだけで依存性注入!
参考: https://github.com/kazuhiro4949/DIHelperForSwift
- Access Level Changer for Xcode
- private/internal/public など? → 合った
- swift refactoring tool
- internal → public 一括変更 →便利そうだけど、セキュ的に大丈夫?という質問の連発
参考: https://github.com/kazuhiro4949/AccessLevelChanger
-
構成
- macOS app
- Xcode Source Editor Extension
- SwiftSyntax
-
作り方
- Xcode で「Xcode Source Editor Extension」テンプレート選択
- source editor command の perform メソッドで実行される
- SwiftSyntax をターゲットの Frameworks/Libraries に入れる
- SwiftSyntax の導入は必ず調べながら (+1 の導入 F/wがあるらしい)
-
他の手法との比較
- コード自動生成自体は色々ある
- Source Editor Xtension は Swiftファイルのみ制御
- Xcode Template はコードにより複雑になるかも
- Run Script とその他 はビルド時しかできない
-
まずは資料: https://speakerdeck.com/trickart/split-japanese-sentence-for-uilabel-and-swiftui-text
-
レイアウトでの改行の地獄
- 反応型表示とは?
- adjustFontSizeToFitWidth を trueにしたら解決(?)
- ↑こうすると文字サイズの調整が地獄
- さらに、逆方向(小→大)は空白まで問題になる
-
NSLineBreakMode (元 英語用)
- byClipping
- byCharWrapping
- byWordWrapping →日本語では適用できない 😇
-
Word Joiner
\u{2060}
で単語扱いの切り目を- 手作業より、MeCab を利用する形態素解析を!
-
obj-c++ とは?
- Obj-C + C++
- 拡張子
.mm
- Swift → Obj-C++ → C++ になるよ
- Mecab 自体が C++ なので、この説明が必要
-
Wrapper の書き方
- Obj-c++ で
- ↑をやったことを Swift Package 化
cSettings
で define,linkerSettings
でリンカーライブラリ設定
-
辞書データ
- 辞書データを Bundle して Swift Package 化
参考: https://github.com/trickart/muscat
Discord で突っ込まれた「NLTagger」
- 日本語の品詞が「Others」のため、使えない
SwiftUI は?
- lineBreakModeがなくても使えた
辞書データ
- Muscat では MecabIPAdic を使ってる
- mecab-ipadic-NEologd を使ってもいいよ
実は前にあったツール
- Google の Budou(py)
- 単語区切りに HTML を…
- なのでマスカット〜
質問タイム
- コピペできるようにしたテキストはどうする?
- 性能的には?
- 基本は nMB ぐらいだが、アプリに Bundle してから容量は nnMBになってしまう
- kakari サービス
- 薬局のシステム - 患者側のアプリ連携
- 指定薬局専用のように見えてるらしい
- つまり、薬局の顧客管理アプリ
- kakari for clinic
- kakari から情報を引継ぎ、簡単に連携するようになった
- Firebase Dynamic Link を利用した (今見るとこれ Deeplink だ)
- データ引継ぎは kakari 本家が設置されているかによって
-
まずは Speakerdeck: https://speakerdeck.com/kichiemon/apple-privacy
-
IP隠し
- 情報暗号化・DNS の2つリレーで通信
-
Privacy Enhancement
- カスタマサクセスとしての Apple の提供
- 法律、機能の追加
- 信頼性の判断基準
-
Apple の Privacy 理念
- 「基本人権」
- 実は 2010 D8 Conf から言われていた Steve Jobs から
- Apple の Privacy 4原則
- Data minimization: 最小限にとって利用も簡潔に、データは必要性とセットで
- Ondevice Processing: 端末外にデータを持ち出すな(持ち出しても端末で処理終えてから)
- Transparency Control: 見えない所で情報収集は NG
- Security Protection: 流出は絶対防いで行こう(必ずローレベルから点検すべき)
-
App Dev 側からの心持ち
- ガイドラインは「軸」: 政府・業界団体・Apple Store のガイドラインに従おう+WWDC参考しよう
- 設計時にプライバシーの観点を: データの生涯周期をちゃんと決める計画を、ユーザーに一々説明
-
最後に: 情報保護は共同責任、みんなが頑張らなきゃ(by Apple)
まずは Speakerdeck: https://speakerdeck.com/ohayoukenchan/iosdc2021-zhi-rarezaruke-jin-sutetasu
-
ゴール:
Offer
とは? -
Offer の二種類
- お試しオファー
- 新規 Subscription 獲得
- iOS 10 以降
- Promotion Offer
- 既存の方の維持・戻ってこい
- iOS 12.2 以降
- お試しオファー
-
Promotional offers が Trials に紐づく場合
- Trial Offer 途中に Promotional Offer を入れたら→ 13ヶ月無料
- 既存課金者の Promotional Offers を入れたら→ 課金した期間が終わったらその続きとして
-
↑で紐づかない場合
- 無料から同じ期間: Cross-grade になり、前の subscription が取り消しになっちゃう
- 有料から同じ期間: 上記の Cross-grade になり、前の subscription が取り消しになったら、返金が行われる
- 有・無料問わず期間が異なる: 紐づく場合と同じく、前の subscription が終わってから
-
結論: だからお知らせをちゃんとするし、期間を全部別にすれば良いかも?
-
Promotional Offers が別 Promotion に紐づく場合
- 期間問わずに前の Promotion が終わってから
- Pending の「別Promotion」が複数になると最新のやつのみ残り、他は飛ばれてしまう
-
これは資料をちゃんと読み取り、その中で基礎から深堀りしないと… https://speakerdeck.com/inamiy/iosdc-japan-2021
-
今までの async 計算
- completion handler で測った (fetch - response)
- flatMap(計算結果によりその結果を持ってくる) -> js の Promise.then()
- Promise/future
-
await/async の形
- try await function(arg)
-
Monad (flatMap 型)
- protocol/extension として Functor[Map] の subprotocol
monad.flatMap{ f($0).flatMap(g) }
- callback 重ねから簡単化できる形だった
?.is
==.flatMap(\.is)
throws -> try
でも計算できていた →async -> await
型に書き換えられるResult<value, error>do
やAsync.do
の中身は<-
に変わった
-
継続と継続渡しスタイル(CPS)
- callback (
->
)func cpsfunction<R>(a: A, completion: D -> R) -> A -> R
の形らしい(不可解 🤪)- CPS では completion リターンにより逆順で伝わる形
- Monad でも使えるらしい
- Structured Concurrency で、キャンセルがうまくいけた (リソース管理場面で有利)
- Lifecycle 管理の場面で、TaskGroup 配下の Task 毎に生存期間区切りができている
- CallCC
- callback の例外処理、goto 処理、defer 処理などで使われる
- 非常に危ない黒魔法(?)
<- shift / <-reset
で非同期処理
- callback (
-
Coroutine
- Java の Runnable/Thread?
pause/send
などで制御- 非同期では
suspend/resume
を使う - AsyncCoroutine の場合、
<- await
中身を suspend にしている
結論: async/await を理解するにはコルチーンを、コルチーンの理解には Monad と CPS(継続) などの理解が必要
吐きそう…
参考: https://medium.com/flawless-app-stories/swift-monad-functor-applicative-806bb34c68c5 Monad と Functor ってなに?という記事
韓国語で「Swift Concurrency Roadmap」という、昔のことを語っている記事 https://medium.com/@jungkim/%EC%8A%A4%EC%9C%84%ED%94%84%ED%8A%B8-%EB%8F%99%EC%8B%9C%EC%84%B1-%EB%A1%9C%EB%93%9C%EB%A7%B5%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC-about-swift-concurrency-roadmap-ccf651c09c4c
- どのファイルを計測するか?
- App Store の ipa 情報、テストアプリの情報、.app というバンドルの情報があるが
- 端末用の .ipa を獲得し、容量を測る必要がある(App Store の情報もズレがある)
- リリース済みアプリのサイズを確認する
- Xcode Report Tool の App Size Report で、アプリを組み込んでからのリポートで確認できる
- ↑を使えば、開発中で端末の種類別の容量リポートが取得できる
- CI で xcodebuild からも OptionsPlist.plist で を設定すれば
- ipa の内部を確認する
- ipa は実は zip なので、解凍して中身確認ができる
- 不要なファイルやリソースを確認する
- README, swiftlint/swiftgen などのツール、デバッグ用のモジュール
- 解凍した後の .app バイナリを解析する
- Bloaty: Google 製のバイナリサイズプロファイラ CLI
- 具体的にどうやってアプリのサイズ削減ができるか?
- App Thinning: デバイスでの動作に必要要素のみ入れる
- Fastlane から
export_options({thinning: "<thin-for-all-variants>"})
を! - 社内で試した感想: 0.1MB も変わってなかった
- Fastlane から
- Enable Bitcode: xcodeproj で
ENABLE_BITCODE: yes
- ただ、
fastlane download_dsym
が AppStoreConnectAPIKey に対応しないから 直接ダウンロード必要
- ただ、
- リソース系1: Asset Catalogs 採用
- メタデータタグ付け
- リソース系2: Image Format
- PNG は 8bit を利用しよう
- ベクター画像に iOS13 で利用可能な svg を採用し、pdf の 10% まで削減しよう
- 32bit PNG を使うには「Web用に保存」を使おう
- リソース系3: On-demand Resource としてリソースを
- その他
- Compile Option:
SWIFT_OPTIMIZATION: -Osize
やASSETCATALOG_OPTIMIZATION_OPTION: space
- なるべく Swift 純正を使おう: RxSwift→Combine, Realm→CoreData
- Compile Option:
- App Thinning: デバイスでの動作に必要要素のみ入れる
- iOS14 から登場した Frameworks
- NIDiscoveryToken 取得し、お互いの位置を交換し、NISession を開始、NISessionDelegate を取得
- 9m まで検知可能、xyz 軸取得可能
- 1peer 1session 原則
- 分厚い iPhone ケース使うと取りづらい
- iOS15 ではサードパーティからも使えるし、 CoreBluetooth を使ってトークン取得もできるらしい
- 画面全体をスクショでクラッシュしたらしい
- 結構前からあったけど、再現も特定もできなかった
- 「使い続けるとアプリ落ちる」という手がかり
- もしmemory leak?
- 重要なのは「リリース後の観測」
- 技術の刷新を意識しましょ〜
- M1 の修正不可の脆弱性!
- register の中のデータを使ったら発生
- Missing Register Access Control による
- A14系全部
- VM やめましょう
- Malware が入っていたら予想しないクラッキングが発生するだけ
- つまり、「致命的ではない」
- NOT A HOTEL app が Tesla API を使ってる
- BMW アプリの一部 API が公開されているが、本家機能はあんまり…
- Tesla Unofficial REST API
- 社長の Tesla を乗っ取って試した
- NOT A HOTEL app のうちで上記の Tesla API v2 を使って乗っ取った
- pixiv のデザインスポンサー
- ロゴとサイトを作るらしい
- プラチナスポンサーになるらしい
- 5月末から始まり、最終は6月末に完成
- サイトのデザインは↑の後すぐ、7末に修正終えて 8頭にリリース
- デザイナーエンジニアーとりまとめの総務
- iOSDC の紹介からしないとデザイナーとデベロッパー取りむずい
- Push の今まで: iOS10 の Extension, 目立たない配信など
- iOS15 新機能: Summary, 集中、Interruption
- 指定した時間にくる Summary
- 集中モードでフィルターできる
- 4つのレベルで重要度によるプッシューの区分を
- 新機能からの影響
- ユーザーの目に触れにくくなりそう
- Push が中心であれば、機能が壊れるかも?
- バッジだけくるやつ→自動で集中モードに入ってから…
- どうしよう
- Time sensitive が重要
- Relevance Score の設定を検討
- Interruption Level の優先順位を再構成
- 14.7.1 基準
- 実験 WebKit
- デフォルト 36/82
- HTTP/3: UDP で速度向上
- WebGL 2.0
- WebGPU: ↑からの Metal ベースの w3c 仕様策定のもの
- Web Share API lv.2: 画像のウェブ上即時シェアができたのはこれのおかげ
- element:
<model> <source src='xxx'> </model>
- SwiftUI で一部 Bold にするに何を使う?
Text('hoge').bold()
は hogeが長くと問題→ +Text(' ')
などで補う- iOS13から
- イメージをテキストにラッピングするには
Text(Image(systemName: <image名>)
- iOS14から
- Formatで金額を区切り
Text('\(amount)円')
- iOS13から
- iOS15からは「FormatStyle」が使える(
.month, .date, .time
など)
- 説明しない系、エラーをちゃんと見せてない系、イライラするでしょ
- メンテナンスなど「メッセージ」を表示したら
- 500 のなか、アクションを見せるパターン
→ とにかく「説明+ネクストアクション+最新状況」をちゃんと魅せる
- スマートリモコンスイッチボット
- 専用のアプリからスマホリモコンが家電を
- Siri に対応する、ショットカットから使える
- Homebridge でスイッチボット API 叩く
- ↑でできないこと
- 今のステータス取れない(実装したらできるやつもある)
- OSSだが、実装無理の部分もある (意外と複雑な仕組みで、OSS と合わない場合)
-
まずは資料: https://speakerdeck.com/nanashiki/iosdc-2021
- デモコードがあるらしい: https://github.com/nanashiki/MiniSNS-iOS
-
Xcode 12.5.1 の iOS 14基準
-
.alert の罠
- Vstack で2つ並んで書いたら使えない
- .alert の位置により、childview のアラートが出なくなる
- 解決: enum に定義して適用させる
-
sheet, fullscreencover の並かぶりは 14.5 から治ったらしい
-
XCUITest の例
- ログイン・ログアウトの UI テスト作成
- メッセージの投稿 UI テスト
- E2E は実際に操作しながら
- Mock では Mock の結果を想定してテスト
-
UI の難点
- E2E: Tutorial など、一回のみの画面が多く、そこで引っかかる
- Mock: POST通信が難しい, JSON 担保できない、導入障壁が結構高い
-
SwiftUI の一番長所
- Xcode Previews で開発毎に直ぐ画面見れる
- APIClientMock を利用し、通信結果の表示を Xcode Previews で確認できる
-
SwiftUI と UITest
launchArguments = ["-MockAPI"]
で UITest からapp.launch
すればおk- 遷移時のバグ担保できるから安心
- ただ CI に時間かかる、Xcode アップデートにより壊れるか恐れ
- iOS 14.5 で↑の壊れる現象が…
結論: SwiftUI は Xcode Preview を使うために使ったらしい