プラットフォーム

Magento モバイル アプリ: 5 つの入手方法と選び方

PWA からカスタム ビルドまで、Magento または Adob​​e Commerce モバイル アプリへの 5 つのルートを、ストアの意思決定フレームワークと電話テスト計画と比較します。

ネイビーの Magento アプリへの 5 つの方法を示す活版印刷のカバー、インディゴのバンドの下のサンゴ ブロック上の 5 つの丸いバーの横

Adobe は Magento ストア用の既成の顧客アプリを出荷していないため、すべての Magento モバイル アプリは 5 つのルートのいずれかから提供されます。つまり、モバイル ストアフロントを改善してそこで終了する、Web サイトからアプリへのコンバーターを備えたアプリ内にライブ ストアフロントを配置する、マネージド アプリ サービスを利用する、独自のネイティブ画面を備えたモバイル アプリ拡張機能をインストールする、または Magento の API でカスタム ネイティブ ビルドを委託するというものです。

ルートが最も異なるのは、ストアのどのくらいの量を 2 回目に構築する必要があるか、そして Magento ではそれが高価であるという点です。このガイドでは、5 つを比較し、SiteTo.App が間違った選択であることを示し、電話テスト計画と公開メモを提供します。短いバージョンについては、を参照してください。 Magento からアプリページへ.

Magento ストアにはアプリが必要ですか?

Magento および Adob​​e Commerce ストアには、ディストリビューター、直接販売するメーカー、部品および消耗品ビジネス、価格交渉のある B2B 販売者など、複雑なカタログが含まれる傾向があります。顧客の多くは再び同じ種類の注文を行っており、そのタスクがショートカットに値するほど頻繁に行われる場合には、アプリがその役割を果たします。ベンダーを比較する前に、次の 3 つの質問をしてください。

  1. 顧客はアプリで毎週または毎月何をするでしょうか? 消耗品を再注文し、注文を確認し、SKU ごとに部品を検索します。タスクに名前を付けることができない場合は、高速なモバイル サイトで十分です。
  2. そのタスクはすでにモバイル ストアフロントで機能していますか? ストアフロントから構築されたアプリは、その速度とチェックアウトを継承します。
  3. 通知は購入者にとって有益でしょうか? 定期的に注文する商品の再入荷アラートは便利です。毎週のプロモーションは簡単にミュートできます。

答えが弱い場合は、まずモバイル ストアフロントに予算を費やします。

Magento モバイル アプリを入手する 5 つの方法は何ですか?

ルート顧客が得られるものあなたが維持するものお支払い方法ストアに提出する人
1. モバイル ストアフロントまたは PWA の改善より高速なサイト、オプションでブラウザからインストール可能あなたのストアフロント開発時間誰でもない;ストアリストはありません
2. ウェブサイトからアプリへのコンバーター (SiteTo.App)ライブストアフロントをネイティブシェルにロードするあなたの名前のアプリあなたのストアフロントプラットフォームごとに 1 回: Android は 29 ドル、iOS は 79 ドル、両方とも 99 ドルあなた自身のアカウントから
3. マネージドアプリサービスチームがセットアップ、QA、提出を処理する同様のアプリあなたのストアフロント月額または年会費通常はサービス
4. モバイルアプリの拡張機能ベンダーのカタログ、カート、チェックアウト画面を備えたネイティブ アプリストアフロント、コネクタモジュール、アプリのデザインライセンスまたはサブスクリプションとカスタマイズあなたまたはベンダー
5. カスタムネイティブビルド何を指定してもストアフロントと別個のアプリのコードベースプロジェクト料金と継続的なメンテナンスあなたまたは代理店

ストアの掲載情報を含むすべてのルートには開発者アカウントも必要です。Apple Developer Program は年間 99 ドル、Google Play は 1 回あたり 25 ドルで、Apple と Google に直接支払われます。

1. より優れたモバイル ストアフロントまたは PWA

