Is this going to have an official release?

[Solace-Studios]

Interested in a tool that generates RIBs with needle automatically

[danifru]

Not chasing the release, but the question underneath it is one I would like to ask.

LifecycleKit comes out of the RIBs lineage, where scoping is explicit and a child's lifetime is something you hold rather than something you infer. SwiftUI went the other way entirely: lifetime is derived from view identity and you get very little say in it. Those two models seem fundamentally at odds, and most attempts I have seen to reconcile them end up either running an object graph alongside the view tree, or giving up and letting SwiftUI own everything.

Where did you land on that?

And is getback-compose you trying the same idea on the other platform because Compose gives you more room to do it, or less?

[AdamShare]

Not chasing the release, but the question underneath it is one I would like to ask.

LifecycleKit comes out of the RIBs lineage, where scoping is explicit and a child's lifetime is something you hold rather than something you infer. SwiftUI went the other way entirely: lifetime is derived from view identity and you get very little say in it. Those two models seem fundamentally at odds, and most attempts I have seen to reconcile them end up either running an object graph alongside the view tree, or giving up and letting SwiftUI own everything.

Where did you land on that?

And is getback-compose you trying the same idea on the other platform because Compose gives you more room to do it, or less?

I may come back to LifecycleKit at some point and update it into a much better place, but the underlying idea is still pretty close to how I think about this.

The distinction I would make is between a view-oriented architecture and a view-owned architecture. I'm very much in favor of the former. A business component can map 1:1 with a view and be designed around that view. What I don't want is for the view lifecycle to implicitly own the state, references, dependencies, and business logic behind it.

This came up quite painfully with RIBs and UIKit. RIBs gave us an explicit business-logic hierarchy and ownership model, but UIKit also had its own independently mutable view-controller hierarchy. There wasn't always a great way to bind mutations made to that UIKit hierarchy back into the RIB hierarchy. Things like navigation, back handling, and transitions could therefore cause the two trees to get out of sync. We saw a lot of bugs at Uber that ultimately came from that mismatch.

That experience made me more interested in making the business state the source of truth rather than having the UI hierarchy implicitly become another source of state.

The frameworks themselves have different problems here. Traditional Android views have lifecycles that are primarily concerned with rendering and presentation, so making them own application state can be particularly fragile when the view hierarchy is destroyed and recreated. SwiftUI is much better at preserving state because it is fundamentally state-driven, but because views are declarative and can be recreated, it can sometimes be harder to reason about the lifetime and identity of objects associated with them.

What I'm trying to preserve is what these frameworks are particularly good at: the UI reacts to state changes, and user interaction feeds changes back into state. But I want the important application state, navigation state, dependencies, and ownership to live outside of the rendering lifecycle.

That's also the main idea behind GetBack Compose. It's quite view-oriented—the business/navigation structure can correspond directly to the views being displayed—but the navigation stack is state owned by the business-logic layer. Compose renders that state rather than implicitly owning it.

So I don't see this as choosing between RIBs and SwiftUI/Compose. It's more about separating what the UI represents from what owns the application's state and lifecycle. Those can have a very close, even 1:1 relationship without making the UI framework the owner of everything.

[danifru]

That distinction lands, view-oriented without being view-owned is exactly the failure mode we keep hitting when SwiftUI identity decides to recycle something the business layer still needs. The Uber dual-hierarchy story is useful too. Reclip is a small team shipping consumer features fast, so we care less about rebuilding RIBs and more about people who have already felt that pain and refuse to let the UI own the truth. Would you be up for a short call this week? Happy to walk through what we are building and see if it is interesting on your side. Dan

…

On Sun, 23 Aug 2026 at 15:41, Adam Share ***@***.***> wrote: *AdamShare* left a comment (AdamShare/LifecycleKit#1) <#1 (comment)> Not chasing the release, but the question underneath it is one I would like to ask. LifecycleKit comes out of the RIBs lineage, where scoping is explicit and a child's lifetime is something you hold rather than something you infer. SwiftUI went the other way entirely: lifetime is derived from view identity and you get very little say in it. Those two models seem fundamentally at odds, and most attempts I have seen to reconcile them end up either running an object graph alongside the view tree, or giving up and letting SwiftUI own everything. Where did you land on that? And is getback-compose you trying the same idea on the other platform because Compose gives you more room to do it, or less? I may come back to LifecycleKit at some point and update it into a much better place, but the underlying idea is still pretty close to how I think about this. The distinction I would make is between a *view-oriented architecture* and a *view-owned architecture*. I'm very much in favor of the former. A business component can map 1:1 with a view and be designed around that view. What I don't want is for the view lifecycle to implicitly own the state, references, dependencies, and business logic behind it. This came up quite painfully with RIBs and UIKit. RIBs gave us an explicit business-logic hierarchy and ownership model, but UIKit also had its own independently mutable view-controller hierarchy. There wasn't always a great way to bind mutations made to that UIKit hierarchy back into the RIB hierarchy. Things like navigation, back handling, and transitions could therefore cause the two trees to get out of sync. We saw a lot of bugs at Uber that ultimately came from that mismatch. That experience made me more interested in making the business state the source of truth rather than having the UI hierarchy implicitly become another source of state. The frameworks themselves have different problems here. Traditional Android views have lifecycles that are primarily concerned with rendering and presentation, so making them own application state can be particularly fragile when the view hierarchy is destroyed and recreated. SwiftUI is much better at preserving state because it is fundamentally state-driven, but because views are declarative and can be recreated, it can sometimes be harder to reason about the lifetime and identity of objects associated with them. What I'm trying to preserve is what these frameworks are particularly good at: *the UI reacts to state changes, and user interaction feeds changes back into state.* But I want the important application state, navigation state, dependencies, and ownership to live outside of the rendering lifecycle. That's also the main idea behind GetBack Compose. It's quite view-oriented—the business/navigation structure can correspond directly to the views being displayed—but the navigation stack is state owned by the business-logic layer. Compose renders that state rather than implicitly owning it. So I don't see this as choosing between RIBs and SwiftUI/Compose. It's more about separating *what the UI represents* from *what owns the application's state and lifecycle*. Those can have a very close, even 1:1 relationship without making the UI framework the owner of everything. — Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=B74TXX4MFONWZC24I4BSFTL5LNXJHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZYHA4DOMRVGE4KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5388872518>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B74TXX5LN6S5SK3LKT7WVZD5LNXJHAVCNFSNUABFKJSXA33TNF2G64TZHMZDSNRTG4YTMMBTHNEXG43VMU5TCMZUGUZDGOJSG42KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/B74TXX3ARABJOK3EXK3UA7L5LNXJHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZYHA4DOMRVGE4KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/B74TXXZYMJZDLIOG5IBTA5D5LNXJHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZYHA4DOMRVGE4KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>