【個人開発】iOSアプリをWeb版で作り直す3つの理由

「途中まで作ったアプリを、別の技術で作り直してもいいのだろうか」

個人開発を進める中で、このように迷ったことはありませんか？

僕は2026年5月1日から5月31日までの1か月間、潰瘍性大腸炎の体調を記録するiOSアプリ「UCHealthLog」をSwiftで開発しました。
記録・保存・一覧・編集・削除・グラフ表示を備えた最小構成を作り、約2か月間、毎日使用使用していました。

しかし、実際のリリースを考えたとき、潰瘍性大腸炎の人が全員iPhoneユーザーとは限らないことに気づいてしまったのです。
そこで2026年8月ごろ、UCHealthLogをWeb版で作り直すことにしました。

この記事では、iOS版からWeb版へ変更した3つの理由や、Swift開発で得られた経験、Web版の技術構成とメリットデメリットを紹介します。

個人開発で技術変更を検討している方にとって、目的に合った方向を選び直すための判断材料になれば幸いです。

※UCHealthLogは、個人の体調記録を支援する目的で開発しているアプリです。医療診断や治療の提案を行うものではありません。

SwiftでUCHealthLogを開発した目的と現在地

UCHealthLogを作った目的は、日々の体調を少ない手間で記録し、後から振り返りやすくすることです。

最初から多くの人へ提供するサービスを作ろうとしたわけではありません。まずは、自分が日常的に使えるアプリを目指して開発を始めました。

体調を簡単に記録できるアプリが欲しかった

UCHealthLogを作る前は、iPhoneのメモアプリに日々の体調を記録していました。

メモアプリでも記録はできますが、入力形式が決まっていません。体調、腹痛、トイレ回数、血便、服薬など、残したい項目を毎回入力する必要がありました。

記録を続けるなら、入力する項目が最初から用意されている方が使いやすいと考えました。そこで、自分が記録したい内容に合わせた体調管理アプリを作ることにしました。

アプリのテーマや最初に実装する機能を決めた過程は、「個人開発で最初にやったこと5つ」で詳しく紹介しています。

iPhoneユーザーだったためSwiftを選んだ

最初にSwiftを選んだ理由は、自分がiPhoneユーザーだったことと、iOSアプリを一度作ってみたかったからです。

普段使っている端末なら、自分で動作を確認しながら改善できます。当時使用していたiPhone 11 Proを実機として使い、MacBook Air M2とXcodeで開発を進めました。

本業ではJavaを中心に扱っています。そのため、個人開発では本業と異なる言語や開発環境を経験したい気持ちもありました。

iOSアプリを選んだこと自体が間違いだったわけではありません。当時の「まず自分が使えるアプリを作る」という目的には、Swiftが合っていました。

1か月で最小構成を開発し、約2か月毎日使用した

iOS版の開発期間は、2026年5月1日から5月31日までです。

この1か月間で、次の機能を実装しました。

• 体調の記録
• データの保存
• 履歴一覧
• 記録の編集
• 記録の削除
• グラフ表示

すべての機能を作り込んだわけではありません。日々の体調を記録し、後から確認するために必要な機能へ絞った最小構成です。

開発上は「iOS版MVP・仕様版1.04」として管理しています。この1.04は仕様書や設計書の版数であり、App Storeで公開するアプリのリリースバージョンではありません。

開発後の2026年6月1日からは、iPhone 11 Proで約2か月間、毎日使用しました。

作っただけで終わらず、実際に使う期間を設けたことで、入力から保存、履歴確認、グラフによる振り返りまでの流れを確認できました。この経験は、Web版の要件を考えるうえでも土台になっています。

iOS版で使用した技術と開発環境

iOS版では、次の技術を使用しました。

※Xcodeは開発当時のバージョンを記録していないため、この記事では具体的な番号を記載していません。

iOSアプリをWeb版で作り直す3つの理由

Web版へ変更したのは、SwiftやiOSアプリに問題があったからではありません。

UCHealthLogを誰がどの端末で使うのか、個人開発を通して何を身につけたいのかを見直した結果です。

理由は、大きく3つあります。

理由1｜iPhone以外の端末でも使えるようにしたい

Web版へ変更した最大の理由は、せっかくリリースするなら、端末を問わず使える形にしたいと考えたからです。

開発当初は自分がiPhoneユーザーだったため、SwiftでiOS版を作りました。しかし、潰瘍性大腸炎の人が全員iPhoneを使っているとは限りません。

