Mobile Application Development

Transcription

1 Mobile Application Development A White Paper outlining mobile application development strategies. Synopsis: This white paper compares architectural and business model differences between multiple mobile application development strategies for enterprise mobile development. Enterprise architects, CTOs, and CIOs should understand these differences before choosing a long-term strategy for multi-screen mobile development. The focus of this paper is on installed mobile applications vs. inbrowser mobile applications. While having your users rely on the browser is a valid option, it is out of scope for the purposes of this paper. The following is not intended to be a definitive or exclusive list of all criteria but rather a starting point to assemble thoughts on this topic. About the Authors

2 Duane A. Nickull and Matt MacKenzie are co-founders of the Überity technology Corporation, a company that has developed an enterprise mobile payment processing framework for Java developers along with several Java libraries for large scale graph databases. In the past they have participated in many standards efforts including chairing the OASIS SOA Reference Model Technical Committee, contributing to the W3C Web Services Architecture, being the coarchitect of the United Nations ebxml and UN/CEFACT ebusiness architectures, and being a specially appointed technical liaison between OASIS, IETF, IEEE, the United Nations, and ITU. Both Matt and Duane have authored numerous industry white papers and lectured at universities in countries on five continents. Duane regularly works with intelligence agencies in various countries. Both Mr. Nickull and Mr. MacKenzie were previously employed by Adobe Systems as a Sr. Technical Evangelist and Senior Engineering Manager respectively. License: This work is licensed under a Creative Commons Attribution 2.0 Unported License. You may redistribute and quote from parts of this article however attribution is expected. There is no need to seek explicit permission to reuse part of this paper or to quote from it.

3 Table of Contents MOBILE APPLICATION DEVELOPMENT STRATEGIES Synopsis: About the Authors License: THE MOBILE APPLICATION DEVELOPMENT OPTIONS: NATIVE, PORTABLE, AND HYBRID NATIVE CODE PORTABLE CODE INTERPRETED PORTABLE CODE CROSS COMPILING PORTABLE CODE FOR MULTIPLE MOBILE DEVICES HYBRID PORTABLE CODE VARIANTS THE MOBILE APPLICATION DEVELOPMENT LANDSCAPE MAJOR SMARTPHONE PLATFORMS CHALLENGES POSED TO MOBILE APPLICATION DEVELOPMENT STRATEGIES BY A FRACTURED MARKETPLACE COSTS PER APPLICATION 15 TECHNICAL ISSUES AND USER PERCEPTIONS AFFECTING MOBILE DEVELOPMENT STRATEGY 16 APPLICATION INSTALLER SIZE 17 INSTALLED APPLICATION SIZE 17 RUNTIME PERFORMANCE 18 MOBILE BANDWIDTH USAGE 18 CONSISTENCY OF FUNCTION AND APPEARANCE 19 RELEASE DATE SYNCHRONIZATION 19 CODEC SUPPORT FOR MEDIA FORMATS 19 BATTERY USE 20 REUSE OF EXISTING ASSETS 20 OTHER CONSIDERATIONS THE PLAYERS IN PORTABLE CODE ADOBE FLEX AND AIR FOR MOBILE DEVELOPMENT AIRPLAY CORONA PHONEGAP PARTICLE CODE TITANIUM CONCLUSIONS

4

5 The Mobile Application Development Options: Native, Portable, and Hybrid Native programming language models comprise workflows and code systems that are designed to be compiled into machine code, which is executed without further manipulation or re-interpretation, directly by a computer's processors. In this context, machine code may be regarded as the lowest-level representation of a compiled and/or assembled computer program. When targeting multiple devices, the code for each platform may need to work with different mobile Application Programming Interfaces (APIS) and use a different syntax, which makes it difficult to reuse a single code base for multiple platforms. For mobile application development, this is the de facto default choice for many organizations. Portable programming language models, by contrast, allow bytecode or scripts to be interpreted by an intermediate layer that enables it to run on more than one device. The major benefit of the portable model is that the interpretation tier enables the same code to run on multiple systems (hence the term portable). Unlike native code, portable code need not be recompiled into machine code for each specific target platform, yet the source code can be cross-compiled to achieve the appearance of native applications for different devices. Compared to their native counterparts, applications written using the portable model are likely to have more limited access to platform features and functions. A Hybrid approach, defined by using Native Extensibility to extend the capabilities of the portable approach, can mitigate this problem and paves the way for applications to realize the key advantages of both approaches. Note that the differences between the native and portable models are more subtle than simply classifying languages as either compiled or interpreted languages. While most programming languages are generally divided into these two categories for convenience, in practice most languages are not exclusively compiled or interpreted. Perl is often used as an example of an interpreted language yet it can also be compiled 1. Likewise, there are C interpreters there- an- interpreter- for- c

