Align iOS pricing with editor behavior

[yusuftor]

Summary

• align pricing rounding to 2-decimal round-down behavior used by editor
• align yearly-to-weekly conversion to use 365/7 across SK1/SK2/Stripe/TestStore and discount paths
• add/update pricing tests, including parity checks for .99 yearly -> .72 weekly and .49 monthly

Greptile Summary

Aligned iOS pricing calculations with editor behavior by implementing annualized conversion formulas and consistent 2-decimal round-down rounding across all StoreKit product types (SK1, SK2, Stripe, TestStore).

Key Changes:

• Replaced approximate conversions (7 days/week, 30 days/month, 4 weeks/month) with precise annualized formulas (365/52 weeks/year, 365/12 days/month, 52/12 weeks/month)
• Added roundedPrice() helper method to SK2, Stripe, and TestStore products that applies 2-decimal round-down behavior using SubscriptionPeriod.roundingBehavior
• Updated StoreProductDiscount.periodsPerUnit() to use the same annualized conversion ratios
• Updated test expectations to validate new pricing calculations (e.g., $0.99/year → $0.72/week, $0.49/month → expected weekly price)

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The changes are mathematically sound, well-tested, and consistently applied across all product types. The PR fixes pricing inconsistencies by standardizing on annualized calculations that match the editor's behavior. Tests have been added/updated to validate the new calculations.
• No files require special attention

Important Files Changed

Filename	Overview
Sources/SuperwallKit/StoreKit/Products/StoreProduct/SubscriptionPeriod.swift	Updated period conversion formulas to use annualized calculations (365/52 for weeks, 365/12 for months) for consistency with editor behavior
Sources/SuperwallKit/StoreKit/Products/StoreProduct/SK2StoreProduct.swift	Added roundedPrice() helper and updated price conversion calculations to match editor's annualized approach with 2-decimal round-down behavior
Sources/SuperwallKit/StoreKit/Products/StoreProduct/StripeProductType.swift	Added roundedPrice() helper and updated pricing formulas across all period conversions for Stripe products to align with annualized calculations
Sources/SuperwallKit/StoreKit/Products/StoreProduct/TestStoreProduct.swift	Added roundedPrice() helper and updated all subscription price calculations to use annualized formulas consistent with other product types
Sources/SuperwallKit/StoreKit/Products/StoreProduct/Discount/StoreProductDiscount.swift	Updated periodsPerUnit() to use annualized conversion ratios (365/52, 365/12, etc.) matching the changes in other pricing files
Tests/SuperwallKitTests/StoreKit/Products/StoreProduct/SubscriptionPeriodPriceTests.swift	Updated test expectations to reflect new annualized pricing calculations and added new tests for yearly-to-weekly/monthly conversions

_{Last reviewed commit: 4d61ad8}

[greptile-apps]

_{6 files reviewed, 3 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (3)

Sources/SuperwallKit/StoreKit/Products/StoreProduct/SK2StoreProduct.swift
periodDays still uses the old 7 days/week and 30 days/month approximations while the pricing calculations below (lines 272-274) use the new annualized approach (365/52, 365/12). This inconsistency could cause confusion if periodDays is used elsewhere in the codebase.

Prompt To Fix With AI

This is a comment left during a code review.
Path: Sources/SuperwallKit/StoreKit/Products/StoreProduct/SK2StoreProduct.swift
Line: 236-240

Comment:
`periodDays` still uses the old 7 days/week and 30 days/month approximations while the pricing calculations below (lines 272-274) use the new annualized approach (365/52, 365/12). This inconsistency could cause confusion if `periodDays` is used elsewhere in the codebase.

How can I resolve this? If you propose a fix, please make it concise.

---

Sources/SuperwallKit/StoreKit/Products/StoreProduct/StripeProductType.swift
periodDays still uses the old 7 days/week and 30 days/month approximations while the pricing calculations below (lines 303, 307) use the new annualized approach (365/52, 365/12). This inconsistency could cause confusion if periodDays is used elsewhere in the codebase.

Prompt To Fix With AI

This is a comment left during a code review.
Path: Sources/SuperwallKit/StoreKit/Products/StoreProduct/StripeProductType.swift
Line: 258-263

Comment:
`periodDays` still uses the old 7 days/week and 30 days/month approximations while the pricing calculations below (lines 303, 307) use the new annualized approach (365/52, 365/12). This inconsistency could cause confusion if `periodDays` is used elsewhere in the codebase.

How can I resolve this? If you propose a fix, please make it concise.

---

Sources/SuperwallKit/StoreKit/Products/StoreProduct/TestStoreProduct.swift
periodDays still uses the old 7 days/week and 30 days/month approximations while the pricing calculations below (lines 189, 193) use the new annualized approach (365/52, 365/12). This inconsistency could cause confusion if periodDays is used elsewhere in the codebase.

Prompt To Fix With AI

This is a comment left during a code review.
Path: Sources/SuperwallKit/StoreKit/Products/StoreProduct/TestStoreProduct.swift
Line: 159-160

Comment:
`periodDays` still uses the old 7 days/week and 30 days/month approximations while the pricing calculations below (lines 189, 193) use the new annualized approach (365/52, 365/12). This inconsistency could cause confusion if `periodDays` is used elsewhere in the codebase.

How can I resolve this? If you propose a fix, please make it concise.