Native apps

[christopherthomasdesign]

What

Native mobile apps for government – things like the GOV.UK ID Check app and the HMRC app.

Use this space to share things like:

• any broad design principles you've used when working on apps
• things you've learnt from testing mobile apps with users
• how you've adapted GOV.UK styles to an app context
• any components or patterns that are specific to mobile app context (for example, switching between apps and the web)
• how you think different government apps should relate to one another (for example, naming, scope, icons)

These findings could eventually lead to producing some guidance about designing apps "for GOV.UK".

Why

There are a few UK government apps out there, and they use slightly different approaches. We've also heard from different teams asking if there's any guidance out there for designing government apps. It'd be good to share more of what we've learnt to bring a more consistent user experience to them.

CDDO have committed to creating a mobile app strategy as part of their 2022–25 roadmap for digital and data. This is at a very early stage at the time of writing (March 2023), and we don't know what shape it will take. But anything we gather here can be contributed to that strategy to make sure it reflects the knowledge and experience of teams working on apps.

Examples

• there are 4 central government apps in the Apple app store at the moment: GOV.UK ID Check; HMRC; EU Exit: ID Document Check; UK Immigration: ID Check (we've heard of a few other teams working on apps too)
• the team working on GOV.UK ID Check app created a pattern library for it, we could look into sharing that work

Related links

• the Service Manual is the main existing guidance on building an app, last updated in May 2019

[jenbutongit]

Apple has extensive documentation on building apps for iOS (or other apple platforms). https://developer.apple.com/design/human-interface-guidelines/guidelines/overview. There are also accessibility/usability guidelines, things like making sure a button's hitbox is >44pt x 44pt so it's easier to tap. Some of these will apply to android (like the button), but some will be apple specific. Also some docs (official apple docs seem to be outdated) https://www.kodeco.com/6827616-ios-accessibility-getting-started on how to use the Accessibility Inspector.

In terms of switching from web to app or app to web, there will be a way to do this in both platforms. https://developer.apple.com/documentation/xcode/supporting-universal-links-in-your-app this is more technical documentation since there are security considerations especially if you are transferring any data between app <-> web at this point.

Although it may be slightly disconcerting using the exact same UI for both platforms, using a framework like flutter or react native will reduce some design/development cost. There is still a possibility that additional platform specific code to write, in which case you still need an iOS and Android developer, but there is less duplication. Serving an app which is mostly webframes (like the NHS app) is usually ok too when you want to dedupe work.

[frankieroberto]

Should apps have animated transitions between views? This is common for native apps (eg default Notes app on iPhone) but not common on the web.

[stevenjmesser]

Has anyone experimented with Web Push notifications for Web Apps on iOS and iPadOS?

[drenton]

So timely. Ontario beginning to work on an app strategy.

Some early strategic principles/thoughts

(not totally sure where this is going, so maybe more scratch pad... so would welcome some feedback 🙏)

1. Apps are not a replacement for website capability, they are a difference of kind, not degree—targeted and focused to very specific needs (how do we avoid the desire to turn the website into an app)??
2. An experience designed specifically for use outside of the work and home setting i.e. on the go — in the community, while shopping, while in the car, in a park, at the border etc. where ease of use through apps vastly exceeds the best mobile web experience
3. Government apps should be looked at as additive, unleashing unimagined potential to save time and improve the lives of people in Ontario.

Other considerations/thoughts

• Domain appropriateness - where is there sufficient domain speciality to make a unique app valuable vs general purposes ones for Individuals or businesses i.e. parks, benefits recipients, post-secondary students, healthcare etc. an initial strategy that identifies domain opportunities - Ontario has only one app published right now (for roads/drivers)
• Needs that are appropriate for apps and that are not necessary device feature dependent (i.e. only achievable via an app), but focused on the unique app user behaviour that come with mobile devices i.e. higher conversion for push notification and more trust with app notifications vs email or sms or phone calls etc.
• Naming patterns and icon patterns (how to avoid branding problems/conflicts)
• Design system updated for app context. Our experience building apps used in the pandemic (vaccine verification) demonstrated that we're off the mark design wise when we attempt to apply design system patterns geared towards web
• Official publishing accounts (legitimacy issues) - should we have one or multiple?
• Requires a full-feature set of online services; apps should add more value not be just a duplicate of what you can do online

[jenbutongit]

Should apps have animated transitions between views? This is common for native apps (eg default Notes app on iPhone) but not common on the web.

@frankieroberto not necessarily for iOS. It depends on the type of navigation or action. In the case of the notes app you describe, when you navigate to a note, it's adding a new view to the navigation stack (imagine a stack of papers). When you hit back in the top left corner, you "pop" the view from the stack. You'd want to use this if there is a root view, something a user can eventually return back to. Given you're using SwiftUI or UIKit (out of the box UI classes) you do not have to add any additional animations, they come as the default (but you can change it) Similarly, you may want to use sheet actions (see adding a new contact) for short lived actions.

There is also tab navigation which typically doesn't animate anymore. But if the user can slide their thumb to move across the tabs, you might want to animate it as if they were dragging the views (although not required).

[aislingbrock]

Hi everyone! I am a Senior Interaction Designer on the HMRC Mobile App team. The HMRC Mobile App has been around in its current form since 2016 so we've done a lot of work in this space. The app is available on both iOS and Android (we noticed only the Apple App Store is mentioned in the original post!). We have dedicated development teams for each platform that work closely together to ensure a consistent experience across platforms.

On the design side, have a design system that takes the GDS design system and marries it with both the Apple Human Interface Guidelines and the Android Material Design guidelines. This system has not only been used to create the HMRC Mobile App but has also been used to create internal proof-of-concept apps.

To answer some things I've spotted above:

• We try to keep animations subtle for accessibility reasons. Of course, there are system controls that can help with this. But generally speaking, we don't use transitions between screens. We do use some subtle animations on data visualisation elements (like charts that fill in to show individual pieces before becoming static).
• We are currently in the process of exploring push notifications from the web to help with multifactor authentication.
• We're also looking at establishing criteria for what makes a good app candidate and what doesn't, based on our experience and the different areas we've been asked to explore over the years.
• Some of these guidelines touch upon what is mentioned, for example, we are not a carbon copy of the web. We are a tool to help users in a more timely sense. So they can find what they need to do now, take action, and feel involved and in control of their taxes.
• We specialise in microtransactions, not long-winding user journeys. Users check in often to make sure their data seems "correct."
• We are also putting emphasis on actions that occur while on the go. As well as giving users the freedom to access their data and port it to wherever else they may find a use for it.

Some of our recent findings that we've been really interested in is how apps fit within the cost of living crisis, especially with users on lower or variable incomes. We're finding fewer households have desktop or laptop computers as they come at a higher cost. Broadband is also increasing in cost. Whereas smartphones can be bought for less and mobile data in the UK isn't too expensive (certainly not as expensive as in Canada -- I'm Canadian, and moving to the UK has probably saved me hundreds of dollars in mobile data costs over the last 10 years haha). With the initial download and subsequent use of our app using overall less data than the web, we can see clear cost benefits to some of our users.

