DEV Community: Masahiko Sakakibara

I Didn’t Want “Built with Web Tech” to Mean Compromise [Capacitor/Cordova]

Masahiko Sakakibara — Tue, 03 Nov 2026 07:32:24 +0000

HTML, CSS, JavaScript. The same technologies you use for websites and web apps can also power iOS and Android apps. Capacitor and Cordova let you run those web interfaces inside a mobile app, with plugins providing access to features such as push notifications and Face ID.

The component that displays the web interface inside the app is called a WebView. Apps built this way are often called WebView or hybrid apps. They aren't just small experiments: in Japan, examples include AEON's iAEON shopping app and the Sumitomo Mitsui Banking Corporation app.

There are challenges, though. Recreating native UI with web technologies has limits. Liquid Glass, introduced in iOS 26, is a good example: the glass changes shape under your finger and refracts the content behind it.

Then there are ads. Google AdMob is a common choice for mobile apps, but making a native ad scroll between posts in a web feed is a different problem from placing a banner on the screen. The web content and the native UI live in separate rendering layers.

For almost ten years, I thought of these as limitations of WebView apps. But after questioning the requirements and experimenting, I finally found a way to make native UI and web content coexist without disrupting the experience!

Native UI alongside web content

Close this web-based sheet, and the iOS tab bar appears underneath. You can then interact with it, including a long press. The tab bar is native UI rendered by UIKit.

Web content and native UI, behaving naturally on the same screen. I honestly used to think this wasn't possible!

An iOS tab bar that controls the web app

Compare a long press on a web recreation with the native tab bar. The curvature of the glass and the distortion of the photo behind it are different.

I built @rdlabo/capacitor-native-ui to use this native UI alongside web content. It reads supported Ionic components and renders their native counterparts with UIKit and SwiftUI.

Labels and selection state can still be managed on the web side. Ionic isn't required, either: in a plain HTML app, you can explicitly mark buttons and back buttons for native rendering.

I've also released a Cordova plugin. It shares the native rendering implementation, so Cordova apps can use it too.

Native ads that scroll with the posts

Navigation wasn't the only place I wanted native UI. I wanted ads between posts, scrolling with the feed, as they do on X. The posts and photos are web content; the ads between them are rendered by the Google Mobile Ads SDK.

Both platforms are showing test ads.

After tuning the behavior separately on iOS and Android, I made this available through @capacitor-community/admob.

When you can't interact with it, could an image do?

The hardest part of both features was the boundary between the web and native rendering layers.

CSS z-index only controls stacking inside the WebView. A web sheet cannot cover a native view placed above the WebView itself. Scrolling has the same problem: moving the web content doesn't automatically move the native view with it.

They are separate rendering systems. Of course they behave differently. But to the person using the app, it's all one screen.

So I reconsidered the requirement: when does the UI actually need to remain a live native view?

The native UI itself doesn't need to enter the DOM. Only its appearance does. That realization was a thrill. I call the approach “Projection.”

But taking a snapshot isn't the whole solution. Hide the native view first, and you get a blank frame before its image appears. Show the image first, and the translucent glass appears twice, layered over itself.

Neither works.

So I prepare the snapshot and get it ready for display on the web side before switching. When hiding the native view, I temporarily display the same image on the native side to bridge the handoff. Once the web side displays its copy, I remove the temporary native-side image in step with rendering. The appearance stays the same; only the place rendering it changes.

Tuning that handoff frame by frame produced the behavior in the opening demo. Just watching it, you can't tell when the tab bar becomes an image.

It feels like magic!

There are limits: a snapshot cannot preserve interaction or video playback. Scrolling also calls for different strategies. In supported iOS scroll regions, the live native view follows the content. For Android ads that can be captured, an image is projected while scrolling.

I extracted the shared coordination into WebView Native UI Engine, so other plugin authors can use it. My Projection article goes deeper into preparing the snapshot and timing the handoff.

Adapting the app to iPhone Duo

Using native UI also gave me a way to support iPhone Duo!

On Duo's outer display and its inner display in landscape, back buttons and tab bars move to the sides. This arrangement is called Vertical Bars. Moving navigation to the sides gives the same Ionic app more vertical room for its content.

This recording enables the vertical layout using a switch inside the demo app.

Moving the bars is only part of the work. The web content needs to leave room for them, too. The background can fill the screen, while cards and lists stay clear of the bars. Safe areas become a question of how the content and controls fit together, not just how much padding to put at the top and bottom.