アプリを使用しないことが正解の場合もあります。デフォルトの Luma テーマにより携帯電話でのストアの動作が遅くなる場合は、アイコンよりも軽量のフロントエンドの方が顧客にとって役に立ちます。 ヒュヴァのテーマ は 2025 年 11 月から無料でオープンソースになっており、Adobe Commerce の販売者向けに Adob​​e が独自の文書を作成するようになりました。 コマースストアフロント、既製のドロップイン コンポーネントを使用します。 PWAスタジオ ヘッドレス プログレッシブ Web アプリでは引き続き利用できます。

PWA はブラウザからホーム画面に追加できますが、App Store には表示されません。iPhone での Web プッシュは、顧客がその方法でインストールした場合にのみ機能します。私たちのガイド PWA、ネイティブ、WebView 違いをカバーします。

2. ウェブサイトからアプリへのコンバーター

コンバーターは公開ストアフロント URL を取得し、アプリ内に配置します。 SiteTo.App では、アプリはライブ Web サイトのネイティブ シェルです。アイコンと起動画面、ロゴ付きのネイティブ ヘッダー、サイド メニュー、下部タブ、スワイプ バック、プルして更新、および独自の Firebase プロジェクトを介したオプションのプッシュ通知が含まれます。内部のページは、WebView にロードされた Magento ページです。

Magento サーバーには何もインストールされず、API 認証情報も必要ありません。顧客グループの価格、共有カタログ、配送ルール、およびモバイル サイトに表示されるすべての拡張機能は、同じページであるため引き継がれます。同じ理由で、このアプリはモバイル ストアフロントと同等かそれ以上ではありません。

3. マネージド アプリ サービス

マネージド サービスでは、ページに対して同じ WebView アプローチを使用し、多くの場合、カスタム ネイティブ画面などの追加機能を使用して、アプリの構成、テスト、送信、保守を行うチームを追加します。そのチームに対して定期的な料金を支払います。社内にアプリを所有する時間がない人がいる場合、これは正当な選択です。このようなサービスの 1 つを比較します。 SiteTo.App 対 MobiLoud.

4. Magento 用のモバイル アプリ拡張機能

の アドビコマースマーケットプレイス 独立系ベンダーは、Magento 2 用のモバイル アプリ拡張機能を販売しています。通常の設計は、ストアにインストールされたコネクタ モジュールに加えて、それを通じてカタログ、カート、顧客データを読み取る事前構築済みのネイティブ iOS および Android アプリです。ネイティブの製品リストと製品ページを取得します。

購入する前に、アプリがどのカスタマイズをサポートしているか、誰が Magento アップグレードを通じてコネクタの互換性を維持しているか、誰の開発者アカウントがリストを保持しているかを尋ねてください。カスタム オプション、B2B 機能、サードパーティの支払い方法のサポートはベンダーによって異なります。

5. カスタムネイティブビルド

マジェントの GraphQL API はヘッドレス店舗とモバイルクライアント向けに設計されており、代理店はその上に任意のアプリを構築できます。これは、Web サイトが提供できない機能 (倉庫でのバーコード スキャン、現場営業担当者向けのオフライン注文、Bluetooth デバイス、AR またはバックグラウンド処理) を実現する唯一のルートです。

これは、Magento にパッチが適用されるたびに再テストする 2 番目のコードベースでもあるため、ビルドだけでなくメンテナンスの予算も確保してください。

Magento ではなぜカスタマイズがルートを決定するのでしょうか?

Magento では、どの顧客がどのカタログを参照するか、顧客グループが何を支払うか、運賃の見積り方法、どの支払い方法がどのバスケットに表示されるかなど、重要なロジックが PHP モジュールやテーマ テンプレートに組み込まれていることがよくあります。ネイティブ アプリはテンプレートを読み取ることができません。 REST または GraphQL を通じて Magento に要求しますが、ストアフロントを変更する拡張機能が API を通じて同じ動作を公開するとは限りません。 API サポートの構築にお金を払うか、アプリとサイトの違いを受け入れるか、機能を省略するか、それぞれのギャップが決定となります。

ルート 2 と 3 は、店頭を再利用することでこの質問を回避します。ルート 4 と 5 は、一度に 1 つのカスタマイズでそれに答えます。見積もりを依頼する前に、顧客がサインインから注文確認までの間に使用する拡張機能とカスタム モジュールをリストします。短いリストにより、ネイティブ ルートが現実的になります。長いものは、自分が持っているものを再利用するための議論です。

