# pwa Published articles for pwa. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How to Accept Payments in a Progressive Web App (PWA) DevFeed: [How to Accept Payments in a Progressive Web App (PWA)]() Original publisher: [Read original article]() Author: Ayush Agarwal Published: 2026-03-30T00:00:00Z Content type: tutorial Language: en Sources: [Dodo Payments Blog]() Topics: [PWA](), [web applications](), [Software as a service](), [Mobile]() Tags: [app-store](), [how-to](), [mobile](), [payment-processing](), [payments](), [pwa](), [saas](), [subscriptions](), [tax](), [web-app]() ### AI overview This guide explains how to add payment processing to a Progressive Web App using Dodo Payments. It covers web checkout, subscription states, and tax compliance for global SaaS distribution. ### Source excerpt Guide to adding payment processing to Progressive Web Apps. Avoid app store fees, use web checkout, and handle subscriptions with automatic tax compliance. ## Smart photo organization through privacy-first, on-device AI DevFeed: [Smart photo organization through privacy-first, on-device AI]() Original publisher: [Read original article]() Author: Cynthia Wang Published: 2025-10-15T08:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [On-device AI](), [Firebase](), [PWA](), [SDKs](), [web applications](), [browser]() Tags: [ai](), [ai-logic](), [firebase](), [gemini](), [hybrid-inference](), [on-device](), [on-device-ai](), [privacy](), [pwa](), [sdks](), [tutorials](), [web](), [web-browser]() ### AI overview This Firebase tutorial explains how to build a privacy-focused photo organization progressive web app using on-device AI. It describes running a local model in the browser so photos remain on the user's device and can be analyzed offline, with Firebase AI Logic SDKs detecting and caching compatible models such as Gemini Nano and providing a fallback approach for other browsers. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Apple's Dispute With the EU Over DMA Compliance and Browser Competition DevFeed: [Apple's Dispute With the EU Over DMA Compliance and Browser Competition]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-09-25T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [browser](), [Security](), [iOS](), [PWA](), [push-notification](), [Web]() Tags: [apple](), [browser](), [browsers](), [competition](), [dma](), [eu](), [geofencing](), [ios](), [iphone](), [pdf](), [push-notification](), [pwa](), [sdk](), [security](), [webdev]() ### AI overview The article argues that Apple is misrepresenting the European Union's enforcement of the Digital Markets Act and shifting responsibility for its own compliance decisions onto regulators. It focuses on alleged barriers affecting browser competition on iOS, including geofencing, restricted PWA and Push Notification APIs, SDK bugs, and difficult development entitlements. ### Source excerpt Contents Lies by Any Other Name Great Artists Steal Dear Tech Reporters: Access Is Not A Beat This blog is failing on several levels. First, September 2025 is putting the "frequent" in "infrequently", much to my chagrin. Second, my professional mission is to make a web that's better for everyone, not to tear Apple down. But just when I thought I was out, they pull me back in. Over the past 24 hours, Cupertino has played the hits from its iPhone-era anti-user, anti-business, anti-rule-of-law power trip. To recap: Apple sent a demand that the EU give up on DMA enforcement in a petulant and utterly misleading press release that mostly served to catalogue Apple's own failures to comply. Cupertino's kept astroturf outfit -- ACT | The App Association -- penned unhinged misinformation for consumption by US regulatory types (h/t Damien Geradin). The EC then called Apple's bluff. Make no mistake about what's going on: Apple is claiming that the EU is forcing Apple to adopt interpretations of the DMA that no other party has, which the EC itself has not backed, and which are "forcing" Apple to avoid shipping features in the EU. Or, put another way, Apple wants to launder the consequences of its own anticompetitive, anti-user choices through a credulous tech press. The goal is to frame regulators for Apple's own deeds. Lies by Any Other Name If this smells like bullshit, that's because it is. Apple tried similar ploys last year when it sprung a blatant attempt to kill PWAs on the EU as a price for having the temerity to regulate. The plan, it seemed then, was to adopt an exotic reading of the DMA and frame the EC for killing PWAs. What Apple's attempting now is even more brazen, particularly after 16+ months of serial non-compliance since the DMA came into force (h/t OWA). Remember that: Apple's browser, and by extension every iOS browser, fails on basic security and privacy controls, putting users at risk constantly. Apple serially misrepresents this situation to anyone who will ## Apply blur to iOS status bar in PWA DevFeed: [Apply blur to iOS status bar in PWA]() Original publisher: [Read original article]() Author: Stanko Published: 2025-04-11T00:00:00Z Content type: tutorial Language: en Sources: [Stanko Tadić]() Topics: [PWA](), [CSS](), [iOS](), [Web Development]() Tags: [background](), [code](), [css](), [ios](), [pwa]() ### AI overview This tutorial describes a CSS-based workaround for applying a blurred overlay to the iOS status bar area in a standalone PWA. The workaround uses a fixed element positioned outside the viewport and backdrop filtering, but an August 2026 update states that it no longer works on recent iOS versions because of WebKit changes. ### Source excerpt Update August 2026: This workaround no longer works on recent iOS versions. WebKit changed how standalone PWAs handle the status bar area. The fixed overlay positioned outside the viewport no longer renders under the status bar. I haven't found a workaround for this yet. If you find a solution please let me know. On my current project, I'm making a Progressive Web App (PWA) and I was really annoyed that the status bar on iOS was completely transparentAlthough the option is called black-translucent. When the content scrolls behind it, it blends with the status bar elements, and it doesn't look great. I couldn't find a native solution, so I tried using CSS instead. To my surprise, my idea worked on the first try. Here is my solution next to the default iOS status bar: After applying the CSS solutionDefault If you are impatient, feel free to jump to the demo. The solution # I think the solution is pretty simple - a fixed div that covers the status bar area and applies a blur effect to the background. But there's a catch, the div needs to be positioned outside of the viewport. Here is the code, HTML first:
and the CSS: body { --bg-color: 186 230 253; background-color: rgb(var(--bg-color)); } .statusbar { position: fixed; left: 0; right: 0; top: -80px; height: 80px; overflow: hidden; z-index: 100; } .statusbar::before { content: ''; position: absolute; left: 0; right: 0; top: 0; height: 150%; -webkit-backdrop-filter: blur(8px); backdrop-filter: blur(8px); background-color: rgb(var(--bg-color) / 0.6); } The CSS can be even simpler - we can remove the ::before element and just apply the blur to the .statusbar element itself. But this gives a nicer, more natural blur effect - check Josh Comeau's blog post in which he explains it in detail. Demo # You can check the live demo, just remember that you'll need an iOS device to see the effect. Not just that - for the effect to be visible, you'll need to add the app to your home screen. If you don't w ## A vanilla Rails stack is plenty DevFeed: [A vanilla Rails stack is plenty]() Original publisher: [Read original article]() Author: Jorge Manrubia Published: 2024-12-12T18:00:00Z Content type: opinion Language: en Sources: [37signals Dev]() Topics: [Rails](), [Hotwire](), [PWA](), [Ruby](), [Stimulus](), [Web Development]() Tags: [frameworks](), [hotwire](), [pwa](), [rails](), [ruby](), [stimulus](), [test]() ### AI overview The article recommends a vanilla Rails 8 stack with minimal Ruby and JavaScript dependencies, server-rendered views, Hotwire, import maps, standard CSS, relational-database-backed services, Minitest, PWAs, and Kamal deployment. It presents this approach as 37signals' balance of productivity, user experience, and long-term maintainability. ### Source excerpt Minimal dependencies, maximum productivity. Staying vanilla pays long term dividends for your Rails apps. ## Apple's iOS 17.4 Changes Threaten Progressive Web App Features in the EU DevFeed: [Apple's iOS 17.4 Changes Threaten Progressive Web App Features in the EU]() Original publisher: [Read original article]() Author: Alex Russell Published: 2024-02-25T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [PWA](), [iOS](), [Web](), [Mobile]() Tags: [browsers](), [competition](), [compliance](), [device-apis](), [dma](), [geofencing](), [ios](), [push-notifications](), [pwa](), [shortcuts](), [web](), [webdev]() ### AI overview The article argues that Apple's iOS 17.4 changes in the EU will restrict progressive web app capabilities, including storage, push notifications, app-like interfaces, and device APIs. It contrasts the threatened changes with continued PWA support on Windows and Android and frames them as a response to the EU Digital Markets Act. ### Source excerpt Update: OWA is out with an open letter appealing to Apple to do better. If you care about the future of the web, I encourage you to sign it, particularly if you live in the EU or build products for the common market. After weeks of confusion and chaos, Apple's plan to kneecap the web has crept into view, menacing a PWApocalypse as the March 6th deadline approaches for compliance with the EU's Digital Markets Act (DMA). The view from Cupertino. The DMA requires Apple to open the iPhone to competing app stores, and its lopsided proposal for "enabling" them is getting most of the press. But Apple knows it has native stores right where it wants them. Cupertino's noxious requirements will take years to litigate. Meanwhile, potential competitors are only that. But Cupertino can't delay the DMA's other mandate: real browsers, downloaded from Apple's own app store. Since it can't bar them outright, it's trying to raise costs on competitors and lower their potential to disrupt Apple's cozy monopoly. How? By geofencing browser choice and kneecapping web apps, all while gaslighting users about who is breaking their web apps. The immediate impact of iOS 17.4 in the EU will be broken apps and lost data, affecting schools, governments, startups, gamers, and anyone else with the temerity to look outside the one true app store for even a second. None of this is required by the DMA, as demonstrated by continuing presence of PWAs and the important features they enable on Windows and Android, both of which are in the same regulatory boat. The data loss will be catastrophic for many, as will the removal of foundational features. Here's what the landscape looks like today vs. what Apple is threatening: PWA Capability Windows Android iOS 17.3 iOS 17.4 App-like UI ✅ ✅ ✅ ❌ Settings Integration ✅ ✅ ✅ ❌ Reliable Storage ✅ ✅ ✅ ❌ Push Notifications ✅ ✅ ✅ ❌ Icon Badging ✅ ✅ ✅ ❌ Share-to PWA ✅ ✅ ❌ ❌ App Shortcuts ✅ ✅ ❌ ❌ Device APIs ✅ ✅ ❌ ❌ Apple's support for powerful web apps wasn't stellar, b ## Testing with Accessibility Scanner DevFeed: [Testing with Accessibility Scanner]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2024-02-16T03:38:54.088000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [Accessibility](), [Testing](), [Android](), [App](), [Google Play](), [Flutter](), [React Native](), [PWA]() Tags: [accessibility](), [accessibility-testing](), [android](), [flutter](), [google-play](), [pwa](), [react-native](), [test-automation](), [testing]() ### AI overview This tutorial explains how to use Accessibility Scanner for semi-automated accessibility testing of Android apps. The tool can identify issues involving content labels, touch target size, clickable items, and text and image contrast, but it cannot detect every accessibility problem, so manual testing remains necessary. It can be used with native Android apps, Flutter and React Native apps, and PWAs. ### Source excerpt When I talk about accessibility with Android developers, I often hear that some easy-to-use tests should automatically catch every possible accessibility issue. And I get it. That would make the whole topic of accessibility so much easier and straightforward. But the truth is that automated testing only catches some things. Studies suggest that the maximum percentage of caught accessibility issues is 40-50%. Deque, the company that develops the aXe accessibility tool, claims that the number is 57% in their study of automated accessibility tools. These studies have been performed with websites, but based on my experience, I have no reason to believe that the number would be higher on Android. So manual testing is always needed. But for that 40-57% (or whatever the exact number is on Android accessibility testing), there are some tools to use. One of them is Accessibility Scanner, and in this blog post, I'll discuss how to test your app with it. Let's start with what it is. What Is Accessibility Scanner Accessibility Scanner is a helpful tool for semi-automated accessibility testing. It's an app which can catch issues from the following categories: Content labels Touch target size Clickable items Text and image contrast It also suggests how to fix some of its findings and provides more info about the issues. However, it does not find every possible accessibility issue and thus does not guarantee the accessibility of your app. Manual testing is still needed. I keep saying this because I've seen these claims so many times that "Well, our test automation didn't find any accessibility issues, so our app is accessible". One great thing is that you can use Accessibility Scanner with any Android app - it can be a native Android app or built with cross-platform technologies such as Flutter or React Native. Or it can even be a PWA - Progressive Web App. Using Accessibility Scanner Installation To use the Accessibility Scanner, you must first download it from Google Play: Acces ## How competing browsers and Progressive Web Apps could challenge mobile app stores DevFeed: [How competing browsers and Progressive Web Apps could challenge mobile app stores]() Original publisher: [Read original article]() Author: Alex Russell Published: 2024-01-01T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [Mobile](), [Web app](), [browsers](), [Web]() Tags: [apis](), [app-store](), [apple](), [apps](), [browsers](), [competition](), [google](), [mobile](), [pwa](), [web-app](), [web-apps]() ### AI overview The article argues that regulatory pressure opening mobile ecosystems to competing browsers could enable Progressive Web Apps to become an alternative to native app stores. It says browser access to essential APIs, app portability, and web-based discovery could weaken Apple and Google's control over mobile distribution. ### Source excerpt The tech news is chockablock1 with antitrust rumblings and slow-motion happenings. Eagle-eyed press coverage, regulatory reports, and legal discovery have comprehensively documented the shady dealings of Apple and Google's app stores. Pressure for change has built to an unsustainable level. Something's gotta give. This is the backdrop to the biggest app store story nobody is writing about: on pain of steep fines, gatekeepers are opening up to competing browsers. This, in turn, will enable competitors to replace app stores with directories of Progressive Web Apps. Capable browsers that expose web app installation and powerful features to developers can kickstart app portability, breaking open the mobile duopoly. But you'd never know it reading Wired or The Verge. Contents The Buried Lede Disruption Disrupted Green Shoots A New Hope With shockingly few exceptions, coverage of app store regulation assumes the answer to crummy, extractive native app stores is other native app stores. This unexamined framing shapes hundreds of pieces covering regulatory events, including by web-friendly authors. The tech press almost universally fails to mention the web as a substitute for native apps and fail to inform readers of its potential to disrupt app stores. As Cory Doctorow observed: "An app is just a web-page wrapped in enough IP to make it a crime to defend yourself against corporate predation." The implication is clear: browsers unchained can do to mobile what the web did to desktop, where more than 70% of daily "jobs to be done" happen on the web. Replacing mobile app stores will look different than the web's path to desktop centrality, but the enablers are waiting in the wings. It has gone largely unreported that Progressive Web Apps (PWAs) have been held back by Apple and Google denying competing browsers access to essential APIs.2 Thankfully, regulators haven't been waiting on the press to explain the situation. Recent interventions into mobile ecosystems include require ## Safari 16.4 Adds Long-Delayed Web Platform Features DevFeed: [Safari 16.4 Adds Long-Delayed Web Platform Features]() Original publisher: [Read original article]() Author: Alex Russell Published: 2023-02-22T00:00:00Z Content type: opinion Language: en Sources: [Alex Russell]() Topics: [WebKit](), [browsers](), [Web platform](), [PWA]() Tags: [browsers](), [competition](), [components](), [compression](), [css](), [pwa](), [reporting](), [safari](), [wasm](), [webdev](), [webrtc]() ### AI overview This commentary reviews Safari 16.4's web-platform additions, including PWA, Web Components, CSS, Web Codecs, WASM SIMD, compression, reporting, Canvas, and WebRTC changes. It argues that many features arrived years after Chromium implementations and notes some improvements remain limited to macOS and iPadOS. ### Source excerpt If you're a web developer not living under a rock, you probably saw last week's big Safari 16.4 reveal. There's much to cheer, but we need to talk about why this mega-release is happening now, and what it means for the future. Contents WebKit's Roaring Twenties Good Things Come In Sixes What Changed? Headcount Is Destiny Early Innings But first, the list! WebKit's Roaring Twenties Apple's summary combines dozens of minor fixes with several big-ticket items. Here's an overview of the most notable features, prefixed with the year they shipped in Chromium: 2015: Web Push for iOS (but only for installed PWAs) 2020: PWA Badging API (for unread counts) and id support (making updates smoother) 2015: PWA installation for third-party browsers (but not to parity with "Smart Banners") A bevy of Web Components features, many of which Apple had held up in standards bodies for years1, including: 2019: Constructable Stylesheets (important for performance) 2019: Form participation and default ARIA role 2021: Declarative Shadow DOM for "SSR" Myriad small CSS improvements and animation fixes, but also: 2018: CSS Typed OM for faster styling from JavaScript 2020: CSS Custom Properties can now be animated 2019: