Mobile Application standards and guidance

[nigejohnson]

May also be worth running these by the Cloud Mobile Services team (so Graham Wells?) and the Technical Architect for this area (Mike Plucinski).

[nigejohnson]

Below, for the record, is the relevant conversation with and input form Mike Plucinski, the Technical Architect for the mobile area:

From: Johnson, Nigel Sent: 12 March 2020 11:14 To: Plucinski, Mike Cc: Sagar, Ben; Wells, Graham Subject: RE: Digital standards for mobile dev work.

Thanks again Mike,

My responses are below, and I fed those through into revisions. Revised docs attached, in Word format (markdown checked back into the GitHub branch).

I’ll also dump this conversation into GitHub as I think it’s a useful one for us to keep track of.

Please let me know if you think of anything else.

Regards,

Nigel.

From: Plucinski, Mike Sent: 06 March 2020 19:18 To: Johnson, Nigel Subject: RE: Digital standards for mobile dev work.

Nigel,

Great document(s) ! not much to add , just some considerations

I would consider tabulating the standards into something akin to the Architecture Principles document. (The one that Jacq’s did for Applications )

We’ll consider, but ultimately I suspect we’ll be limited to trying to keep a similar look and feel to all the standards.

Wrapping Vs Native Sandboxing+In-App VPN

Considering IOS now Sandboxes Apps/data to an acceptable degree , wrapping in now mostly unnecessary as you elude to in your text. Therefore we should take the native Sandbox & In-App VPN as the default deployment approach before Wrapping

Conversely Android Sandboxing controls/strength is version dependent & regarded as less secure - So maybe a case for wrapping, if the wrapper tech actually adds value and the data in scope requires it. Response: I’ll mention both of the above points.

Although we haven’t deployed Android on the estate, If in future we did I expect we would take the Google For Work / Samsung Knox Container approach instead. Noted and of interest: but I’ll leave that out of our dev standard: I think that’s a possible/potential Cloud Mobile Services standard instead.

PWA I had a quick Google on these sites- • https://brainhub.eu/blog/progressive-web-app-vs-native-app/

• https://www.nimbleappgenie.com/blogs/progressive-web-apps-vs-native-app/

Lots of Pros’ for PWA!

But I can’t find much in terms of PWA vs native Apps in the context of Security.

Data-In-transit(HTTPS/TLS1.2+ ) isn’t my concern, its more around Data-at-Rest .

I assume the security controls for data segregation are down to the browser strength?
• So IOS Safari is trusted..
• But some Android 3rd Party browsers could introduce risk?

Response: you are correct to identify this. As we are enforcing the entry of passcodes all data on the iPad should be encrypted when the ipad is turned off and only decrypted when the ipad is turned back on and the passcode successfully re-entered. That protection should apply to the browser local storage as well as any other files. According to the w3c indexedDB spec, indexedDB is only meant to be accessed via Javascript from the same origin: of course it’s impossible to guarantee that said spec will be followed by every single browser, but it should be followed by all the main ones. That means “reasonably” secure, but not as secure as Apple’s app sandboxing. I will note this so that anyone is aware of that potential downside.

Privacy GDPR considerations – Obvious one – On App Install I would explicitly declare and ask for agreement if any Personal/Sensitive/location Data will be stored. iOs/iPad OS does some of this by default… e.g. asking if an app should access the camera or geolocation, so you’ll be prompted each time you re-open the app after a fresh install. Same with PWAs: if you clear the app and then hit the website to re-download, you’ll get the relevant prompts the first time your JavaScript tries to access the camera or the GPS. Beyond that, doesn’t this apply to everything though? I’ve noted in our GitHub that we may need a “what GDPR means for devs” standard, perhaps as a more general data protection/retention standard.

Also an option to disable sending of Log information and any other ‘Phone Home’ routes to services like Google Analytics. (Xerox Print App has this) I’ll note the need, using a third party app, to read carefully and be aware of how that app may share data.

Platform Version Support If App is to be deployed on DEFRA managed devices then • IOS- Latest Version • Android N/A

And goes without saying but must be tested against emerging OS releases via the beta route

If App is developed for External Parties and/or Public consumption and handles data below Official , I would suggest a more lax requirement in the interests of sustainability.
• IOS Version Latest-1
• Android Latest -1

I’ll add the above to the “testing” section of the standards. I have a feeling though that the second bit, when I stopped to think about, actually implied a broader requirement! Application Logs If we develop internal Apps or commission third parties to develop on our behalf, I would welcome a useful debug option so exceptions are caught and logged with a meaningful event description. Agreed, I’ll note this. AIMS-MA I know has good capability in this area but other apps don't. (Picky I know- but helps us when issues arise)

Cheers

Mike.

From: Johnson, Nigel Sent: 06 March 2020 12:25 To: Plucinski, Mike; Wells, Graham Cc: Sagar, Ben Subject: Digital standards for mobile dev work.

Hi both,

Could I ask you to review the attached please, especially the bits where I’ve mentioned GIO and the Cloud Mobile Services team? Not urgent but I would value your input.

This relates to an initiative in “Digital” to set down standards and guidance for ourselves, so I’ve attempted to cover the mobile piece.

Note that formatting wise the docs are fairly plain as they are intended for conversion to markdown (ho hum) to keep the rest of the dev community happy. I haven’t attached the actual markdown versions as content wise they are identical.

The docs are fairly concise and should be self-explanatory, but I’d start with the “standards” first.

Any input (within reason!) appreciated.

Thanks,

Nigel. Software Engineer Digital Data and Technology Services Department for Environment, Food and Rural Affairs

[johnwatson484]

There's a lot of words in both the standards and the guidance which makes it quite an effort to read and fully digest the information.

