先日配信再開したAndroid版に続き、iOS版の東方BGM on VGSもAppStoreで配信再開しました。
https://apps.apple.com/jp/app/id680248037
実は数日前から既に旧バージョンをそのまま復活させていたのですが、本日からAndroid版と同等のアップデートがされました。
久々のApple審査対応は中々楽しかったです。（Appleによるバイナリリジェクトが1回、メタデータリジェクトが1回、審査待ちの間の自己審査によるセルフリジェクトが7回ぐらい）
機能的には、Android版とほぼ同じですが、モダンUIの見た目が少し異なります。
Android版のモダンUIはマテリアルデザイン（にしたつもり）で作りましたが、iOS版の方は私の個人的な趣向でフラットデザイン & ダークモード固定にしてみました。
デザイン方面はサッパリなので、マテリアル or フラットのどっちが良いのか実のところよく分からないです。（フラットが好きなのは作りやすいため）
しばらくの間（1ヶ月ぐらい?）、色々と手が回らないと思いますが、落ち着いたら月1回程度でも曲追加できたら良いなと思っています。
半分わざと、私自身のお尻に火をつけるため「曲追加をしないと収益が上げにくいマネタリング構造」にしてみたので、今度こそは続けられる...筈。
なお、旧東方VGSの頃はApple審査に結構時間が掛かった関係で、Androidは即アップデート、iOSはある程度まとまってから月1ペースぐらいでアップデートという（管理が面倒な）リリーススケジュールで運営してましたが、最近は審査期間がAndroidもiOSもあまり変わらないので、今後アップデートはAndroid/iOSほぼほぼ同時になる予定です。
基本、審査が通ったら即リリースするので、若干のラグはあるかもしれませんが。
以下、技術寄りのネタです。
VGSは元から「半エミュレーション」みたいな技術で作っていたので、単一のFragmentやViewで簡単に組み込むことが出来ます。
iOS版もAndroid版と同様、GPLv3ライセンスのOSSとしてソースコードを公開しているので、気になる方は覗いてみてください。
https://github.com/suzukiplan/tohovgs4-ios
なお、Android版の開発言語はKotlinですが、iOS版はSwiftではなくObjective-cです。
新規にスマホアプリを開発するならDart（Flutter）、ゲーム系ならC#（というかUnity）というのが今後のトレンドだと思われるので、Swiftを習得する機会を逸してしまった感があります。（Flutterについてはまだメインストリームというよりは比較的攻めているデベロッパしか使ってないかもしれませんが）
それなら東方VGSも今回はDartで作れば良かった訳ですが、Android版を復活させた時点ではiOS版の復活は未定で、最低限 iOS Developer Program の年会費を支払える程度の収益が得られそうなら復活させようと考えていたので、Dart より手早く作れる Kotlin で開発した経緯があります。
GitHubの方を見て頂けると東方BGM on VGSの言語構成比率を見ることができますが、実装の約9割が C/C++ で、OSネイティブ実装（Kotlin, Objective-c）のコード量は大したことがないから、それなら色々と面倒なP/F共通化をするよりも小回りが効くネイティブ言語（Kotlin, Swift）の方がメンテし易いかも...という見立てもあります。（Flutterではないですが実際こういう話しもあるらしいですし）
安定運用フェーズになれば基本的にネイティブコードは殆ど触らず、songlist.jsonの更新とMMLファイルの追加だけになるように設計しているので、ネイティブコードを触る必要があるのはOSのアップデートや依存ライブラリのアップデートなどへの追従ぐらいになる筈で、それならOSネイティブ言語で開発しておいた方がメンテナンスが楽になるのではないかという見立てもあります。
また、現状曲の追加にはアプリのアップデートが必要な形になってますが、曲データの配信をサーバで行い、アプリのアップデート頻度を下げる方策についても並行して検討中です。
以下、現在検討中のサーバサイド（動的な曲配信）についての技術ネタです。
アプリのアプデ作業も中々手間が掛かるので、サーバで曲データを配信するのが良いのは当然です。
そこで、私が tohovgs-cli (GitHub) で曲データ追加の Pull Request をマージすれば、アプリに追加した曲が配信されるような形のコンテンツ配信システムを現在検討中です。
AWSとかを使えばサーバ系が専門外の私でも、そういったサーバの構築自体は簡単にできます。
ただし、下手に構築してしまうとサーバコストが発生してしまい、それで赤字になるとまた続けられなくなってしまいます。変動費が増える分には売上でペイできるので問題無いかもしれませんが、固定費は極限まで0円に漸近させなければなりません。
今のアプリの構造上、tohovgs-cli の GitHub Pages で songlist.json と MML ファイルだけ配信できれば（つまり、静的ホスティングだけできれば）動的な曲配信に対応出来るので、小規模な内は GitHub Pages でサーバ配信がノーコスト対応可能かも...と思ったのですが、どうやらそういった使い方はNGらしいです。
Prohibited uses
GitHub Pages is not intended for or allowed to be used as a free web hosting service to run your online business, e-commerce site, or any other website that is primarily directed at either facilitating commercial transactions or providing commercial software as a service (SaaS).
GitHub Pagesは、オンラインビジネス、eコマースサイト、その他商取引の促進や商用ソフトウェア(SaaS)の提供を主目的とするウェブサイトを運営するための無料ウェブホスティングサービスとして使用することは意図されていませんし、許可もされていません。
なので、動的な曲配信という用途で GitHub Pages を使うことはできません。
その他の方法としてはFirebase Hosting を使う方法もありますが、Sparkプラン（無料）だと 10GB/月 が上限（GitHub Pages の 1/10）で、Blazeプラン（有料）だと10GB/月を超えると 1GB あたり $0.15 らしいです。
AWS S3 なら50TBまでは1GBあたり$0.023なので、一見するとAWSの方がお得に見えますが、CDN（CloudFront）を使う場合、クライアントの地域によって値段が変わり、日本なら 1GB あたり$0.114掛かるので合計すると $0.137。最初の10GBまで無料という点を勘案すると、Firebase Hosting の方がお得かもしれません。
GCPもStorage+CDNならAWSよりちょっと安いぐらい。
東方VGSはそもそもデータサイズが小さいから、恐らく無料枠（10GB）だけで余裕で捌けそうなので、Firebase Hostingが一番コスパが良いだろうと思っているところです。
また、Firebase HostingならダイレクトにGitHub actionsと統合できる点が強いので、私のユースケース的にもやはりFirebase Hostingが有力かなと。
0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。