6 Modern trends toward just-in-time compilation and byte code interpretation at times blur the traditional categorizations of compilers and interpreters. That said, machine code, which runs directly on a processor, should not be confused with byte code, which is executed by an interpreter. It is important to understand the characteristics that define each model at an abstract level before mapping key success factors to tangible computer platforms and languages. The term computer in this context encompasses many devices including laptop computers, smartphones, tablet devices, and just about anything else with a Central Processing Unit (CPU). The key focus remains on mobile application development. Native Code Native code must be compiled for each targeted platform upon which it will run as shown in Figure 3.1 Figure 3.1 Native code as a Mobile Application Development strategy

7 In figure 3.1, the core application logic is encoded into code (a syntax), which compilers use to generate native binary code application/installers (labeled Application Installer) for multiple platforms. Each native installer or application runs only on the system for which it was compiled. Since each platform has a unique runtime environment, the logic must be encoded, written, and maintained for each platform. The encoded logic (code) can differ significantly based upon the options available to the developers who work with each platform. Core communication classes are one example of differences between platforms. One platform might support only basic Hyper Text Transfer Protocol (HTTP) and HTTP/S, while platforms two and three might support additional communication protocols such as the Universal Datagram Protocol (UDP). Further, the underlying APIs may be different for each platform. Similarly, decoders for binary images might support only certain formats for each platform such as Portable Network Graphics (PNG) or Graphic Information Format (GIF). In the smart phone market, there are several variants of native programming models. The Apple ios platform uses Objective C targeting a UNIX-based operating system. The Google Android Platform has both a native Software Development Kit (SDK) and a Native Development Kit (NDK) targeting a Linuxbased operating system. The BlackBerry Tablet OS platform uses multiple development SDK s including QNX and Adobe AIR 3. Portable Code Portable code, by definition, can be compiled or in its original source syntax, and be run or interpreted on more than one mobile device. In some cases, this portable code can be used to either generate native applications that can be run on targeted platforms. Interpreted Portable Code When the portable code is to be interpreted, developers begin by writing code that encapsulates the mobile application s logic. The developer then exports either a binary or scripted version of the application (a set of instructions) that can be run on more than one platform as shown in Figure 3.2. During runtime execution, an Interpreter, running on the mobile device, interprets those 3

8 instructions into actions and the application runs. HTML and JavaScript, which are not compiled during the development time but rather interpreted at runtime, are examples of this approach. Figure 3.2 Interpreted Portable Code Architecture for mobile applications The key difference between this approach and native code for mobile application development is that one common code base (labeled Code (syntax) ) is created and maintained while targeting multiple platforms. Logically, this approach imposes some restrictions on developers. The most notable differences are: 1. The set of mobile development Application Programmatic Interfaces (API s) that is supported by the portable syntax is often a subset composed of the common capabilities offered by the platforms targeted. As such, certain features may not be available. Mobile developers using this approach may need to use a native extensibility mechanism to access features and functions on specific platforms that are not covered by the portable code itself. Native extensibility is a basic capability of portable coding platforms such as Nitobi s PhoneGap mobile development platform. 2. When creating applications using a portable code SDK, developers may need to write extra code to test whether certain features are available for each platform. This is a relatively minor concern.

9 3. Because portable applications are often interpreted as an intermediate step at runtime, they may not execute as fast as native code applications. However, most perform within acceptable targets and native extensions can help here too. For many organizations the affect of these two restrictions are far outweighed by the advantages of using interpreted code, including lower costs for development and maintenance over time. Because the responsibility of supporting functionality across multiple platforms does not fall to the code owner, development and maintenance costs are often lower. Cross Compiling Portable Code for Multiple Mobile Devices A third strategy is to use a cross compiler to transform portable source code into a native machine code format, which eliminates the need for intermediate interpretation. Applications built with this methodology are completely indistinguishable from pure native applications in their behavior since they do not require a runtime interpreter. This variation is shown in Figure 3.3. The Application/Installer can be interpreted directly by the environment upon which they run. This approach enables organizations to use a single source code base to target multiple device platforms.

10 Figure 3.3 Cross Compiled Application Installers This approach is particularly valuable when targeting a mobile platform that does not provide developers with the freedom to use intermediate interpreters. Hybrid Portable Code Variants Hybrid approaches combines the multiplatform advantages of the portable model with some of the platform-specific advantages of native applications and mitigates the impact of a higher level set of API s by using Native Extensions. In this depiction (Figure 3.4) of a hybrid model, a compiler is used to compile the Application Logic into a portable binary code package (labeled Byte Code / Script for Interpretation below). The Application Logic can also be encoded into native applications and native-appearing applications that reference an intermediate runtime environment. Instructions to bootstrap the runtime environment are compiled within the Application / Installer package. To most end users, the applications built using this variant are indistinguishable from native applications when being installed and used.

11 Figure 3.4 A Hybrid Approach to Multi-screen Mobile Application Development The hybrid model provides other advantages as well. For example, compilers can package native extensions for each platform, so that multiplatform applications are not limited to subset of features common to all platforms. Generally, one common code base can be used, but logic (as shown in figure 3.4) may be needed to ensure features are present before attempting to use them. function init() { if(accelerometer.issupported) { l.text = "Acquiring data"; a.addeventlistener(accelerometerevent.update, reada); } else { l.text = "no accelerometer support";

12 } } Figure 3.4 An if-else statement in ActionScript used to test for accelerometer support. Code Courtesy of James Ward. Key examples of portable code packaged to appear native include Java code compiled and packaged into a native executable (*.exe) 4 for the Windows operating system and ActionScript compiled and packaged with the Adobe AIR runtime as a native package (such as an *.apk file for the Android operating system) that also could include native extensions. Applications that are crosscompiled, as described in the previous section, may run without the presence of an intermediate interpretation layer. The hybrid approach has proven very successful as demonstrated by the growth of Java for use in the enterprise. While SAP s ABAP and Microsoft s.net platforms continue to be popular, Java holds top spot on the TIOBE index for most popular programming language as of May The Mobile Application Development Landscape The emergence and growth of the smart phone and smart device (including tablet devices) market since the release of the first iphone to the public in June has been so rapid that many CIOs and CTOs have lacked the historical data needed to make informed decisions on corporate strategy for mobile development. A major inflexion point is expected between 2013 and 2014 when, according to Morgan Stanley s Mary Meeker, Internet access via portable devices will overtake wired Internet connections 7. Potentially, the majority of electronic interactions between an enterprise and its customers may be conducted via mobile devices shortly thereafter. While the timing of this event is difficult to predict, the ultimate result is not, given the continuous, rapid pace of the mobile marketplace. No matter what they may have done to date, most enterprises need to start 4 a- java- program- into- an- exe Despite what they may have done to date, most enterprises need to start adopting NEW long term mobile strategies immediately. A choice between Native or Portable/Hybrid development strategy is one of the very FIRST CHOICES they will have to make. 7 meeker- mobile- internet- will- soon- overtake- fixed- internet/

13 adopting long term mobile development and management strategies immediately. Deciding to pursue a native, portable, cross compiled or hybrid development strategy is one of the first choices they will have to make. To make the correct decision, an understanding of the marketplace and relevant major players is required. Major Smartphone Platforms Apple s ios-based iphone was the first touch-screen smart phone to achieve widespread popularity. Since its introduction in 2007, Apple has sold more than 70 million units according to Mobile Crunch 8. The iphone is not the strongest selling platform however. ComScore released a study 9 in January 2011 based on surveying more than 30,000 U.S. mobile subscribers and found Samsung to be the top handset manufacturer overall with 24.9 percent market share. Google Android took the lead among smart phone platforms with 31.2 percent market share, after two months in second place. Research In Motion (RIM) also held on to almost 9% of the market with Apple trailing the pack at only 6.7 %. 8 sold million- iphones- last- quarter- over- 70- million- since- launch/ 9http:// le_subscriber_market_share

14 Figure 4.1 Top smartphone platforms for the three months ending Feb 2011 (source: _U.S._Mobile_Subscriber_Market_Share) With the April 2011 release of the BlackBerry PlayBook tablet and several subsequent Android based tablet releases scheduled for 2011, analysts have projected the major contenders as Google, RIM, Apple, Microsoft, and HP (Palm) in that specific order as of February Figure 4.1 is consistent with several independent projections. Challenges Posed to Mobile Application Development Strategies by a Fractured Marketplace A logical conclusion of the rapid spiral growth and continued fast pace of innovation is that most enterprises will have to support more mobile platforms than they have supported in the past. Without a historical reference, most CIOs and CTOs are navigating uncharted waters when it comes to deciding on a 10 ile_subscriber_market_share

15 long-term mobile development management strategy accounting for multiple device platforms. To begin with, it is useful to examine the business and financial burdens imposed by portable and native application development methodologies. For global enterprises in the Fortune 1000, it is highly likely that in the foreseeable future, their mobile applications will have to run on at least three and possibly four of the major platforms offered by the device platform vendors covered by Android, Microsoft, Apple, and RIM. Costs per Application The average costs of a mobile application vary based on the platform targeted and the features requested. According to a 2010 study by Forrester 11, development of a basic no frills mobile application starts at around $15,000 USD, while more sophisticated applications cost upwards of $150,000. Other quotes post flagship applications at around $500,000. These figures typically do not include the costs of maintaining each application over time, which can be considerable. Developer pay scales vary based on skills. Objective C developers in Brooklyn, NY command an average of around $134,000 per year according to SimplyHired.com 12, while Flash developers in the same neighborhood earn roughly 60% at $77,000 per year 13. Many corporations started by outsourcing mobile development to create their first mobile applications. As the skillset becomes more mainstream, it is likely that more mobile development will be done in-house. Most enterprises targeted the ios platform as their first platform because Apple was first to the market. Without in-house Objective C programming skills, many projects were outsourced. Now many of their first applications are being rewritten for Android, and soon may have to be rewritten for Windows Mobile and RIM devices. The conclusion is that building and supporting three or four separate code bases is not a financially desirable long term strategy. Enterprises that choose the native code route (or have requirements forcing them to use it) will incur significant costs as they repeatedly map application logic to each new platform to- build- a- mobile- app- heres- how- to- convince- the- cfo / 12 objective- c+developer/l- brooklyn,+ny 13 flash+developer/l- Brooklyn%2C+NY

16 Enterprises that choose a portable code strategy let the programming platform vendor incur the costs of mapping logic to each platform and save lower costs by developing and maintaining a single code base, as shown in Figure 4.2. Figure 4.2 Native development incurs significant costs for each additional supported platform. Clearly, developing and maintaining multiple native code bases for each platform is likely to be an innefficient and costly mobile strategy. The primary cause is that the different programming languages/models and APIs of each platform must be learned and accounted for by the application s owner rather than pushing this cost to a portable code vendor. The portable code vendor is better able to absorb this cost because it divided amongst all who use the platform. While technical restrictions may force some enterprises to pursue a native application strategy, many enterprises will be best served by using a portable or hybrid model to reduce multiplatform mobile development costs. One challenge of this approach is that it is extremely difficult for any crosscompiler vendor to completely expose the complete set of underlying native API s within a cross compiler API set. There are also incompatibilities amongst targetted platforms covered this sort of functionality. As such, cross compilers may either support a common subset of API s or comliment the offerings with native extensions. Technical Issues and User Perceptions Affecting mobile Development Strategy Where multiple selections exist for a given application function (such as clients) end users tend to select applications based on a limited number of key

17 criteria, including confidence in the vendor, quality, performance, cost, and application size. Confidence in a particular vendor relies heavily on the ability of the user to establish the identity of the application distributor. If the application contains malicious code, it is imperative that the identity of the application vendor be established The overall quality of the application is key and is often reflected in how the application is ranked and how users perceive it. Users also gravitate towards reference applications, for example the Android GMail client built by Google is considered a reference application. Application Installer Size Application installer size is a factor to consider because some users prefer applications with a smaller installer. Here, native applications have an advantage over portable solutions because portable applications may have to include interpreter code or additional logic to determine if features are available to the application. Users tend to conflate application installer size with the size of the application. If users see a large application installer, they often assume the application itself will take consume more memory. It is true, however, that a larger application installer will take longer to download. The truth is that application installer size does not necessarily correlate linearly with installed application size or memory usage. Sometimes, a portable application installer is also bundled with the runtime, which may be shared by several applications. If it detects that the runtime is already present, it may not install the runtime meaning a small percentage of the application installer is actually installed to the device. With a portable/hybrid approach, additional resources, such as icons or splash screens of various sizes for different devices, may be included in the installed to account for varying requirements across multiple platforms. Such images must be present in multiple dot per square inch (DPI) densities as well as sizes for each platform has its own requirements. As capabilities such as storage capacity and SD Card size grow, this concern should be somewhat mitigated. Installed Application Size The size of the installed application is also important as a consideration. However, the ability to install applications directly to SD cards combined with Moore s law may mitigate this factor as hardware advances. Native applications

18 have a tendency to be smaller once installed because they are optimized for a single platform and can count on certain features to be present. There are several techniques and tools that can be used to reduce application size. Many users will be able to simply move applications to SD cards to alleviate the space problem. Coding techniques optimized for mobile development (which vary from platform to platform) can also be employed. Developers or designers can reduce the size and fidelity of all graphics and other assets to shrink applications size. Of course, this may adversely affect the application s appearance, however a reasonable balance can be found. Overall, installed application size is not likely to be top level priority as mobile devices increase their storage and memory capacity. Runtime Performance Runtime performance is perhaps the most critical item for many users. If an application is noticeably slow, freezes up often, or crashes most users will seek an alternative. There are several subcategories of performance metrics including time to load an application, time to render a view, and more. Native applications generally have a slight advantage here; however as processing power increases the difference is becoming less noticeable. Mobile Bandwidth Usage Bandwidth usage is an important factor affecting the overall perception of an application s performance. Since users pay for bandwidth, using less is better. Mobile bandwidth usage is directly affected by a number of factors. Binary encoding of data has a large impact on the bandwidth used (the more compact the binary format, the less bandwidth required). Transporting data in suboptimal formats (such as XML) to mobile devices will take more bandwidth (and CPU cycles) than JSON or an AMF, the latter of which also enable data to be interpreted directly as binary objects. Here, the decision to use a portable, native, or hybrid model is less important than the architecture and protocols supported by a specific application development framework. There are several Message Exchange Protocols (MEPs) that are highly optimized for mobility including data throttling and data paging. There are also several binary formats that are highly optimized such as JSON.

19 Another way to improve runtime performance is to migrate to a three-tier architecture and offload as much of the heavy processing and message exchanges as possible to the middle and back end tiers. This can be done with cloud based computing as well. The Google Android speech-to-text translation service uses this approach. Consistency of Function and Appearance A large percentage of enterprises will desire a consistent look-and-feel for their brands. This is also important across multiple screens and devices. This is increasingly difficult to achieve using the native code route as native components and features vary from platform to platform. Additionally, developer synchronization across multiple projects is difficult to achieve. For organizations seeking a consistent look-and-feel, a portable or hybrid strategy has clear advantages over the native route as the same code and components will be rendered similarly on different platforms. Using a standardized styling mechanism such as CSS is also effective to some degree. If a native look and feel is desired, this can be achieved with both native and portable/hybrid strategies assuming the development stack vendor supports custom design. Release Date Synchronization Enterprises may want to release mobile applications for multiple platforms at the same physical time. Portable code strategies hold a large advantage here yet they do not alleviate all release synchronization issues. Even if enterprise mobile application developers only have to create a single portable code base, they still have to perform tests on multiple platforms. A well-managed development shop can be invaluable in helping to time releases. Additionally, some device platforms require explicit approval of applications which may result in some applications being live before others. Codec Support for Media Formats One of the most consistent and sustained criticisms the ios platform has been a reluctance to allow Flash (the underlying SWF file format) technology on the platform. Adobe recently stated 14 it would halt development of mobile flash 14 flash- mobile- dead

