Обычной практикой может быть использование утверждений в коде для проверки входных параметров, целостности данных и т. Д. Во время разработки приложения.

Я тестирую свои приложения, НО, учитывая, что я не Кнут (ион пишет чеки на 1 доллар), и я не могу позволить себе нанять большую команду специалистов по обеспечению качества на полный рабочий день, как это делают некоторые компании, занимающиеся разработкой программного обеспечения для медицинских и космических систем. Я предполагаю, что во всех приложениях всегда будет множество ошибок, которых еще никогда не было замечено во время тестирование или QA. Предположим, что в противном случае кажется интеллектуально нечестным. Итак, после тестирования приложения (и, очевидно, устранения всех ошибок, вызвавших любые ранее обнаруженные сбои ASSERT) и подготовки приложения к отправке в Apple, что следует делать со всеми проверками ASSERT в сборке выпуска / распространения? Оставить или нет?

Вот одна из причин, по которой они могут быть оставлены: если приложение работает неправильно для некоторых пользователей, эти пользователи могут получить оценку «1 звезда», и никто не скажет разработчику, почему это достаточно подробно. Но если приложение аварийно завершает работу из-за сбоя ASSERT, оно все равно может получить оценку 1 звезда, но разработчик потенциально может получить некоторые аварийные дампы, косвенно через iTunes и iTunes Connect, если подключится достаточное количество пользователей, чтобы выяснить, что происходит не так. И если приложение будет отклонено Apple из-за нового сбоя ASSERT, это предотвратит попадание плохой версии приложения на устройства своих клиентов.