Gyuyoung Kim

Chromium/Blink Engineer at Igalia
Blink on Apple tvOS • Chrome iOS • Web Platform

  - E-mail: gyuyoung.kim at chromium.org  or gyuyoung at igalia.com
  - Blog: http://blogs.igalia.com/gyuyoung
  - LinkedIn: https://www.linkedin.com/in/gyuyoung-kim-11bb856/

Projects

Blink for Apple tvOS (2025 – Present)

Project Description

Apple TV runs tvOS, which is derived from iOS but does not provide a WebKit WebView for third-party apps. Any app needing web functionality must therefore embed its own engine. This project explores whether Blink — already being ported to iOS — can also run on tvOS, with the longer-term goal of upstreaming that support into Chromium. The platform makes this hard: tvOS lacks the low-level APIs (fork(), mach_msg(), posix_spawn_*()) that Chromium's multi-process model relies on, has no BrowserEngineKit, disallows JIT, and uses a remote-based, focus-driven input model rather than touch. The goal is therefore not a full browser, but practical, maintainable Blink-based web capabilities within those constraints. I presented updates and a live demo on real Apple TV hardware at BlinkOn 20 (2025) and BlinkOn 21 (2026).

My Contribution

I worked on bringing up and upstreaming the initial tvOS port. On the build side, I introduced tvOS-specific configuration — a new toolchain, the IS_IOS_TVOS flag in C++/Objective-C, and a target_platform = "tvos" GN setting. On the runtime side, I enabled single-process mode to work around the missing multi-process APIs, removed or disabled BrowserEngineKit-dependent code paths, disabled JIT in V8, and adjusted third-party libraries such as ANGLE, V8, and Dawn for tvOS. I helped get content_shell running first on the tvOS simulator and then on real Apple TV devices, added Crashpad support, and improved input handling for the Apple TV Remote's focus-based navigation. On the web platform side, I enabled WebAssembly in interpreted mode and VP9 software decoding, and verified hardware-accelerated H.264/H.265 decoding to support real media playback. I also set up reference bots for tvOS builds and tests to keep the port maintainable as upstream Chromium evolves.

Chrome iOS on Blink (2024 – Present)

Project Description

In early 2024, Apple began allowing third-party browser engines such as Blink and Gecko on iOS and iPadOS. The Chromium community has been developing an experimental Blink-based Chrome iOS, reusing the existing iOS Chrome UI and implementing the //ios/web public APIs with Blink (rather than WebKit) under a new //ios/web/content directory. Igalia has contributed to this effort since it became public.

My Contribution

I worked mainly on UI components and their integration with the Chrome iOS UI — file and color choosers, context menus, and select-list popups. I also contributed multimedia features, including video screen capture, hardware encode/decode, and audio recording, and graphics work around compositing and rendering, such as Metal support on ANGLE and fixes in the graphics layers. On the testing side, I worked on the unit, browser, and web test frameworks, filtered out unsupported and failing tests, and built the infrastructure to run web tests on the iOS simulator — reaching about 72% web test coverage with a ~92% pass rate among working tests early in 2024. I have maintained the ios-blink CI bot to keep builds and tests green, and helped enable remote debugging with DevTools on Blink for iOS.

Web Platform Tests in Chromium (2023 – 2024)

Project Description

The web-platform-tests (WPT) project is a cross-browser test suite for the web platform. Shared tests give browser projects confidence that their implementations match each other, which in turn lets web developers rely on consistent behavior across browsers. Chromium runs these as part of its web tests (under web_tests/external/wpt, around 50,000 tests), loading pages in content_shell and comparing rendered or JavaScript output against expected results. Every patch must pass these tests before merging.

My Contribution

I worked on WPT-related tasks within Chromium, including how the project incorporates these tests into its development workflow and how run_web_tests.py and content_shell interact to execute them. This work fed directly into enabling and maintaining web tests for the Blink iOS port.

WebGPU Conformance Test Suite (2022 – 2023)

