iOSエンジニアはきつい？応募先でもOS対応は仕事に残る。受託・自社の手がかりは求人、担当本数は面接

最近、iOSエンジニアとして働いていて、辞めたい、きついと思った場面を3〜5個、まずは回数か期間と一緒に書いてみてください。会社を移っても、OS対応、情報収集、リリース前に忙しくなる場面はアプリ開発の仕事に残り、iOSではApp Storeの審査も続きます。求人票では受託か自社か、担当OS、古いコードの改善・移行を読み、担当アプリの本数、申請の段取り、OSごとの人数は面接で聞きます。 厚生労働省の職業情報提供サイトのjob tagも、OSが新しくなるとアプリのバージョンアップ対応が必要になり、開発業務の何割かを占めると説明しています（「ソフトウェア開発（スマホアプリ） - 職業詳細」、2026年9月30日確認）。例にするのは、自社サービスのiOSアプリを4年担当し、2人でOS対応とUIKitからSwiftUIへの移行を進める架空の人です。

iOS・Androidの開発を辞めたい場面を、今の職場の値と一緒に書く

きつい、追いつけない、属人化している、という言葉だけでは、応募先との違いを比べられません。最近辞めたいと思った場面を3〜5個選び、担当アプリ数、人数、回数、期間、仕事の割合、平常時とピーク時の実残業を添えます。

例の人について書くと、次のようになります。値はすべて架空ですが、求人票と面接でも同じ単位を使います。

辞めたい場面	今の職場の値	比べる単位	確認先
OS対応の間、機能開発が進まない	iOS担当2人。直近の対応は6週間で、機能開発を3週間止めた	OSごとの人数、週数、止めた期間	予定表、担当表
App Storeへの提出が戻り、公開が遅れた	直近の公開で1回戻り、予定より2日遅れた。申請は本人	回数、日数、申請する人	申請履歴、公開予定表
UIKitからSwiftUIへの移行が終わらない	直近3か月は移行が仕事の3割	期間、仕事の割合、対象画面	予定表、チケット
新しい情報を追う時間が業務外になる	直近1か月は業務外に4時間	月の時間、業務内の時間、費用	予定表、経費精算
リリース前に残業が増える	平常月18時間、直近のリリース前月42時間	同じ担当者の月の実残業	勤怠、公開予定表

受託開発なら、担当アプリの本数も先に書きます。たとえば、過去に納品したアプリを同時に何本更新し、1本に何週間かかり、保守契約がない場合の費用を誰が負担したか、まで分けます。複数案件を抱えるつらさは、1本あたりの期間だけでなく、更新する本数と組み合わせないと応募先と比べられません。

三つの置き場所を決めてから、例の人の場面を分ける

例の人の場面を振り分ける前に、三つの区分を決めます。

• アプリ開発を続けるなら残る側: OS対応や情報収集のように、スマホアプリを出し続ける仕事に含まれる場面です。iOSではApp Storeへの提出と審査もここに入ります。
• 会社ごとに確かめる側: 受託か自社か、更新対象の本数、費用、申請する人、担当人数、移行の進み方、学ぶ時間、実残業など、応募先の値を確かめる場面です。会社を移れば必ず軽くなるという意味ではありません。
• 今は分からない側: つらい場面はあるものの、原因を一つに分けられない状態です。現職の記録から相手・回数・期間・決めた人を足して、置き直します。

一つの場面に二つ以上の原因があれば、別の行にします。例の人の場面を分けると、次のようになります。

分けた場面	最初に置く側	そう置く根拠	次に確かめる値
新しいOSに合わせてアプリを直す	アプリ開発を続けるなら残る側	job tagとAppleの公式要件がOS対応を示す	対応したOS・SDK
iOS担当2人で、機能開発を3週間止めた	会社ごとに確かめる側	担当人数と仕事の配分はチームごとに決まる	OSごとの人数、止めた期間
App Storeへ提出し、審査を受ける	アプリ開発を続けるなら残る側	Appleの公式情報が提出物の審査を示す	提出した内容
本人が申請し、公開が2日遅れた	会社ごとに確かめる側	申請する人と公開日までの余裕はリリースの段取りで決まる	申請する人、戻った回数、余裕日数
フレームワークなど新しい技術に対応する	アプリ開発を続けるなら残る側	job tagが技術・情報の変化と継続的な情報収集を挙げる	担当する技術
UIKitからSwiftUIへ移す対象と進み具合	会社ごとに確かめる側	対象と開発計画はアプリごとに決まる	移行の対象、仕事の割合、進み具合
情報収集が業務外に月4時間ある	会社ごとに確かめる側	業務内の学習時間と費用支援は会社の制度で決まる	業務内外の時間、費用
リリース前に仕事が増える	アプリ開発を続けるなら残る側	job tagがリリース前の残業増を挙げる	忙しくなる時期
リリース前月の実残業が42時間になる	会社ごとに確かめる側	担当量と人員配置は配属先ごとに決まる	平常月・リリース前月の実残業

