Comments 9
Справедливости ради, пользователи не ищут ваше приложение по имени пакета, они будут искать его по названию. Ну либо перейдут по ссылке или отсканируют QR код. Если так хочется, чтобы юзер перепечатывал, можно дать ссылку на свой сайт, а там уже редирект/ссылка на магазин приложений (вы скорее всего захотите одну ссылку на все платформы, если будете печатать её на визитке, так что вам всё равно придётся делать промежуточную страницу с ручным или автоматическим выбором платформы).
Поэтому id пакета не обязан быть слишком красивым или одинаковым на всех платформах, часто он вообще формируется по имени разработчика (типа com.my_cool_gamedev_studio.my_game), а имя проекта лишь в конце.
Единственным исключением будут пакеты для Linux, так как там юзеру это реально придётся набирать, ибо это команда.
Это пока вы не разрабатываете для глобального охвата платформ, не учитываете дизайн-вид визиток для нового бизнеса, получения патентов, где прийдется внести все эти виды идентификаторов и т д. По итогу сами запутаетесь. Пользователи не ищут по имени пакета, это верно, головная боль не у них, а у тех кто создает и заботится о своем имени продукта и автор это очень четко указал.
Я же говорю, на визитке будет ссылка на ваш сайт (домен которого, действительно, лучше выбрать красивый), а уже на его странице либо набор кнопок со значками платформ, либо авторедирект по user agent в нужный магазин. Юзер (не) увидит имя пакета лишь мельком в строке адреса во время переадресации. Вы не захотите массово распрострвнять прямые ссылки на магазины, потому что у пользователей разные устройства и ссылка на AppStore бесполезна пользователю Android. Вы захотите одну ссылку, которая подходит всем (а ещё с возможностью воткнуть свою аналитику переходов).
Соответственно, вам нужен красивый домен, вам нужно хорошее имя приложения. А имена пакетов это техническая информация, лишь бы хоть какие-то были и вы их куда-то записали, чтобы копипастить везде где просят. Они недалеко ушли от хешей.
Справедливости ради, пользователи не ищут ваше приложение по имени пакета
Господин, вы считаете что иметь единый идентификатор для всего зоопарка платформ - это не справедливо и неудобно для пользователя? Если будет единый идентификатор - это рай для всех. Да, пользователю обычно всё равно (но я бы хотел только по ид=названию найти приложение во всех сторах), но единообразие идентификаторов важно не только для поиска, но и для управления продуктом. Эти строки живут в ссылках стора, интеграциях и документах, и со временем превращаются в “паспорт” приложения:
юридические/комплаенс-документы, договоры, реестры и просто корпоративная отчётность, где удобнее иметь один канонический идентификатор продукта, а не зоопарк строк.
в ссылке Google Play реально светится package name через параметр id=..., и в B2B-переписке/презентациях это часто видно.
Android App Links требуют assetlinks.json и там завязка на пакет/подпись, поэтому согласованность домена и ID снижает шанс ошибок, а на iOS в apple-app-site-association ключ appID строится как TeamID + bundleID. И да, в CI/CD (тот же fastlane) вы постоянно оперируете bundle identifier как общей переменной проекта, так что единообразие реально экономит время.
CI/CD: В скриптах сборки (Fastlane, GitHub Actions) вы оперируете одной переменной APP_ID, а не пишете «лапшу» из условий if ios then ... else ....
Группировка статистики и логика валидации клиентов на сервере упрощается в разы, когда у вас один ключ продукта, а не таблица маппинга разных ID.
И еще полно случаев, где это удобно.
В итоге: даже юзеру не всё равно, от удобного юзер не откажется, но разработчику и бизнесу единый ID экономит часы на настройку, деньги на юристов и нервы на поддержку легаси.
последовательность из двух дефисов на 3-й и 4-й позициях (xn--) зарезервирована для кодирования международных доменов (IDN) через алгоритм Punycode
В качестве признака Punycode зарезервирована не последовательность из двух дефисов в 3й и 4й позициях а вся комбинация xn-- . Если вместо xn используются какие-то другие символы то дефисы в 3й и 4й позициях это просто дефисы. Примеры:
И наконец f---edcompany . com - праобраз известного итальянского сайта . Его уже давно нет с нами, но можно посмотреть архив .
Самое ироничное, что вся эта боль не из-за «кривых разработчиков», а из-за исторического бага экосистем.
Android тащит за собой Java, Apple — сертификаты и reverse DNS, Linux — CLI-культуру.
Даже PWA, которые вроде бы обещают «одну точку входа», в итоге просто переносят эту сложность на уровень браузера и окружения, а не убирают её.
И никакой Flutter/React Native это принципиально не лечит — только маскирует.
На тему локальных доменов есть боль в понимании что так оказывается можно было. Я когда-то в 2016 делал стартап и назвал сайт «фирмы.онлайн». Ну круто же выглядит. И валидное имя домена - браузеры как надо всё открывали. Только почта не со всех почтовиков ходила. И люди переспрашивали нужно добавить в конце .com или .ru? И удивлялись что без точки. И что по-русски. И что вообще так можно было. И не заходили на сайт потому что не понимали что это домен. И как ссылка это не парсилось в тексте. И оно умерло. Не только по причине домена конечно, но некоторые идеи, выходящие за привычное понимание, имеют большие проблемы в продвижении. И это был 2016 год. Впрочем, с тех пор сайтов с доменами даже в .рф не так и много, а .онлайн это вообще нонсенс.
печально, что всё не единообразно, но это и плюс, что и искусство начать разбираться во многом
Идентификатор пакета. Боль кроссплатформы