どのルートがどの Magento ストアに適合しますか?

あなたの状況最初に見るルート
モバイル ストアフロントが遅い、または使いにくいまず店構えを整えてから決定する
モバイル ストアフロントでは注文がよく受け付けられており、毎月のアプリ料金なしで独自の商品を掲載したいと考えています。ウェブサイトからアプリへのコンバーター
B2B 購入者はサインインして交渉価格で再注文します価格とカタログはサーバー側にあるため、コンバーター
アプリが必要ですが、チームの誰もセットアップを所有して送信を保存できませんマネージドアプリサービス
カタログとチェックアウトが標準に近く、ネイティブの製品画面が必要な場合モバイルアプリの拡張機能
スキャン、オフライン注文、またはその他のデバイス機能が必要であるカスタムネイティブビルド
セグメントまたは放棄されたカートによってトリガーされるプッシュ キャンペーンが必要な場合マネージド サービス、その機能を備えた拡張機能、またはカスタム ビルド

SiteTo.App が Magento ストアの選択として間違っているのはどのような場合ですか?

  • モバイル ストアフロントが遅い。 アプリは同じページを読み込むため、最初にキャッシュとテーマを修正します。
  • Web サイトに存在しない画面が必要です。 SiteTo.App は、ページの周囲にネイティブ ナビゲーションを追加します。再設計はしません。
  • ターゲットを絞ったプッシュまたは自動プッシュが必要です。 通知は、オプトインした全員にダッシュボードから手動で送信されます。セグメントやスケジュールはまだなく、Magento イベントによってそれらをトリガーすることはできません。
  • バイヤーはオフラインで作業するか、バーコードをスキャンします。 アプリにはストアを読み込むための接続が必要ですが、スキャンや Bluetooth などのデバイス機能は追加されません。
  • ストアレビューを他の人に担当してもらいたい。 自分の Apple アカウントと Google アカウントから送信します。

Magento の機能は WebView アプリ内でどのように動作しますか?

WebView は Safari や Chrome と同じブラウザ エンジンを使用するため、Magento ストアフロントのほとんどは携帯電話のブラウザと同じように動作します。例外は予測可能です。

Sessions. Adobe のドキュメント 顧客セッションの有効期間 デフォルトの Cookie の有効期間は 3,600 秒であり、セッション Cookie の有効期限が切れた顧客はサインアウトされます。アプリのユーザーはサインインしたままにすることを期待しているため、このデフォルトは慎重な決定に値します。この設定は、[ストア] > [構成] > [一般] > [Web] > [デフォルトの Cookie 設定] にあります。サーバーセッションは別個のタイムアウトであり、アドビでは、これに対する管理者設定がないため、開発者がサーバー上の PHP 設定で変更することを指摘しています。セッションを長くするとセキュリティとのトレードオフが生じるため、一緒に合意してください。の 永続的なカート 顧客が「Remember Me」にチェックを入れた場合、セッション終了後もそのデバイスでカートを利用できる状態が維持されます。

キャッシュされたページ。 フルページ キャッシュを使用すると、Magento はページが読み込まれた後、ブラウザーのローカル ストレージを使用してミニ カートと顧客名を入力します。これは WebView で機能しますが、カートに追加した後、チェックアウト後、サインアウト後にカート数を確認してください。

Payments. ゲートウェイのカード フィールドは Web フォームです。 3-D セキュア チャレンジ、PayPal、後払いプロバイダー、銀行リダイレクトはすべてページを離れ、注文成功ページに戻る必要があります。 Apple Pay と Google Pay は、デバイスと組み込みブラウザが公開する内容によって異なります。両方のプラットフォームですべてのメソッドをテストします。

Sign-in. 電子メールとパスワードは信頼できるパスであり、ストアフロントの reCAPTCHA は通常、モバイル Web と同じように読み込まれます。 Googleの OAuth ポリシー では、埋め込み Web ビュー内でのサインイン画面が許可されていないため、ブラウザーでの動作中にアプリ内でソーシャル ログイン拡張機能の Google ボタンが失敗する可能性があります。

