Насколько я помню то где-то в 2018 уже прилично форков с поддержкой iOS было, просто не всем надо было (например нам) до удаленной работы. Насколько я помню 2GIS об этом где-то в 2018 рассказывал :)
Вы сравнивали с https://github.com/zebrunner/stf ? Это DeviceFarmer (бывший openSTF), подпиленный под iOS. DeviceFarmer все никак в upstream не вольют поддержку iOS (есть и другие форки разной степени сырости). У нас уже год крутится с некоторыми модификациями без проблем, надо будет ваше решение тоже попробовать :)
В целом AmazonDeviceFarm, headspin.io и многие другие фермы для удаленного доступа к девайсам основаны на openSTF допиленном (libpcap патчат и андроидоский хардкод меняют на iOS специфичные штуки), но свои плюшки обратно не контрибьютят :(
Если не хочется платить за clean my mac или автоматизировать скриптами (у нас на билд-нодах стоит чистка там где не надо incremental билды), то есть неплохая GUI утилитка github.com/waylybaye/XcodeCleaner
Для удаления неподдерживаемых симуляторов можно использовать xcrun simctl delete unavailbale вместо способа, описанного в статье. Мне помогло освободить в районе 10Гб — старые симуляторы под iOS 7/8 и Watch OS1
Также кейсы, описанные выше подходят для сетей где надо авторизоваться в браузере/веб-вью перед тем как пустят в Интернет
— кейс про 404 я описал — наверное не очень понятно просто обрисовал
— про 200 + JS не слышал — сейчас добавлю, спасибо!
Григорий, спасибо :)
1. Билды собираются в TeamCity. У каждой из команд если свое приложение, которое позволяет ставить нужный билд. Команду релиз-инжиниринга это расстроило, они написали HTML5 приложение, теперь у нас их 4 :)
У Win Phone/Android с этим вообще никаких трудностей нет. Для iOS мы распространяем Enterprise билды, чтобы любой человек из компании мог их поставить без добавления девайса в provision-profile. Но они не поддерживают пуши, поэтому если необходимо протестировать пуш-нотификации, приходится ставить руками на активированные для разработки устройства.
2. Логи, да именно так и есть — мы логи можем слать на e-mail на Android/WinPhone причем если послать на определенный мейл с указанием тикета, то лог автоматически прикрепится. Если такого тикета нет — он создастся пустой. Удобно если где-то в поездке закрашилось приложение :)
3. Мы такое не реализовывали если честно, подам идею разработчикам. В большинстве случаев от саппорта приходят уже отфильтрованные жалобы в которых более-менее понятно что и как. Так же у нас есть beta для iOS и Android, билды которого обернуты в TestFairy, мы там видео сессии прокликиваем время от времени, если пришел краш или жалоба от бета-пользователя
1. Новая фича или рефакторинг старой «прячется» под фича флаг и мы через определенный интерфейс контролируем ее состояние. Иначе говоря мы ее можем «раскатывать» постепенно:
— на определенное приложение (у нас их несколько);
— на определенный процент пользователей или на по определенным правилам (например на 10% пользователей или на отдельную страну).
Или же совсем отключить новый функционал по решению команд тестирования, разработки, продуктовой команды. После того как фичу обкатали мы можем сказать клиенту «не спрашивай ее больше с сервера и закэшируй состояние» или же выключить фича флаг на клиенте к следующему релизу (и убрать старый код если мы переписывали определенный функционал).
2. С другой стороны, мы сообщаем серверу какие фичи клиент поддерживает и сервер контролирует доступны ли она клиенту.
Например, в определенных странах мы не поддерживаем платежи или платные функции не должны быть доступны несовершеннолетним. Сервер говорит такому клиенту «ты поддерживаешь фичу, но не включай ее» и для такого клиента не будут доступны платежи.
Как только платежи стали доступны (договорились о платежах или юзер стал совершеннолетним) сервер даже в этой сессии может прислать модифицированное состояние фичи и она станет доступна пользователям.
3. А также мы можем быть подстрахованы со стороны фреймворка A/B-тестирования. Если мы уже приняли решение какая группа лидирует или что-то не так с мобильным приложением, мы можем завершить тест досрочно или перевести всех пользователей в другую группу.
1. Речь шла о платформе iOS. Проблемы уже нет, либо уже пофикшена была либо с переходом на FB Graph API — фейсбук сам прогресс показывает. Собственно говоря, поэтому и написал что «пару версий назад», перед публикацией проверял — проблемы нет (последний раз видел проблему когда еще первый API использовался и был разрешен автопостинг).
2. У нас проблема не только со Swype, но и как минимум со SwiftKey — y нас в модальном окне авторизации через OAuth при его закрытии если долго отвечает сервис или медленное интернет соединении (Twitter, Instagram). Судя по нашим краш-репортам в iOS9.1 проблемы уже нет (как минимум в нашем приложении)
Они до сих пор не пофисили чудный баг с потерей crash-репортов на iOS. Теперь баг воспроизводится не со 100% вероятностью, но всё же.
— запускаем аппу
— включаем режим полета (или network link conditioner в very bad network)
— крашим приложение
— перезапускаем приложение без доступа к инету (или не выключаем NLC)
AR: краш репорт утерян примерно с 50% вероятностью (пару версий назад было 100%)
Дык, известная же проблема — на 4pda обсасывалась чуть ли не год назад. Насколько я знаю — апдейт до 4.3 либо решает проблему, либо отодвигает на дальний срок. У обоих родителей GS3 уже почти 2 года, вроде живые :)
в Charles тоже есть, не так удобно подмена сделана, но ненамного. Если что-то хитрое подменять надо, всегда программисты помогают :) У меня Fiddler вроде не падал особо, но не скажу что я прям активно им пользовался
Здравствуйте!
Дайте, пожалуйста, чуть больше деталей по возникшей проблеме в ПМ, и мы обязательно с ней разберемся:
— регистрация по e-mail или через FB (если возможно и e-mail в ПМ)
— другие детали, которые Вы вспомните
Насколько я помню то где-то в 2018 уже прилично форков с поддержкой iOS было, просто не всем надо было (например нам) до удаленной работы. Насколько я помню 2GIS об этом где-то в 2018 рассказывал :)
Вы сравнивали с https://github.com/zebrunner/stf ? Это DeviceFarmer (бывший openSTF), подпиленный под iOS. DeviceFarmer все никак в upstream не вольют поддержку iOS (есть и другие форки разной степени сырости). У нас уже год крутится с некоторыми модификациями без проблем, надо будет ваше решение тоже попробовать :)
В целом AmazonDeviceFarm, headspin.io и многие другие фермы для удаленного доступа к девайсам основаны на openSTF допиленном (libpcap патчат и андроидоский хардкод меняют на iOS специфичные штуки), но свои плюшки обратно не контрибьютят :(
https://heisenbug-piter.ru/talks/2018/spb/6feubdtqqwqocya2w4cwq2/ Тут есть инструмены, которые Вам могут помочь. Видео пока не в общем доступе (есть только слайды), но должны быть доступные где-то в ноябре судя по предыщему опыту
Для удаления неподдерживаемых симуляторов можно использовать xcrun simctl delete unavailbale вместо способа, описанного в статье. Мне помогло освободить в районе 10Гб — старые симуляторы под iOS 7/8 и Watch OS1
— кейс про 404 я описал — наверное не очень понятно просто обрисовал
— про 200 + JS не слышал — сейчас добавлю, спасибо!
1. Билды собираются в TeamCity. У каждой из команд если свое приложение, которое позволяет ставить нужный билд. Команду релиз-инжиниринга это расстроило, они написали HTML5 приложение, теперь у нас их 4 :)
У Win Phone/Android с этим вообще никаких трудностей нет. Для iOS мы распространяем Enterprise билды, чтобы любой человек из компании мог их поставить без добавления девайса в provision-profile. Но они не поддерживают пуши, поэтому если необходимо протестировать пуш-нотификации, приходится ставить руками на активированные для разработки устройства.
2. Логи, да именно так и есть — мы логи можем слать на e-mail на Android/WinPhone причем если послать на определенный мейл с указанием тикета, то лог автоматически прикрепится. Если такого тикета нет — он создастся пустой. Удобно если где-то в поездке закрашилось приложение :)
3. Мы такое не реализовывали если честно, подам идею разработчикам. В большинстве случаев от саппорта приходят уже отфильтрованные жалобы в которых более-менее понятно что и как. Так же у нас есть beta для iOS и Android, билды которого обернуты в TestFairy, мы там видео сессии прокликиваем время от времени, если пришел краш или жалоба от бета-пользователя
1. Новая фича или рефакторинг старой «прячется» под фича флаг и мы через определенный интерфейс контролируем ее состояние. Иначе говоря мы ее можем «раскатывать» постепенно:
— на определенное приложение (у нас их несколько);
— на определенный процент пользователей или на по определенным правилам (например на 10% пользователей или на отдельную страну).
Или же совсем отключить новый функционал по решению команд тестирования, разработки, продуктовой команды. После того как фичу обкатали мы можем сказать клиенту «не спрашивай ее больше с сервера и закэшируй состояние» или же выключить фича флаг на клиенте к следующему релизу (и убрать старый код если мы переписывали определенный функционал).
2. С другой стороны, мы сообщаем серверу какие фичи клиент поддерживает и сервер контролирует доступны ли она клиенту.
Например, в определенных странах мы не поддерживаем платежи или платные функции не должны быть доступны несовершеннолетним. Сервер говорит такому клиенту «ты поддерживаешь фичу, но не включай ее» и для такого клиента не будут доступны платежи.
Как только платежи стали доступны (договорились о платежах или юзер стал совершеннолетним) сервер даже в этой сессии может прислать модифицированное состояние фичи и она станет доступна пользователям.
3. А также мы можем быть подстрахованы со стороны фреймворка A/B-тестирования. Если мы уже приняли решение какая группа лидирует или что-то не так с мобильным приложением, мы можем завершить тест досрочно или перевести всех пользователей в другую группу.
2. У нас проблема не только со Swype, но и как минимум со SwiftKey — y нас в модальном окне авторизации через OAuth при его закрытии если долго отвечает сервис или медленное интернет соединении (Twitter, Instagram). Судя по нашим краш-репортам в iOS9.1 проблемы уже нет (как минимум в нашем приложении)
— запускаем аппу
— включаем режим полета (или network link conditioner в very bad network)
— крашим приложение
— перезапускаем приложение без доступа к инету (или не выключаем NLC)
AR: краш репорт утерян примерно с 50% вероятностью (пару версий назад было 100%)
Дайте, пожалуйста, чуть больше деталей по возникшей проблеме в ПМ, и мы обязательно с ней разберемся:
— регистрация по e-mail или через FB (если возможно и e-mail в ПМ)
— другие детали, которые Вы вспомните
Чем отличается флоу для iOS и используете ли обезьянку AntEater для iOS?