Tag Xcode

Xcode: プロジェクトにカスタムフォントを追加する方法

開発するアプリの企画によっては、システムフォントでは表現力が弱い場合があります。 今回は Xcode プロジェクトへカスタムフォントを追加する際、必要となる作業をメモしておきます。 目次 プロジェクトにフォントを追加する まとめ プロジェクトにフォントを追加する FontBook で使用するフォントの PostScript 名を調べる macOS に標準インストールされている FontBook.app を起動し、インストールしたいフォントを選択します。ここでは Source Code Pro レギュラーを選択します。 FontBook のツールバーより iマークアイコン、もしくは ⌘+i でフォント情報を表示させ、PostScript 名をメモしておきます。 この PostScript 名 は、Xcode でコードからフォントを指定する ときに必要となります。 フォントファイルをプロジェクトへコピーする 先ほど FontBook で PostScript 名を調べたフォントファイルを、Xcode プロジェクトへ ドラッグしコピー します。 プロジェクトへフォントがコピーされていれば、ファイルを選択すればフォントのサンプルが参照できます。 info.plist > Fonts provided by application に追加する Xcode プロジェクトの info.plist で「+」ボタンをクリックし、Fonts Provided by application 項目を追加します。 先ほど追加したFonts Provided by application 項目の Item0 の value にコピーした フォントファイル名 を記述します。 Copy Budle Resources に追加する プロジェクト -> Build Phases -> Copy Bundle Resources にフォントファイルが追加されているか確認します。 ここにフォントファイル名がない場合、「+」ボタン よりフォントを選択し、フォントファイルを追加 しておきます。 ストーリーボードでカスタムフォントを利用する ストーリーボードのラベル等で、フォントを指定すればカスタムフォントが利用できるようになっています。 コードでカスタムフォントを利用する ソースコードからカスタムフォントを指定する場合は、以下のサンプルのように font 名に FontBook で調べた PostScript 名を記述します。 まとめ フォントをシステムフォントからカスタムフォントへ変更するだけで、アプリの印象はガラリと変わります。 また、似たような機能をもつアプリであっても UI デザインやフォントを変更することで、ユーザー体験はおおきく変化します。 やりすぎは注意ですが、適切なフォントを選択することで、より完成度の高いアプリになるのではないでしょうか。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。

Xcode: $(SRCROOT) 、$(BUILD_DIR) 等の内容を出力する

Xcode プロジェクトの設定を行う際、ファイルのパス指定に SRCROOT や BUILD_DIR 等の変数が割り当てられているのを目にするかと思います。 今回はこれら Xcode で使われているマクロ変数を出力したいと思います。 目次 $(SRCROOT) 、$(BUILD_DIR) 等の内容を出力する まとめ $(SRCROOT) 、$(BUILD_DIR) 等の内容を出力する プロジェクト > Build Phases を開き、「+」で New Run Script を追加します。 追加された Run Script 項目へ以下の1行を追加し、ビルドを実行します。 ビルド実行後、プロジェクトフォルダ内に env.txt が出力されます。 env.txt には、Xcode で使用されているマクロ変数がすべて出力されています。 まとめ env.txt には、Info.plist や Buid Settings 等以外でも使われている 400 以上のマクロが出力されています。 新規プロジェクト時に、env.txt を Run Script で吐き出しておくと、後々役立つかもしれませんね。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。

Xcode: Launch Image 変更後、実機で確認できない場合の解決方法

Xcode でアプリにローンチ画像(スプラッシュ)を設定する際、Assets.xcassets で画像を管理しますが、Assets 内の画像変更後にローンチ画像を実機で確認すると、前の画像が表示されるときがあります。 一度こうなると、いくら Mac、Xcode を再起動してもローンチ画像が変更されない状態が続きます。 この現象を解決する方法をメモしておきます。 目次 Launch Image 変更後、実機で確認できない場合の解決方法 まとめ Launch Image 変更後、実機で確認できない場合の解決方法 Assets で画像を変更すれば、厳密には変更内容は反映されています。 この現象は iOS デバイス内に画像キャッシュが残っているため、画像ファイル名をそのまま利用し、データだけを差し替えた場合、キャッシュを参照してしまうことで発生します。 解決方法は以下の通りです。 アプリをロングタップ(長押し)し、アプリを一旦削除します。 iOS デバイスのスリープボタンを長押しして、電源をオフにします。 iOS デバイスの電源をオンにし iOS を起動します。 Xcode からアプリをビルドし、iOS デバイスへアプリを再インストールします。 これで iOS デバイス内にある画像キャッシュがクリアされ、ローンチ画像の変更が確認できます。 まとめ Xcode で開発時に iOS 端末に画像キャッシュが残ってしまい、変更後の確認ができない現象はローンチ画像以外のリソースでも発生します。 せめて開発時には Xcode 上から、これらのキャッシュをクリアする仕組みを準備しておいて欲しいものですね。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。

