You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> flutter build ios --flavor free
> flutter install -d 'iphone 14'
The Xcode project defines schemes: free, paid
You must specify a --flavor option to select one of the available schemes.
EDIT: links to repos mentioned in this comment and next one added for convenience:
The following steps are an alternative reproduce, using a repo with very similar structure as the integration test above, and notes to create it from scratch, that is, flutter create.
> git clone https://github.com/bradyt/flutter-flavor-reproduce-steps
> cd flutter-flavor-reproduce-steps
> flutter build ios --flavor free
> flutter install -d 'iphone 14'
The Xcode project defines schemes: free, paid
You must specify a --flavor option to select one of the available schemes.
First searching the issue tracker, then searching the wider internet, with search terms like "flutter install scheme flavor ios", I may have some solution, trying a video on youtube.
In that repo, if I use Xcode to delete the third scheme "Runner" leaving schemes "cookie" and "coffee", I get the bug above.
So my naive impression is that for those of us creating two schemes for flavors, we have to keep a third, the old Runner scheme, around.
The author mentions in the youtube channel that they could have deleted the default configurations, but that also lead to errors, though I haven't tried yet to see if those are easily fixable.
@bradyt
Although I didn't try the integration_test flavor example you shared above, I tried one of flutter's flavor example based on this article that has dev and prod flavors. Running the said command built and installed the dev version of the app on my iphone properly without any issues:
dhs@Dhss-MacBook-Pro flavors_example % flutter build ios --flavor dev
Building com.nevercode.triage for device (ios-release)...
Found saved certificate choice "Apple Development: Darshan Kawar (AV76JL68FU)". To clear, use "flutter config".
Signing iOS app for device deployment using developer identity: "Apple Development: Darshan Kawar (AV76JL68FU)"
Running Xcode build...
└─Compiling, linking and signing... 5.0s
Xcode build done. 9.4s
Built /Users/dhs/Documents/NCFlutter/triage-examples/flutter_examples/flavors_example/build/ios/iphoneos/Runner.app.
dhs@Dhss-MacBook-Pro flavors_example % flutter install -d 21150b119064aecc249dfcfe05e259197461ce23
Installing com.nevercode.triage to Darshan's iphone...
Uninstalling old version...
dhs@Dhss-MacBook-Pro flavors_example %
Right the "Flutter Explained" example follows that blog article you linked.
My understanding is that the integration test discards the original Runner scheme, and original configurations, and creates the two schemes and sets of matching configurations to replace.
I get the sense that Flutter requires that original Runner scheme and configurations in order for flutter install to work.
If that's correct, is it expected behavior that flavor/scheme usage must retain that Runner scheme? I found it interesting that it didn't seem to be needed for flutter run. I get the sense that someone deliberately did not want a requirement on the original Runner scheme, but didn't finish up ensuring it worked with flutter install.
Should we simply close issue? The issue as originally described seems solved. I don't know if my previous question about Runner scheme is really relevant to Flutter.
Um, never mind, I think I finally got it. Not sure why I didn't wait a few more seconds for recent test.
I think not only is it required to keep the Runner scheme, but the Runner scheme has to have a distinct bundle ID from each of the schemes, or else a flutter build ios --flavor dev && flutter install -d "iphone 14" will overwrite an install from the prod listing at TestFlight, rather than the install from the matching dev listing.
In other words, if the bundle ID of the prod scheme matches the bundle ID of the original Runner scheme, then locally building and installing the dev scheme will overwrite an install from the TestFlight listing for prod. That seems a little surprising, and something to be aware of.
I've renamed the bundle ID for Runner as com.example.app.Runner, to be distinct from prod bundle ID, and things seem to be working better.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
bradyt commentedon Feb 9, 2022
The following steps are an alternative reproduce, using a repo with very similar structure as the integration test above, and notes to create it from scratch, that is,
flutter create.bradyt commentedon Feb 10, 2022
First searching the issue tracker, then searching the wider internet, with search terms like "flutter install scheme flavor ios", I may have some solution, trying a video on youtube.
I found a way to recreate this breakage on a working app, at the associated example I found at https://github.com/Flutter-Explained/flavor_tutorial.
In that repo, if I use Xcode to delete the third scheme "Runner" leaving schemes "cookie" and "coffee", I get the bug above.
So my naive impression is that for those of us creating two schemes for flavors, we have to keep a third, the old Runner scheme, around.
The author mentions in the youtube channel that they could have deleted the default configurations, but that also lead to errors, though I haven't tried yet to see if those are easily fixable.
darshankawar commentedon Feb 10, 2022
@bradyt
Although I didn't try the integration_test flavor example you shared above, I tried one of flutter's flavor example based on this article that has
devandprodflavors. Running the said command built and installed thedevversion of the app on my iphone properly without any issues:bradyt commentedon Feb 10, 2022
Right the "Flutter Explained" example follows that blog article you linked.
My understanding is that the integration test discards the original Runner scheme, and original configurations, and creates the two schemes and sets of matching configurations to replace.
I get the sense that Flutter requires that original Runner scheme and configurations in order for
flutter installto work.If that's correct, is it expected behavior that flavor/scheme usage must retain that Runner scheme? I found it interesting that it didn't seem to be needed for
flutter run. I get the sense that someone deliberately did not want a requirement on the original Runner scheme, but didn't finish up ensuring it worked withflutter install.bradyt commentedon Feb 10, 2022
Should we simply close issue? The issue as originally described seems solved. I don't know if my previous question about Runner scheme is really relevant to Flutter.
darshankawar commentedon Feb 10, 2022
Thanks, yes, closing based on above comment.
bradyt commentedon Feb 11, 2022
@darshankawar Can you please provide the code example you ran described here?
This way if I have more issues, we can all start from the minimal example you have, that should ideally work better than any of mine.
Asking for source code that works with current Flutter, if possible.
bradyt commentedon Feb 11, 2022
Um, never mind, I think I finally got it. Not sure why I didn't wait a few more seconds for recent test.
I think not only is it required to keep the Runner scheme, but the Runner scheme has to have a distinct bundle ID from each of the schemes, or else a
flutter build ios --flavor dev && flutter install -d "iphone 14"will overwrite an install from theprodlisting at TestFlight, rather than the install from the matchingdevlisting.bradyt commentedon Feb 12, 2022
In other words, if the bundle ID of the
prodscheme matches the bundle ID of the original Runner scheme, then locally building and installing thedevscheme will overwrite an install from the TestFlight listing forprod. That seems a little surprising, and something to be aware of.I've renamed the bundle ID for Runner as
com.example.app.Runner, to be distinct fromprodbundle ID, and things seem to be working better.github-actions commentedon Feb 26, 2022
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.