Vertical Bars follow iOS conventions for width, button order, grouping, and animation. Other apps follow those same conventions, which makes small differences in a web recreation easier to notice. Matching the transitions and the changing shape of the glass is particularly tricky. This is where I want to use native UI.

A plain HTML app can use it too. In this example, pressing the native back button on the right runs the existing web-side handler and returns to the list.

Outside Ionic, this integration supports explicitly marked buttons and back buttons. It does not automatically convert arbitrary HTML tab bars.

Device layout information comes from Erkam Yaman's Capacitor Foldable. I use that information to align the web layout with the native controls. Thank you, Erkam!

You still need to initialize the plugins and connect the layout updates. But you don't need a separate app UI just for Duo. The documentation has guides for Ionic Vertical Bars and framework-independent integration.

More room for what we can build with the web

All the plugins and libraries described here are open source under the MIT license:

Building with web technologies doesn't have to mean giving up the native capabilities your app needs. You can build the content and behavior with the web, then bring in native UI where it makes sense. That's the choice I wanted to make possible.

After almost ten years of treating this as a constraint, I finally got past it. This was software development, but it felt like inventing something. I'm proud of this one!

If this made you think, “Wait, a web-based app can do that?”, I'm happy. If it gives you something you've wanted for your own app, even better.

What native UI have you wanted to use alongside your web content?

Adapted from my Japanese article on note, with the comics translated into English.

Building Ionic/Capacitor Apps for the iPhone Duo Era

Masahiko Sakakibara — Mon, 02 Nov 2026 14:32:07 +0000

iPhone Duo introduces Vertical Bars, moving back buttons and tab bars to the side of the screen.

That changes the layout and the experience more than I expected. How much? App Store screenshot specifications now include iPhone Duo alongside the existing iPhone and iPad requirements. It seems Apple sees this as a distinct experience, too.

As app developers, we need to account for it. So I built a way to adapt an existing Ionic app to Duo. Take a look:

The switch in this demo enables the vertical layout.

It's the same Ionic app, with its tab bar and back button moved to the side. These aren't HTML and CSS recreations. They're real native UI rendered by UIKit and SwiftUI.

The web screens and application logic stay in place. Native UI handles the navigation controls.

In my previous article (in Japanese), I explored how Duo behaves. This time, I'll show how to bring that behavior to an existing app. This also works with Capacitor apps that don't use Ionic.

How Duo changes navigation and safe areas

Back buttons and tab bars move to the side

On Duo's outer display, and on its inner display in landscape, back buttons and tab bars move into Vertical Bars at the side. Here's the same Ionic app before and after adapting to that layout.

Before	After

Same Duo, same screen. Only the vertical layout has been enabled.

On the right, the buttons and tab bar have moved to the side, and the content stays clear of the bars. Moving the controls also changes how the content beside them fits on screen.

What belongs inside the safe area changes, too

Safe areas need some attention here. This isn't just a matter of moving padding from the top and bottom to the left and right. Compare these two Apple explanations:

Left: Building Apps for iPhone X (9:43). Right: Prepare your app for iPhone Duo (6:55).

In the earlier iPhone example on the left, the yellow cell backgrounds extend beyond the safe area, while text and controls stay inside it. In the Duo example on the right, entire cards and lists sit inset from the bars, as shown by the blue region.

The background fills the screen; lists and cards stay inset. That's a change in how we apply safe areas between iPhone and iPhone Duo, and one to keep in mind when adapting an app.

Shared UI makes small differences stand out

Vertical Bars come with many iOS-defined constraints: width, button order, grouping, and animations. You can include custom views, but they need to adapt to the fixed width and vertical layout. Apple's walkthrough explains those rules.

Other apps follow the same rules. That makes small differences easier to notice when we recreate something similar on the web.

I've tried to reproduce iOS 26/27 UI with web technologies, down to the pixel. But did I really match the way Liquid Glass changes shape and animates? That's harder to say.

For UI shared across apps, like Vertical Bars, I wanted to hand that part over to real native controls.

Make just the Vertical Bars native

That's why I built @rdlabo/capacitor-native-ui. It connects native UI with a WebView so they can coexist. Here, we'll use it to rearrange existing navigation buttons and tab bars as native controls for Vertical Bars.

When you use the native tab bar, its actions are passed to the original web components, and your web screens switch as before. The back button works the same way. The appearance and interaction change, while the application logic behind them stays in place.

We can also use the device's layout information to keep the background full-screen and the content inset from the bars. Let's add this to an existing app.