Xcode: pod setup が先に進まない問題の解決方法

前回の cocoapods インストール の後、pod setup でセットアップを行うと思うのですが、ここでもさらに Setting up CocoaPods master repo から処理が先に進まない問題が発生しました。 今回はこの問題を解決したいと思います。 目次 pod setup が先に進まない問題の解決方法 まとめ pod setup が先に進まない問題の解決方法 インストール完了後に cocoapods のリポジトリフォルダへ移動します。 リポジトリをクローンします。 リポジトリクローン完了後、pod setup を実行します。 Setup completed が表示されればセットアップ完了です。 まとめ cocoapods は一度インストールしてしまえば、ライブラリ・フレームワーク等の更新は pod install 一発で最新のバージョンになり重宝しますが、導入がすんなりいかないのが残念でした。 導入後に問題が発生するケースもあるので、本末転倒ですが従来通り Xcode プロジェクトファイルへマニュアルコピーでもいいような気がします。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。

Xcode: cocoapods インストール Operation not permitted エラーを回避

macOS Sierra クリーンインストール後、cocoapods をインストールしようとしたら Operation not permitted エラーが発生し、インストールができませんでした。 El Capitan 以降の OS では、マルウェアからの攻撃に対するセキュリティ強化のため、root 権限にもシステム関連フォルダへのアクセスに制限がかかる(rootless)ようになったのが原因です。 今回はこの問題を解決し、cocoapods をインストールする方法をメモしておきます。 目次 cocoapods インストール時の Operation not permitted エラーを回避する まとめ cocoapods インストール時の Operation not permitted エラーを回避する まず ターミナル.app から普通に cocoapods をインストールしようとします。 すると以下のようなエラーが発生します。 /user 直下への書き込みが制限されているため、cocoapods のインストール先を /usr/local/bin とします。 これで cocoapods のインストールが完了しました。 まとめ セキュリティが強化されることは歓迎ですが、sudo コマンドの万能感がなくなるのは、それはそれで少し不便だったりもします。。 悪質なマルウェアが存在しなければこういうことにはならないのですが、現実世界ではドアに鍵がついているなら、鍵をかけて外出することで、防犯というリスク回避になることと同様、rootless の機能は重要だと感じました。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。

Xcode: 開発のログ・関連ファイル・キャッシュ等を削除する

Xcode で開発を行っていると、プロジェクトファイル以外に多くの関連ファイルが作成されます。 開発機が SSD の場合、ちょっとしたキャッシュもこまめに削除しておかないと、いつの間にかストレージの容量が残り数 GB となった場合、急にビルドが遅くなったり、クラッシュの原因となります。 今回は、iOS アプリ開発時に作成される関連ファイルが保存されている場所や、データを管理するためのメモを残したいと思います。 目次 開発のログ・関連ファイル・キャッシュ等を削除する まとめ 開発のログ・関連ファイル・キャッシュ等を削除する Xcode で開発に関連するファイルは ~/Library/Developer/Xcode/ 以下に保存されています。 各フォルダ内のデータについて Archives テストフライトでのベータ配布時や App Store 申請時にビルドしたアーカイブデータが保存されています。 直近のものは残しておいてもいいですが、半年以上前のものは削除しても問題ないと思います。 DerivedData シミュレータにインストールされたアプリデータや、一時的に開いたプロジェクトに関連する派生データが保存されています。間違って削除しても、プロジェクト起動時には必要なファイルが生成されるので、全削除しても問題ありません。 iOS DeviceSupport 開発機にインストールされている iOS デバイスのサポートファイルがバージョンごとに保存されています。最新の iOS のバージョン – 1.0 あたりまでを残して、古いものは全て削除しても問題ないと思います。 iOS Device Logs 各デバイスのログが保存されています。ログファイル自体は大きいものではないので、無理して削除する必要はないと思いますが、1年以上前のデータは全て削除してもいいのではないでしょうか。 まとめ 開発プロジェクト完了時や、新しい iOS やデバイスがリリースされるごとに、これらのファイルを整理するようにこころがけていれば、快適な作業環境が保てるのではないでしょうか。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。