I think the standards would be best if you flipped them so the standard is stated clearly first before the justification. Then it's easier to quickly refer back to a standard. If a reader is interested in the justification then they can read on.

[johnwatson484]

Several of the standards make assumptions about the application that I don't think we need to worry about here.

For example, the standard states applications should work offline but there may be no user need that identifies that as necessary. Our standards shouldn't demand solutions to problems we don't necessarily have.

[johnwatson484]

I think we should make some reference to analytics as it will help us support and iterate the application if we can better understand who are users are and what devices they are using.

For example, the Google Play developer console gives really good insights into items such as

• user demograhics
• android versions being used to run your app
• crash reports
• uptake figures

I think it's useful to see what the store platform gives us before we consider what we need to build ourselves.

[johnwatson484]

Should we make some mention to CI/CD with mobile applications?

It goes without saying that we should have a deployment process and they're only published by CI/CD like everything else we do. But there are considerations such as app signing, zip alignment, storage of keys that I think it's worth mentioning that need to be part of a CI/CD process.

Or maybe we just say apps should be signed before publishing?

[johnwatson484]

Should we have a standard for release notes? The format of the release notes could be subjective depending on your users and what your user research implies the format should be. But is it worth considering saying something like you must create a release note to accompany a deployment.

Unsure if that's a more general development point than something we need to specifically consider for mobile marketplaces.

[johnwatson484]

Should we consider any store presence standards?

Again, specific services content will be driven by UCD as to what naming, language, layout, images etc is appropriate but is there some general development specific rules we should consider?

[johnwatson484]

I think we should state something about app permissions we request from a user to run our application. ie we only ask the minimum we need.

[nigejohnson]

There's a lot of words in both the standards and the guidance which makes it quite an effort to read and fully digest the information.

I think the standards would be best if you flipped them so the standard is stated clearly first before the justification. Then it's easier to quickly refer back to a standard. If a reader is interested in the justification then they can read on.

OK, that's serves the need of those who just want to see the standards and the needs of those who need to see the "why": e.g. to assess whether the "why" is still relevant. I'll do that.

[nigejohnson]

Several of the standards make assumptions about the application that I don't think we need to worry about here.

For example, the standard states applications should work offline but there may be no user need that identifies that as necessary. Our standards shouldn't demand solutions to problems we don't necessarily have.

Being able to work offline is the most meaningful functional differentiator between a mobile app and non mobile app: i.e. I don't think you can call an "app" truly mobile without it. that's the definition of mobile app I think we should adopt for these docs because it's a very important one. I've seen projects stumble over/not appreciate the need for something to work offline a couple of times: e.g. have sales people say "look our app works on mobile devices", and just show a web app working in a browser on a smart phone, and for that to pull the wool over the eyes of PMs, only for the sales people to have to reverse their position when challenged on whether can it actually work offline/without a signal, which is the what the project really wanted but couldn't enunciate. I think any other definition of "mobile" would dangerously muddy the waters.

I've now reviewed the common definitions of "mobile apps" online, and have revisited this, using instead the term "offline mobile app" to both attempt to avoid the dangerous confusions I was worried about above and to stress that usually we will be providing offline mobile apps (but agree that usually isn't necessarily always).

[nigejohnson]

I think we should make some reference to analytics as it will help us support and iterate the application if we can better understand who are users are and what devices they are using.

For example, the Google Play developer console gives really good insights into items such as

• user demograhics
• android versions being used to run your app
• crash reports
• uptake figures

I think it's useful to see what the store platform gives us before we consider what we need to build ourselves.

I think that would be more appropriate when we drill down to specific technologies.

[nigejohnson]

Should we make some mention to CI/CD with mobile applications?

It goes without saying that we should have a deployment process and they're only published by CI/CD like everything else we do. But there are considerations such as app signing, zip alignment, storage of keys that I think it's worth mentioning that need to be part of a CI/CD process.

Or maybe we just say apps should be signed before publishing?

I think that would be more appropriate when we drill down to specific technologies.

[nigejohnson]

Should we have a standard for release notes? The format of the release notes could be subjective depending on your users and what your user research implies the format should be. But is it worth considering saying something like you must create a release note to accompany a deployment.

Unsure if that's a more general development point than something we need to specifically consider for mobile marketplaces.

I would agree that it's more a general topic and therefore going beyond the scope of the general "mobile app dev" piece, which, let's face it, is big enough as it is!

[nigejohnson]

Should we consider any store presence standards?

Again, specific services content will be driven by UCD as to what naming, language, layout, images etc is appropriate but is there some general development specific rules we should consider?

Should we consider any store presence standards?

Again, specific services content will be driven by UCD as to what naming, language, layout, images etc is appropriate but is there some general development specific rules we should consider?

The only standards and guidance I'm comfortable with re app store publication is detailed in the "Distributing and Managing Apps" section of the standards document. I think that's all we can say right now. If and when the situation changes that could, of course, be revised, but I don't think we should be proscriptive right now.

The UCD stuff sounds rather a lot like style guides and advice: I think that's another huge topic that would be better dealt with elsewhere and may already be being covered elsewhere. Certainly they'd be a huge overlap between web app and PWA guidance, especially as, given that most computer use is likely to be on smartphones rather then desktops, I'd expect even ordinary web apps to be progressive enough in their UI to have a usable UI on non desktop devices. Anything specific to mobile apps would be best included in the detailed standards for each individual mobile technology.

[nigejohnson]

I think we should state something about app permissions we request from a user to run our application. ie we only ask the minimum we need.

I think this is likely to be the default behaviour anyway: e.g. apps (or the thing "hosting" the app such as the browser) automatically ask when the app tries to gather the user's location, so apps ask for what they need as they need it.

[ben-sagar]

Minor amendments as discussed on call 17/08/2020, ready for approval.