Project Description

WebGPU is the successor to WebGL, exposing modern GPU capabilities (Direct3D 12, Metal, Vulkan) for both rendering and general computation on the web. The WebGPU Conformance Test Suite (CTS) verifies behavior defined by the specification; it is written in TypeScript, developed on GitHub, and runs under infrastructures such as WPT and Telemetry. The CTS is organized into four categories — API, Shader, IDL, and Web Platform — and uses parameter helpers to generate large Cartesian products of test cases.

My Contribution

I contributed CTS tests as part of Igalia's involvement, which began in June 2022. My tests covered the validity of texture formats and copy functionality, as well as the behavior of index formats and depth/stencil state.

Multiple Page Architecture (MPArch) (2021 – 2022)

Project Description

MPArch is a significant Chromium architecture change that lets a single WebContents host multiple pages (active/inactive, visible/invisible) in the same tab. Previously, features such as BFCache, Portals, Prerendering, FencedFrames, and Guest Views each solved the "multiple pages per tab" problem in their own way, which greatly increased complexity across the codebase. MPArch unifies these onto a shared model, cleanly separating the tab, page, and main-document concepts and benefiting from Site Isolation's similar split.

My Contribution

Igalia joined the MPArch effort on the prerendering work in April 2021, and I contributed to prerendering — including prerendering content restrictions — as well as the long tail of fixes for MPArch-related features. From September 2021, I worked on FencedFrames, another MPArch target. The Igalia team merged over 550 patches for MPArch from April 2021 onward.

Legacy IPC to Mojo Migration (2020 – 2021)

Project Description

Chromium's multi-process architecture relies heavily on inter-process communication. Historically this used a legacy named-pipe IPC that the project considered a poor fit for its security, stability, and modularity goals. Mojo is the replacement: roughly 3× faster than the legacy IPC with about one-third the context switching, and it removes unnecessary layers while letting interface clients and implementations connect across arbitrary process boundaries. Migrating off the legacy IPC was a prerequisite for high-impact projects like BackForwardCache, multiple Blink isolates, and RenderDocument — with roughly 450 legacy IPCs to convert as of January 2020.

My Contribution

Igalia worked on this migration in earnest from 2020, and I focused first on the //content layer, where the conversion was effectively complete (293 of the messages migrated) by the end of March 2021, leaving only a few Java Bridge messages. I then worked on other modules — Android WebView, Media, and Printing were all completed, and I moved on to Extensions. I shared this progress in a lightning talk at BlinkOn 14 (video, slides).

Whale Browser in Naver Labs (Dec. 2016)

Project Description

The Whale Project set out to build Naver's own web browser (whale.naver.com). As Korea's largest internet company, Naver was unusual in not having its own browser, unlike Google or Apple. Naver began developing one based on WebKit in 2011, and this was what brought me from Samsung to Naver. In June 2016, however, the project moved from WebKit to Chromium. The reason was Korea's unique web environment: many Korean banking and government sites worked only with IE (via ActiveX) or with Chrome through extensions, and there was strong user demand for Chrome-style extensions. After the switch to Chromium, the team focused mainly on UI and integration with Naver's services, since Chromium's core was already stable. The goal was to improve everyday convenience and user experience, and Whale shipped features such as split view, sidebar, smart popup, quick search, translation, mouse gestures, an embedded IE view, an embedded music player, and widgets. Whale is now in high demand and is in closed beta in Korea.

My Contribution

On Whale, I worked on security, geolocation, and the Whale UI. I was closely involved in the IETab UI. Because IE mode matters so much in Korea's web ecosystem — especially for banking and government sites — the team built IE compatibility on top of the Chrome extension framework. This combined an executable for accessing COM objects, JavaScript, and native UI; my focus was on the Chromium native UI and the JavaScript that interfaced with the executable. I also built a number of native UI elements, including Omnibox bubbles and dialogs that followed Whale's UX guidelines (using the Chromium views framework), a global mute button, and the Whale updater.