同じ分け方はAndroidでも使えます。対象APIレベルへの対応は残る側へ置き、過去の納品アプリの本数、費用、人数は会社ごとに確かめる側へ移してください。

例の人にない場面は、次の早見表へ置きます。

場面	最初に置く側	根拠の出どころ	次に確かめる値
Androidの対象APIレベルに対応する	アプリ開発を続けるなら残る側	Google Playの公式要件	対応したAPIレベル
過去の納品アプリを何本も無償で更新する	会社ごとに確かめる側	抱える本数と費用負担は受託の範囲と保守契約で決まる	本数、1本あたりの期間、保守契約、費用負担
顧客のアカウントで一人で申請する	会社ごとに確かめる側	アカウントと担当者は顧客との運用分担で決まる	アカウント、申請する人、確認する人
iOSだけ、Androidだけを担当し続ける	会社ごとに確かめる側	担当OSは募集する役割とチームの分担で決まる	入社直後と将来の担当OS
Objective-C・UIKit・Javaの保守が続く	会社ごとに確かめる側	保守する対象と移行計画はアプリごとに決まる	古いコードの割合、移行の対象と時期
新しい技術情報を追い切れない	アプリ開発を続けるなら残る側	job tagが継続的な情報収集を挙げる	担当する技術、情報の更新頻度
英語の資料を業務外で読む	会社ごとに確かめる側	読む資料と学ぶ時間は担当と職場の制度で決まる	英語を使う業務、業務内外の時間、支援
誰にも相談できず、辞めにくい	会社ごとに確かめる側	相談相手と交代要員はチームの担当分けで決まる	人数、休む時・辞める時に見る人
実機検証を一人で担う	会社ごとに確かめる側	QAとの分担、検証端末、担当人数はチームごとに決まる	検証作業、QAとの分担、端末台数、担当人数
公開が遅れ、営業や上司に責められる	今は分からない側	現職の記録だけでは、公開日を約束した人と遅れを調整する人を判別できない	約束した人、調整する人、直近の出来事、相談後の変化

実機検証がきついなら、QAとの分担、検証端末の台数、担当人数を別々に聞きます。

OS対応・情報収集・リリース前に忙しくなる場面は、アプリ開発に残る

応募先が変わっても、ストアへアプリを出し続けるなら、プラットフォーム側の要件への対応はなくなりません。OS対応そのものは残る側へ置き、使う期間、担当人数、止める機能開発、抱えるアプリの本数は会社ごとに確かめます。

Apple Developerの「Upcoming Requirements - Apple Developer」は、2026年4月28日以降、App Store ConnectへアップロードするアプリをXcode 26以降とiOS 26 SDKでビルドするよう求めています。前年の要件は「近日適用開始の要件 - Apple Developer」にあり、2025年4月24日からXcode 16以降とiOS 18 SDKでのビルドが必要でした（いずれも2026年9月30日確認）。2年続けて同じ形の提出要件が更新されており、OS対応は一度で終わる仕事ではありません。

Androidにも提出要件があります。「Google Play アプリの対象 API レベルに関する要件 - Play Console ヘルプ」によると、2026年8月31日以降、新しいアプリとアップデートをGoogle Playへ送信する場合はAndroid 16（APIレベル36）以降を対象にする必要があります。既存アプリがAndroid 15（APIレベル35）以降を対象にしていない場合、そのアプリの対象APIレベルより高いAndroid OSバージョンを搭載したデバイスの新規ユーザーは利用できなくなります（2026年9月30日確認）。

この要件は、受託開発を発注した顧客から過去の納品アプリの更新を求められる理由の一つになりえます。

