iOSDC 2022「アニメーションAPIのすべて」補足など - 24/7 twenty-four seven
先日のiOSDC 2022にて「アニメーションAPIのすべて」という発表をしました。 fortee.jp きっかけはDroidKaigi 2021で荒木佑一さんの「動かす」という発表です。 www.youtube.com Androidのさまざまなアニメーション APIについてコードや具体的な例を用いて解説する内容です。最後にスライド自体がAndroidアプリとして作られていて、サンプルのアニメーションはすべて実際に動いていたものだった、と明かされるところが非常におもしろいと思ったのです。ぜひこれのiOS版をやろうとそのとき考えたのでした。 ちなみに、荒木さんはそれ以前のDroidKaigiや別のカンファレンスでも「動かす」シリーズで話されているので資料などを探して読んでみるとどれもおもしろいです。 ということで１年間あたためていたアイデアが無事採択されたことはよかったのですが、さすがにこ
CIによるXcodeのテスト実行結果をGitHub Checksにわかりやすく表示する - 24/7 twenty-four seven
Xcodeによるユニットテストの実行結果をCIサービスの画面で確認するのはなかなか大変です。 GitHubにはCIのステータスをそこそこリッチな画面表示として返せて、Pull Requestの画面から１クリックでアクセスできるGitHub Checksがあるのでそこで確認できればとても便利です。 ということでXcodeのテスト結果をGitHub Checksに表示するGitHub ActionとBitrise Stepを作りました。 github.com Xcodeがテストを実行した際に生成するXcode Result Bundleというテスト結果やログ、コードカバレッジ、スクリーンショットなどをすべてまとめたデータを解析して、Markdownの形式でまとめてGitHub Checks APIにPOSTする、ということで実現しています。 次のように、テストを実行する際にXcode Resu
Apple IDの2ファクタ認証をCI環境で突破する - 24/7 twenty-four seven
【注意】この記事で紹介しているSMS APIサービスのVonageは利用規約により認証にVonageの電話番号を利用することを禁止しているという記述があるので、末尾の別解として載せたAndroidデバイスを使ってSMSを転送する方法が良さそうです。 help.nexmo.com 2021年2月から、App Store Connectにログインする際にすべてのApple IDで2ファクタ認証が必須になります。 Starting February 2021, additional authentication will be required for all users to sign in to App Store Connect. This extra layer of security for your Apple ID helps ensure that you’re the only
CIのシークレット変数に1Password CLIを利用する - 24/7 twenty-four seven
CIでいろいろなタスクを自動化していると、CIで必要とするAPIのトークンやアカウント情報など設定しているシークレット変数が増えてきます。 たいていの場合はCIサービスのシークレット変数を利用すればよいですが、サービスによっては一度設定したシークレット変数を見ることができなかったり（GitHub ActionsやCircle CIが該当）、トークンやアカウント情報の更新や追加があったときにCIの変数を更新していくのが大変だったり、シークレット変数のメンテナンスはそこそこ面倒な作業です。 性質上かなり強い権限が設定されているトークンだったりすることもあるので、誰がその値をメンテナンスできるか、という管理の問題もあります。 そこで1Passwordをアカウント情報の共有に使っている組織なら、1PasswordはCLIの操作が提供されているのでCIから1Passwordのアカウント情報を取得する
CocoaPodsをWorkspaceに自動統合せずに利用する - 24/7 twenty-four seven
背景 現在のiOSアプリ開発におけるパッケージマネージャのデファクトスタンダード（事実上の標準）としてCocoaPodsとCarthageがあります。Xcode 11からはSwift Pacakge ManagerがXcodeに統合されて利用できますが、ライブラリ側の対応が必要ということや、ベンダーライブラリなどを考えるとCocoaPodsは少なくとも当面は使われ続けるでしょう。 Carthageと違って、CocoaPodsは.xcodeprojに依存せず独自のビルドシステムを持つことや、（デフォルトでは）Workspaceにライブラリのプロジェクトを自動的に統合するので、リンクに関する設定をやらなくて済むという特徴があります。 しかし、これは長所でもあり短所でもあります。 リンクの設定を自動で追加するために、プロジェクトのビルド設定がCocoaPodsが自動で追加する記述によって非常に複
iOS 13にしかないフレームワークを使用したアプリをiOS 12以下でも動くようにするには - 24/7 twenty-four seven
SwiftUI、Combile、RealityKitなどiOS 13以上の環境にしか存在しないフレームワークを使用するアプリをiOS 12以下の環境で実行すると、その機能を実際に呼び出さないようにしていたとしても、起動時にダイナミックリンクに失敗してクラッシュしてしまいます。 dyld: Library not loaded: /System/Library/Frameworks/RealityKit.framework/RealityKit Referenced from: /Users/katsumi/Library/Developer/CoreSimulator/Devices/7D73BD02-5C30-4723-9023-4D19BCDAE1AA/data/Containers/Bundle/Application/A9E00179-1DDD-4051-9207-7CC6C9DC
CのライブラリをiOS向けにビルドする - 24/7 twenty-four seven
ほとんどのUNIX系OSにおけるCライブラリはAutotoolsを使って開発されています（./configure && make installの手順でビルドする）。 普通に./configure && make installすると実行している環境（MacやLinux）用のバイナリが生成されますので、そのままではiOSで利用できません。 iOSで使用できるようにするにはiOS環境用にビルド、いわゆるクロスコンパイルする必要があります。 Autotools（./configure）ではクロスコンパイルのことが初めから考慮されていてそのための機能がサポートされているので、./configureの設定を正しくできれば、意外と簡単にさまざまなCのライブラリをiOS上で動くようにビルドできます。 設定について iOSではデバイスとシミュレータでCPUアーキテクチャが異なるのでそれぞれのアーキテクチ
Auto Layoutの静的な制約で実現するテキストの量によって折りたたみ可能なテキストビュー - 24/7 twenty-four seven
長いテキストが初期表示では折りたたまれて表示されていて、「つづきを読む」ボタンを押すことで表示エリアが拡大して全文が表示されるという挙動を、できるだけ動的な要素を排除して実現してみます。 サンプルコードは下記のリポジトリで公開しています。 github.com 今回の例ではUIStackViewを活用します。UIStackViewは内部のビューのisHiddenプロパティによってビューのサイズをゼロにできるので、うまく活用すればあたかも複数のレイアウトを切り替えているような挙動を実現できます。 テキストビュー（またはラベル）の左右両端と上端が一致するようにStack Viewに制約を付けます。 さらにテキストビューとStack Viewの高さが一致する制約を付けます。 Stack Viewの中のビューに高さの制約として折りたたんだときのサイズを指定します。例では200ptです。 テキストの
Auto Layoutの静的な制約で実現する伸び縮みするヘッダービュー - 24/7 twenty-four seven
TL;DR, 優先度の異なる複数の制約を同時に定義することで、静的な定義だけで動的な振る舞いを実現できる 動的な要素の少ない構造のビューはより堅牢である はじめに 読みやすくメンテナンスしやすいソフトウェアを作るために重要なことの一つは構造をシンプルに保つことです。 iOSアプリのビューは壊れやすいソフトウェアの代表ですが、できるだけシンプルに作ることで変化に強い、堅牢で壊れにくいソフトウェアにできます。 動的な要素が少ないということは、ビューがシンプルであるということの指標の１つと言えます。 この記事では下記に示すような、スクロールに合わせて伸び縮みするヘッダーを、動的な要素を無くし、Auto Layoutの静的な制約のみで実現する方法を解説します。 動的な要素とは、実行時におけるビューおよび制約の追加・削除、Frameや制約を更新することと、機種やスクリーンサイズ、標準UIコンポーネン
StoryBoardまたはXIBについて、ファイルごとにDeployment Targetを設定する - 24/7 twenty-four seven
昨日はじめて知ったのですが、StoryBoardやXIBファイルはプロジェクトやターゲットのDeployment Targetとは別に、各ファイルごとに個別にDeployment Targetを設定することができます。 例えば、iOS 8以上にしか存在しないUIVisualEffectViewや、iOS 9以降でしか使えないUIStackViewをStoryBoardで配置して、プロジェクトのDeployment Targetを7.0（や8.0）にすると、下記のエラーでビルドに失敗します。 Main.storyboard: error: Class Unavailable: UIVisualEffectView prior to iOS 8.0 これを避けるためにはStoryBoardを使うことをあきらめ、コードでOSバージョンを分岐して、コードでUIコンポーネントを配置する必要があると思
WebとiOSアプリでパスワードを共有する - 24/7 twenty-four seven
iOS 8からWebサービスとアプリ間でiCloudキーチェーンを通じてパスワードなどアカウント情報を共有できるようになりました。 （ただし、現状ではiCloudキーチェーンを使えるのはSafariのみのため、MacのSafariとiOSアプリの間に限る） 昨今ではそれぞれ別のサービスで同じパスワードを再利用せず、サービスごとに固有のできればランダムなパスワードを登録して、パスワードマネージャで管理することが推奨されています。 Webサービスを使うだけならブラウザのパスワード管理などを利用すればいいのですが、そのサービスのiOSアプリを利用しようとするとパスワードを調べるのが大変でした。 iOS 8では（Safari限定ではありますが）Webサービスで入力してキーチェーンに保存したアカウント情報を、iOSアプリでも利用することができます。 パスワードなど機密性の高い情報を共有するため、どの
SwiftでKeychainを簡単に使うライブラリ "KeychainAccess" を書きました - 24/7 twenty-four seven
kishikawakatsumi/KeychainAccess · GitHub そろそろSwiftをちゃんと勉強しようと思って作りました。 Swiftで書かれたKeychainのラッパーの中ではもっとも高機能でかつ簡単に使えるものができたと思います。 機能としては下記を備えています 簡単に使えるインタフェース アプリ間のキーチェーン共有 アクセシビリティ（バックグラウンド動作時の制限など）属性のサポート iCloudによるキーチェーンの同期 Touch IDによるキーチェーンの保護（iOS 8〜） iOSとOS Xの両方の動作をサポート インストール Carthage github "kishikawakatsumi/KeychainAccess" CocoaPods pod 'KeychainAccess' CocoaPodsを使う場合、CocoaPodsのバージョンはbeta版の0.
コマンドラインからiOSアプリケーションをiTunes Connectにアップロードする - 24/7 twenty-four seven
参考 Testflight build notes via iTMSTransporter [self reloadData];: Automatic app creation and binary upload Command upload App/Ipa to the iTunes Connect App Store Redesign of itunes connect · Issue #38 · kovpas/itc.cli · GitHub TL;DR Xcode（厳密にはApplication Loader）に付属するiTMSTransporterまたはaltoolを使います。 上記のリンク先を見ればだいたいわかります。 altoolのほうが直感的なコマンドで簡単です。 iTMSTransporterはそもそもゲームのアイテムなど大量のIn-App Purchaseのメタデータを
Travis CIでiOSアプリのリリース作業を自動化する - 24/7 twenty-four seven
この記事において利用している.travis.ymlとRakefileの全体はGistにて公開しています。 ↓ Rakefileの全体はこちら gist.github.com/kishikawakatsumi/8918124 ↓ .travis.ymlはこちら gist.github.com/kishikawakatsumi/8918365 概要 ユビレジではiOS アプリを申請する際に発生する作業の大部分をCIで自動化しています。 申請の作業としてユビレジでは下記のワークフローを決めています。 1. リリースブランチを作る 2. リリースするバージョンのバイナリをビルドする 3. 2と同等のアプリケーションを社内に配布して最終チェックをする 4. クラッシュレポートのサービスとしてCrittercismを利用しているので、そこにデバッグシンボル（dSYM）をアップロードする 5. 2のバイ
iOS 8でIn-App Purchaseの状態に追加されるSKPaymentTransactionStateDeferredの影響を考える - 24/7 twenty-four seven
In-App Purchaseでプロダクトの購入を扱うときにはStoreKitのSKPaymentTransactionStateを使います。 例えばPurchasedなら購入完了なのでプロダクトのダウンロードを始める、Failedなら失敗なのでアラートを出すなどとします。 iOS 8からはその状態に新しくSKPaymentTransactionStateDeferredが追加されます。 2014/8/6時点ではまだドキュメントに解説はありません。 API diffとヘッダには記載されています。 WWDCのセッション218, 303ではそれなりに詳しく解説されていますので参考になると思います。 Deferredという状態は「Ask to Buy」というiOS 8のApp Storeの新機能のために導入されました。 「Ask to Buy」はiOS 8で搭載される「ファミリー共有 (Fami
Storyboardを1画面ごとに分割した話 - 24/7 twenty-four seven
今年の5月くらいの話なのですが、ユビレジのiPadアプリケーションのプロジェクトで使っているStoryboardを基本的に1画面（≒1 View Controller)の単位に分割するということをしました。 1画面1Storyboardメソッドについてはnakiwoさんが書かれた記事も参考になります。 1画面から始めるStoryboard - Cocoaメモ ↑ 上記の資料はどちらかというとStoryboardを使い始めるにあたって、１画面単位で少しずつ使っていこうという感じですが、ユビレジではもともとほぼ全部の画面がStoryboardになっていました。 ただ複数人で共同作業をするにあたっては、1画面単位を1ファイルにしておくくらいがメンテナンスしやすいんじゃないかなあという結論になったのでしばらくそういうふうに運用することにしました。 また、XIBと違ってStoryboardは単純にコ
NSArrayやNSDictionaryからNSNullを効率よく取り除く - 24/7 twenty-four seven
iOSアプリケーションでWeb APIから返ってきたJSONを処理するのにNSNullの扱いに困っていて、事前にNSNullを取り除いてしまうのが事故を防ぐための確実な方法なのですが、再帰的にすべての要素を検査する以外になにかいい方法がないかと思って考えていたらちょっとおもしろい方法を思いついたので書いてみました。 kishikawakatsumi/CollectionUtils · GitHub ↑ に含まれるCUCompactArrayとCUCompactDictionaryです。 NSArrayとNSDictionaryのサブクラスとして実装されていて、次のようにして生成します。 （普通にalloc/initを使って生成することも可能です） NSArray *array = @[@"0", @"1", [NSNull null], @"2", [NSNull null], @"3"]
NSDateFormatterのパフォーマンスの話 #potatotips - 24/7 twenty-four seven
クックパッド主催の第4回potatotipsでiOSのtipsとして日付のフォーマットをするときのパフォーマンスの話をしました。 きっかけ きっかけは何気なくgistを眺めていたときに見つけたこれです。 ↓ Compare the date parsing performance of NSDateFormatter against SQLite's date parser for parsing an iOS 8601 date. NSDateFormatter took 108.163 seconds strptime_l took 21.656 seconds sqlite3 took 7.096 seconds そうそう、NSDateFomatterはけっこう遅いからフォーマットが固定だったりロケール関係ないときはstrptime_l使うよね、アップルのドキュメントにも載ってるし…
CocoaPodsで導入しているライブラリのライセンス表記を自動的に作成する - 24/7 twenty-four seven
CocoaPodsを利用している場合は、PodsディレクトリにPods/Pods-acknowledgements.plistまたはPods/Pods-acknowledgements.markdownが自動的に作成されていますので、それを利用して使用しているライブラリのライセンス表記を自動化できます。 一番簡単なのは設定アプリに項目を設けて表示することです。アプリケーションに画面を追加するわけではないのでお手軽です。 CocoaPodsのWikiにも同様の方法が載っています。 Acknowledgements · CocoaPods/CocoaPods Wiki · GitHub ライセンス表記は使用しているライブラリの構成が変わったときにだけ更新されればいいので、PodFileのpost_installフックで作成されるようにします。 これで`pod install`あるいは`pod
ユビレジのiPadアプリのCI環境をJenkinsからTravis CIに移行したときのまとめ - 24/7 twenty-four seven
こちらの記事について、最新のTravis CIの環境(2014/4/15)ではコード署名に失敗する問題があります。 その問題の修正については下記の記事にまとめました。 Travis CIでipaを作るときのCode Signが失敗するのを修正したメモ - 24/7 twenty-four seven 実際は完全に移行したわけではなくて、Travis CIの有料プラン（プライベートリポジトリが使える）のフリートライアルを試しているところなのですが、しばらくはTravis CIでCIを動かすことにしたので、そのときの設定などをまとめます。 もともとは社内のサーバでJenkinsをホストしていて、それがダメということは全然ないのですが、社内でサーバをメンテナンスするのも面倒だし、ビルドスクリプトとかをポータブルな状態にしておくのは手元でサクッと実行できたりいろいろ都合が良さそうだと思い、試しにや
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
