× This site is under continuous improvement. Please help us by providing comments here.

Mobile Application Development Strategy

Overview

Today, mobile sites and applications are integral to nearly every organization’s business strategy. With the right strategy, mobile sites and applications can provide increased visibility to the Agency’s mission, while also helping us provide value to our external stakeholders.

At the same time, due to the potential for extensive publicity through mobile channels, there is a higher risk for the Agency if the wrong mobile application development strategy or technology is adopted.

The EPA is operating in a fast-evolving environment characterized by constantly changing operating platforms with frequent updates along with many new devices and form factors. Additionally, with multiple channels available for communicating with mobile users in terms of technology, platforms, and User Experience (UX), the EPA is faced with the dilemma of making the right choices.

For the purposes of this document, a mobile app, or application, is defined as any native (downloadable) or Web application designed specifically to be accessed and utilized on a handheld mobile device (e.g. smart phone, tablet etc.). They can be designed as a mobile web app, hybrid app or native mobile app.

Diagram outlining the overall process
Note: Please allow at a minimum 2 months (2 Mobile Access Review Committee (MARC) meetings) for the review process and 2 weeks for final review and posting of the approved mobile app to app stores and EPA’s Developer Central. (See diagram for details). It is also important to note that coding of any mobile app should only begin after MARC approval.

Top of Page

Planning a Mobile App

Before you create a mobile app, you need to think about what will be useful for the audience or audiences who will use your application. As you develop your project charter, you should ask yourself some basic questions:

  • Who is my intended audience?
  • What are they trying to achieve in a mobile setting?
  • How will I use the mobile app? What resources can my program bring to bear, and where do I need help from Communications staff in terms of promotion and marketing?
  • How will I measure success?
  • What is the expected End of Life (EOL) of the mobile app?
  • Could I just stick to creating a mobile website?

A mobile app may be data-centric, content-centric or both. A data-centric app may show the nearest brownfield site. A content-centric application may display water saving tips that consumers can use while they are at home or work.

Prior to approaching the MARC, the appropriate type of mobile app must be selected. The type of mobile app will dictate which review form to submit to the MARC. To promote code re-use and interoperability, applications should be built using a hybrid application development strategy (Please contact the MARC (Mobile_AppMARC@epa.gov) for a list of suggested frameworks).

Top of Page

A “One-Size Fits All” model isn’t adequate

When trying to decide what type of Mobile Applications should be delivered to the target users, the EPA must not take a one-size fits all approach. Making this decision involves a trade-off between providing a rich, native user experience versus the portability of the application across platforms that will sacrifice the rich native UX.

There are pros and cons to adopting both paths that must be taken into consideration by both the program office that proposes a new mobile app and the MARC.  Both parties will have to evaluate this issue based on key parameters such as native experience, cost of development, time to market, ease of deployment, and managing the apps to determine the best choice. EPA’s Mobile Application Development Strategy will go over the following types of mobile app development and briefly outline the advantages and disadvantages against each of them:

  • Mobile Web App Development (Preferred)
  • Hybrid App Development (Preferred)
  • Native Mobile App Development

The following evaluation criteria must be taken into consideration when making a choice on what mobile application development strategy will be adopted by the program office.

  1. Native UX
  2. Portability
  3. Time to market
  4. Maintenance & management
  5. Ease of deployment

Top of Page

Mobile Web App Development (Preferred)

Mobile web apps are developed using HTML 5, CSS 3, and JavaScript. These application are executed on the web server, accessible via web browsers, and are portable across multiple mobile platforms. These mobile web apps would leverage the OneEPA Standalone template or be built in the Drupal WebCMS, both of which are fully responsive to various screen sizes. However, a native and rich UX is impossible to create using this strategy. Despite the fact that several device specific functions and offline stores can be leveraged via HTML 5, constraints exists due to the sandbox nature of specific platforms and the extent to which HTML 5 specifications are adopted by native browser components on the user’s device.

Advantages Disadvantages
  • Better manageability due to web server based deployments
  • Excellent portability across multiple platforms
  • High ease of code maintainability and reuse
  • Decrease in total cost of ownership
  • Lower development costs
  • Fastest time to market
  • Lack of native UX
  • Lower performance due to browser based dependencies
  • Dependence on native browser implementation for access to device capabilities
  • Unpredictable performance due to dependency on internet connection
  • Applications are “stateless” meaning that the user must initiate a task before the application will respond.

Top of Page

Hybrid App Development (Preferred)