iOSでは提出後の審査も仕事に残ります。Apple Developerの「App Review - 配信 - Apple Developer」は、App Store Connectに提出されるアプリとアップデートなどを審査すると説明しています（2026年9月30日確認）。「2024 App Store Transparency Report」では、2024年に全世界で審査した提出件数の約4分の1が却下されました。この割合はアプリ数ではなく提出件数の割合で、同じアプリが承認までに複数回提出される場合があります（2026年9月30日確認）。

厚生労働省job tagの「ソフトウェア開発（スマホアプリ） - 職業詳細」は、関連する技術や情報の変化が激しく、研究会、交流会、オンラインの講演、SNSなどで新しい情報を集める必要があると説明しています。また、アプリのリリース前などは残業が増えるとしています（2026年9月30日確認）。応募先では、情報収集が業務内か、リリース前の実残業が何時間かを面接で聞きます。

求人を1件開き、受託か自社か、担当OS、古いコードの改善・移行を読む

会社ごとに確かめる側へ置いた場面から一つ選び、スマホアプリエンジニアの求人を1件開きます。最初に見るのは、会社説明、仕事内容、募集背景、組織の説明です。

以下の割合は、2026年9月30日時点で当サイトPREVIOに掲載中の、職種にスマートフォンアプリエンジニアを含む求人から、題名がiOS・Android・Swift・Kotlin・Flutter・React Native・モバイルなどの開発職と読めるものを、勤務地を限定せず全件集計した結果です。題名からPM、QA・テスト、デザイナー、営業、インフラ、サーバーサイド、ゲーム、Unityなどと読める求人は除きました。会社単位で、その会社の対象求人のどれか1件に書いてあれば書いてある、どの求人にもなければ書いていないとし、各項目を同じ対象求人と掲載欄で確認しました。担当OSの区分だけは題名で数えています。割合は5%単位に丸め、5%を下回るものは5%未満とします。この集計は求人票の記載率で、職場の実態を示す数字ではありません。当サイトの対象求人は自社サービスの会社に偏り、SIer・SES・受託の業界区分は約15%です。日本のスマホアプリ求人全体の構成とは読めないため、事業の形を割合では比べません。

受託か自社かは、会社説明と仕事内容で探す

会社説明と仕事内容で、特定の自社サービスを開発するのか、顧客から開発を受託するのか、客先で働くのかを見ます。自社サービス、自社プロダクト、受託、客先常駐などの語があれば、仕事内容と一致するかを確かめます。これらの語がなくても、サービス名や仕事内容から事業の形を読める場合があります。自社内開発は働く場所の説明で、自社サービスを運営する会社という意味ではありません。受託会社が自社内で開発する場合も、SES・派遣の求人で客先勤務と併記される場合もあります。顧客名や案件例だけで受託と断定せず、誰のアプリを誰との契約で開発するのかが読めなければ、面接へ回します。

受託なら、納品後のOS対応を保守契約に含むか、過去のアプリを何本抱えるかが働き方を変えます。自社サービスなら、複数サービスを横断するのか、一つのアプリを継続して担当するのかを見ます。求人票で読めるのは事業の形と担当サービスの手がかりまでです。

SES・派遣で配属先が未定なら、仕事内容と案件例から直近のスマホアプリ案件の担当OS、人数、働く場所を読みます。面接では、直近の同種案件の値に絞り、OSごとの人数と一人で配属される可能性を聞きます。

担当OSは題名だけで決めない

iOSだけ、またはAndroidだけの題名の求人を出す会社は約55%でした。両OSかクロスプラットフォームの題名の求人を出す会社は約25%、モバイルエンジニアなど汎用の題名だけを出す会社は約35%です。一つの会社が複数の種類の求人を出すと複数の区分に入るため、合計は100%になりません。これらは会社の求人題名を分類した割合で、一人が担当するOSの分布ではありません。

題名だけでなく仕事内容も読みます。iOSの求人でもAndroidとの共通化やFlutterへの移行を担う場合があり、モバイルエンジニアという題名でも配属後は片方のOSだけを担当する場合があります。入社直後と将来の担当OSが書かれていなければ、別々に聞きます。

Flutter・React Nativeなどクロスプラットフォームの語が出る会社は約35%でした。この数字は求人票に語が出る会社の割合で、採用している会社の割合ではありません。応募条件に経験名があるだけか、入社後の仕事内容にもあるかを分けます。