Web版なら、対応するブラウザがあれば、AndroidやPC、タブレットからも利用できます。そのため、特定の端末に限定せず、利用の入口を広げられるWeb版へ変更しました。

ただし、Web版v1では端末間の自動同期には対応せず、データは利用したブラウザ内に保存されます。

理由2｜Webアプリの開発工程を一通り経験したい

2つ目の理由は、Webアプリの要件整理からテスト、公開までを経験したいからです。

僕はSESエンジニアとして、Java、TypeScript、Vue.jsなどを使ったWebシステムの開発・保守・テストに関わってきました。

一方、業務では担当範囲が決められていることも多く、自分でアプリ全体の要件を決め、技術を選び、公開まで進める機会は限られます。

Web版UCHealthLogでは、次の工程に取り組みます。

• Reactによる画面開発
• IndexedDBを使ったローカルデータ保存
• スマートフォン・タブレット・PCへのレスポンシブ対応
• Vitestによる単体・コンポーネントテスト
• PlaywrightによるE2Eテスト
• Git・GitHubによるブランチ管理
• Cloudflareへの公開

Web版v1では、バックエンドやサーバー上のデータベースは実装しません。

今回経験するのは、フロントエンド、ブラウザ内のデータ保存、自動テスト、公開までの範囲です。実装していない技術まで「経験した」と見せるのではなく、自分が取り組んだ範囲を正確に整理していきます。

個人開発を始めた背景については、「低年収エンジニアの挑戦」でも紹介しています。

理由3｜学習を続けていることを形に残したい

3つ目の理由は、本業以外でも自己学習を続け、自分で考えながら開発していることを形に残したいからです。

「こういうアプリを作りました」と完成品だけを見せることが目的ではありません。

• なぜこのアプリを作ったのか
• なぜiOS版からWeb版へ変更したのか
• どの機能を最初に実装するのか
• なぜその技術を選んだのか
• どのようにテストしたのか
• 不具合をどう調査して改善したのか

こうした判断や過程も、個人開発で得られる経験です。

Web版では、要件書、GitHubの変更履歴、ブランチ、Pull Request、テスト結果などを残します。完成品だけでは見えにくい、開発中の考え方や改善の過程も整理する予定です。

個人開発をしただけで、転職が成功したり年収が上がったりするわけではありません。

それでも、面接などで「勉強しています」と話すだけでなく、「この課題に対して、このように考えて開発しました」と説明できる材料にはなります。

個人開発を転職活動でどう見せるかについては、「未経験Javaエンジニア向け｜評価されやすいポートフォリオ設計」でも整理しています。

リリース前だったから軌道修正を決断できた

Web版を選んだ理由とは別に、方向転換するタイミングも判断材料になりました。

iOS版は最小構成まで開発しましたが、App Storeには公開していません。

Appleは、App Storeで公開するアプリを審査対象としており、提出前にはクラッシュや不具合の確認、アプリ情報やメタデータの整備などを求めています。

参考：App Review Guidelines｜Apple Developer

iOS版の公開準備や、iOS特有の不具合・アップデート対応へ本格的に時間を使う前に、UCHealthLogの想定利用者と自分の学習目的を見直しました。

公開後であれば、利用者への影響も考えながら方針を変更する必要があります。今回はリリース前だったため、比較的早い段階でWeb版へ軌道修正できました。

もちろん、Appleの審査を避けることだけが目的ではありません。Web版にも複数ブラウザでのテストやセキュリティ対応が必要です。

「保守をしなくて済む」のではなく、想定利用者と身につけたい技術に合わせて、取り組む開発・保守の対象を選び直したと考えています。

Web版リリース後か、または別のアプリでApp Storeへのリリースも挑戦したいと思います！

Swiftで開発した経験は無駄ではなかった

Web版で作り直すと聞くと、それまでのiOS開発が無駄になったように見えるかもしれません。

僕自身も、せっかく動くところまで作ったアプリを別の技術で作り直すことに、少なからず迷いがありました。

それでも、Swiftで開発した経験があったからこそ、Web版の要件を具体的に決められています。

メインのJava以外の開発を経験できた

本業ではJavaを中心に扱っています。

iOS版の開発では、Swift、SwiftUI、SwiftData、Swift Charts、PhotosPickerなど、本業では触れていない技術を使用しました。

画面の作り方、データの保存方法、グラフの表示、端末からの写真選択など、Javaを使った業務システムとは異なる開発を経験できました。

Swiftの実務経験が身についた、とまでは言えません。

ただし、初めて扱う言語やフレームワークでも、必要な情報を調べ、エラーを確認しながら最小構成を作った経験は残っています。

