Lessons Learned from Building Enterprise Mobile Apps

Over the years, Phase2 has partnered with enterprise clients in healthcare, sports, entertainment, as well as financial institutions and government agencies, to develop and maintain their mobile and native applications. During this time we’ve learned countless lessons through our work.

Build UIs Using Device-specific UX Patterns

Both Google and Apple have extensive documentation of their human interface guidelines and users are expecting familiar experiences from their apps. By deviating from these patterns, you lose the trust of your users and your app looks like a sloppy port from another platform. 
 

Designing and building for two different platforms is more work but the investment is worth it to keep your customers engaged.

Stay on Top of Code Maintenance 

While working in an agile environment with new features being desired by stakeholders, it is easy to forget about or bump maintenance stories to the backlog. Staying on top of dependency updates allows for easier upgrades providing more secure code and the latest device APIs available to your users. 

Between new device launches, OS updates, and framework dependencies, it can seem like a never-ending battle to stay up to date. By planning out regular and frequent updates, we have been able to maintain apps on the bleeding edge of technology. Using React Native has allowed us to adapt to these ever changing requirements with large open source community support and corporate backing. Large jumps between versions are usually messy and difficult to complete and test thoroughly. When we make space in our sprints to get the upgrades completed it prevents us from needing to make those large jumps and if there are breaking changes, we can adapt to them. 

Choose UI Libraries Carefully

When starting a new React Native project, it may seem like a good idea to grab an off-the-shelf UI library like NativeBase, or React Native Paper, to get a head start on your app. However, these libraries have their drawbacks when it comes to modifying them to your enterprise’s brand guidelines. When choosing an off-the-shelf UI library, you must assume that you will outgrow it at some point and need to roll your own components and refactor your code base to remove the library. 

These libraries do have their place for rapid prototyping and proof of concept apps. To test out new features with alpha and beta testers, it can be freeing to grab ready-made components to act as building blocks for a test. 

When we build a custom component library for a client’s app, we leverage design tokens and tools like StorybookJS to create a consistent experience between components. This combination creates a stable base to build complex screens in a modular fashion. 

Testing and QA Take Time

Unless all of your users are using the same device, as some enterprises do with managed devices you’ll need to test across many different devices and platforms. This can seem like an impossible and expensive task, but there are ways to automate and distribute the effort. Unit and E2E testing with tools like Jest and Detox only are as good as the test case coverage. You’ll want to look into more automated testing with tools like Appium or Selenium to simulate specific actions you expect your users to perform. Tools and services like AppCenter, Browserstack, and Testlio can help distribute the workload and cost of having your own device farm to test on. 

Paying attention to these lessons will set you up for success on your next mobile app project. We hope you enjoyed reading the Phase2 blog! Please subscribe below for regular updates and industry insights.