We're also big sticklers for accessibility. There's a lot to be said for how built-in accessibility tools on smart devices have changed the game in allowing users to customise their device environment and access information in a way that isn't as simple on desktop PCs which often require 3rd party software and websites which are tricky to override. We design our apps so these system settings persist within the app, and so the app works seamlessly with VoiceOver and TalkBack.

Also perhaps interestingly for our Canadian pals, we're in the process of providing the app in both English and Welsh! Since I am Canadian, one of my resources when looking at languages was to look for Canadian apps in both English and French. I didn't come across many which was likely either because I don't have access to all Canadian apps on the UK app store, or because Canadian bilingualism is so prevalent that there are standalone French language apps. So it's been interesting to look at bilingual (or potentially multilanguage) apps over the last few months.

As you can see, we could chat apps all day, and we have been waving this flag and hoping for updated guidance for quite some time! It will be nice to move past the argument of "should apps exist at all" which so often derails conversations about the work we have been doing! We really welcome further conversation and to share more of our knowledge.

We're on the x-gov Slack channel, or you can find me here, and I can put you in contact with one of our many other app experts who will be MORE THAN 'APPY to help. :)

[frankieroberto]

@jenbutongit thanks for the detailed explanation!

My question was partly motivated by the observation that, where a native app is mainly a wrapper for a web view, there's often no animations when following links, even if they're designed to look like native-style navigation. This kinda bugs me (although it took me a while to work out why these apps felt weird), but I’m not sure if this is an issue worth addressing or not?

I guess it comes down to whether or not to use native views or web views... 🤔

[mattmachell]

This is interesting. Does it indicate a change in strategy and roll back the intent of the classic blog post we're not appy ?

A lot of what I see in gov space mobile apps could easily just be a progressive web app, as they are just webviews in app wrappers. That is to say they aren't really doing anything that necessitates low level native api access, higher performance graphics, deep OS integration or any of the reasons you'd really want to use an app and thereby bind yourself to app-store policies and update cycles.

I guess I'm wondering on the intent and the user need you're looking to solve with this and what's driving it?

[querkmachine]

@mattmachell Not an area I'm involved in, so opinions my own: I don't think this is a change in strategy, as (at least in GDS) our intended use cases seem to be limited to places low/native-level API access is needed.

The most high-profile at the moment might be the planned One Login app, which will support biometric and NFC-based identity verification methods. Doing these purely in the web browser is currently either impractical, if not impossible.

The Web NFC specification is still a community draft, only available in Chromium on Android devices, and—to my knowledge—only supports the NDEF protocol, which isn't the same as the one typically used on identity documents like passports.

Biometric authentication has technically been possible on mobile browsers for some time, however have only recently become available to the 'mainstream' with the addition of Passkeys support in iOS 16.

As far as I know, there is no intention for apps to replace online equivalents or become the sole means of accessing government services—they're either being used as 'shortcuts' for services that are very frequently used (as the HMRC app is) or they're stopgaps where, unfortunately, the browser support just isn't there yet.

[jenbutongit]

@jenbutongit thanks for the detailed explanation!

My question was partly motivated by the observation that, where a native app is mainly a wrapper for a web view, there's often no animations when following links, even if they're designed to look like native-style navigation. This kinda bugs me (although it took me a while to work out why these apps felt weird), but I’m not sure if this is an issue worth addressing or not?

I guess it comes down to whether or not to use native views or web views... 🤔

Loading spinner is fairly standard procedure for native apps, but I concur, on a phone's browser you at least have some indication like a progress bar or spinner whilst the request is made but is often not implemented for apps-that-are-just-webviews-with-native-sprinkles. For tab navigation there aren't usually loading spinners but since it's native/some data stored on device, it feels more responsive when loading a page/tab, then the rest is loaded in via skeleton components or loading spinner.

I imagine most of this comes down to expertise in web development vs app development. If it's easier/cheaper for you to implement as web view, you probably don't have much choice.

To echo @querkmachine's sentiment, it's worth considering whether a web shortcut is fine or if you do actually need lower level app integration. in the case you do need a native app, you probably do just want them to go into the app, do the action, and then send them back to their browser.

In the cases that the native app ends up being really small, and doesn't really need any persistence, I wonder if app clips would be better? https://developer.apple.com/app-clips/ (Android have an equivalent also).