技術を変更したからといって、そこで学んだことまで消えるわけではありません。

約2か月毎日使ったから操作の流れを確認できた

iOS版は、開発後に約2か月間毎日使用しました。

実際に使ったことで、体調を入力し、保存し、履歴やグラフから振り返るという一連の流れを確認できました。

机上で仕様を考えただけでは、どの機能が必要なのか判断しにくい部分があります。

自分で使う期間を設けたからこそ、Web版でも残す機能と、Web向けに見直す部分を分けやすくなりました。

個人開発では、作った時点を完成にするのではなく、実際に使ってから改善することも大切だと感じています。

iOS版の仕様と設計をWeb版へ引き継げた

Web版では、Swiftのコードをそのまま使うことはできません。

それでも、次の仕様はiOS版から引き継いでいます。

• 日別の体調記録
• 月間カレンダー
• 履歴一覧
• 記録の詳細・編集・削除
• 食事写真
• トイレ回数のグラフ
• 7日・14日・30日の期間切り替え
• 同じ日の記録を1件にするルール
• 青を基調とした画面デザイン

iOS版がなければ、これらをゼロから考える必要がありました。

Web版はコードを作り直しますが、アプリの目的や機能まで白紙に戻したわけではありません。

作り直しは振り出しではなく方向修正だった

技術を変更することと、それまでの経験を捨てることは同じではありません。

iOS版で検討した仕様や画面構成はWeb版へ引き継ぎ、約2か月使った経験も要件の整理に活用しています。

変更したのは、アプリの目的ではありません。

体調を記録し、後から振り返りやすくするという目的は同じです。その目的を、より多くの種類の端末で実現するために、提供方法と技術構成を変えました。

作り直しは振り出しではなく、実際に作って使ったからこそ選べた方向修正だと考えています。

Web版の技術構成と現在の進捗

Web版への変更を決めたのは、2026年8月ごろです。

iOS版とは別のプロジェクトとして管理し、現在はPhase 2にあたるデータ層まで開発を進めています。

Web版で採用した技術

Web版では、次の技術を採用しました。

Web版v1では、ユーザー登録、ログイン、サーバー上のデータベース、端末間同期は実装しません。

まずはiOS版の主要機能をWebで再現し、自分で継続して使える状態まで完成させることを優先します。

現在はPhase 2まで進行している

Web版の開発は、5つのPhaseに分けています。

Phase 1では、React、TypeScript、Tailwind CSS、React Routerなどの開発基盤を整えました。VitestとPlaywrightの初期設定も、この段階に含めています。

Phase 2では、IndexedDBを扱うDexie.jsのデータ構造、データ操作を分離するrepository、日付キー、入力値の検証、transaction、migrationのひな型、データ層のテストを進めています。

先にデータの保存方法やルールを固めることで、画面実装後にデータ構造を大きく変えるリスクを減らす狙いがあります。

今後はiOS版の主要機能をWebへ移す

今後は、次の順番で開発する予定です。

• Phase 3
  • ホーム
  • 月間カレンダー
  • 履歴一覧
  • 記録の詳細・編集・削除
  • 食事写真
  • グラフ
• Phase 4
  • 画像の圧縮
  • データのエクスポート・インポート
  • 保存容量の確認
  • レスポンシブ対応
  • ダークモード
  • セキュリティ設定
• Phase 5
  • PlaywrightによるE2Eテスト
  • Chrome・Edge・Firefox・Safariでの確認
  • iPhone実機での確認
  • Cloudflareへの公開

機能を思いつくたびに追加するのではなく、Phaseごとに実装範囲と完了条件を決めています。

Web版への変更にもデメリットはある

Web版へ変えれば、すべての問題が解決するわけではありません。

利用できる端末の種類を広げられる一方で、iOS版とは違う実装やテストが必要になります。

iOS版のコードはそのまま使えない

iOS版で使ったSwiftやSwiftUIのコードは、Web版ではそのまま使用できません。

SwiftUIはReact、SwiftDataはIndexedDBとDexie.js、Swift ChartsはRechartsへ置き換えます。

写真選択についても、PhotosPickerからWebブラウザのファイル選択へ変更します。

機能や画面構成は引き継げても、実装の多くは作り直しです。その分、完成までの開発期間も長くなります。

Web版特有のデータ消失リスクがある

Web版v1では、体調記録や食事写真をブラウザ内へ保存します。

サーバーへ健康情報を送らない点はメリットですが、ブラウザのデータを削除すると記録を失う可能性があります。

