Flutterについて(受託開発)

よし、Flutterを覚えよう


10年くらい、android,iOSのアプリ開発(受託)をやってきました。

最近の傾向として、

スマホアプリの開発案件は全体で少なくなってきたかもしれません。

それと、アプリの難易度アップ(高機能なアプリ)が見受けられます。


少なくなってきた傾向として

・iOS ,android の両方の技術者が必要で、コストがかかる

・アプリの定期的な更新が必要でサーバーのランニングコストよりもかかる

このへんかなと、


あとは、フリーのエンジニアに叩き売りする感じのところもあるようです。


普通の企業でアプリを提案すると

最近は予算が問題でなかなか弱腰な事が多いです。


そこで、今後のアプリ開発を少しでも増やすため、

マルチプラットフォーム対応のものを利用して、

従来のアプリ開発の費用を減らして、数を回し、保守もらう流れを検討しています。


そこで目をつけたのが、Flutterでゲーム系でなければ敷居は低く参入できる。

Googleもある程度本気の様子なので。

今後2〜3年は確実にFlutterはあるりそうな気配もあります。


Flutter案件を提案して受託できるように勉強や情報収集していきます。


Google アナリティクス 4 ってなに?

2023 年 7 月 1 日より、ユニバーサル アナリティクスでは標準プロパティで新しいデータの処理ができなくなります。それまでに Google アナリティクス 4 プロパティに切り替えて設定を進めておきましょう。


ねぇ、これって どうゆこと?


iOSのアプリが次々に削除されている様子です

