safari progressive web apps

PWA on iOS - Current Status & Limitations for Users [2024]

Apple couldn't stay behind anymore since PWAs are much more than a buzzword. What's the status now? Does iOS finally provide full support for PWAs? You'll find the answer below.

A QUICK SUMMARY – FOR THE BUSY ONES

TABLE OF CONTENTS

Introduction

Apple could care more about Progressive Web Apps, there’s no doubt about that. There’s not much documentation, the APIs are added slowly and most common things like Web App Manifest aren’t there for too long (at this point, I wonder if they will get there at all). On the other hand, PWAs are a thing . Maybe not as hyped as Machine Learning, but still, there’s a solid batch of those out there. And even Apple cannot ignore that fact forever.

PWA on iOS - Current status [2024]

As of 2023-2024, Progressive Web Apps (PWAs) on iOS have evolved significantly, offering a more native app-like experience. While they still face certain limitations on iOS compared to Android, recent updates have brought improvements.

Key updates and features of PWAs on iOS include:

1. Home screen addition ‍

Although Safari doesn't provide an automatic installation prompt, users can still add PWAs to their home screen. iOS 13 introduced a new Share Sheet design, making this process more intuitive with visual cues from the apple-touch-icon meta tag.

Recent improvements

• iOS 13 introduced changes to the Share Sheet, which affected how users add PWAs to their home screen. The design of the Share Sheet was updated, and it's recommended for developers to adjust their apps accordingly, particularly since Safari now uses the apple-touch-icon for the home screen icon, enhancing visual recognition for the user​​.

Limitations

• No automatic prompt : Unlike Android, iOS does not provide an automatic installation prompt from within Safari, so the process is less intuitive and relies on user action.
• Dependence on Safari's capabilities : The functionality and appearance of the PWA when launched from the home screen depend on Safari's capabilities, as it is the underlying browser for PWAs on iOS.
• User engagement : Adding a PWA to the home screen can significantly increase user engagement and retention, as it makes the app more accessible and convenient to use.
• Branding opportunity : The presence of the app icon on the home screen serves as a constant visual reminder of the app, reinforcing brand presence.

2. Dark mode support ‍

PWAs on iOS 13 can support Dark Mode, aligning with the wider adoption of this feature across platforms.

• Consistency with device settings : On iOS, PWAs that support Dark Mode can align with the system-wide Dark Mode settings of the device. This means the PWA can automatically switch between light and dark themes based on the user's system preferences.
• Implementation : Implementing Dark Mode in a PWA involves using CSS media queries to detect the preferred color scheme of the user's device. Developers can then apply different styles or themes based on this preference. The relevant CSS feature is prefers-color-scheme , which can be set to light or dark .

iOS-specific considerations

• Safari compatibility : For PWAs on iOS, Dark Mode support hinges on Safari's support for the prefers-color-scheme media query. Fortunately, recent versions of Safari on iOS do support this feature.
• Limitations : While PWAs can adapt their styles to match the Dark Mode setting, there are limitations in how far this integration goes. For example, it's not currently possible to change the app icon dynamically based on the theme.
• User preference respect : An important aspect of implementing Dark Mode is respecting the user's system settings, providing a seamless experience that matches their overall device usage.

3. Motion sensor API ‍

From iOS 13 onwards, apps need to ask for permission to use motion sensors like the accelerometer and gyroscope, a change aimed at enhancing user privacy.

• User permission : One of the key aspects of using the Motion Sensor API on iOS is the requirement for explicit user permission. Due to privacy concerns and potential misuse, Apple mandates that apps request and obtain user consent before accessing motion sensor data.
• iOS 13 changes : With iOS 13, there were significant changes to the Motion Sensor API usage. Previously, these sensors were freely accessible; however, the update introduced stricter controls, requiring apps to explicitly ask for permission​​.

Impact on PWAs

• Enhanced interactivity : For PWAs, the ability to use motion sensors opens up new possibilities for user interaction and engagement. It allows for more dynamic and responsive app designs, particularly in gaming, fitness apps, or any application where device movement can be a meaningful input.
• User privacy and security : The requirement for explicit permission aligns with broader trends towards user privacy and security. While it adds an extra step in the user experience, it ensures users are aware of and consent to the data being used.
• Cross-platform considerations : Developers need to be aware of how different platforms handle motion sensor access. While iOS requires explicit permission, the approach may differ on other platforms like Android.

4. iPadOS distinctions ‍

With the introduction of iPadOS, iPads now offer a desktop-class browser experience. However, PWAs on iOS 13 do not automatically adjust their layout when switching to/from Split Mode on iPads.

iPadOS, while sharing a foundation with iOS, brought specific changes that impact the behavior and capabilities of PWAs on iPad devices.

Desktop-class browsing experience ‍

One of the major shifts with iPadOS is the provision of a desktop-class browsing experience in Safari. This means that websites and PWAs are rendered in a way that is more akin to the desktop version rather than the mobile version. This change enhances usability and functionality, especially for complex web applications.

Development considerations

• Responsive design : Developers need to ensure their PWAs are responsive and adaptable to different screen sizes and modes, especially considering the variable rendering between full-screen and Split View modes.
• Testing across modes and devices : Thorough testing across various iPad models and configurations (including Split View and Slide Over) is crucial to ensure a consistent and user-friendly experience.
• Leveraging iPad features : Developers should consider how to best use iPad-specific features like the Apple Pencil or trackpad support to enhance the functionality and appeal of their PWAs.

5. Enhanced PWA installability and accessibility ‍

With updates like the "Add To Dock" button on desktop Safari and the "Add To Home Screen" button in in-app browsers using Safari View Controller, Apple has made installing and accessing PWAs more straightforward and user-friendly. These updates are part of a broader effort to improve the overall usability and appeal of PWAs on iOS platforms

• Streamlined addition to home screen : A key aspect of PWA installability on iOS is the ability for users to add these web apps to their home screen. While iOS traditionally hasn't provided an automatic installation prompt for PWAs like Android does, improvements in the ease of adding PWAs to the home screen have been noted. This involves using the Safari browser's share options to manually add the PWA to the home screen.
• Improved web app manifest support : The web app manifest is a crucial component for PWAs, as it defines the app's appearance when installed on the home screen, including icons, start URL, and display mode. Enhanced support for the web app manifest in Safari on iOS improves the overall installation and user experience, making PWAs feel more like native apps.
• Full-screen and standalone modes : Enhancements in full-screen and standalone modes for PWAs on iOS provide a more immersive user experience. When launched from the home screen, these PWAs can operate in a mode that's visually similar to native apps, without the typical browser UI elements.
• Increased storage quotas : Recent updates to Safari on iOS have included increases in the storage quotas assigned to web apps, including PWAs. This enhancement is significant for PWAs that need to store more data on the device, improving their functionality and user experience.
• Safari improvements : Ongoing updates to Safari, the primary browser for iOS, directly influence PWA capabilities. Enhanced support for modern web standards and APIs in Safari boosts the functionality and reliability of PWAs on iOS devices.
• Greater focus on security and privacy : With growing concerns around data security and user privacy, enhancements in these areas are also expected to continue, ensuring that PWAs offer a safe and secure experience for users.
• Accessibility enhancements : Improvements in accessibility features, ensuring PWAs are usable by people with various disabilities, are also a key focus. This includes better screen reader support, improved keyboard navigation, and adherence to WCAG guidelines.

6. Improved user interaction ‍

Features like Pointer Events allow PWAs to detect whether interactions are made via finger, Apple Pencil, or mouse, particularly useful on iPadOS.

• Touch and gesture controls : Enhanced support for touch and gesture controls is crucial for PWAs on iOS. This includes smooth scrolling, pinch-to-zoom, and swipe gestures that are expected in a native app experience. Improvements in these areas make PWAs feel more natural and intuitive to use on touch-screen devices.
• Responsive design and layouts : With diverse iOS devices, including various models of iPhones and iPads, responsive design is essential. This means PWAs need to adapt seamlessly to different screen sizes and orientations, providing an optimal user experience across all devices.
• Animation and transition effects : Smooth and appealing animations and transition effects can significantly enhance user interaction in PWAs. These visual cues not only make the app more engaging but also help in guiding users through the app’s functionality.
• Performance optimization : Fast loading times and efficient performance are key aspects of user interaction. This includes optimizing images, scripts, and leveraging browser caching to ensure the PWA is responsive and efficient.
• Improved offline capabilities : Enhancements in offline functionality, such as better data caching and offline content availability, contribute significantly to user interaction. Users expect a degree of functionality even when they are not connected to the internet.

7. Development and inspection tools ‍

PWAs are now inspectable on iOS, facilitating the development process.

Development tools for PWAs on iOS

• Web development IDEs : Integrated Development Environments (IDEs) like Visual Studio Code, Sublime Text, and Atom are popular for PWA development. They offer features like syntax highlighting, code completion, and extensions/plugins specifically useful for web development.
• Framework and library support : Frameworks like React, Angular, and Vue.js, along with libraries like Ionic, are instrumental in PWA development. They provide a structured way to build dynamic web applications that can function as PWAs.
• PWA builders : Tools like PWABuilder or PWA Studio by Magento offer simplified ways to create PWAs. They can generate service workers, manifests, and even package PWAs for different platforms, including iOS.
• Testing and debugging tools : Tools like Lighthouse (for performance and quality auditing), Chrome DevTools (for debugging), and BrowserStack (for cross-browser testing) are essential in the PWA development lifecycle.

Inspection tools for PWAs on iOS

• Safari developer tools : For PWAs on iOS, Safari's built-in developer tools are crucial. They allow developers to inspect, debug, and optimize their web applications for Safari on iOS devices.
• Remote debugging : Tools like Safari Web Inspector enable remote debugging of PWAs running on iOS devices. This is vital for testing and ensuring that the PWA behaves as expected on actual iOS hardware.
• Performance monitoring tools : Tools like Google's Lighthouse provide audits for performance, accessibility, progressive web apps, SEO, and more, offering valuable insights for optimizing PWAs for iOS.
• Service worker testing tools : Since service workers are a core component of PWAs, tools that facilitate testing and debugging of service workers are essential. This includes checking offline capabilities, caching strategies, and background sync functionality.

8. Background running and app switcher integration ‍

PWAs on iOS now have improved background running capabilities. They can run in the background and reflect their state in the App Switcher, similar to native apps. This development, although still subject to certain restrictions, marks a significant step towards offering a more native app-like experience

Background running in PWAs on iOS

Limited background execution ‍

Traditionally, PWAs and web apps on iOS have had limited capabilities in running in the background compared to native apps. This is due to the restrictions iOS places on background processes to conserve battery life and maintain performance.

Service Workers ‍

Service workers, a core technology behind PWAs, do run in the background, but their functionality is mainly focused on caching and push notifications (where supported). This enables some level of offline functionality and content updating in the background.

Recent enhancements ‍

There have been improvements in how PWAs handle background tasks on iOS. For instance, more recent versions of iOS started to allow some form of background processing for web apps, but with certain limitations and conditions, especially regarding timers and resource management​​.

App Switcher integration

Enhanced User Experience

Integration with the iOS app switcher is crucial for a seamless user experience. It allows users to view and switch between apps, including PWAs, as they would with native applications.

App state preservation ‍

For a PWA to be practical and user-friendly, it should maintain its state when a user switches to another app and then returns. This means that the PWA should resume where the user left off, without reloading or losing progress.

Visual representation ‍

In the app switcher, the PWA should ideally have a representative preview and icon, making it easily recognizable to the user. This visual representation is typically handled by the PWA's manifest settings and how the app is coded to behave in multitasking environments.

PWA on iOS - Limitations for users

The current limitations for users of Progressive Web Apps (PWAs) on iOS include:

No push notifications ‍

One of the most significant limitations for PWAs on iOS is the lack of support for push notifications. This impacts the ability of PWAs to engage users proactively, which is a key feature in many native apps.

Installation process ‍

Unlike native apps, PWAs don't have an automatic installation prompt in Safari. Users must manually add PWAs to their home screen, which may not be as intuitive as the installation process for native apps from the App Store.

Limited interaction with device features ‍

Certain device features and sensors may not be fully accessible or supported in PWAs on iOS. For example, while geolocation is supported, other functionalities like USB and Bluetooth connectivity are limited.

Variable performance across devices ‍

The performance and behavior of PWAs can vary across different iOS devices, particularly when considering the diverse capabilities and specifications of iPhones and iPads.

Limited offline capabilities ‍

While PWAs can work offline, their capabilities in this mode might be limited compared to native apps. The extent of offline functionality depends on how the PWA is designed and what data it caches.

App store discoverability ‍

While it's possible to submit PWAs to the App Store, they need to offer more than just a repackaged website. This can create a hurdle for PWA developers looking to leverage the App Store for discoverability.

Browser dependency ‍

PWAs on iOS rely heavily on Safari's capabilities and limitations, as it's the primary browser used for PWAs on Apple devices. Any limitations in Safari directly impact the capabilities of PWAs.

Limited support for advanced web features ‍

Safari's slower adoption of new web standards can limit the functionality of PWAs on iOS. For instance, features like Web Bluetooth or advanced payment options may not be available.

User Experience inconsistencies ‍

There can be inconsistencies in the user experience when using PWAs on iOS, especially when comparing them with their native app counterparts or their performance on other platforms like Android.

App state management ‍

Issues with managing the app state and layout changes, especially in the context of iPadOS and its Split Mode, can affect the usability of PWAs.

<span class="colorbox1" fs-test-element="box1"><p>Read also: Legacy Application Modernization Roadmap - a Step-by-Step Guide. Feel like the software in your company is no longer effective and has become a development blocker? That could mean it's time for a major update!</p></span>

Want to build a Progressive Web App? Here's what to consider

Advantages of building a pwa for ios.

• Broader reach and accessibility : PWAs can be easily accessed via a web browser, without the need for downloading from an app store. This can expand your app's reach to a wider audience.
• Reduced development costs : Developing a PWA can be more cost-effective than creating a native app, especially if you aim to support multiple platforms. You can use a single codebase for both iOS and Android, reducing development and maintenance costs​​.
• Improved performance and features : Recent advancements in PWAs, such as the addition of push notifications, enhanced offline capabilities, and background running, make them more competitive with native apps in terms of functionality​​​​.
• Ease of updating : PWAs can be updated more easily than native apps. Updates are deployed on the server side, eliminating the need for users to download updates from the App Store.

Considerations and challenges

