コミュニティソリューション

ZimaOSアプリストアのアップデートの仕組み:手動メンテナンス、安定性、プルリクエスト、アプリストアv2

A November 2025 thread asking why some ZimaOS App Store applications lagged upstream versions. Zima-Giorgio said store versions were manually maintained, stability mattered, availability issues were prioritized, and the team regularly reviewed pull requests. Current App Store v2 adds version/update metadata and content-hash-driven client updates but does not itself guarantee a fixed release cadence.

ZimaOS App Storeの更新は、「上流の更新から必ず7日以内に更新する」といった単純なルールに基づいて管理されていたわけではありません。2025年11月の情報源スレッドで、Zima-Giorgio氏はアプリのバージョンが手動で管理されていると述べました。また、安定性が重要であるため、サービスアプリは意図的に上流の最新リリースより遅れる場合がある一方、利用不能につながる問題にはより高い優先度が与えられると説明しました。

現在のApp Store 2.0では、アプリカタログの構築方法と配信方法が変更されていますが、これによって保証された保守サイクルが自動的に実現するわけではありません。v2プロトコルは、バージョンメタデータ、更新日時、リリースノート、コンテンツハッシュ、クライアントによる差分更新をサポートします。ただし、元となるアプリ定義の保守と検証は、引き続き人の手で行う必要があります。

IceWhaleは、ストアのバージョンが手動で管理されていると説明

直接的な回答は簡潔なものでした。App Storeのソフトウェアバージョンは手動で管理されており、サードパーティーやコミュニティ運営のストアでは、より新しいバージョンが提供される場合があります。

これにより、デフォルトカタログに掲載されているバージョンが、上流のアプリ開発者によって公開された最新タグと異なる理由が説明できます。

最新であることが、必ずしも最も安全とは限らない

Zima-Giorgio氏は後に、サービス型アプリケーションを常に最新リリースですぐに動作させられるとは限らないと説明しました。安定性も判断材料の一つです。

NASでは、検証を経ていないデータベースの更新やメジャーバージョンアップを急いで行うよりも、上流より1つ前の検証済みリリースを使い続けるほうが、問題を引き起こしにくい場合があります。

利用不能につながる問題には、より高い優先度が与えられる

IceWhaleは例としてImmichを挙げました。以前のサーバーが対応するモバイルアプリとの互換性を失った際、App Storeパッケージが更新されました。

これは有用な保守原則です。通常の利用を妨げる障害は、機能追加だけを含む上流リリースよりも、迅速な対応を正当化する場合があります。

プルリクエストは保守ワークフローの一部

IceWhaleは、チームがPRリストを定期的に確認し、必要に応じてリクエストをマージしていると説明しました。Giorgio氏はユーザーにPRの提出や独自ストアの作成を促し、特にUptime Kumaの更新への協力を求めました。

つまり、App Storeはベンダーだけが管理する閉じたカタログではなく、部分的にコミュニティと協力して運営されていることになります。

現在のApp Store v2には、より明確なビルドおよび更新プロトコルがある

現在のIceWhale開発者向けドキュメントによると、生成されたv2ストアには次のようなフィールドが含まれます。

  • version;
  • update_at;
  • release_note;
  • content_hash

クライアントの更新確認はストアインデックスとコンテンツハッシュに基づいて行われるため、変更されていないアプリはスキップされ、変更されたアプリのメタデータやComposeファイルだけを差分取得できます。

現在のApp Store v2のビルドおよび更新モデルをご覧ください。

バージョンメタデータがあっても、保守SLAが設定されるわけではない

ストアでは、より優れたバージョン情報や更新情報を提供できるようになりました。しかし、プロトコルによって、すべてのアプリを一定日数以内に更新しなければならないと定められているわけではありません。カタログの方針決定とアプリの検証は、引き続き人が行うプロセスです。

App StoreのバージョンとDockerイメージタグは関連しているが、同一ではない

Composeファイルでは、特定のイメージタグを固定することも、latestのような広範なタグを使うことも、複数の独立したイメージを含むマルチサービス構成を参照することもできます。表示されるストアのバージョンは、パッケージ化されたアプリ定義を示すものであり、スタック内のすべてのイメージが同じバージョン番号に従うことを保証するものではありません。

上流の正確なバージョン管理が重要な場合は、Compose定義を確認してください。

メジャーアップデートには、より慎重な対応が必要

Nextcloud、Immich、データベース、ホームオートメーションプラットフォームなどのアプリケーションでは、スキーマの移行や互換性を損なう設定変更が発生する可能性があります。保守担当者が移行動作を検証する間、App Storeの更新が遅れることは意図的な場合があります。

カタログより先に手動で更新する場合は、事前にアプリケーションデータをバックアップしてください。

コミュニティストアはより速く更新できるが、リスクも異なる

サードパーティーのストアでは、より新しいバージョンが早く公開される場合があります。しかし、その検証、更新頻度、ロールバックの品質は、運営者の保守状況に左右されます。「デフォルトストアより新しい」ことが、必ずしも「より十分にテストされている」ことを意味するわけではありません。

App Store更新に関するよくある質問

IceWhaleは、毎月決まった更新サイクルを約束していましたか?

いいえ。情報源では、バージョンは手動で管理され、安定性と可用性が優先度に影響すると説明されています。

ユーザーはApp Storeアプリの更新に協力できますか?

はい。IceWhaleは、プルリクエストの提出とサードパーティーストアの運営を明確に推奨しています。

App Store v2では更新メタデータが改善されていますか?

はい。現在のv2出力では、バージョン、更新日時、リリースノート、コンテンツハッシュに基づく更新確認がサポートされています。