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
FolioのiOSチームで利用しているFastfileとBitriseワークフロー - 24/7 twenty-four seven
FolioのiOSチームではさまざまなタスクをそこそこ高度に自動化していると思うので、（そのまま別のプロジェクトで使いまわせるほどポータブルではないけど）参考にしてもらえる部分はけっこうありそうと思うので公開リポジトリに置いてみました。 github.com 簡単に解説します。 Fastfile lane :snapshot_test Folioアプリのユニットテストはいわゆる一般的なロジックテストに加えてスクリーンショットを用いたスナップショットテストがあります。 GitHub - uber/ios-snapshot-test-case: Snapshot view unit tests for iOS 目的は修正によって意図しない影響が起こっていないことを検証するためと、現状の画面の一覧をGitHubで変更管理したいからです（これについては詳細を後述）。 （ボタンを追加したら関係ないは
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は単純にコ
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
CocoaPodsをWorkspaceに自動統合せずに利用する - 24/7 twenty-four seven
背景 現在のiOSアプリ開発におけるパッケージマネージャのデファクトスタンダード（事実上の標準）としてCocoaPodsとCarthageがあります。Xcode 11からはSwift Pacakge ManagerがXcodeに統合されて利用できますが、ライブラリ側の対応が必要ということや、ベンダーライブラリなどを考えるとCocoaPodsは少なくとも当面は使われ続けるでしょう。 Carthageと違って、CocoaPodsは.xcodeprojに依存せず独自のビルドシステムを持つことや、（デフォルトでは）Workspaceにライブラリのプロジェクトを自動的に統合するので、リンクに関する設定をやらなくて済むという特徴があります。 しかし、これは長所でもあり短所でもあります。 リンクの設定を自動で追加するために、プロジェクトのビルド設定がCocoaPodsが自動で追加する記述によって非常に複
OpenAPI (Swagger) のコード生成から通信処理を分離してスキーマ定義だけを利用する - 24/7 twenty-four seven
背景 今関わっているプロジェクトではOpenAPIを利用して、APIのスキーマを定義しています。 OpenAPIではスキーマ定義からクライアントコードを生成できます。 しかし、デフォルトのコード生成はスキーマ定義とネットワーク通信のコードが強く結びついており、使いにくい場面があると感じていました。 認証等がなく、単純なGETだけのエンドポイントを相手にしている場合はそうなっているのは便利だと思いますが、今のプロジェクトでは リクエストヘッダに認証トークンおよびアプリの情報を示す情報を追加する （デバッグビルドでは）リクエスト前と後にログ出力をする アクセストークンの期限が切れた場合は自動的にアクセストークンをリフレッシュし、シームレスにリトライする すべてのエンドポイントで発生しうるエラー（サーバーエラーの5xxや、クライアントエラーの4xx、強制アップデートや緊急メンテナンスなど）と、個
SceneKitとCALayerで作る3Dのスライドショー - 24/7 twenty-four seven
大型ディスプレイに投影するデジタルサイネージを作る仕事をしました。 できあがったのがこれです。 github.com まず、アートディレクターと相談して、下記の映像を参考にして3D空間を飛び回るようなスライドショーでいこうと決めました。 www.youtube.com www.youtube.com 最初のプロトタイプはCALayerだけで作りました。 CALayerは3Dの変形をサポートしていて、かつmacOSのCALayerではCore Imageのフィルタがエフェクトに使えるので、各層のレイヤーに次のように書くだけで遠くなるにつれてブラーをかけてぼやかせる、ということが簡単に実現できます。 let frontLayer = CALayer() frontLayer.frame = layerFrame if let filter = CIFilter(name: "CIGaussia
UITableViewでページング処理をする。 - 24/7 twenty-four seven
App Storeとかであるんだけど、UITableViewの最初の20件とかを 読み込んでおいて、もっと見たい場合は一番下のセルの 「ほかの？？件を読み込む」 とか 「次の？？件…」 ってのを押すとインジケーターがぐるぐる回って そこにセルがインサートされるみたいなやつを作りたくて 検索してみたけど実装する方法がみつからない。 あれってどうやればいいんだろう…。 もうちょっと探してみる。 UITableViewで「ほかの？？件を読み込む」を実装する方法がわからない - clouderのiPhoneアプリを公開するまでの日記 - iPhoneアプリ開発グループ 「次の？？件…」を表示するために最初のデータ件数＋１をテーブルビューの行数とします。 - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NS
Auto Layoutの静的な制約で実現するカラム幅が可変のテーブル - 24/7 twenty-four seven
次に示すような見出しと各カラムが右寄せ、ラベルの文字数によってカラムの幅が伸縮し、広くなった場合は隣の列を押し出し、短くなった場合は少なくとも見出しの幅に収まり、各列の間には一定のマージンを置くというテーブルレイアウトを、静的なAuto Layoutの制約だけで作ることを考えます。 このような、UIコンポーネントが持つコンテンツの大きさによって隣接するコンポーネントを押し出すような場面ではAuto Layoutがとても効果的に働きます。 Auto Layoutなしで実現しようとすると、列ごとの各行の文字幅を計算し、最大の幅に合わせて再配置する、という処理をコンテンツが変わるたびに行うということになりますが、Auto Layoutの制約を使用する場合ではそもそもレイアウトの再計算を自分でやる必要はないので、コンテンツの変わったタイミングなどを気にする必要はありません。 ただデータを再代入する
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コンポーネン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
