The UK government takes a default position of no native mobile apps unless certain conditions are met. Native apps are expensive to develop and maintain across different platforms. Web apps that are responsive to different devices are preferred. Exceptions to the no-apps policy may be considered if a responsive web service is already in place, the content is available via APIs/open data, and there is clear evidence that a native app is necessary and justified to meet a specific user need not addressed by existing options. A approval process involves evaluating the need, alternatives, demand evidence, and justification for the chosen platform.

1. UK Government approach to
apps
Tom Loosemore
20th
February 2013

2. 210/17/12
GDS2
At the Oct 2012
Digital Leaders’ meeting,
the position was clarified:
native apps could not be
developed without Cabinet
Office approval.

3. 310/17/12
GDS3
The Nov 2012 Digital Strategy says:
“Stand-alone mobile apps will only
be considered once the core web
service works well on mobile
devices, and if specifically agreed
with the Cabinet Office”

4. 410/17/12
GDS4
This presentation explains
why we have a‘by default, no
apps’ position.
And in what circumstances
apps might be considered as
exceptions.

5. Confusion is understandable.
So-called “Apps” come in
several very, very different
flavours.
5
GDS

6. 610/17/12
GDS6
What is meant by ‘an app’?
1. Device-specific ‘download and
install’ apps (aka ‘native apps’)
2. Websites that respond to various
screen sizes (aka ‘responsive
websites’, ‘web apps’ or ‘HTML5’)
3. Various hybrids of the above

7. 710/17/12
GDS7
What is a‘Native’ App ?
-Downloaded, installed piece of bespoke
software.
-Free or paid-for.
-Persists on the device.
-Can access all device features
-Proprietary code, hence requires completely
different software for iPhone/iPad, Android,
Blackberry etc.
-Spotify, Angry Birds, Instagram, Skype etc.

8. 8
GDSHMRC Tax Calculator Native App

9. 9
GDSNHS Change4Life Native Apps uses persistence

10. 1010/17/12
GDS10
‘Native’ App - Pros
-Revenue (download and buy)
-Persistent presence on device
-Can access all functions on a device
-Snappier performance in general
-Can be used offline, in some cases.

11. 1110/17/12
GDS11
‘Native’ App - Cons
-Expensive to develop & maintain
-Needs several different versions (Android,
iPhone, iPad, Blackberry etc)
-Service iteration more complex (x3)
-Can only be downloaded via gatekeeper
app stores (Apple, Google)
-Most apps are little downloaded, and even
then rarely used.

12. 12
GDS

13. 1310/17/12
GDS13
What is a‘Web App’
-Uses device’s built-in web browser
-Is a website which optimises its layout
& functionality for each device
-Uses open standards (HTML5)
-Examples: GOV.UK, PM’s dashboard,
FT webapp, Virgin Active’s ‘My Locker’,
bbc.co.uk/sport

14. One responsive website, 2 devices
14
GDS

15. 15
GDS
FT realised that few user needs can only be
met through native apps – moved to Web
App.

16. 1610/17/12
GDS16
Web App - Pros
-It is your website, so costs are minimised
and service iteration simplified.
-Uses open standards (HTML5)
-No gatekeepers to constrain access
-Performance still good
-Mobile web outstripping mobile app reach
-Clear winning strategy for ‘utility’ services
which do not require complex device
features or persistence.

17. 1710/17/12
GDS17
Web App- Cons
-Not persistent on device
-Some device features unavailable (camera,
address book)
-Requires internet connection
-Not snappy enough for some complex
services (e.g. Spotify, Facebook, Skype)
-No ‘download and buy’ revenue stream.

18. Hybrid App
18
- A small native app which then
loads up a bespoke website
- So, can use device features (e.g.
camera) that Web apps can’t.
- Requires a stand-alone website
- Examples “Bing for Mobile”,
Netflix app, LinkedIn app, BBC
News app
GDS

19. 19
GDS

20. 2010/17/12
GDS20
Hybrid App – Pros & Cons
Not as expensive to maintain as a native
app, can access device functions and be
persistent…
…but still requires a new parallel version
of your web service, and multiple versions
to be developed for each device.

21. If there is a market for native or
hybrid apps, why should the
government monopolise it?
There is a vibrant market of 3rd
party native app developers
using government data & APIs.
21
GDS

22. 22
GDSMobile apps using data.gov.uk open data

23. 23
GDS
Back to the HMRC Tax Calculator native app…

24. Government’s position is that native &
hybrid apps currently rarely justified.
Ensure your service meets the Digital by
Default service standard and it will work
well on mobile devices.
Make your data & API available for re-
use and you will stimulate market if there
is real demand for native apps.
24
GDS

25. We are backing open standards
(HMTL5) rather than risking
proliferation of parallel versions of
services as devices proliferate.
25
GDS
How will you afford to
support The iWatch?
Or the next big thing?

26. And while people spend as much time
using apps as using mobile web...
26
GDS
…the vast
majority of app
use is for
gaming & social
networking.

27. For “utility”
needs, such as
those met by
government
services, the
mobile web is
preferred to
native apps
27
GDS

28. So what will the ‘By default, no
native apps’ position mean for
Digital Leaders?
Ministers and civil servants will
probably still think they need
native apps so…
28
GDS

29. Expect to hear justifications
for why only a native or
hybrid app will do.
29
GDS

30. Expect to hear why web
apps aren’t all they’re
cracked up to be.
30
GDS

31. 3110/17/12
GDS31
Five key questions you should
consider:
1.Is our web service already designed to be
responsive? If not, why not?
2.What is the user need that only a
native/hybrid App can meet?
3.Are there existing native/hybrid apps
which already meet this user need?
4.Is our service available to 3rd
parties via
API or open data? If not, why not?
5.Does meeting this need justify the lifetime
cost of native or hybrid App?

32. 32
GDS
If after asking the questions,
you’re convinced it’s got to be
a native or hybrid app, then
let’s have a chat about an
exception.
(There will be some…)

33. 33
GDS
The Process

34. 34
GDS
Have you met the necessary
conditions?
NOTE: If these are not in place, it is
unlikely that your proposal will be
approved.

35. 35
GDS
Condition 1:
Your web service is already designed
to be responsive
Condition 2:
The service or the content you’re
looking to build an app for is already
open to third-parties via APIs or as
open data

36. 36
GDS
Answer the following
questions and provide
supporting evidence

37. 1. What is the user need?
Please provide evidence.
37
GDS

38. 2. Is this user need of sufficient
importance to (your users to) justify
the lifetime cost of your proposed
app?
If you believe it is, how have you
determined this?
38
GDS

39. 3. Which 3rd-party native/hybrid apps
already exist to meet this user need?
If there are none and Condition 2 has
been met, please state why this might
be the case.
If there are 3rd-party alternatives,
explain why you believe your app is
necessary.
39
GDS

40. 4. Is there evidence of demand for
this type of app amongst your target
users?
If you believe there is, please
provide supporting evidence e.g.
similar apps which have proven
popular with your target audience
and evidence of their popularity.
40
GDS

41. 5. Is there evidence to justify building
an app for the platform you’re
proposing to do this for?
If so, please provide supporting
evidence e.g. analytics data that
shows proportion of visitors to your
content/service that currently access it
via relevant platform.
41
GDS

42. 42
GDS
In addition to the evidence requested
above, all digital spend for the
development of standalone mobile
apps is subject to the GDS spend
approval process.
Contact GDS PMO for details:
pmo@digital.cabinet-office.gov.uk

43. Thank you.
tom.loosemore@digital.cabinet-office.gov.uk
@tomskitomski
20th
February 2013