First off, congratulations! Getting your app published in a public app store or to your internal enterprise is a big achievement, especially if it’s your first app. But once the celebration dies down, the next questions that generally get asked are, “How quickly can we build the next app?” “Can we add AI and machine learning to this app?” “Should we build a web version that delivers the same functionality?” And “What happens after this release?” This blog post will cover all the post-release mobile app development best practices you need to know.
All questions regarding use cases, business needs or platform support are valid and important. A strong mobile portfolio and roadmap will answer most of them, but in case you don’t have one, this Kickstart will help you.
For now, let’s focus on the app that you just released and the journey that accompanies it. It’s a fun ride, complete with ups and downs, do’s and don’ts. As with any journey, don’t forget to keep a diary and capture feedback so things go more smoothly with each iteration. Now onto the cheat sheet:
Clean up your app
An application’s development process often includes “quick fixes”: snippets of code put there to fix issues or speed up development (usually to meet the deadline). Now it’s the time to go back and clean those up, remove any compiler warnings, add some missing code documentation and perform minor optimizations. This will pay off as you continue to work on the codebase, though you may initially need to add developers or functionality.
Should you add a pre-built NPM package, NuGet package, or pod to help you deliver on time (faster) by adding functionality that’s published on GitHub? Or should you have the team build it from scratch? This is the Build vs Buy debate.
To make this decision, our team weighs the benefits of speed and convenience vs the risks of using code that’s not yours-whether open source or from a purchased library license. There’s no rule of thumb around this decision but we approach it by asking ourselves: How comfortable are we about depending $X for feature Y? Just remember, never copy/paste Open Source code. That’s just not cool.
Update your SDK and OS Support
The technology your apps run on (iOS 12, Android P, etc.) is always changing, maturing, and (hopefully) improving. Always be sure to keep in mind Apple’s annual release cycles and Google’s betas and official releases.
We recommend establishing a regular set of tasks to address these items (e.g. update to the latest SDK, fix deprecated APIs, analyze new APIs, add possible changes to your backlog, and perform a full regression once per quarter). It’s much easier to update an app from iOS SDK 11 to 11.1 than from 9.0 to 11.11.
Support new screen sizes and/or form factors
Android developers should be very familiar with this process due to the high degree of manufacturer/device fragmentation. But this is also starting to become a common pattern, even on iOS devices. To minimize the pain, always try to build your UI “responsively.” Or begin by supporting a limited set of devices and add new device support over time. This strategy makes far more sense in the enterprise space where device type is a known entity.
Similarly, if you build an app for iPhone and want to target iPad next, take some time to rethink the UI design to take advantage of the flattened hierarchy and additional real estate tablets provide.
Extend to the next platform
If you’re building consumer apps and you built your first iteration for one specific platform, this may seem like a natural next step. However, B2E apps are a bit of a different beast. Understanding the details of your user base will help you make better decisions regarding what platforms to support. For instance, you may not need to support Android if you’re an iOS company that provisions devices for its users.
Analytics, Exceptions, and Crash Reports
Initial app launches commonly include “basic analytics,” which track things like installs, sessions, session times and locations, and an out-of-the-box crash report tool to ensure you’re alerted when something goes wrong. This is a great start, however to deliver true value and get a better sense for how solid your app is you should add more metrics, track engagement, funnels, and even handled exceptions in the code. If your first app is a consumer app, also consider adding a prompt to review the app in the store.
Bug fixes/Crash Reporting
After the initial release, there is always a backlog of bugs. If things are looking good, the majority of these items will be ranked “low” or “lowest” (but they’re still important). Reported crashes should be continuously monitored and imported into your backlog. Although minor issues may appear on this list, it’s still important to add them to the next iteration. An app’s success is in the details. For example, you may have an issue with a hidden keyboard or with a malfunctioning “return” button. For you this may seem like a “low priority” issue but your users may consider it a deal-breaker and delete the app.
App Store monitoring, reviews and feedback
This point is specific to consumer apps listed in public App Stores. Remember, there will always be positive reviews and negative reviews, no matter what, but how you act on those reviews is what differentiates a successful mobile app from a failure. Consider that a user took the time to write something about your work. The least you can do is to listen. Also keep in mind, many users drive their decision to install an app based on other users’ reviews.
You initially began developing this app with tons of great ideas but not enough time or budget to fit them in or to prepare your backend services to support them. Now it’s time to reconsider them. Prototype the additional ideas, and plan to add at least one every 8-10 weeks.
Global companies and consumer apps often need to support multiple languages. We always recommend you provide localization support even if you’re planning to restrict the first release to a single language. This will give you a good head start when it comes time to support additional languages later on.
This applies to both internal as well as public-facing apps. Most frameworks for building mobile apps include support for accessibility. Enabling them is not complicated, though you should consider including testing to ensure your app can be used just as easily by everybody.
Pertinent to even the 2nd and 3rd release, A/B testing is critical to maintain relevance and ensure app success. Not all users have the luxury of a big screen or a full keyboard and mouse so if you want to really disrupt the way teams work and make them mobile-ready you need to test multiple scenarios and paths, determine which resonate most and consider the feedback.
Are you ready to deploy version 2?
As you can see, app development is journey, and mobile is a unique balancing act. Never stop listening to feedback and always ask how your mobile projects can provide the most value for users. Happy coding!
Propelics understands your journey and we specialize in making your ride to a successful mobile app portfolio and mobile strategy as smooth as possible. So please don’t hesitate to reach out to us with any questions or concerns.
Chief Technical Architect at Propelics