20 hence it becomes less relevant to the overall market. RIM and several other companies had been quick to pounce on this as a key differentiator for their offerings, attracting customers in the process. Likewise, support for media codecs, including H.264, H.263, and QuickTime (MOV), also varies from platform to platform. A standards based development strategy will become a clear choice given this recent confusion in the marketplace. Codec support is a consideration for enterprises, but it is generally not involved in the decision on which mobile development strategy to pursue. Battery Use When more CPU or GPU cycles are used at runtime, more power is drained from the battery and more heat is generated. Some have suggested that an interpretation layer, or more accurately a translation layer, creates extra processing overhead, and hence requires more energy required. Evidence for this theory, however, is not easy to find. The reality is that most of the time developer and architect skill play a much larger role in the overall battery consumption of an application than choice of programming model. For example, migrating to a three-tier architecture and using the middle tier for heavy processing can reduce the number of CPU cycles required on client devices. Reuse of Existing Assets Instead of developing new sets of assets for mobile applications, some existing digital assets may be able to be used. For example, if an enterprise has used a Model-View-Controller framework within an enterprise Flex application, it may be possible to use some of the existing Model and Controller assets. Reuse of other assets such as metadata declarations (XML schemas for example), graphics, audio, and video clips may be possible in many cases. This is both a business and a technical consideration. Since each of the large mobile platforms uses different native execution environments, the advantage here clearly lies with portable code strategies if and only if the developer can use the same language and existing assets in mobile development. For example, organizations that use the Adobe Flash Platform to develop Rich Internet Applications may find the opportunity to reuse existing logic written in ActionScript 3 for mobile applications. In contrast, if native code is needed for each platform, such code could not be reused.

21 Other Considerations Additionally, there are non-technical factors, such as application market dynamics, approval processes (including application censorship), developer license fees, and submission of quality assurances that affect which strategy might be correct for an enterprise. The Players in Portable Code This section provides a brief introduction to five major contenders (in alphabetical order) in the portable code development sector. This is not an exhaustive and complete list as new platforms may emerge over time. Adobe Flex and AIR for Mobile Development Adobe has a long-standing developer community skilled in writing application logic in ActionScript 3. Adobe set up the Open Screen Project (OSP), an industry alliance of hardware and device manufacturers, retooled their core Flex libraries and component set, and made a sizable investment into mobile computing. Working with companies in the Open Screen Project and enterprise customers, Adobe engineers ported the AIR runtime to multiple target platforms. In many cases, existing ActionScript code can be reused for mobile applications. More: Airplay The Ideaworks Airplay SDK allows developers to write their application logic in C++ with the IDE of their choice. The SDK then cross compiles the source code for up to six different targets including ios, WebOS, Android, Symbian, Bada, and Windows Mobile 6.x. Developers write their code then select the ARM (or x86) binary they wish to deploy and highlight the desired platforms. They may then create multiple platform-specific installers based on the single native application binary. More: Corona

22 The Corona SDK is another cross platform, mobile application development kit. Corona helps developers create games and applications that run on both ios and Android. Corona recently introduced a new set of services that help games and apps succeed in the various application stores and achieve business success. More: PhoneGap PhoneGap is a free and open source cross-platform development platform originally built by Nitobi, a Vancouver-based IT shop. It supports six platforms and has experienced growth in its developer base as well as in its use overall. It uses WebKit, an open source implementation of HTML, JavaScript and other standards. That means developers and companies can use PhoneGap for mobile applications that are free, commercial, open source, or any combination of these. Nitobi, the parent company that developed the idea for PhoneGap, was acquired by Adobe Systems in November PhoneGap itself will remain open source and free. Particle Code As recently reported by TechCrunch 15, Palo Alto-based Particle Code is building a software development platform that enables mobile developers to write mobile apps and games once, and then deploy both HTML5 and native apps across platforms and devices from within a single code base. Particle Code is built upon the Eclipse IDE, and supports development in languages including Java, C# and ActionScript 3. More: Sencha: 15 apps- or- web- apps- particle- code- wants- you- to- do- both/

23 Sencha has Titanium Appcelerator s Titanium SDK is a free and open source application development platform. It allows developers to create native mobile, tablet, and desktop applications using existing web technologies such as JavaScript, HTML, CSS, Python, Ruby, and PHP. Similar to the Adobe Flex SDK and Ideaworks Airplay, Titanium also allows developers to create desktop applications. More: Conclusions Regardless of what the long-term evolution of the mobile industry is, most enterprises need to consider a mobile development and management strategy now. They will need to keep up with the rapid pace of innovation, and work with the uncertainty surrounding the platforms they may ultimately have to support. Due to varying business requirements and runtime performance requirements, it would be unwise to declare that a native, portable, or even hybrid model should always be used over the other alternatives. In general for enterprises looking to target multiple platforms while keeping development costs low, the benefits of the portable and hybrid approaches will increasingly outweigh those of the native approach for the reasons included herein. Executives responsible for their enterprise s mobile development strategy should weigh the factors listed within this white paper carefully before committing to any choice and be wary of company s long term commitments to keep development various technologies. duane@technoracle-systems.com matt@uberity.com