Picture this: Your team just successfully launched the company’s new mobile app, and you’re having a great week so far. The analytics dashboard is buzzing along with steadily climbing stats showing high engagement, increasing active users, and positive reviews. Life is good! Then you’re called into an emergency meeting. A security flaw has been discovered in your application that can’t be resolved remotely. You develop a hotfix and release it as quickly as possible. But there’s another problem. Users are not downloading the updated application. What now?
The scenario described above is one of many common challenges facing mobile app development teams. In this blog post, we will describe three common challenges we face when developing enterprise-grade mobile apps for our clients and present some techniques you can use to overcome them.
common mobile development challenges:
pace of innovation
In mobile development, many businesses find themselves struggling to keep pace with innovation. Enterprises often have multiple product lines, divisions, and geographies, each with its own backlog of competing priorities. This leaves the product development team to juggle priorities while trying to fulfill requests in a timely manner with quality deliverables. Depending on the industry, high-priority change requests can be time-sensitive, requiring developers to shift tasks around as priorities change. The faster the pace of innovation, the higher the volatility, and the more at risk your product is for missed deadlines, security flaws, and overall lower quality releases.
Another challenge presents itself after the app is released to users. How do you control what happens with your application once it is in the hands of your users and under their control? How do you keep your users and yourself secure? How do you keep users on the latest software? How do you prevent users from using faulty versions of your software? To protect yourself and your users, you will want to design certain capabilities into your applications to provide some level of operational control, even after a public release.
Note: If you have already released your application without post-release management, it’s OK! Keep reading to see what you can do to increase the security and control of your future applications.
Our last challenge is about the close relationship between your compiled app and specific environments. As discussed earlier, once an app is released to consumers, it is out of your control. Your compiled app is also likely coupled to a specific configuration of your production environment via URL configurations, API keys, or domain models. If your production environment is not suitable for alpha or beta testing, you may also want to provide a version of your app integrated with a staging environment. If your application doesn’t support configuration changes, you will need to release separate builds that integrate with the staging and production environments. Unfortunately, this means testers are not actually verifying the same compiled app that production users will receive, adding an element of risk to each release.
To combat the struggles outlined above, we have implemented and recommend the following processes into our development lifecycle:
1. Wrap all new features in feature toggles.
Feature toggles help teams respond to changing priorities and release when the business is ready. The concept is simple: Developers implement a small piece of logic around their new code, allowing it to be turned on or off dynamically. This technique greatly reduces the need for long-standing feature branches, where code quickly diverges from the mainline, introducing risk when it is finally merged with other developers’ code.
Implementing feature toggles is a great first step that can help address all three of the challenges above. If the product owner needs to shift priorities and push a feature to a later release, no problem, toggle it off. If you configure your apps to retrieve these toggles from a remote data source, you can even turn features on and off remotely without the need for a new build or release. Furthermore, once you have mastered the art of managing toggles via a remote API, A/B testing is a short jump away using the same principles. Read more about implementing feature toggles here.
Note: As features are released into production, tasks should be queued up for developers to remove dead code and old toggles to reduce technical debt.
2. Utilize trunk-based development.
Trunk-based development is a source code branching strategy where developers collaborate on a single branch called “trunk,” creating short-lived branches that always merge back into trunk as quickly as possible.
When used in combination with feature toggles, developers are empowered to commit code early and often, without fear of breaking functionality. This keeps developers up-to-date on the latest version of the code and greatly reduces integration work. Once any amount of work is completed, it is immediately tested (preferably via an automated continuous integration server), code reviewed, and merged back into trunk. At any point in time, trunk will include all of the completed development in a tested, production-ready state. Learn more about trunk-based development here.
3. Use remote environment configurations or kill switches to manage live releases.
With a little forethought, you can have some control over your apps out in the wild. Two common approaches include having your apps call out to a remote source for configuration data (URLs, environment variables, keys, etc.) and including a kill switch or forced update that locks the application down to the launch screen and provides only a message directing the user to update before the application will resume.
In today’s world, we recommend including a forced update process or kill switch in any released application as protection against future security vulnerabilities. This provides an easy way to force users into upgrading to the latest version of the application; however, as an abrupt user experience it should be used sparingly. Remote configuration also allows you to configure each released build remotely and direct builds to point at any environment, URL, or data source you choose. You can even do this dynamically, based on device location or other information about the user. However, this approach requires a more in-depth implementation and can present a single point of failure for your application if the remote configuration provider goes offline.
making app development better
In closing, no software development process will ever mitigate all risks, remove all volatility, or prevent all defects. However, a robust set of processes and guidelines will enable your development teams to efficiently produce quality products with minimal friction. Have questions or need help with your mobile app development process? We’d love to connect. Reach us at email@example.com.