I know Warnings and Optimizations are for a developer to fix if he/she chooses to fix. In this case, I have a good code review practice to have the code generate minimal possible warnings. I was able to resolve many warnings as possible. However, at times, it is possible that XCode generates some stray warnings. I am also capable to fix those. I am so much familiar with the comprehensive list of reasons( Apple Appstore Review Guidelines documents) that can lead to your app's rejection in the review process.
I always work on a terminology of the below process, although I use different tools, this process still applies to me
-Preconditions. Determine what conditions are mandatory for you to review the change. If any of your conditions are missing, reject the update and reopen the issue
-Read the issue. Make sure you are aware of the full scope of the problem
-Reproduce the original state on the master branch. Keep this state open for further comparison
-Test the implemented solution on the feature branch without looking at the source code. Verify that the behaviour matches your expectations
-Come up with a mental model of the solution. Think about how you would implement the solution
-High-level review of the code. Read the source code of the diff of the feature branch and master
-Second, detailed review. should be aware of how the change should work
-Integrity check. Embrace DRY principles. Whenever you can see that there is room for refactoring, point out the cause.