How to review code in another language/ from another team?

First, I highly recommend this Q&A from a software engineer at Microsoft covering a similar topic. There's a lot of general advice there on how you can legitimately add value reviewing code outside of your domain.

That being said, I really like your instinct around expanding your scope via more holistic code review - I think this is really important in a startup to build resiliency. It's pretty common for a startup to only have 2 iOS engineers or something, so if 1 iOS engineer leaves for whatever reason, the remaining is stuck without a code review partner. This can be fixed if non-iOS folks can do a decent job reviewing iOS code as well.

Since you're an Android engineer, I have 2 more specific pieces of advice for you.

Branch Out Organically From Your Domain

• Certain stacks are more similar than others. For you, the most organic extension by far is going over to iOS - A lot of the concepts between iOS and Android are the same.
• In general, try to stay in the front-end. There's a huge rift between rendering pixels on screen vs. not. So after iOS, web would come next.
• Things get tricky once you expand past front-end, but my recommendation is to start at the back-end portions closest to the front-end. This will almost certainly be the code powering the REST APIs the mobile app calls. Since this is something you are very directly invested in as every front-end engineer should want good APIs to call, you can leave very practical feedback that legitimately makes the code and service and better.

Mirror Your Understanding Of Other Systems To Android

• This is a big reason why I 100% believe that software engineers should learn depth-first. Once you have a very deep understanding of one system, you can understand every other part of the software world by using it as an anchor.
• For Android, here are some high-level concepts that you should try to understand the equivalent of, particularly in other front-end stacks:
  • View controller - For Android, this will be Activities and Fragments.
  • Model - For Android this is generally a data class with annotation processing.
  • User event handling - For Android, these are your listeners like onClick.
  • Networking stack - This one can vary a lot, but you want to understand how the flow of data looks when pulling from an API.
• After you do the "concept matching", you should be able to read other code reviews and think something like, "This commit adds the model for this new screen that will fetch X type of object". From there, you can more or less pretend it's an Android commit (just in a different skin) and look for similar patterns that you would apply to an Android code review.

I mostly end up asking questions.

There's absolutely nothing wrong with this - This is a huge part of effective code review! This is good signal for the author, because if they're getting way too many questions about the purpose of their commit or how their code works, that could be a sign that they can improve in some way (adding more context to summary, using more modularization, etc).