-
Notifications
You must be signed in to change notification settings - Fork 9.7k
[in_app_purchase_storekit] Add support for macOS #6517
Changes from 1 commit
0b14213
889977a
587855d
ef56e75
518e1ee
1d93e23
013943a
80f1d3e
2425d2c
388b956
e56276b
8865423
60cad62
699a49a
e6d65fa
231089f
93a8c17
c2a6a33
b4e810f
ac2fef9
8fce70c
5b1ec11
6dc218c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,37 @@ | ||
| // | ||
|
||
| // RunnerTests.swift | ||
| // RunnerTests | ||
| // | ||
| // Copyright 2013 The Flutter Authors. All rights reserved. | ||
| // Use of this source code is governed by a BSD-style license that can be | ||
| // found in the LICENSE file. | ||
| // | ||
|
|
||
| import XCTest | ||
|
|
||
| final class RunnerTests: XCTestCase { | ||
|
||
|
|
||
| override func setUpWithError() throws { | ||
| // Put setup code here. This method is called before the invocation of each test method in the class. | ||
| } | ||
|
|
||
| override func tearDownWithError() throws { | ||
| // Put teardown code here. This method is called after the invocation of each test method in the class. | ||
| } | ||
|
|
||
| func testExample() throws { | ||
| // This is an example of a functional test case. | ||
| // Use XCTAssert and related functions to verify your tests produce the correct results. | ||
| // Any test you write for XCTest can be annotated as throws and async. | ||
| // Mark your test throws to produce an unexpected failure when your test encounters an uncaught error. | ||
| // Mark your test async to allow awaiting for asynchronous code to complete. Check the results with assertions afterwards. | ||
| } | ||
|
|
||
| func testPerformanceExample() throws { | ||
| // This is an example of a performance test case. | ||
| measure { | ||
| // Put the code you want to measure the time of here. | ||
| } | ||
| } | ||
|
|
||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -21,6 +21,6 @@ Downloaded by pub (not CocoaPods). | |
| s.ios.dependency 'Flutter' | ||
| s.osx.dependency 'FlutterMacOS' | ||
| s.ios.deployment_target = '9.0' | ||
| s.osx.deployment_target = '10.11' | ||
| s.osx.deployment_target = '10.15' | ||
|
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. https://docs.google.com/document/d/1wHqr2cob78VfUKhOFEKjaUM_mnV4gL-mg3gSQCFhF7Y/edit What will happen if the user is running 10.13 or 10.14?
Contributor
Author
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. As far as I can tell, users will get a compile-time build error as was also the root cause of test failures 3 and 4 from this comment prompting them to increase their macOS deployment target to 10.15 or higher. Because of those build failures we also had to change the tool (see this separate PR). IIRC users of
Contributor
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. @a-wallen As mentioned above, it's not uncommon in the ecosystem for plugins to have higher minimum requirements than the minimum that Flutter itself supports. On Android, for instance, any platform view-based plugin requires 19+ or 20+ (depending on the mode). If it turns out there are a significant number of people who really don't want to drop pre-10.15 support in order to use this plugin, we could do a follow-up to make the plugin "support" earlier versions but no-op all the methods on those versions (we have some precedent for that approach in some of our iOS plugins). I'd rather not do it if there's not demonstrated demand for it though, since having an app that uses the store but has a viable mode without the store present seems pretty niche, and it adds some annoying boilerplate throughout the plugin. 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. Thanks for the explanations! |
||
| s.pod_target_xcconfig = { 'DEFINES_MODULE' => 'YES' } | ||
| end | ||
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.
I see that you simlinked the RunnerTests folder, but you don't appear to have added any of the tests to this targets. I don't see any tests being run in CI for macOS (compare to iOS).
The Xcode project needs to be set up to run all of the tests from RunnerTests.
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.
hmm… interesting, will look into this
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.
Thank you for pointing this out. I wasn't aware that I initially setup the tests wrong for macOS. This should be fixed with 8865423.