Universal Link открывает неправильный идентификатор пакета

Фон:

  • наше приложение использует разные идентификаторы пакетов для сборок разработки, бета-версий и производственных сборок (App Store).
  • В настоящее время я внедряю универсальные ссылки в наши разработки.
  • Наша производственная сборка, которая в настоящее время находится в App Store, не поддерживает универсальные ссылки.

Я столкнулся с этой сумасшедшей проблемой, когда мои универсальные ссылки не только не открывают разрабатываемую версию приложения, но вместо этого запускают рабочую версию, несмотря на то, что рабочая версия не имеет надлежащих прав.

Мой файл apple-app-site-association был проверен с использованием обоих https://branch.io/resources/universal-links/ и https://search.developer.apple.com/appsearch-validation-tool/ и выглядит так:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "DY74R9XXXX.com.myapp.consumer.debug",
        "paths": [ "/profiles/*", "/messages/*"]
      },
      {
        "appID": "DY74R9XXXX.com.myapp.consumer",
        "paths": [ "/profiles/*", "/messages/*"]
      }
    ]
  }
}

Согласно https://developer.apple.com/library/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html массив details должен оцениваться по порядку и останавливаться после нахождения совпадения.

Порядок словарей в массиве определяет порядок, которому следует система при поиске соответствия, поэтому вы можете указать приложение для обработки определенной части вашего веб-сайта.

Цель состоит в том, чтобы одна и та же универсальная ссылка загружалась в разрабатываемой версии для всех членов моей команды и в рабочей версии для конечных пользователей, у которых нет пакета .debug на их телефонах.

Это не только не работает, но, как уже упоминалось, универсальные ссылки всегда загружают рабочую версию, даже если в рабочей версии отсутствует право applinks:dev.myserver.com, указывающее на мой файл apple-app-site-association. Это кажется безумием, но это будет означать, что я могу запускать произвольные пакеты, которые я не публиковал, и что файл прав не применяется.

Кроме того, если я удалю вторую запись из массива details и оставлю словарь только для отладочной версии, универсальные ссылки перестанут работать и вместо этого откроют Safari. Переключение порядка массива также не имеет никакого эффекта. Я сталкивался с таким поведением на iPhone 6s как на 9.3, так и на 9.3.1. Любые советы по этим двум проблемам (запуск неправильного пакета и отказ от запуска пакета отладки, когда это единственная запись) очень ценятся!


ios ios9 deep-linking ios-universal-links
person emkman    schedule 19.04.2016    source источник
comment
Как это ни странно, похоже, что iOS каким-то образом объединяет права между DY74R9XXXX.com.myapp.consumer.debug и DY74R9XXXX.com.myapp.consumer, возможно, потому, что они очень похожи. Это точно нигде не задокументировано. Не могли бы вы попробовать изменить идентификатор пакета для отладочной сборки на что-то однозначно другое?   -  person Alex Bauer    schedule 19.04.2016
comment
@AlexBauer, кажется, вы правы в том, что права путаются из-за сходства, но это не объясняет, почему это не работает только с одной записью сведений. Однако, основываясь на вашем предложении, я изменил идентификатор пакета на com.myapp.dev, и это сработало. Затем я изменил его на com.myapp.dev.dev, и это тоже сработало (меня беспокоила ошибка с идентификаторами 4 уровней по сравнению с типичными 3). Любые предложения по следующим шагам?   -  person emkman    schedule 19.04.2016
comment
Файл apple-app-site-association извлекается только при установке приложения. Предполагая, что это на самом деле проблема с кэшированием, я думаю, вам придется каждый раз удалять обе сборки приложения, чтобы получить чистый тест. Если бы вы только удаляли и переустанавливали один из них, я мог бы видеть, как это вызвало бы эти затянувшиеся проблемы.   -  person Alex Bauer    schedule 19.04.2016
comment
@AlexBauer Я нашел точную причину, и это не кэширование. Смотрите мой обновленный ответ ниже. Спасибо за вашу помощь!   -  person emkman    schedule 19.04.2016
comment
Это потрясающе. Спасибо за обновление!   -  person Alex Bauer    schedule 20.04.2016

Ответы (2)


arrow_upward
2
arrow_downward

Это не проблема кэширования – обновленное решение ниже

Оригинальный ответ:

После изменения моего идентификатора пакета на что-то другое на третьем уровне, по предложению Алекса Бауэра, я смог заставить ссылки работать. Затем я изменил свой идентификатор пакета обратно на com.myapp.consumer.debug, и они продолжили работать. Так что, возможно, это была странная ошибка, связанная с кэшированием службы swcd. Однако, если я перемещу запись DY74R9XXXX.com.myapp.consumer на первое место в массиве, она продолжит запускать потребительскую версию, даже если ей не хватает прав. Это похоже на потенциально отдельную или дополнительную ошибку, связанную с идентификаторами пакетов четырех уровней и неправильным сопоставлением.

Обновленное/правильное решение

Изменение идентификатора пакета, а затем его обратное изменение фактически устранило проблему, поскольку это изменило мои файлы Info.plist и project.pbxproj. Когда я посмотрел diff, истинная проблема стала очевидной. Ранее мы устанавливали идентификатор пакета с помощью этого значения в Info.plist:

<key>CFBundleIdentifier</key>
<string>$(PRODUCT_BUNDLE_IDENTIFIER)${BUNDLE_ID_SUFFIX}</string>

со статическим PRODUCT_BUNDLE_IDENTIFIER в нашем project.pbxproj. Это было основано на ранее опубликованных общих практиках для нескольких сборок env. Однако в XCode 7 Apple настоятельно рекомендует обновить настройки, чтобы Info.plist всегда содержало:

<key>CFBundleIdentifier</key>
<string>$(PRODUCT_BUNDLE_IDENTIFIER)</string>

Это никогда не было проблемой, прежде чем создавать и отправлять в iTunes с правильным именем пакета. Однако теперь ясно, что для некоторых функций требуется именно эта настройка, как указано здесь: -with-xcode-7">Использовать идентификатор пакета вместо идентификатора пакета продукта с Xcode 7

Я установил идентификатор пакета продукта для каждого типа сборки через XCode, как показано здесь и теперь все работает как положено.

TL;DR – универсальные ссылки нацелены на ваш PRODUCT_BUNDLE_IDENTIFIER, не на ваш CFBundleIdentifier. Если ваш PRODUCT_BUNDLE_IDENTIFIER не соответствует окончательному идентификатору пакета вашего пакета, универсальные ссылки не будут работать правильно.

person emkman    schedule 19.04.2016
comment
Спасибо за выделение проблемы. Я пытаюсь исправить это путем изменения в PRODUCT_BUNDLE_IDENTIFIER, но выдает ошибку: Для параметра appIdName было предоставлено недопустимое значение «XC $CB_APP_ID». Профиль подготовки Профиль подготовки группы iOS: * не поддерживает функцию связанных доменов. Профиль подготовки Профиль подготовки группы iOS: * не включает право com.apple.developer.associated-domains. Подписание кода требуется для типа продукта «Приложение» в SDK «iOS 10.0» Не могли бы вы проверить? - person CoDe; 10.01.2017

arrow_upward
1
arrow_downward

Другое решение, если вы работаете с несколькими целевыми и несколькими проектами Firebase.

  1. Создайте файл прав для целевого и
  2. Создайте другую ссылку на Deep в консоли Firbase.
  3. Используйте App_code из консоли Firebase для обновления файла прав -> Имя связанного_домена.

Вот и все. Создайте форму ссылки, используя другой app_code. Это запустит уважаемое приложение.

person CoDe    schedule 10.01.2017