また、別の端末、別のブラウザ、別のブラウザプロファイルへデータは自動同期されません。

その対策として、記録と写真をファイルとして保存できるエクスポート機能と、データを戻せるインポート機能を実装する予定です。

ローカル保存であることや、バックアップが必要なことも利用者へ明示します。

対応する環境が増えるほどテストも増える

iOS版では、主にiPhone 11 Proで動作を確認していました。

Web版では、iPhoneだけでなくAndroid、PC、タブレットも考慮する必要があります。

ブラウザも、Safari、Chrome、Edge、Firefoxを正式な対応対象としています。

利用できる端末の種類を広げるほど、画面表示やブラウザごとの違いを確認する範囲も広がります。

公開方法を変えても保守は必要になる

Web版は、App Storeへ提出せずに公開できます。

ただし、審査がないからといって、公開前のテストやセキュリティ確認が不要になるわけではありません。

レスポンシブ表示、ブラウザごとの動作、データ保存、バックアップ、セキュリティヘッダーなど、Web版だからこそ必要になる対応があります。

iOS版の保守を避けたのではなく、想定利用者と身につけたい技術に合わせて、取り組む開発・保守の対象を選び直しました。

iOS版を残しながらWeb版の完成を目指す

Web版へ変更した後も、iOS版のコードや仕様は削除しません。

一旦そのまま残し、iOS版を使いたいという要望があれば、将来的なリリースを検討します。

iOS版は今後の選択肢として残しておく

iOS版は、約2か月毎日使用できる最小構成まで開発しています。

Web版の比較対象や仕様確認にも使えるため、開発したコードと資料は引き続き管理します。

ただし、現時点でApp Storeへの公開予定はありません。

まずはWeb版を優先し、完成後の反応や要望を見ながら判断する予定です。

Web版は実際に使えるところまで完成させる

Web版では、最初からユーザー登録やクラウド同期まで作り込みません。

まずはiOS版の主要機能をWebで再現し、実際に記録と振り返りができる状態を目指します。

その後、バックアップ、レスポンシブ対応、複数ブラウザでのテストなど、Web版に必要な機能を追加します。

技術を変更することよりも、変更後にきちんと完成まで進めることが大切です。

完成品だけでなく開発過程も実績にする

Web版の開発では、完成した画面だけでなく、次の内容も残しています。

• 開発要件書
• 技術選定
• 実装Phase
• Gitのブランチ運用
• Pull Request
• 単体テスト
• E2Eテスト
• 不具合と修正内容
• iOS版からWeb版へ変更した理由

これらは、派手な実績ではないかもしれません。

それでも、本業以外でも学習を続け、自分で課題を見つけて開発していることを説明する材料になります。

まとめ｜作り直しは目的に合わせた方向修正

この記事では、Swiftで開発したUCHealthLogをWeb版で作り直す理由を紹介しました。

iOS版は2026年5月1日から5月31日までの1か月間で最小構成を開発し、約2か月、毎日使用しました。

実際に使用したことで、記録・保存・一覧・編集・削除・グラフという基本的な流れを確認できました。

その後、リリースを考えたとき、潰瘍性大腸炎の人が全員iPhoneユーザーとは限らないことに気づきました（よくよく考えれば気づけるはずだが作るのに夢中になっていました笑）。

Web版へ変更した理由は、次の3つです。

1. iPhone以外の端末でも使えるようにしたい
2. Webアプリの開発工程を一通り経験したい
3. 自己学習と開発の過程を形に残したい

リリース前だったことも、方向転換を決断できた要因の1つです。App Storeの公開準備やiOS版の保守へ進む前に、想定利用者と個人開発の目的を見直せました。

Swiftで開発した経験は無駄ではありません。

本業で主に使っているJava以外の言語や、iOS固有のUI・データ保存・グラフ・写真選択を経験できました。iOS版の仕様や、約2か月使って確認した操作の流れも、Web版へ引き継いでいます。

作り直しは、振り出しに戻ることではありません。

誰のどのような悩みを解決したいのか、現在の技術はその目的に合っているのか、作り直しても引き継げるものは何か。この3つを整理した結果、Web版への方向転換を決めました。

個人開発で技術変更に迷っている方は、最初に選んだ技術を守ることだけでなく、現在の目的に合っているかを一度見直してみてください。

小さくても実際に作って使った経験は、次の開発にも必ず残ります。

個人開発を始める前に整理したことは、「個人開発で最初にやったこと5つ」で紹介しています。