Hybrid app development frameworks leverage a combination of web based and native app development. Applications are built using HTML 5, CSS 3 and JavaScript. These applications are then compiled using the native SDK and provide better portability across platforms as compared to native apps. Some of the hybrid frameworks provide flexibility to extend and customize the platform by adding additional wrapper plug-ins which allow the application to access more specific native device capabilities.

Advantages Disadvantages
  • Limited access to native device capabilities
  • Excellent portability across platforms
  • Easy to deploy like native applications
  • Greatest potential for code re-use
  • Decreased ownership cost
  • Faster time to market
  • UX is better than mobile web applications but not as good as native mobile applications
  • Performance issues due to browser based dependencies
  • Dependency on hybrid framework developer to add capability for native API extensions

Top of Page

Native Mobile App Development

Native mobile apps created for a specific operating system are developed using the native language of that platform (such as Google’s Java-based “Android” or Apple’s Objective C “iOS”). The applications have access to all of the devices capabilities and functionalities since they use the native SDK for application development. These application provide the highest UX factor compared to other types of application development.

Advantages Disadvantages
  • Tighter integration with platform which results in the app running more efficiently.
  • Maximum performance
  • Easier to deploy to app stores
  • A unique set of source code is created which prohibits code reuse
  • Higher development and maintenance costs
  • Longer time to market, since app store approval is required
  • More expensive to develop and reach a smaller audience

Comparison of Approaches

[[{“fid”:”185601″,”view_mode”:”full”,”fields”:{“format”:”full”,”field_file_image_alt_text[und][0][value]”:”Mobile App Dev Rating”,”field_file_image_title_text[und][0][value]”:””,”field_image_alignment[und]”:”none”,”field_caption[und][0][value]”:””,”field_caption[und][0][format]”:”inline”},”type”:”media”,”link_text”:null,”attributes”:{“alt”:”Mobile App Dev Rating”,”height”:”254″,”width”:”427″,”class”:”media-element file-full”}}]]

Top of Page

Making a Decision Between Mobile, Hybrid and Native App Development

Along with business requirements, various factors must be taken into consideration when selecting a mobile app development approach:

  • What would be the application capabilities across various platforms? Will the application have similar capabilities across platforms? All platforms are not able to handle application capabilities in a similar fashion. An example would be the iOS handles user notification and application states differently than Android.
  • A user’s experience can differ from one platform to another. Views that may be possible on iOS may not be able to be implemented on an Android and/or Windows mobile device.
  • Data synchronization needs must be taken into consideration. Does the native mobile application need to connect with a server to synchronize data? What data synchronization approach will be taken across all platforms?
  • Will performance be compromised when implementing solution across various platforms
  • How will the application be distributed when available across multiple platforms?
  • Storage capability and method must be taken into consideration when building the application across various platforms.

Top of Page

Mobile Web and Hybrid Apps are the First Choice at EPA

Mobile web apps are platform agnostic and do not require deployment directly to the device which significantly simplifies the deployment process. Building a web based application that leverages a responsive web template should be considered as the first option especially if the application is very simple and leverages only the common denominator functionality of HTML 5 that is supported across all browsers. Hybrid app development should be the second preference (Please contact the MARC (Mobile_AppMARC@epa.gov) for a list of suggested frameworks).

When developing a mobile web app consider the following key design principles:

  1. Detect device capability and adapt the content that will be delivered.
  2. Keep things simple. An effective mobile layout needs to be simple. Information presented needs to be structured into a layout that minimizes horizontal and vertical scrolling and any need for zooming.
  3. Mobile web app need to be easy to navigate while making the best use out of the device’s capabilities. Reducing the number of clicks to perform an action is critical to improve navigability of a mobile web application.
  4. Content must be adapted based on the device.
    1. Unnecessary text and links must be hidden when possible to make the best use of screen real estate.
    2. Different graphics should be leveraged for different screen resolutions.
    3. Video formats must be adapted to what is supported by the device.
    4. Interaction mechanisms must be customized based off of the capability of the device.
  5. Online/offline operation needs to be taken into consideration since the mobile web experience can be badly impacted based on the persistence of an internet connection. Mobile web applications should leverage local caching whenever possible.
  6. Speed needs to be taken into consideration. Mobile web applications should provide faster response times while delivering fewer resources to the user to minimize data usage on mobile devices.

Various questions need to be addressed when deciding which of the three outline mobile app development strategies should be leveraged.

  • How complex and graphics intensive is the mobile app?
  • Does the mobile application need to be deployed on multiple platforms?
  • What changes can be anticipated with the mobile app and can these changes be addressed with the chosen development strategy?
  • Is there an immediate need to deliver the app to the market?
  • What is the end of life for the application being developed?
  • Does the mobile app need to synchronize with back end systems or pull from data sources?
  • How frequently will the mobile app need the upgraded and does the application storefront deployment plan support these upgrade requirements?

