As a Xamarin.Forms mobile developer, I’ve done many apps in an enterprise environment, consumer facing and internal. There are many pitfalls when developing for mobile, and these aren’t specific to Xamarin, but contain a few Xamarin examples.
Here are my stories. I learnt most of these the hard way.
1. Not Abstracting Enough
Abstraction allows you to change code underneath without affecting the rest of the code. Some people wonder why I abstract to such an extent as I do now, and it is because, things get pulled out from under you, more than you would expect.
The database in your app is the least likely component to change. Upper management know nothing of it, and don’t really care. But what does cause an issue here is when you start your app off, then you do something like add an offline sync feature, which is commonly added later in development. If you have your model, talking directly to your database repository, you now have to delve into your business logic, to add this new complex feature, and it gets messy.
Surely your analytics provider such as HockeyApp won’t change. Think again. I have had industry or business changes, result in the analytics provider changing 3 times on me, in the same app, in a matter of 10 months. If you did what I originally did, and just scattered tracking events around your app, directly against the SDK provided, guess how much work you have now.
Private and internal APIs aren’t put to as much scrutiny as public and widely used APIs. Hence, if something needs changing, they are likely to just push a possible breaking change. Being in an enterprise, it is also likely teams don’t have great communication channels between each other. If your API isn’t abstracted from your business logic, it once again, results in going into your business logic, to change the calls you make to the API.
Result – Save yourself a lot of unnecessary dev time.
2. Not Setting Up CI & CD Correctly
This isn’t just about setting up continuous integration and continuous delivery, it’s about setting up your mobile app to allow easy deployment to each environment.
Ensure your configuration for your dev, UAT and production environment, are all done in configuration files. If you hard code these values, it becomes hard to separate out during builds. If you have numerous configuration files for each environment, and use them for each build, it is easy to setup in any automated build process. This also has the added advantage of making your configuration nicely abstracted for unit testing.
Do it first
Just in case it wasn’t obvious, setup your CI & CD as the first thing you do. Manually building and deploying updates to HockeyApp or the store, is so time consuming and tedious, it’s just not worth it. Even if you do it many times, you don’t get much faster at it, I can vouch for that.
Result – Save yourself redeploying your app, numerous times because you keep making mistakes in your config.
3. Forgetting UI Automation Testers
That may include forgetting your future self, if you are also doing the UI Tests.
When developing the UI, take a note of anything that has a changing value of note, and is an interaction point between the user and the app. Add an AutomationId to this element, as you design the View. Make the AutomationId’s consistent, by defining this with the at the start. It will speed up the development of UI Tests by a noticeable degree.
Result – Improve speed with UI Testing, by having everything ready for them. It also reduces the amount of time they come back to the development team to make changes, so they can test.
4. Not Tracking The Right Metrics
Analytics is just placing tracking code through your app, but that won’t win over your manager.
Insights are when you track the right metrics, to form an insight about app usage, and can directly correlate it, to the business goals. Know why your app exists, find out what the goal is, then determine what metrics can be gathered to achieve this, in a nice simple report. If you don’t have this, you will have a hard time, trying to justify your mobile project and your progress. It is also great to see your project making an impact, and if it isn’t you can test and measure, until it does. Giving you a much bigger change at a successful outcome.
Result – Being able to justify your position and success of outcomes to higher level managers.
5. Security As An Afterthought
With security breaches continuing to happen, you can’t afford to be lax with your companies data and security. I have always been very cautious with security, but I have personally stopped someone putting a private security key, hard coded in the app, with their assumption it would be hidden. Your mobile app is completely public. Obfuscation or hard coding data only slows hackers down, it doesn’t stop them. Your app can be completely reverse engineered, once out in the store.
Define a checklist, before you start your app. You can check out the OWASP mobile project checklist to base yours off. Then use this check list to review any Pull Requests, and help ensure you aren’t adding any security holes.
3rd Party Checks
They are companies out there, that can perform automated and manual penetration attacks on your app. If you have very sensitive data, such as a financial or health information, I would recommend you look into these services.
Result – Not having extreme anxiety caused by a data breach and the consequence that may follow.