-
Notifications
You must be signed in to change notification settings - Fork 334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Customer Center compilation flag #4149
Changes from all commits
5efc10b
5938194
e8a666d
ca9a23e
ac5d90d
94806c4
cac09a4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,6 +11,8 @@ | |
// | ||
// Created by Cesar de la Vega on 18/7/24. | ||
|
||
#if CUSTOMER_CENTER_ENABLED | ||
|
||
import Foundation | ||
Comment on lines
+14
to
16
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. okay, I'll admit that it's annoying to have this in 30 files, but it legitimately took me just a couple of mins to add There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. and we'll only need to remove it when we're ready to ship the feature There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I bet we can probably leave it out in some of these files... But better to be sure 👍 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No idea if this is in the realm of possibilities, but would it be possible to have the the flag only around public entry points of the Customer Center feature? E.g. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. While that should be fine for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if.. we only wrap the constructor of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There are a bunch of internal types inside Having said that, we would still be exposing new types which can potentially change, even if they are unusable... So I don't think it's ideal 😓 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm yea, not ideal indeed. 🤔 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I figured we can probably fine tune this a bit. TBH I figured I'd go with the most brainless imaginable approach which is to wrap all the things just because:
If you feel that it's still worth the trouble, I'm more than happy to do it, but it might take me a while, so feel free to take it over and carry it through the finish line. I figured my biggest contribution here would be setting up the skeleton, i.e.: the compilation flag and the usage, feel free to adapt it to whatever is best! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah I think you're making very good points. Not worth the extra effort to do fine tuning imo. Also, we don't have a good idea what fine tuning would even look like yet. |
||
import RevenueCat | ||
|
||
|
@@ -30,3 +32,5 @@ protocol CustomerCenterPurchasesType: Sendable { | |
product: StoreProduct) async throws -> PromotionalOffer | ||
|
||
} | ||
|
||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in order to merge to
main
, we just make a new PR that kills this line. And then we bring it back in the integration branchThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that since the flag is only defined for the Xcode project, SPM and CocoaPods builds will already evaluate it to false and skip Customer Center. Carthage won't, however, since it reads from Xcode, so we should remove it to merge into
main