Add it to an existing Ionic app

With the setup below, the plugin reads your existing ion-tab-bar and ion-back-button and renders their native counterparts. Those controls support Duo's Vertical Bars, so you don't need to substantially rebuild your navigation.

npm install @rdlabo/capacitor-native-ui @rdlabo/ionic-theme-ios27 @erkamyaman/capacitor-foldable

Add the vertical-layout CSS to your global Sass so web content stays inset from the bars. You can keep your existing theme.

@use '@rdlabo/ionic-theme-ios27/dist/css/vertical-bars.css';

If your page transitions aren't already integrated with native UI, wrap the existing transition animation with withNativeUITransition and assign it to navAnimation before initializing Ionic.

Initialize native UI once for the app. After ion-app is mounted, handle the device's layout information at the app root and start with verticalOnly. Here's that part of the setup:

import { Foldable, type BarPlacement } from '@erkamyaman/capacitor-foldable';
import { setVerticalBarsLayout } from '@rdlabo/ionic-theme-ios27';
import { enableNativeUI } from '@rdlabo/capacitor-native-ui';

const applyPlacement = ({ verticalBarEdge, inset }: BarPlacement) =>
  setVerticalBarsLayout({ edge: verticalBarEdge, inset });

const listener = await Foldable.addListener(
  'barPlacementChange', applyPlacement
);
applyPlacement(await Foldable.getBarPlacement());
const rail = await enableNativeUI({ controls: 'verticalOnly' });

verticalOnly limits native rendering to Vertical Bars. The placement handler reflects the device's bar placement and insets in the web layout, so existing screens adapt to both vertical and regular layouts.

When the component that owns this setup is destroyed, clean up with listener.remove() and rail.destroy(). If you're already initializing native UI, integrate this into that existing setup.

Build the web app, run npx cap sync ios, then build and run the iOS app on Duo. The integration guide includes transition examples and explains where the setup belongs in each framework.

Add it to an app without Ionic

If you don't use Ionic, the plugin can display native buttons in Vertical Bars based on your existing HTML buttons. Here, the native back button at the side returns to a web-based list:

A plain HTML app on Duo. The back button on the right returns to the web list.

Add these two packages to your existing Capacitor project:

npm install @rdlabo/capacitor-native-ui @erkamyaman/capacitor-foldable

Once the app's root element (#app here) is mounted, initialize once. This is the startup example from the documentation:

import { enableNativeUI } from '@rdlabo/capacitor-native-ui/core';

const shell = await enableNativeUI({
  root: document.querySelector<HTMLElement>('#app')!,
});

Combine this with the documented device-placement integration. Get the initial placement with Foldable.getBarPlacement(), listen for barPlacementChange, and reflect the placement and inset in your existing CSS.

When vertical placement is no longer active, restore the regular spacing and call shell.disableVerticalControlArea(). When it returns, call shell.enableVerticalControlArea(). Process spacing updates and these state changes in sequence.

When the root is destroyed, remove the placement listener and call await shell.destroy().

With initialization in place, add data-* attributes to the existing HTML buttons you want to display as native UI. This marks a back button for placement in Vertical Bars. Pressing it invokes the original click handler.

<button
  type="button"
  data-native-ui="back-button"
  data-native-ui-placement="rail"
>
  Back
</button>

Build the web app, run npx cap sync ios, and rebuild the iOS app. This integration supports buttons and back buttons; it doesn't automatically convert HTML tab bars. The guide and examples cover the setup in more detail.

Help your Capacitor app feel at home on Duo

When someone chooses Duo, we want them to keep using their familiar apps in a way that fits the device.

Keep the web screens and logic you've already built, and use real native UI for navigation. That's now an option for adapting to Duo, too.

The device-placement information comes from Erkam Yaman's Capacitor Foldable. Thank you, Erkam!

@rdlabo/capacitor-native-ui is open source under the MIT license. If you're planning Duo support, give it a try in your existing app!

See you next time.

Originally published in Japanese on Zenn.

I Wanted Real Native UI in My WebView. So I Built Projection. [Capacitor/Cordova]

Masahiko Sakakibara — Sun, 01 Nov 2026 02:47:07 +0000

When you build a WebView app with Capacitor or Cordova, you often recreate native UI on the web to make the app feel at home on the device.

I've spent more than a year working on this, releasing my work as an open-source Ionic Theme that recreates native UI with web technologies.

But did I really recreate Liquid Glass, introduced in iOS 26? That's harder to answer. I could get the appearance close, but the background refraction and the way it responds to touch were beyond what I could reproduce on the web.

