Wikipedia iOS公式アプリの開発環境と検証経路

公式アプリとしてのリポジトリ

wikimedia/wikipedia-iosはWikipediaの公式iOSアプリを公開するSwift中心のリポジトリです。メタデータはMIT Licenseを示し、Wikimedia AppsのチームページとPhabricatorの計画ページが開発の窓口としてリンクされています。READMEは利用者向け機能一覧よりも、Xcodeでプロジェクトを開き、スキームを選び、テストする開発者向け情報を中心にしています。したがって、このリポジトリを読むときはアプリの画面仕様を推測せず、設定、ターゲット、テストコードがどのサービス環境を向いているかから確認するのが適切です。

scripts/setupからXcodeへ

基本の流れはscripts/setupを実行した後、Wikipedia.xcodeprojを開き、Wikipedia schemeとtargetでiOS Simulator上のアプリを実行することです。依存ツールとしてXcode、SwiftLint、Objective-Cコードのlintに使うClangFormatが挙げられています。インストール済みのXcodeだけで完了すると決めつけず、リポジトリが要求する依存物をsetupが取得できたかをログで確認します。初回のビルドでは署名やシミュレータのランタイムが原因になりやすいため、アプリの実行と単体テストを別工程として記録します。

WikipediaとStagingを切り替える仕組み

Wikipedia schemeはproduction serversを指します。Staging schemeは複数のstaging server環境を使い、Configuration.swiftのcurrent propertyを変更して対象を調整します。Experimentalは試作やデザイン確認用で、既定ではproductionを向きます。Debug専用のLocal Page Content Service and Announcementsはローカル環境を切り替える用途、RTLは-AppleLocaleで右から左の表示を起動する用途です。環境を切り替える変更はコードと同じ重さで扱い、テスト用の設定が本番スキームへ混ざっていないことを確認してください。

テストに残る地域依存

Wikipedia schemeにはiOS unit testsを実行する設定があり、Cmd+UまたはProductからテストできます。READMEはテスト端末の言語と地域をSettingsのLanguage & Regionでen-USにしないとテストが通らないと明記しています。地域に依存するテストを見逃すと、別ロケールの開発者だけが失敗する状態になります。RTL schemeやローカライズ更新の経路と合わせ、en-USでの基準実行、別地域での表示確認、失敗したテストの条件をそれぞれ保存するのが具体的な確認方法です。

ターゲットとリリース前の見方

WMF targetはメインアプリとextension、ウィジェットや通知で共有するアプリロジックを束ねます。Performance TestingはWikipediaの複製schemeですが、Run stepをRelease configurationにして手動の性能確認に使います。複数targetがあるため、単一のアプリ起動だけではextensionのビルドや設定を検証できません。MITの利用条件を確認し、XcodeでWikipedia、Staging、Performance Testingを順にビルドして、接続先、構成、テスト結果を分離して記録することが、このコードベースに即した導入判断になります。

環境設定をテスト記録に残す

Wikipedia iOSの開発では、Configuration.swiftのcurrent propertyが向く先を変更したままコミットしない運用が必要です。Wikipedia schemeのproduction、Staging、Experimentalを同じ端末で試すときは、アプリのbundleや保存データを区別し、どのサーバーへリクエストしたかをログで確認します。Local Page Content Service and AnnouncementsはDebug専用、RTLもlaunch argumentを使う開発用経路なので、Release configurationへ混ざらないことを確認します。Performance TestingではReleaseを走らせ、起動時間や主要画面の計測条件を固定します。Cmd+Uのunit testはen-USの言語地域で基準を取り、別ロケールでは既知のT259859との関係を記録します。extensionとwidgetを含むWMF targetまでビルドできて初めて、アプリ本体以外の変更を評価できます。

ローカルと本番の事故を切り分ける

Wikipedia iOSを起動する前にConfiguration.swiftのcurrent propertyとscheme名を記録し、productionへ向くWikipediaとStagingを別の実行データで試します。Experimentalは一時的な機能確認用として扱い、TestFlight向けの設定が通常のReleaseへ混ざらないかを確認します。RTLは-AppleLocale launch argumentで起動し、Update Localizationsの処理後に英語とRTLのレイアウト差を比較します。Performance TestingではRelease configurationの起動と主要画面を同じ端末で計測します。Wikipedia schemeのCmd+Uはen-USで基準を取り、extension、widget、notificationを束ねるWMF targetもビルドして、アプリ本体だけが成功した状態を完成としないことが必要です。

スキームを混ぜずにビルドする

scripts/setup後にWikipedia、Staging、Experimentalを個別に起動し、Configuration.swiftのcurrentと接続先を記録します。en-USのシミュレータでCmd+Uを実行し、RTL、Local Page Content Service、Performance Testingの設定を別に確認します。WMF targetとextension、widgetもビルドし、production設定がテスト用変更を含まないことを確認します。 READMEの既知の地域依存をテスト計画に明記し、en-US以外で失敗した場合はアプリの不具合と断定せず、T259859の状態とテストの期待値を照合します。コードレビューではSwiftとObjective-Cそれぞれのガイドラインにも戻ります。 Xcodeの署名、Simulatorのruntime、SwiftLintとClangFormatの版を保存し、再現できる環境としてチームへ共有します。 StagingとWikipediaの通信先を取り違えないよう、scheme名とConfiguration.swiftのcurrentを起動ログへ出力します。 Xcodeのテスト端末言語を固定し、テスト結果とschemeの接続先を一緒に保存します。 テスト端末の言語地域、scheme、Configuration.swiftの値を毎回記録します。 Stagingの接続先、en-USの言語地域、Wikipedia schemeのunit test結果を一緒に保存し、別ロケールの失敗とコード変更を切り分けます。

編集部の結論

WikipediaのiOSクライアントを調査したい開発者には、公式アプリのコードと開発用スキームを追える資料です。ビルド前にscripts/setupを実行し、Xcodeの対象バージョンと署名を確認したうえで、en-US設定のシミュレータでテストを走らせ、Staging接続を本番と分けてください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes