!

!

!

!

!

!

!

!

!!

Mobile Development Strategies

An argodesign White Paper !

by Chipp Walters

!!!!!

!!!!

!!

Mobile Development Strategies An argodesign White Paper !by Chipp Walters

!

M

!!Executive Summary !One of the Post-PC challenges for many Executives is understanding the issues around designing and building products for mobile devices. The purpose of this document is to help explain in an easy-to-understand way, different development strategies for building and deploying applications across mobile platforms. !This Executive Summary is a document argo uses to examine factors for assessing and ultimately selecting the correct strategy and technologies for mobile development for our customers and partners. !The Basics !Development tools and solutions for mobile deployment can be grouped into three application strategies: !

1. Native Application Development (Unique for Individual Platforms) 2. Web-Based HTML5 Apps 3. Cross Platform “Build Once Run Everywhere” Application Frameworks

!Development Methodology !In order to evaluate the various approaches, it’s important to have a basic understanding of project development methods, workflow and pipeline. There are many different methodologies used in development processes, and it is not the intent of this document to review them all, but it is useful to spend a little time going over some concepts. !Agile vs Waterfall !Both of these terms have been used quite a bit when referring to development methodologies. Essentially, the Agile development methodology was created in response

�3

to process issues between management and developers. Developers wanted managers to quit looking over their shoulders and demanding changes mid-stream, and managers wanted developers to spend more time showing them the current state of progress. In the older and more traditional Waterfall mode (PERT and GANTT models), managers and stakeholders may not see a product for months until after everything is finished, thus not allowing for interim feedback to affect the final product. !With Agile, developers agree to do specified work, unencumbered by management, in short periods of time called “sprints” which usually last a week or two. Then management and stakeholders can review, and iterate if necessary. !The iteration is the important part; this is where the app can be tweaked and refined to create a better end product. !Of course this is a gross oversimplification of the two methodologies, and more detail can be found in our 5D's white paper. The thing to remember is that structured iteration is a key part of understanding how efficient a development pipeline can be. !The Pipeline !At argo, we use a custom 5D project management approach. It combines the best of Agile iteration with the performance criteria inherent in Waterfall. For purposes of this document, we won’t concern ourselves with explaining all 5D’s, but will focus on the last three: Design, Develop and Deploy. !As far as Design goes, we will assume a project already has a world-class User Experience or User Interface (UI/UX) designed — by argodesign, of course! — and tested, and signed off by all stakeholders. Note: This is most different from Agile, where UIX is done simultaneously with development. !The next step is to convert the UIX design into a working application. Each Application Strategy listed below has a specific workflow pipeline. Understanding the pipeline is helpful in assessing a strategy’s strengths and weaknesses.

�4

!All pipelines will begin with Design and end with Deploy. This document does not review any of the mid-tier application levels and instead only focuses on the client application design. Let’s take a quick look at each Application Strategy. !Native Application Development (Unique Tools for Individual Platforms)!Platform-specific “Integrated Development Environments” (called IDEs) provide maximum control, device access and execution speed for their respective operating systems and

devices. While these IDEs do not have the multiple domain expertise overhead which is part of the HTML5 development pipeline (more on that later), they do require experienced and

�5

seasoned C and Java programmers, and there is little overlap either in individual expertise or code reusability. !To program in XCode for iOS, Eclipse and Java for Android and Visual Studio for Windows 8 requires experienced senior programmers all working in parallel, and a rare team lead who understands and can possibly work in all programming environments. A tall task, for sure. Plus, keep in mind each platform requires its own code base, so keeping builds in sync across platforms can be an issue. !Native Pipeline !Typically, unique interface elements are created for each platform. So, for three platforms there can also be three times the work on interface designs. Next, the assets are extracted by a single team and forwarded to each platform development team. There the app is coded. If a mid-tier state is needed (not always), it is coded as well by a different group. Finally, a testing group tests the three different applications on the three different platforms. !Evaluation

Native PipelinePro Con

Typically elegant WYSIWYG IDEs allow for faster development PER platform.

Different developer expertise per platform which is expensive when used to develop apps for multiple platforms.

Good debugging tools and tightly integrated development environment.

Multiple codebases to manage. One for each platform.

Superb for developing a single app for a single platform.

No forced uniformity of interface across all apps and platforms, which many times is desired.

Can be delivered as an application in the platform’s app store.

Difficult to sync builds and features across all platforms. Much more work keeping all platforms up-todate and maintained.

Can have platform specific user interface. Does not create browser HTML5 applications.

Complete access to all platform APIs.

�6

!!

No requirement to be compatible with the platform browser or standards.

Offline caching of data.

Broad rather than deep workflow pipeline. No need for too many specialties.

Compiled apps generally run faster.

Pro Con

Native Pipeline Report CardIssue Notes Grade

Cost of Development

All apps are complete unique codebases, therefore each application needs to be programmed from scratch. Multiple platforms equals multiple projects, multiple products, multiple management and multiple testing. Overall the MOST expensive way to develop for all mobile platforms.

D

Speed of Development

While the pipeline is shorter, the teams are broader. Unlike Web-based, which has multiple steps in a single pipeline, this approach has fewer steps but more pipelines. It can be difficult to manage process across multiple platforms.

C+

�7

!!Web-Based HTML5 Apps !There has been an ongoing search for a ubiquitous WYSIWYG IDE for HTML5 for some time. Originally, it was thought an easy Flash-like app builder would be forthcoming from Adobe and other vendors, but nothing has yet surfaced which is reasonably adept at providing the shortcut approaches that 4th-generation programming toolsets have already delivered. !Consequently, the main issue for those wishing to rapidly build and deploy HTML5 is the lack of an integrated and intuitive WYSIWYG (What You See Is What You Get) authoring

Quality of Build

Generally, the highest quality apps come from a native programming approach. This is because the tools and optimizations are geared specifically for each platform and there are generally better testing and debugging tools for platform-specific IDEs.

A

Maintenance

Assuming multiple platforms, each codebase must be separately maintained. So, if a change is to be made or a feature needs to be added, all code bases must be updated, requiring twice the work, testing and deployment of updates.

D+Risks

Multiple parallel development paths can be problematic, especially if all are set to ship product at the same time. Also, it can be difficult to replace experienced programmers if they leave.

C

Issue Notes Grade

�8

system where controls can be dragged onto a canvas and instantly be set up for coding and use. Currently, in order to build HTML5 Apps, some or all of the following technologies must be mastered: !

1. HTML 2. CSS 3. DOM 4. Javascript 5. JQuery 6. Client-side frameworks and Libraries like AngularJS, Bootstrap, Ember 7. Server-side frameworks and Libraries like Node JS 8. Hybrid frameworks (both client and server side) like Ruby on Rails 9. Middle-tier application languages like C#, php, Ruby, Python

!HTML5 Pipeline !In an HTML5 development pipeline, one set of interface elements is created for all platforms. Next the assets are extracted and then converted to HTML/CSS/Javascript by a single team and forwarded to the client-side (browser) development team.

�9

Many times the HTML/CSS/Javascript UIX's need to be refactored for the specific framework being used. Then the app is coded. Finally, a testing group tests the web browser application across the three different platforms. !!!Evaluation !

HTML5-Based PipelinePro Con

Typically Browser-based so it’s available on all browsers.

Because it runs in a browser, support for device-specific APIs varies a good bit.

Because it runs in a browser, it is theoretically possible to create a single codebase to support all mobile AND desktop browsers.

Requires expertise in A LOT of different domains.

Can use responsive web design practices to reconfigure for different screen resolutions (smartphone vs tablet).

HTML5, browsers and CSS comprise a constantly changing platform, and apps can quickly and easily break due to mobile browser updates.

Workflow pipeline is easy to specialize for different developers.

Because not native, the app may perform more slowly.

Open Source tools offer a variety of options for developing and deploying.

More difficult to change UIX in the middle of development because many different specialists are needed to rebuild interface code.

Single development effort is much less expensive than having to support separate developments for each platform.

Can be resource-intensive and expensive to develop because of the complex workflow and all the people needed to build the app.

Typically does not need recompiling for new devices. It just works.

Complex apps are difficult and can be time-consuming to build.

No desktop solution. This does not take into account the Javascript/HTML frameworks discussed below.

Cannot be delivered as an application in the platform’s app store.

Limited offline caching of interactive elements and user credentials.

�10

!HTML5 Report Card

Issue Notes Grade

Cost of Development

The lengthy pipeline and the multiple individuals with specialized domain knowledge creates larger and more expensive-to-manage teams. The fact that there is a single unique codebase for all mobile platforms offsets the cost somewhat.

B

Speed of Development

The lengthy pipeline, and issues with iteration outside a particular group's scope of expertise, can sometimes create problems for working in an Agile environment. Thus, the speed of development for this approach suffers. It is very easy to run and test apps using this approach, as they can run in a development environment’s browser.

C+

Quality of Build

While some mobile APIs are accessible from browsers, they are somewhat limited. And because all client side code runs in interpreted modes, the speed for some functions may suffer. Still, network latency is typically the biggest single speed factor, which can help mask slow performance concerns of the browser.

B

MaintenanceUsing a single codebase, this approach scores high marks, only slightly offset by the possibility of platform-specific updates with changing browser compatibility.

A-�11

!Cross-Platform “Build Once Run Everywhere” Application Builders !These toolsets can be grouped into 2 segments. !1. Fourth Generation Programming Languages (4GL) considered the easiest to use

with the most potential for rapid development. They often use human–readable syntax and allow for extreme consolidation of tasks focusing on Rapid Application Development (RAD). Typically, these tools are great for smaller applications and tend to become unwieldy for large teams building large applications. This makes them a good fit for mobile. These tools typically use a runtime player (like a Flash player) which is embedded in the specific platform native app, thus performance, while good, still isn’t up to the native app standard. Not a good choice for twitch games, but simple animations can be created and run just fine. Examples include Flash, LiveCode, RealBasic, RAD Studio XE3 and others. !

2. Javascript-based Application Toolsets can also create native cross-platform applications. While based in a more traditional, multi-staged pipeline approach, they don’t have the RAD advantages of the 4GLs but are still quick to learn and can

Risks

The single pipeline and the fact that all code runs in browsers makes for less risky development. Specialty web app developers are easier to find than experienced C++ application developers. Cannot be chosen if the end goal is to be in app stores. Must be deployed on the web.

BIssue Notes Grade

�12

provide great leverage in terms of effort vs speed of development. These tools generate a Javascript-in-Browser solution, which can compile to a native app – which is actually an app running a browser instance. Because of this, the speed is not as fast as native, but acceptable.Examples include Appcelerator Titanium, PhoneGap, and others. There are also other languages embedded in cross-platform IDEs such as LUA.

!Experienced developers are needed to push these tools to maximum performance, and it may be difficult finding the right lead developer and team. These toolsets typically have a powerful IDE where all interface design, asset management and coding is done. Some can even create content directly in the IDE. These frameworks encapsulate a WYSIWYG environment, with a code editor using a Just In Time (JIT) compiler (like Java) OR browser to review the app as it is built in the development environment. This methodology creates a very fast design, build, run, test loop (no compiling necessary) which enables superior development times. !While these tools create apps which perform somewhat faster than browser-based apps, rarely do they produce apps as fast and snappy as if programmed natively. Still, as mentioned before, many times network latency is a far greater performance inhibitor than the small perceived performance lag inherent to these frameworks. !These tools also have better API access than browser-based apps, yet still not as good as native toolsets. Most can be extended using native coded external modules. So, if a feature is not yet supported, it can be added via a custom native module. !Compiling for different platforms is simple and direct. Plus, most of these toolsets can build stand-alone applications for Windows and Mac desktops as well. argo note: In perhaps the fastest development project to date, argo team members developed a full pilot app for Sesame Street with both Teacher and Student modules running on Android tablet using a 4GL in under one month. Not one bug was reported during the pilot run. !

�13

Cross-Platform 4GL Pipeline !In a 4GL development pipeline, one set of interface elements is typically created for all platforms to provide an identical User Interface. Next the assets are simply extracted by a single team member (or sometimes by the developers themselves), and forwarded to the app development team.

There the app is coded. If a mid-tier state is needed (not always), it is coded as well by a different group. The developer group creates separate builds for each platform. Finally, a testing group tests the application across the 3 different platforms. !Cross-Platform Javascript Pipeline !

�14

Cross-Platform Javascript Description: In a HTML5 development pipeline, one set of interface elements is created for all platforms. Next the assets are extracted and converted to HTML/CSS/Javascript by a single team and forwarded to the development team.

!There the app is coded. The developer group creates separate builds for each platform. Finally, a testing group tests the application across the multiple different platforms. !!

�15

Evaluation !

!!!

Cross-Platform 4GL PipelinePro Con

Typically elegant WYSIWYG IDEs allow for extreme speed in development. Apps can be built in half the time.

There can be significant learning curve in learning new IDEs and framework.

Simple workflow. Same person lays out the app and codes it, interactively testing each step.

Can be locked in to one vendor.

Single codebase compiles to multiple native apps. Because of JIT compiler, still not as fast as native compiled apps.

Performance typically better than browsers. Less than 100% APIs supported.

Creates apps which can be offered in each platform’s app stores.

Not as good for large apps or large teams of programmers.

Access to most platform APIs. May need to add custom modules for custom features.

Easy to create bug-free code. Many do not create browser code so resulting app CANNOT run on the web (though it can connect to web services).

Can create desktop apps with the same codebase. Can be difficult to find the best developers.

Easy to create offline caching

Cross-Platform 4GL Report CardIssue Notes Grade

Cost of Development

Because of extreme RAD, the time to develop is short. And because it is short, it is less expensive. Also, fewer people are needed in development.

A�16

!!!

Speed of Development

Again, because of RAD and existing libraries, the time it takes to complete a project is significantly shortened. A

Quality of Build

Still not as fast or robust as a 100% native app. Plus may not have support for all platform APIs. The quality of the build depends more on the developer experience than other approaches. Supports more APIs than HTML5 development.

B+Maintenance

Single codebase creates different native apps for each. Each platform needs to be built and deployed for. Good solution if you MUST HAVE the app in an app store and want minimum maintenance.

B+

Risks

Just like every other approach EXCEPT Native Development, you can ‘box’ yourself in to performance and feature corners as this technology does not support 100% APIs, nor does it render as fast as Native. Most Agile of all approaches. Very easy to iterate design changes. Also, important to assess the risk of working with a single vendor toolkit. Plus, does not create browser compatible builds.

C+

Issue Notes Grade

�17

!!!

Cross-Platform Javascript Framework PipelinePro Con

Typically elegant WYSIWYG IDEs allow for good speed in development.

Locked in to one vendor.

Single codebase compiles to multiple native apps. More complex workflow. Similar pipeline to HTML5 Development.

Creates apps which can be offered in each platform’s app stores.

Still not as fast as native compiled apps. Performance same or slower than browsers.

Access to most platform APIs. Less than 100% APIs supported.

Works well with larger teams of programmers than does 4GL.

May need to add custom modules for custom features.

Can also deploy builds in browsers. Can be difficult to find the best framework specific developers.

Most frameworks offer offline caching.

Cross-Platform Javascript Framework Report CardIssue Notes Grade

Cost of Development

Similar pipeline to HTML5 Development. Single pipeline with lots of stages. B

Speed of Development

Again, similar to HTML5 Development. C+

�18

!!!!!Overall Scorecard !!!

Quality of Build

Performance is slower than HTML5 in iOS due to problem with Apple not allowing developers to embed Apple’s faster JavaScript interpreter. Still, has more APIs and nice cross-platform support for them. Can be designed responsively.

B+Maintenance

Using a single codebase, this approach also scores high marks, offset by the need to compile for each platform independently. B+

RisksSame as HTML5. Longer pipeline creates more difficult Agile process. Also, important to assess the risk of working with a single vendor toolkit.

B

Issue Notes Grade

Cost of Development

Speed of Development

Quality of Build

Maintenance Risks

Native D C+ A D+ CHTML5 B C+ B+ A- B

4GL A A B+ B+ C+

�19

!!!!!!Recommendations !There’s not a single best Mobile Application Strategy. For instance, at argo we’ve used a different approach for a single platform Android tablet app versus a multi-platform web-based application. This is because a mobile application strategy is based on many factors including target application platform requirements, budget and schedule, maintenance requirements and specifically conversations with clients and their customers. We recommend you contact argo for more information on how we can help you craft your mobile strategy and then help you build and deploy your mobile applications. !

Appendix Some notes about the Kindle and Nook !Both Kindle and Nook have two levels of devices. The first level is called the “Reader.” The Kindle Reader and the Nook Reader are e-ink (also called “paperwhite”) enabled monochromatic devices with extremely slow display rates. As such, they are not capable of executing any but the most simple applications and there are no third party apps for these devices. The full-color Kindle Fire and Nook HD are both Android devices, and can run Android apps with little to no modification. !

Javascript B C+ B+ B+ B

Cost of Development

Speed of Development

Quality of Build

Maintenance Risks

�20