Xcode: アプリビルド時に dyld`dyld_fatal_error が出た場合の解決方法

アプリのビルド時、dyld`dyld_fatal_error と言うエラーが発生することがあります。 目にする機会は非常に稀ですが、今回はこのエラーが発生した場合の解決方法をメモしておきます。 目次 dyld`dyld_fatal_error が出た場合の解決方法 まとめ dyld`dyld_fatal_error が出た場合の解決方法 Product -> Clean (shift+command+K) でクリーン実行後、ビルドすれば問題は解決します。 まとめ このエラーの解決方法は Clean コマンド一発で済みますが、頻繁に発生するものではなく、どちらかというと開発者側に責任がない(プログラム上に問題がない)ときに起こるため、発生するとすごく焦ります。 自分の場合、開発も終わりに近づき Certificate 周りの変更を Apple Developer 側で行った際に発生しました。 ビルド時おまじないのように、クリーンしてからビルド、という手順が習慣になっていれば、このエラーに遭遇することはまずありませんが、覚えておいて損はないかと思います。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。

Swift: Bridging-Header 作成・設定方法(Xcode 7.2 対応)

現在は Swift が主流となってきましたが、まだまだ Objective-C で書かれたコードも健在で、Swift 上で Objective-C コードのライブラリ等を使用する場合、Bridging Header ファイルを作成する必要があります。 Bridging Header の作成自体は簡単ですが、Xcode での設定の方法をいつも忘れてしまうので、今回は Bridging Header に関する一通りの作成、設定の流れをメモしておきます。 目次 Bridging Header ファイル作成 Xcode の設定 まとめ Bridging Header ファイル作成 Xcode メニューから File -> New -> File を選択します。 Header File を選択します。 ファイル名は任意となりますが、ここでは Bridging-Header.h とし、Create でヘッダーファイルの作成は完了です。 ファイルの中は以下のようになります。 Bridging-Header.h コメントアウトがある部分に、使用する Objective-C ライブラリ等のヘッダーファイルをインポートすれば Bridging Header の作成は完了です。 次項ではこの Bridging Header が使用できるように Xcode の設定をしていきます。 Xcode の設定 TARGETS -> Build Settings を選択します。 Swift Compiler – Code Generation の Objective-C Bridging Header を探します。 Resolved のとなりの空欄をダブルクリックし、以下をコピペします。作成したヘッダーファイル名が Bridging-Header.h 以外の場合はファイル名を書き換えてください。 $(SRCROOT)/$(PRODUCT) の部分は Xcode が自動的にフルパスに変換してくれます。 以上で設定は完了です。 まとめ コードの記述はともかく、ここら辺の単純な設定をいつも忘れてしまうのは自分だけでしょうか。 アプリの開発規模によっては、ビジネスロジックに専念できるまでの工程が多くなってしまうのは仕方のないことですが、ものぐさな自分からすると、今回の場合では Objective-C ファイルをプロジェクトにドラッグコピーするだけで、Swift からアクセス可能になれば便利なのにと思いました。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。

Xcode: UIImageView 表示モード一覧(Xcode 6 Swift 対応)

UIImageView の UIViewContentMode (Scale to Fill や Aspect Fit等) の意味をよく忘れるので、メモしておきます。 UIImageView 表示モード一覧 Scale to Fill 縦横の比率を変え全体表示 Aspect Fit 縦横の比率をそのままに長い辺を基準に全体表示(※空白が発生する可能性あり) Aspect Fill 縦横の比率をそのままに短い辺を基準に全体表示(※空白は発生しない) Redraw Aspect Fillと同じだが、UIImageViewのサイズ変更に追随してリサイズ Center 画像サイズを変えず中央配置 Top 画像サイズを変えず上辺を揃える Bottom 画像サイズを変えず下辺を揃える Left 画像サイズを変えず左辺を揃える Right 画像サイズを変えず右辺を揃える Top Left 画像サイズを変えず上辺・左辺を揃える Top Right 画像サイズを変えず上辺・右辺を揃える Bottom Left 画像サイズを変えず下辺・左辺を揃える Bottom Right 画像サイズを変えず下辺・右辺を揃える まとめ Aspect Fit か Aspect Fill で迷う方が多いと思いますが、これらは Fit(ぴったり合う)、 Fill(満たす)と、素直に英語で判断すればよいと思われます。日本人開発者は損ですよね。。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。

