Тестирование Обновлений приложения для iOS
Этот technote обсуждает, как протестировать обновление к приложению для iOS, уже развернутому через App Store. Общая методика тестирования выходит за рамки этого документа. Для получения информации об оптимизации поставки обновления см. «Сокращающий Размер Загрузки для Обновлений приложения для iOS» и «Сокращения Размера моего Приложения».
Рекомендуемая процедура тестирования
Установите оперативное распределение заархивированной сборки обновления с помощью iTunes на устройстве, уже имеющем старую версию установленного приложения.
Процесс установки приложения XCode оптимизирован для разработки, но немного отличается, чем, как iTunes и App Store устанавливают приложения. Это хорошо во время разработки, потому что это быстрее, но использование XCode для установки приложения по более старой старой сборке может создать «frankenbuild» с устаревшими файлами в .app пакет, который не будет существовать после обновления App Store.
Когда приложение обновляется, старое .app пакет полностью заменяется, и все данные в старом контейнере приложения могут быть сохранены также.
Кроме того, выполнение с присоединенным отладчиком XCode замаскирует «сторожевые катастрофические отказы», которые могут произойти, если обновление берет слишком долго для запуска.
Создать Заархивированную сборку, которую можно и протестировать и представить:
1) В XCode выбирают «Archive» из меню «Product» для архивации сборки приложения. Можно найти архив на вкладке Archives в окне Organizer.
2) Упакуйте сборку как «Оперативное» .ipa файл путем выбора его в окне Organizer и нажатия «Distribute …»; тогда выберите «Save for Enterprise or Ad-Hoc Deployment». Выберите любые «Идентификационные данные Подписывания кода»: это позволит Вам установить на Вашем тестовом устройстве.
3) Тестовое обновление к той сборке путем открытия .ipa файл с iTunes и синхронизирующий для установки это на устройстве, имеющем предыдущую версию установленного приложения. Убедитесь, что Вы использовали предыдущую версию приложения достаточно, что это сохранило любые данные, которые это могло бы сохранить во время использования. Наиболее распространенные обновления задач имеют, должным образом не имеет дело с данными, создаваемыми предыдущей версией приложения.
Управление данными через обновления
Наиболее распространенной причиной ошибок после обновления является новая версия приложения, не обрабатывающего данные, создаваемые предыдущей версией приложения.
Когда приложение обновляется, очень последняя версия, доступная в App Store для целевого устройства, установлена. Промежуточные обновления не выполняются. Ваше приложение должно обработать данные, создаваемые любыми предыдущими версиями приложения.
Когда приложение обновляется, .app пакет полностью заменяется последней версией приложения. Кроме того, абсолютный путь к контейнеру приложения (»Application_Home«) и таким образом все файлы в нем, изменится. Поэтому необходимо только сохранить пути к файлам относительно контейнера приложения.
NSSearchPathForDirectoriesInDomains() или -[NSFileManager URLsForDirectory:inDomains:] будет всегда давать Вам допустимый путь к току <Application_Home> или стандартный подкаталог в нем.
Перечисление 1 метод, возвращающий URL току Application_Home/Documents каталог
- (NSURL *)applicationDocumentsDirectory { |
return [[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject]; |
} |
Когда приложение обновляется, любые данные в контейнере приложения могут быть сохранены. От практические точки зрения, это означает Ваши потребности приложения корректно обработать (или проигнорировать) старые кэши и временные файлы.
<Application_Home>/Documents/ и <Application_Home>/Library (исключая <Application_Home>/Library/Caches подкаталог), единственные каталоги, которые, как гарантируют, будут сохранены через обновления. Несмотря на то, что другой <Application_Home> подкаталоги могут быть отодвинуты, Вы не должны полагаться на это как на договор API.
Новые аппаратные средства
То, когда пользователь мигрирует на новое устройство впервые, скопировало данные от их более старого устройства, установлен на новом устройстве, вместе с последней версией любых приложений, установленных на старом устройстве. Этот сценарий совпадает с регулярным обновлением, за исключением двух соображений. Временные данные не будут абсолютно установлены, потому что они никогда не копировались. Кроме того, любые файлы, отмеченные как, «не копируют», не будет установлен.
Отладка оперативных сборок
Если проблема только воспроизведет в Оперативной сборке, то необходимо будет проанализировать вывод Crash Logs и Console от устройства для отладки ее. Отладка Развернутых приложений для iOS объясняет, как собрать эту информацию. Посмотрите Понимание и Анализирование Докладов Катастрофического отказа приложения для iOS и Отчетов Катастрофического отказа Понимания относительно iOS Сеанс WWDC для подсказок.
Следующие шаги
После тестирования заархивированной сборки к Вашей удовлетворенности можно представить его App Store путем выполнения этих шагов. Важно представить ту же самую сборку, которую Вы протестировали.
Для получения информации о проверке Вашего приложения и обновления являются достаточно маленькими, чтобы быть загруженным без соединения Wi-Fi, видеть «Сокращение Размера моего Приложения» и «Сокращения Размера Загрузки для Обновлений приложения для iOS».
История версии документа
| Дата | Примечания |
|---|---|
| 07.10.2014 | Добавленный больше подробных данных о процессе обновления и какие файлы сохраняются. |
| 14.05.2014 | Удаленный список чрезмерно специфичных возможных проблем. |
| 13.02.2013 | Редакционные изменения. |
| 27.10.2011 | Новый документ, обсуждающий некоторые методы наиболее успешной практики для тестирования обновления к приложению для iOS, уже развернутому через App Store. |