サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
こんにちは。モバイル基盤部の@giginetです。平成最後のエントリを担当させていただきます。 iOSアプリの開発では、Xcodeが生成するプロジェクトファイルである、*.xcodeprojをリポジトリで共有するのが一般的です。 しかし、この運用は大規模なプロジェクトになるほど、数多くの課題が発生します。クックパッドiOSアプリは巨大なプロジェクトであり、通常の*.xcodeprojによる管理には限界が生じていました。 そこで、昨年秋にXcodeGenというユーティリティを導入し、プロジェクト管理を改善したので、その知見をお伝えします。 従来のプロジェクト管理の問題点 ファイル追加の度にコンフリクトが発生する *.xcodeprojファイルはプロジェクトに含まれるソースファイルの管理を行っています。 開発者がプロジェクトにファイルを追加すると、このプロジェクトファイルが更新されることにな
以下のTwitterアンケートを見かけたので、記事書いてみました。 結果は、母数が10人なので参考程度にするのが良いと思いますが、僕も多数派の「CocoaPodsもCarthageも含めている」を特に迷い無く選択しています僕は今ではCocoaPodsもCarthageも含めていない運用にしています。 【iOSアプリプログラマに質問】 あなたはアプリのリポジトリにCocoaPodsで取得したソースコードやCarthageでビルドしたフレームワークを含めていますか？ — りず (r.izumita) (@rizumita) October 6, 2016 ちょうどCocoaPodsのガイドにこのことが記載されているので、まずはその訳を載せます。 (この記載はわりと有名なはずで、ここでオススメされているからバージョン管理に含める選択を取っている人も多そう。)CocoaPodsのガイドの訳 原文
非エンジニアリング脳なデザイナーが新規アプリ開発の現場でXcodeを使用することがどのような影響を与えたか。について、自身の経験を元にまとめました。
About the content This content has been published here with the express permission of the author. Carthage is a new dependency manager for Objective-C andSwift projects, intended to be thesimplest way to add frameworks to aCocoa application. Carthage works by delegating tasks to Xcode and Git, minimizing new concepts as much as possible, so you can continue to use the tools you’re already famil
海外事業向けのiOSアプリケーション開発を担当している西山(@yuseinishiyama)です。クックパッドは現在、海外複数カ国に向けてサービスを展開しています。 主にObjective-Cで記述されたアプリケーションを全面的にSwiftに書き換える機会があったので、その際に得た知見や書き換えるに至った動機を共有します。 書き換えに至るまでの経緯 この項では、書き換えに至るまでの経緯について説明します。 Objective-C期 アプリケーションの開発は2014年7月頃にスタートしました。Swiftの発表直後でしたが、時期尚早ということもあり、Objective-Cで実装することになりました。 Objective-C、Swift混在期 2014年10月頃から、Swiftへの段階的な移行のために、新規のコードをSwiftで書くようになりました。Swiftの記述力や、ヘッダと実装を行き来しな
Brian Gesiak さんをゲストに迎えて、Facebook, ComponentKit,React Native,Swift, Quick, Xcode などについて話しました。 ShowNotes Facebook's iOS Infrastructure - @Scale 2014 F8 2015 - Facebook on iOS: Inside the "BigBlue App" ComponentKit | AReact-inspired view framework for iOS ComponentKit | WhyC++React Native AsyncDisplayKit Nuclide - a unified IDE Thoughts on Atom modocache/GiftSwiftGit2/SwiftGit2SwiftAPIs: Ge
CocoaPodsのgitを利用するアクションが全く成功しなくなります。具体的にはpod install, pod updateなどが全く通りません。 公式ブログにあるとおり、0.34.0以上からCocoaPodsは高速にgitリポジトリをcloneするため--depth 1 (shallow clone) オプションを採用するようになっています。しかしながらGitHub:Enterprise側の技術的問題なのか、GitHub:Enterprise内のgitリポジトリに対するhttpないしhttps経由でのshallow cloneが成功しないため永遠にpod installやpod updateが終わりません。
以上で導入は完了です。 元々のプロジェクト(Hoge.xcodeproj)とは別にワークスペースが(Hoge.xcworkspace)作成されるので、以降の作業ではこちらを使うようにします。 Project Navigatorは以下のようになっているはずです。 どうやらライブラリ群をlibPods.aというスタティックライブラリにまとめて、リンクしているようです。CocoaPodsの良いところ git submoduleを直接使っている場合と比較したメリットを書きます。プロジェクトへの導入の自動化 git submoduleはライブラリのソースコードを管理するのであって、 どのようにXcodeプロジェクトに導入されるかまでは管理していません。 つまり、ライブラリを導入するには手動で以下の手順を行う必要があります。 導入に必要なファイルのみをXcodeプロジェクトに追加 必要に応じてフレ
久しぶりにテストを書く このブログも独自ドメインではてなブログに移行して読者数が一気に減ってしまいましたが、半年以上前のホッテントリぶりにブログ書きます。 前回は iOS 開発環境における CI 導入についてでしたが、今回はもう一度テストに戻って、その中でも iOS における Integration Test の実行方法について書きたいと思います。 Integration Test って？ 日本語では良く結合テストと呼ばれていますが、iOS 開発ガイドなどでは単体テストをロジックテストと呼び、結合テストはアプリケーションテストと呼んでいます。 結合テストはUI テストとも呼ばれる場合もあったり、このブログで紹介した GHUnit でも最近では ViewController のテストができたりと境界は結構曖昧です。 僕の iOS におけるテストのイメージとしては、 Unit Test はコ
2015年11月9日追記：以下の内容は Xcode 4 までに対応しています。最近の Xcode に対応するにはgithub.com/github/gitignore の Objective-C.gitignore を使うことをお勧めします。（追記終わり） Xcode で作ったプロジェクトを Git で管理するにあたってめんどくせえーのは、 .xcodeproj の中にプロジェクトのデータとユーザデータが一緒に入ってる点です。普通に空のプロジェクトを作るとこうなります： Xcode 3: - $PROJ.xcodeproj/ - project.pbxproj - $USER.mode1v3 - $USER.pbxuser Xcode 4: - $PROJ.xcodeproj/ - project.pbxproj - project.xcworkspace/ - xcuserdata/
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
