iOSエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのiOSエンジニアがつまずきやすいのは、App Storeの審査の通過を「完成」の条件にされる契約、Macや開発者アカウントの扱いのあいまいさ、既存コードの読み違い、Appleの更新が重なる時期の稼働の膨らみです。どれも、アプリを動かすだけでなく、Appleの仕組みの中で届け続けるというiOSの事情から起きます。

対策の基本は、つまずきの種を契約と参画初期の取り決めで小さくしておき、現場では記録と早めの共有で守ることです。この記事では、契約・現場・技術・お金の順に、iOSならではの場面と対策を整理します。契約前に確かめる項目の一覧はiOSエンジニアがフリーランスになるにはで扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

審査の通過が完成の条件になっている

請負の契約で「App Storeでの公開」を納品の条件にすると、審査で差し戻されたときに、いつまでも完成しない状態になりかねません。審査の判断はAppleが行うもので、作り手が結果を約束できるものではないからです。差し戻しの理由が、アプリの機能ではなく、発注側のアカウント情報や掲載内容にあることもあります。

対策：請負で受けるときは、何をもって完成とするか（審査への提出までか、指定した環境での動作確認までか）を契約で決めておきます。差し戻しへの対応が追加の作業になるのか、契約の範囲に含むのかも書いておくと安心です。準委任と請負の違いは準委任と請負の違いをご覧ください。

業務範囲が「iOSアプリ開発」だけになっている

契約書には「iOSアプリの開発支援」とだけ書かれ、現場ではAndroidの不具合の調査、サーバーのAPIの修正、ストアに載せる画像の差し替えまで頼まれる、という食い違いが起きることがあります。モバイルの現場は人数が少なく、境目のない仕事が回ってきやすいのが特徴です。

対策：参画前に、担当するもの（iOSの実装、レビュー、審査への提出作業など）と、担当しないものを言葉で確かめておきます。範囲の外の依頼が来たときの扱いは業務範囲が変わったときの記事と追加の依頼の断り方をご覧ください。

指揮命令の形が社員と変わらなくなる

社内のiOSチームに深く入ると、勤務時間や作業の手順まで細かく指示されるようになることがあります。準委任の契約と実態がずれてくる状態で、考え方は偽装請負の記事で解説しています。

現場でのつまずき

Macと開発者アカウントの準備で動けない

iOSの開発は、Macと検証端末、そして発注側の開発者アカウントへの招待がそろわないと始まりません。貸与のMacが届かない、証明書やプロビジョニングの権限がもらえない、といった理由で、参画して数日をビルドもできずに過ごすことがあります。

対策：参画前に、Macは貸与か持ち込みか、検証端末はどれを使うか、App Store ConnectとTestFlightでどの権限をもらえるかを窓口と確かめておきます。届くまでの間は、コードや設計資料を読む時間にあてられるよう、リポジトリの閲覧だけでも先にもらえないか相談するのも一つの方法です。

リリースの手順が人に依存している

運用中のアプリでは、審査への提出や証明書の更新を、特定の社員だけが手作業で行っていることがあります。その人が休むとリリースが止まり、急に代わりを頼まれて手順が分からない、という事態になりがちです。

対策：参画の初期に、ビルドから提出、段階的な公開までの手順が書き残されているかを確かめます。書かれていなければ、自分が関わる部分から手順を残していくと、チームからの信頼にもつながります。

既存チームの書き方を早く変えすぎる

前の現場でうまくいった設計の型や、好みのライブラリを、参画してすぐに持ち込むと反発を招きやすくなります。とくにSwiftUIとUIKitが混ざるアプリでは、どちらで書くかに現場なりの理由があることも多いものです。

対策：最初は既存の書き方に合わせ、困っている点が見えてから一つずつ提案します。提案するときは、変えると何が良くなり、変えないと何が起きるかを添えます。

技術でのつまずき

古いコードと新しいコードの境目を読み違える

Objective-C、UIKit、SwiftUI、Combine、async/awaitが一つのアプリに混ざっていることは珍しくありません。どこが古い作りで、どこから新しい作りに移ったのかを読み違えると、修正が思わぬ画面に影響します。

