サービス›その他›iOSアプリ開発
iOSアプリ開発
humbulls はアプリ開発を専業にしていません。マーケティングを設計していて、そこにアプリが要ると分かったときに、外へ出さずに自分の手で作ります。
こんな課題ありませんか
- 3社から見積もりを取ったら、金額が桁違いに開いた。何が違うのかを説明できる人が社内にいない
- アプリの著作権とストアの名義が制作会社のままで、別の会社に移せない
- 公開したあと、OS が上がるたびに改修費の相談が来る。来年いくらかかるのかを誰も読めない
- 社内に開発できる人がいない。作ったあと誰が直すのかが決まらないまま話が進んでいる
- 作りたい機能は説明できるが、誰がどこから使い始めるのかを聞かれると答えに詰まる
- アプリの制作と、紹介ページと、広告の担当が別々になっていて、公開後の数字を並べて見ている人がいない
- 事業の発表に間に合わせたい日が決まっている。間に合うかどうかの返事が、どこからも返ってこない
humbulls の特徴
受けられない条件を、相談の前に書いている
引き受けられる案件と、引き受けられない案件の条件を、このページに公開しています。相談してから断られるより、読んだ時点で分かるほうが早いためです。
条件に当てはまらない依頼は受けません。特に、24時間の稼働保証や障害時の一次対応が契約に必要な案件は、体制の問題として引き受けられません。その場合は、範囲を変える案か、対応できる開発会社を紹介する形でお答えします。
マーケティングの側から作る
アプリだけを切り出して作りません。誰に届けるか、どこから流入させるか、何を計測するかを決めてから実装に入ります。公開したあとダウンロードされない原因は、実装の品質よりも流入の設計側にあります。
設計と画面と実装を分けません。iOS アプリの開発も UI/UX の画面設計も、humbulls の代表が実務として通ってきた領域です。流入を設計した人がそのまま画面を引き、コードを書きます。
humbulls が自社で公開した Apple Watch 向けアプリでは、アプリ本体と紹介ページを humbulls が両方作りました。紹介ページは Next.js 16 + React 19 で、3D の表現は 3D ライブラリを使わず canvas に 437 行を手で書いています。BtoC・自社案件です。クライアント案件については、社名や数字を出せる事例をこのページにまだ載せていません。
仕様書と規約とリポジトリごと渡す
アプリ本体だけでなく、仕様書・コーディング規約・Lint 設定・リポジトリを渡します。別の開発者に引き継げる状態にしておくためです。ストアの名義と証明書の扱いも、着手の前に契約で決めます。
humbulls は他のサービスで「運用ごと納品」を掲げていますが、アプリでは社内の非エンジニアが自分で改修できる状態にはなりません。 Swift のコードは Swift を読める人にしか直せないためです。ここは成立しない条件3 に書いたとおりで、できないことをできると書きません。
少人数開発が成立しない4条件と、成立する3条件
先に前提を書きます。iOS アプリの開発と UI/UX の画面設計は、humbulls の代表が実務として通ってきた領域です。ただしこのページに並べられる事例カードは、いまのところありません。 社名・時期・数字を出せる形で記録した案件がないためです。自社の実物としては、Apple Watch 向けのアプリを仕様の起案から App Store 公開まで自分の手で通したものが1本あります。件数で選ぶ相手ではない、というのがこのページの立ち位置です。
そのうえで、少人数の開発が完成まで届くかどうかは、案件の性質でほぼ決まります。humbulls は次の7条件で判定しています。成立しない条件を先に書きます。 4つのうち1つでも当てはまる案件は、humbulls では引き受けません。
成立しない条件1 決済・課金・健康情報など、事故が取り返しのつかないデータを扱う
課金はライブラリを入れれば済む。実装量としては大きくない。
重いのは実装量より、審査と責任の設計のほうです。App 内課金にはストア審査の規定があり、返金・二重課金・購読の復元といった、お金が動いたあとの手当てが要ります。医療・健康に関わるデータも同じで、扱いを間違えたときに謝って直せる範囲を超えます。ここは体制で買う領域で、少人数の速度では埋まりません。
humbulls は引き受けません。課金が要る場合は、その部分を既製のサービスに寄せられるかを先に検討します。寄せられないと分かった時点で、開発会社を紹介する側に回ります。
成立しない条件2 稼働保証や、障害時の一次対応が契約に要る
アプリは公開したら完成で、あとは何かあったときに直せばよい。
アプリは公開してからのほうが長く、OS の更新が毎年入ります。追随をやめれば、いずれ動かなくなります。そして「何かあったとき」に誰が最初に電話を取るかは、人数でしか解けません。少人数では、夜間に一次対応の当番を立てられません。
humbulls は稼働保証の契約を結びません。保守が必須要件の案件は引き受けません。引き受ける場合も、公開後の扱い（OS 更新への追随を誰がどの費用で行うか）を着手の前に契約で決めます。決めないまま公開する進め方はしません。
成立しない条件3 納品後、社内の非エンジニアが自分で改修する前提になっている
仕様書とソースコードをもらえば、社内で運用できる。
Swift で書いたアプリは、Swift を読める人にしか直せません。仕様書・規約・リポジトリを渡しても、読める人が社内にいなければ、次に触れるのは外注し直したときです。ノーコードのツールとは前提が違います。humbulls は他のサービスで「社内で回る状態にして支援を終える」を方針に掲げていますが、ネイティブアプリでは成立しません。
引き継ぎ先に開発者がいるか、いなければ外注し直す前提を持っているかを、着手の前に確認します。どちらもない場合は、ネイティブアプリをやめて Web で作る案に切り替えます（→ Webアプリ開発）。ブラウザで動く形なら、humbulls が更新を続けられる範囲が広がります。
成立しない条件4 作るものが先に決まっていて、誰がどこから使い始めるかが決まっていない
要件がまとまっているほうが、発注はスムーズに進む。
要件が固まっていること自体は問題になりません。問題になるのは、機能の一覧はあるのに、最初の利用者がどこから来るかが空欄のときです。公開後にダウンロードされないという結果は、実装からではなくここから出ます。そして流入の設計がない案件では、humbulls を選ぶ理由がありません。開発を専業にしている会社のほうが速く安く作ります。
humbulls はアプリ単体の受託をしません。誰に届けるか、どこから流入させるか、何を計測するかを一緒に見る前提でのみ引き受けます。この線引きが、開発会社と humbulls の使い分けです。
ここから、引き受けられる側の条件です。3つとも当てはまる案件が、少人数の開発が完成まで届く形です。
タップで拡大成立する条件1 作るものが小さい。画面数が少なく、端末の中で完結する
小さく作ると価値が薄くなるので、機能は最初から入れておいたほうがよい。作るならサーバーと API の設計から入る。
少人数の開発が止まる原因は、機能の難しさよりも機能の多さです。humbulls が App Store 公開まで通したアプリは、Swift のコードが13ファイル・1,293行でした。この規模が、少人数と AI で完成まで届くと humbulls が見ている目安です。 数字として小さいことは隠しません。先に共有しておかないと、途中で「もう1画面」が積み上がって公開日が動きます。もう1つの目盛りがサーバーです。端末の中で完結するアプリ（センサー・ヘルスデータ・ローカル保存で成立するもの）は、サーバーの運用責任が発生しません。自前のサーバーを持った時点で、アプリの保守にサーバーの保守が乗ります。
中心の機能を1つ決めて、それ以外を「公開後に検討する」側へ寄せます。最初に決めるのは、入れる機能ではなく落とす機能です。認証やデータ共有が要る場合は、既製のバックエンドで足りる範囲に収めます。収まらない要件が出てきたら、それは成立しない条件2（稼働保証と一次対応）に落ちる案件です。
タップで拡大成立する条件2 公開の期日が決まっていて、機能を削る判断ができる
期日が厳しい案件は、少人数の相手には向かない。
逆です。期日が決まっている案件のほうが成立します。少人数の開発が破綻するのは、期日が短いときよりも、機能を削る判断をする人が決まっていないときです。期日が固定されていれば、削る判断が発注側で下せます。期日が曖昧な案件では、削る理由がないので機能が積み上がり続けます。
最初に「公開する日」と「その日までに落とすもの」を決めます。決める人を1人にします。この2つが決まっていれば、進め方の残りはほぼ機械的に進みます。
タップで拡大成立する条件3 アプリの外側（紹介ページ・計測・ストアの掲載文）まで humbulls が見てよい
アプリは開発会社、紹介ページは制作会社、広告は代理店と分けたほうが、それぞれの質が上がる。
分けると、全体を見る人がいなくなります。ストアの説明文と紹介ページの言葉が違う、広告の着地と機能が噛み合わない、公開後の数字を並べて見ている人がいない。これは能力の問題ではありません。分担の形から出る結果です。そして、この条件が humbulls を選ぶ理由になります。 ここを分けたい案件は、開発を専業にしている会社に頼むほうが合理的です。
アプリ本体、紹介ページ、計測、ストアの掲載素材を1つの範囲として引き受けます。設計した人がそのまま文言を書き、実装します。分業しないので、引き継ぎの過程で意図が落ちません。
タップで拡大7条件をどう使うか
- 成立しない条件が1つでも立つ → humbulls では引き受けません。範囲を変える案か、他社を紹介する形でお答えします
- 成立する条件が3つとも立つ → 引き受けます。モック相談会からそのまま進み方の話に入れます
- 成立する条件のうち1つか2つが空欄 → 空欄になっている条件を埋めるところから相談します。多くは条件2（期日と削る判断）と条件3（範囲）が空欄です
- 判断がつかない → モック相談会で当てはめます。当てはめた結果を持ち帰って、他社に頼む判断をしてもらっても構いません
進め方
実際の進め方は、作るものと期日を踏まえて決めますが、基本の形はこの6ステップです。
モック相談会
作りたいものと、それが誰の何を解決するのかを聞きます。あわせて上の7条件を、その場でこの案件に当てはめます。受けられないと判断した場合は、この時点でそう伝えます。ここを飛ばすと、断る理由を見つけるのが実装の途中になり、双方の時間が消えます。
触れるモックの提示
仕様書を往復させる前に、触れる形にして見せます。文章で合意するより、動くものを見てから直すほうが早いためです。ここで方向が違うと分かれば止めます。止めた場合の費用はかかりません。
「動くモック」が TestFlight 配布・シミュレータの録画・画面遷移のプロトタイプのどれを指すかは、案件ごとに相談して決めます。
仕様と計測の確定
画面・データ・連携先を決めます。同じ工程で、公開後に何を数えるかも決めます。計測を後回しにすると、公開した初月の数字が残らないまま運用が始まります。ストアの名義と証明書の扱い、公開後の OS 更新対応の範囲も、この工程で契約に落とします。
実装
Swift / SwiftUI で作ります。コーディング規約と Lint を最初に敷いてから書き始めます。あとから規約を入れると、直す対象がコード全体になります。実装と並行して、紹介ページとストアの掲載文も進めます。
ストア申請・公開
審査に出す素材（アイコン・スクリーンショット・説明文・プライバシー情報）を作り、申請して公開まで持っていきます。審査で差し戻される前提で日程を組みます。1回で通ることを前提にすると、公開日が動きます。
引き渡し
リポジトリ・仕様書・規約・Lint 設定・ストアの権限を渡します。別の開発者が引き継げる状態にしておくためです。あわせて、公開後に humbulls が担当する範囲と、担当しない範囲を書面で確認します。
成果物
実物
| # | 実物 | 内容 |
|---|---|---|
| 1 | 仕様書（spec.md） | 機能を1つに絞った時点の仕様書の一例 |
| 2 | コーディング規約と Lint の実行結果 | 規約と Lint は書き始める前に敷きます |
| 3 | Xcode プロジェクト構成とリポジトリ | 引き継げる状態にして渡します |
| 4 | 受入判定シート（7条件） | 相談の場で条件を当てはめた記録の一例 |
| 5 | 計測の設計と実装 | 公開後に何を数えるかを、作る前に決めます |
| 6 | App Store 掲載素材一式／アプリの紹介ページ | 掲載素材と紹介ページを humbulls が作った一例 |
納品物リスト
- アプリ本体（Swift / SwiftUI）
- Xcode プロジェクト一式とリポジトリ
- 仕様書
- コーディング規約と Lint 設定
- App Store 申請素材（アイコン・スクリーンショット・説明文・プライバシー情報）
- 計測の設計と実装
- ストアの名義・証明書・リポジトリの帰属を書いた合意書
- 公開後に humbulls が担当する範囲と、担当しない範囲を書いた合意書
無料相談
作りたいものを、まず聞かせてください。 モック相談会は60分・無料です。上の7条件をその場でこの案件に当てはめて、humbulls で引き受けられるか、引き受けられないかをお伝えします。引き受けられないと判断した場合は、その理由と、代わりに当たるとよい相手をお伝えします。
フォームからのご連絡には3営業日以内に返信します。
関連ナレッジ
- 一人マーケターの業務設計 — AI で 5 人分の役割を回す 1 週間モデル（7条件の前提になっている「少人数 + AI でどこまで回るか」の実測ログ）
- マーケ業務の AI 効率化はどこから — 月 25 時間削減までの実測ロードマップ（定型度とリスクで適性を判定する型。7条件による受入判定と同じ考え方）
- マーケターのための Claude Code 入門 — 非エンジニアでも 30 分で始める（humbulls が実装に使っている道具そのものの解説）
- Anthropic 公式 Skills 17 実装を解説 — Skill 設計の原則（引き渡しの工程で渡す「引き継げる状態」の作り方）
- サービスサイトの段階公開 — リード獲得と並走する 4 フェーズ設計（成立する条件2「機能を削る判断」を、サイト側で実践した記録）
実績・事例
iOS アプリの開発と UI/UX の画面設計は humbulls の代表が実務として通ってきた領域ですが、社名・時期・数字を出せる形で記録したクライアント案件が、いまのところありません。 掲載の許諾も確認できていません。
自社の実物としては、Apple Watch 向けアプリを仕様の起案から App Store 公開まで1人で通したものが1本あります。ただし watchOS 単独・BtoC・自社サブブランドの案件で、BtoB 向けサービスページの文脈とは一致しません。これを「iOSアプリ開発の実績」として並べると読者が誤読するため、事例としては使いません。
事例が揃うまで、このページの判断材料は上の7条件と、関連ナレッジの記事です。
FAQ・価格・完了後の道
費用はどのくらいかかりますか。
作るものと画面数で大きく変わるため、一律の金額はお答えできません。お伝えできるのは、モック相談会とモックの提示までは無料であること、金額はモックを見てから決めることの2点です。範囲が読めない状態では見積もりを出しません。 Apple Developer Program の年額、外部サービスの利用料、広告費は含みません。含まれないものは見積もりの前にお伝えします。
公開までどのくらいかかりますか。
参考値として、humbulls 自社の Apple Watch 向けアプリは、仕様の起案から App Store 公開まで約3ヶ月でした。ただし watchOS 単独・Swift 1,293行という規模での自社実測なので、そのまま見積もりには使えません。 モックを見た時点で工程表を作り、どこにどれだけかかるかを先にお見せします。Apple の審査にかかる時間は humbulls の管理外なので、差し戻される前提で日程を組みます。
どのくらい前に相談すればよいですか。
公開したい日が決まっている場合は、その日から逆算して余裕を持ってご相談ください。成立する条件2 に書いたとおり、humbulls が引き受けられるのは「公開する日」と「その日までに落とすもの」を決められる案件です。日程が詰まっているほど、削る判断を早く下す必要があります。受けられるかどうかの判定だけなら、60分のモック相談会で結論が出ます。
iOSアプリの開発実績はどのくらいありますか。
iOS アプリの開発と UI/UX の画面設計は、humbulls の代表が実務として通ってきた領域です。ただし、社名や数字を出せる形でこのページに載せられる事例は、いまのところありません（掲載の可否と内容を確認中です）。
App Store に公開まで持っていった自社の実物は、Apple Watch 向けアプリが1本です。仕様の起案から審査を通して公開するまでを外に出さずに1人で通し、コーディング規約と Lint を敷いて実機のテストまで詰め、アプリと紹介ページを humbulls が両方作りました。件数で選ぶ相手ではありません。上の7条件に当てはまるかどうかで判断してください。
公開したあとの保守はお願いできますか。
稼働保証を伴う保守は引き受けません。 障害時の一次対応を24時間受ける体制がないためです（成立しない条件2）。OS の更新への追随と不具合の修正については、担当する範囲と担当しない範囲を着手の前に書面で決めます。保守が必須要件の案件は、この時点でお断りします。
アプリだけの依頼でも受けてもらえますか。
受けていません。誰に届けるか、どこから流入させるか、何を計測するかを一緒に見る前提でのみ引き受けます（成立しない条件4）。アプリ本体だけを速く安く作ることが目的なら、開発を専業にしている会社のほうが合理的です。相談の場でそう判断した場合は、そのようにお伝えします。
作ったあと、社内で改修できるようになりますか。
なりません。 Swift で書いたアプリは、Swift を読める人にしか直せません。仕様書・コーディング規約・リポジトリは渡しますが、それは社内の非エンジニアが触れるようになるという意味ではありません。別の開発者に引き継げる状態にする、という意味です。humbulls が抱え込む形にはしません。社内で運用したい要件が強い場合は、Web で作る案をご提案します（→ Webアプリ開発）。
App Store のアカウントは、どちらの名義になりますか。
ストアの名義・証明書・リポジトリの帰属は、着手の前に契約で決めます。方針としては、発注者側の資産として残る形を前提にしています。humbulls 自身のアプリは代表個人名義で公開されており、法人名義での運用については確認中です。
Android 版も一緒に作れますか。
現時点の方針は、Apple のプラットフォームに範囲を絞る、というものです。両方を並行して保守すると、成立しない条件2 に自分で当たります。Android も必要な要件であれば、Web で作る案（→ Webアプリ開発）を先にご提案します。
同時に何社まで進められますか。
同時に進める案件数に上限を置いています。実装と審査は日程を動かしにくい工程なので、受注量より納期の確実性を優先するためです。埋まっている場合は、着手できる時期をその場でお伝えします。
価格目安
- モック相談会とモックの提示までは無料
- 見積の順序: 金額はモックを見てから決める
- 含まれないもの: Apple Developer Program の年額・外部サービスの利用料・広告費・稼働保証を伴う保守。見積もりの前にお伝えする
完了後の道
- アプリを公開したあとの集客は リード獲得支援（プロジェクト型）へ
- アプリの数字を事業の数字と並べて見る場合は 計測ダッシュボードの構築へ
- マーケティング全体を継続して見る段階に進む場合は、伴走プラン Growth Partner（月額30万円〜 / 最低3ヶ月）へ
- アプリ自体の継続保守は受け皿を持ちません（成立しない条件2）。担当する範囲と担当しない範囲を着手の前に決めます