In a nutshell: PWAs offer possibilities that were previously reserved for native apps. When it comes to look & feel, they come very close to native apps and outperform traditional (mobile) websites in terms of performance. They also tend to have more reach and only need to be developed for one platform. But they also have disadvantages: Not (yet) full support on iOS, access to hardware features is restricted and many toolkits & SDKs can only be built into native apps.

We have now built one of our native iOS apps – the Stations app – as a PWA. In this post we compare the two apps 1:1.

What requirements did the Stations PWA have to meet?

The Stations iOS App is very popular with commuters and all regular public transport users in Switzerland who want to find out about the next departure times of trains, trams, buses etc., as well as about track changes, delays and cancellations simply and quickly.

Important for the users: Fast loading times and continuous updating of the data. The usability of the iOS app is also kept intuitive: the next departure times are displayed depending on the GPS-location. You can also create favorites and search for specific locations and later departure times.

So how does the PWA compare to the native iOS app? We compared the two apps using different criteria.

Criterion 1: App Installation

If you google the Stations app, it is displayed in the browser search. With one click you are in the App Store and can install the app with another click.

Since the PWA is new, you still have to find it via entering the web link – stationsapp.ch – (which will change with use and SEO over time). With Android, the user is asked after clicking on the link whether he wants to install the PWA. Such a hint is missing in iOS. He can add the app to the screen via share options and the browser navigation disappears.

CONCLUSION: Both apps are installed in about the same amount of time. The «detour» via the App Store for the native app may be a mental hurdle for some. A PWA, on the other hand, can be tried out via the browser link. Disadvantage on Apple devices: the user may not even think that it is a PWA if the app itself does not indicate it.

Criterion 2: Usability & Performance

The look of the two apps is indistinguishable. As soon as the app is added to the home screen, the last indication of a web app – the browser navigation – disappears. In other words, the apps are visually identical twins.

PWA

native App

The loading times of the PWA are in no way inferior to those of the iOS app, since it is a single-page application that loads the content via web services.

The scroll and click behaviors are almost identical, except for small details in the feel: in the iOS app, it is possible to incorporate a vibration when tapping a function, e.g. in the Stations app at the connection detail view. Such gimmicks are currently not possible in PWAs.

Disadvantage of the PWA: the approval for GPS use must be given once a day, while with the native app a one-time acceptance is sufficient (and this can be changed at any time in the device settings). Also, the PWA on iOS always restarts when you go off for a moment, the last searched connection is gone. An extension in the code is required as a workaround in the next upgrade.

Note: We didn’t do design optimizations for desktop and tablets (such as the native app does for tablets), although this would of course be possible without any problems.

CONCLUSION: As far as performance and usability are concerned, the two apps are almost identical – with the exception of a few cutbacks in the PWA.

Criterion 3: Scope of functions

The functions of the iOS app could be easily implemented in the PWA:

GPS-based display of stops in the vicinity

Display of next public transport departure times as a table view

Notification of delays, track changes, train cancellations

Search by town

Create favorites

Integration of live data for SBB and many regional train operations

Caching (of the overview pages)

However, the Stations app is a rather «simple» app in terms of functionality, and does not offer any functions not supported by Apple for PWAs such as push. Also, the app does not need any hardware features like Bluetooth or NFC and there are no toolkits and SDK’s like AR, ML, Scanning or similar in use.

Note: Due to time constraints, we have not yet implemented the full range of functions of the native app in the PWA and the layout is not yet optimized for desktop, tablets. We also had to do without functions that are not possible with PWAs, such as 3D-Touch, multitasking on iPad and an Apple Watch version.

CONCLUSION: With this app, which is rather simple in terms of functionality, we have not reached any functional limits. In general the planned scope of functions is an important decision criterion for or against the use of a PWA.

Criterion 4: Development effort

For those who may be interested, a brief digression about the technologies used:

After a thorough evaluation of various frameworks, we decided on «React» for the development. The advantage was that the framework already offers a lot, e.g. a service worker for caching. However, we also had to add some rather «primitive» functions, such as the history, i.e. navigating back, built as a separate stack with HTML5 / CSS / Javascript. Of course, we paid attention to good reusability of the developed components.

For data storage, we integrated WebSQL and implemented a JSON export of the database at the first loading, because already existing data cannot be stored initially in WebSQL storage. In the future we will replace WebSQL in order to be able to support more browsers.

As with all web developments, some CSS tricks were necessary to ensure that the app was displayed correctly on various browsers, platforms and screen sizes (although the layout of the app was not optimized for tablets and desktops). Remark: the app does not yet run on Microsoft Edge, Internet Explorer and Firefox, as it is using WebSQL (we will have to do changes to make it running on all browsers).

Since the PWA is developed for only one platform, the development effort is clearly lower than for apps developed for both platforms – iOS and Android – in the respective native language.

According to our experience, however, the savings are not exactly 50%, because they depend on how much platform-specific UX the app should contain and how many browser and OS versions should be supported.

The effort required to align the layout to different screen sizes also plays a role, of course. A PWA that is also optimized for desktop or tablets takes more time than if it is primarily intended for smartphones. On the other hand, this can also save the effort of designing a separate conventional website.

CONCLUSION: The savings in the development and maintenance of one PWA compared to two native apps are certainly a decisive argument in favor of PWAs, provided the functional requirements permit this.

It is best to load the two apps yourself and make the comparison! (Remark: supported browsers are Safari and Chrome)