26 June 2018
Web developer's guide to the mobile development galaxy 1/2
You’re a web developer, Head of Technology, maybe even a CTO. When it comes to web applications, nothing can really surprise you. But, more and more often, you’re thinking about going mobile – whether for yourself or for your company. How hard can it be? Well, rephrasing Douglas Adams’ Hitchhiker’s Guide to the Galaxy, mobile development is “a lot more complicated than you might think. Even if you start from a position of thinking it’s pretty damn complicated in the first place”. But, hey! Here’s this little guide to help you!
So, you’re thinking about creating a mobile app. Where to begin? You’ve probably overseen several lifetimes of web projects. You’ve witnessed the rise and fall of many web frameworks; the demise of “send by FTP and hit refresh” development. Nowadays, even the simplest web portal is being set up using global CDNs, Docker and traffic management. Every website is an advanced app made with cutting-edge technologies. It’s not humanly possible to grasp all those constantly moving parts. And you’re OK with that because you know enough to satisfy your professional goals.
But if the web is such a complex creation, what can you expect from mobile development?
Discussing technology is like shooting at a speeding train. You’ll hit or miss because everything is constantly changing. There are risks to be taken into account, but, on a business level, mobile apps are quite easy to understand. Do you have a product that can benefit from quick and/or highly optimised interactions with users? Do the interactions have to happen in a low-friction environment that the user is already familiar with? If your answer is “yes”, plus you want to reach a third of the world population, then you’re on the right track.
The first thing you need to know about mobile apps is that they’re “applications”, no different from desktop applications written in .NET, C++ or Java products developed for, let’s say, the Windows 10 platform. They have to be installed, they can crash and they can be hacked. If anything, they’re more difficult to do right. Yes, a smartphone is small and fits in your pocket, but from a technical standpoint, it’s a computer like any other, only with limitations. It has CPU, GPU and drivers, and it runs small Linux or Unix, plus apps.
Depending on the platform, mobile apps can be written in Java on Android, or in Kotlin – a new generation language compatible with Java Virtual Machine. On iOS, there’s Swift – a new generation language similar to C/C++, but with a mix of features and good ideas from other cutting-edge languages. These languages are compiled to native code and can utilise the full power of mobile components, which, although powerful for their size and power usage, are at best two, three generations behind home PCs.
By doing things the way Apple and Google intended, you at least remove one layer of obstacles. Plus, you don’t lose the advantages of native mobile apps, which might happen if you cut corners with a “multi-platform” hybrid app.
There’s no such thing as a free lunch. If you skimp on development, you’re bound to end up with a poor-quality product. Of course, sometimes it’s what you want or even needs to do. Supporting two platforms means having two separate projects with their own budgets, which will, in turn, create two similar but different products with their own codebases. Still, if you’re thinking long-term, then think again before investing in a non-native, third-party technology, even if it proclaims itself as “native”. Short-term, you’ll be saving money, but, in the long run, you’ll back yourself into a corner.
Before you start developing a mobile app, you have to grasp its limitations. It will allow you to satisfy your true needs and define the scope of the project – the “idea” for the app.
First of all, there are two major mobile platforms: Apple iOS and Google Android. As Microsoft abandoned its mobile efforts, they’re the only ones that count. That simplifies things to some extent, but these platforms differ in fundamental ways. Distributing your app on one of them can limit the app’s functionality. How? On Android, you can publish any app that loosely adheres to the policy of the Google Play store, but on iOS, things get a little more difficult. There’s a set of Review Guidelines that you have to know and apply. This is usually enough, but bear in mind that these rules can change.
Another limitation is what you can and cannot do in a mobile app. This differs widely between platforms. For example, on iOS, it’s quite difficult to leave the app working in the background when the user launches another app. Why? For the sake of lower battery consumption, privacy and the performance of the entire device. This topic alone deserves at least two separate articles, but I encourage you to discuss it with some friendly mobile developers (or simply a remote mobile-development team, if you’re a CTO and you’re planning to outsource) while you’re preparing a business plan. Let’s say you’re planning to create a fitness app that tracks the user’s location even if the app remains in the background. A good mobile team can introduce an API to do exactly that. They’ll know how to go around the limitation.
If some of the limitations originate from the App Store rules, then it’s possible to release a so-called “Enterprise” app. It’s a special type of app that you can publish without the need for Apple’s approval. At least, for the distribution part of the process. However, you still need to obtain the Apple Developer Enterprise Program. This program is also a little bit pricier than the standard one. Plus, all Apple Developer programs are based on a yearly subscription. The main downside is that you need your own channel of distribution. All things considered, the enterprise solution should be applied sparingly and only for edge cases.
Finally, there’s also the matter of privacy. Whether we like it or not, mobile phones have become the centre of our lives. They store sensitive information, like who we’re dating, where we’ve been and where we’ll go. This data is invaluable to users, but it’s also in constant danger of being stolen or used in fraud activities. When you’re designing your mobile app, remember that users are becoming more and more conscious about their privacy. You should take extra measures to respect that. It would be easier to “borrow” their contact book and upload it to the server but they will publicly crucify you for that. Just don’t plan to do anything you personally wouldn’t want to be a part of.
After the scope has been defined, you can focus on the next crucial part of the process: the design of the mobile app. This phase can determine the app’s success, final cost and future extensibility. Mistakes can have repercussions throughout the lifetime of the project. And when I talk about design, I don’t mean only a big company logo and colours straight from the brand book. It’s a little bit more complex than that. To understand it, you have to know a few fundamental facts.
First of all, it’s not easy to fit all the data, controls, views and whole site structure into a small mobile screen.
If you’ve worked with responsive design, then you know what I mean. Still, a website is usually used in different scenarios than a mobile app. Take, for example, a banking app. You don’t want to browse multiple lists of your past transactions. Nor do you need to print a receipt for the last month’s electricity bill payment. What you want is to make a transfer to your colleague to pay for a pizza or check if you can afford a new dress. Of course, I’m not saying that an app shouldn’t be feature-complete. But some of the functions should be at hand, optimized for the users’ actions and habits. If you make your app this way, you’ll guarantee its usability and maximize the value of your product.
Secondly, you don’t want to go wild with UI components. There are standards for tables, sections and buttons. At this stage, choose stock ones. They are well tested, ready to be used right now and consistent with the UI guidelines. You can always replace them with something fancier later on, but prepare to support it throughout the app’s lifetime.
As for the UI, we’ve established that iOS and Android are very different platforms. The UI components themselves and the way they’re applied are fundamentally different. Android uses Google Material Design, which you’re probably familiar with thanks to Gmail and Google apps. Apple iOS uses the Human Interface Guidelines. So why not simply use Material Design on both platforms or implement a custom, heavily-branded solution? Because, in the long run, it won’t be worth it. You’ll add weeks, if not months, to your app development, plus you’ll complicate it. You’ll also increase the support cost. And, most importantly, you’ll end up with very unhappy users. Why? Because of the lack of familiarity.
If you’re an iOS user and you see a Google app designed in Material Design on your system, it will annoy you. It will look different, work different, and you’ll have to learn how to use it. Of course, it’s not a problem for power users, but most of the mobile audience isn’t that advanced. They’ve learned how their system works. They know what to expect and how the UI will look or respond to their actions. It makes them feel safe and in control. You’ll take it away from them if you introduce a foreign concept. You won’t be able to make it 100% consistent with the current OS. You won’t be able to reproduce all system functions or behaviours in your custom UI.
In the end, you have to accept that iOS and Android apps look and behave differently, as it should be. Your users will be grateful for that. And, in the long run, you’ll save money and time by not fighting the OS you’re developing for.
The last question is: how do you design the app properly? This area has its own specialists – the UX experts. Every mobile studio should have its own UX team. They’re able to establish the requirements for the mobile app, based on feedback from you or your potential users. They should organize workshops, pick your brain and come up with a solution that fits your business needs. You should take part in the process from early on – this is as invaluable as the documentation. Press for interactive mock-ups using native components, where you can check for inconsistencies. Inspect how they work with different screen sizes. Start from the smallest devices and identify the most important features of the app. Then you’ll be able to move to bigger sizes, e.g. an iPad screen.
Your design team will provide you with many options and solutions. Pick the ones that work best for your business. Catching mistakes at this stage can eliminate hours of unnecessary work and help you get meaningful output from the development team. Afterwards, the design team can introduce colours, logos, and themes to the mock-ups, but this stage is based on personal preferences or the company’s branding. It isn’t as crucial as the UX. Selecting colours, icons and style comes last and can be done while the development is underway.