Web developer’s guide to the mobile development galaxy 2/2
Zbigniew CisińskiHead of Mobile Team
So, you’ve read the first part of Web developer’s guide to the mobile development galaxy and you already know the basics. You have a concrete idea for your app and you’re ready to give instructions to the design team. You know the difference between iOS and Android functionality, and how a mobile app UI doesn’t equal a web UI. You’ve also come to terms with why, in the long run, a dedicated app will be more beneficial than a hybrid one. Now it’s time to complete the process and make your business idea a reality.
The first question your development team will ask is “which version of the mobile system should we target?”. And the worst answer you can give is “all of them”. It’s just not possible. You should target the most popular ones. Stats for Android versions and for iOS versions can be checked online. On Android, you should target the earliest version with most users, while on iOS, it’s usually the latest one or the one before that, at most.
Why isn’t it possible to target the remaining 7% of the market? Because, in most cases, those old devices aren’t even supported by the development tools – it’s impossible to use them for testing. In addition, adapting your app to many OS versions will cost you, and I’m not talking only about the money for support. Imagine all those shiny new APIs which can handle complex tasks in a few lines of code. Now imagine abandoning those APIs and writing the code by hand just to support some old phone which might be used in a country you won’t even target. Doesn’t sound very appealing, does it?
“Sir, I’m not entirely sure if we can target these devices…”
Spend some time to determine the minimal version of your app as it’ll impact the architecture. The architecture itself can change with every new SDK version, with every list of available stock components or support for the newest hardware and OS functionality. Of course, when you decide to outsource the mobile development, these technical details will be handled by your mobile team. Nevertheless, you should provide them with a clear starting point – a minimal version depending on your goals and the project timeline.
You could target only the current version of the iOS and still end up supporting 90% of the market when you finish the MVP of our app. Or, it could be cheaper to do it on the latest version and skip 27% of the market, but only for a few months until users catch up. Plus, supporting such apps costs less because the differences between the current OS version and the next one will be smaller than e.g. an OS from three years ago.
All in all, you need to think in terms of where the market will be when the development of version 1.0.0 ends. Medium-size applications can be completed in half a year or longer, so the current state of affairs isn’t enough. You should always look into the future.
When the development starts, keep an eye on the product. Every Scrum-based project will have demos, but you can, and should, ask the development team to deploy the app on your devices. Acquire the ones with all the supported systems for testing. Also, provide feedback as early as possible because changes later on will be costly and time-consuming.
As for the API, if it’s been built already, then mobile apps could use the same API as the current web app. If the API is still under development, try to have it ready as soon as possible. Mobile apps usually consume data from a server and need a way to store the information outside of the device. Developers can work on interactive API mocks, but the crucial part is to deliver a documented, final version ASAP. Also, plan for API versioning from the start. Ask yourself: “what will happen when a new API is published”? The website will use it immediately. But the old version of the app will call home using the old API calls. What then?
One final advice: release early and release often. By the time your “perfect” app is completed, there could be hundreds of implementations of that same business idea. Even if your app consumes the API of your well-established website and you’re not in a hurry to get it to market, release early. Users will see the added benefit of the mobile app, and, what’s more important, they’ll appreciate it being actively developed. So, release the MVP and follow up with new features in constant and rapid succession. This will also give you an excuse to inform your clients that a new version of their favourite mobile app is being published. With new and exciting features they all have been asking for! The development cycle can be an effective marketing tool, if you know how to use it.
The Quality Assurance
The best-designed app with the coolest features won’t survive on a user’s device for long if it crashes constantly. A website can be refreshed, but a mobile app will just die a more-or-less silent death, enraging the user. Most of them will delete the app and that’s it. No second thoughts. No second chances. That’s why it’s so crucial to implement a quality assurance process as soon as the development starts.
When it comes to mobile apps testing, Ron Swanson definitely has his own way
Most of mobile development teams should have QA engineers on staff. Potential problems on a mobile device are quite different from the ones you encounter on a PC website – solving them requires specialization in the field. A typical example of a mobile problem is the loss of connectivity. A user might start listening to an audio stream in his/her room, then move downstairs, outside of the Wi-Fi range and, finally, go to the basement where there’s no mobile network or Wi-Fi.
A mobile app should handle every loss of connectivity smoothly. Even if, in the meantime, there have been two notifications from Twitter and a call from aunt Cecilia.
Another common mobile issue is multiple language support. A mobile app selects the language based on the system language settings, but words can differ in length or some translation can be missing. It all has to be thoroughly checked.
As you can see, mobile technology has its share of unique challenges. A skilled QA engineer has to know how to simulate such harsh conditions and what to expect. Some of the more advanced teams will also test security and performance of the mobile app. Plus, if you’re planning for a long-term project, consider introducing automated tests. They can verify if recent changes didn’t break anything in the app and if all features work as they were designed to. These tests are done from the perspective of the UI. They simulate possible user actions in a series of scenarios, which should be created for every user story.
Finally, tests should be performed on a wide range of devices because the hardware and software differ greatly on both platforms. Some issues may arise on less popular brands of devices, but you should always prioritize the ones that are most widely used. You could also benefit from checking what devices your product is targeting. They may differ substantially by country or user segment, and it makes no sense to invest in testing for a fraction of the potential user base.
As soon as you have the MVP, you’ll want to release it to the public. On Android, it’s a relatively easy process. You have to prepare a marketing description and screenshots of the app (or marketing images), plus decide on a category in which the app will be published. The publishing itself should take no more than 6 hours globally. As for the app updates, some devices will do it automatically while others will wait for the user to update manually. In a year, your stats might show an old version of your app being actively used.
Presenting your app to Android users is pretty easy. On iOS, things get slightly more difficult.
On Android, your app won’t have to go through a review (however, it can be removed later on if it violates the Google Play Program Policies and Developer Distribution Agreement). On iOS, it’s a little bit more complex. Of course, you’ll also need to ready all the marketing materials and pick a category in advance. But, besides that, every new version of the app will have to pass a review. It’ll be tested manually by the Apple employees for an indefinite amount of time, and, in the end, it can be rejected. So, don’t count your chickens…
Every review can end in rejection, so you’ll have to keep your fingers crossed and treat it as another business risk. Rejection usually comes from not obeying the Review Guidelines, which are very vague and change often, so you might think it’s unfair. Still, rejection is not the norm, and you can appeal. The review time varies, depending on whether there’s a new device or OS version coming. You can check the average review waiting time, but remember that 7 days and 1 day both average to 4 days. If you want to plan a campaign, you can send the app for review and hold the release, making the app available later manually or setting a date of publication. This should give you some control over the process.
Overall, the publication is a simple process if you provide some buffer time for it. There can be problems, usually on the iOS side, but you should take them into account as a business risk.
If you feel like adding small features after five years, your development team will tell you that it’s just not possible. Why? Because developer tools and frameworks change, libraries are abandoned and operating systems evolve.
In a year’s time, every app will require changes. And you have to plan for it in advance. Ask your mobile team to identify those maintenance points. For example, when a new beta version of the iOS is released, your app should be tested on it.
Remember to add some statistics and crash logs to your application. Third-party systems like Crashlytics are quick to implement, and they’ll provide you with the necessary feedback about the app usage. You’ll know which features to prioritize and what went wrong. Plus, you’ll spend less time hunting down those troublesome crashes. In general, the more non-standard solutions and UI components you have, the more they’ll need to be monitored. Ask your team often if there are solutions that need more work than others. It could be possible to save money in the future by replacing them now.
Last but not least, don’t let the codebase “go stale”. Otherwise, you’ll have to rewrite the whole app, and you certainly don’t want to do that.
Let’s face it: mobile development is entirely different from creating websites or web services. However, I’m sure that you’ll learn the ropes slowly and make mistakes along the way. Probably the best way to succeed, business-wise, is to find an experienced mobile development team and build an open and honest relationship with them. They have the necessary knowledge to warn you about impending problems, e.g. a new device your app isn’t compatible with. You simply have to ask them. Just remember: choose your team wisely as this is a long-term marriage and, like with all marriages, divorce can be costly and messy. You certainly want to avoid that. 😉
Here at The Software House, "Zibi" is the King of Mobile. Having circa 10 years of experience in mobile development, he knows pretty much everything about it – especially when it comes to Apple and iOS.