Modularization Risk Radar (Community Research)

[SzymonMrozek]

Context and intent

Hello Wire team, and thank you for all the ongoing work on modularization.
As a past contributor and someone who values Wire's open-source approach, I've been experimenting with a coding agent (Codex 5.3 extra high) as a research tool for relatively large codebases.
I noticed the ongoing modularization effort and thought this was a good moment to run that experiment and share the findings.
This is an independent, volunteer architecture review.

It is shared in a collaborative spirit:

• findings may be useful, partially useful, or not useful for your roadmap;
• some conclusions may be wrong and should be validated by maintainers (it was constrained to a 8h spike);
• there are no expectations attached to this report.

If helpful, this can be treated as an early risk scan while modularization is still at a stage where directional corrections are relatively low-cost.

Wire iOS Issues are currently disabled, so this pull request is used as the discussion thread for architecture feedback.
This is a docs-only contribution with one central report and linked subreports.

What is in scope

• Main report:
  • thoughts/shared/research/2026-02-25-wire-ios-modularization-master-report.md
• Detailed subreports (boundaries, DI, routing, shared modules, data ownership, tooling):
  • thoughts/shared/research/*subreport.md

No production code, no build logic, and no runtime behavior was changed.

TL;DR

• Modularization progress is real and meaningful.
• The biggest early risks are around cross-feature boundaries and integration shape, not feature extraction itself.
• Priority order in the report:
  • Top: interface consistency, routing capabilities, app-boundary DI cost, tooling/DX.
  • Mid: internal layer leakage, broad shared-module ownership drift.
  • Low: assembly re-exports, data-model ownership split.

Impact Areas

Recommended Sequence

Reading path

• Start here:
  • thoughts/shared/research/2026-02-25-wire-ios-modularization-master-report.md
  • Jump to detailed examples directly from each issue section in the master report.

Feedback welcome (if useful)

• Validate or challenge evidence quality in the master report (file/line references).
• Confirm whether the top-priority ordering matches current team pain.
• Confirm whether the proposed sequence is realistic for current roadmap constraints.

Non-goals

• Not a rewrite proposal.
• Not a demand for immediate tooling migration.
• Not a claim that all findings are final or complete.

[CLAassistant]

All committers have signed the CLA.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[SzymonMrozek]

cc @johnxnguyen @netbe (not sure if you noticed this 'PR' 😄)

[netbe]

cc @johnxnguyen @netbe (not sure if you noticed this 'PR' 😄)

@SzymonMrozek I noticed, but didn't take the time yet to read through :)

[johnxnguyen]

cc @johnxnguyen @netbe (not sure if you noticed this 'PR' 😄)

Hey @SzymonMrozek ! Sorry the delay. I hope that you have been well. Thanks for your interest in sharing these insights with us, we don't get much external engagement but it's always nice to see it. I haven't had a chance to look at your findings yet but it's on my list and I look forward to it.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Please update it or close it in case is not relevant anymore.