Demo videos related to my implementation

  - https://drive.google.com/file/d/0B_oE69uAXsk9b0lCZmRmcmwtZms/view
  - https://drive.google.com/file/d/0B_oE69uAXsk9ejBRdjlRSVA5b00/view
  - https://drive.google.com/file/d/0B_oE69uAXsk9bVdBdk40Qk1rUm8/view

Samsung SUHD TV based on Tizen (Mar. 2015)

Project Description

This Tizen TV prototype was shown at the Tizen Developer Conference 2014 in San Francisco. Tizen is a genuine open-source Linux OS, valued for its stability and speed, and the prototype supported sideloading of standard Tizen .tpk and widget apps. As a prototype, its final feature set had not yet been decided. (Video)

My Contribution

I was responsible for page zoom, smooth scrolling, and viewport handling in the browser. The TV browser team (about 10 people) worked on multimedia, smooth scrolling, and overall user experience. Our aim was a TV browser that felt as smooth as a mobile browser, so we focused on smooth scrolling, the tiled backing store, and synchronized graphics. WebKit EFL had a number of defects along the way, so I fixed these in both the prototype and upstream — improving the Tizen TV browsing experience while also contributing back to WebKit EFL.

NX300 Mirrorless Camera (Feb. 2013)

Project Description

Tizen is an open-source, standards-based software platform backed by major mobile operators, device makers, and silicon vendors across many device categories — smartphones, tablets, netbooks, in-vehicle infotainment, smart TVs, and more. It offers an OS, applications, and a user experience designed to let people move easily between devices. The project runs under the Linux Foundation, governed by a Technical Steering Group that drives platform development and sets up working groups for specific device verticals; the Tizen Association coordinates the industry side, from requirements and service models to marketing and education. Tizen relies heavily on HTML5, and its SDK and APIs let developers build cross-device applications with HTML5 and related web technologies.

My Contribution

Tizen is built on SLP (Samsung Linux Platform). SLP began as a Samsung-internal proprietary project, whereas Tizen is open source — and my work moved naturally from SLP to Tizen. I worked on the WebKit-Tizen port, which builds on the WebKit EFL port but adds Tizen-specific features such as geolocation, multimedia, and network information. My work covered both bug fixing and engine enhancements. Through this, I learned how to collaborate within the WebKit community, which led to productive interactions between Samsung's WebKit engineers and existing contributors. My open-source work — including contributing the Network Information API in HTML5 — led to my becoming a WebKit reviewer in October 2012.

Samsung Linux Platform v1.0 / v2.0 (Nov. 2008 ~ Jul. 2011)

Project Description

Samsung Linux Platform (SLP) is a mobile OS built on the Linux 2.6 kernel and the X.org server. It evolved from XO v1.0, moving from the XO windowing system to the X Window System and adopting the Enlightenment Foundation Libraries (EFL) for applications. SLP spanned phones, TVs, cameras, MP3 players, tablets, and laptops; it was compatible with LiMo, and the SLP team became a prominent contributor to the LiMo Foundation. Architecturally, SLP adapted a standard Linux desktop for mobile, using many open-source components in a layered stack of applications, middleware, and the Linux kernel.

 My Contribution

I worked on the WebKit EFL port. Samsung and Profusion, a Brazilian software company, jointly started the initial WebKit EFL port (wiki); Profusion's engineers laid the groundwork, and I refined and extended it. My work spanned build fixes, crash fixes, and missing features — download support, context menus, video and audio, the viewport meta tag, and geolocation. One key contribution was setting up and maintaining the Buildbot and EWS (Early Warning System) for the EFL port, which played a major role in stabilizing it and made development and testing more efficient.

Keeping a project in sync with WebKit's fast-moving development is a well-known challenge, and frequent rebasing often caused merge conflicts. To manage this, I encouraged my colleagues to upstream their local patches, which helped with conflict resolution, and many Samsung WebKit developers contributed actively as a result. Through this work, I became a WebKit committer — an important milestone in my career.

