Code Audit for Android/iOS

Question

I have just been given a task at work to help audit a code base for a mobile app. I am not a mobile app programmer, although I've been a software developer for many years now, but know nothing about mobile apps. I was wondering if there's any tips or tools that I can use for this code audit.

I have seen the replies to this older post for a Java EE application, which can't be applied to my case since they're mostly based on having maven to build the app and in my case they use Gradle. Also these replies are from 2011 and perhaps there are more recent ones I'd really be very grateful to hear about.

Answer 1

In itself, the fact of appointing someone with no experience in the target environment seems like a complete nonsense to me, so I'd question the management here.

I do hope for you that you know at very least the languages these apps are written in: probably Java for Android & Objective-C for iOS (your question didn't mention what technologies your past experience concerned). If not, you're bound to just make remarks about comments, file size, and maybe some about naming conventions, which is of little interest compared to a real audit.

Beyond programming languages, iOS and Android are designed in very different ways, with different conventions & patterns. I actually know very few people who are really good in both environments, and there's a reason for this: these are different worlds, each of which you can easily spend your whole time on to learn APIs, common libraries, design philosophy, work-arounds for common issues, and understand a bit of how the internals work.

I don't know how much time you have to perform this task, but I'd suggest you learn how to code a basic app on the target environment, and learn about the key components.

My approach is generally:

• gather some context from the team
• get the source
• build the app & get a taste of what it's doing (I usually hand-draw a screen flow diagram at this stage, it's useful later when you navigate in the code), also take note of bugs, slow features, non-user-friendly stuff (feedback is important to the team)
• go to the source code, examine it's macroscopic layout: . look at the build scripts to see what external libs it's using . take note of the general package hierarchy, check that the naming is consistent, that packages are not overloaded with junk . look generally at the class naming: is it consistent? do class names help figure out what's actually inside . do some basic stats about file sizes: it's something that can quickly indicate some design flaws
• now about the code in itself: . read it until satisfied that you understand the general way it works (drawing a technical flow diagram helps), I like to start by the app entry-point (generally an activity in Android) . make sure you spot how what you read achieves what you saw while testing the app . take note of bad coding habits you spot while reading (naming, comments, it can be anything: there's no limit to how bad the code can be ^^) . take note of unreadable/overly-complex bits of code (but don't spend days just to understand them) . if you had noticed slow features in the app, it might be worth looking at those bits of code a little more carefully . have a good night sleep, then re-read all your notes, and try to extract some high-level remarks about the application design

Now, specifically for Android, here the most common list of things to look for, based on my experience:

• components life-cycle handling issues (for components like activities, services, fragments and such): symptoms include device rotation and application switches causing issues
• thread handling issues (things done on the UI thread, when they should really run in background)
• massive activities / services (many people think that creating activities / fragments / services is all that's required in terms of architecture - it is true only for very simple apps)

I won't enter more into the specifics, because people a lot more intelligent than me wrote books about this. And you have to code apps to really get a grasp of those subjects: a lot of them, so that's what you should start with: code apps yourself, otherwise: 1/ your audit will be irrelevant 2/ the team will spot your lack of skills pretty fast - depending on the aim of this audit, you might have a very hard time facing them...