• User Experience : While PWAs have improved significantly, there may still be some gaps in user experience compared to native apps, especially in terms of advanced features and integration with iOS-specific functionalities.
• App store presence : PWAs are not distributed through the App Store, which can be a significant channel for user discovery and trust. Depending on your target audience, not being on the App Store could be a limitation.
• Limited access to iOS features : PWAs may not have access to all iOS features and capabilities that native apps do, such as certain hardware integrations and advanced APIs.
• Variable performance across devices : PWAs can behave differently across various iOS devices, depending on factors like browser capabilities and hardware specifications.

Tips for building a PWA for iOS

• Focus on performance : Ensure your PWA is optimized for performance, especially on mobile devices. This includes fast loading times, efficient use of data, and smooth animations.
• Design for mobile-first : Prioritize a responsive, mobile-first design to provide a seamless experience on iOS devices.
• Test extensively : Thoroughly test your PWA on multiple iOS devices and browsers to identify and fix any compatibility or performance issues.
• Leverage latest web capabilities : Stay updated with the latest web technologies and standards to enhance the capabilities of your PWA.
• Consider user engagement strategies : Since PWAs don't support all native features, think creatively about user engagement strategies. For example, consider alternative methods for push notifications if they are crucial for your app.
• Prepare for offline use : Implement service workers for offline support, which is a key feature of PWAs.

<span class="colorbox1" fs-test-element="box1"><p>Read also: DORA Metrics: 4 Ways to Measure Software Delivery Performance . Improved processes and fast, stable delivery ﹣that’s what you get after starting to measure your team’s performance with DORA metrics. Learn how each of the metrics works and set the path to boosting your team’s performance and business results.</p></span>

Progressive Web Apps + iOS – A slow evolution

As you can see, things are changing slowly. Even if they don’t say it out loud, Apple has moved a bit closer to Progressive Web Apps. While the development of Progressive Web Apps for iOS is still more difficult than for the Android-based phones, it gets better over time. And there’s no doubt your business can still benefit from PWAs. Even on iOS.

Our company invests time in Progressive Web Apps by developing and popularizing them. If you’re more interested in this topic, let’s stay in touch.

Frequently Asked Questions

Our promise

Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.

A serial entrepreneur, passionate R&D engineer, with 15 years of experience in the tech industry.

Software development enthusiast with 6 years of professional experience in the tech industry.

Popular this month

Get smarter in engineering and leadership in less than 60 seconds.

Join 300+ founders and engineering leaders, and get a weekly newsletter that takes our CEO 5-6 hours to prepare.

previous article in this collection

It's the first one.

next article in this collection

It's the last one.

Use Safari web apps on Mac

Starting with macOS Sonoma, you can use Safari to save any webpage as a web app, so that you can use it independently of Safari. Web apps offer a streamlined, app-like experience and easy access from the Dock.

How does a web app differ from a webpage?

How to create a web app from a webpage, how to change web app settings, how to use notifications with a web app, how to delete a web app.

When you use a webpage as a web app, it looks and behaves just like it does in Safari. Yet the experience of using a web app differs in several ways.

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. In this way, it keeps your browsing separate, similar to using a Safari profile . What you do in a web app stays in the web app.

A web app can have any name or icon that you want.

For websites that send notifications, the web app's icon in the Dock can show the number of unread notifications.

In all other ways, a web app works like any other app. You can even add it as a login item so that it opens automatically when you log in .

Requires macOS Sonoma or later

In Safari, open the webpage that you want to use as a web app.

Type the name that you want to use for the web app, then click Add. The web app is saved to the Applications folder of your home folder, and you can open it from the Dock, Launchpad, or Spotlight.

Open the web app, click the app's name in the menu bar, then choose Settings from the menu.

Application Name: Type a new name for the app.

Application URL: Type a new URL for the app, or click Set to Current Page.

Icon: Click the icon shown, then choose a new image from the file dialog that opens. That image becomes the new icon for your web app.

Show navigation controls: Choose whether the toolbar shows the back button, forward button, app name, and Share button.

Show color in title bar: Choose whether to allow the color of the title bar adapt to the color of the website.

From the Privacy tab, you can open Privacy & Security settings or clear the website's data, including cookies and caches.

If a website is designed to send you notifications about new or updated site content, it asks for your permission to do so. If you click Allow when prompted, those notifications appear on the lock screen and in Notification Center. Web apps support an additional notifications feature: The number of unread notifications appears as a red badge on the app's icon in the Dock.

To use this feature, respond to the website's notifications request in the web app, not in Safari. The web app then appears in Notifications settings: Choose Apple menu  > System Settings, click Notifications in the sidebar, then select the web app from the list of applications on the right. Web apps are listed as the name of the web app, not the URL of the website.

Web apps are saved to the Applications folder of your home folder. To delete a web app, open your home folder, such as by choosing Go > Home from the menu bar in the Finder. Then open the Applications folder and drag the web app to the Trash.

Explore Apple Support Community

Find what’s been asked and answered by Apple customers.

Contact Apple Support

Need more help? Save time by starting your support request online and we'll connect you to an expert.

What are Progressive Web Apps? PWA Guide for Beginners

Progressive Web Apps (PWAs) are simply installable web applications – websites that you can install on your device, much like you would install an app from an app store.

They bring together the best parts of using a website (easy to access, no need to install anything) with the great features of mobile apps (fast, can work offline), offering a high-quality user experience.

The core of a PWA's usefulness lies in the offline-first approach, where applications are designed to function seamlessly without a constant internet connection. This means you can still use these apps even when your internet is slow or not available, and makes PWAs very user-friendly and accessible, even where an internet connection is not always reliable.

5 Reasons to Use a PWA Instead of a Native app

Progressive Web Apps (PWAs) are reshaping the landscape of digital interaction. They offer a hybrid experience that combines the best features of web and mobile apps.

Let's delve deeper into why PWAs are often a superior choice compared to native apps:

1. Speed and Ease of Installation

PWAs eliminate the lengthy download and installation process typical of native apps. You can access a PWA as swiftly as you'd load a web page, making it as straightforward as bookmarking your favorite site – no waiting for downloads or navigating through app stores.

Consider Twitter Lite, a PWA version of the popular social media platform, which offers the full Twitter experience without the need to wait for a separate app download.

2. Minimal Storage Requirements

One of the most significant advantages of PWAs is their minimal storage requirements. Since they primarily store data online, much like cloud services, they occupy significantly less space on a user’s device.

This feature is particularly beneficial for users with limited device storage or expensive data plans. For example, Pinterest’s PWA takes up less space than its native counterpart but still provides a rich, engaging user experience.

3. Reliable Offline Performance

A PWA's ability to function offline is like having a good book downloaded to your e-reader, ready to enjoy even when you're out of range of a good signal.

PWAs can function effectively even in areas with poor or no internet connectivity, using cached data from previous online activities. This ensures that users have uninterrupted access to essential features.

A notable example is the Starbucks PWA, which allows customers to browse the menu and customize orders, regardless of their internet connection for a consistent user experience.

4. Cost-Effective Development and Cross-Device Compatibility

Developing a PWA can be more cost-effective than building native apps for various platforms. This unified approach not only saves significant development time and resources but also simplifies maintenance and updates.

Businesses like Uber have leveraged PWAs to provide a seamless user experience across all devices without the need for multiple native apps.

5. Automatic Updates and Push Notifications

PWAs update themselves seamlessly, much like a web page loading the latest content each time it’s visited. Users always have access to the most current version of the app without going through the process of manual updates. This feature ensures that users are not hindered by outdated versions, a common issue with native apps.

For instance, Google Maps’ PWA automatically incorporates the latest features and improvements without user intervention. In addition to staying current, PWAs can engage users with push notifications, just like native apps, keeping them informed and involved without the need for a visit to the app store.

PWA Core Concepts

To fully grasp the potential and functionality of Progressive Web Apps, it's essential to understand their foundational components. These core concepts not only define the structure and behavior of PWAs but also distinguish them from traditional web applications.

Service Workers: The Backbone of PWAs

Service workers are scripts that run in the background, separate from your web page. They act as a proxy between the web application and the network.

Think of service workers as behind-the-scenes helpers for your web app. Their main job is to manage how your app talks to the internet.

They can save important parts of your app on the user's device, which means your app can work even when there's no internet. They're also in charge of quietly updating app content and can send notifications, just like a native app on your phone.

The App Manifest: Your PWA's Identity

The web app manifest is a JSON file which is essential because it tells the user's device how your app should look and behave.

It's like your app's ID card – it includes the app's name, the icons it uses, the first page it should open, and how it should display (like in full screen). This file makes your web app feel more like a regular app, allowing users to 'install' it on their home screen.

Caching: The Key to Offline Functionality

Effective caching is vital for a robust offline experience. Caching is like your app's memory. It stores important parts of your app so they can be quickly loaded later, even if there's no internet. It's crucial for making your app work offline.

There are different ways to handle caching, such as cache-first (where the app checks the cache before the internet), network-first (the opposite), and stale-while-revalidate (a mix of both). The choice depends on what your app does and what kind of information it handles, affecting how your app stores and retrieves its data.

Overview of Building a PWA

Building a Progressive Web App (PWA) might sound complex, but it's quite manageable when you break it down into steps. In this article, I'll give you an overview of the process – and in my next tutorial, I'll go into the process in more detail.

1. Start with a Basic Webpage:

Create a simple website using HTML for structure, CSS for style, and JavaScript for functionality.

2. Create a Manifest File:

In the manifest file, write down your app's name, the icons it uses, and the first page it should open. This makes your website act more like an app you can install.

3. Set Up a Service Worker:

In your main JavaScript file, add a service worker. This is a special script that works separately from your website.

The service worker's job is to handle how your app stores and retrieves data, especially for offline use.

Following these steps will help you build a simple PWA that users can install and use, even when they're offline.

Real World Use Cases for PWAs

These real-world examples demonstrate the practical benefits and impact of offline-first strategies:

• Starbucks : Starbucks has a PWA that lets customers look at the menu and order drinks and food even when they're offline. This not only makes the experience better for customers but also helps increase sales and customer interaction with the brand, as they can order anytime, anywhere.
• Khan academy : Khan Academy, a well-known educational site, has a PWA allowing students to download and access lessons and courses without an internet connection. This feature is particularly helpful for those in areas with unreliable internet, ensuring uninterrupted learning. Just like the Starbucks PWA, Khan Academy's use of this technology improves the user experience, making education more accessible and flexible.
• Trivago : Trivago, a popular hotel search engine, developed a PWA to enhance user experience, especially for travelers with unstable internet connections. The PWA allows users to browse hotel deals and information offline, making trip planning more flexible and accessible. This has led to increased user engagement and higher conversion rates, as travelers can continue interacting with the app even in areas with poor connectivity.
• Forbes : Forbes, a leading global media company, launched a PWA to improve the mobile experience for its readers. The PWA significantly reduced loading times and allowed offline reading of articles. This innovation not only enhanced user engagement but also resulted in a noticeable increase in readership and time spent on the site. The Forbes PWA demonstrates how media outlets can leverage offline-first strategies to reach and retain a wider audience, regardless of their internet connectivity.

PWAs are changing the game in web development, bringing features we usually see in native apps to the web.

They offer a blend of the accessibility of web applications with the engaging user experience of native apps. They represent a forward-thinking solution for businesses and developers looking to maximize reach and functionality while minimizing costs and complexity.

PWAs aren't just a passing trend – they're the next big thing in how we make and use web apps. By focusing on working offline, PWAs provide a more reliable and user-friendly experience.

Whether you're just curious or ready to start building, the following resources remain great places to begin exploring the possibilities of offline-first web applications.

• Google's PWA Checklist
• MDN Web Docs on Service Workers
• Web.dev for PWA tutorials

As a self-taught developer, I'm here to teach beginners what I wish I knew and how I wish I knew it when starting out.

If you read this far, thank the author to show them you care. Say Thanks

Learn to code for free. freeCodeCamp's open source curriculum has helped more than 40,000 people get jobs as developers. Get started

DEV Community

Posted on Jun 6, 2023

Safari 17 Beta: A Game Changer for PWAs on MacOS

Safari 17 Beta is the latest version of Apple's web browser, which was released on June 5, 2023. It includes many new features and improvements for web developers, especially for those who create Progressive Web Apps (PWAs).

If you are not familiar with PWA, PWAs are web applications that offer a native app-like experience to users. They can be installed on various devices, including MacOS, and can work offline, send push notifications, and access device features.

In this blog post, I will highlight some of the new WebKit features that Safari 17 Beta supports for PWAs.

New WebKit Features for PWAs

• Web Share API Level 2 : This API allows PWAs to share files with other apps on the device, such as photos, videos, or documents. It also supports sharing multiple files at once.
• Web App Manifest : This is a JSON file that describes a PWA, such as its name, icons, start URL, display mode, and more. Safari 17 Beta supports more manifest properties than before, such as categories , description , and screenshots .
• Web App Banner : This is a prompt that appears on Safari when a user visits a PWA that can be installed on the device. Safari 17 Beta improves the appearance and behavior of the banner, making it more consistent with native app banners.
• Service Workers : These are scripts that run in the background and enable PWAs to work offline, sync data, send push notifications, and more. Safari 17 Beta improves the performance and reliability of service workers, and adds support for some new APIs, such as CacheStorage and Background Sync .
• Web Push API : This API allows PWAs to send push notifications to users even when they are not using the app. Safari 17 Beta adds support for silent push notifications, which can be used to update the app's content or state without alerting the user.

Advantages of PWAs for Developers

PWAs offer many advantages for developers, and on MacOS right now, as well. Some of them are:

• They are easier and cheaper to develop and maintain than native apps, as they use web technologies and standards.
• They can reach a wider audience, as they are compatible with different browsers and devices.
• They can leverage the features and performance of Safari, which is the default browser on MacOS and supports many PWA capabilities.
• They can provide a seamless user experience, as they can adapt to different screen sizes and orientations, work offline, and update automatically.

PWAs are a great way to create engaging and reliable web applications that can run on MacOS and other platforms. If you want to learn more about PWAs, you can check out this guide from Google.

Are you interested in learning GitHub but don't know where to start? Try my course on LinkedIn Learning: Learning GitHub .

Thanks for reading this post, I hope you found it interesting!

Feel free to follow me to get notified when new articles are out 🙂

Emanuele Bartolesi Follow

Top comments (4).

Templates let you quickly answer FAQs or store snippets for re-use.

• Location Frankfurt
• Education BSc Advanced Technology @ University of Twente
• Work Founder @ Webshift
• Joined Feb 28, 2023

I am really thinking about this a lot and could image the future with only PWA‘s where users do not install native apps on their devices anymore (at least that is what I would like for mobile).

What do you think? Will the PWA be able to fully replace native apps at some point?

• Email [email protected]
• Location Zurich, Switzerland
• Pronouns he/him
• Work Microsoft 365 Architect
• Joined Jun 22, 2018