古いコードの改善・移行は、対象と進み具合を分ける

リファクタリング、リプレイス、技術的負債、SwiftUI・Compose・Flutterへの移行など、既存コードの改善・移行の語を書く会社は約25%でした。応募時の望ましい経験、技術ブログの題名、サーバー側の話を含む境界事例もあります。この割合は語を書く会社の割合で、移行が順調な会社や、仕事の約25%を移行に使う会社の割合ではありません。

求人票では、何から何へ移すのか、全体のどこまで終わったのか、入社後に保守と移行のどちらを担うのかを探します。SwiftUIなどの語が応募条件や歓迎要件にあるだけなら、入社後の移行作業があるとは扱いません。仕事内容にも移行の対象と役割があるかを見ます。改善・移行という説明があっても、対象がサーバー側や社内システムなら、スマホアプリの古いコードの話ではありません。

人数は内訳、学ぶ支援は使い方まで読めない

モバイル担当の人数を書く会社は約5%でした。書く会社の記載には、OSごとに1〜2人とする例があり、別の会社には配属部署のiOSエンジニアが15人という例がありました。一人目のモバイル・iOS・Flutterエンジニアを募る会社は5%未満でした。人数を書く会社だけを見ても、スマホアプリ求人全体で少人数がどのくらいあるかは分かりません。

部署全体の人数を、iOS・Androidそれぞれの担当人数とは読みません。一人目の募集なら、レビューする人、休む時に見る人、採用後に何人まで増やす予定かを面接へ回します。

書籍、カンファレンス、セミナー、勉強会など学習支援の語が出る会社は約45%でした。制度の記載は、業務内に学ぶ時間があることや、実際に利用できることまでは示しません。費用の上限、直近の利用例、業務内外の時間を聞く手がかりにします。

担当アプリ数・申請の段取り・人数・ピーク時の実残業は面接で聞く

求人票から読めない値は、今の職場と同じ対象・期間・単位で聞きます。更新対応についても、何週間ですか、だけでは足りません。複数案件を持つ受託なら、同時に更新するアプリの本数と1本あたりの期間を組み合わせます。

前節と同じ集計で、OS・SDK更新、ストアへのリリース・審査、端末・実機検証、障害・緊急対応、リリース前後の繁忙のどれかを書く会社は約10%で、約90%はどれも書いていませんでした。これは求人票の記載率で、残りの会社に対応や負担がないという意味ではありません。Apple・Googleの提出要件はあるため、書かれていない担当・本数・期間を面接で確かめます。

場面	今の職場の値	求人票で読むこと	面接で聞く質問
App Storeへの提出が戻り、公開が遅れる	直近の公開で1回戻り、予定より2日遅れた。申請は本人	リリース・申請・審査対応の記載	直近の公開では、誰のアカウントで誰が申請し、誰が確認しましたか。審査から何回戻り、公開予定日まで何日の余裕がありましたか
OS担当が少ない	iOS担当2人	組織と人数の記載	配属時のiOS担当とAndroid担当はそれぞれ何人ですか。休む時は誰が見ますか
OS対応中に機能開発が止まる	対応6週間、機能開発を3週間停止	OS対応と開発計画の記載	直近のOS対応に何週間使い、その間に機能開発を何週間止めましたか
UIKitからSwiftUIへの移行が終わらない	直近3か月は移行が仕事の3割	改善・移行の対象	直近3か月に古いコードの保守と改善・移行へ、それぞれ仕事の何割を使いましたか
リリース前に残業が増える	平常月18時間、直近のリリース前月42時間	実残業の数字と対象	配属予定先では、直近の平常月とリリース前月の実残業はそれぞれ何時間でしたか

受託なら、この表とは別に、同時に更新するアプリの本数、1本あたりの期間、保守契約の有無、費用を負担する側を聞きます。申請も顧客と自社のどちらのアカウントを使い、誰が申請・確認するかを分けます。SES・派遣で配属先が未定なら、直近の同種案件について同じ値を聞き、一人で配属される可能性も確かめます。

