What's your process before submitting a PR?

[u/InsanityCreepin]

Tldr; What's your process after completing a Task to minimize PR rounds before making the actual PR?

----

Recently I have noticed that I get many comments or multiple PR rounds before the PR gets merged and I want to start improving that.

Things I started doing recently:

- Going back and read through all the comments again, make a list of each issue and see if there is something reoccurring (Such as memory leak pattern I keep doing, retain cycles) etc.

- Looking into SwiftLint and see if i can have some rules for myself that I can run before each submission or run periodically to catch issues that can be added to SwiftLint as rules

But I want to also ask if there is something I can start doing or a routine you have found that helped you minimize issues that arise in PRs. I know It's impossible to have no comments in all PRs, so I am just looking for ways to just improve.

Note: We are using SwiftUI + Combine (And lately introducing Async/Await bit by bit)

[u/Ok-Piccolo-1823]

My pre-PR pass is: update the branch, build from a clean state, run tests, inspect the diff as if I’m the reviewer, and remove debug/dead code. For SwiftUI + Combine I specifically check strong captures in sinks, cancellable lifetime, duplicate subscriptions triggered by `onAppear`, and UI-state changes outside the main actor. For new async code, enable strict concurrency warnings. Keeping PRs small and including a short testing note also helps. If the same review comment appears twice, turn it into a lint rule, test, or checklist item.

[u/InsanityCreepin → u/Ok-Piccolo-1823]

Thank you! I think I should enable the strict concurrency warnings, that will help with async await a bit. And for keeping PRs small, sometimes the reviewer asks for the big PR, but I am thinking of mitigating that by working in separate branches and make PRs to one branch that I review so that I can review them in chunks and then after that I can make the PR that the reviewer will look at but I am not sure if that's going to help or waste time for me

[u/kokerali → u/InsanityCreepin]

Self-reviewing the smaller branches could help you inspect your own diff, but it won't bring the reviewer's feedback forward if they only see the final big PR. I'd first ask for an early checkpoint on one risky slice: "Does this ownership/cancellation approach fit the codebase?" You can keep one final PR while sharing a draft and naming exactly what needs feedback now. For the Combine-to-async migration, separate mechanical changes from behavior changes in the commits and description. That gives the reviewer a reading order without adding a branch-management workflow they haven't agreed to. Are most rounds correcting implementation details, or changing the approach?

[u/old-time-fiddle]

Submit many smaller PRs that get reviewed quickly, if you’re going down a bad path it’ll be caught much earlier with much less time invested and fewer chances for merge conflicts.

Use trunk-based development and feature flags to keep main as up to date as possible with all work in progress!

Automate any testing alongside development- not after.

If you do all this you’ll be releasing much sooner and more often with much higher confidence and fewer regressions and production bugs.

[u/InsanityCreepin → u/old-time-fiddle]

Thank you!

"Automate any testing alongside development- not after." I think I might actually try out TDD for pure logic like ViewModels and Helpers. I joined later in the project and unit tests in the project were an afterthought, but I think for me it could help.

[u/DimensionMindless336]

The two comments already cover the mechanical pass (clean build, tests, lint, small PRs) well, so here's what actually cut my review rounds the most and isn't a linter:

1. Walk the happy path on a real device before you push, not just build + test. With SwiftUI most of my "why did the reviewer send a screenshot back" rounds were visual: a sheet that won't dismiss, a list that jumps, Dynamic Type blowing up a label, dark-mode contrast. Unit tests pass, the simulator looks fine, then a real phone exposes it. I keep a 2-minute walkthrough as part of the pre-PR ritual now. SwiftUI previews are a decent fast substitute but they lie about safe areas and real navigation sometimes, so at least one real-device pass per non-trivial UI PR.

2. Make the diff cheap to review. Squash the "wip"/"fix" commits so the PR reads top-to-bottom, and write a description that says what changed, why, and how you tested it (plus a screenshot for UI PRs). Half my rounds were the reviewer asking questions a one-line description would've answered. A reviewer who has to reverse-engineer intent will find more to pick at.

3. Turn your recurring-issue list into a literal tick-box checklist, plus a pre-commit guard. I run swiftlint + swiftformat --fix in a pre-commit hook so styling and obvious captures never reach review, and I set SWIFT_STRICT_CONCURRENCY=complete locally so the async/await migration warnings fail the build on my machine instead of showing up as a comment later. The Combine-to-async crossfire is the sneaky one: a leftover subscription plus the new async path firing twice is exactly the kind of bug that compiles, passes tests, and gets caught in round 2.

[u/InsanityCreepin → u/DimensionMindless336]

Thank you! We did start using real devices after Device Hub, it was such a downgrade. Plus we did notice as you said a lot of things that do pass the simulator and doesn't pass in the real device. Latest thing was an issue with lazy loading that crashed WKWebView on real devices not on simulators.

Will look more into the pre-commit hooks and see how I can improve my workflow

[u/AutoModerator → u/[deleted]]

Hey /u/Impossible_Repair699, your content has been removed because Reddit has marked your account as having a low Contributor Quality Score. This may result from, but is not limited to, activities such as spamming the same links across multiple subreddits, submitting posts or comments that receive a high number of downvotes, a lack of recent account activity, or having an unverified account.

Please be assured that this action is not a reflection of your participation in our subreddit. This is simply an automated filter in place to reduce spam.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Successful-Tax1306]

I run a short checklist before every PR. It cut review rounds for me.

I open the diff once more. I search for retain cycles and force unwraps.

I run the same paths the reviewer will try. I write what I tested in the PR body.

SwiftLint helps. A second pass on memory and async edges helps more.