DON'T LEAVE SO SOON!
SIGN UP TO KEEP UP WITH OUR UPDATES
Four of our clients have been successfully acquired in the last 8 years. Click here to learn more.
For over 25 years organizations have been challenged with taking a normal sized software application and fitting it in a smaller device like today’s Smartphones and still make it functional and easy to use. In this Blog Article we will discuss the approaches for doing this, as well as what needs to be done when you are ready to publish your Mobile Application.
Ever since Psion, Apple, Palm, IBM, Microsoft, BlackBerry, and others created the Personal Digital Assistant (PDA) and later the ubiquitous Smartphone the software industry has been trying to take a normal application interface and squeeze it into a small screen that could be displayed on the device. And that is a HUGE challenge, not only because of the smaller footprint that you can display any User Interface on, but also the fact that you are dealing with a touch screen and a tiny keyboard for data entry.
As an example, here is a screenshot of Identiv’s standard Web Interface.
And here are screen shots from the Native iOS and Native Android Mobile Applications.
And a quick shout out to the entire ArkusNexus Team working with Identiv, which is an awesome physical security company. They rock and are a igh performing Software Development Team. #SoftwareDevelopment #NearShoreDevelopment #MobileDevelopment #ThoughtLeadership @goarkus
Over the decades in general there have been two approaches that were taken for having an application displayed on a Smartphone or PDA device.
Both have their Pros and Cons.
This has been the promised panacea for decades now. Create the application using this programming technique and it will magically work on both a Normal Browser and also on a PDA, Smartphone, or Tablet device. Whether you refer to this as a Responsive Design, an Adaptive Design, or other term, the concept is the same. The code will detect the dimensions of the devices display and dynamically change how the User Interface is displayed.
The major Pro for taking this approach is that you have only a single code base to maintain and develop against. This makes it significantly easier when performing upgrades, patches, and enhancements. This also allows you to have an app on both platforms faster. However, it doesn’t always work as well as advertised. Sometimes the translation between different Form Factors (display sizes) doesn’t always work well. So, at times User Interface components can end up being displayed in the wrong order or in weird places.
In addition, there may be some limitations with the Micro Browser that do not exist in a normal Browser on a regular device. Early on this caused significant issues when trying to use an Adaptive Approach, as some functions simply wouldn’t work at all. Also, because it is not a Native Application but a Browser or Web Application, you are not able to interact with the device directly or as easily. This can cause additional limitations on what Users are able to do.
Another form of Adaptive approach is to use cross-mobile platform frameworks such as ReactNative. The benefits of these platforms provide better access to phone sensors and items such as camera roll, contacts, etc. They do, however, tend to be slower in performance, unable to do multi-threading or unable to perform background processes like native applications can do.
This approach means that the Development Team will use a Native Programming language to develop a similar User Interface to what is displayed on the standard Web Interface. But one that is designed specifically for the Device, typically iOS or Android.
The major Pro to this approach, is that the User Interface is built specifically for the Mobile Device or Tablet, and it is much better at dynamically resizing UI components to fit various Form Factors on devices that run that particular Operating System (iOS or Android). So, this tends to be an enormous benefit for the Users. In addition, because it is a Native Application, it can be designed to specifically take advantage of features found on the device. For example, looking up contacts. Taking photos and uploading them, etc.
This becomes extremely important when you want to design say a Banking Application, where you want to allow the User to take a photo of a check and upload it for processing. The same is true if you are designing a Retail application which processes Credit Card transactions through a scanner attached to the Smartphone. In both of these cases you need to interact directly with the Smartphone and any attached devices.
However, the major Con is that now you have to maintain perhaps 3 separate code bases. And this can become a challenge long-term to keep everything in sync.
Once your team has created and fully tested your Native Mobile Application, then the next step in the process is to Publish it on the various Apple iOS and Google Android Application Stores. The challenge is that both companies have taken two very different approaches.
Google has the easiest approval process, but also the weaker quality testing process. This means that you can get your Native Android Application approved fairly quickly and without a lot of fuss. However, it also means that there can be Android applications that don’t work correctly or even may include malware in them.
Apple has long taken a much more rigorous approach, as they want to have a lot of control over the overall experience and quality of their products. Because of this, when you develop a Native iOS Application you have to submit it to Apple for testing, before it is approved to be displayed in their App Store.
This approval process can take 2 or 3 weeks, although subsequent releases may take less time. From a Release Planning perspective, you need to take this into account. In addition, there is always some risk that Apple doesn’t approve your application or requests changes, which will lengthen the time before the application is available. On the positive side, this typically means that an iOS App has been more thoroughly tested and is free-er of defects, malware and potential problems.
In this Blog Article we have briefly covered:
The bottom line is that which approach you take is greatly dependent upon your Business Requirements and what you need the application to do.
We hope that you have enjoyed this article and found it useful.
Thank you, David Annis.