iOSエンジニアはきつい？OS対応と審査に振り回されるのはどこでも同じか

自社アプリの iOS 開発を一人で担当しているエンジニアがいるとします（架空の例です）。夏の間、機能開発と並行して新しい iOS への対応を進めたのに、正式版が出た週に表示が崩れるという問い合わせが来た。修正版は審査で 1 回戻され、営業が店舗に告知していたキャンペーンの初日に間に合わなかった。iOS をやる限りこれが毎年続くのか、一人に任せきりの会社がおかしいのか。

毎年秋の OS 対応、翌春の開発環境の必須化、審査を通るまで出せないことは、スマホアプリを作る限りどこの会社でもあります。Android にも同じ形の締め切りがあります。ここは会社を移っても変わりません。

変わるのは、毎年来るこの作業を何人で分けるか、その間に機能開発の締め切りをずらすか、審査に余裕を見た日程を誰が組むかです。 上の例は、一人で担当していたこと、締め切りをずらさなかったこと、告知の日が先に決まっていたことが重なって起きたもので、どれも会社の段取りで変えられます。

OS 対応と審査は、どの会社でも毎年ある

新しい iOS は Apple の日程で毎年出ます。正式版が出るまでにベータで自分のアプリを確かめて直し、翌春には新しい開発環境でビルドしないとアップデートを出せなくなります。2026 年は 4 月 28 日から、App Store Connect にアップロードするアプリは Xcode 26 以降・iOS 26 の SDK でビルドすることが必要になりました（「Upcoming Requirements - Apple Developer」、2026 年 9 月 30 日確認）。前年も 2025 年 4 月 24 日から Xcode 16 以降が必要になっていて、毎年同じ形で来ます（「近日適用開始の要件 - Apple Developer」、2026 年 9 月 30 日確認）。

Android も同じです。Google Play は毎年、アプリが対象にする API レベルを引き上げていて、2026 年 8 月 31 日からは、新しいアプリとアップデートを Android 16（API レベル 36）以降を対象にして出す必要があります（「Google Play アプリの対象 API レベルに関する要件 - Play Console ヘルプ」、2026 年 9 月 30 日確認）。厚生労働省の job tag も、スマホの OS が新しくなるとアプリのバージョンアップ対応が要り、それが開発業務の何割かを占めると書いています（「ソフトウェア開発（スマホアプリ） - 職業詳細」、2026 年 9 月 30 日確認）。

そして iOS では、不具合を直した版も App Store の審査を通るまで公開できません。Apple はアプリのアップデートも含めて、提出されたものをすべて審査しています（「App Review - 配信 - Apple Developer」、2026 年 9 月 30 日確認）。審査で戻されると直して再提出することになり、ある開発会社の技術ブログは、1 回あたり「約2日」かかると書いています。

スマホアプリの仕事でつらいと言われることを、どの会社でもあるものと、会社で変わるものに分けるとこうなります。

きつさ	どの会社でもあるか、会社で変わるか
毎年の OS 対応と、開発環境の必須化	どの会社でもある。日程は Apple と Google が決める。何人で、どれだけの期間をかけて対応するかは会社で変わる
審査を通るまで出せない	どの会社でもある。リリース日にどれだけ余裕を見るか、遅れた時に誰が調整するかは会社で変わる
新しい OS と古い OS の両方で、表示と動作を確かめる	どの会社でもある。どの OS まで対応を続けるかは会社の方針で変わる
リリース前に忙しくなる	どの会社でもある（job tag も、リリース前などは残業が増えると書く）。忙しい時期をいくつ重ねるかは会社で変わる
担当が 1〜2 人で、休めない・辞めにくい	会社で変わる
古いコードを保守しながら新しい作りに移す	どのアプリにも起きうる。移行にどれだけ時間をくれるかは会社で変わる

つらさの差は、何人で分けるかと、締め切りをずらすかで出る

OS 対応の量は、アプリの規模や画面の作り、古い OS をどこまで対象にするかで変わります。同じ iOS 26 の新しいデザインへの対応でも、QA を含めて 3 日で終えたと書く会社の技術ブログもあれば、1 月中旬から 3 月中旬まで 3 段階に分けて進めたと書く会社の技術ブログもあります。アプリも対応した範囲も違うので、この 2 つを並べて長い・短いは言えません。