I am a big fan of PWA since the beginning... but I don't think they replace native apps completely... (but I would like 😀)

• Joined Aug 17, 2023

There's no documented support for Web App Install Banners in Safari / iOS 17.

Here's the WWDC announcement: developer.apple.com/videos/play/ww...

and the beta release notes: developer.apple.com/documentation/...

• Joined Jun 9, 2023

I’m sorry but I think Apple didn’t create web app banner !

Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink .

Hide child comments as well

For further actions, you may consider blocking this person and/or reporting abuse

NodeJS 22 is Live

Emmanuel Eneche - Apr 25

Free Project Management Software

Kajal Shrama - Apr 25

Tips and Strategies for Hiring Top ReactJS Developers in 2024: Expert Guide

Hire Laravel Developers - Apr 25

10 VS Code extensions for maximum frontend development productivity

Opajobi Oyegoke - Apr 24

We're a place where coders share, stay up-to-date and grow their careers.

Progressive Web Apps on iOS

This is a beginner's guide about creating PWAs for iOS including custom icons, splash screens, safe area and dark mode support.

How to make a PWA for iOS?

A progressive web application is just a special kind of website, that can look and behave like a native iOS app. In order to build a PWA, first we're going to create a regular website using SwiftHtml . We can start with a regular executable Swift package with the following dependencies.

As you can see we're going to use the vapor Vapor library to serve our HTML site. If you don't know much about Vapor let's just say that it is a web application framework, which can be used to build server side Swift applications, it's a pretty amazing tool I have a beginner's guide post about it.

Of course we're going to need some components for rendering views using SwiftHtml, you can use the source snippets from my previous article , but here it is again how the SwiftHtml-based template engine should look like. You should read my other article if you want to know more about it. 🤓

We're also going to need an index template for our main HTML document. Since we're using a Swift DSL to write HTML code we don't have to worry too much about mistyping a tag, the compiler will protect us and helps to maintain a completely valid HTML structure.

Finally we can simply render the bootstrap our Vapor server instance, register our route handler and render the index template inside the main entry point of our Swift package by using the previously defined template helper methods on the Request object.

It is just that easy to setup and bootstrap a fully working web server that is capable of rendering a HTML document using the power of Swift and the Vapor framework. If you run the app you should be able to see a working website by visiting the http://localhost:8080/ address.

Turning a website into a real iOS PWA

Now if we want to transform our website into a standalone PWA, we have to provide a link a special web app manifest file inside the head section of the index template.

Meta tags vs manifest.json

Seems like Apple follows kind of a strange route if it comes to PWA support. They have quite a history of "thinking outside of the box", this mindset applies to progressive web apps on iOS, since they don't tend to follow the standards at all. For Android devices you could create a manifest.json file with some predefined keys and you'd be just fine with your PWA. On the other hand Apple nowadays prefers various HTML meta tags instead of the web manifest format.

Personally I don't like this approach, because your HTML code will be bloated with all the PWA related stuff (as you'll see this is going to happen if it comes to launch screen images) and I believe it's better to separate these kind of things, but hey it's Apple, they can't be wrong, right? 😅

Anyways, let me show you how to support various PWA features on iOS.

Enabling standalone app mode

The very first few keys that we'd like to add to the index template has the apple-mobile-web-app-capable name and you should use the "yes" string as content. This will indicate that the app should run in full-screen mode, otherwise it's going to be displayed using Safari just like a regular site.

We should change the hostname of the server and listen on the 0.0.0.0 address, this way if your phone is on the same local WiFi network you should be able to reach your web server directly.

You can find out your local IP address by typing the following command into the Terminal app.

Just use that IP address and go to the http://[ip-address]:8080/ website using your iOS device, then you should be able to add your website to your home screen as a bookmark. Just tap the Share icon using Safari and select the Add to Home Screen menu item from the list. On the new screen tap the Add button on the top right corner, this will create a new icon on your home screen as a bookmark to your page. Optionally, you can provide a custom name for the bookmark. ☺️

Since we've added the meta tag, if you touch the newly created icon it should open the webpage as a standalone app (without using the browser). Of course the app is still just a website rendered using a web view. The status bar won't match the white background and it has no custom icon or splash screen yet, but we're going to fix those issues right now. 📱

Custom name and icon

To provide a custom name we just have to add a new meta tag, fortunately the SwiftHtml library has predefined enums for all the Apple related meta names, so you don't have to type that much. The icon situation is a bit more difficult, since we have to add a bunch of size variants.

As you can see icons are referenced by using the Link tag, using the Apple touch icon rel attribute. The default icon without the sizes attribute can be a 192x192 pixel image, plus I'm providing some smaller sizes by using a for loop here. We also need to serve these icon files by using Vapor, that's why we're going to alter the configuration file and enable the FileFiddleware.

By adding the FileMiddleware to the app with the public directory path configuration your server app is able to serve static files from the Public directory. Feel free to create it and place the app icons under the Public/img/apple/icons folder. If you are running the server from the command line you'll be fine, but if you are using Xcode you have to specify a custom working directory for Vapor , this will allow the system to look up the public files from the right place.

Your custom icons won't show up if you are using a self-signed certificate.

Build and run the server and try to bookmark your page again using your phone. When you see the add bookmark page you should be able to validate that the app now uses the predefined Hello PWA name and the image preview should show the custom icon file instead of a screenshot of the page.

Proper status bar color for iOS PWAs

Long story short, there is a great article on CSS-Tricks about the most recent version of Safari and how it handles various theme colors on different platforms. It's a great article, you should definitely read it, but in most of the cases you won't need this much info, but you simply want to support light and dark mode for your progressive web app. That's what I'm going to show you here.

For light mode we're going to use a white background color and for dark mode we use black. We're also going to link a new style.css file so we can change the background of the site and the font color according to the current color scheme. First, the new meta tags to support theme colors both for light and dark mode.

Inside the style CSS file we can use a media query to detect the preferred color scheme, just like we did it for the .themeColor meta tag using SwiftHtml.

That's it, now the status bar should use the same color as your main background. Try to switch between dark and light mode and make sure everything works, there is a cool PWA demo project here with different colors for each mode if you want to double check the code. ✅

Splash screen support

Hint: it's ridiculous. Splash screens on iOS are problematic. Even native apps tend to cache the wrong splash screen or won't render PNG files properly, now if it comes to PWAs this isn't necessary better. I was able to provide splash screen images for my app, but it took me quite a while and switching between dark and light mode is totally broken (as far as I know it). 😅

In order to cover every single device screen size , you have to add lots of linked splash images to your markup. It's so ugly I even had to create a bunch of extension methods to my index template.

Now I can simply add the splashTags() call into the head section, but I'm not sure if the result is something I can totally agree with. Here, take a look at the end of this tutorial about splash screens , the code required to support iOS splash screens is very long and I haven't even told you about the 40 different image files that you'll need. People are literally using PWA asset generators to reduce the time needed to generate these kind of pictures, because it's quite out of control. 💩

Safe area & the notch

A special topic I'd like to talk about is the safe area support and the notch. I can highly recommend to read this article on CSS-Tricks about The Notch and CSS first, but the main trick is that we can use four environmental variables in CSS to set proper margin and padding values.

First we have to change the viewport meta tag and extend our page beyond the safe area. This can be done by using the viewport-fit cover value. Inside the body of the template we're going to add a header and a footer section, those areas will have custom background colors and fill the screen.

Except the background color we don't want other content to flow outside the safe area, so we can define a new CSS class and place some margins on it based on the environment. Also we can safely use the calc CSS function if we want to add some extra value to the environment.

It looks nice, but what if we'd like to use custom styles for the PWA version only?

Detecting standalone mode

If you want to use the display mode media query in your CSS file we have to add a manifest file to our PWA. Yep, that's right, I've mentioned before that Apple prefers to use meta tags and links, but if you want to use a CSS media query to check if the app runs in a standalone mode you'll have to create a web manifest.json file with the following contents.

Next you have to provide a link to the manifest file inside the template file.

In the CSS file now you can use the display-mode selector to check if the app is running in a standalone mode, you can even combine these selectors and detect standalone mode and dark mode using a single query. Media queries are pretty useful. 😍

You can turn the header into a sticky section by using the position: sticky attribute. I usually prefer to follow the iOS style when the website is presented to the end-user as a standalone app and I keep the original theme colors for the web only.

Don't forget to rebuild the backend server, before you test your app. Since we've made some meta changes you might have to delete the PWA bookmark and install it again to make things work. ⚠️

As you can see building good-looking progressive web apps for iOS is quite tricky, especially if it comes to the metadata madness that Apple created. Anyway, I hope this tutorial will help you to build better PWAs for the iOS platform. This is just the tip of the iceberg, we haven't talked about JavaScript at all, but maybe I'll come back with that topic in a new tutorial later on.

Share this article Thank you. 🙏

Get the Practical Server Side Swift book

Swift on the server is an amazing new opportunity to build fast, safe and scalable backend apps. Write your very first web-based application by using your favorite programming language. Learn how to build a modular blog engine using the latest version of the Vapor 4 framework. This book will help you to design and create modern APIs that'll allow you to share code between the server side and iOS. Start becoming a full-stack Swift developer.

Tibor Bödecs

CEO @ Binary Birds

Server side Swift enthusiast, book author, content creator.

Progressive Web Applications (PWA) on iOS 13 & 14 Provide a Rich Channel to Reach Customers Despite the Platform Limitations

Last Updated - Sat Jan 09 2021

Progressive Web Apps are everywhere, literally. Every major browser and platform has support for service workers and are using the web manifest file in some form or fashion.

This includes Apple's iPhones and iPads using iOS Safari.

Do Progressive Web Apps (PWA) work on iOS?

The catch is Apple's implementation is somewhat restrained compared to other platforms, especially when compared to Chrome and Edge.

Stop right there!!!!

THIS DOES NOT MEAN Progressive Web Apps don't work on iOS, they do and they are great!

The limitations are limited at this time. Almost every feature you want n your application is supported by Safari on iPhone.

Safari supports service worker caching. It does not support push notifications or background sync. Safari does use parts of the web manifest file.

There is a 50MB service worker cache limit, but that does not mean you cannot persist more data. IndexedDB allows you to store a few GBs of data. It really depends, like other platforms, on the available space.

There is no native add to homescreen prompt, but other than Chrome and Edge no one else does either.Unused web apps that have not been added to the homescreen will have their cached assets purged after 7 days. This is less of a problem than most think.

That may sound like a lot is missing, but it is not as bad as it sounds.

A great feature of the web platform is the ability to progressively enhance (the progressive part of PWA) and polyfil many features when a browser does not support them natively.

To be fair Apple was really the first platform to support the concept of a web app. When they released the iPhone the first apps were HTML5 based.

As such they provided a way to manually add a website to the homescreen and launch in a full screen experience.

They kept the process simple, just sort of hidden.

Unfortunately, they never matured the experience. And service workers did not exist at the time.

Today that has changed, but like I mentioned, the iOS PWA experience is a little different than other platforms, but very serviceable. It is also improving with each Safari update.

I should note that Apple is not a fan of the term 'Progressive Web App' or 'PWA'. Instead they prefer to call them HTML Apps or Web Apps.

This is merely semantics. There is no official PWA specification, it is merely a term created to describe a modern breed of websites.

They are keen to point out that progressive web application is a term created by a Googler and initially promoted by Google. To be fair they are right.

The main takeaway from this article is why PWAs are a great choice to target iPhone and iPad users for your application. In fact Apple will probably tell you that too if you pay attention to the direction they are heading.

For now we know how Safari on iOS 13 supports modern web APIs. We are still waiting to see what updates and features will be added to iOS 14 and the next version of Safari.

Does Apple Even Want Progressive Web Apps?

Current pwa implementations have more success on ios than before, consumers are burned out on apps, pwa technology supported on ios, ios progressive web app cache capacity, does ios support push notifications, background sync on ios, ios pwa quirks.

Many wonder if Apple wants PWAs to succeed or even work on iOS and MacOS. The reason is progressive web apps compete with the AppStore.

The reality is Apple is more than willing to see apps leave the store and migrate to the web . They are doing a great job themselves of running off many brands from the AppStore as it is.

Recently they denied Hey.com's app update because they were not using Apple's in app payment services. Instead BaseCamp chose to use traditional merchant card services that charge 1-3% or 10% of Apple's 30% fee.

Spotify has filed a lawsuit against Apple's app store practices .

And then there is the Epic battle with Apple over Fortnite .

If you don't believe me, you should see app owners contacting me to create a PWA for them. Some because their apps were removed. Others because they fear removal or rejection.

By removing apps and making others 'uncomfortable' they are recommending to use the web.

Seriously, they even use that language:

"if the App Store model and guidelines are not best for your app or business idea that’s okay, we provide Safari for a great web experience too."

Clients have confirmed these Apple notices suggesting they move to the web.

So does Apple care about AppStore success? Yes, they do, but at the same time it is not their priority, selling hardware at massive margins is the goal.

Sure the AppStore generates billions in sales each year and yes Apple takes a 30% cut. But as I highlighted in the Spotify vs Apple article, much of that revenue is from a handful of apps.

I have created a litmus test to determine if your app should be native or a progressive web app: Does your app sell iPhones?

If the answer is no, then don't waste your time and money on a native app. Apple does not want you anyway.

But if you want to invest $5000-50000 on an iOS app to see if they will accept it be my guest. I am still here to make it available to everyone for less.😁

When you take the time and create a proper progressive web app you are taking the time to create a better user experience. This better UX ultimately means your customers are happier with your online experience and of course engage at higher rates.

Even with platform limitations a consistent message from brands using PWA is their iOS engagement numbers increase.

It is sort of real-world application of the 'a rising tide raises all ships' saying.

There are many PWA examples out there reporting across the board improvements to key performance indicators.

AliExpress saw an 82% increase in iOS conversions, the Washington Post saw nearly a 5x increase in user engagement and MyNet saw a 19% page view increase on iOS just to name a few sites and stats.

Even with the current limitations making a better web user experience means you will reap rewards on iOS. And eventually Apple will catch up to the competition. At least to where Chrome, Edge and other browsers are today. When those missing features light up your customers will just experience them.

Oh, and if you think having a presence in the App Store will make you successful, think again.

We know about 4 years ago consumers reached app fatigue and stopped downloading or installing apps.

Yes, apps are still downloaded, but for the most part it is the 4 or 5 apps the consumer uses the most and only when they get a new device.

For the most part these apps are Facebook. I mean Facebook, Messenger, WhatsApp and Instagram, all Facebook apps.

When you read over 80% of a consumer's screen time is in an app, almost all that time is using social media. The other apps are video, which honestly can be progressive web apps without degrading experience. I mean Netflix is phasing their apps out.