同じ集計で、残業時間の数字を書く会社は約20%でした。その「数字を書く会社」だけを見ると、各社に複数の値がある場合の最大値でも20時間以下の会社が約90%です。ただし、多くは全社・部門平均で、配属予定のモバイル担当の残業水準ではありません。固定残業時間も給与に含む時間外手当を計算するための時間で、実際に残業した時間ではありません。求人票に上限、平均、固定残業時間があっても、配属予定先の平常月と直近のリリース前月の実残業を聞きます。

答えが会社全体の値なら、配属予定先へ絞って聞き直します。求人票の欄が空の場合や、自社内開発と書きながら仕事内容に客先常駐や派遣がある場合は、働く場所と事業の形を分け、両方を示して質問にします。残業とは別に、求人票の会員数などには2021年10月現在のような古い記載時点が付く場合があります。その日付の値として扱い、現在の値を聞きます。

この見分け方で分からないこと

公式情報から分かるのは、OS・SDK・対象APIレベルへの対応や、iOSのApp Store審査があることまでです。更新、審査、実機検証に使う時間、担当人数、抱えるアプリ本数、費用、公開までの余裕は分かりません。

job tagの職業説明は、ネイティブアプリだけでなく、ブラウザで使うWebアプリとハイブリッドアプリも含みます。年収・労働時間・有効求人倍率は職業分類の統計で、スマホアプリだけの値ではないため、この記事では使っていません。タスクの実施率と就業形態の割合はこの職業の就業者による回答ですが、仕事の量や負担の根拠にはならないため使っていません。

当サイトの求人集計から分かるのは、求人票に語や数字が書かれているかまでです。担当OSは題名から数えており、一人が両OSを担当するかは読んでいません。Flutterなどの語が出る割合は、採用している会社の割合ではありません。既存コードの改善・移行を書く割合も、作業の量や進み具合を示しません。

求人票と面接で分かるのは、記載された内容と説明時点の実績までです。入社後も同じ事業、担当アプリ数、人数、申請の段取り、学ぶ時間、実残業が続くとは限りません。会社を変えれば全部解けるとも、アプリエンジニアを辞めるしかないとも判定できません。

よくある質問

iOSエンジニアはなぜきついと言われるのですか？

OS・SDKの変更への対応、App Storeの審査、特定のプラットフォームへの依存、新しい情報の収集、少人数での属人化、古いコードの改善・移行などが理由として挙がります。ただし、OS対応や審査の存在と、担当アプリ数、申請の段取り、人数、仕事の割合は分けて考えます。

Androidでも同じ見分け方を使えますか？

使えます。AndroidではGoogle Playの対象APIレベル要件への対応を、アプリ開発を続けるなら残る側へ置きます。更新するアプリの本数、1本あたりの期間、費用、Android担当の人数は会社ごとに確かめます。この記事で確認した審査の一次情報はApp Storeのもので、Androidの審査一般を同じ数字では説明しません。

アプリエンジニアを辞めたほうがよいですか？

一律には決められません。いちばんつらい場面がOS対応や情報収集そのものなら、会社を移ってアプリ開発を続けても残ると見込みます。担当本数、費用、申請の段取り、人数、古いコードの割合、ピーク時の実残業が主因なら、応募先の値を確かめてから比べます。

FlutterならOS対応から離れられますか？

自動的には離れられません。クロスプラットフォームで開発しても、App StoreやGoogle Playへ提出するなら、配信先のSDK・対象APIレベルの要件に対応します。求人票ではFlutterの語だけでなく、ネイティブ側の対応を誰が担うかも確認します。

求人票で確かめる場面を一つ選ぶ

最初に書いた3〜5個の場面のうち、会社ごとに確かめる側へ置いたものから、いちばん変えたい場面を一つ選んでください。担当アプリ数と費用なら会社説明、仕事内容、保守・運用を読み、本数、1本あたりの週数、保守契約、費用を負担する側を聞きます。審査の段取りならリリース業務の記載を読み、戻った回数、公開予定日までの余裕日数、申請・確認する人を聞きます。担当OSなら題名と仕事内容を読み、入社直後と将来の担当OSを聞きます。古いコードの移行なら仕事内容を読み、対象、仕事の割合、進み具合を聞きます。人数なら組織の説明を読み、OSごとの人数と一人で配属される可能性を聞きます。学ぶ支援なら待遇と制度を読み、英語を使う業務、業務内外の時間、費用の上限、直近の利用例を聞きます。残業なら勤務時間の欄を読み、配属予定先の平常月とリリース前月の実残業を聞きます。