差が出るのは、OS 対応を予定に入れて、そのぶん機能開発の締め切りを後ろにずらしているかと、担当が 2 人以上いて、一人が休んでも開発が止まらないかです。この 2 つがそろっていれば、対応の量が同じでも、一人で機能開発と並行して抱え込むことは避けやすくなります。

job tag は、スマホアプリはプロデューサーやデザイナーも含めたチーム全体で 4〜6 人で作ることが多いと書いています。これはエンジニアだけの人数ではないので、iOS を書く人が 1〜2 人という職場は、社員の多い会社でも起こりえます。

キャンペーン日に間に合わない事故は、審査を先に通しておけば防げることがある

審査があることは変えられません。ただ、審査で 1 回戻されたら告知の日に間に合わない、という形は、段取りで避けられることがあります。

1 つは、審査を先に通しておき、公開だけを告知の当日にするやり方です。App Store では、審査を通った版をすぐには公開せず、手動で公開する設定を使える場合があります。もう 1 つは、キャンペーンの開始をアプリの更新に頼らず、サーバー側で切り替えられるようにしておくことです。どちらも、告知の日を決める人が、決める前に開発チームに相談していないと使えません。

前に挙げた開発会社の技術ブログは、顧客がリリース日を決めている案件では「1つのリジェクトがリリース日遅延のリスクに繋がることもある」と書いています。日程を決める人が審査を考えに入れないまま告知を出すと、審査で戻された時に、遅れの責めを開発の担当者が負わされやすくなります。

求人票で一人体制は見抜ける？

ほとんどは見抜けません。当サイトの掲載求人では、iOS や Android の担当の人数を書いている会社は 10% 未満でした。OS 対応、ストアへのリリース・審査、実機の検証、障害対応、リリース前の繁忙のどれかを仕事として書く会社も約 10% で、約 90% はどれも書いていません。書いていないのは、無いという意味ではありません。どのアプリでも必要な作業なので、わざわざ書いていないだけかもしれません。

人数が書いてある求人なら、その人数が手がかりになります。「一人目のモバイルエンジニアとして」のように 1 人目を募集している求人や、アプリの立ち上げの募集は、入った時点では一人体制だと思って読んでおくのが安全です。それ以外の大半の求人では、iOS の担当が何人かは面談で確かめるまで分かりません。

去年の秋に締め切りをずらしたかで、その会社の回し方が見えてくる

体制を一般論で聞くと、どこもチームで対応していると答えられます。去年や最近の具体的な出来事を聞くと、実際の回し方が分かります。大事な順に 4 つです。

iOS を書いている人は今何人いますか。誰かが休んだ時は誰が見ますか。 人数を書いていない会社が大半なので、カジュアル面談の最初に聞くのが早いです
去年の秋の OS 対応は、何人で、どれくらいかかりましたか。その間、機能開発の締め切りはどうしましたか。 大事なのは後半の、締め切りをどうしたかです。2 人で分けて、その期間は機能開発の締め切りを 1 本後ろにずらし、崩れた画面の確認には QA も入った、という答えなら、OS 対応を予定に入れて回している会社です。担当者が機能開発と並行して対応した、新しい iOS が出てから問い合わせで表示崩れに気づいて直した、という答えなら、今と同じことが起きると思っておいたほうがいいです
最近、キャンペーンや告知に合わせたリリースで、日程は誰がいつ決めましたか。 告知の前に開発チームに相談しているか、審査に余裕を見た日程を誰が組んでいるかが分かります
審査で戻されてリリースが遅れたことはありますか。その時、営業やお客さんへの説明は誰がしましたか。 遅れの責めが担当者一人に向かう会社かどうかが分かります

辞める前に、今の会社で変えてもらえることは？

転職を決める前に、今の会社に変えてもらえることもあります。上司には、つらいと伝えるより、具体的な頼みごとにして話すほうが返事をもらいやすくなります。

iOS の後任が誰で、いつまでに入る見通しか。決まらない場合、業務委託などで手当てするか
次の OS 対応の時期に、何人で対応し、機能開発の締め切りをどうするか
キャンペーンの日を決める時は、告知の前に開発チームに一度相談してほしい。審査を先に通して公開だけ当日にすれば、今回のようなことは防げる

