デリッシュキッチンのLiquid Glass対応への取り組み - every Tech Blog
はじめに 株式会社エブリーでデリッシュキッチンのiOSアプリの開発をしている成田です。 iOS 26から、Appleの新しいデザイン言語である「Liquid Glass」が導入されました。 2026年4月の現時点では設定のフラグによって適用を回避できますが、次のXcodeのメジャーアップデートではこのフラグの廃止が見込まれています。 また、2027年春頃には新しいメジャーバージョンのXcodeでのビルドが必須になると考えられ、対応は避けられない状況です。 こうした背景から、すでにLiquid Glassへの対応を進めているiOSアプリ開発者の方も多いのではないでしょうか。 デリッシュキッチンでも現在ユーザーへのリリースを目指して対応を進めています。 本記事では、以下のような流れでデリッシュキッチンにおけるLiquid Glass対応への取り組みについて紹介したいと思います。Liquid G
マイナポータル バックエンドシステム更改の舞台裏：500名・18か月、対策前進の記録｜デジタル庁
デジタル庁プロダクトマネージャーユニットの平野 賢です。2023年8月よりマイナポータルのバックエンドシステム更改プロジェクトにプロジェクトマネージャー（PM）として携わってきました。 このプロジェクトは、2026年1月1日の本番移行作業の完遂をもって終了となりました。本記事では数年に一度の規模で実施された政府情報システムの更改（刷新）が、どのように進められたのかを紹介します。 マイナポータルとははじめに、マイナポータルについて説明します。 マイナポータルとは、個人向け行政サービスのオンライン窓口サービスです。国民の皆さまがマイナンバーカードを利用して、引越しやパスポートの申請、確定申告などの手続、医療費・薬剤情報・税情報といった本人情報の確認など、様々な行政サービスを利用できます。（詳細はこちら）。 マイナポータルのホーム画面バックエンドシステム更改プロジェクトの概要プロジェクトの背景マ
Liquid Glass 対応 — タップルでの意思決定と実装 | CyberAgent Developers Blog
この記事で学べること ✅ デザイン・方針がわかる ✅ 実装の参考になる ✅ バグ対応の参考になる 対応に困っていたり、なかなか温度感が上がらなかったりする方がいたら、ぜひこの記事を参考にしてください。 目次 なぜやるのか デザインの変遷 対応期限 早めに対応を進めるべき理由 対応フロー 対応事例 なぜやるのか Liquid Glassは、半透明のガラスのような質感と、光の反射・屈折を伴う動的なアニメーションが特徴です。 10年に1度のデザイン変更となっており、標準のデザインとして認知が進んでいます。 対応アプリも着々と増えており、Apple公式からもデザインギャラリーが公開されました。 私たちもその大きな流れに乗っていきます。 引用：Apple Document デザインの変遷 実際に、これまでのデザインの変遷を見てみましょう。 2007〜2013年：スキューモフィズムデザイン iPhon
Cognition | How Devin Is Modernizing COBOL at Fortune 500 Companies
The pressure to modernize COBOL has never been greater. Forty-seven percent of organizations cannot fill their COBOL roles and 92% of COBOL developers plan on retiring by 2030. As a result, over the past eight months, several Fortune 500 companies have staffed Devin on COBOL project — documenting millions of lines of code, migrating a customs workflow from COBOL to AWS Lambda, and refactoring tax
グローバル展開にむけたアプリと基盤の再構築 | メルカリエンジニアリング
Cross Border (XB) Engineeringの @deeeeeeeeeet です． 先日の事業戦略発表会において共有しましたが，今後更にメルカリの海外展開を加速させるためにグローバル版のメルカリアプリを先日リリースしました． このアプリは現在提供してる日本版・アメリカ版のメルカリとは異なる新しいアプリであり，またアプリだけではなくその裏側のバックエンド基盤も新たに再構築しています．本記事では，エンジニアリングの観点からメルカリ グローバルアプリ（以下、グローバルアプリ）とその基盤の戦略やアーキテクチャーをこれまでのメルカリの挑戦から得られた学びを振り返りつつ紹介します． メルカリにおける越境取引 「メルカリ」に出品したことがあるみなさんの中には，自分の商品が一般のお客さまではなく事業者によって「代理購入」された経験がある方もいらっしゃるかもしれません．これは，海外のお客さまが
メルカリの Confluence → Notion 移行プロジェクト(2025年〜2026年3月の軌跡) | メルカリエンジニアリング
目次 はじめに プロジェクトの発足 直面した「2つの壁」 完璧なインポートは幻想（技術の壁） 金融事業ゆえの厳しい制約（コンプライアンスの壁） 現状と今後 もし過去に戻れるとしたら？ Confluence導入時まで戻れたら… Confluence→Notion移行プロジェクト開始時に戻れたら… おわりに はじめに こんにちは。Engineering Officeのkikoです。 今、私はCentral Knowledge Management Committeeのメンバーとして、社内のドキュメント基盤をConfluenceからNotionへ移行するプロジェクトを推進しています。 当プロジェクトはまだ完遂していませんが、3月末に一つの節目を迎えたので、同Committeeメンバーのt-yamaさんと共に、これまでの振り返りをまとめました。 これから社内ドキュメントツールを導入しようとしている
iOS 27 / Xcode 27 の破壊的変更に備えて今から準備すべきこと | DevelopersIO
現在、iOS 26対応を進めているが、すでにiOS 27（2026年9月リリース予測）で予告されている破壊的変更が気になっている。特にLiquid Glassデザインの完全義務化とUISceneライフサイクルの強制適用は、対応を怠るとアプリが起動すらできなくなるリスクがある。 iOS 26の時点でAppleはこれらの変更を公式に予告しており、猶予期間が設けられている状態だ。しかし、いざiOS 27がリリースされてから慌てて対応するのでは遅いだろう。早めに全体像を把握して、計画的に移行を進めるべきだと考えている。 本記事では、iOS 26で非推奨となったAPIやAppleの公式発言から推測されるiOS 27の破壊的変更について、今から準備すべきことをまとめる。なお、iOS 27は未リリースのため、推測を含む内容が多い点に留意してほしい。 予測されるスケジュールの詳細は後述するが、2027年4
AIを活用した大規模iOSアプリのSwift Concurrency移行戦略 - Sansan Tech Blog
はじめに こんにちは！技術本部 Sansan Engineering Unit Mobile Application Groupに所属するiOSエンジニアの劉 志輝です。 今回は、ビジネスデータベース「Sansan」のiOSアプリで進めている、Swift6時代に向けたSwift Concurrencyへの移行戦略についてお話しします。 このアプリは10年以上にわたって継続開発されており、UIKit + VIPERアーキテクチャで構成されています。 非同期処理にはRxSwift（Single、Observable、BehaviorRelay）とGCD（DispatchSemaphore、DispatchQueue）が広範に使われており、複数のモジュールにまたがる大規模なコードベースです。 そのため、単純な書き換えではなく、既存設計との整合性を保ちながら段階的に移行する必要があります。この移行
LINE iOSアプリにWebKitの新API「WebPage」を導入できず、自前で実装した件
はじめに こんにちは、iOSアプリエンジニアのKiichiです。LINE iOSアプリでアプリ内ブラウザなど、Webまわりの開発を担当しています。普段はUIKitをベースに機能改善や新機能開発を進めつつ、SwiftUI・Observation Framework・Swift Concurrencyなどのモダンな技術を用いて巨大な既存コードベースを改善することに努めています。 本記事では、WebKitの新API「WebPage」を検討した結果、なぜそのまま導入できなかったのか、そしてその思想をどのように自前実装へ落とし込んだのかについて紹介します。 WebKitと責務分離の懸念 LINE iOSのアプリ内ブラウザでは、これまで WKWebView を直接利用してきました。しかし、 load(_:) や goBack() などのインフラ的な責務UIView として画面に表示されるUIとしての責
Flutterでディープリンクをリプレースした話
背景 現在Flutterアプリ開発に携わってまして、ディープリンクを自分が実装した時にチーム内でディープリンクってなんだろう、ディープリンクって難しいものなの？という声や雰囲気があったので、なんか久々に記事書こうかなと思った次第です。（というか自分の中の棚卸しに近い） メインは既存のディープリンクを新しいサービスを使ったディープリンクにリプレースした最近の話を。その時に考えたポイントや困ったことを書きます。困ったことはGoRouterの設計の話になります。（GoRouterは記事分けるかも） この辺の知識多少はあるけど、技術深めるタイプではないので、豚骨ラーメンではなくちょっとパンチのある中華そばくらいの濃さの内容となります。 ターゲット Custom URL SchemeからAppsFlyer(OneLink)にリプレースする人 別サービスへのリプレースでも横展開できる考え方あります。
【Flutter】Riverpod 3 への移行ガイド
はじめに ２０２５年９月１０日にRiverpod3.0が正式にリリースされました。 今回のアップデートで便利になった反面、2.x と同じ感覚でコードを書くと、 思わぬ落とし穴にハマるケースもありました。 2.x系を使っていた自分が3.x系に移行するにあたっての注意事項を記事にまとめました。 これからRiverpodの3.x系へバージョンアップを行う方の参考になれば幸いです。 記事の対象者 Riverpod 2.x系から3.x系へ移行を行う Flutter/Dart 開発者 AsyncValue / Notifier / Providerライフサイクル変更点を押さえたい人 Stream/非同期Providerの新仕様と落とし穴を避けたい人 テストで retry/override 周りの新挙動に対応したい人 記事を執筆時点での筆者の環境 [✓] Flutter (Channel stable,
Riverpod3に移行する中で遭遇したこと、取り組んだこと
はじめに 私の担当するプロジェクトでは、build_runnerを用いたコード生成を活用するパッケージをいくつも使っています。riverpod_generatorもその一つです。ところが、riverpod_generatorが3.x未満だとbuildパッケージが2.xのままで、他のコード生成パッケージのアップデートがいつまで経ってもできない状態でした。この依存関係の問題を解決するため、大変そうだとは思いつつもRiverpod 3.0への移行を決断しました。 実際、移行作業は想像以上に大変でした。だからこそ、同じ課題に直面している方の助けになればと思い、この記事にまとめることにしました。 この記事では、Riverpod 3.0への移行で遭遇した問題とその対処方法をまとめています。移行のすべてを解説するガイドではなく、特に対応に悩んだポイントや公式ドキュメントに記載されていない点を中心に扱いま
Flutter3.38アップグレードにおけるiOSとAndroidの影響範囲 - every Tech Blog
Flutter3.38アップグレードにおけるiOSとAndroidの影響範囲 背景 Flutter3.38アップグレードの手順 パッケージのバージョン依存関係調整 依存関係の解消によって副次的問題が発生 1. Dart SDK バージョン 2. Ferryエコシステム（GraphQLクライアント） 3. Freezed（コード生成） 4. Firebase（iOS 13対応のため2.x系を使用） 5. その他の重要な更新 6. Isar Plus（データベース）モデル修正 解決した依存関係の競合 競合1: isar_db_generator 競合2: intl バージョン 競合3: source_gen バージョン 競合4: build バージョン 競合5: gql_exec バージョン 競合6: ferry バージョン 競合7: web パッケージ（iOS 13対応のための調整） 競合8
Riverpod v3とrefと非同期処理に向き合う
はじめに Riverpod v3のリリースから3〜4ヶ月経ち、またanalyzerのアップデート対応のためにバージョンアップを検討している方も多いのではないでしょうか？ [1] v3はv2に比べると、特に参照が切れたProviderの検知が強化されました。結果として、不要なProviderが破棄されやすくなっています。このためbuildメソッド内でref.watchを利用している箇所には影響がないものの、ButtonのonPressed内でref.readを利用している箇所に影響が出ることがあります。 この記事では、特にref.readで非同期処理を参照する時の実装について現在考えていることをまとめます。また、最近考えている「StatelessなSingletonはkeepAliveしてもよいのでは？」という点についても触れたいと思います。 なお、すべて筆者が調べたり考えたりした内容です。
3000 ドルかけて Devin と React 18 移行して得た学び
2025 年 11 月から約 2 ヶ月間で、運用中の Web サービスを React 16.8 から React 18 に移行した。 その間、自分では 1 行もコードを書かず、Devin(一部 Codex)に全てのコードを書かせた。移行にあたってデグレが 2 回発生したが、大きなサービス障害はなく、無事に移行を完了できた。 移行にかかった Devin の費用は、約 3000 ドルだった。この中には React 18 移行とは直接関係のない変更や、今後のメンテナンス性を大いに向上させる変更も含んでいるが、それでも「結構かかったな」という印象である。 そこで得られたいくつかの学び(失敗談)をまとめた。React 18 移行だけでなく、「ゴールが明確に定まっている非常に大きなタスク」に有効な学びだと思う。ただし、 あくまで 2025 年末頃の AI エージェントの能力と知識に基づくものであり、い
Android Gradle Plugin 9.0 更新対応 - Qiita
Android Gradle Plugin(AGP) 9.0 がリリースされ、大きめの変更が入っているので対応した時のメモになります。 掻い摘んだ内容になるので公式のリリースノートも参照ください。 KMP のプロジェクトの場合はここでは解説しませんが以下の記事を併せて参照することをお勧めします。 対応の流れ AGP 9.0 更新は以下の流れで対応することになると思います。 Gradle 9.1 以上に更新する AGP 9.0 に更新する AGP 9.0 で追加されたオプションを無効にする オプションを一つづつ有効にしていき、エラーが出れば修正していく Android Studio の AGP Upgrade Assistant を使用することで 3 まで対応してくれるので、事前に使用してビルドが通るところまで確認できるとひとまず AGP の更新自体はできたことになります。 オプションを一つ
GitHub Enterprise移行プロジェクトの全記録 ーー 1000リポジトリの移行と、これから作る運用組織 - Sansan Tech Blog
1. はじめに 技術本部 コーポレートシステム部 Corporate Architectureグループの吉山です。 最初に所属先のコーポレートシステム部門について簡単に紹介させてください。コーポレートシステム部は、情報システム部門（いわゆる情シス）にあたります。部のミッションとして「EXをシンプルにする」ということを掲げています。EXとはEmployee Experience（従業員体験）のことです。 今回は、当社で実施したGitHub TeamからGitHub Enterprise Cloud（EMU）への移行プロジェクトについてブログにまとめます。 2024年12月から始まった移行プロジェクトは、約9ヶ月を経て2025年夏に概ね完了しました。元々1000リポジトリ程度が存在していたOrganizationから、700リポジトリほどを新しいEnterprise環境へ移行しています。この移
実録！GitHub Enterprise Cloud 導入 〜コスト増を乗り越えたわけ〜 - Leverages Tech Blog
はじめに こんにちは！レバレジーズ株式会社テクノロジー戦略室SREチームの竹村です。 テクノロジー戦略室のSREチームでは、全社のエンジニアの開発生産性の向上やシステムの信頼性向上に取り組んでいます。 エンジニアの生産性向上や工数削減を叶えるため、2024年にレバレジーズの開発組織全体で、GitHub Enterprise Cloud（GHEC） への移行を行いました。 今回は、複数の施策を積み上げることで、コスト増を上回るメリットを示し、導入に至った経緯を赤裸々に皆さんにお届けできればと思います！GHEC以外のサービス導入検討の参考にもなると思うので、何か新しいサービスやプランアップを検討されているかたもご一読いただけると幸いです。 苦労したポイント！ GHEC への移行・導入にあたっての一番苦労したポイントはやはり、大幅なコスト増をまわりに理解してもらうことでした。多くの高度な機能が利
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://blog.flutter.dev/we-rebuilt-flutters-websites-with-dart-and-jaspr-317c00e8b400
Sansanでの認証基盤内製化と移行