Problem or use case
The Subscriptions design pass in #1269 brought the screens in line with Bitkit - Handoff v62, but deliberately left four things out because each needs a product or design decision rather than a rendering fix. Three are controls the handoff draws that neither platform has built; the fourth is a colour rule the design system implies but the frames do not commit to.
None of these are regressions — all are absent on iOS as well as Android, so they are unbuilt design, not drift. Recording them here so they are not silently lost now that the surrounding screens look finished.
Proposed solution
1. Edit on the created-subscription detail
The handoff footer is Edit + Delete (Subscription Detail Created); the app shows Delete only. Needs a decision on what is editable after a subscription exists — amount and frequency change what the payer already accepted, so this may mean re-proposing rather than editing in place.
2. Renew on the expired detail
The handoff footer is More Info + Renew (Subscription Detail Expired); the app shows More Info only. A renew entry point implies a re-subscribe flow: whether it re-proposes to the same counterparty, and what happens when their endpoints or terms have changed since.
3. Automatically pay this subscription toggle
Both Subscribe to Subscription and Renew Subscription carry a purple toggle above the swipe. The app has no toggle: SubscriptionsScreen.kt derives payOnAcceptance from subscription.paymentDueOnAcceptance(now) != null, so it is computed and never user-settable. Building it means persisting an auto-pay preference per subscription and deciding what happens on a failed automatic payment.
4. Swipe knob colour: fixed brand, or derived from the balance being spent?
Open design question, currently shipped as fixed brand orange.
Every other confirm swipe in the app follows the balance it spends — SendConfirmScreen does ONCHAIN -> Brand, LIGHTNING -> Purple, SavingsConfirmScreen is Brand, SpendingConfirmScreen and ExternalConfirmScreen are Purple, Boost is Yellow, and hardware is Blue (see #1259). The subscription success confetti already follows the rail too, via subscriptionConfettiResource.
Subscriptions are the exception: the swipe is hardcoded. The design system supports the distinction — the component is a variant set named Swipe to Pay with Savings and Spending variants — but all three subscription frames instantiate the Savings variant, knob #FF4400. It is unclear whether that is deliberate or just the default variant being dropped in.
The visible consequence today: accepting a lightning-paid subscription shows an orange accept swipe and then immediately opens the send flow with a purple pay swipe.
A rail-derived implementation was written and reverted in #1269 pending this decision. To reinstate, cherry-pick 4f64643ae and bfdda4d9f; they add acceptsLightningPayment and isPaidFromSpending(maxSendLightningSats), requiring both that the payee accepts lightning and that the sender can actually cover the amount from spending, plus unit coverage.
Alternatives considered
Shipping 1–3 as rendering-only stubs was rejected: each control implies a flow that does not exist, so a button that does nothing would be worse than its absence. For 4, leaving the subscription swipe hardcoded is defensible as long as it matches the frames, which is why #1269 ships it that way.
Additional context
Problem or use case
The Subscriptions design pass in #1269 brought the screens in line with
Bitkit - Handoff v62, but deliberately left four things out because each needs a product or design decision rather than a rendering fix. Three are controls the handoff draws that neither platform has built; the fourth is a colour rule the design system implies but the frames do not commit to.None of these are regressions — all are absent on iOS as well as Android, so they are unbuilt design, not drift. Recording them here so they are not silently lost now that the surrounding screens look finished.
Proposed solution
1.
Editon the created-subscription detailThe handoff footer is
Edit+Delete(Subscription Detail Created); the app showsDeleteonly. Needs a decision on what is editable after a subscription exists — amount and frequency change what the payer already accepted, so this may mean re-proposing rather than editing in place.2.
Renewon the expired detailThe handoff footer is
More Info+Renew(Subscription Detail Expired); the app showsMore Infoonly. A renew entry point implies a re-subscribe flow: whether it re-proposes to the same counterparty, and what happens when their endpoints or terms have changed since.3.
Automatically pay this subscriptiontoggleBoth Subscribe to Subscription and Renew Subscription carry a purple toggle above the swipe. The app has no toggle:
SubscriptionsScreen.ktderivespayOnAcceptancefromsubscription.paymentDueOnAcceptance(now) != null, so it is computed and never user-settable. Building it means persisting an auto-pay preference per subscription and deciding what happens on a failed automatic payment.4. Swipe knob colour: fixed brand, or derived from the balance being spent?
Open design question, currently shipped as fixed brand orange.
Every other confirm swipe in the app follows the balance it spends —
SendConfirmScreendoesONCHAIN -> Brand, LIGHTNING -> Purple,SavingsConfirmScreenis Brand,SpendingConfirmScreenandExternalConfirmScreenare Purple, Boost is Yellow, and hardware is Blue (see #1259). The subscription success confetti already follows the rail too, viasubscriptionConfettiResource.Subscriptions are the exception: the swipe is hardcoded. The design system supports the distinction — the component is a variant set named
Swipe to Paywith Savings and Spending variants — but all three subscription frames instantiate the Savings variant, knob#FF4400. It is unclear whether that is deliberate or just the default variant being dropped in.The visible consequence today: accepting a lightning-paid subscription shows an orange accept swipe and then immediately opens the send flow with a purple pay swipe.
A rail-derived implementation was written and reverted in #1269 pending this decision. To reinstate, cherry-pick
4f64643aeandbfdda4d9f; they addacceptsLightningPaymentandisPaidFromSpending(maxSendLightningSats), requiring both that the payee accepts lightning and that the sender can actually cover the amount from spending, plus unit coverage.Alternatives considered
Shipping 1–3 as rendering-only stubs was rejected: each control implies a flow that does not exist, so a button that does nothing would be worse than its absence. For 4, leaving the subscription swipe hardcoded is defensible as long as it matches the frames, which is why #1269 ships it that way.
Additional context
Bitkit - Handoff v62, Subscriptions sectionjourneys/subscriptions/; they do not cover any of the above, andjourneys/README.mdrecords the suite as not yet ported tobitkit-ios