Fix retain cycle in Client

[yewreeka]

Introduction 📟

Client kept a strong reference to Conversations, PrivatePreferences, and XMTPDebugInformation, all which kept a strong reference to Client. I also noticed that XmtpApiClient objects hang around because of ApiClientCache, but not sure if that's really an issue worth worrying about.

Purpose ℹ️

Fix retain cycle in Client

Testing 🧪

Ran tests and checked the memory graph in the example app

[macroscopeapp]

Fix retain cycle by making Conversations.client weak and add ClientError.clientDeallocated for deallocated Client handling across conversation APIs

Convert Conversations.client to a weak reference and route all access through Conversations.requireClient() which throws ClientError.clientDeallocated; update PrivatePreferences and XMTPDebugInformation initializers to drop Client and use ffiClient and historySyncUrl; adjust stream logic to finish with ClientError.clientDeallocated when the client is nil.

📍Where to Start

Start with Conversations.requireClient() and its use across methods in Sources/XMTPiOS/Conversations.swift.

---

Macroscope summarized a0ee41b.

[claude]

Claude Code is working…

I'll analyze this and get back to you.

View job run

[cameronvoell]

thanks for finding this @Jarodl . I added small change to remove the client reference from debuginformation. I also made the client reference in Conversations private, to minimize the chance of someone trying to acceess it when it's not available.

There is a small chance an integrator uses the SDK in an untended way holding a reference to a client.conversations() and then trying to use it when the client is not in memory. But hopefully suggested use cases in our docs will make that rare enough, so still think fixing memory leak possibilities here is the better way to go.

If you can suggest a follow up at some point to pass in some context provider instead of the client so we dont have the risk of someone trying to access the unowned client reference when its not available, that would be awesome. But this is a great improvement 👍

[yewreeka]

thanks for finding this @Jarodl . I added small change to remove the client reference from debuginformation. I also made the client reference in Conversations private, to minimize the chance of someone trying to acceess it when it's not available.

There is a small chance an integrator uses the SDK in an untended way holding a reference to a client.conversations() and then trying to use it when the client is not in memory. But hopefully suggested use cases in our docs will make that rare enough, so still think fixing memory leak possibilities here is the better way to go.

If you can suggest a follow up at some point to pass in some context provider instead of the client so we dont have the risk of someone trying to access the unowned client reference when its not available, that would be awesome. But this is a great improvement 👍

I updated this to use a weak reference to avoid crashing in case it is used improperly, and to throw an error if the client has been deallocated. Let me know what you think! In Convos we're only keeping a max number of clients active at a time now, so this retain cycle is much more obvious now. Thank you!

[cameronvoell]

@yewreeka I just did a dev release of these changes off latest main and stable libxmtp main using the branch cv/jarod/client-retain-cycle-dev-release

Release version will be:

• 4.9.0-dev.fce3ad0
• 4.9.0-dev.fce3ad0-dylib