If you study mobile app consumption 99% of apps are rarely downloaded. If an app is downloaded 90% of the downloads are used once before the app is removed.

Most apps are eventually abandoned and after a while purged from the platform due to lack of interest by device owners.

Unfortunately, many still fear or falsely assume they need to have their brand in the AppStore to be found.

Are you Facebook? Are you Fortnite?

If you answered no, then most likely no one is looking for your app in the store.

They are searching for your products and services in search engines. While SEO ~ is not simple, it can provide piles of targeted traffic to your site.

Once you get them on your site you can easily remarket and engage them in your sales funnel. By the time you get them to the purchase point they don’t want to go through the 6-8 steps to download your app to their phone.

If you have a progressive web app they have already ‘installed’ the core plumbing required for your PWA experience. You just need to get them to formally install or add your PWA to their device homescreen. A far easier task than downloading an app.

I frequently read articles about limitations of progressive web apps on iOS. Most are a bit naïve and paint a much bleaker picture about capabilities than reality.

Sure, there are limitations with Apple Safari due to its laggardness in supporting modern web standards. The current joke among web developers is Safari is the new Internet Explorer.

Of course, Internet Explorer is Microsoft's old, long deprecated browser that had so much disdain passed its way. It lagged behind its rivals FireFox and then Chrome.

Today most browsers support the same modern web standards and capabilities. Most except Safari, which always seems to be at least 2-3 years behind the competition.

The story is not as bad as that sounds. The boundaries can be handled if you plan for them. And if and when Apple ships support for a feature it can just light up in your application.

I have built applications that deal with iOS limits. Even with the lack of push notifications you can fall back to SMS. Sure USB and Bluetooth are not supported, but the demand for these APIs is very niche.

Today's modern standards have elevated the web platform to almost even parity with native counterparts. Sure there are a few edge cases where the web does not have a viable specification. But these missing features tend to have rare implementations even with native apps.

So yeah, right now the web does not offer Geo-Fencing, but I know very few applications that leverage this technology anyway, so I am not that concerned.

As for progressive web applications, what they are and what they can do that mere websites can do is well, no different.

To be classified as a progressive web application there are 3 criteria:

• Register a Service Worker with a fetch event handler
• Valid web manifest file with a minimal homescreen icon set

That is the bare minimum, but of course there is more to the puzzle.

PWAs are just websites, but they differ from a common website in that they have those three technical features but are designed to just plain be better.

Ambiguous and anecdotal as you can get. Yes, it is the eye of the beholder if you will.

The thing about a progressive web app that makes them stand out can often be just taking advantage of platform APIs like Geolocation , biometric authentication, the payment request API, Bluetooth, Camera, Web Share and many other user experience APIs available today.

When you really boil it down, Progressive Web Applications deliver a superior user experience. This user experience gracefully degrades when the browser does not support a modern feature.

In other words, the web site provides the best possible experience the browser allows.

I find it frustrating how many of these features are assumed to not be supported or worse brand new when they have existed for years.

For example, Geolocation has been supported by all browsers for a decade.

Biometric authentication, i.e. fingerprint or facial recognition enjoys support among most browsers via the WebAuthn specification . For the record iOS Safari has shipped support .

As far as PWA support on iOS the only core thing missing is the support of the web manifest. The file that provides enhanced meta data about the web site to the browser. It facilitates the add to homescreen experience .

Apple has shipped limit support, or really partial use, for this feature. It is not a deal breaker.

That's right, a web manifest file is not required for a great user experience, and you CAN add a progressive web app to the iPhone homescreen.

iOS has had add to homescreen support on iOS since the first iPhone shipped. So rather than divert engineering resources to support this standard they focused more on catching up in the service worker space.

I think this was the right choice.

You can still include Safari's mobile-web-app-capable and touch-icon META tags in your page's HEAD without causing issues with other browsers on other platforms.

This is what is great about the web. It is very forgiving and you can add modern functionality to a website and gracefully degrade when the browser does not support a feature.

I am sure Apple will eventually support web manifest files, but for now I would prefer they focus on adding service worker features, other platform APIs and fixing bugs.

Right now, the biggest progressive web application limitation on iOS is the small cache capacity quota Apple imposes, ~50MB.

Again this is not a deal breaker for most web sites. If you need 50MB to cache your site's assets you really should revisit your application's code and caching logic.

I am working on a few projects right now that do need to cache more than 50MB, but they need to cache audio and video files. For these applications the media files can be looked at more as data rather than a network addressable resource, which is what service worker cache is really designed.

In these cases, the audio and video files can be cached using blob storage in IndexedDB, a browser database with much more available capacity. In fact, the IndexedDB capacity on iOS seems to be almost unlimited in the tests I have run, up to 1GB.

Let me put this in perspective, I have built several large web sites with 100s of unique web pages and support assets and cached everything (excluding images) in localStorage. localStorage is typically limited to 5MB, so you get the idea.

IndexedDB access is available within your service worker, where localStorage is not. This does mean you can intercept the network request to the more 'binary' responses and cache them in IDB in the service worker and sort of build a special caching abstraction layer to make managing their caching easier across different browsers.

Of course, even with Android and other mobile devices disk space is a premium. This is why Apple chose to limit service worker cache to 50MB. A 32GB phone does not have much storage once you factor in the operating system and other mandatory platform apps.

So, don't expect to be able to cache a high definition, large screen formatted movie. But audio books, podcasts and properly formatted videos should have no problem being cached on iOS.

So don't let the lack of service worker cache capacity stop you from using a Progressive Web App.

At this point in time Apple's iPhone and iPads do not support  native push notifications . You can gracefully fallback to SMS notifications. Both provide high engagement levels with minimal costs.

I am asked about this more than any other web platform feature, at least it feels that way.

Even though I get frustrated with Safari's limitations it does support most modern web APIs needed to make great user experiences.

This does not mean I am not asked by clients and potential clients if they can do some pretty crazy stuff. Most of the request are often not even possible with a native app. Others violate Apple, Google and Microsoft's terms, which means native apps are rejected and the stakeholders are hoping they can use the web to achieve their goals.

As for background sync this is a bummer. However, this is not supported by browsers outside the Chromium ecosystem at the moment.

You can create your own synchronization support by leveraging offline detection and IndexedDB. The main drawback here is the user will need to open your web app in order for your fallback to work. You cannot trigger the service worker to just execute in the background when the network returns, which is the main feature of the service worker background sync API.

Another quirk PWAs have on iOS is being purged. This can be very problematic.

Recently Apple has addressed this problem. When a PWA is added to the user's homescreen the platform will retained cached assets for an indefinite period. Even more incentive too push users to install your PWA.

Because Apple assumes space on its devices is cramped, they aggressively throw unused items overboard to free up disk space. Add to homescreen seems to be a signal to the operating system the assets are more important, therefor they are retained.

If your PWA or any website for that matter, goes unused for a few days (we think it is roughly 14 days, it is not documented) the device will remove all cached assets associated with the origin. This includes IndexedDB, service worker cache, localStorage, etc. Again, this concerns sites not added to the homescreen.

This has made relying on cached assets a bit of an issue. The real problem lies when a user might try to load your PWA while they are offline for the first time in a month. The PWA won’t work, even if your service worker pre-caches all the required files for offline functionality.

You should also build in a check for purged cached assets in your service worker. I think just important is you should also include some sort of notice for your users if they expect the application to function offline.

Let them know the content they are caching now may not be available if unused for a long period of time. If they anticipate needing your app for offline usage try to plan ahead.

In theory your cached content could be purge by other browsers too, but they are not as aggressive. Providing a message to set user expectations can go a long way to curb potential issues down the road.

Sure there are limitations to for Progressive Web Apps on iOS, but they are not deal breakers. Many of the most requested features have at least some form of fallback solution. It may not provide a comparable user experience the native web platform API or service offers.

For most mobile apps, especially on iOS, are not a good channel to promote and engage your customers. App installs are rare for most apps. Development, maintenance and marketing for these apps is also very expensive.

The web, progressive web apps specially, are available to everyone in every browser on every device. Plus they can be affordably marketed using organic search, PPC and traditional marketing funnels.

Many brands have reported improved customer engagement stats after upgrading their websites to a PWA, especially on iOS. Most likely your brand will too.

We use cookies to give you the best experience possible. By continuing, we'll assume you're cool with our cookie policy.

Install Love2Dev for quick, easy access from your homescreen or start menu.

• Kevin Farrugia
• Aug 11, 2016

A Beginner’s Guide To Progressive Web Apps

• 18 min read
• Mobile , Apps , AMP , Service Workers
• Share on Twitter ,  LinkedIn

About The Author

Kevin Farrugia is a co-founder at Incredible Web , a web & mobile application development company based in Malta, EU; that delivers industry-leading … More about Kevin ↬

Email Newsletter

Weekly tips on front-end & UX . Trusted by 200,000+ folks.

Progressive web apps could be the next big thing for the mobile web. Originally proposed by Google in 2015, they have already attracted a lot of attention because of the relative ease of development and the almost instant wins for the application’s user experience.

A progressive web application takes advantage of the latest technologies to combine the best of web and mobile apps . Think of it as a website built using web technologies but that acts and feels like an app. Recent advancements in the browser and in the availability of service workers and in the Cache and Push APIs have enabled web developers to allow users to install web apps to their home screen, receive push notifications and even work offline.

Progressive web apps take advantage of the much larger web ecosystem, plugins and community and the relative ease of deploying and maintaining a website when compared to a native application in the respective app stores. For those of you who develop on both mobile and web, you’ll appreciate that a website can be built in less time, that an API does not need to be maintained with backwards-compatibility (all users will run the same version of your website’s code, unlike the version fragmentation of native apps) and that the app will generally be easier to deploy and maintain .

Why Progressive Web Apps?

A study has shown that, on average, an app loses 20% of its users for every step between the user’s first contact with the app and the user starting to use the app. A user must first find the app in an app store, download it, install it and then, finally, open it. When a user finds your progressive web app, they will be able to immediately start using it, eliminating the unnecessary downloading and installation stages. And when the user returns to the app, they will be prompted to install the app and upgrade to a full-screen experience.

However, a native app is definitely not all bad. Mobile applications with push notifications achieve up to three times more retention than their counterparts without push, and a user is three times more likely to reopen a mobile application than a website. In addition, a well-designed mobile application consumes less data and is much faster because some resources reside on the device.

A progressive web application takes advantage of a mobile app’s characteristics, resulting in improved user retention and performance, without the complications involved in maintaining a mobile application.

When should you build a progressive web app? Native is usually recommended for applications that you expect users to return to frequently, and a progressive web app is not any different. Flipkart uses a progressive web app for its popular e-commerce platform, Flipkart Lite, and SBB uses a progressive web app for its online check-in process, allowing users to access their tickets without an Internet connection.

When assessing whether your next application should be a progressive web app, a website or a native mobile application, first identify your users and the most important user actions. Being “progressive,” a progressive web app works in all browsers, and the experience is enhanced whenever the user’s browser is updated with new and improved features and APIs.

Thus, there is no compromise in the user experience with a progressive web app compared to a traditional website; however, you may have to decide what functionality to support offline, and you will have to facilitate navigation (remember that in standalone mode, the user does not have access to the back button). If your website already has an application-like interface, applying the concepts of progressive web apps will only make it better .

If certain features are required for critical user actions but are not yet available due to a lack of cross-browser support , then a native mobile application might be the better option, guaranteeing the same experience for all users.

Characteristics Of A Progressive Web App

Before we jump into the code, it is important to understand that progressive web apps have the following characteristics :

• Progressive . By definition, a progressive web app must work on any device and enhance progressively, taking advantage of any features available on the user’s device and browser.
• Discoverable . Because a progressive web app is a website, it should be discoverable in search engines. This is a major advantage over native applications, which still lag behind websites in searchability.
• Linkable . As another characteristic inherited from websites, a well-designed website should use the URI to indicate the current state of the application. This will enable the web app to retain or reload its state when the user bookmarks or shares the app’s URL.
• Responsive . A progressive web app’s UI must fit the device’s form factor and screen size.
• App-like . A progressive web app should look like a native app and be built on the application shell model, with minimal page refreshes.
• Connectivity-independent . It should work in areas of low connectivity or offline (our favorite characteristic).
• Re-engageable . Mobile app users are more likely to reuse their apps, and progressive web apps are intended to achieve the same goals through features such as push notifications.
• Installable . A progressive web app can be installed on the device’s home screen, making it readily available.
• Fresh . When new content is published and the user is connected to the Internet, that content should be made available in the app.
• Safe . Because a progressive web app has a more intimate user experience and because all network requests can be intercepted through service workers, it is imperative that the app be hosted over HTTPS to prevent man-in-the-middle attacks.

Let’s Code!

Our first progressive web app, Sky High, will simulate an airport’s arrivals schedule. The first time the user accesses our web app, we want to show them a list of upcoming flights, retrieved from an API. If the user does not have an Internet connection and they reload the web app, we want to show them the flight schedule as it was when they last downloaded it with a connection.

The first characteristic of a progressive web app is that it must work on all devices and must enhance on devices and browsers that allow it. Therefore, we’ve built our website using traditional HTML5 and with JavaScript that simulates the retrieval of data from a mock API. Throughout the application, we are using small bits of Knockout to handle our Model-View-ViewModel (MVVM) bindings — a lightweight JavaScript framework that allows us to bind our JavaScript models to our HTML views. We chose to use Knockout because it is relatively simple to understand and does not clutter the code; however you may replace this with any other framework, such as React or AngularJS.

Our website follows Google’s material design guidelines, a set of principles that guide design and interaction. Material design not only serves as a unified standard across applications and devices, but also gives design meaning. We’ve used material design for Sky High’s arrivals view to give our progressive web app that native-app look and feel.

Finally, we tested our app to make sure it is jank-free and that scrolling is silky-smooth. Jank-free rendering has been shown to improve user engagement. Aim for a rendering of 60 frames per second.

For this demo, we will retrieve a static JSON file, instead of a real API. This is merely to keep things simple. In the real world, you would query an API or use WebSockets.

The index.html file is relatively standard. We’ve created an HTML list and bound our View Model property arrivals to it using Knockout , through the attribute data-bind=“foreach: arrivals” . The View Model arrivals is declared in the page.js file below and exposed in the Page module. On our HTML page, for each item in the arrivals array, we’ve bound the title , status and time properties to the HTML view.

This page.js file exposes the Page module, which contains our ViewModel vm and two functions, hideOfflineWarning and showOfflineWarning . The View Model ViewModel is a simple JavaScript literal that will be used throughout the application. The property arrivals on the ViewModel is Knockout’s observableArray , which automatically binds our HTML to a JavaScript array, allowing us to push and pop items onto our array in JavaScript and automatically update the page’s HTML.

