VS Codeはコードを書く場所であり、アプリをビルドするSDKそのものではありません。
FlutterならFlutter SDK、React NativeならNode.jsと対象OSの環境、iOSならXcodeというように、エディターとは別に必要な道具があります。
最初にターミナルだけで空のアプリを動かし、その後でVS Codeの拡張機能を加えると問題を切り分けやすくなるでしょう。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 開発対象 | VS Code以外に必要な中心環境 | 最初の確認 |
|---|---|---|
| Web | 言語ランタイム、パッケージ管理、ブラウザー | 開発サーバーが起動 |
| Flutter | Flutter SDKと対象OSのビルド環境 | 実機またはエミュレーターで起動 |
| React Native | Node.js、Android StudioまたはXcode | 対象OSで標準アプリが起動 |
| iOSネイティブ | Xcode、SDK、署名環境 | Xcode経由で実機起動 |
VS CodeとSDKと拡張機能の役割を分ける
VS Codeは編集、検索、ターミナル、デバッグ画面、履歴確認の入口になります。
一方でコンパイラー、端末SDK、署名、ストア提出は言語や公開先の環境が担当します。
| 構成要素 | 主な役割 | 壊れたときの確認先 |
|---|---|---|
| VS Code | 編集と操作の入口 | エディター設定 |
| 拡張機能 | 言語支援とデバッグ連携 | 拡張の版と設定 |
| SDK | ビルドと実行 | 公式CLIと環境変数 |
| OS別ツール | 署名、実機、配布 | XcodeまたはAndroid環境 |
Flutterの正式な対象範囲はFlutter supported platformsで確認できます。
React Nativeでは公式の環境構築資料が開発OSと対象OSごとに分けた、Android StudioやXcodeなどの導入物を確認してください。
エディター上の実行ボタンが失敗したら、同じコマンドを内蔵ターミナルで実行します。
CLIでも失敗するならSDK側、CLIでは成功するならVS Codeの起動設定側へ調査範囲を絞れます。
言語別の環境を五段階で組み立てる
拡張機能のおすすめ一覧から始めず、公式SDKの最小構成を作ります。
- 公開先と使用言語を一つに固定する
- 公式SDKと必要なOS別ツールを導入する
- ターミナルから標準プロジェクトを作って起動する
- VS Codeへ公式または管理元が明確な拡張だけを加える
- 別フォルダーへ取得し直して同じコマンドを再現する
iOSを対象にする場合は、コード編集をVS Codeで行ってもビルド環境の条件は残ります。
Xcode Supportで、使うXcodeとmacOS、SDKの対応を確認してください。
Androidを対象にするなら、仮想化とPC資源も見ます。
Android Studioの導入要件は、IDE単体とエミュレーター併用で必要なメモリや保存領域を分けています。
拡張機能を減らしたときの確認回数を数える計算例
次の数字で、競合原因を絞る考え方を示すと仮定しましょう。
同じ言語支援を行う拡張を4個入れた状態で不具合が起きると、最初の有効化組み合わせは最大16通りあります。
公式拡張1個に絞れば、確認する基本状態は有効と無効の2通りです。
16通りから2通りへ減るため、エディターの問題かSDKの問題かを追いやすくなります。
| 構成 | 仮の組み合わせ | 最初の確認 |
|---|---|---|
| 類似拡張4個 | 2の4乗 | 最大16通り |
| 公式拡張1個 | 2の1乗 | 2通り |
拡張数だけで危険度は決まりませんが、同じ役割のものを重ねるほど設定の出所が分かりにくくなります。
必要な機能を一つずつ追加し、追加前後のビルド結果を残してください。
設定と秘密情報をリポジトリで分ける
フォーマット、推奨拡張、デバッグ起動設定は、チームで共有すると環境差を減らせます。
APIキー、署名鍵、個人トークンは共有設定と分け、実値を履歴へ入れません。
VS Codeのソース管理クイックスタートでは、変更確認、ステージ、コミットなどの基本操作を確認できます。
エディターで見えない設定ファイルも含め、コミット前に差分を読みます。
変更レビューを必須にする場合は、リポジトリ側の保護も使います。
GitHubの保護ブランチ資料で、レビューや状態チェックをマージ条件へ加える考え方を確認できます。
VS Codeによるアプリ開発のよくある質問
VS Codeだけでスマホアプリを作れますか？
編集はできますが、ビルドには言語SDKと対象OSのツールが必要です。
React Nativeの例では公式環境構築資料がAndroid向けのAndroid StudioとiOS向けのXcodeを開発条件として分けています。
Visual StudioとVS Codeのどちらを選びますか？
.NETのプロジェクト作成、ワークロード管理、統合デバッグを一つのIDEで進めたいならVisual Studioが候補です。
複数言語のCLIを中心に軽量な編集環境を作りたいならVS Codeが向きます。
製品名ではなく、必要なSDKとデバッグ手順をチームが再現できるかで選びます。
拡張機能は多く入れたほうが便利ですか？
必要な機能が増える一方で、設定競合、更新差、起動時間、供給元確認の対象も増えます。
まず言語ごとの公式または管理元が明確な拡張一つで開始し、不足する機能だけを追加してください。
CLIで再現できる環境をVS Codeから操作する
VS Codeを開発環境の中心にしても、ビルド手順をエディター固有の操作へ閉じ込めないことが重要です。
ターミナルで再現できるSDK構成があれば、別のPCや自動テストへ移しやすくなります。
- VS Codeの役割は編集と操作の入口でありSDKや署名環境とは別
- 言語別環境の完成条件は標準プロジェクトのCLI起動と別フォルダーでの再現
- 類似拡張を重ねたときに増える設定競合と調査対象
- 共有する設定と履歴へ入れない秘密値の明確な境界
Android向けの構成を選んだ場合は、Android Studioで環境構築から公開まで進める手順でSDK、実機、署名の流れを具体化できます。
