Separate appnames for ios and package name for android

[uloco]

Feature Request

It would be great to have a way to specify different appnames or package names for ios and android without any (com.) prefixing magic happening by upgrade helper.

Why it is needed

Our app does not have a .com domain so our bundle identifier is different than just com.appname.

I ran into multiple issues in the past and also recently, where I used the app name field to put in our app name and did not realize it automatically prefixes it with com. for android.
I had build issues where our package (obviously) could not be found. This is a possible issue a lot of people have, which could easily be fixed.

Possible implementation

Just add two fields to specify the appname for ios and the package name for android without prefixing them with com. on android automatically.

[smallsaucepan]

@uloco about to look in to this. Could you please review the solution below? You mention wanting to add TWO new fields? I think only one is required though.

What's your app name? [RnDiffApp____]

Say we add a single "app namespace" field ...

Default values would be:

What's your app name? [RnDiffApp____]
What's your app namespace? [com________]

This would give same result as the tool does now with iOS name RnDiffApp and Android files such as com/rndiffapp/MainActivity.java

Entering custom values for either:

What's your app name? [UpgradeHelper ____]
What's your app namespace? [au.org.mycorp ______]

Would give iOS name of UpgradeHelper and Android files such as au/org/mycorp/upgradehelper/MainActivity.java

[smallsaucepan]

@lucasbento / @pvinis would one of you like to assign this to me? Have forked and will return with a PR.

[pvinis]

feel free to open up a PR 👍

[smallsaucepan]

Merged by @pvinis. You happy to close this @uloco ?

[uloco]

On vacation right now and can't test. Will come back to this next week

[uloco]

Unfortunately this fix does not solve my problem. Our android package name is not the same as just package.appname because it has a suffix also. I would really just let us enter two completely separate input fields for both platforms since we could also just specify two completely different package names in reality.

For example our iOS app is called Smokeless and our android package name is world.smokeless.android.
I can't use it as is with the current change (or don't know how)

[pvinis]

i wonder if something like this would work for you.

if not, I'm not sure exactly what the issue is. could you give specific examples and the steps you have to do now manually in order for the upgrade-helper to work for you, so we can try and make these automatic?

[uloco]

it would work for android but, what if there is a reference to the ios app in AppDelegate for example?

[uloco]

In my opinion it would be way easier to understand what parts apply where to just have two separate input fields, one for ios and one for android. What if my iOS app is called "foo" and my android package is "bar.baz.abc"? The ios and android app names / packages don't have to be the same in general.

[smallsaucepan]

Understand what you're getting at @uloco. See below for a possible solution. Placeholder text is displayed below in italics.

Default values would be:

What's your app name? [ RnDiffApp ]
What's your app package? [ com.rndiffapp ]

Entering a value for app name would give:

What's your app name? [ UpgradeHelper ]
What's your app package? [ com.upgradehelper ]

Entering a value for package would give:

What's your app name? [ RnDiffApp ]
What's your app package? [ au.org.mycorp.coolapp ]

This aims to strike a balance between indicating to a novice that changing the app name changes the default app package, and also allows the experienced dev to enter a completely unrelated package name.

Would that solve the issue? Will wait for feedback before proceeding with any further changes.

[uloco]

don't like the implicit logic in behind what input field is filled or not (ux wise bad in my opinion), but you decide.

feature wise if I can specify two fields that don't affect each other this is fine.