Проверять следование гайдам платформы не на последнем этапе перед добавлением в стор, а в течении всего процесса разработки с помощью регулярно обновляемых платформой и вендорами, а вторами библиотек ML линтеров в IDE.
И эти линтеры не просто будут ругать и даже не только рассказывать как надо но и предлагать заранее какие-то стандартные приемы по сложным партернам в коде
Те разработчики, кто не будут этому следовать, а следовать будет не намного сложнее чем сейчас писать тесты, просто будут фуу, словно git не используют по сегодняшним меркам.
Гайды платформы должны проникнуть глубоко в процесс Быть гибкими и впитывать новые веения в дизайне (новые хорошие идеи ui/ux паттернов и элементов должны в Гайдах/SDK’ях появляться быстро).
Эплу не удалось: и проверяют не строго и при этом большинство идут не через app store (Alex: я из апстора ничего кроме эпловских софтин не юзаю)
Разрешение на потенциально annoyed Паттерны
Детекция скрытых паттернов и замена на стандартные подходы
Замена велосипедов на стандартные библиотеки
Автоматический ML based контроль QA & UX. См так же Data driven QA
Обнаружение неправильного или не полного использования паттернов, библиотечных интерфейсов.
Например, проверяем navigator.onLine, но не подписываемся на изменения (результат: беджик offline покажем, а при появлении сети не попытаемся повторить Load-запрос)
GitHub CodeQL: разработчики библиотек могут писать линтеры для поиска нежелательных паттернов в коде. Это больше направлено на безопасность но вполне может быть использована и для других целей
Пытатаются разные тонкие высокоуровневые паттерны энфорсить. Но пока тупенько
В Радио-Т 707 Бобук как раз говорит что можно было бы и сразу исправлять