Appleが公式サイト( https://developer.apple.com/news/?id=gi6npkmf )で発表したApp Store Improvementsという施策が開発者の間で波紋を呼んでいる。3年以上更新がなく、かつダウンロード数が極めて少ないアプリをApp Storeから削除するという方針だ。すでに280万本以上のアプリがこのプロセスによって削除されたという事実は、モバイルアプリ市場の巨大な新陳代謝を象徴している。


この施策の核心は、長期間メンテナンスされていないアプリ、いわゆる塩漬けアプリの排除にある。開発者として一度リリースしたアプリが手入れされずに放置されることは珍しくない。特に個人開発者や小規模なチームでは、次々と新しいプロジェクトに移る過程で、過去の遺産が管理外に置かれるケースは往々にしてある。Appleはこれらを品質低下のリスク要因と見なしている。


削除対象となる条件は2つある。1つ目は3年以内にアップデートが行われていないこと。技術的な観点から見れば妥当な期間だ。3年あればiOSのバージョンは3つ進み、iPhoneのハードウェアも大きく進化する。画面サイズの変更、ノッチやダイナミックアイランドの登場、プライバシー要件の厳格化など、3年前のコードベースが現在の環境で最適に動作する保証はない。古いAPIを使用し続けることは、セキュリティ上の脆弱性を招く可能性も否定できない。


2つ目の条件は、直近12ヶ月間でのダウンロード数が極めて少ない、あるいは全くないことだ。この条件が曲者で、極めて少ないという表現の具体的な閾値は公表されていない。しかし、文脈から読み取れるのは、新規ユーザーからの需要が消失しているアプリをターゲットにしているという点だ。既存のユーザーが継続して利用しているだけでは不十分で、ストアという市場において新たな価値を提供できていないアプリは退場を迫られる。


多くの開発者が抱く懸念は、完成されたツール系アプリの扱いだ。電卓や単位変換、特定の計算を行う単機能アプリなどは、一度完成すれば頻繁な更新を必要としない。機能がシンプルであればあるほど、バグも出にくく、OSの更新による影響も受けにくい。これらが更新不足という理由だけで削除されるのは理不尽に感じる。しかしAppleの論理では、プロモーションもメンテナンスも行われないアプリは、ストアの検索ノイズとなり、ユーザーが本当に求めている高品質な最新アプリへの到達を阻害する要因となる。


ポジティブな側面もある。削除通知を受け取った場合の猶予期間が、当初の30日から90日に延長された。この変更は開発者コミュニティからのフィードバックを受けたもので、90日あれば対応の余地は十分にある。大規模な改修を行わずとも、最新のXcodeでビルドし直し、最低限の動作確認を行って再提出するだけで、アップデートの実績は作れる。それだけでアプリの寿命を延ばすことができるのだから、開発者にとっては必須のメンテナンス作業として組み込むべきだろう。


削除されたとしても、そのアプリがこの世から消滅するわけではない。すでにユーザーの端末にインストールされているアプリは引き続き動作するし、アプリ内課金のリストア機能なども維持される。影響を受けるのはあくまで、App Storeでの新規発見とインストールだ。既存のユーザーベースを維持しつつ、ストア上での公開を終了するという選択肢も、ビジネスモデルによってはあり得る。


なぜAppleはここまで強硬に整理整頓を進めるのか。それはApp Storeというプラットフォームの信頼性を維持するためだ。ユーザーがアプリを検索したとき、動作しないアプリや画面レイアウトが崩れた古いアプリが表示されれば、iPhoneそのものの体験価値が下がる。最新の技術、最新のデザインガイドライン、最新のプライバシー保護機能に準拠したアプリだけが並ぶ場所でありたいというAppleの意思表示は明確だ。


280万本という削除数は、見方を変えればそれだけの数のアプリが役割を終えたということでもある。デジタルコンテンツは永遠に残ると思われがちだが、OSという土台が常に変化し続ける以上、その上で動くアプリもまた生物のように適応し続けなければならない。変化に対応できない種が淘汰されるのと同様に、更新されないアプリもまた姿を消していく。


開発者が取るべき行動はシンプルだ。App Store Connectに登録しているメールアドレスが有効かを確認し、Appleからの通知を見逃さないようにする。そして、自分のポートフォリオの中に最終更新日が2023年以前のアプリがないか棚卸しをする。もし該当するアプリがあり、それを存続させたいと願うなら、今すぐXcodeを開くべきだ。コードを書き換える必要すらなく、ただ最新の環境でビルドボタンを押すだけで救える命がある。


ダウンロード数の基準が曖昧なことへの不安は残る。極めて少ないという言葉が、月間10ダウンロードを指すのか、年間100ダウンロードを指すのかは誰も知らない。この不透明さは、開発者に常に緊張感を強いる。ボーダーライン上にいるアプリを持つ開発者は、この通知に怯えることになるだろう。しかし、逆に言えば、それほどギリギリの需要しかないアプリにどれだけのリソースを割くべきか、という冷徹なビジネス判断を迫られているとも言える。


ストアの品質担保はユーザーにとって最大の利益だ。検索結果が洗練され、安心してダウンロードできる環境が整えば、結果としてアプリ全体の利用率は向上する。現役で活動している開発者にとっては、放置された競合アプリが消えることで、自社のアプリがユーザーの目に留まる機会が増えるチャンスでもある。ゴミ屋敷を掃除しなければ新しい家具は置けない。App Store Improvementsは、アプリ経済圏を持続可能なものにするための必要な自浄作用だ。


技術的負債という言葉があるが、ストア上の公開状態を維持すること自体にもコストがかかる時代になった。放置こそが最大のリスクであり、何もしないことが即ち退場につながる。私たちは、ただコードを書くだけでなく、書いたコードが生き続けるための環境整備もまた、エンジニアリングの一部として受け入れなければならない。週末に久しぶりに古いリポジトリをcloneし、ライブラリの依存関係を解決し、ビルドエラーと格闘する。そんな泥臭い作業こそが、愛するアプリを守る唯一の手段だ。


Guideline 2.3.10 で審査が落ちた話。

結論を記載します。

Guideline 2.3.10 の殆どは、

Apple(iOS)以外の事は記載してはいけません。ってやつです。

android も同時リリースの場合、

よく、Webviewとかで、

htmlにまとめて(面倒なので)表記する事があったりしますが、

内部で表示するものに関しては、リジェクトされます。

外部ブラウザで表示させるか、(こっちはちょっと自信ないですが・・・。)

内部で表示する場合は、URLを分けるか、javaScriptなどで、

出し分ける対応すれば良いです。

Guideline 2.3.10 - Performance - Accurate Metadata
We noticed that your submission includes irrelevant third-party platform information.
Specifically, your description includes Google Play references.