The functions hideOfflineWarning and showOfflineWarning enable the rest of our application to call these functions to update the page’s UI that displays whether we are connected online. The showOfflineWarning adds a class of loading to our arrivals-list HTML element to fade the list, and then it retrieves the HTML file offline.html through XHR. Assuming that the file has been retrieved successfully ( response.status === 200 ), we append this to our HTML. Of course, if we aren’t using service workers and the user is not connected to the Internet, then it would not be possible to retrieve offline.html , and so the user would see the browser’s offline page.

The business logic from where we retrieve the data from our API and bind it to our View Models and Views is found in arrivals.js and is standard MVVM functionality using Knockout. In the arrivals.js file, we simply initialize the services and View Models that we will be using throughout the application, and we expose a function — Arrivals.loadData() — that retrieves the data and binds it to the view model.

Web App Manifest

Let’s make our web app more app-like. A web app manifest file is a simple JSON file that follows the W3C’s specification . With it, it is possible to run the web app in full-screen mode as a standalone application, to assign an icon that will get displayed when the application is installed on the device, and to assign a theme and background color to the app. In addition, Chrome on Android will proactively suggest that the user install the web app, via a web app install banner . To display the installation prompt, your web app needs to:

• have a valid web app manifest file,
• be served over HTTPS,
• have a valid service worker registered,
• have been visited twice, with at least five minutes between each visit.

manifest.json

Let’s break down this manifest file:

• short_name is a human-readable name for the application. In Chrome for Android, this is also the name accompanying the icon on the home screen.
• name is also a human-readable name for the application and defines how the application will be listed.
• description provides a general description of the web application.
• icons defines an array of images of varying sizes that will serve as the application’s icon set. In Chrome for Android, the icon will be used on the splash screen, on the home screen and in the task switcher.
• start_url is the starting URL of the application.
• display defines the default display mode for the web application: fullscreen , standalone , minimal-ui or browser .
• orientation defines the default orientation for the web application: portrait or landscape .
• theme_color is the default theme color for the application. On Android, this is also used to color the status bar.
• background_color defines the background color of the web application. In Chrome, it also defines the background color of the splash screen.
• related_applications is not implemented in our example but is used to specify native application alternatives in the various app stores.

Add the manifest.json reference to the index.html file’s head tag:

Once a user has added the web app to their home screen, they will be able to re-engage with your application immediately from their device, without having to directly open the browser. You can see how this is much more than a web bookmark.

Add to Homescreen on Chrome for Android from Smashing Magazine on Vimeo .

Add to home screen in Chrome for Android

Service Workers

One of the more exciting aspects of progressive web apps is that they can work offline. Using service workers, it is possible to show data that was retrieved in previous sessions of the app (using IndexedDB ) or, alternatively, to show the application shell and inform the user that they are not connected to the Internet (the approach we’ve taken in this demo). Once the user reconnects, we can then retrieve the latest data from the server.

All of this is possible through service workers, which are event-driven scripts (written in JavaScript) that have access to domain-wide events, including network fetches. With them, we can cache all static resources, which could drastically reduce network requests and improve performance considerably, too.

Application Shell

The application shell is the minimum HTML, CSS and JavaScript required to power a user interface. A native mobile application includes the application shell as part of its distributable, whereas websites ordinarily request this over the network. Progressive web applications bridge this gap by placing the application shell’s resources and assets in the browser’s cache. In our Sky High application, we can see that our application shell consists of the top header bar, the fonts and any CSS required to render these elegantly.

To get started with service workers, we first need to create our service worker’s JavaScript file, sw.js , placed in the root directory.

Let’s look more closely at our service worker. First, we are setting a cacheName variable. This is used to determine whether any changes have been made to our cached assets. For this example, we will be using a static name, meaning that our assets will not change or require updating.

The install event fires during the installation phase of the service worker and will fire only once if the service worker is already installed. Therefore, refreshing the page will not trigger the installation phase again. During the installation phase, we are able to declare which assets will be cached. In our example above, we are caching one CSS file, two JavaScript files, our fonts file, our offline HTML template and, of course, the application root. self.skipWaiting() forces the waiting service worker to become active.

So far, we have declared our service worker, but before we see it kick into effect, we need to reference it in our JavaScript. In our application, we register it in main.js

We’ve also included two event listeners to check whether the session’s state has changed from online to offline or vice versa. The event handlers then call the different functions to retrieve the data through Arrivals.loadData() and to enable or disable the offline message through Page.showOfflineWarning and Page.hideOfflineWarning , respectively. Our application also checks whether the user is currently online, using navigator.onLine , and either retrieves the data or shows the offline warning accordingly. And in the last line of main.js , we apply the Knockout bindings to our View Model Page.vm .

If we load our application for the first time (with Chrome Developer Tools), we will see nothing new. However, upon reloading, we will see that a number of network resource have been retrieved from the service worker. This is our application shell.

Offline Test

A user running the application without an Internet connection (assuming that they have already been on the page) will simply result in the application shell and the offline warning being displayed — an improvement over Chrome’s prowling t-rex. Once the user has established a network connection, we disable the warning and retrieve the latest data.

The Guardian takes a particularly interesting approach when offline users access its website, providing a crossword puzzle:

Push Notifications

Push notifications allow users to opt in to timely updates from applications they trust, helping them to re-engage with the apps. Push notifications on the web allow you to engage with your audience even when the browser is closed.

The Push API is supported in Chrome, Opera and Samsung’s browser and is under development in Firefox and Microsoft Edge. Unfortunately, there is no indication that the feature will be implemented in Safari.

Performance

One of the easiest wins with service workers is that we can improve performance with little to no effort. Comparing our website to itself before service workers were implemented, before we were retrieving over 200 KB upon page load; that is now reduced to 13 KB. On a regular 3G network, the page would have taken 3.5 seconds to load; now it takes 500 milliseconds.

These performance improvements are drastic because the application itself is very small and has limited functionality. Nevertheless, through the correct use of caching, it is possible to significantly improve performance and perceived performance, especially for users in places with low-connectivity.

Google’s Chrome team has put together a tool for testing progressive web apps. Lighthouse runs in Node.js or as a Chrome plugin and can be found on GitHub, too.

To run a Lighthouse test, your website needs to be available online, meaning that you cannot test on localhost .

To start, download the npm package:

Once that’s installed, run Chrome (version 52 onwards):

The output of the Lighthouse run will be visible in the command line and will grade your website according to the progressive web app features and properties you have implemented — for example, whether you are using a manifest.json file or whether your page is available offline.

This article is merely an appetizer for progressive web apps. We could do a lot more to create that app-like experience users are looking for, whether by supporting push notifications with the Push API , making the app re-engageable, or using IndexedDB and background syncing to improve the offline experience.

Cross-Browser Support

These are still early days for progressive web apps, and cross-browser support is still limited, especially in Safari and Edge. However, Microsoft openly supports progressive web apps and should be implementing more features by the end of the year.

• Service workers and Cache API . Supported in Chrome, Firefox, Opera and Samsung’s browser. In development in Microsoft Edge, expected to be available by the end of 2016. Under consideration for Safari.
• Add to home screen . Supported in Chrome, Firefox, Opera, Android Browser and Samsung’s browser. Microsoft seems to indicate that progressive web apps will be available as store listings. No plans for Safari as of yet.
• Push API . Mostly supported in Chrome, Firefox, Opera and Samsung’s browser. In development in Microsoft Edge. No plans for Safari as of yet.

If more developers take advantage of the features offered by progressive web apps — which are relatively easy to implement and provide immediate rewards — then users will prefer consuming these web apps in supported browsers, hopefully convincing the other browser vendors to adapt.

Source Code

The entire source code for this tutorial is available in a Github repository , and the demo is available on GitHub Pages .

Further Reading

• The Building Blocks Of Progressive Web Apps
• Conversational Design Essentials: Tips For Building A Chatbot
• Building A First-Class App That Leverages Your Website
• Creating A Complete Web App In Foundation For Apps

Smashing Newsletter

Tips on front-end & UX, delivered weekly in your inbox. Just the things you can actually use.

Front-End & UX Workshops, Online

With practical takeaways, live sessions, video recordings and a friendly Q&A.

TypeScript in 50 Lessons

Everything TypeScript, with code walkthroughs and examples. And other printed books.

• Generative AI
• Office Suites
• Collaboration Software
• Productivity Software
• Augmented Reality
• Emerging Technology
• Remote Work
• Artificial Intelligence
• Operating Systems
• IT Leadership
• IT Management
• IT Operations
• Cloud Computing
• Computers and Peripherals
• Data Center
• Enterprise Applications
• Vendors and Providers
• Enterprise Buyer’s Guides
• United States
• Netherlands
• United Kingdom
• New Zealand
• Newsletters
• Foundry Careers
• Terms of Service
• Privacy Policy
• Cookie Policy
• Copyright Notice
• Member Preferences
• About AdChoices
• E-commerce Affiliate Relationships
• Your California Privacy Rights

Our Network

• Network World

The best progressive web apps for productivity

With chrome os, windows, mac, or even mobile, these standout pwas will help you get more done without any of the usual baggage..

Say the phrase “progressive web app” to most people — including tech-savvy professionals — and you’re bound to be met with a consistent reaction: the classic blank stare, probably followed by a period of awkward silence.

Progressive web apps  — or PWAs, as they’re often called — are one of the most promising app-related advancements of the past several years, but they’re still relatively uncommon, completely confusing, and consequently quite misunderstood. Part of that is an issue of branding: Plain and simple, “progressive web app” is a dreadfully clunky name that seems more intended for developers than the general public.

Part of it is consistency, as the capabilities of PWAs vary wildly from one program to the next. And part of it is presentation, as the method for finding and installing PWAs is anything but obvious, and there’s no great centralized storefront for browsing through available options or assessing their quality.

If you manage to track down the right programs for your purposes, though, progressive web apps can become an invaluable part of your productivity toolbox. The best PWAs provide fully capable, app-like interfaces that work offline and are virtually indistinguishable from their more traditional app counterparts. They’re lightweight, they update themselves automatically, and they work exactly the same way across most common computing platforms. They can be an important element of a Chrome OS setup, and they can be every bit as useful on a Windows, Mac, or Linux system and even on an Android or iOS device.

The trick is mostly just to find the blasted things and figure out which are actually worth your while. And today, we’re gonna break that all down.

What are progressive web apps?

First, a quick overview of what, exactly, a progressive web app even is — because as we’ve already established, it’s pretty darn confusing. The simplest way to think of a progressive web app is as a mix between a website and a locally installed program. A PWA connects to your browser and relies on regular web technologies, but it’s packaged in a way that makes it look and feel more like a traditional standalone app.

And when it’s done well, it can offer many of the same advantages a traditional local app would give you — in a setup that’s consistent across different device types and painless to manage and maintain.

How do you find and install a progressive web app?

This is where things get especially murky. Google is slowly starting to feature progressive web apps in the Play Store on Chromebooks, but the options are still few and far between (and also not labeled or searchable in any specific way). And while some third-party sites have popped up to fill the PWA virtual store void, those are generally a bit lackluster and bogged down with lots of low-quality silliness.

At this point, the only reliable way to see that a PWA is available on the desktop front is to visit the associated website and then look for either a special icon in the browser’s address bar — a monitor with a downward-facing arrow in Chrome or a series of three connected squares with a plus sign in Edge — or to open the browser’s main menu and look for an “Install” option while the site is open. That command will appear in the main three-dot menu within Chrome and within the “Apps” section of the main menu in Edge when it’s available.

Note that in cases where a service requires you to be signed in to use it, you may need to sign in first (or create an account and then sign in) before you’ll see the PWA installation prompt.

The option to install a progressive web app appears in two different places within Chrome, shown here, as well as within Microsoft’s Edge browser.

Firefox, curiously enough, no longer supports the PWA standard, and Safari has never supported it in its desktop incarnation.

The same basic concept will work on mobile, too, by looking in your browser’s main menu while viewing a site with PWA capabilities on your phone or tablet. On Android, Chrome will show an “Install app” option when the possibility exists, while Edge will simply say “Add to screen,” with no obvious indication of whether the resulting item will be a PWA or just a basic link to opening the site in the browser.

On iOS, only Safari supports PWA installation, and it, too, offers only a vague “Add to home screen” option with no indication of whether you’ll get a PWA or a basic web link when using it. (Told ya this was confusing!)

Regardless of the platform or device type, once you’ve found and installed a PWA, it’ll appear as an icon on your desktop, home screen, or wherever your operating system stores newly installed apps.

So with all of that out of the way, let’s move on to the productivity-oriented PWAs worth using — with a focus on apps that actually add something to the experience beyond giving you a glorified link to a website.

The best progressive web apps for tasks and notes

If you want a perfect example of what a progressive web app oughta be, look no further than Todoist. The exceptional list-making app (and my pick for one of the best organization-related apps on Android as well) offers a thoughtfully crafted PWA that looks, feels, and acts almost exactly like a regular local program.

Once it’s installed on your device, you’ll be able to view, manage, and adjust any existing tasks you’ve created and also create new tasks in a snappy, buffering-free interface that you’d never even realize is connected to a browser. And best of all, the app is fully offline-capable: Anytime you don’t have an active internet connection, you’ll see an icon letting you know you’re in offline mode and that any changes you make will be synced as soon as you’ve reconnected.

Todoist’s progressive web app looks and works exactly like a traditional program, even when you’re offline.

The one catch is that you have to be sure to open the app in advance, while you still have an active connection, so it can sync and load up all the most current info initially.

Google Keep

Somewhat surprisingly, Keep is currently the sole Google service that’s offered as a genuinely capable and worthwhile progressive web app at this point. Unlike its Google-family cousins, Keep acts like an actual program and allows you to search, view, and edit existing notes and also take new notes even when you’re offline. And with advanced features ranging from time- and location-based reminders to tagging, color-coding, and even A.I.-driven image-to-text conversions, it’s a standout option that’s absolutely advantageous in this form.

The Google Keep PWA is great for note-taking on any device.

For more basic note-taking purposes, the aptly named Simplenote does an equally impressive job of offering an app-like experience in the progressive web app structure. Simplenote — which is also exceptional for no-frills note-taking on Android — gives you a clean and easy-to-navigate interface for taking, editing, and viewing your notes. It has support for tags as well as checklists but none of the clutter-creating extras most other note-taking platforms provide.

And just like Keep and Todoist, it’s fully capable of offline work, so long as you remember to open the app while you’re still connected so it can perform that initial sync.

For basic, no-frills note-taking, the Simplenote progressive web app is a notch above the rest.

The best progressive web apps for multimedia work

