Bug: iOS target ignores `title` from spec, using `package.name` for the home screen display name

[dogancankalinci]

When building an app for the ios target, Buildozer ignores the title field in the buildozer.spec file for setting the application's visible name on the iOS home screen. Instead, it shows the value of package.name in the home screen, which is intended for the bundle identifier, not for display.

To Reproduce

Steps to reproduce the behavior:

1. Create a buildozer.spec file with distinct title and package.name values.
2. Build and install the application on a device.
3. Check the app's name on the device's home screen.

Expected behavior

The application's name displayed on the iOS home screen should be the value specified in the title token.

Actual behavior

The application's name on the home screen is the value from the package.name token.

[AndreMiras]

Great catch, thanks for the report, do you want to give it a try to fix it?
A possible fix would be to keep package.name for project/scheme/path naming but set CFBundleDisplayName and probably CFBundleName from config.get("app", "title") when TargetIos.build_package() updates the plist.
The unit test could extend tests/targets/test_ios.py::test_build_package_no_signature with distinct title and package.name values and assert the dumped plist includes the title.
Let us know what you think

[dogancankalinci]

Hi, thanks for the feedback. I don’t have time to work on a fix right now, but I wanted to report the issue so it’s visible. If someone wants to pick it up, feel free. The proposed solution makes sense and would probably fix it.

[AndreMiras]

I've opened a pull request, give it a try and let us know if it fixes the issue
#2037
You can probably directlyp pip install https://github.com/AndreMiras/buildozer/archive/refs/heads/fix/issue-1976-ios-title-package-name.zip to test it. Or patch manually the code changes on your site-packages.

[dogancankalinci]

Unfortunately I don't currently have access to an iPhone device to verify the fix. I originally reported the issue after testing on a relative's device some time ago.

The implementation looks correct to me though, and the proposed plist changes match the expected behavior, so I think it's probably safe to merge even without my confirmation.