B2B ページ。 企業アカウント、共有カタログ、クイックオーダー、要求リスト、および交渉可能な見積もり アドビコマース B2B はストアフロント ページなので、他のページと同様にアプリで開きます。ファイル アクションはテストする部分です。CSV を Quick Order にアップロードし、請求書 PDF をダウンロードします。

ストアビュー。 アプリは 1 つの URL を開きます。ストア ビューがパス内で別のドメインまたはストア コードを使用する場合は、アプリの開始場所を決定し、ストアと通貨スイッチャーにアクセスできるようにしてください。

Magento ストアをアプリとして段階的にテストするにはどうすればよいですか?

可能であれば iPhone と Android 電話を 90 分ほど用意し、顧客グループごとにテスト アカウントを用意します。プレビューは無料でカードも必要ないため、支払う前にプラン全体を実行してください。

ステップ 1: 電話で店頭を確認する

携帯電話の Safari と Chrome で実稼働ストアを開きます。ホーム ページ、大きなカテゴリ、商品ページをモバイル データ上に読み込みます。ここで遅いことやぎこちないことはアプリでも同様です。

ステップ 2: プレビューを作成する

店頭の住所を貼り付けます SiteTo.App。 VPN または IP ホワイトリストの背後にあるステージング サイトは電話機に読み込まれないため、運用 URL を使用してください。アプリ名、アイコン、起動画面を設定し、リピーターの行動に基づいてタブを作成します。一般的なセットはホーム、検索、カート、注文、アカウントであり、B2B ストアではホームをクイック注文に置き換えることもあります。 URL を書き換えると Magento のデフォルトのパスが変更されるため、ライブサイトから各リンクをコピーします。 Magento の検索結果 URL には検索語が必要なので、高度な検索ページまたは検索ボックスにアクセスしやすいページにある [検索] タブをポイントします。コードをスキャンして携帯電話でアプリを開きます。

ステップ 3: サインインとセッションをテストする

リテール アカウントでサインインし、アカウント ダッシュボードを開きます。プレビューを完全に閉じてから再度開き、まだサインインしていることを確認します。その後、1 時間以上放置してからもう一度お試しください。メールで送信されたリンクはアプリの外部で開くため、パスワードのリセットをリクエストします。提供されているすべてのソーシャル ログイン ボタンをタップします。

ステップ 4: 顧客グループごとに価格とカタログをテストする

卸売アカウントまたは企業アカウントとしてサインインし、3 つまたは 4 つの製品を Web サイトと比較して価格と階層価格を確認します。共有カタログを使用している場合は、その会社のカタログ外の製品が非表示のままであることを確認してください。

ステップ 5: 製品タイプ、検索、フィルターをテストする

構成可能な製品、バンドル、およびカスタム オプションを備えた製品をカートに追加します。 SKU で検索します。大きなカテゴリでは、複数の階層化されたナビゲーション フィルターを適用し、製品を開いて、後ろにスワイプしてフィルターがまだ適用されていることを確認します。

ステップ 6: 実際に注文する

3D セキュアをトリガーするカードやリダイレクトするすべての方法を含む、各支払い方法で注文を完了します。後で返金される低額の実際の注文が最も信頼できるテストです。アプリ内の成功ページに到達したことを確認します。 B2B の場合は、アカウントで注文し、注文履歴から再注文することもできます。

ステップ 7: 重複を確認して終了する

ネイティブ ヘッダーの下に表示されるサイト ヘッダーと、タブを覆うチャット バブルまたは Cookie 通知を探してください。 SiteTo.App は、アプリ内でのみ実行されるスクリプトを使用してサイト要素を非表示にすることができます。外部リンク、PDF、電話番号を開いて、戻る方法があることを確認します。

ページの問題は Magento で修正され、ナビゲーションの問題は SiteTo.App 設定で修正されます。依存しているハンドオフが失敗し、許容可能なフォールバックがない場合は、別のルートを選択します。あなたはそれを知るために何も費やしませんでした。

費用はいくらですか? アプリの所有者は誰ですか?