When you need Photoshop-caliber editing without the actual Photoshop software, Photopea is an admirable alternative that relies entirely on web-based technology. Once you’ve installed the Photopea PWA, you’ll be able to do everything from optimizing photos to adjusting illustrations and creating complex, multilayered graphic files.

No matter what kind of computer you’re using, you can accomplish advanced graphic work with or without an active internet connection with the Photopea progressive web app.

Photopea is fully offline-capable.

For bulk resizing and adjusting of images — like when you have a stack of photos you want to bring down to a consistent width and maybe also add a border or watermark onto prior to uploading to your company’s website — the delightfully simple PhotoStack is exactly the progressive web app you need.

PhotoStack lets you drag in any number of images and then specify what it is you want to do with ’em. In addition to the aforementioned possibilities, you can change their file format to a consistent standard, adjust their image quality to make their sizes smaller, create a pattern to give them consistent names, and remove any potentially identifying EXIF data stored within them.

Bulk image adjustments are easy with the simple yet capable PhotoStack progressive web app.

Once you get the parameters set the way you want, it’s just a couple quick clicks, and all of your images will be adjusted exactly as you specified — whether you’re online or off.

Chrome Canvas

If basic image markup is all you need, Google’s super-simple Chrome Canvas app is the tool for the job. Chrome Canvas is all about scribbling over images — and that’s pretty much it.

Google’s Chrome Canvas app is ideal for basic image markup and scribbling.

When you’re on the go and needing a quick way to circle or highlight something in a photo or maybe erase part of an image before sharing it into Slack, Chrome Canvas is the fastest and easiest way to do it. And just like all the other progressive web apps we’ve covered, it works as well offline as it does while connected to the internet.

One more progressive web app worth pondering

Speaking of simple single-purpose programs, the final progressive web app in our collection is one that’s as narrowly focused as can be. It’s called 5217, and it’s based on the productivity theory that the best way to structure your work day is in ongoing cycles of 52 minutes on, 17 minutes off.

With that in mind, 5217 gives you a timer to continuously count down both parts of that pattern. Every time 52 minutes go by, the app will alert you that it’s time for a break. After 17 minutes, it’ll let you know that it’s time to get back to work again, whether you’re online or off.

The 5217 progressive web app keeps you on time and on track.

Fair warning, though: You may find yourself tempted to work for 17 minutes each hour and then break for 52. Resist that temptation — or at the very least, save it for Friday.

Don’t worry: Your secret’s safe with me.

Related content

The end of non-compete agreements is a tech job earthquake, meta opens its mixed-reality horizon os to other headset makers, a crafty new android notification power-up, microsoft uses its genai leverage against china — prelude to a tech cold war, from our editors straight to your inbox.

JR Raphael has been covering Android and ChromeOS since their earliest days. You can ingest his advice and insight in his long-standing Android Intelligence column at Computerworld and get even more tasty tech knowledge with his free Android Intelligence newsletter at The Intelligence .

More from this author

The best android app drawer enhancement you’ll ever make, how workona can transform your team collaboration, 5 advanced tricks for google’s circle to search on android, most popular authors.

Show me more

How to fix icloud sync in seconds.

Gen Z workers pick genAI over managers for career advice

Adobe’s new Firefly Image 3 adds genAI features to Photoshop

Why the world will be wearing more technology in the future

Is AR/VR set for another growth spurt? | Ep. 143

Voice cloning, song creation via AI gets even scarier

More tech layoffs as AI takes hold

Is AR/VR set for another growth spurt?

• Skip to main content
• Skip to search
• Skip to select language
• Sign up for free
• English (US)

Making PWAs installable

One of the defining aspects of a PWA is that it can be promoted by the browser for installation on the device. Once installed, a PWA appears to users as a platform-specific app, a permanent feature of their device which they can launch directly from the operating system like any other app.

We can summarize this as follows:

• Supporting browsers promote the PWA to the user for installation on the device.
• The PWA can be installed like a platform-specific app, and can customize the install process.
• Once installed, the PWA gets an app icon on the device, alongside platform-specific apps.
• Once installed, the PWA can be launched as a standalone app, rather than a website in a browser.

We'll discuss each of these features in this guide. First, though, we'll discuss the requirements that a web app must meet for it to be promoted for installation.

Installability

For a web app to be promoted for installation by a supporting browser, it needs to meet some technical requirements. We can consider these the minimum requirements for a web app to be a PWA.

The web app manifest

A web app manifest is a JSON file that tells the browser how the PWA should appear and behave on the device. For a web app to be a PWA it must be installable, and for it to be installable it must include a manifest.

The manifest is included using a <link> element in the app's HTML:

If the PWA has more than one page, every page must reference the manifest in this way.

The manifest contains a single JSON object containing a collection of members, each of which defines some aspect of the PWA's appearance or behavior. Here's a rather minimal manifest, containing just two members: "name" and "icons" .

Required manifest members

Chromium-based browsers, including Google Chrome, Samsung Internet, and Microsoft Edge, require that the manifest includes the following members:

• display and/or display_override

For a full description of every member, see the web app manifest reference documentation .

Secure context

For a web app to be installable, it must be served in a secure context . This usually means that it must be served over HTTPS. Local resources, such as localhost, 127.0.0.1 and file:// are also considered secure.

Service worker

For a web app to be installable, it must include a service worker with a fetch event handler that provides a basic offline experience.

Installation from an app store

Users expect to find apps in the app store for their platform, like the Google Play Store or the Apple App Store.

If your app meets the installability prerequisites, you can package it and distribute it through app stores. The process is specific to each app store:

• How to publish a PWA to the Google Play Store
• How to publish a PWA to the Microsoft Store
• How to publish a PWA to the Meta Quest Store

The PWABuilder is a tool to simplify the process of packaging and publishing a PWA for various app stores. It supports the Google Play Store, Microsoft Store, Meta Quest Store, and iOS App Store.

If you have added your app to the app store, users can install it from there, just like a platform-specific app.

Installation from the web

When a supporting browser determines that a web app meets the installability criteria described earlier, it will promote the app to the user for installation. The user will be offered the chance to install the app. This means you can distribute your PWA as a website, making it discoverable through web search, and also distribute it in app stores, so users can find it there.

This is a great example of the way PWAs can offer you the best of both worlds. It's also a good example of how progressive enhancement works with PWAs: if a user encounters your PWA on the web, using a browser that can't install it, they can use it just like a normal website.

The UI for installing a PWA from the web varies from one browser to another, and from one platform to another. For example, a browser might include an "Install" icon in the URL bar when the user navigates to the page:

When the user selects the icon, the browser displays a prompt asking if they want to install the PWA, and if they accept, the PWA is installed.

The prompt displays the name and icon for the PWA, taken from the name and icons manifest members.

Browser support

Support for PWA installation promotion from the web varies by browser and by platform.

On desktop:

• Firefox and Safari do not support installing PWAs on any desktop operating systems. See Installing sites as apps , below.
• Chrome and Edge support installing PWAs on Linux, Windows, macOS, and Chromebooks.
• On Android, Firefox, Chrome, Edge, Opera, and Samsung Internet Browser all support installing PWAs.
• On iOS 16.3 and earlier, PWAs can only be installed with Safari.
• On iOS 16.4 and later, PWAs can be installed from the Share menu in Safari, Chrome, Edge, Firefox, and Orion.

Installing sites as apps

Safari for desktop and mobile, and Edge for desktop also support installing any website as an app. However, this is not specific to PWA because the site doesn't need to meet the installability criteria described in this guide, and because the browser doesn't proactively promote the site for installation.

Triggering the install prompt

A PWA can provide its own in-page UI for the user to open the install prompt, instead of relying on the UI provided by the browser by default. This enables a PWA to provide some context and a reason for the user to install the PWA, and can help make the install user flow easier to discover.

This technique relies on the beforeinstallprompt event, which is fired on the global Window object as soon as the browser has determined that the PWA is installable. This event has a prompt() method that shows the install prompt. So a PWA can:

• add its own "Install" button
• listen for the beforeinstallprompt event
• cancel the event's default behavior by calling preventDefault()
• in the event handler for its own "Install" button, call prompt() .

This is not supported on iOS.

Customizing the installation prompt

By default, the install prompt contains the name and icon for the PWA. If you provide values for the description and screenshots manifest members, then, on Android only, these values will be shown in the install prompt, giving the user extra context and motivation to install the PWA.

The screenshot below shows what the install prompt for the PWAmp demo looks like on Google Chrome, running on Android:

Launching the app

Once the PWA is installed, its icon is shown on the device alongside any other apps that the user has installed, and clicking the icon launches the app.

You can use the display manifest member to control the display mode : that is, how the PWA appears when it is launched. In particular:

• "standalone" indicates that the PWA should look and feel like a platform-specific application, with no browser UI elements
• "browser" indicates that the PWA should be opened as a new browser tab or window, just like a normal website.

If the browser does not support a given display mode, display will fall back to a supported display mode according to a predefined sequence. The display_override enables you to redefine the fallback sequence.

Do PWAs Work on iPhone? The State of Progressive Web Apps for iOS

• PWA iOS support was removed and then reinstated for EU users in early 2024.
• Regardless of region, Progressive Web Apps only work with the Safari browser, and have certain limitations compared to native iOS apps.
• It’s still worthwhile to build a PWA for your website, but for best results, consider converting your site to a native app as well.

In this article, we’re going to break down how (or if ) Progressive Web Apps (PWAs) work on iOS devices.

PWAs are a great way to serve a better website experience to visitors on mobile, who account for more than half of all web users today. 

Progressive Web Apps allow you to deliver an app-like experience without the huge expense of native app development. However, as you’ll see, PWAs can’t quite measure up to native apps , especially for iPhone users.

Keep reading for everything you need to know about PWAs on the iOS platform.

Current Status of PWAs on iOS

Progressive Web Apps do work on iOS, though with a few differentiating points. Here’s an up-to-date summary of the state of iOS PWAs.

Apple removed (then restored) PWA support in the EU

The big news regarding iOS PWAs is Apple’s stance on PWAs for EU iOS users.

In February 2024, news came out that Apple had removed support for Progressive Web Apps in the EU.

This was confirmed on their official website documentation . Under the FAQ heading “Why don’t users in the EU have access to Home Screen web apps?”, Apple confirmed that it was a conscious decision (not a bug), to remove PWA functionality in the EU to help comply with the newly passed Digital Markets Act (DMA).

However, Apple has since posted an update to this message, saying that support for Home Screen apps (PWAs) is being brought back:

“Previously, Apple announced plans to remove the Home Screen web apps capability in the EU as part of our efforts to comply with the DMA. The need to remove the capability was informed by the complex security and privacy concerns associated with web apps to support alternative browser engines that would require building a new integration architecture that does not currently exist in iOS. We have received requests to continue to offer support for Home Screen web apps in iOS, therefore we will continue to offer the existing Home Screen web apps capability in the EU. This support means Home Screen web apps continue to be built directly on WebKit and its security architecture, and align with the security and privacy model for native apps on iOS.”

Source: developer.apple.com

iOS PWAs only work with Safari

To run and install a PWA on an iPhone, the user must use the Safari browser.

While this won’t affect most iPhone users (it’s estimated that around 80% of iOS users use Safari as their default browser), it does lower overall usability of PWAs on iPhones.

No automatic install prompt on iOS devices

Android PWAs can prompt visitors to install the app on their home screen, with a banner that automatically appears when the user lands on the site, which features a button that lets users install the app with one click.

This is not possible on Safari, however. Users need to do this manually. And while it only takes a couple of extra clicks, it significantly decreases visibility for awareness of the fact that the website can be installed on the user’s home screen, and thus will result in significantly fewer installs.

You can use push notifications (with limitations)

Push notifications are possible with PWAs on iOS 16.4 or later. There are a couple of hoops to jump through, however.

You will need to set up an opt-in functionality to get the user’s permission to send push notifications from your Progressive Web App. 