返事が曖昧なら、いつまでに何を決めるかを、その場で決めてもらいます。採用中のまま何か月も経っているなら、今何人と面接していて、いつまでに決める予定かを聞きます。具体的な答えが出てこなければ、実際には採用が進んでいないと見てよいと思います。

見切りの目安は、待った月数ではなく、次の夏の OS 対応が始まるまでに 2 人で対応できる見込みが立つかどうかです。今年と同じ形でもう一度夏を迎えそうなら、転職先を決めてよい時期です。上司に頼みごとを出すのと、求人を見始めるのは並行で構いません。外の求人を見ておくと、上司の返事が来た時に、残る場合と転職する場合の条件を並べて比べられます。

よくある質問

Swift しかできないと、よそで通用しませんか？

当サイトの掲載求人には、iOS だけを担当する題名の求人も、両 OS やクロスプラットフォームの題名の求人もあります。担当の広さは会社で変わるので、iOS の経験が長い人の行き先が無くなるわけではありません。ただ、Swift と Apple の SDK の上で仕事をすること自体は、スマホアプリを続ける限り変わりません。Android を以前書いていた程度なら、面接では先に、いつまで何を書いていたかと、今の専門は iOS だということを自分から伝えておくと、突っ込まれた時に慌てずに済みます。

Android エンジニアなら振り回されませんか？

毎年の締め切りは同じ形で来ます。Google Play の対象 API レベルの引き上げに合わせて、毎年アプリを直して出し直します。対象 API レベルを上げないままの既存のアプリは、それより新しい Android の端末を使う新規ユーザーには使えなくなります（上の Google Play の要件）。

自社アプリと受託では、どちらが振り回されにくいですか？

振り回され方が違います。受託はリリース日を顧客が決め、案件ごとにアプリが変わり、納品済みのアプリにも OS や API レベルの要件が上がるたびに更新の依頼が来ることがあります。自社開発では同じアプリを作り続け、リリース日を決めるのは社内の営業や企画です。自社のほうが段取りを社内で変えられる余地はありますが、自社なら起きないとは言えません。どちらでも、リリース日の決め方は上の面接の質問で確かめられます。

年収はどれくらい狙えますか。審査には何日前に出せばいいですか？

どちらも、この記事では目安を示せません。iOS エンジニアだけの年収の相場を示す統計は手元に無く、当サイトでもこの職種の求人の年収は集計していません。今の年収と求人の年収を比べる時は、固定残業代が含まれているかどうかを合わせてから比べてください。審査に出す日は、1 回戻されて出し直しても間に合う日にしておく、というのが段取りの考え方です。

この記事の数字と例について

当サイトの数字は、2026 年 9 月 30 日時点で当サイト PREVIO に掲載していたスマートフォンアプリエンジニアの求人のうち、求人の題名からスマホアプリの開発職と読めるものを、会社単位で数えました。書いてある会社は、その内容を書いた求人を 1 件以上出している会社、書いていない会社は、どの求人にも書いていない会社です。求人票に書いてあるかで判定していて、職場の実態ではありません。割合は 5% 単位に丸めています。当サイトの掲載求人は自社サービスの会社に偏っていて、日本の求人全体の数字ではありません
Apple と Google の要件、Apple の審査、job tag は、2026 年 9 月 30 日に原文を確認しました。job tag のこの職業は、ブラウザで使う Web アプリなども含めて書かれています
OS 対応にかかった期間の 2 例と、審査で戻された時の約 2 日は、それぞれ 1 社の技術ブログに書かれていた例です
次は当サイトの見立てと助言です
- 審査を先に通して公開だけ当日にする、サーバー側で切り替える、という段取り
- 告知を先に出すと遅れの責めを開発の担当者が負わされやすいこと
- iOS を書く人が 1〜2 人という職場は社員の多い会社でも起こりうること
- 審査に出す日は 1 回戻されても間に合う日にする、という考え方
- 面接の答えの読み方と、1 人目や立ち上げの募集の読み方
- 上司への頼み方と見切りの目安
- Android の経験の伝え方と、自社と受託の比べ方