SiteTo.App の料金はプラットフォームごとに 1 回につき、Android の場合は 29 ドル、iOS の場合は 79 ドル、両方を一緒に購入した場合は 99 ドルです。 SiteTo.App サブスクリプションはありません。アイコンの変更など、その後の再構築は別途お見積りとなります。 Magento での日常的な変更には再構築の必要はありません。の 価格ページ に詳細があり、 コストガイド より広い市場を比較します。

アプリは自分の開発者アカウントから公開されるため、リスト、評価、レビューはあなたのものになります。その他のルートについては、Magento のアップグレードに伴う作業も含めた 3 年間の合計を各ベンダーに問い合わせてください。

Magento ベースのアプリを App Store や Google Play に公開するにはどうすればよいですか?

の ガイドを作成して公開する 完全なシーケンスを説明します。 Magento ストアに特有の点がいくつかあります。

iOS. ビルドは署名され、自分の Apple アカウントで TestFlight にアップロードされるため、Mac や Xcode は必要ありません。送信する前に、TestFlight ビルドでテスト計画を繰り返します。見る Xcode を使用せずに Web サイトを iOS アプリに変換する.

Android. Google Play の場合は AAB、直接インストールの場合は APK を受け取ります。 Google は、新しい個人開発者アカウントに対し、本番リリース前にクローズド テストを実行するよう求めているため、そのための時間を確保してください。

査読者アクセス。 カタログや価格がゲストに表示されない場合、レビュー担当者にはログイン ウォールが表示されます。適切なグループにデモ顧客を作成し、その資格情報をレビューメモに記入します。

アカウントの削除。 Apple は、アカウント作成をサポートするアプリに対して、アプリ内でアカウントの削除を提供することを要求しています。デフォルトの Magento カスタマー ダッシュボードには削除オプションがないため、リクエスト フォームまたは拡張機能を追加し、アカウント エリアからリンクします。

商品の支払い。 Magento チェックアウトを通じて購入した物理的な製品は、その単純なケースです。ダウンロード可能な製品またはデジタル サブスクリプションを販売する場合は、 App Store レビューガイドライン 初め。 SiteTo.App はチェックアウトを使用し、Apple In-App Purchaseを追加しません。

Apple と Google が承認の決定を行いますが、その結果については誰も約束できません。 Apple は、Web サイト以外の機能をほとんど追加しないアプリを拒否できる ガイドライン 4.2。ネイティブ ナビゲーション、プッシュ、明確な繰り返しタスクはすべて役に立ちます。 出版ガイド レビューをさらに詳しく説明します。

よくある質問

Magento には顧客向けの独自のモバイル アプリがありますか?

いいえ、アドビは API とストアフロント ツールを提供していますが、ストア用の既製の顧客アプリは提供していません。これは、Web サイトからアプリへのコンバーター、マネージド サービス、モバイル アプリ拡張機能、またはカスタム ビルドを通じて取得できます。

モジュールをインストールせずに Magento 2 ストアをアプリに変えることはできますか?

はい。 SiteTo.App などの Web サイトからアプリへのコンバーターは、公開ストアフロント URL から機能します。 Magento サーバーには何もインストールされず、REST および GraphQL API は使用されません。モバイル アプリ拡張機能は逆のアプローチを採用しており、コネクタ モジュールが必要です。

Magento をアップグレードしたりテーマを変更したりする場合、新しいビルドが必要ですか?

いいえ。アプリはストアフロントで提供するものをすべて読み込むため、次回ページが読み込まれるときにアップグレード、テーマの変更、新しい拡張機能が表示されます。 URL が移動した場合はタブのリンクを更新します。アイコンや起動画面を変更するには、新しいビルドが必要になる場合があります。

次のステップ

顧客がサインインから注文確認までの間に触れる拡張機能とカスタム モジュールをリストします。リストが長く、モバイル ストアフロントですでに注文が順調に受け付けられている場合は、 アプリとして無料でプレビューする 上記の 7 つのステップを実行します。の Magento からアプリページへ テスト中に傍に置いておくための短いチェックリストがあります。

Web サイトをアプリとして見る

プラットフォームを選択する前に、エクスペリエンスをカスタマイズしてプレビューします。

プレビューを構築する

読み続けてください

すべてのガイド