Problem or use case
The Subscriptions design pass in #754 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 Android as well as iOS, so they are unbuilt design, not drift. Recording them here so they are not silently lost now that the surrounding screens look finished.
This is the iOS half of synonymdev/bitkit-android#1276; the two should land together.
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. The handoff also draws a whole Renew Subscription sheet for it, laid out like the subscribe sheet.
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: SubscriptionsView.swift derives payOnAcceptance from subscription.paymentDueOnAcceptance(at: now) != nil, 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 — SendConfirmationView.accentColor does blue when hardware, purple for spending, brand for savings; SavingsConfirmView is brand, SpendingConfirm, FundManualConfirmView and SpendingHwSign are purple, Boost is yellow. The subscription success confetti already follows the rail too, picking confetti-orange or confetti-purple off paymentProofKind.
Subscriptions are the exception: both swipes in SubscriptionsView.swift are hardcoded .brandAccent. The design system supports the distinction — the component is a variant set named Swipe to Pay with Savings and Spending variants — but all four 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 #754 pending this decision. To reinstate, cherry-pick d205448f and 96a93af6 (reverted by bf8afd5f); they add acceptsLightningPayment and isPaidFromSpending(maxSendLightningSats:), requiring both that the payee accepts lightning and that the sender can actually cover the amount from spending. Verified on device against a 24,646 sat spending limit: a 5,000 sat proposal rendered purple and a 50,000 sat one orange.
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 #754 ships it that way.
Additional context
Problem or use case
The Subscriptions design pass in #754 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 Android as well as iOS, so they are unbuilt design, not drift. Recording them here so they are not silently lost now that the surrounding screens look finished.
This is the iOS half of synonymdev/bitkit-android#1276; the two should land together.
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. The handoff also draws a whole Renew Subscription sheet for it, laid out like the subscribe sheet.3.
Automatically pay this subscriptiontoggleBoth Subscribe to Subscription and Renew Subscription carry a purple toggle above the swipe. The app has no toggle:
SubscriptionsView.swiftderivespayOnAcceptancefromsubscription.paymentDueOnAcceptance(at: now) != nil, 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 —
SendConfirmationView.accentColordoes blue when hardware, purple for spending, brand for savings;SavingsConfirmViewis brand,SpendingConfirm,FundManualConfirmViewandSpendingHwSignare purple, Boost is yellow. The subscription success confetti already follows the rail too, pickingconfetti-orangeorconfetti-purpleoffpaymentProofKind.Subscriptions are the exception: both swipes in
SubscriptionsView.swiftare hardcoded.brandAccent. The design system supports the distinction — the component is a variant set namedSwipe to Paywith Savings and Spending variants — but all four 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 #754 pending this decision. To reinstate, cherry-pick
d205448fand96a93af6(reverted bybf8afd5f); they addacceptsLightningPaymentandisPaidFromSpending(maxSendLightningSats:), requiring both that the payee accepts lightning and that the sender can actually cover the amount from spending. Verified on device against a 24,646 sat spending limit: a 5,000 sat proposal rendered purple and a 50,000 sat one orange.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 #754 ships it that way.
Additional context
Bitkit - Handoff v62, Subscriptions sectionjourneys/subscriptions/; they do not cover any of the above, andreview-and-subscribe.xmlrecords the orange swipe as the current expectation