Swift:Optional についての概要と基本的な使い方

Objective-C から iOSアプリの開発を始めた人でも Swift に慣れるにはそれなりにコストがかかります。 Swift を学び始めて誰もが最初に気づく Objective-C との違いは、変数の後に付く ? や !(Optional変数)だと思います。 今回はこの Optional について自分なりにまとめてみようと思います。 optional について まず最初に、Optional というのは型です。Int の Optional型、String の Optional型、といった表現をします。 変数の型が Optional かそうでないかの違いは、変数に nil が入る(もしくは入るかもしれない)か、そうでないかの違いとなります。 このように Optional は nil が入る(かもしれない)値を明示的にする目的で使用されます。 Optional の宣言 Optional の宣言は ? で宣言する方法と ! で宣言する方法があります。 両者の違いは次項で説明するアンラップに関係します。 ? は一般的な Optional 型 ! は暗黙的にアンラップされる Implicitly Unwrapped Optional 型 で、この2つは同じ Optional 型のように扱われがちですが、全然別物です。 はじめに言っておくと ! は特別なことがない限り使用しないほうがいいです。 Optional のアンラップ Optional 型から値を取り出すことをアンラップするといいます。 Optional のアンラップにはいくつか方法があります。 フォースド・アンラッピング (Forced Unwrapping) 読んだ意味そのまま、強制的に値を取り出す方法で ! を使用し値を取り出します。 Optional 変数を通常の変数のように、そのまま出力しようとするとエラーになります。 Optional 変数が nil だった場合にもエラーとなります。 オプショナル・チェインニング (Optional Chaining) ? を使用し値を取り出します。 値が nil だった場合は nil を返します。 オプショナル・バインディング (Optional Binding) Optional 型の変数を代入された変数が、非 Optional 型になることを利用しアンラップする方法です。 上記の例の場合、if で string に値が代入できるイコール optionalStr が nil ではない、という意味となるため、もし optionalStr が nil の場合は println は実行されません。冗長にも思われますが、オプショナル・バインディングを使用すると nil を意識したコーディングとなります。 暗黙的アンラップ (Implicitly Unwrapped Optional) 冒頭で述べた ! で宣言をおこなった値は暗黙的にアンラップされます。 値が nil の場合にはエラーとなります。 このように Implicitly Unwrapped Optional で宣言すると、一見して普通の変数のように扱えるため、Optional に対しての理解がないと ! を乱用してしまいがちです(自分はそうでした)。 ただ、これでは Optional を使用するメリットである nil が入る(かもしれない)値を明示的にする、という意味がなくなってしまいます。 ! での Optional 宣言は、オブジェクトの初期化のときに「どうしても初期値が nil でなければいけない場合」にのみ使用するものとなります。 宣言時は nil にするしかないが、宣言後には常に何かの値が入っていることを前提とした場合にのみ ! (Implicitly Unwrapped Optional) で宣言すればよいでしょう。 まとめ Optional は 基本的には ? を宣言し使用することで、Optional の目的である nil を意識したコーディングが行え、コンパイラの nil 値のチェックが容易になります。 nil を返す(かもしれない)関数の戻り値を処理する場合はオプショナル・バインディングのように、まず Optional 変数で受け取り、Optional のラッピングを解いて処理をする という使い方ができるようになります。 Optional 型に慣れるまではコーディング中やビルド時に、幾度と無くエラーとなってしまいますが、そのほとんどは Xcode が自動で対処(サジェスト)してくれるため、まずはガンガン使ってみるのが一番の習得方法だと思います。 この記事がみなさんのお役に立ちましたら、下記「Share it」よりブックマークやSNSで共有していただければ幸いです。