Observations about Windows 8 !Microsoft has a confusing set of operating system offerings. In fact, Windows 8 comes in three different flavors. !1. Windows 8 (Intel) for desktops, laptops and slates. 2. Windows 8 RT (Arm) for tablets. 3. Windows 8 for phones. !Each is compiled for different processors. This presents problems for application strategies outside of native and browsers. Many cross-platform frameworks have announced future compatibility as they are just now evaluating their own strategy for deploying on Windows 8 RT and Windows 8 for phone. Currently, it is unclear if Windows 8 RT will survive in enough quantities to justify third party vendors creating custom toolset builds supporting it. Its sales are lackluster with !!projections of less than $0.5 million this quarter. Many industry pundits believe the Intel Windows 8 tablets, with full support for Windows 8 (and Win7) apps, may be the product consumers eventually choose. In any case, it’s clearly a risk for any institution to establish a Windows 8 RT baseline as it’s a sole standard platform. !Google Chrome OS and Chromebook !Considered by Gartner Research as a “Post-PC” mobile platform, Google’s Chromebooks are netbooks with a Chrome browser-based OS which stores virtually all data in the Cloud. This very inexpensive laptop has a number of features which may be preferred over PC based netbooks and mobile tablets for delivery of learning applications to education customers. In late 2012, Google offered a $99 Chromebook laptop for classrooms, an unheard-of and unbeatable price point. Google Chromebooks have only 16GB of flash storage, so little if anything can be stored locally. Still, the devices are well designed with the best of breed Google Apps (Docs, Spreadsheet, Presentation, Sites and others) and are a perfect fit for many who don’t need or want a full-fledged laptop. Because everything

�21

is stored in the Cloud, if the laptop is lost, stolen or broken, remediation is quick. Just replace the laptop with a new one, login and the student or operator is back where they left off. Another advantage of Chromebooks is that they run Flash inside the browser. Therefore, a lot of Flash content not available to mobile devices is still available to Chromebook customers. Since Chromebooks run all software in a browser, the only option for deploying applications is to create apps using HTML5 frameworks and toolsets. Lastly, to date, there are no known viruses which attack a Google Chromebook. So, using the Chome OS keeps the student or operator safe from malicious code attacks. !What to do about Flash? !As we know, Flash is a dying mobile delivery platform. It has never worked on Apple’s iOS and now Android has dropped support for it. Many content providers have substantial assets built in Flash which they now need to reassess and probably repurpose. It should be noted that there are OS platforms which still run Flash. All modern desktop browsers run Flash just fine. Most netbooks can run Flash, but some struggle with heavily animated and high vector count Flash swf files. Google’s Chromebook runs Flash but also may see some performance problems with the more processor-intensive Flash files. !Types of Flash Files !Flash files, called “movies,” can be broken down into a few different groups. These are listed from easiest to repurpose to hardest to repurpose. !1. Media Wrappers 2. Content Players 3. Animated Content 4. Flash Applications !Flash Media Wrappers !Media Wrappers are video players, slide presentations, document viewers and other simple tools which store their assets outside of the Flash movie application. So, the Flash application code is fairly straightforward and has a small footprint as they have only a

�22

single purpose: to play an external filetype. For instance, a typical Flash video file outside the app has an .flv extension. This means it can only be played by a Flash player. It is a fairly basic task to recompile the video with an HTML5 capable codec and have it available for delivery on mobile. In fact, as long as the content is stored OUTSIDE the player, it can generally be converted and repurposed to play in an HTML5 wrapper. !Flash Content Players !Content Players are more evolved versions of Media Wrappers. They can have multiple purposes such as playing a movie while scrolling text in a separate pane. Or showing a slideshow while a voiceover is playing. Typically Content Players, like Media Wrappers, store their content in files outside the main movie application and are fairly small in size and function. In this case, repurposing these players is simply a matter of converting the content and then writing a small Player app to reproduce the functionality of the original Flash Content Player. !Animated Content !Content which is created and animated inside of Flash is much more difficult to repurpose. If it is mostly linear in nature, it can be converted (either via screen capture or Adobe’s Flash application, or various convertors) to a video, which can then be embedded in a mobile application. If it is not linear in nature, then it becomes a tedious task to extract the assets and reanimate in the mobile application. While there are various toolkits which claim this ability, none is foolproof and many just ‘barely’ work. !Flash Applications !Flash and Flex can create very code specific Web and Adobe Integrated Runtime (AIR) applications which rival the functionality of many desktop applications. To convert and repurpose these types of apps requires a complete restart and recode from the beginning. This is the most time and resource intensive conversion process and is decidedly NOT simple. !

�23

Flash Converters !There are many products which claim to convert Flash to HTML5 and other formats. These include Google Swiffy, Adobe Wallaby, Recool, Thundersoft Flash to HTML5 and others. Most can convert only specific filetypes, like banner ads. Rarely is the conversion 100% identical to the original. There is yet no silver bullet for converting Flash apps to other application runtime or source code.

�24