対策：最初の数週間は、変更を小さく区切り、影響する画面をテストやTestFlightのビルドで確かめてからレビューに出します。求められる技術の幅はiOSの案件で求められるスキルで整理しています。

Appleの更新の影響を見落とす

Appleの要件は毎年のように変わります。2026年10月時点のApple Developerの案内では、2026年4月28日以降、App Store Connectにアップロードするアプリは、Xcode 26以降とiOS 26などのSDKでビルドすることが求められています。Xcodeを上げたら、使っている外部ライブラリが新しいSDKに対応しておらず、ビルドが通らない、という事態も起きます。

対策：新しいOSのベータ版が出た段階で、手元でビルドと主要な画面の確認を試し、影響のありそうな点を一覧にしてチームに共有します。対応を誰が担うかを早めに決めておくと、提出の期限の直前に慌てずに済みます。

実機でしか起きない不具合を後回しにする

シミュレーターでは動いても、実機ではカメラ、通知、Bluetooth、バックグラウンドでの動作などで問題が出ることがあります。リモートの案件では実機での確認が後回しになりやすい点に注意が要ります。進め方はiOSエンジニアのリモート案件の記事をご覧ください。

お金でのつまずき

Appleの更新の時期に稼働が膨らむ

新しいOSの公開の前後や、提出要件の期限が近い時期は、対応の作業が集中します。精算の幅を超えて働いても、契約によっては報酬に反映されないことがあります。

対策：契約の精算の幅と、超えたときの扱いを確かめ、稼働の見込みが幅を超えそうなら早めに窓口へ伝えます。考え方は精算幅の記事で整理しています。

機材の負担を見込んでいない

自分のMacや検証端末を使う案件では、機材の更新や、新しいOSに対応した端末の購入を自分で負担することになります。報酬の額面だけで条件を判断すると、思ったより手元に残らないことがあります。

対策：持ち込みの機材を使う案件では、機材の費用を年単位で見積もり、報酬との釣り合いを考えます。報酬の決まり方と機材の扱いはiOSエンジニアの報酬の記事で触れています。

支払いの時期を確かめていない

フリーランス法では、発注側は成果物などを受け取った日から60日以内のできる限り短い期間で支払期日を定めることになっています（2026年10月時点、公正取引委員会の案内による）。請負で審査を待つ形の契約では、いつを「受け取った日」とするかで支払いの時期が変わることもあります。支払条件の見方は支払条件の記事をご覧ください。

つまずきを防ぐ参画初期の取り決め

ここまでの対策をまとめると、参画の初期に次の点をそろえておくと、多くのつまずきを防げます。

1. 機材とアカウント：Mac、検証端末、App Store ConnectとTestFlightの権限
2. 担当の範囲：iOSの実装・レビュー・提出作業のどこまでか、Androidやサーバーに触れるか
3. リリースの手順：誰が提出し、差し戻されたら誰が対応するか
4. 相談の窓口：設計の判断を誰が持つか、問題が起きたら誰に伝えるか

最初の1か月の進め方はiOSエンジニアの参画初月にやることで整理しています。

よくある質問

審査で差し戻されたら、フリーランスの責任になりますか？

準委任の契約では、専門家として通常求められる注意を払って業務を行うことが約束の中身で、審査の結果そのものを約束するものではありません。請負の契約では、何を完成とするかの書き方によって扱いが変わります。契約書の文言に迷う場合は、弁護士などの専門家にご相談ください。

自分のMacを使う案件で、業務のソースコードを置いても大丈夫ですか？

発注側の情報管理の決まりによります。持ち込みの機材にソースコードを置いてよいか、ディスクの暗号化や画面ロックなどの条件があるかを、参画前に確かめてください。決まりが書面にない場合は、窓口に確認してから作業を始めると安心です。

参画してすぐ、Androidの対応も頼まれました。引き受けるべきですか？

契約の業務範囲に含まれるかを先に確かめます。範囲の外であれば、引き受けるかどうか、引き受ける場合の稼働と報酬の扱いを窓口と決めてから進めます。範囲の変え方は業務範囲が変わったときの記事をご覧ください。