Considering native UX versus portability is critical in the decision making process as to which mobile application development strategy to use since this has broad implications on the application manageability, time to market and cost.

[[{“fid”:”185753″,”view_mode”:”full”,”fields”:{“format”:”full”,”field_file_image_alt_text[und][0][value]”:”Mobile App Development Decision Diagram”,”field_file_image_title_text[und][0][value]”:””,”field_image_alignment[und]”:”none”,”field_caption[und][0][value]”:””,”field_caption[und][0][format]”:”inline”},”type”:”media”,”link_text”:null,”attributes”:{“alt”:”Mobile App Development Decision Diagram”,”height”:”265″,”width”:”433″,”class”:”media-element file-full”}}]]Increases in application portability will lead to a decrease in the richness of the native UX. Application which have a rich native UX often result in decreased code reuse and increased maintenance. Developing mobile application that have native UX will also lead to an increase in time to market.

Top of Page

Getting Approval for Your Mobile App

Once you have a plan for your mobile app, you need to bring it to the Mobile Access Review Committee (MARC). Do this before you start coding.

The MARC will review your idea and give you approval to start your project. They will ensure that you are aware of all applicable standards and any other security or legal requirements that your project will need to meet. Use the chart below to determine the appropriate form that you must fill out and submit to the MARC (Mobile_AppMARC@epa.gov).

I want to develop a…

If I want to develop a… Then… And the next steps are..
Native App for the Public MARC Review is Required
  • The submission process for native mobile app concepts is detailed in the System Life Cycle Management (SLCM) Procedure.
  • Review this procedure carefully prior to submitting a concept to MARC.
  • After completing all required steps, submit the Mobile Application Evaluation Form to MARC for review and consideration.
  • Development must not begin until MARC approves the mobile application concept.
  • Expect about two weeks for MARC to complete the evaluation of the mobile app concept.
Mobile Web App or Website for the Public MARC Review is Required
  • The submission process for mobile web apps and websites is similar to that for native mobile apps and is detailed in the SLCM Procedure.
  • However, offices need only submit the shorter Mobile Web Concept Review Form to MARC for review and consideration.
  • Web pages that are automatically optimized for mobile browsers by a WebCMS do not require MARC review.
Mobile App for Internal Use Only No Review Necessary
  • The sponsoring office must contact MARC to register the app or website during the development and completion stage.
  • Registering the app with MARC (Internal Mobile Application Registration Form) ensures that the originating office can capitalize on best practices from MARC, as well as create best practice opportunities for other offices in the Agency.

What if MARC Does not Approve my Concept?

Concepts that are not approved can be modified and resubmitted. The evaluation process is transparent and submitters will be provided detailed explanations for all decisions. For details on the criteria used for evaluation, see the guidance document: Mobile Application Evaluation Guidance PDF (9 pp., 116 K) Intranet

Before you start:

  • Make sure your application is approved by the MARC before development begins.
  • Plan to deploy your applciation to the EPA Mobile Web App template or use the app building blocks described in the EPA Native and Hybrid Mobile App Look and Feel document for native or cross-platform apps. If you intend to create a unique look and feel for your application, then you will need to submit a justification to the MARC.

Top of Page

Designing and Developing Your Mobile App

If you are coding a mobile app, you should follow the same guidelines you would use for web applications.

If you are coding a hybrid application, please contact the MARC (Mobile_AppMARC@epa.gov) for the recommended framework to use.

For both native and hybrid applications, design guidelines can be found in the EPA Native and Hybrid Mobile App Look and Feel document.

The following resources can be used when developing mobile apps for the EPA:

Google Analytics: All Mobile Web, Hybrid and Native apps should leverage Google Analytics:

There is a Google Analytics SDK for both Android and iOS located here:

Please contact the MARC for Agency GA Account Information that will be specific to your mobile application.

Mobile web apps using the OneEPA Standalone Template do not need to add any additional Google Analytics code to their application.

Top of Page

Section 508 Compliance

This guide, developed by the GSA, provides specific methods to help you make your content accessible and Section 508 compliant within your mobile application. Please review all requirements outlined in this guide and make sure ythat your application is in compliance before submitting your application back to the MARC for posting on Google Play and the Apple app store.

Top of Page

Security and MAAC approval for EPA Developed Applications

All mobile applications developed by the EPA will also be made available on EPA iphone devices which means that they will go through an expedited MAAC review. The MARC will handle submitting all mobile apps developed by the EPA through this process which involves a security code scan of .apk and .ipa files.

