It's easy; just acquire some mobile app development tools and get started.
Building business apps for mobile devices should be easy.
- The physical features of mobile devices impose limits on memory, storage capacity, and screen size.
- The apps typically satisfy a narrow set of business requirements.
One might expect that the device constraints and a narrow requirement domain would simplify the task of building mobile apps. However, building business apps for mobile devices can be hard work, especially for companies that have little experience in mobile development and are embarking on new projects.
In fact, building the apps is the least difficult part of the task. The hard work is struggling with the decisions that precede app-building activities.
As you're considering business apps, these are some of the decisions you'll need to make:
- Which processes or transactions are appropriate for mobile apps
- Which mobile platforms to support
- What types of app to use
- What development tools to use
- How to distribute the apps: via an app store or side-loading
The skills of your developers can influence or limit the choices. Which approach should you take?
- Train existing developers who have no mobile skills.
- Hire new developers who have the skills but not the business understanding.
- Outsource the all of the mobile development.
- Just purchase an already-available app.
The decisions are intertwined such that one choice can force outcomes for everything. For example, choosing native apps on one platform determines the platform, reduces the list of suitable development tools, identifies the required developer skills, and excludes most of the other options.
Which app type is the most appropriate for the business requirements? Which app type is optimized for performance or the easiest to build? Are native apps faster than hybrid apps? What app type is the easiest to build? What criteria do you use to assess the options? What action do you take if an app store rejects your apps?
In the end, the differences in the mobile platforms and development tools matter less than a well-thought-out mobile strategy (platform, app type, and development tools), less than the choice of appropriate business processes to mobilize, and less than the quality of the user experience you build into the apps.
Mobile App Types
Mobile apps fit into three categories: native, hybrid, and HTML.
Native Apps
Native apps are installed on a mobile device and compiled to run on the device's operating system, like RPG or COBOL applications on IBM i, Java on Linux, or C# on Windows. Developers build native apps using languages including Objective-C (or Swift) on iOS, Java on Android, C# on Windows Phone, and C/C++.
Hybrid Apps
Hybrid apps are a combination of two components: the business app and a container (or wrapper). The container is a native app that hosts the business app and provides access to mobile device features including the camera, location services, and sensors. Developers use HTML, CSS, and JavaScript to build the app and tools to package the app with the container.
HTML Apps
HTML apps (also known as pure HTML) are server-based or device-based Web applications. The applications are designed to fit mobile device screens or use a responsive design that can adapt the user interface for different screen sizes. In the browser, developers use HTML5, CSS, and JavaScript to build the app's user interface and business logic, and, on the server, developers use other languages (C#, COBOL, Java, PHP, RPG, Ruby, Python, etc.) for the business logic and data access components.
Developers can also package the application and save it on a mobile device. Mobile device users operate the app using the browser on their mobile device.
App Types Compared
This table presents some of the characteristics and dependencies of each app type.
|
Characteristics |
Native |
Hybrid |
HTML |
|
App runs as compiled, executable code |
Yes |
Only the container |
No |
|
Requires HTML, CSS, and JavaScript |
No |
Yes |
Yes |
|
Requires access to a server to run |
No |
No |
Depends on use of local storage |
|
Can access server resources |
Yes |
Yes |
Yes |
|
Can use the device camera |
Yes |
Depends on the container |
Depends on the device's browser |
|
Can use location services |
Yes |
Depends on the container |
Depends on the device's browser |
|
Can store data on the device |
Yes |
Depends on the container |
Depends on the device's browser |
|
Can use sensors |
Yes |
Depends on the container |
Depends on the device's browser |
|
Runs on every mobile device |
No |
Depends on the container |
Depends on the device's browser |
HTML apps depend on the browser provided with a mobile device and the HTML features implemented in the browser. The HTML5 specification provides solutions for accessing mobile device features from apps developed using HTML. For example, the SQL database API and the offline application HTTP cache are options for equipping HTML apps with offline storage.
Hybrid apps rely on a container (or wrapper) app for access to device features, and the apps can use only the features made available by the container.
Which App Type Is Best?
The short answer is, it depends.
Each app type is suitable for most applications, but business requirements may suggest desirable app characteristics.
- Native apps are the most appropriate when animation is a requirement.
- Hybrid apps offer the potential for cross-platform apps with the ability to write once and run anywhere.
- HTML apps are best for ease of deployment or if you want to avoid app stores and side-loading.
However, each app type brings compromise, and that's the reason for careful consideration when choosing an app type.
The app type is only one of the factors that influence decisions concerning mobile app development.
Which Business Processes and Transactions?
How do you choose the business processes and transactions to mobilize?
Processes that work best in mobile apps...
- Are discrete and finish in a short time (e.g., retrieving the balance of an account)
- Have few or no external dependencies (such as retrieving data from a database on a server)
- Must be easily understood by the device user. If a user can't operate the app without reading a user guide, the process is too complex.
This decision requires an analysis of line-of-business (LOB) systems to determine the processes and transactions that will fit into a mobile app. Orders are an often-quoted example. However, if the order requires twelve 5250 screens in an IBM i application, with real-time access to a dozen database tables, it might work on a tablet but will be impractical to use on a phone.
App Audience
Who will use the apps? Apps for employees and apps for customers have different objectives. Employee apps focus on productivity, providing information on demand and capturing information required by the business process. The user interface design may be compromised for the sake of productivity. Apps used by customers provide and capture information but can also assist sales by suggesting complementary or alternate products. Many businesses fall into the trap of creating apps from their perspective and ignoring the customer perspective. For customer apps, the user experience is paramount and it must entice customers. Adverse app reviews in the app stores can influence customer willingness to use your app.
The app's target audience influences the mobile platforms you may have to support. If you supply devices to employees, you may be able to dictate the mobile platform. In cases where employees can bring their own device, a homogeneous mobile platform is unlikely. Similarly, customers will choose their devices, and the variety of devices is likely to widen with an increasing number of customers. It might be helpful to find out the types of devices your customers use and prepare for a growth in the support workload as the number of app users increases.
Buy or Build?
Should you buy apps or build your own? The Apple and Google app stores have hundreds of thousands of apps, and the number of apps in the Windows phone app store is growing. Surely you could find an app that fits your requirements. However, you will find that the majority of apps are social, personal, or games. Most business apps are provided by companies for use with their business, examples being banking and ERP software providers.
With a diligent search, it is possible to find apps that you can buy and configure for your use. Two examples are apps for mobile purchases (shopping-cart style apps) and human resource management. For cross-industry requirements, such as HR, buying an app might be adequate for simple processes. Companies trying to interact with their customers face dependencies when buying apps, including lack of influence over the app's features and no support for integration with existing LOB systems.
Most companies will build apps because they can control the features, platforms, development tools, and integration capabilities. Using in-house developers or outsourcing development becomes an economic decision after resolving the platform choice. Choose development partners carefully when outsourcing the work.
Choosing the Platform(s)
Prominent platforms are Android and iOS. Other platforms include BlackBerry, Symbian, and Windows Phone. Which platform or platforms do you choose? The criteria for choosing platforms include ideology, largest number of devices, and/or available developer skills.
You have no control over the mobile platforms. What actions can you take if a platform fails, closes, or changes?
The consequences of choosing platforms are significant. Choosing only one platform simplifies the choice of development tools and the skills developers require but isolates customers who do not use the chosen platform. A choice of multiple platforms allows you to reach more customers with your app, but the cost is a heavier developer workload.
If you choose multiple platforms, do you choose native apps for each platform or a cross-platform development tool that supports your chosen platforms? One approach to resolving the platform choice is to select a platform and then build and publish an app to gain experience and test customer or employee reaction.
Here are examples of criteria for choosing a mobile platform:
- Viability and maturity of the platform
- Customer reach (i.e., most devices)
- Appeal to customers (some customers buy on price, and others pay extra for perceived quality)
- Development and maintenance costs
- Manageability and fit with existing IT infrastructure
- Developer skills
Security and encryption may be a mandatory requirement for some industries.
Choosing a platform is one of the more difficult decisions as it confines the choice of mobile devices and development tools.
Development Tools
There are many development tools from which to choose to build native or hybrid apps. If you've built HTML applications for desktop or laptop browsers, you already have the tools to build HTML apps for mobile devices.
Native Apps
Native app development uses programming languages, tools, and SDKs built for a mobile platform, including these:
- Apple iOS, Objective-C/Swift using Xcode
- Android, Java using Google's Android Development tools, or Eclipse with an Android plug-in
- Microsoft Windows Phone, C# using Visual Studio
Developers build apps using a language appropriate for the mobile platform, compile the apps, and deploy them to mobile devices. A compiled and deployed native app is a binary that runs on a specific mobile platform. The tools and development process are similar to building RPG or COBOL applications to run on IBM i servers.
To build an app that will run on iOS, Android, and Windows Phone requires three instances of the app, one for each mobile platform, built using different programming languages that compile binaries that are not interchangeable.
Using C/C++ to develope native apps provides a level of cross-platform code. The APIs differ on each platform, so there's work to do for each platform.
Supporting native apps on multiple platforms requires a significant development effort when compared with hybrid apps that offer the ability to develop once and achieve cross-platform flexibility.
Hybrid
Hybrid apps use HTML5, CSS, and JavaScript, SDKs and tools built to support multiple mobile platforms. The development tools include whatever tools you use to build Web applications plus an app packaging tool. Apache Cordova, Adobe PhoneGap, and Appcelerator Titanium are examples of hybrid app tools.
The hybrid app tools language support includes HTML, CSS, JavaScript, server/desktop languages, and proprietary scripting or macro languages.
The user interface is one point at which the tools offer differing methods for rendering the apps screens. One method uses the mobile device's browser to render the user interface, and most of the hybrid tools support this method. Another method is to package the app with the native control APIs with the result that the app's screens appear more like native apps than browser-rendered apps.
The tools include support for mobile device features (camera, location, sensors, etc.), but the support differs from one tool to another.
One class of hybrid app tools allows developers to write server applications using languages including C/C++, C#, COBOL, and RPG, and the tools provide a mobile device app that interacts with the server programs. The app and its user interface are native to the device, and the app exchanges data with the server.
An advantage of building hybrid mobile apps is the opportunity to code once and generate apps to run on multiple platforms. Developers can build the apps using a language of their choice and select a target platform at generation/packaging time.
HTML5
Apps built using HTML5, CSS, and JavaScript run on any device with a browser that supports HTML5 features. The development tools are the same as those developers use to create Web applications that run on desktop and laptop computers.
Building apps using Web tools removes cross-platform limitations, provided the apps take account of the numerous different browser eccentricities.
Developers can design the apps to run on a server or copy the files to a mobile device and run the app from the device.
The HTML5 specification provides access to some of the device features, but developers rely on the browsers to support the features.
Evaluate the Options
What are the options for developing apps for mobile devices, and what decisions do you face?
Do Nothing
Doing nothing is not a feasible option for most companies. Customers will come to expect to use their mobile devices to interact with companies, especially so for companies selling directly to consumers. Companies can improve productivity using mobile apps in their processes. Even industries that see no compelling reason for mobile apps today will face the problem tomorrow.
Decisions you must take:
- Choose a mobile platform? No need to choose.
- Choose app types? No need to choose.
- Choose development tools? No need to choose.
The significant decision is avoiding or postponing the development of mobile apps.
Purchase Apps from an App Store
To purchase apps from an app store requires a search for available apps. Set aside plenty of time to search the app stores. Reducing the list by searching for business apps still produces a long list of potential apps. Then you must examine each potential app to determine its suitability for your requirements. Good luck with sending change/enhancement requests.
This is an option only for companies that operate generic processes, where the processes offer no competitive advantage—e.g., small companies with unique products.
Decisions you must make:
- Choose a mobile platform? The app you choose dictates the platform.
- Choose app types? The app developer has made this decision.
- Choose development tools? The app developer has made this decision.
Outsource Mobile App Development
Outsourcing mobile app development is a viable option for companies that don't regard software development as a core business activity and whose IT infrastructure offers no competitive advantage. App development should be faster than using in-house developers with no mobile development skills.
All outsourced activities require diligent contract and project management. Your company won't be the only customer of the outsourcing company, and your priorities will compete with those of the outsourcing company.
How do you choose a partner? A most important consideration is whether the partner company will be around when you need to update or rewrite the apps (and, believe me, you will).
Decisions you must make:
- Choose a mobile platform? You should choose the platform(s).
- Choose app types? The outsourcing company will help you decide or make the decision for you.
- Choose development tools? The outsourcing company will decide.
Develop Your Own Mobile Apps
Developing your own apps for mobile devices provides more control and flexibility than the other options, but it opens up a complex set of decisions.
Decisions you must make:
- Choose a mobile platform? You choose the platform. Do you select one or multiple platforms?
- Choose app types? You choose the app type, and if you also choose multiple platforms the development tool choice becomes complicated.
- Choose development tools? You can choose the development tools. If you choose multiple platforms and the app type is native, you require multiple development tools or C/C++. If the app type is hybrid, you require a development tool that will support your chosen platforms.
The decisions become more complex if you choose a development tool before the app type. The development tool may determine both the platform and the app type.
Summing It Up
Upon reflection, it seems that developing business apps for mobile devices is not as easy as one might hope. The reality is that mobile devices and apps will become more pervasive, touching most aspects of life, and companies will be forced to provide their products and services via mobile apps.
So, what do you do?
Careful planning is the way to manage the situation. Gather information about customers. Examine your business processes to determine how to use them with mobile devices. Survey your developer skills. Prepare a strategy for going mobile. Build an app to test your strategy.
You could use the decisions discussed in this article to create a decision table or a weighted evaluation to help eliminate or confirm your options.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online