# WebView

Published articles for WebView.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## jetc.dev Newsletter Issue #331

DevFeed: [jetc.dev Newsletter Issue #331](<https://devfeed.tech/articles/jetc-dev-newsletter-issue-331-26633.md>)

Original publisher: [Read original article](<https://jetc.dev/issues/331.html>)

Author: CommonsWare

Published: 2026-09-15T14:00:00Z

Content type: article

Language: en

Sources: [jetc.dev | Issues](<https://devfeed.tech/sources/jetc-dev-issues.md>)

Topics: [Jetpack Compose](<https://devfeed.tech/topics/jetpack-compose.md>), [compose-for-desktop](<https://devfeed.tech/topics/compose-for-desktop.md>), [servo](<https://devfeed.tech/topics/servo.md>), [WebView](<https://devfeed.tech/topics/webview.md>)

Tags: [bug-fixes](<https://devfeed.tech/tags/bug-fixes.md>), [chromium](<https://devfeed.tech/tags/chromium.md>), [compose-for-desktop](<https://devfeed.tech/tags/compose-for-desktop.md>), [issue](<https://devfeed.tech/tags/issue.md>), [jetpack](<https://devfeed.tech/tags/jetpack.md>), [jetpack-compose](<https://devfeed.tech/tags/jetpack-compose.md>), [release-notes](<https://devfeed.tech/tags/release-notes.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

This newsletter reviews recent Jetpack Compose release changes and highlights related developer content. It covers Compose BOM updates, Material3 and other Compose library versions, a keyboard focus bug and workaround, keyed composition, dialog background blurring, and Compose for Desktop libraries including a CEF-based option and window chrome controls.

### Source excerpt

SideEffect keys! CEF-based WebView and window chrome controls for desktop apps! And... why does the keyboard flicker?!?

## Maestro CLI 2.9.0: test light and dark mode in one flow

DevFeed: [Maestro CLI 2.9.0: test light and dark mode in one flow](<https://devfeed.tech/articles/maestro-cli-2-9-0-test-light-and-dark-mode-in-one-flow-22904.md>)

Original publisher: [Read original article](<https://maestro.dev/blog/maestro-cli-2-9-0>)

Author: Manu Armani

Published: 2026-08-31T15:00:00Z

Content type: release

Language: en

Sources: [mobile.dev - Medium](<https://devfeed.tech/sources/mobile-dev-medium.md>)

Topics: [Command-line interface](<https://devfeed.tech/topics/cli.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>), [WebView](<https://devfeed.tech/topics/webview.md>), [Web](<https://devfeed.tech/topics/web.md>), [Chrome](<https://devfeed.tech/topics/chrome.md>), [YAML](<https://devfeed.tech/topics/yaml.md>)

Tags: [2-9-0](<https://devfeed.tech/tags/2-9-0.md>), [android](<https://devfeed.tech/tags/android.md>), [angular](<https://devfeed.tech/tags/angular.md>), [chrome](<https://devfeed.tech/tags/chrome.md>), [cli](<https://devfeed.tech/tags/cli.md>), [dark-mode](<https://devfeed.tech/tags/dark-mode.md>), [ios](<https://devfeed.tech/tags/ios.md>), [react](<https://devfeed.tech/tags/react.md>), [release](<https://devfeed.tech/tags/release.md>), [vue](<https://devfeed.tech/tags/vue.md>), [web](<https://devfeed.tech/tags/web.md>), [webview](<https://devfeed.tech/tags/webview.md>), [yaml](<https://devfeed.tech/tags/yaml.md>)

### AI overview

Maestro CLI 2.9.0 adds commands for testing light and dark themes within a single flow across iOS, Android, and Web. It also introduces negation globs for YAML files and improves Android WebView inspection, Chrome Web flows, Android reliability, and upload-status polling.

### Source excerpt

Maestro CLI 2.9.0 adds dark-mode commands for iOS, Android, and Web, negation globs in config.yaml, and reliability work for Android WebViews and modern Chrome.

## Security Week 2635: вредоносное ПО в автомобильных Android-устройствах

DevFeed: [Security Week 2635: вредоносное ПО в автомобильных Android-устройствах](<https://devfeed.tech/articles/security-week-2635-android-23090.md>)

Original publisher: [Read original article](<https://habr.com/ru/companies/kaspersky/articles/1073832/>)

Author: Kaspersky\_Lab ("Лаборатория Касперского")

Published: 2026-08-25T08:00:25Z

Content type: news

Language: ru

Sources: ["Лаборатория Касперского" RU](<https://devfeed.tech/sources/ru-2.md>)

Topics: [Security](<https://devfeed.tech/topics/security.md>), [Android](<https://devfeed.tech/topics/android.md>), [APK](<https://devfeed.tech/topics/apk.md>), [HTTP](<https://devfeed.tech/topics/http.md>), [WebView](<https://devfeed.tech/topics/webview.md>)

Tags: [2026](<https://devfeed.tech/tags/2026.md>), [android](<https://devfeed.tech/tags/android.md>), [apk](<https://devfeed.tech/tags/apk.md>), [badbox](<https://devfeed.tech/tags/badbox.md>), [http](<https://devfeed.tech/tags/http.md>), [security](<https://devfeed.tech/tags/security.md>), [tag-9fe8963de219](<https://devfeed.tech/tags/tag-9fe8963de219.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

Kaspersky researchers discovered Android malware installed on DoFun automotive head units. The JarService dropper downloads a clicker for advertising banners and a reverse-proxy module, linking the campaign to attacks on Android TV set-top boxes and the BADBOX platform.

### Source excerpt

Исследователи "Лаборатории Касперского" обнаружили новый Android-зловред, уникальной особенностью которого является установка на головное устройство автомобиля. Вредоносное ПО использовало особенности головных устройств производителя DoFun, позволявшие устанавливать произвольные APK-файлы. Целью распространения вредоносного ПО являлось мошенничество с рекламными баннерами и использование автомобильной магнитолы в качестве прокси-сервера. Исследование кода выявило связи с другими атаками, нацеленными, например, на телеприставки под управлением Android. Расследование началось в июне 2026 года, когда специалисты "Лаборатории Касперского" обнаружили новый дроппер JarService. Зловред устанавливался как обычное пользовательское приложение и никак не маскировался под легитимное ПО. Точнее, у него полностью отсутствовал интерфейс, что указывало на возможность установки без ведома пользователя. Дроппер расшифровывает данные и запускает следующий этап атаки -- вредоносный загрузчик. Он, в свою очередь, отправляет информацию на командный сервер злоумышленников, скачивает оттуда и запускает финальную полезную нагрузку -- кликер на рекламные баннеры и реверс-прокси. Читать далее

## SwiftUI Custom URL Schemes

DevFeed: [SwiftUI Custom URL Schemes](<https://devfeed.tech/articles/swiftui-custom-url-schemes-21088.md>)

Original publisher: [Read original article](<https://useyourloaf.com/blog/swiftui-custom-url-schemes/>)

Author: Keith Harrison

Published: 2025-10-27T11:26:47Z

Content type: tutorial

Language: en

Sources: [K. Harrison](<https://devfeed.tech/sources/k-harrison.md>)

Topics: [SwiftUI](<https://devfeed.tech/topics/swiftui.md>), [WebView](<https://devfeed.tech/topics/webview.md>), [iOS](<https://devfeed.tech/topics/ios.md>), [WebKit](<https://devfeed.tech/topics/webkit.md>), [App](<https://devfeed.tech/topics/app.md>)

Tags: [async](<https://devfeed.tech/tags/async.md>), [auto-layout](<https://devfeed.tech/tags/auto-layout.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [ios](<https://devfeed.tech/tags/ios.md>), [ios-26](<https://devfeed.tech/tags/ios-26.md>), [objective-c](<https://devfeed.tech/tags/objective-c.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [scheme](<https://devfeed.tech/tags/scheme.md>), [swift](<https://devfeed.tech/tags/swift.md>), [swiftui](<https://devfeed.tech/tags/swiftui.md>), [web](<https://devfeed.tech/tags/web.md>), [webview](<https://devfeed.tech/tags/webview.md>), [wwdc](<https://devfeed.tech/tags/wwdc.md>), [xcode](<https://devfeed.tech/tags/xcode.md>)

### AI overview

This tutorial explains how to create a custom URL scheme handler for SwiftUI WebViews in iOS 26. It covers implementing URLSchemeHandler, loading local HTML resources from an app bundle, registering the handler in a WebPage configuration, and displaying the page in a WebView.

### Source excerpt

Create a custom URL scheme handler for SwiftUI WebViews. Custom URL schemes Apple introduced both WebView and WebPage SwiftUI views in iOS 26. These provide similar WebKit functionality to the UIKit WKWebView APIs. This includes being able to register custom URL schemes to load local resources. Suppose I have an App that loads quotations from the local App bundle. My URL scheme uses the format: quotes://001.html There are a few steps to support a custom URL scheme: Create a custom URL scheme handler that knows how to load the local resources. Register the scheme handler in a WebPage configuration. Have the WebView load and display the web page. Let's look at each of those steps. URLSchemeHandler (iOS 26) The URLSchemeHandler is a protocol with a reply method to return an async sequence of results. The AsyncSequence expects us to either yield a URLResponse and some data or throw an error. struct QuoteSchemeHandler: URLSchemeHandler { static let scheme = "quotes" func reply(for request: URLRequest) -> some AsyncSequence< URLSchemeTaskResult, any Error > { AsyncThrowingStream { continuation in ... } } } The reply method provides us with the URLRequest. I start by extracting the URL and checking it matches our quotes scheme: guard let url = request.url else { continuation.finish(throwing: QuoteError.missingURL) return } guard url.scheme == QuoteSchemeHandler.scheme else { continuation.finish(throwing: QuoteError.invalidScheme) return } To construct the URL response I need the mime type and length of the data. I first extract the filename from the URL, determine the mime type from the file extension, and then load the data: do { let file = try filename(for: url) let mimeType = try mimeType(for: file) let data = try Data(contentsOf: file) I can then build the URLResponse: let response = URLResponse( url: url, mimeType: mimeType, expectedContentLength: data.count, textEncodingName: "utf-8" ) If nothing has gone wrong I then add the response and the data to the AsyncSequenc

## Apple's in-app browsers may enable extensive tracking despite App Tracking Transparency

DevFeed: [Apple's in-app browsers may enable extensive tracking despite App Tracking Transparency](<https://devfeed.tech/articles/apple-vs-facebook-is-kayfabe-26553.md>)

Original publisher: [Read original article](<https://infrequently.org/2025/08/apple-vs-fb-kayfabe/>)

Author: Alex Russell

Published: 2025-08-25T00:00:00Z

Content type: opinion

Language: en

Sources: [Alex Russell](<https://devfeed.tech/sources/alex-russell.md>)

Topics: [WebView](<https://devfeed.tech/topics/webview.md>), [browser](<https://devfeed.tech/topics/browser.md>), [browsers](<https://devfeed.tech/topics/browsers.md>), [Web](<https://devfeed.tech/topics/web.md>), [Internet](<https://devfeed.tech/topics/internet.md>)

Tags: [apple](<https://devfeed.tech/tags/apple.md>), [browser](<https://devfeed.tech/tags/browser.md>), [browsers](<https://devfeed.tech/tags/browsers.md>), [facebook](<https://devfeed.tech/tags/facebook.md>), [in-app-browsers](<https://devfeed.tech/tags/in-app-browsers.md>), [internet](<https://devfeed.tech/tags/internet.md>), [policy](<https://devfeed.tech/tags/policy.md>), [privacy](<https://devfeed.tech/tags/privacy.md>), [script](<https://devfeed.tech/tags/script.md>), [surveillance](<https://devfeed.tech/tags/surveillance.md>), [web](<https://devfeed.tech/tags/web.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

The article argues that Apple's App Tracking Transparency had little discernible effect on Facebook's revenue and that Apple continues to permit extensive tracking through in-app browsers. It says these WebViews can observe URLs and allow existing web tracking mechanisms to correlate in-app activity with browsing, while restricting users' access to their preferred browsers.

### Source excerpt

Photo by Claudia Raya Apple vs. Facebook is, and always was, kayfabe. In reality, Apple is Facebook's chauffeur; holding Zuck's coat while Facebook1 wantonly surveils iPhones owners.2 Facebook's gross profit over time. Facebook and Apple mugged convincingly for the cameras as "App Tracking Transparency" rolled out, talking up the impact to Facebook's business. But San Mateo's profits tell a very different story. Net income dipped between late 2021 and early 2023 thanks to accelerating capital expenditures, not reductions in revenue. Despite strenuous efforts to sell the move, it's hard to discern any impact from ATT whatsoever. How can we be sure Apple's wise? Because Cupertino continues to allow Facebook's wide-scale abuse of In-App Browsers: Open Web Advocacy - In-App Browser Primer Apple has long facilitated and enriched mass surveillance through native apps, both directly from in-app activity, but much more insidiously through the In-App Browsers that lurk behind every link in Facebook, Instagram, Messenger, Threads, TikTok, Pinterest, etc. I have written about them before, and they still stink to high heavens. Facebook couldn't ask for a better or more willing accomplice than Apple as it glides into the second decade of its browserjacking spree. In-App Browsers are, for Facebook's purposes, ad-blocker blockers. Cheat codes for the enterprising panopticon proprietor. Much wringing of hands transpires every time one of these knockoff browsers is suspected of injecting script into web pages. The fear is that this will enable a level of tracking by apps that is not otherwise possible. As scary (and real) as the threat is, it is also a misdirection. To effect total surveillance, Facebook et al. don't need to inject scripts into the runtime, they only need your browser not to block their "ad tags" that are already embedded in every high-traffic page on the internet. Combined with the ability to watch every URL you navigate to in a WebView, this is more than enough to

## Mobile Bridge: Making WebViews Feel Native

DevFeed: [Mobile Bridge: Making WebViews Feel Native](<https://devfeed.tech/articles/mobile-bridge-making-webviews-feel-native-1499.md>)

Original publisher: [Read original article](<https://shopify.engineering/mobilebridge-native-webviews>)

Author: Mauricio de Meirelles

Published: 2025-04-25T14:12:00Z

Content type: tutorial

Language: en

Sources: [Shopify Engineering](<https://devfeed.tech/sources/shopify-engineering.md>), [Shopify Engineering - Shopify Engineering](<https://devfeed.tech/sources/shopify-engineering-shopify-engineering.md>)

Topics: [WebView](<https://devfeed.tech/topics/webview.md>), [Shopify](<https://devfeed.tech/topics/shopify.md>), [React Native](<https://devfeed.tech/topics/react-native.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>), [migration](<https://devfeed.tech/topics/migration.md>)

Tags: [mobile](<https://devfeed.tech/tags/mobile.md>), [react-native](<https://devfeed.tech/tags/react-native.md>), [shopify](<https://devfeed.tech/tags/shopify.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

Shopify describes Mobile Bridge, a framework for improving WebView performance, appearance, and integration in its mobile app. The approach preloads, authenticates, caches, and reuses WebViews through native iOS and Android modules.

### Source excerpt

Learn how we tackled the main issues of traditional WebViews--performance, appearance, and integration--and how Mobile Bridge became a game-changer in our mobile development strategy, even allowing us to accelerate the migration to React Native.

## Testing Claude for Swift and JavaScript Coding Questions

DevFeed: [Testing Claude for Swift and JavaScript Coding Questions](<https://devfeed.tech/articles/a-swim-with-a-chat-bot-35508.md>)

Original publisher: [Read original article](<https://meowni.ca/posts/chatty-mcchatface/>)

Author: Monica Dinculescu

Published: 2024-09-29T00:00:00Z

Content type: opinion

Language: en

Sources: [Monica Dinculescu](<https://devfeed.tech/sources/monica-dinculescu.md>)

Topics: [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [Claude](<https://devfeed.tech/topics/claude.md>), [Swift](<https://devfeed.tech/topics/swift.md>), [Stack Overflow](<https://devfeed.tech/topics/stackoverflow.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [CSS](<https://devfeed.tech/topics/css.md>), [HTML](<https://devfeed.tech/topics/html.md>), [WebView](<https://devfeed.tech/topics/webview.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [claude](<https://devfeed.tech/tags/claude.md>), [css](<https://devfeed.tech/tags/css.md>), [html](<https://devfeed.tech/tags/html.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [prompt-engineering](<https://devfeed.tech/tags/prompt-engineering.md>), [stack-overflow](<https://devfeed.tech/tags/stack-overflow.md>), [swift](<https://devfeed.tech/tags/swift.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

The author describes mixed experiences using AI chatbots, especially Claude.ai, for coding help. Claude was useful for Swift syntax and JavaScript tasks, but unreliable answers in unfamiliar areas could take longer to verify than using Stack Overflow.

### Source excerpt

I have 4 (rounded up) beefs with language-y AI bots that have resulted in me sort of avoiding them altogether: They have the personality of a middle manager who writes Google Docs all day that nobody wants to read They're reallllly good at guessing but not actually that smart, which leads to very convincing lies (see: the "how many Rs in strawberry?" saga). If I had the inclination to double check all the bot's work, I would've just done it myself Absolutely no thank you to the scam that is "prompt engineering". I'm not wasting 17 demon invocations to convince Chat GPT to do a thing. That's not the future I was promised. (not their fault) I have unresolved trauma about generated code from the Microsoft FrontPage era Testing the waters Unrelated to bots, I've been recently faffing about on a Swift app, with exactly zero prior knowledge of Swift. I basically have to Google everything (what's up with the mad ForEach syntax????) to get to a Stack Overflow page that isn't the one I actually need because search results have gotten sloppy, and it takes a minute. None of the things I'm copy pasting are "hard"; they're tedious code I can write in other languages but not in this one. And not to be a jerk, but 1-1 code translation isn't what I want to spend my spare time on. A friend told me to try Claude.ai, and it worked reasonably well for what I asked of it, which was mostly syntax (how do I add internal padding to a TextField?). I tried it for some harder questions with mixed results: how do I make links inside a WebView not open a native app? was a mess, but why do you think a page of just inputs is really slow gave me the right idea for where to start spelunking. The problem with trying it on a language I'm not an expert in goes back to Beef #2 above - I can't spot the very convincing lies as easily, and then I spend extra time trying to figure out if I copied it wrong or the answer is wrong (which is what happened with the WebView question), and it takes longer than if

## How JavaScript-First Frontend Practices Struggled with the Mobile Web

DevFeed: [How JavaScript-First Frontend Practices Struggled with the Mobile Web](<https://devfeed.tech/articles/reckoning-part-1-the-landscape-26546.md>)

Original publisher: [Read original article](<https://infrequently.org/2024/08/the-landscape/>)

Author: Alex Russell

Published: 2024-08-12T00:00:00Z

Content type: opinion

Language: en

Sources: [Alex Russell](<https://devfeed.tech/sources/alex-russell.md>)

Topics: [Front end](<https://devfeed.tech/topics/frontend.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>), [Chrome](<https://devfeed.tech/topics/chrome.md>), [WebView](<https://devfeed.tech/topics/webview.md>), [Chromium](<https://devfeed.tech/topics/chromium.md>)

Tags: [chrome](<https://devfeed.tech/tags/chrome.md>), [chromium](<https://devfeed.tech/tags/chromium.md>), [frontend](<https://devfeed.tech/tags/frontend.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [performance](<https://devfeed.tech/tags/performance.md>), [webdev](<https://devfeed.tech/tags/webdev.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

This first part of a four-part investigation examines how JavaScript-first frontend culture developed alongside the mobile web. It describes browser development for Android, the challenges of Chromium's memory-hungry multi-process sandboxing, and the introduction of PWAs and Push Notifications, then argues that desktop-oriented JavaScript frameworks brought unnecessary bloat to mobile-first projects.

### Source excerpt

Instead of an omnibus mega-post, this investigation into JavaScript-first frontend culture and how it broke US public services has been released in four parts. Other posts in the series: Reckoning: Part 2 -- Object Lesson Reckoning: Part 3 -- Caprock Reckoning: Part 4 -- The Way Out When you live in the shadow of a slow-moving crisis, it's natural to tell people about it. At volume. Doubly so when engineers can cheaply and easily address the root causes with minor tweaks. As things worsen, it's also hard not to build empathy for Cassandra. In late 2011, I moved to London, where the Chrome team was beginning to build Google's first "real" browser for Android.1 The system default Android Browser had, up until that point, been based on the system WebView, locking its rate of progress to the glacial pace of device replacement.2 In a world where the Nexus 4's 2GB of RAM and 32-bit, 4-core CPU were the high-end, the memory savings the Android Browser achieved by reusing WebView code mattered immensely.3 Those limits presented enormous challenges for Chromium's safer (but memory-hungry) multi-process sandboxing. Android wasn't just spicy Linux; it was an entirely new ballgame. Even then, it was clear the iPhone wasn't a fluke. Mobile was clearly on track to be the dominant form-factor, and we needed to adapt. Fast.4 Browsers made that turn, and by 2014, we had made enough progress to consider how the web could participate in mobile's app-based model. This work culminated in 2015's introduction of PWAs and Push Notifications. Disturbing patterns emerged as we worked with folks building on this new platform. A surprisingly high fraction of them brought slow, desktop-oriented JavaScript frameworks with them to the mobile web. These modern, mobile-first projects neither needed nor could afford the extra bloat frameworks included to paper over the problems of legacy desktop browsers. Web developers needed to adapt the way browser developers had, but consistently failed to hit the

## Making the case for the WebView

DevFeed: [Making the case for the WebView](<https://devfeed.tech/articles/making-the-case-for-the-webview-30797.md>)

Original publisher: [Read original article](<https://devblog.kogan.com/blog/making-the-case-for-the-webview>)

Author: Campbell Graham

Published: 2024-01-25T05:29:47Z

Content type: opinion

Language: en

Sources: [Kogan.com](<https://devfeed.tech/sources/kogan-com.md>)

Topics: [WebView](<https://devfeed.tech/topics/webview.md>), [mobile-app-development](<https://devfeed.tech/topics/mobile-app-development.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>), [User Experience](<https://devfeed.tech/topics/user-experience.md>)

Tags: [hybrid](<https://devfeed.tech/tags/hybrid.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [mobile-app-development](<https://devfeed.tech/tags/mobile-app-development.md>), [user-experience](<https://devfeed.tech/tags/user-experience.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

This opinion article argues that nested WebViews can be appropriate in hybrid mobile apps when teams must balance feature work, platform changes, maintenance, and parity with an accompanying website. It suggests evaluating criticality, interactivity, change frequency, content size, loading overhead, and native-development complexity, while keeping transitions seamless and preserving navigation and user state.

### Source excerpt

Learning to embrace a hybrid approach for mobile app development: Native apps are best! Like the rest of the native mobile app development community, I typically agree with the notion that "native is best" when it comes to mobile apps. After all, these are the technologies we spend tens of hours every week utilising, and there is a passion for user experience that I feel is required in order to happily dive into the deep-end-specialisation of Google or Apple's tooling. An example of what is possible with Google's Material Design for Android: https://developer.android.com/design/ui?_gl=1*1g30ii5*_ga*MjA3NjQzNjE2NS4xNzAyOTQ0Nzc2*_ga_QPQ2NRV856*MTcwNjA2MTg0My44LjEuMTcwNjA2MTk2Ni4wLjAuMA.. However... As one of these oft-opinionated app developers who tends to view non-native tooling like React Native as a sub-par user experience, I have a potentially unpopular idea to share. Sometimes, a nested WebView does have its place. The pitch It might not be popular with the purists, but please hear me out. The nested WebView does sometimes have an important role to play (emphasis on nested!). When facing the challenge of balancing new features, requested enhancements, required platform changes and general maintenance, maintaining the required degree of parity between your mobile app and its accompanying website can be difficult. In my experience, here are some key factors to consider when deciding whether to implement a flow natively within your app or whether to utilise a nested WebView: Is it a critical piece of functionality that users will frequently use? To what degree is the content static or interactive? Will it be subject to frequent changes? How much content is there to display? Will the overhead of loading a WebView (including any relevant JavaScript) be fast enough for the use case? Do you feel any technical hurdles of developing it natively will result in a better user experience? There is no definitive flow chart that can help make this decision for you. However, wh

## Mastering UI Testing for Android web forms

DevFeed: [Mastering UI Testing for Android web forms](<https://devfeed.tech/articles/mastering-ui-testing-for-android-web-forms-23704.md>)

Original publisher: [Read original article](<https://engineering.theblueground.com/mastering-ui-testing-for-android-web-forms/>)

Author: Vaios Tsitsonis

Published: 2024-01-05T11:50:19Z

Content type: tutorial

Language: en

Sources: [Blueground Engineering blog](<https://devfeed.tech/sources/blueground-engineering-blog.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [WebView](<https://devfeed.tech/topics/webview.md>), [Forms](<https://devfeed.tech/topics/forms.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [HTML](<https://devfeed.tech/topics/html.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [forms](<https://devfeed.tech/tags/forms.md>), [html-elements](<https://devfeed.tech/tags/html-elements.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [testing](<https://devfeed.tech/tags/testing.md>), [ui-testing](<https://devfeed.tech/tags/ui-testing.md>), [web](<https://devfeed.tech/tags/web.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

This tutorial explains a UI-testing problem in Android apps that open web forms in a WebView. Programmatically changing HTML input values can mark related JavaScript events as non-trusted, leaving a button disabled even when the fields display values.

### Source excerpt

Yeah! We are Android engineers! 🎉 We can build almost anything by ourselves and make it run on any Android device! But sometimes we may need to use a third-party library or incorporate web-based functionality into a WebView to go fast. This can introduce challenges during UI testing.

## A Practical Guide to Building Better Android WebViews

DevFeed: [A Practical Guide to Building Better Android WebViews](<https://devfeed.tech/articles/the-better-webviews-collection-26011.md>)

Original publisher: [Read original article](<https://proandroiddev.com/the-better-webviews-collection-778c7bd709e6?source=rss-2ffcf6104135------2>)

Author: Stacy Devino

Published: 2023-05-09T14:04:27Z

Content type: tutorial

Language: en

Sources: [Stories by Stacy Devino on Medium](<https://devfeed.tech/sources/stories-by-stacy-devino-on-medium.md>)

Topics: [WebView](<https://devfeed.tech/topics/webview.md>), [Android](<https://devfeed.tech/topics/android.md>), [Front end](<https://devfeed.tech/topics/frontend.md>), [Google](<https://devfeed.tech/topics/google.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-app-development](<https://devfeed.tech/tags/android-app-development.md>), [androiddev](<https://devfeed.tech/tags/androiddev.md>), [browser](<https://devfeed.tech/tags/browser.md>), [cache](<https://devfeed.tech/tags/cache.md>), [chromium](<https://devfeed.tech/tags/chromium.md>), [compatibility](<https://devfeed.tech/tags/compatibility.md>), [front-end](<https://devfeed.tech/tags/front-end.md>), [mobile-app-development](<https://devfeed.tech/tags/mobile-app-development.md>), [web-development](<https://devfeed.tech/tags/web-development.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

This practical guide explains how to build better Android WebViews. It covers WebKit and provider differences across devices, compatibility checks with AndroidX WebKit and Browser, shared caching and DOM storage, and WebView settings affecting frontend rendering, scaling, accessibility, testing, and security.

### Source excerpt

The Better Android WebViews Collection WebViews are one of the most controversial subjects in the Community and unfortunately have been much maligned by developers. WebViews can be extremely useful and the best first implementation for a ton of situations from Login and Payments to User Support and Legal. Using WebViews, you can allocate your resources and attention to what your customers value most. WebView-primary apps even make up almost a third of all Apps on the Google Play Store. So, how do we make really good WebViews? Knowledge Drop 🧠💧 WebKit implementation varies ⏺ Non-Chromium-based (Non-GMS devices and some vendors) ⏺ Not all Play-Enabled devices have all features. Use isFeatureSupported and permission checks rather than @Targetan Android OS to be safe. ⏺ Customized Chromium Base (Samsung and Amazon Fire devices) There are 3 "Standard" WebViews available embedded as providers. ⏺ "Standalone" AOSP basic implementation and standard for 5.X-6.X ⏺ "Monochrome" public and AOSP-accessible unified Browser and WebView for 7.X-9.X ⏺ "Trichrome" which is a base Core Library, WebView, and Chrome browser all separated for 10.X -- Now (13.X) Use the modern WebViewCompat extensions with AndroidX Webkit / AndroidX Browser to avoid compatibility issues & version-based errors All WebView instances in your app will share the same Cache and Dom Storage, improving performance and memory usage Trust the Chromium Docs first over android.dev ⏺ WebView is now built and maintained by the Chrome team, so their documentation is going to be the most accurate and extensive WebView Settings for Success 🏆 "Make it look like Chrome" or "Why is Scaling broken?!?!?!" ReactJS, VueJS and similar front end frameworks rely on viewport and framing information in order to enable their dynamic sizing and styling features. By Default, what exists on Chrome is not what is enabled in the WebView and it requires some browser/web rendering knowledge to even figure out what is going wrong. Try these ou

## Data Processing in Codename One apps

DevFeed: [Data Processing in Codename One apps](<https://devfeed.tech/articles/data-processing-in-codename-one-apps-19279.md>)

Original publisher: [Read original article](<https://www.codenameone.com/blog/data-processing-in-codename-one-apps/>)

Author: Steve Hannah

Published: 2021-03-25T00:00:00Z

Content type: tutorial

Language: en

Sources: [CodeName One](<https://devfeed.tech/sources/codename-one.md>)

Topics: [data-processing](<https://devfeed.tech/topics/data-processing.md>), [Parsing](<https://devfeed.tech/topics/parsing.md>), [HTML](<https://devfeed.tech/topics/html.md>), [JSON](<https://devfeed.tech/topics/json.md>), [XML](<https://devfeed.tech/topics/xml.md>), [WebView](<https://devfeed.tech/topics/webview.md>)

Tags: [conversion](<https://devfeed.tech/tags/conversion.md>), [data](<https://devfeed.tech/tags/data.md>), [data-processing](<https://devfeed.tech/tags/data-processing.md>), [html](<https://devfeed.tech/tags/html.md>), [json](<https://devfeed.tech/tags/json.md>), [parsing](<https://devfeed.tech/tags/parsing.md>), [webview](<https://devfeed.tech/tags/webview.md>), [xml](<https://devfeed.tech/tags/xml.md>)

### AI overview

A tutorial covering data processing and conversion in Codename One apps, with recipes for parsing JSON, HTML, and XML. It explains using HTMLParser, its asynchronous behavior and webview-based implementation, along with clipboard operations and JavaScript sandbox limitations.

### Source excerpt

The following recipes relate to data processing and conversion in Codename One apps. This includes parsing data like JSON, HTML and XML.

## Comparing React Native, Flutter, and Kotlin Multiplatform for Cross-Platform Mobile Development

DevFeed: [Comparing React Native, Flutter, and Kotlin Multiplatform for Cross-Platform Mobile Development](<https://devfeed.tech/articles/my-2-cents-about-cross-platform-25547.md>)

Original publisher: [Read original article](<https://www.marcogomiero.com/posts/2020/my-2cents-cross-platform/>)

Author: Marco Gomiero

Published: 2020-08-04T00:00:00Z

Content type: opinion

Language: en

Sources: [Posts on Marco Gomiero](<https://devfeed.tech/sources/posts-on-marco-gomiero.md>)

Topics: [cross-platform](<https://devfeed.tech/topics/cross-platform.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>), [Flutter](<https://devfeed.tech/topics/flutter.md>), [Kotlin Multiplatform](<https://devfeed.tech/topics/kotlin-multiplatform.md>), [React Native](<https://devfeed.tech/topics/react-native.md>), [Dart](<https://devfeed.tech/topics/dart.md>), [Kotlin](<https://devfeed.tech/topics/kotlin.md>)

Tags: [cross-platform](<https://devfeed.tech/tags/cross-platform.md>), [dart](<https://devfeed.tech/tags/dart.md>), [flutter](<https://devfeed.tech/tags/flutter.md>), [kotlin-multiplatform](<https://devfeed.tech/tags/kotlin-multiplatform.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [opinions](<https://devfeed.tech/tags/opinions.md>), [performance](<https://devfeed.tech/tags/performance.md>), [production](<https://devfeed.tech/tags/production.md>), [react-native](<https://devfeed.tech/tags/react-native.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

A mobile developer shares experience-based opinions on cross-platform development, focusing on React Native, Flutter, and Kotlin Multiplatform. The article discusses performance, language preferences, production use, and when to choose cross-platform solutions.

### Source excerpt

During my journey as a mobile developer, I had the chance to try and give a look at some cross-platform solutions both for work and fun reasons. Today, I want to share my thoughts and considerations about them and why/when you should use cross-platform. I hope that these thoughts will be helpful to anyone that is in the process of choosing the right solution for their product. Disclaimer: in this article, I will share some opinions based on my experience and they can apply to your situation or not. If you want to share your considerations, feel free to reach me out on Twitter @marcoGomier.

## Chrome Custom Tabs in Android

DevFeed: [Chrome Custom Tabs in Android](<https://devfeed.tech/articles/chrome-custom-tabs-in-android-25832.md>)

Original publisher: [Read original article](<https://segunfamisa.com/posts/chrome-custom-tabs>)

Author: Segun Famisa

Published: 2016-06-04T08:05:30Z

Content type: tutorial

Language: en

Sources: [Segun Famisa](<https://devfeed.tech/sources/segun-famisa.md>)

Topics: [Chrome](<https://devfeed.tech/topics/chrome.md>), [Android](<https://devfeed.tech/topics/android.md>), [WebView](<https://devfeed.tech/topics/webview.md>), [Google](<https://devfeed.tech/topics/google.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [browser](<https://devfeed.tech/tags/browser.md>), [chrome](<https://devfeed.tech/tags/chrome.md>), [code](<https://devfeed.tech/tags/code.md>), [developers](<https://devfeed.tech/tags/developers.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [technical](<https://devfeed.tech/tags/technical.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

A tutorial explaining why and how to use Chrome Custom Tabs in Android applications. It compares opening links externally and using WebView, then describes Custom Tabs as a way to display Chrome content within an app with customizable controls and transitions.

### Source excerpt

Introduction I have been seeing a behaviour in some apps for a while, and I've always wanted to know how it was done. I noticed some apps that allow to view urls within the app, used something that is "Powered by Chrome". I first noticed this on the Twitter for Android app, then on Medium, then Feedly. I was interested in knowing how these worked, but I didn't know what to search for. Finally, a few weeks ago, I stumbled on "Chrome Custom Tabs". Alas, that was what I was looking for. In this post, I'm going to explain why, when and how to use "Chrome Custom Tabs" in your Android applications. Why use Chrome Custom tabs? When building apps, developers are usually faced with difficult tradeoffs to make when we have to show web content in our Android apps. Very common and easy solution is to open links externally. If you do this, then these lines of code will look familiar: Intent browserIntent = new Intent(Intent.ACTION_VIEW, Uri.parse(url)); startActivity(browserIntent); This typically results in a heavy-weight transition between the app and web. Launching a browser from your app to view web content results in a huge context switch which isn't customizable, and hence could lead to a terrible experience. An improvement on this experience will be to use a WebView which is essentially an Android view that displays web pages. However, this options requires technical work to implement and delivers a browsing experience that the users aren't used to. To solve this problem, the Google Chrome team introduced a new feature last September, called custom tabs. This allows to load a chrome tab within your app, and also allows you customize the look and feel of Chrome thereby making the transition between your app and the web content fast & seamless for your users. This is Chrome Custom tab in action on Twitter for Android app: Chrome Custom tab allows you customize the experience of Chrome. It allows you customize: Toolbar color Enter and exit animations Add custom actions to th

## Introducing GoldenGate

DevFeed: [Introducing GoldenGate](<https://devfeed.tech/articles/introducing-goldengate-31887.md>)

Original publisher: [Read original article](<http://engineering.flipboard.com//2015/02/golden-gate>)

Author: https://twitter.com/emilsjolander (Emil Sjölander)

Published: 2015-02-24T00:00:00Z

Content type: release

Language: en

Sources: [Flipboard](<https://devfeed.tech/sources/flipboard.md>)

Topics: [WebView](<https://devfeed.tech/topics/webview.md>), [Java](<https://devfeed.tech/topics/java.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [Library](<https://devfeed.tech/topics/library.md>), [LineageOS](<https://devfeed.tech/topics/lineageos.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [java](<https://devfeed.tech/tags/java.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [library](<https://devfeed.tech/tags/library.md>), [type-safety](<https://devfeed.tech/tags/type-safety.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

Flipboard introduces GoldenGate, an annotation-processing library for Android that generates Java wrappers around JavaScript code used in WebViews. The library provides compile-time type checking for calls across the native-JavaScript bridge.

### Source excerpt

You might not know it, but both Flipboard for iOS and Flipboard for Android make heavy use of web views. We use web views so we can ensure consistent designs for our partners' articles across all platforms. Communication between native code and the JavaScript code running in a web view is something that is both tedious to implement as well as very bug prone as it's mostly just string concatenation. Today we are releasing a library to make this task easier when developing Android applications which use web views. GoldenGate is a annotation processing library which generates java wrappers around your JavaScript code. An annotation processing library is a piece of code which runs when you compile your code and has the ability to generate new java classes. This means that GoldenGate can ensure at compile time that you are sending the correct types into the JavaScript functions you define in your bridge. If you're interested in knowing more about how to write your own, this blog post is a good intro. Let's get into a quick example to really show the power of the library! First of all a quick example of how to currently call a JavaScript function in a WebView. 1 webview.loadUrl("javascript:alert(" + myString + ");"); You should clearly see that a lot can go wrong here which the compiler won't catch. For example you could misspell 1 alert or maybe 1 myString isn't a string at all. GoldenGate allows for the compiler to have your back. The same code as above written with GoldenGate looks like this. 1 2 3 4 5 6 7 @Bridge class JavaScript { void alert(String message); } JavaScriptBridge bridge = new JavaScript(webview); bridge.alert(myString); We started by defining an interface which describes the JavaScript methods we want to call from java. This interface is annotated with 1 @Bridge which is where the magic happens. This will generate a class named 1 JavaScriptBridge in this case which implements all the methods defined by the interface. There are a couple more options for

## Understanding Android Intents for App-to-App Interaction

DevFeed: [Understanding Android Intents for App-to-App Interaction](<https://devfeed.tech/articles/what-s-your-intent-30575.md>)

Original publisher: [Read original article](<https://ryanharter.com/blog/2014/11/whats-your-intent/>)

Published: 2014-11-26T07:00:00Z

Content type: article

Language: en

Sources: [Blogs on Ryan Harter](<https://devfeed.tech/sources/blogs-on-ryan-harter.md>)

Topics: [Android](<https://devfeed.tech/topics/android.md>), [android-apps](<https://devfeed.tech/topics/android-apps.md>), [App](<https://devfeed.tech/topics/app.md>), [WebView](<https://devfeed.tech/topics/webview.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [android-apps](<https://devfeed.tech/tags/android-apps.md>), [apps](<https://devfeed.tech/tags/apps.md>), [use-cases](<https://devfeed.tech/tags/use-cases.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

This article explains Android's Intent system as a way for apps to interact and exchange data without knowing the specific apps involved. It compares Intents with URLs and describes action and request use cases, including launching activities and handling external content.

### Source excerpt

One of the most powerful, yet sometimes overlooked, features of Android is the Intent system. Android's Intents allow apps to interact with each other, without intimate knowledge of each other. Intents are one of the differentiating factors that allows Android apps to interact and send data beyond their walls, while still keeping the system relatively safe. Anatomy of an Intent I like to think of Intents as the opposite of URLs. You remember URLs, right? That's how you got to this page.

## HTML5 Taking over the app world - Touchlab

DevFeed: [HTML5 Taking over the app world - Touchlab](<https://devfeed.tech/articles/html5-taking-over-the-app-world-touchlab-38058.md>)

Original publisher: [Read original article](<https://touchlab.co/2012-07-html5-taking-over-the-app-world>)

Published: 2012-07-03T19:59:00Z

Content type: opinion

Language: en

Sources: [Touchlab | Enterprise Mobile Innovation & Development](<https://devfeed.tech/sources/touchlab-enterprise-mobile-innovation-development.md>)

Topics: [HTML5](<https://devfeed.tech/topics/html5.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>), [App](<https://devfeed.tech/topics/app.md>), [WebView](<https://devfeed.tech/topics/webview.md>), [cross-platform](<https://devfeed.tech/topics/cross-platform.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [Ajax](<https://devfeed.tech/topics/ajax.md>)

Tags: [ajax](<https://devfeed.tech/tags/ajax.md>), [code-sharing](<https://devfeed.tech/tags/code-sharing.md>), [cross-platform](<https://devfeed.tech/tags/cross-platform.md>), [development](<https://devfeed.tech/tags/development.md>), [html5](<https://devfeed.tech/tags/html5.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [mobile](<https://devfeed.tech/tags/mobile.md>), [thoughts](<https://devfeed.tech/tags/thoughts.md>), [webview](<https://devfeed.tech/tags/webview.md>)

### AI overview

This opinion argues that HTML5 could serve as a mobile app platform, but Apple and Google have little incentive to support it within their app ecosystems. It discusses WebView limitations, the author's experience with JavaScript and Ajax, and broader cross-platform development examples.

### Source excerpt

I think you might read that title and think this is going to be about how HTML5 is steadily taking over the native app world on mobile devices...