feat: iOS/macOS app icons naming suffix -flavor#362
feat: iOS/macOS app icons naming suffix -flavor#362defuncart wants to merge 2 commits intoAngeloAvv:masterfrom
Conversation
|
It is also possible to override the app icon name during generation: |
Thanks @xShuusui for the info :) I'll leave the PR opened incase @AngeloAvv wants to migrate to suffix naming. |
|
Hey @defuncart , thanks for your help! How does this behave when running the processor(s) multiple times on a previously flavorized project with the suffix approach? I need to understand if this should be considered a breaking change or not. I mean, I'm not concerned about the previously generated assets (which we could get rid of by adding another processor), but I wanna make sure the xcode project/workspace and schema files are not corrupted. |
|
@defuncart are you still able to follow up on this PR? There are a few things that need to be fixed. |
Hi @AngeloAvv, I currently am unable to look further into this, perhaps in a couple of weeks. From what I remember there was no schema corruption. However a few PRs has landed since then, so branch needs a rebase and another round of testing. |
| static String iOSAssetsPath = '$iOSRunnerPath/Assets.xcassets'; | ||
|
|
||
| static String iOSAppIconPath = '$iOSAssetsPath/%sAppIcon.appiconset/%s'; | ||
| static String iOSAppIconPath = '$iOSAssetsPath/AppIcon-dev.appiconset/%s'; |
There was a problem hiding this comment.
Is this an oversight?
| static String iOSAppIconPath = '$iOSAssetsPath/AppIcon-dev.appiconset/%s'; | |
| static String iOSAppIconPath = '$iOSAssetsPath/AppIcon-%s.appiconset/%s'; |
3 participants
Firstly thanks for creating this package, it is very useful, especially when integrating flavors into existing projects.
For iOS & macOS, the generated app icon naming is
<FLAVOR>AppIcon, however generallyAppIcon-<FLAVOR>is the convention. This is also the naming used by flutter_launcher_icons, so when a project depends on both of these packages (i.e. flutter_flavorizr to generate flavors, flutter_launcher_icons to update icons at a later stage), then manual rework is required so thatAppIcon-devetc. is used inproject.pbxproj.This PR adjusts the icon generation to be
AppIcon-devinstead ofdevAppIcon.This could also be a solution for #329 - generate app icons in a format supported also by flutter_launcher_icons, and then use flutter_launcher_icons to add dark/tint icons on iOS, monochrome on android etc.
This isn't technically a breaking change.
AppIcon-devis created and correctly referenced.devAppIcondoes still exist but should not affect the app. A migration could be mentioned to delete the old assets.