The generated builds are great, but lack a lot of extensions necessary for proper development.
It would be really beneficial if we could be able to process AndroidManifest.xml or Info.plist manually during the build process.
Specifically:
I have to check "None" when asked about encryption algorithms every time I upload a build to TestFlight.
The names of the XCode output are always "app" and not the configured project name.
I would like to have a different app logo for the play store/app store since pictures can't be transparent (see below)
Android integrations with the phone's sensors require specific AndroidManifest.xml configurations I have to do manually every time
Change the Certificate Bundle Identifier for the outputted XCode project that overrides the app-<build architecture>-Release identifier
On a Side Note:
The output icon1024.png as apart of the assets can't be transparent, and it fails validation on the initial output. This should be seen as a user bug fixed with this enhancement.
Why is there a separate Debug release type with every Release release type? They seem identical and don't serve a purpose outside of the Debug button in IntelliJ / XCode. This seems to slow down builds by 2x.
What is the purpose of including iosX64? The only Apple products that have an X64 chip are pre-2020 MacBooks (which can simulate Arm64 iPhones anyways)
The generated builds are great, but lack a lot of extensions necessary for proper development.
It would be really beneficial if we could be able to process
AndroidManifest.xml
orInfo.plist
manually during the build process.Specifically:
AndroidManifest.xml
configurations I have to do manually every timeapp-<build architecture>-Release
identifierOn a Side Note:
icon1024.png
as apart of the assets can't be transparent, and it fails validation on the initial output. This should be seen as a user bug fixed with this enhancement.Debug
release type with everyRelease
release type? They seem identical and don't serve a purpose outside of theDebug
button in IntelliJ / XCode. This seems to slow down builds by 2x.iosX64
? The only Apple products that have an X64 chip are pre-2020 MacBooks (which can simulate Arm64 iPhones anyways)