SwiftUIでiPhoneアプリを開発し、App Storeに公開する。
ここまでは何とか進められても、次に考えるのが「どうやって収益化するか」という問題です。
私自身、個人開発したアプリを複数公開しており、最近はGoogle AdMobを使った広告収益化にも取り組んでいます。
ところが、実際に導入してみると、SwiftUI側の実装だけでは完結しませんでした。
特に手間取ったのが、app-ads.txtの設定です。
この記事では、実際の作業で確認した内容を中心に、AdMob導入時の注意点とトラブルの切り分け方法をまとめます。
- AdMob導入で必要になる作業
iOSアプリにAdMobを導入する場合、主に次の作業が必要になります。 - Google AdMobでアプリを登録する
- 広告ユニットを作成する
- Google Mobile Ads SDKを導入する
- SwiftUIに広告表示処理を実装する
- 開発中はテスト広告を使用する
- app-ads.txtを公開する
- AdMob管理画面で確認状況をチェックする
ここで重要なのは、広告を表示するための実装と、広告配信のための設定は別物という点です。
アプリのコードが正しくても、Web側の設定が不足していることがあります。
SwiftUIにGoogle Mobile Ads SDKを導入する
Google Mobile Ads SDKはSwift Package Managerを利用して導入できます。
Xcodeでプロジェクトを開き、以下の順番で操作します。
File → Add Package Dependencies
パッケージのURLには、Google公式のリポジトリを指定します。
https://github.com/googleads/swift-package-manager-google-mobile-ads
利用するバージョンや対応環境は、導入時点の公式ドキュメントで確認してください。
SDKを追加した後は、アプリの構成に合わせて初期化処理を実装します。
例えば、SwiftUIのApp構造体では次のように記述できます。
import SwiftUI
import GoogleMobileAds
@main
struct MyApp: App {
init() {
MobileAds.shared.start()
}
var body: some Scene {
WindowGroup {
ContentView()
}
}
}
これは初期化方法を示す簡略例です。
実際には、必要なプライバシー対応や同意取得を確認したうえで、適切なタイミングで初期化・広告読み込みを行います。
また、Google Mobile Ads SDKの導入には、アプリIDなどの必要な設定も伴います。
開発中は必ずテスト広告を使用する
広告を導入する際に注意したいのが、本番広告とテスト広告の使い分けです。
開発中はGoogleが提供するテスト広告ユニットIDを使用するか、テストデバイスを設定します。
例えば、iOSのバナー広告用テストIDは以下です。
ca-app-pub-3940256099942544/2435281174
実際の開発では、DebugビルドとReleaseビルドで広告ユニットIDを切り替える方法が便利です。
enum AdConfiguration {
static var bannerUnitID: String {
#if DEBUG
return "ca-app-pub-3940256099942544/2435281174"
#else
return "YOUR_PRODUCTION_AD_UNIT_ID"
#endif
}
}
本番環境では、自分のAdMob管理画面で発行した広告ユニットIDを指定します。
ただし、この実装だけで広告表示が完了するわけではありません。広告ビューの実装や読み込み処理も必要です。
開発中に本番広告を繰り返し表示・クリックしないことが重要です。
app-ads.txtとは?
app-ads.txtは、アプリの広告枠を販売することが認められている事業者を公開するための仕組みです。
AdMobでアプリの収益化を進める場合、このファイルの公開と確認が重要になります。
ファイルの内容は、AdMob管理画面で案内される情報を利用します。
形式の例は次のとおりです。
google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0
pub-XXXXXXXXXXXXXXXXの部分には、自分のパブリッシャーIDが入ります。
この値は例示用なので、そのまま使用しないでください。
5. app-ads.txtで404エラーが発生した
私が実際に遭遇した問題が、app-ads.txtの公開先で404エラーが発生するというものでした。
ファイルを作成したつもりでも、指定したURLでアクセスできなければ、AdMob側から正しく確認してもらえません。
そこで、MacのターミナルからHTTPステータスを確認しました。
curl -L -sS -o /dev/null
-w 'HTTP: %{http_code}\n'
--max-time 15
"https://example.com/app-ads.txt"
example.comは、自分が公開したドメインに置き換えます。
正常にファイルが公開されていれば、通常は次のようになります。
HTTP: 200
一方、ファイルが見つからない場合には以下が返されます。
HTTP: 404
404の場合は、公開先のディレクトリ、デプロイ状況、URLの指定が正しいか確認します。
HTTP 200でもAdMobの確認完了とは限らない
ここは特に重要です。
HTTP 200が返ってきたことと、AdMobによる認証が完了したことは同じではありません。
HTTP 200で分かるのは、指定したURLに対してサーバーが正常なHTTPレスポンスを返したということです。
そのため、次のような確認も必要です。
curl -L -sS
--max-time 15
"https://example.com/app-ads.txt"
ファイルの中身が正しいことを確認したうえで、AdMob管理画面のステータスも確認します。
また、公開先が正しくても、App Storeに登録したデベロッパWebサイトとの関連付けなどが適切でなければ、期待どおりに検出されない場合があります。
設定を変更した直後は、AdMob側の反映まで時間がかかることもあります。
何度も設定を変更する前に、まず公開状態を確認するのがおすすめです。
広告を表示する場所も重要
広告収益化では、広告を表示できればよいというわけではありません。
個人的には、ユーザーがアプリ本来の機能を使う際に邪魔にならない配置を意識しています。
例えば、診断アプリの場合です。
- 診断中は操作に集中できるようにする
- 結果を確認する体験を優先する
- 誤タップが起きやすい位置を避ける
- 広告のために重要な操作ボタンを隠さない
短期的な広告表示回数だけでなく、継続利用されるアプリを目指すことが大切だと考えています。
個人開発で学んだこと
今回のAdMob導入を通じて感じたのは、アプリ開発と収益化では求められる作業が少し違うということです。
SwiftUIで画面を作り、機能を実装するだけでは収益化は完了しません。
広告SDKの設定、Webサイト側のファイル公開、App Storeの情報、プライバシー対応など、複数の要素が関係します。
また、トラブルが発生したときは、闇雲にコードを書き換えるよりも、問題がどこにあるのかを切り分ける方が効率的でした。
今回の場合、curlコマンドを使って公開先の状態を確認できたことが役立ちました。
Macのターミナルで確認できることは、できるだけターミナルで確認する。
個人開発では、こうした小さな工夫も作業効率につながると感じています。
まとめ
SwiftUIアプリへのAdMob導入では、次のポイントが重要です。
- SDKの導入だけでなく、必要なアプリ設定も確認する
- 開発中はテスト広告を使用する
- app-ads.txtが正しく公開されているか確認する
- HTTP 200とAdMob側の認証完了を区別する
- 広告配置ではユーザー体験を優先する
- トラブルはコード・Web公開・管理画面に分けて切り分ける
今後も、SwiftUIやXcodeを使ったiOS・macOSアプリ開発について、実際に経験した内容を発信していきたいと思います。
アプリ開発・SwiftUIのご相談について
現在、個人でiPhone・Macアプリの開発・公開を行っています。
SwiftUIアプリの修正、機能追加、App Store申請準備などのご相談も受け付けています。
Swift修正・機能追加サービス
https://coconala.com/services/4435856
最後までお読みいただき、ありがとうございました。