<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>mobile on Ikoma's Blog</title><link>https://blog.yusukeikoma.com/ja/tags/mobile/</link><description>Recent content in mobile on Ikoma's Blog</description><generator>Hugo</generator><language>ja-jp</language><lastBuildDate>Wed, 30 Sep 2026 11:33:30 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/ja/tags/mobile/index.xml" rel="self" type="application/rss+xml"/><item><title>Expo の fingerprint ランタイムバージョンは、JavaScript ではなく extra の編集で変わる</title><link>https://blog.yusukeikoma.com/ja/posts/fingerprint-runtime-version-changes-when-you-edit-extra/</link><pubDate>Wed, 30 Sep 2026 11:33:30 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/fingerprint-runtime-version-changes-when-you-edit-extra/</guid><description>OTA アップデートは、変更できないネイティブのバイナリを呼び出す JavaScript です。ランタイムバージョンは、そのバイナリの ABI バージョンだと考えられます。@expo/fingerprint 0.20.13 を使った実験で、どの編集がハッシュを変え(extra、version、ビルド番号、ネイティブモジュール)、どれが変えないか(JavaScript、純 JS の依存)を確かめ、既定値を黙って落とすスキップリストの落とし穴も見ます。</description></item><item><title>React Native 標準の URL は '../x' を解決しない</title><link>https://blog.yusukeikoma.com/ja/posts/react-native-builtin-url-does-not-resolve-dot-dot/</link><pubDate>Sat, 26 Sep 2026 21:31:14 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/react-native-builtin-url-does-not-resolve-dot-dot/</guid><description>ウェブサイトと React Native アプリで共有するクライアントライブラリが壊れるのは、fetch ではなく、Web プラットフォームの地味な部分であることが多いです。React Native 0.87.1 と Expo 57 のソースを読むと、ランタイムが3層あること、ウェブなら &amp;lsquo;/b/x&amp;rsquo; になるところを &amp;lsquo;/b/c/d/../x&amp;rsquo; と返す URL クラスがあること、Expo が置き換えない限り fetch にレスポンスのストリームがないことが分かります。必要なものを確認する小さなクライアントを、4つの模擬ランタイムでテストします。</description></item><item><title>APNs が保持する通知は1アプリ1件だけなので、プッシュはヒントとして設計する</title><link>https://blog.yusukeikoma.com/ja/posts/push-notifications-are-hints-apns-stores-one/</link><pubDate>Sat, 19 Sep 2026 21:10:16 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/push-notifications-are-hints-apns-stores-one/</guid><description>端末がオフラインのとき、アプリが終了されたとき、送信が多すぎるときにプッシュがどうなるかを、AppleとGoogleは文書で説明しています。通知は置き換えられ、捨てられ、順序が入れ替わり、遅れます。文書に書かれた失敗モードの表と、ペイロードを適用するクライアントが収束せず、カーソルから取得するクライアントが収束することを示す小さなシミュレーションを紹介します。</description></item><item><title>ステップアップ認証のチャレンジは 401 で届き、クライアントにはループ防止が要る</title><link>https://blog.yusukeikoma.com/ja/posts/step-up-authentication-challenge-is-a-401/</link><pubDate>Tue, 15 Sep 2026 13:18:09 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/step-up-authentication-challenge-is-a-401/</guid><description>RFC 9470 は、API がクライアントに「このトークンは、弱すぎる、または古すぎるログインで取得されたものだ」と伝える方法を定めています。RFC を節ごとに読み、試作のサーバーとクライアントを作ると、仕様が決めているもの(401 のチャレンジと2つのパラメーター)と、実装側に残されているもの(同時に届くチャレンジ、ループ、キャッシュ)が分かります。</description></item><item><title>バックグラウンドから戻ったWebSocketのOPENは、確かめるまで主張にすぎない</title><link>https://blog.yusukeikoma.com/ja/posts/mobile-os-background-sockets/</link><pubDate>Sat, 12 Sep 2026 14:18:24 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/mobile-os-background-sockets/</guid><description>AppleとAndroidの公式ドキュメントには、バックグラウンドのアプリは一時停止され、ネットワークが止められ、既存の接続が閉じられうると書かれています。つまり、フォアグラウンドに戻ったときの readyState === OPEN は、最後に処理したイベントの記憶にすぎません。この記事では、その記述から「確認する、作り直す、取りこぼしを取り戻す」という小さなルーチンを導き、Linux上の凍結プロセスという代役で動かします。実機では試していない点も、はっきり書きます。</description></item></channel></rss>