Both show a long press. Look at the edges of the glass and the background showing through it.

Then why not use real native UI?

That brought me to a different problem: making it coexist with the WebView. Web content and native UI live in separate rendering layers. I couldn't make them feel like one natural interface.

Recently, I found a way. Take a look!

As I slowly close this web-based sheet modal, a native tab bar emerges from underneath it.

The web modal appears above the native tab bar. Close it, and the tab bar is interactive native UI again.

This tab bar isn't an HTML or CSS recreation. It's real native UI rendered by UIKit on iOS.

I call this approach Projection.

The boundary a WebView can't cross

A WebView and native UI don't share a stacking order or a scrolling system.

The WebView renders HTML and CSS. No matter how high you set a CSS z-index, a web modal cannot cover a native view placed above the WebView itself.

Scrolling has the same problem. When content inside the WebView scrolls, a native view doesn't automatically move with it. To place native ads between posts, as you see in an X feed, you need to synchronize their positions—and clip the parts that pass behind the header.

They're separate rendering systems. Of course they behave differently.

But to the person using the app, it's all one screen.

If native UI can't go into the DOM, project its appearance

The turning point was thinking about when native UI can't be interacted with.

When a modal is open, you can't use the tab bar it covers. The same goes for an alert: you can't tap the components behind it.

So, while that UI is unavailable for interaction, does it actually need to stay in the native layer?

Turn it into an image temporarily and place it within the WebView's stacking order. When it becomes interactive again, bring back the real native UI.

The same idea works for scrolling. Switch to an image when scrolling starts, then back to the real view when it stops. Web content and native UI can coexist without compromising the user experience at all.

That realization was pretty exciting.

The native UI itself doesn't need to be in the DOM. Only its appearance does.

That's the idea behind Projection.

In the middle, the tab bar is an image.

In practice, there are three ways to display the UI:

Mode	What it shows
Live Native UI	The real native view, ready for interaction.
Web Projection	An image of the native UI inside a DOM container.
Web Fallback	HTML or another fallback supplied by the plugin when an image isn't available.

Of course, you can't interact with the native UI while it's projected as an image. That makes the timing of the switch—in both directions—essential.

It feels like magic

The idea was simple. Getting the handoff right was hard.

Hide the native UI before showing its image, and you get a blank frame. Show the image before hiding the native UI, and the translucent UI appears twice, layered over itself.

Neither works.

So I capture the image on the native side and decode it on the web side during idle time, before the switch. But a UI element can still be changing shape just after a long press ends. On iOS, I check its position and size at intervals roughly equal to one frame at 60fps, and capture it only after three consecutive checks find no change.

When Projection starts, I temporarily show the same image on the native side to bridge the handoff. I place the image, captured with its background, and hide the real native UI in the same native-side operation. This prevents both the blank gap and the doubled translucent UI.

Then I show the image on the web side and use requestAnimationFrame to notify the native side to remove its temporary copy. The appearance stays the same. Only the rendering layer changes.

Just watching the screen, you can't tell when the native UI becomes an image.

It feels like magic!

I've also tuned scrolling separately on iOS and Android so the native UI follows the content smoothly.

Watch the top edge of each ad. On both platforms, it disappears behind the header.

And you can use it today

The first things I wanted to support were iOS navigation—toolbar buttons and a tab bar—and native ads that scroll within web content.

This approach is already available in @rdlabo/capacitor-native-ui and @capacitor-community/admob.

But keeping it limited to the plugins I work on felt like a missed opportunity.

Toolbars, mini-player controls, UI provided by native SDKs—there must be more places where this could help.

So I extracted the shared pieces into WebView Native UI Engine, an open-source library under the MIT license.

It's for Capacitor and Cordova plugin authors, with support for iOS and Android.

Register a native view and its destination DOM container, then notify the Engine of the relevant state changes. It coordinates the display transitions. I designed it to fit into existing plugins while preserving their APIs and business logic.

I'd love for you to try it in one of two ways.

If you build plugins

Whether you're building a new plugin with native UI or extending an existing one, try integrating the Engine.

The Getting Started guide includes a minimal setup and integration instructions.

If you use plugins

Wouldn't it be interesting to have this in a plugin you already use?

Suggest it to the plugin's author. Or, if you think you can implement it, send a pull request.

There must be uses for this that I'd never think of on my own.

I can't wait to see what you build with it!

WebView Native UI Engine on GitHub