Top of Page

Gathering Feedback for your Mobile App

If you plan on collecting feedback please follow these tips. Also, keep in mind the requirements of the Paperwork Reduction Act (PRA). The PRA was enacted to minimize the paperwork burden for individuals; small businesses; educational and nonprofit institutions; Federal contractors; State, local and tribal governments; and other persons resulting from the collection of information by or for the federal government. The Act generally provides that every federal agency must obtain approval from the Office of Management and Budget (OMB) before using identical questions to collect information from 10 or more persons. An Information Collection Request (ICR) must be prepared when collecting information from 10 or more persons.

In order to avoid PRA requirements, it is strongly advised that you collect feedback from 9 or less external individuals.

Top of Page

Listing Your Mobile App

App Stores
For native and hybrid apps, please coordinate with the MARC in order to ensure that your app gets properly registered with the appropriate app store under EPA’s account (Google Play, Apple App Store, Blacberry Developer and Windows Phone Dev Center).

Reusable Component Services (RCS)​ and Developer Central
Every external (public-facing) EPA mobile app must be registered in RCS under the Mobile App category. The listing will subsequently be added to EPA’s Developer Central Application Showcase for marketing to the Developer community.

U.S. Digital Registry
The U.S. Digital Registry serves as the authoritative resource for agencies, citizens and developers to confirm the official status of social media and public-facing collaboration accounts, mobile apps and mobile websites. The MARC will handle registering your mobile application with the Federal Government Mobile Apps Directory.

Top of Page

Promoting Your Mobile App

Once the application is ready, the program team should develop a promotion plan with Communications.

A sample plan might include:

  • Press release (if deemed suitably newsworthy)
  • Progress Alert
  • Announcements on the EPA Website
  • Social Media Postings (Twitter and Facebook)
  • Email to select stakeholders with a request to amplify the message

Top of Page

Operation and Maintenance

Plan for updates: It is critical to think about how your mobile application will evolve over time. If properly managed, updates can demonstrate to the users that the mobile app is regularly maintained and that the developer is invested heavily into improving the mobile app. Ensuring that you have a recurring budget available for application improvements allows for you to plan for evolution in the user interface. Up front planning of improvements lead to reduced costs in the long term. Since updates are relatively easy to deploy, it becomes very easy to deliver new features progressively, as opposed to delivering them all at once. This approach is consistent with agile development methodologies, which allows you to focus on deliver the features which have the highest business values first.

Remember to test app upgrades: Often, mobile apps store data directly on the mobile device. As a result, updates have to address two possible scenarios. The first scenario is the simplest one where the user directly installs a new version of the mobile app without the previous version installed. In this scenario, there isn’t much to do apart from thoroughly testing the applications for bugs. The second scenario is where the user has a previous version of the app installed and has related data stored on the device and will install a newer version of the mobile app. If the data storage format has changed in the new version of the mobile app, a migration tool may be required to move from the old format to the new format. Scenarios like these must be taken into consideration when providing app updates to the public.

Retain users: Providing frequent as well as free updates to your mobile app is a great way to retain users. Users will be able to see that you are investing and constantly improving your mobile app. Free new features over time will also entice users to come back and continue to use your app. User retention is critical to long term success of any mobile app making planning for regular updates critical.

Use feedback from Google Analytics to improve the application:It is critical that you use leverage Google Analytics to understand which features are used the most and which are the least useful. This should guide which features might likely appear in a future version. Listening to user feedback and implementing immediate changes allows you to build a strong and committed user community.

Top of Page

Internal Mobile App’s Developed by the EPA for use on EPA Mobile Devices (iOS)

Note: The below process applies to iOS native/hybrid mobile applications only. iOS best practices for in-app authentication and encryption are recommended. Apple does not secure the data in the app. The security of the data is the responsibility of the developer.

  1. All internal mobile applications developed by the EPA must follow the MARC app review process outlined above. Once the app has been reviewed, the MARC will assist with deployment of the app and will coordinate with EPA’s Mobile Application Approval Committee (MAAC) for internal app distribution.
  2. MAAC app approval process which may involve additional security scans.
  3. The MARC, with developer assistance, will submit the mobile app to Apple for review through EPA’s Apple Developer Program for Business to Business (B2B) distribution.
  4. Apple Review and Testing.
  5. Once approved by Apple, the mobile app will be made available through EPA’s Volume Purchase Program (VPP). The app will now be ready for download on all EPA mobile devices.

Top of Page

Related Information

For guidance and best practice on coding a mobile web app, see these resources:

Top of Page