iOSエンジニアのフリーランス案件の仕事内容|案件の種類と1日・1か月の流れ
公開 2026-11-04 監修:株式会社エージェントベスト
フリーランスのiOSエンジニアの仕事は、Swiftで画面と機能を作り、テストを通し、App Storeの審査を経て利用者に届けるまでの流れを、チームの一員として回すことです。ただし、運用中のアプリに入るのか、ゼロから作るのか、古いコードを置き換えるのかで、1日の時間の使い方も、話す相手も、手元に残る成果物も変わります。
この記事では、iOSの業務委託案件を5つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。独立までの準備はiOSエンジニアがフリーランスになるには、求められる技術はiOSエンジニアのスキルの記事で扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。
iOS案件の仕事は「アプリの状態」で決まる
同じ「iOSエンジニア募集」でも、参画するアプリがどの状態にあるかで仕事の中身が大きく違います。おおむね次の5種類に分けられます。
| 案件の種類 | 主な相手 | 時間を多く使う仕事 |
|---|---|---|
| 運用中アプリの機能追加 | PdM、デザイナー、サーバー側の開発者、QA | 機能の実装、コードレビュー、定期リリース |
| 新規アプリの立ち上げ | 発注元の責任者、デザイナー、API設計の担当者 | 設計の方針決め、土台づくり、初回の審査対応 |
| 書き換え・移行 | テックリード、既存の開発メンバー | 既存コードの読み解き、段階的な置き換え、回帰の確認 |
| 受託開発 | 受託会社のPM・ディレクター、発注元の担当者 | 仕様の確認、見積もりへの協力、納品と検収の対応 |
| 共通基盤・SDK | 社内の各アプリチーム | モジュールの設計、APIの整備、ドキュメント |
運用中アプリの機能追加は案件の数が多く、フリーランスのiOSエンジニアが最初に入ることの多い型です。以下では、それぞれの典型的な流れを紹介します。時間の配分は現場によって違うため、目安として読んでください。
運用中アプリの機能追加
1日の流れ(例)
朝はチームの朝会で、前日の進み具合と、つまずいている点を共有します。午前中は担当するチケットの実装を進め、昼をはさんでほかのメンバーのプルリクエストをレビューします。午後はデザイナーと画面の細部を詰めたり、サーバー側の開発者とAPIのレスポンスの形を確かめたりします。夕方はシミュレーターと実機で動きを確かめ、プルリクエストを出して1日を終えます。
運用中のアプリでは、新しいコードを書く時間と、既存のコードを読む時間が同じくらいあるのが普通です。画面ひとつ直すにも、どこから呼ばれているか、どのデータに依存しているかを確かめる必要があるためです。
1か月の流れ(例)
- スプリントの始め:PdMと優先順位をすり合わせ、担当する機能を見積もる
- スプリントの途中:実装とレビューを回し、TestFlightで社内のテスターに配って確認してもらう
- リリース前:QAの指摘を直し、リリースノートを用意し、審査に提出する
- リリース後:クラッシュの報告やレビューの評価を見て、必要なら修正版を出す
リリースを2週間ごとなど決まった間隔で回すチームでは、この流れが月に1〜2回まわります。
成果物
機能のコード、ユニットテストやUIテスト、プルリクエストの説明、TestFlightの配布ビルド、リリースノート、仕様の確認メモなどです。審査への提出そのものは、社員やリードが担当する現場もあれば、フリーランスが任される現場もあります。
新規アプリの立ち上げ
1日の流れ(例)
立ち上げの初期は、コードを書くより決める仕事が多くなります。画面の作り方をSwiftUI中心にするか、最低対応OSをどこにするか、画面とデータの分け方をどうするか、ライブラリを何に頼るか。こうした方針を、発注元の責任者やほかの開発者と相談しながら決め、決めた理由を文書に残します。
方針が固まると、ログイン、通信、画面遷移、エラー表示などの土台を作り、その上にほかのメンバーが機能を足せる状態にしていきます。
1か月の流れ(例)
- 最初の数週間:要件と画面の流れの確認、技術の方針決め、プロジェクトの雛形づくり
- 中盤:主要な画面の実装、APIとの結合、テストとビルドの自動化
- 初回リリースの前:プライバシーに関する表示や同意の画面の確認、審査に出す情報の準備、審査の指摘への対応
成果物
設計の方針をまとめた文書、プロジェクトの雛形、共通の部品、主要な画面、ビルドと配布の仕組み、審査に出す情報の下書きなどです。立ち上げの案件では、あとから来る人が迷わないための文書の重みが増します。
書き換え・移行の案件
Objective-CからSwiftへ、UIKitからSwiftUIへ、古い非同期処理からSwiftの並行処理(async/await)へ、といった置き換えを担う案件です。アプリを止めずに少しずつ移すため、新しいコードを書く力より、壊さずに移す段取りの力が問われます。
1日の多くは、既存のコードを読み、どこから手をつけるかを決め、置き換えた部分に既存と同じ動きをさせることに使われます。1か月の単位では、置き換える範囲を区切って計画し、区切りごとに回帰テストを行い、通常の機能追加のリリースに混ぜて少しずつ出していきます。
Appleは、App Storeに提出するアプリをビルドするXcodeやSDKの版、最低対応OSについて、要件を順に加えています。たとえば2026年4月28日からは、Xcode 26以降とiOS 26などのSDKでビルドすることが、2026年9月9日からは、iOS 13以降を対象にすることが求められています(2026年10月時点、Apple Developerの案内による)。こうした要件への追従が、移行の案件が生まれるきっかけになることもあります。
成果物は、移行の計画、置き換えたコード、回帰テスト、移行の手順や残っている課題の記録などです。
受託開発の案件
開発会社が発注元から請け負ったアプリの開発に、iOSの担当として参画する案件です。仕様は発注元と受託会社の間で決まり、iOSエンジニアは受託会社のPMやディレクターを通して確認することが多くなります。
1日の流れは機能追加の案件と似ていますが、仕様の不明点を確かめる手間が増えます。直接聞ける相手が限られるため、確認事項をまとめて出し、回答を記録に残す仕事が欠かせません。1か月の単位では、工程の区切りに合わせて発注元の確認を受け、指摘を直し、納品と検収に向けた準備を進めます。
成果物は、コード、テストの結果、仕様の確認の記録、納品物の一覧などです。配信に使うApple Developer Programのアカウントは、個人・組織のどちらでも登録できるため、どのアカウントで申請するかを最初に確かめておく必要があります(2026年10月時点、Appleの案内による)。
共通基盤・SDKの案件
複数のアプリを持つ会社で、ログインや決済、分析、デザインの部品など、各アプリで使う共通のモジュールを作る案件です。画面を作るより、ほかの開発者が使う部品の使いやすさを考える時間が長くなります。
各アプリのチームから要望を集め、APIの形を決め、破壊的な変更を避けながら版を上げていきます。成果物は、モジュールのコード、APIのドキュメント、サンプルアプリ、版ごとの変更点の記録などです。
どの案件にも共通する仕事と関わる相手
種類が違っても、次の仕事はほぼすべてのiOS案件にあります。
- 実機での確認:シミュレーターでは分からない動き(カメラ、通知、通信の切り替わり、端末ごとの画面の大きさ)を実機で確かめる
- TestFlightでの配布:テスターや関係者に試してもらい、指摘を受け取る
- OSの更新への対応:新しいOSの公開に合わせて、表示の崩れや非推奨のAPIを確かめる
- 稼働の記録と報告:精算のために作業時間を記録し、週や月の単位で報告する
関わる相手と、渡すものを整理すると次のようになります。
| 相手 | 渡すもの |
|---|---|
| PdM・発注元の担当者 | 見積もり、進み具合、仕様の確認事項 |
| デザイナー | 実装上の制約、画面の動きの確認 |
| サーバー側の開発者 | APIへの要望、結合で見つけた不具合 |
| QA | テスト用のビルド、修正の内容 |
| Androidの開発者 | 仕様のそろえ方、共通の不具合の情報 |
働く場所については、運用中アプリの機能追加はリモートで回しやすく、検証用の端末や機器との連携が絡むと出社が求められやすくなります。詳しくはiOSエンジニアのリモート案件の記事をご覧ください。Androidの案件の仕事内容はAndroidエンジニアの仕事内容で解説しています。
よくある質問
フリーランスのiOSエンジニアも、App Storeの審査への提出まで担当しますか?
現場によります。社員やリードが提出と審査の窓口を担う現場もあれば、フリーランスに任される現場もあります。提出を担う場合は、審査の指摘への対応やリリースの判断にどこまで関わるかも、参画前に確かめておくと安心です。
iOSだけでなくAndroidも担当することはありますか?
FlutterやReact Nativeなど、両方のOSを一つのコードで作る現場では、両方に関わることがあります。iOSのネイティブ開発の案件でも、仕様をそろえるためにAndroidの担当者とやり取りする機会は多くあります。
参画して最初の1か月は何をすることが多いですか?
開発環境の準備、コードの構成の把握、小さな修正でのリリースの流れの確認から始めるのが一般的です。進め方はiOSエンジニアの参画初月にやることで詳しく解説します。
参考にした公的情報・資料
記事の内容は公開日時点の情報にもとづきます。制度や税率は変わることがあるため、手続きの前に必ず各機関の最新情報をご確認ください。