はじめに
iOSアプリエンジニアとして現場で働いて 1 年 5 か月が経ちました。
現場では Objective-C ばかりで Swift は個人開発だけなので
Swift に関するところは説得力ないかもしれないです。
初めて現場にジョインした際ある程度準備していたつもりでしたが，
役立たずで最初の現場では本当に色々教えていただきました。
今でも感謝でいっぱいです。
というのもふまえて
初めて iOS アプリエンジニアとして現場にジョインする
ときにあったらいいかも知識について書きたいと思います。
自社案件，受注案件だと少し勝手が違うと思いますので(経験ない)，
一部 SES 寄りのお話としてお読みください。
時期的にアレですが，春からジョインという学生さんもいると
思いますし，中途であればタイムリーな方々もいると思うので
少しでも役立てばなぁと思います。
また，現場によって大きく異なりますので，
一部はまったく不要かもしれないし，
一部はもっと特化すべきだったりするかもです。
基本的な知識(コト)
技術的なベースというか，何も知らずというか研修等なく，
現場に入ることはないとは思いますが，一応こんな感じかなと。
UNIX とか
Unix の知識はやはりいると思われます。
少なくとも Terminal.app とは仲良くしておいた方が良いです。
プログラミングする上である意味基本なので，基本的な
コマンドは最低限覚える。新しい Mac を買ったらまず
最初に Dock に突っ込むレベルのアプリであります。
homebrew でもいいし macports でもいいので，
〇〇インストールしてください！
と言われてすぐ対応できるレベルはあったほうがいいですかね。
あとは makefile 作れなくていいので configure して，
make して make install くらいできれば。
でも iOS アプリ開発では使う場面はほぼないかと。
日本語・英語
日本語でバグ報告など文章を書くことも多いので，
文章はしっかり書けるようにする。(私もまだまだ)
日々のコミュニケーションはしっかりできるように。
iTunes Connect のリジェクト時の対応や新 iOS の
beta 期間中の Apple へのバグ報告などももちろん英語だし，
バグ修正で詰まったとき，Qiita や他のブログさまなどの
日本語の記事などで解決できたらいいですが，
うまく見つけられない場合，Apple のドキュメントや
海外の stackoverflow などに頼ることになります。
すらすら訳すことができなくても今は翻訳サイトも充実
(最近 Google 翻訳久しぶりに使って驚いた)しているし，
少なくとも苦手意識は取り払っておくべきです。
Word・PowerPoint・Excel
iOS アプリ制作だったら Mac だし，こういうツールって
Pages・Numbers・Keynote でしょ？
というのがまずあるけど，リーダーが Windows しか使って
なかったり，もっと上の(察してください)が使ってたりするので
必要ですね。
各種仕様書などはこれらを使っていることは多いです。
現場の経験浅いと，動作確認を担当することも多いです。
テストばかりでコード書きたいと嫌になってはいけません。
アプリ全体の画面や動きを把握させたいという意図もあるかもしれません。
テストケースはエクセル，マークダウンなど現場によって
色々違いますが，エクセル苦手だと辛いことがあります。
(他人事じゃない・・・)
Swift・Objective-C
UIKit など画面寄り，iOS 特有のものを使えるようにはしておく。
AutoLayout も最近では必須だと思う。
画面(遷移)仕様書見てコードが妄想できるくらいなるといいけど，
TableView や CollectionView は奥が深すぎるので，
自学で，業務で実装しながら覚えていく感じでいいかもしれません。
全てのプログラミング言語にいえることかもしれませんが，
参考書開いて 1 ページ目からただ読んでいくのは良くないと思います。
実際にエディタに，playground に打ち込んで動作させながら〜
というのが良いと思います。
iOS の場合，画面が出来ていってどんどん充実してくるのが
目に見えるのが醍醐味というか喜びになりますよね。
基本的な考え方というかプログラミングの基礎はこれ！的な言語は
持っておいた方がいい。オブジェクト指向じゃないけど C 言語とか。
最近は iOS に関する情報は多いので調べたら大概のバグは修正できたりします。
お役に立った Qiita の記事には いいね しましょう！
そして自分も知識の整理のために記事書いて Contribute しましょう。
Git
プロジェクトのファイル管理について
Perforce や TortoiseSVN などの SubVersion で
管理している場合もある(ドキュメントはこういう系は多い)が，
大抵のソースコントロールは Git になります。
頭では理解していても実際に扱うようになると途端に
わからなくなることもあるので実践あるのみだと思います。
今年の 5 月に下記の記事を書きましたが，
ある程度わかってくるとサクサク作業できるようになります。
Gitの知識がほとんどなかったiOSエンジニアがいままで現場で使ったコマンドまとめ
http://qiita.com/MilanistaDev/items/af26a2c077924957dd0b
これに今追加するとしたら，revert と tag くらいですかね。
調べてもわからない，少しでも不安があれば詳しい人に聞きましょう。
その push が，rebase がみんなに迷惑をかけることになるかもしれません。
リポジトリがなんかおかしくなったら最悪 clone し直すという手もあります。
Xcode 周り
だいぶ iOS 関係の情報は日本語でも充実してきているので，
次は Xcode をある程度使いこなせていると色々時短できる。
ショートカットは ⌘ + Shift + o と ⌘ + Shift + j はよく使いますね。
ファイルを探してどこにファイルがあるか確認できますね。
他にもいっぱいあるのでここでは省きます。
ブレークポイント
デバッグには必須です。
この画面の文字列が表示されないなー表示がおかしいなー
この変数にちゃんと文字列入ってるかなとか，
この条件文に入ってくれ・・・ないやんかーとか
実行(操作)しながら確認します。
アプリが落ちるのなんで？ここで Exception が起きてる。
この配列の要素数 0 やん。的な感じです。
見たい行のとこをクリックでブレークポイントがつきます。
操作して処理が走るとここで止まります。
ブレークポイントはりすぎたら
左側のペインのブレークポイントのところで
まとめて消せます。
Exception 起きたら止まってくれるので
All Exceptions は常にはっておいた方がいいかもです。
Comparison
Git で管理していると Xcode 上で差分が見れます。
右上のやつを Comparison にする。
Xcode のエディタが分割されて左が今の状態，右が修正前の状態です。
青い部分が追加したもの。下記画像にはないですが，オレンジだと
変更したものって感じです。
真ん中の部分を選択すると元に戻せます。
無駄な修正(空行，スペースも含む)をレビューに出すと
怒られることもあるので，直接関係のない無駄な修正がないか，
仮実装で入れてたものをレビュー依頼前に元に戻したりというときに使えます。
一番下のものは今のブランチとリビジョンになります。
ここを自在に操れるようになるとバグ修正ではかなり楽しくなります。
詳しくは省きますが，前の実装ではどうなってたの？とか
さかのぼるときに有用です。
リビジョン(コミット)を選択すれば，右側はそのときのソースになります。
前に戻れば戻るほど差分は増えますが，あーここでデグレが起きたのかとかがわかって Discard してデグレ前のソースに一部だけ戻すこともすぐできます。
このリビジョン番号じゃすぐにはちょっとわからないってときは，
Blame や Log の出番です。
Blame
右上のやつを Blame にしてみましょう。
これは本当に便利で使わない日はないといっても過言ではないです。
前に記事書いていたので参考にしてください。
[Xcode]この素晴らしい(クソ)コードは誰が書いたのか調べる方法
http://qiita.com/MilanistaDev/items/5d7e1a7c36a0e8ba94a0
チケットで課題管理している現場ではチケット番号を
コミットするときにコミットメッセージに残しておくと
過去にどういう経緯でこういうコードになったのか，
チケット見て対処を考えたり，よくわからんなー実装したのは・・・
〇〇さんだから詳しく実装について聞いてみよう！
といった感じで使いこなせればみんなが幸せになります。
で，だ。
改行コードがおかしいから，スペースがタブになってたから全部修正したわー
っていうありがた迷惑なコミットが全部を台無しにすることが
あります。その場合は，Comparison の最後で書いたように，
(迷惑な)リビジョン番号を確認して，そのリビジョンより
前に戻ると確認できるようになります。
チーム内で方針はあらかじめ確認しておくといいです。
Debug View Hierarchy
今の画面をシミュレータでグリグリ動かせる。
用途としてはあるはずの View，UI 部品が見えない，
逆になぜか表示されているなどといったときです。
先日もこれのおかげで昔対応したバグの修正方針が
やはり小手先だけの修正だとまずかったことがわかって
当時のモヤモヤが一気に解消されました。
前に記事書いたのですが，
[Xcode]なぜ表示されない・・・ビルドしたアプリのViewの重なりをXcodeで確認する方法
http://qiita.com/MilanistaDev/items/adbf38d186e9727ea7dc
今年の Advent Calendar の @Akatsuki さんが記事の方が詳しくてよかったです。
デバッグのためにView階層を把握する
http://qiita.com/akatsuki174/items/45d4bd7cb150defbf116
知らないと実機とのにらめっこの時間が増えて，
無駄に工数かかる可能性があるかなーと思います。
Xcode 8 からは Debug Memory Graph とかも
使えるようになったし，Instruments なども使えるといいですが，
ちょっと敷居が高い気もするのでまたの機会にでも・・・
Mac 周り
Linux 使いなら問題ないかもですが，Windows ユーザがいきなり使うと・・・
操作は触っていれば慣れるので特に書かないです。
画面収録
実機での動作を収録する際に使えます。
実機を Mac に接続。
QuickTime Player.app を起動して，
ファイル -> 新規ムービー作成
録画ボタンの横のプルダウンで実機を選択すると・・・
バグが見つかって再現確認した際など
App Store に紹介用のムービーを作るときなど，もちろん遊びでも使える。
ブラックマジシャンガールの召喚シーンとか自分用に。
一番嫌なのが，FaceTime カメラが起動して初回のみ自分の顔が映ること＞＜
動画ファイルは重いので GIF 形式にするかはお任せします。
おわりに
初めてiOSアプリエンジニアとして現場にジョインするときにあったらいいかも知識について書きました。
だいぶ偏りがあって，またもっと書くこと(UnitTest，AutoLayout とか)があったのですが，またの機会に回そうと思います。誰かのお役に立てば嬉しいです。
乱文長文となりましたが，最後までご覧いただきありがとうございました！！
網羅できているとも思いませんし，この知識はあった方がいいとかありましたら，ご教示いただきたいです。