XO v1.0 - LiMo Compatible Linux Platform (Sep. 2007 ~ Oct. 2008)

Project Description

XO is a Linux-based mobile platform known for strong high-level features, good performance, and reliability. It supported a range of Board Support Packages (BSPs), windowing systems, and mobile browsers, and was compatible with LiMo Release 1. For its windowing system, XO used DirectFB — a lightweight library providing hardware graphics acceleration, input device handling, and abstraction. As an integrated windowing system, DirectFB supported features like translucent windows and multiple display layers beyond the Linux framebuffer device.

My Contribution

I was responsible for the internet framework. On XO, internet functionality was built on the Mozilla platform, and my area was the JavaScript engine, SpiderMonkey. My main focus was memory consumption and performance in a mobile environment. I added a preference that set a memory-usage threshold: when consumption crossed it, SpiderMonkey would run the garbage collector until enough memory was reclaimed. I contributed this patch upstream to Mozilla, and it was adopted in mobile Firefox as well — showing that the work mattered beyond XO.

SCH-W290 - 3G UMTS/WCDMA HSDPA Phone (Jul. 2007 ~ Aug. 2007)

Project Description

The SCH-W290 was a phone built for SK Telecom, Korea's largest carrier, for their 3G network, supporting both UMTS and WCDMA. It had a slider form factor and features including HSDPA, MP3 playback, expandable memory, and a built-in printer function. It carried two cameras: a front VGA camera (video recording, playback, streaming, video calls) and a rear 1.3-megapixel CMOS camera (recording, playback, streaming, flash, digital zoom). It also supported multitasking, music/video on demand, an MP3 and video player, STK functions, downloadable content, an English dictionary, a file viewer, a photo album and editor, and 3D messaging.

My Contribution

I was responsible for PIMS (Personal Information Management System) — the scheduler, calendar, and alarms. Unusually, this phone ran on the BREW platform rather than the more common J2ME, and the BREW platform was outsourced to a third party. Much of my work was fixing bugs in the PIMS module. Although the base source code was shared across several commercial products, bugs persisted because there was no cohesive, standardized architecture — a common situation under tight product deadlines. The project was intense; I recall working without a real break for about two months. The urgency came from Samsung's push to regain leadership against LG in Korea's 3G phone market — which it did, which made the effort worthwhile.

SGH-P930 - 3G DVB-H Phone (May. 2007 ~ Jun. 2007)

Project Description

The SGH-P930 was a global roaming phone built for DVB-H mobile television. It featured HSDPA data, DVB-H mobile TV, a 2-megapixel camera, Bluetooth, a swiveling 262K-color TFT display, and a microSD slot. Its DVB-H support enabled a Picture-in-Picture function for watching two channels at once, and connectivity included 3G, EDGE, GPRS, HSDPA, Bluetooth, and USB. It targeted Asian and European markets such as Vietnam and Italy, with roaming support in the US. At the time, Samsung led across three mobile-TV standards — DVB-H in Europe, MediaFLO in the US, and DMB in Korea — with milestones including the first S-DMB and T-DMB phones in Korea, Europe's first T-DMB phone in Germany, Europe's first DVB-H phone in Italy, and a MediaFLO demo at CTIA Wireless 2006. (Video)

My Contribution

I was responsible for the mobile Java platform (J2ME) and the mobile browser. As a major Samsung product, it ran on a tight deadline and a demanding schedule — the team often worked well past regular hours. I also traveled to Vietnam and Singapore for a month to support local testing and debugging, where I tested issues across phone calls, the mobile browser, and content downloads. One memorable bug: the operator's main WML page wouldn't render on this phone's browser. After investigation, the cause turned out to be a malformed comment in the WML page's code — a good reminder of how a small detail can have an outsized impact.

JRobo Online Project (Mar. 2003 ~ Jun. 2003)