You’ll also need to configure some things (primarily service workers and integration with Apple's Push API) in the backend code of your Progressive Web App to handle push notifications (and permissions received from users).

See more in Apple’s official developer documentation .

Limited data usage, device integration and offline functionality

Progressive Web Apps on iOS offer something closer to an app-like experience, but have a few limitations in terms of how they work offline, and how they integrate with the user’s device, compared to native apps and PWAs on Android.

These include:

• Storage of offline files limited to 50mb.
• Limited USB/Bluetooth functionality.
• No access to advanced payment integrations (Apple Pay does work).
• No Face ID, Touch ID, ARKit (Augmented Reality).
• No background sync.
• No integration with Siri.

No App Store distribution

You can’t publish your Progressive Web App in Apple’s App Store. Generally speaking, users will need to come to your website and install the PWA manually, by saving it to their home screen.

There are workarounds for this - you can use a service (or write code yourself) to create the framework of a native Swift app around your PWA, and publish that app to the App Store. But Apple’s guidelines for apps published in the App Store are relatively strict, so if you choose to go this route, you may find it takes a lot of work to make your PWA app store compliant.

How to Add a PWA to Home Screen on iOS

Though lacking the visibility and one-click install capability of Progressive Web Apps on Android, installing a PWA on iOS is fairly quick and straightforward.

First, the user will need to visit the PWA website. From there, they can add it to their home screen with a three-step process:

• Click the “share” button at the bottom of the screen.
• Scroll down and click “Add to Home Screen”.
• Confirm by clicking “Add”.

This will add a launcher icon to the home screen of the user's mobile device. When the user taps on the app icon, the PWA will open.

Check out this video for a quick walkthrough:

Is Building a PWA Worth It?

Summing up what we’ve discussed above, Progressive Web Apps on iOS are usable, but come with a range of limitations.

• Support for PWAs was briefly removed for iOS users in the EU, and while it was subsequently restored, it’s a sign that Apple is not totally in favor of PWAs.
• PWAs on iOS only work with Safari.
• iOS PWAs don’t have automatic install prompts, have limited offline capabilities and integration with device features, and can’t be published on the App Store.
• Web push notifications are possible with iOS PWAs, but take extra work to set up, and come with stricter permission requirements from users.

So, with all those limitations considered, is it worth it to build a Progressive Web App?

In our opinion, yes . A Progressive Web App still provides a better user experience, particularly on mobile, than a standard responsive website.

The ability for a user to add it to their home screen is a plus, as is the ability to send push notifications, even if these features are limited compared to native apps and Progressive Web Apps on Android.

Building the necessary components for a Progressive Web App is not a massive undertaking, so unlocking modest benefits for iPhone users (on top of more extensive functionality for users on Android) is likely to be worth it.

Related: 5 Benefits of Building an Ecommerce PWA for Your Online Store

Should You Build a PWA or a Native App?

PWAs are naturally seen as a cheaper alternative to native mobile apps. As we’ve seen, there are certainly a number of shortcomings PWAs have when comparing them to true native apps.

At the same time, PWAs have some advantages:

• Most importantly, they’re significantly cheaper and quicker to build. You don’t need to spend hundreds of thousands of dollars for a project lasting 6+ months, as you would with a native app.
• PWAs are discoverable by Google, and offer an improved mobile browsing experience to a wider share of users, by being accessible in the browser.
• PWAs are naturally cross-platform (outside of not working on certain browsers on iOS), which further adds to convenience for users.

Strictly in terms of user experience and value to a business, PWAs are not as good as native apps. Yet for small businesses with a limited budget, it likely makes more sense to create a PWA website than to invest in fully native apps, or even custom cross-platform apps .

However, with MobiLoud , you can get the best of both worlds - a cheap, efficient PWA combined with a mobile app that can harness the full power of push notifications, enter the app stores, and provide a more immersive user experience on mobile devices - without the huge cost of native apps.

Unlock a Wider Audience and Convert Your PWA to a Mobile App

MobiLoud turns any website into a native mobile app . This gives you access to the benefits of both PWAs and native apps. Instead of choosing between the two, you can build a PWA , then convert it to a mobile app with our done-for-you service .

These apps offer 95% of what you’d get from a fully custom native app, but with a much lower investment. Starting from $350 per month , you’ll get apps that look and feel like custom-built apps on iOS and Android, fully synced with your website, with little to no overhead required to maintain.

All the work to build, test and publish your apps is done for you by our team, including submitting your apps to the app stores for approval. Start to finish, the process can take as little as two weeks.

To see what’s possible for your Progressive Web App, learn more about the process and have your questions answered by one of our project managers, book a free consultation today .

Convert your website into a mobile app

Read more posts like this.

How to Set Up Push Notifications for Your PWA (on iOS and Android)

How to Publish a PWA to the App Store and Google Play Store

SEO for Progressive Web Apps: Boost Organic Traffic to Your PWA

PWA vs SPA: Key Differences | Is One Better Than The Other?

Apple reverses decision about blocking web apps on iPhones in the EU

Apple has reversed its decision about blocking web apps, also known as Progressive Web Apps (PWAs), on iPhones in the EU. The company updated its developer page saying that after receiving many requests to support PWAs, it will reinstate the functionality in the upcoming public release of iOS 17.4.

PWAs can act like native apps and access different functionalities of your device without taking up too much space on your phone. These apps can also send you notifications and keep you logged in to a service. As web apps don’t have to be distributed through the App Store, they also don’t have to pay any fees to Apple for in-app purchases or wait for the company’s review process.

Last month, Apple reduced the functionality of PWAs as mere website shortcuts with the release of the second beta of iOS 17.4 , as security researcher Tommy Mysk  and  Open Web Advocacy had first pointed out. The company then updated its developer page saying that because of security risks like malicious web apps reading data from other web apps and accessing cameras, it decided to end support for homescreen apps.

The iPhone maker pointed toward the Digital Markets Act (DMA) compliance as part of the reason for this decision. The act forced Apple to open up the browser ecosystem and not limit developers to only WebKit, allowing them to choose a different engine.

Apple also said that PWAs had “very low user adoption” so there might not be a lot of impact on users. However, the move didn’t sit well with the regulators so they started to investigate the issue by sending questions to developers, as reported by the Financial Times . Separately, the Open Web Advocacy group published an open letter addressed to Tim Cook to lift the ban on web apps , which was signed by hundreds of organizations and individuals, including Mastodon, internet advocate Cory Doctorow and Vercel CTO Malte Ubl.

Apple’s reversal only applies to web apps based on WebKit, as 9to5Mac noted. Users won’t be able to take advantage of this functionality if a browser chooses to use a different engine.

European Commission’s reaction

The European Commission welcomed Apple’s decision and said that after the company first blocked web apps last month, more than 500 citizens, businesses, and public entities submitted their complaints.

“A large number of these stakeholders depend on Home Screen Web Apps to run their business, to communicate with employees and customers and citizens, or to receive crucial information and updates,” an EC spokesperson told TechCrunch.

The EC also added that Apple’s move to block the web apps under the guise of DMA compliance was “neither required, nor justified.”

We understand some web apps that could have been shut down by Apple’s move included apps for public school and hospital scheduling systems and transport companies’ information apps.

Full text of Apple’s update:

Previously, Apple announced plans to remove the Home Screen web apps capability in the EU as part of our efforts to comply with the DMA. The need to remove the capability was informed by the complex security and privacy concerns associated with web apps to support alternative browser engines that would require building a new integration architecture that does not currently exist in iOS. We have received requests to continue to offer support for Home Screen web apps in iOS, therefore we will continue to offer the existing Home Screen web apps capability in the EU. This support means Home Screen web apps continue to be built directly on WebKit and its security architecture, and align with the security and privacy model for native apps on iOS. Developers and users who may have been impacted by the removal of Home Screen web apps in the beta release of iOS in the EU can expect the return of the existing functionality for Home Screen web apps with the availability of iOS 17.4 in early March.

The story has been updated with the European Commission’s remarks.

• Español – América Latina
• Português – Brasil
• Tiếng Việt
• Collections
• Progressive Web Apps

Make your PWA feel more like an app

Make your Progressive Web App not feel like a website, but like a "real" app

When you play Progressive Web App buzzword bingo, it is a safe bet to set on "PWAs are just websites". Microsoft's PWA documentation agrees , we say it on this very site, and even PWA nominators Frances Berriman and Alex Russell write so , too. Yes, PWAs are just websites, but they are also way more than that. If done right, a PWA will not feel like a website, but like a "real" app. Now what does it mean to feel like a real app?

To answer this question, let me use the Apple Podcasts app as an example. It is available on macOS on desktop and on iOS (and iPadOS respectively) on mobile. While Podcasts is a media application, the core ideas I illustrate with its help apply to other categories of apps, too.

Capable of running offline

If you take a step back and think of the platform-specific applications you have on your mobile phone or desktop computer, one thing clearly stands out: you never get nothing. In the Podcasts app, even if I am offline, there is always something. When there is no network connection, the app naturally still opens. The Top Charts section does not show any content, but instead falls back to a Can't connect right now message paired with a Retry button. It may not be the most welcoming experience, but I get something.

The Podcasts app follows the so-called app shell model. All the static content that is needed to show the core app is cached locally, including decorative images like the left-hand menu icons and the core player UI icons. Dynamic content like the Top Charts data is only loaded on demand, with locally cached fallback content available should the loading fail. Read the article The App Shell Model to learn how to apply this architectural model to your web app.

Offline content available and media playable

While offline, via the left-hand drawer, I can still navigate to the Downloaded section and enjoy downloaded podcast episodes that are ready to be played and are displayed with all metadata like artwork and descriptions.

Previously downloaded media content can be served from the cache, for example using the Serve cached audio and video recipe from the Workbox library. Other content can always be stored in the cache, or in IndexedDB. Read the article Storage for the web for all details and to know when to use what storage technology. If you have data that should be persistently stored without the risk of being purged when the available amount of memory gets low, you can use the Persistent Storage API .

Proactive background downloading

When I am back online, I can of course search for content with a query like http 203 , and when I decide to subscribe to the search result, the HTTP 203 podcast , the latest episode of the series is immediately downloaded, no questions asked.

Downloading a podcast episode is an operation that potentially can take longer. The Background Fetch API lets you delegate downloads to the browser, which takes care of them in the background. On Android, the browser in turn can even delegate these downloads further on to the operating system, so the browser does not need to be continuously running. Once the download has completed, your app's service worker gets woken up and you can decide what to do with the response.

Sharing to and interacting with other applications

The Podcasts app integrates naturally with other applications. For example, when I right-click an episode that I like, I can share it to other apps on my device, like the Messages app. It also naturally integrates with the system clipboard. I can right-click any episode and copy a link to it.

The Web Share API and the Web Share Target API allow your app to share and receive texts, files, and links to and from other applications on the device. Although it is not yet possible for a web app to add menu items to the operating system's built-in right-click menu, there are lots of other ways to link to and from other apps on the device. With the Async Clipboard API , you can programmatically read and write text and image data (PNG images) to the system clipboard. On Android, you can use the Contact Picker API to select entries from the device's contacts manager. If you offer both a platform-specific app and a PWA, you can use the Get Installed Related Apps API to check if the platform-specific app is installed, in which case you do not need to encourage the user to install the PWA or accept web push notifications.

Background app refreshing

In the Podcasts app's settings, I can configure the app to download new episodes automatically. Like that, I do not even have to think about it, updated content will always just be there. Magic.

The Periodic Background Sync API allows your app to refresh its content regularly in the background without the need for it to be running. This means new content is proactively available, so your users can start delving into it right away whenever they decide.

State synchronized over the cloud

At the same time, my subscriptions are synchronized across all devices I own. In a seamless world, I do not have to worry about manually keeping my podcast subscriptions in sync. Likewise, I do not have to be afraid that my mobile device's memory will be consumed by episodes I have already listened to on my desktop. The play state is kept in sync, and listened-to episodes are automatically deleted.

Syncing app state data is a task that you can delegate to the Background Sync API . The sync operation itself does not have to happen immediately, just eventually , and maybe even when the user has closed the app again already.

Hardware media key controls

When I am busy with another application, say, reading a news page in the Chrome browser, I can still control the Podcasts app with the media keys on my laptop. There is no need to switch to the app just to skip forward or backward.

Media keys are supported by the Media Session API . Like that, users can make use of the hardware media keys on their physical keyboards, headphones, or even control the web app from the software media keys on their smartwatches. An additional idea to smooth seeking operations is to send a vibration pattern when the user seeks over a significant part of the content, for example, passing the opening credits or a chapter boundary.

Multitasking and app shortcut

Of course I can always multitask back to the Podcasts app from anywhere. The app has a clearly distinguishable icon that I can also put on my desktop or application dock so Podcasts can be launched immediately when I feel like it.

Progressive Web Apps on both desktop and mobile can be installed to the home screen, start menu, or application dock. Installation can happen based on a proactive prompt, or fully controlled by the app developer. The article What does it take to be installable? covers everything you need to know. When multitasking, PWAs appear independent from the browser.

Quick actions in context menu

The most common app actions, Search for new content and Check for New Episodes , are available right from the context menu of the app in the Dock. Via the Options menu, I can also decide to open the app at login time.

By specifying app icon shortcuts in the PWA's web app manifest, you can register quick routes to common tasks that users can reach directly from the app icon. On operating systems like macOS, users can also right-click the app icon and set the app to launch at login time. There is ongoing work on a proposal for run on login .

Act as default app

Other iOS applications and even websites or emails can integrate with the Podcasts app by leveraging the podcasts:// URL scheme. If I follow a link like podcasts://podcasts.apple.com/podcast/the-css-podcast/id1042283903 while in the browser, I am brought right into the Podcasts app and can decide to subscribe or listen to the podcast.

Handling fully custom URL schemes is not yet possible, but there is ongoing work on a proposal for URL Protocol Handling for PWAs. Currently, registerProtocolHandler() with a web+ scheme prefix is the best alternative.

Local file system integration

You may not immediately think of it, but the Podcasts app naturally integrates with the local file system. When I download a podcast episode, on my laptop it is stored in ~/Library/Group Containers/243LU875E5.groups.com.apple.podcasts/Library/Cache . Unlike, say ~/Documents , this directory is of course not meant to be accessed directly by regular users, but it is there. Other storage mechanisms than files are referenced in the offline content section.

The File System Access API enables developers to get access to the local file system of the device. You can use it directly or via the browser-fs-access support library that transparently provides a fallback for browsers that do not support the API. For security reasons, system directories are not web-accessible.

Platform look and feel

There is a more subtle thing that is self-evident for an iOS application like Podcasts: none of the text labels are selectable and all text blends in with the system font of the machine. Also my choice of system color theme (dark mode) is respected.

By leveraging the user-select CSS property with the value of none , you can protect UI elements from being accidentally selected. Be sure, though, to not abuse this property for making app contents unselectable. It should only be used for UI elements like button texts, etc. The :~:text=system%2Dui,-Glyphs"> system-ui value for the font-family CSS property allows you to specify the default UI font of the system to be used for your app. Finally, your app can obey to the user's color scheme preference by respecting their prefers-color-scheme choice, with an optional dark mode toggle to override it. Another thing to decide on might be what the browser should do when reaching the boundary of a scrolling area, for example, to implement custom pull to refresh . This is possible with the overscroll-behavior CSS property.

Customized title bar

When you look at the Podcasts app window, you notice that it does not have a classic integrated title bar and toolbar, like, for example, the Safari browser window, but a customized experience that looks like a sidebar docked to the main player window.

While not currently possible, title bar customization is being worked on at the moment. You can (and should), however, specify the display and the theme-color properties of the web app manifest to determine the look and feel of your application window and to decide which default browser controls—potentially none of them—should be shown.

Snappy animations

In-app animations are snappy and smooth in Podcasts. For example, when I open the Episode Notes drawer on the right, it elegantly slides in. When I remove one episode from my downloads, the remaining episodes float up and consume the screen real estate that was freed by the deleted episode.

Performant animations on the web are certainly possible if you take into account a number of best practices outlined in the article Animations and Performance . Scroll animations as commonly seen in paginated content or media carousels can be massively improved by using the CSS Scroll Snap feature. For full control, you can use the Web Animations API .

Content surfaced outside of app

The Podcasts app on iOS can surface content in other locations than the actual application, for example, in the system's Widgets view, or in the form of a Siri Suggestion. Having proactive, usage-based calls-to-action that just require a tap to interact with can greatly increase the re-engagement rate of an app like Podcasts.

The Content Index API allows your application to tell the browser which content of the PWA is available offline. This allows the browser to surface this content outside of the main app. By marking up interesting content in your app as suitable for speakable audio playback and by using structured markup in general, you can help search engines and virtual assistants like the Google Assistant present your offerings in an ideal light.

Lock screen media control widget

When a podcast episode is playing, the Podcasts app shows a beautiful control widget on the lock screen that features metadata like the episode artwork, the episode title, and the podcast name.

The Media Session API lets you specify metadata like artwork, track titles, etc. that then gets displayed on the lock screen, smartwatches, or other media widgets in the browser.

Push notifications

Push notifications have become a bit of an annoyance on the web (albeit notification prompts are a lot quieter now). But if used properly, they can add a lot of value. For example, the iOS Podcasts app can optionally notify me of new episodes of podcasts I am subscribed to or recommend new ones, as well as alert me of new app features.

The Push API allows your app to receive push notifications so you can notify your users about noteworthy events around your PWA. For notifications that should fire at a known time in the future and that do not require a network connection, you can use the Notification Triggers API .

App icon badging

Whenever there are new episodes available for one of the podcasts I am subscribed to, an app icon badge on the Podcasts home screen icon appears, again encouraging me to re-engage with the app in a way that is not intrusive.

You can set app icon badges with the Badging API . This is especially useful when your PWA has some notion of "unread" items or when you need a means to unobtrusively draw the user's attention back to the app.

Media playback takes precedence over energy saver settings

When podcast media is playing, the screen may turn off, but the system will not enter standby mode. Apps can optionally keep the screen awake, too, for example to display lyrics or captions.

The Screen Wake Lock API allows you to prevent the screen from turning off. Media playback on the web automatically prevents the system from entering standby mode.

App discovery through an app store

While the Podcasts app is part of the macOS desktop experience, on iOS it needs to be installed from the App Store. A quick search for podcast , podcasts , or apple podcasts immediately turns the app up in the App Store.

While Apple does not allow PWAs on the App Store, on Android, you can submit your PWA wrapped in a Trusted Web Activity . The bubblewrap script makes this a painless operation. This script is also what internally powers PWABuilder 's Android app export feature, which you can use without touching the command line.

Feature summary

The table below shows a compact overview of all features and provides a list of useful resources for realizing them on the web.

PWAs have come a long way since their introduction in 2015. In the context of Project Fugu 🐡 , the cross-company Chromium team is working on closing the last remaining gaps. By following even only some of the pieces of advice in this article, you can piece by piece get closer to that app-like feeling and make your users forget that they are dealing with "just a website", because, honestly, most of them do not care how your app is built (and why should they?), as long as it feels like a real app.

Acknowledgements

This article was reviewed by Kayce Basques , Joe Medley , Joshua Bell , Dion Almaer , Ade Oshineye , Pete LePage , Sam Thorogood , Reilly Grant , and Jeffrey Yasskin .

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2020-06-15 UTC.

Kotlin Multiplatform Development Help

What is cross-platform mobile development.

Nowadays, many companies are facing the challenge of needing to build mobile apps for multiple platforms, specifically for both Android and iOS. This is why cross-platform mobile development solutions have emerged as one of the most popular software development trends.

According to Statista, there were 3.55 million mobile apps available on the Google Play Store and 1.6 million apps on the App Store in the third quarter of 2022, with Android and iOS together now accounting for 99% of the worldwide mobile operating system market .

How do you go about creating a mobile app that can reach Android and iOS audiences? In this article, you will find out why more and more mobile engineers are choosing a cross-platform, or multiplatform, mobile development approach.

Cross-platform mobile development: definition and solutions

Multiplatform mobile development is an approach that allows you to build a single mobile application that runs smoothly on several operating systems. In cross-platform apps, some or even all of the source code can be shared. This means that developers can create and deploy mobile assets that work on both Android and iOS without having to recode them for each individual platform.

Different approaches to mobile app development

There are four main ways to create an application for both Android and iOS.

1. Separate native apps for each operating system

When creating native apps, developers build an application for a particular operating system and rely on tools and programming languages designed specifically for one platform: Kotlin or Java for Android, Objective-C or Swift for iOS.

These tools and languages give you access to the features and capabilities of a given OS and allow you to craft responsive apps with intuitive interfaces. But if you want to reach both Android and iOS audiences, you will have to create separate applications, and that takes a lot of time and effort.

2. Progressive web apps (PWAs)

Progressive web apps combine the features of mobile apps with solutions used in web development. Roughly speaking, they offer a mix of a website and a mobile application. Developers build PWAs using web technologies, such as JavaScript, HTML, CSS, and WebAssembly.

Web applications do not require separate bundling or distribution and can be published online. They are accessible via the browser on your computer, smartphone, and tablet, and don't need to be installed via Google Play or the App Store.

The drawback here is that users cannot utilize all of their device's functionality while using the app, such as contacts, calendars, the phone, and other assets, which results in a limited user experience. In terms of app performance, native apps have the lead.

3. Cross-platform apps

As mentioned earlier, multiplatform apps are designed to run identically on different mobile platforms. Cross-platform frameworks allow you to write shareable and reusable code for the purpose of developing such apps.

This approach has several benefits, such as efficiency with respect to both time and cost. We'll take a closer look at the pros and cons of cross-platform mobile development in a later section.

4. Hybrid apps

When browsing websites and forums, you may notice that some people use the terms "cross-platform mobile development" and "hybrid mobile development" interchangeably. Doing so, however, is not entirely accurate.

When it comes to cross-platform apps, mobile engineers can write code once and then reuse it on different platforms. Hybrid app development, on the other hand, is an approach that combines native and web technologies. It requires you to embed code written in a web development language, like HTML, CSS, or JavaScript, into a native app. You can do this with the help of frameworks, such as Ionic Capacitor and Apache Cordova, using additional plugins to access the native functionalities of platforms.

The only similarity between cross-platform and hybrid development is code shareability. In terms of performance, hybrid applications are not on par with native apps. Because hybrid apps deploy a single codebase, some features are specific to a particular OS and don't function well on others.

Native or cross-platform app development: a longstanding debate

The debate around native and cross-platform development remains unresolved in the tech community. Both technologies are in constant evolution and come with their own benefits and limitations.

Some experts still prefer native mobile development over multiplatform solutions, identifying the stronger performance and better user experience of native apps as some of the most important benefits.

However, many modern businesses need to reduce the time to market and the cost of per-platform development while still aiming to have a presence both on Android and iOS. This is where cross-platform development technologies like Kotlin Multiplatform (KMP) can help, as David Henry and Mel Yahya, senior software engineers at Netflix, note :

Is cross-platform mobile development right for you?

Choosing a mobile development approach that is right for you depends on many factors, like business requirements, objectives, and tasks. Like any other solution, cross-platform mobile development has its pros and cons.

Benefits of cross-platform development

There are plenty of reasons businesses choose this approach over other options.

1. Reusable code

With cross-platform programming, mobile engineers don't need to write new code for every operating system. Using a single codebase allows developers to cut down on time spent doing repetitive tasks, such as API calls, data storage, data serialization, and analytics implementation.

Technologies like Kotlin Multiplatform allow you to implement the data, business, and presentation layers of your app just once. Alternatively, you can adopt KMP gradually: Choose a piece of logic that changes frequently and usually goes out of sync, such as data validation, filtering, or sorting; make it cross-platform; and then connect it to your project as a microlibrary.

At JetBrains, we regularly conduct Kotlin Multiplatform surveys and ask our community members about what parts of code they share between different platforms.

2. Time savings

Due to code reusability, cross-platform applications require less code, and when it comes to coding, less code is more. Time is saved because you do not have to write as much code. Additionally, with fewer lines of code, there's less room for bugs to emerge, resulting in less time spent testing and maintaining your code.

3. Effective resource management

Building separate applications is expensive. Having a single codebase helps you effectively manage your resources. Both your Android and your iOS development teams can learn how to write and use shared code.

4. Attractive opportunities for developers

Many mobile engineers view modern cross-platform technologies as desirable elements in a product's tech stack. Developers may get bored at work when having to perform repetitive and routine tasks, such as JSON parsing. However, new technologies and tasks can bring back their excitement, motivation, and joy for work. In this way, having a modern tech stack can actually make it easier for you to both staff your mobile development team and keep it engaged and enthusiastic for longer.

5. Opportunity to reach wider audiences

You don't have to choose between different platforms. Since your app is compatible with multiple operating systems, you can satisfy the needs of both Android and iOS audiences and maximize your reach.

6. Quicker time to market and customization

Since you don't need to build different apps for different platforms, you can develop and launch your product much faster. What's more, if your application needs to be customized or transformed, it will be easier for programmers to make small changes to specific parts of your codebase. This will also allow you to be more responsive to user feedback.

Challenges of a cross-platform development approach

All solutions come with their own limitations. Some in the tech community argue that cross-platform programming still struggles with glitches related to performance. Furthermore, project leads might have fears that their focus on optimizing the development process might negatively impact the app's user experience.

With improvements to the underlying technologies, however, cross-platform solutions are becoming increasingly stable , adaptable, and flexible.

Here are the results of two Kotlin Multiplatform user surveys regarding framework usage, conducted 6 months apart:

Another commonly voiced concern is that multiplatform development makes it impossible to seamlessly support the native features of platforms. With Kotlin Multiplatform, however, you can use Kotlin's expected and actual declarations to enable your multiplatform app to access platform-specific APIs. Expected and actual declarations allow you to define in common code that you "expect" to be able to call the same function across multiple platforms and provide the "actual" implementations, which can interact with any platform-specific libraries thanks to Kotlin's interoperability with Java and Objective-C/Swift.

As modern multiplatform frameworks continue to evolve, they increasingly allow mobile engineers to craft a native-like experience. If an application is well-written, the user will not be able to notice the difference. However, the quality of your product will heavily depend on the cross-platform app development tools you choose.

The most popular cross-platform solutions

The most popular cross-platform frameworks include Flutter, React Native, and Kotlin Multiplatform. Each of these frameworks has its own capabilities and strengths. Depending on the tool you use, your development process and the outcome may vary.

Created by Google, Flutter is a cross-platform development framework that uses the Dart programming language. Flutter supports native features, such as location services, camera functionality, and hard drive access. If you need to create a specific app feature that's not supported in Flutter, you can write platform-specific code using the Platform Channel technology .

Apps built with Flutter need to share all of their UX and UI layers, which is why they may not always feel 100% native. One of the best things about this framework is its Hot Reload feature, which allows developers to make changes and view them instantly.

This framework may be the best option in the following situations:

You want to share UI components between your apps but you want your applications to look close to native.

The app is expected to put a heavy load on CPU/GPU and performance is likely to require optimization.

You need to develop an MVP (minimum viable product).

Among the most popular apps built with Flutter are Google Ads, Xianyu by Alibaba, eBay Motors, and Hamilton.

React Native

Facebook introduced React Native in 2015 as an open-source framework designed to help mobile engineers build hybrid native/cross-platform apps. It's based on ReactJS – a JavaScript library for building user interfaces. In other words, it uses JavaScript to build mobile apps for Android and iOS systems.

React Native provides access to several third-party UI libraries with ready-to-use components, helping mobile engineers save time during the development process. Like Flutter, it allows you to see all your changes immediately, thanks to the Fast Refresh feature.

You should consider using React Native for your app in the following cases:

Your application is relatively simple and is expected to be lightweight.

The development team is fluent in JavaScript or React.

Applications built with React Native include Facebook, Instagram, Skype, and Uber Eats.

Kotlin Multiplatform

Kotlin Multiplatform is an open-source technology built by JetBrains that allows developers to share code across platforms while retaining the benefits of native programming. Its key benefits include:

The ability to reuse code across Android, iOS, web, desktop, and server-side while keeping native code if needed.

Smooth integration with existing projects. You can utilize platform-specific APIs while making the most of both native and cross-platform development.

Full code-sharing flexibility and the ability to share both the logic and the UI, thanks to Compose Multiplatform , a modern declarative cross-platform UI framework built by JetBrains.

No need to introduce a new language to your codebase when you already use Kotlin for Android. You can reuse your Kotlin code and expertise, which makes migrating to Kotlin Multiplatform less risky compared to other technologies.

If your team needs help adopting a new multiplatform technology, we recommend reviewing our guide on How to introduce multiplatform development to your team .

McDonald's, Netflix, 9GAG, VMware, Cash App, Philips, and many other companies are already capitalizing on Kotlin Multiplatform's ability to be gradually integrated, as well as its low adoption risk. Some of them opt to enhance their app stability by sharing specific, crucial segments of their existing Kotlin code. Others aim to maximize code reuse without compromising app quality and share all application logic across mobile, desktop, web, and TV, while preserving native UIs on each platform. The benefits of this approach are apparent from the stories of the companies that have already adopted it.

As cross-platform development solutions continue to evolve, their limitations have begun to pale in comparison to the benefits they provide. A variety of technologies are available on the market, all suited to different sets of workflows and requirements. Each of the tools discussed in this article offers extensive support for teams thinking about giving cross-platform a try.

Ultimately, carefully considering your specific business needs, objectives, and tasks, and developing clear goals that you want to achieve with your app, will help you identify the best solution for you.

• a. Send us an email
• b. Anonymous form
• Buyer's Guide
• Upcoming Products
• Tips / Contact Us
• Podcast Instagram Facebook Twitter Mastodon YouTube Notifications RSS Newsletter

Apple Releases Safari Technology Preview 193 With Bug Fixes and Performance Improvements

Apple today released a new update for Safari Technology Preview , the experimental browser Apple first introduced in March 2016. Apple designed the ‌Safari Technology Preview‌ to test features that may be introduced into future release versions of Safari.

The current ‌Safari Technology Preview‌ release is compatible with machines running macOS Ventura and macOS Sonoma , the latest version of macOS that Apple released in September 2023.

The ‌Safari Technology Preview‌ update is available through the Software Update mechanism in System Preferences or System Settings to anyone who has downloaded the browser . Full release notes for the update are available on the Safari Technology Preview website .

Apple's aim with ‌Safari Technology Preview‌ is to gather feedback from developers and users on its browser development process. ‌Safari Technology Preview‌ can run side-by-side with the existing Safari browser and while designed for developers, it does not require a developer account to download.

Get weekly top MacRumors stories in your inbox.

Top Rated Comments

But is it snappier?

I'm always curious about these Safari Tech Preview posts. Are they just a quick way to add another headline? I suspect so, as I don't see many people trusting these builds as their daily driver. I've tried that in the past, but it never stuck.

Popular Stories

Apple Announces 'Let Loose' Event on May 7 Amid Rumors of New iPads

Apple Cuts Vision Pro Shipments as Demand Falls 'Sharply Beyond Expectations'

Apple Releases Open Source AI Models That Run On-Device

Apple Finally Plans to Release a Calculator App for iPad Later This Year

iOS 17.5 Will Add These New Features to Your iPhone

Next article.

Our comprehensive guide highlighting every major new addition in iOS 17, plus how-tos that walk you through using the new features.

App Store changes for the EU, new emoji, Podcasts transcripts, and more.

Get the most out your iPhone 15 with our complete guide to all the new features.

A deep dive into new features in macOS Sonoma, big and small.

Revamped models with OLED displays, M3 chip, and redesigned Magic Keyboard accessory.

Updated 10.9-inch model and new 12.9-inch model, M2 chip expected.

Apple's annual Worldwide Developers Conference will kick off with a keynote on June 10.

Expected to see new AI-focused features and more. Preview coming at WWDC in June with public release in September.

Other Stories

16 hours ago by Joe Rossignol

2 days ago by Tim Hardwick