First off, don't judge on one task like that, there's just too many variables (for example: Maybe it's something built-in to iOS while Android requires writing a custom library or working around a broken API). Assuming this is a pattern, though, there's lots of ways to get more insight.
For example, next time, have the iOS guy work with the Android team, and vice-versa. It'll help cross-train and promote different ways of solving problems, but also give great insight into what's actually happening. This could just as easily apply to someone from the backend team or whatever.
Another way is daily standups. Is the Android team getting stuck on something for days a time? Are they constantly blocked by another team or bad process? Are they making progress on whatever tasks they are doing?
Looking at commit and PR history is another way to judge, provided it's someone who can code who's looking and judging. Is the amount of work accomplished for the velocity of check-ins reasonable? If people are consistently only doing a couple lines a day that's a good hint something's going on -- and is worth having a discussion about. I want to emphasize though this needs to be a pattern. Some of the hardest bugs I've fixed that have taken days to narrow down are basically a single-character change (< instead of <= for example).
Depending on the situation, it might be possible to get regular demos, eg: every few days. One way to do this is break down feature work into smaller iterative chunks/stories. Beware though, it's a thin line to becoming an obnoxious micro-manager.
