А теперь представьте, что у нас не аккаунт, где полторы фотки, а работающий через Instagram интернет-магазин с наработанной клиентской базой. Или аккаунт с парой миллионов подписчиков, в который вложено много сил и денег. Но даже в не таких экстремальных случаях вы теряете свой контент. Если фотографии у вас могут быть сохранены локально, то комментарии и лайки (под лайками я понимаю ссылки на людей, которые залайкали) никто вам не вернёт.
Ну и да, если бы меня звали Иван, и у меня был бы аккаунт ivan, я бы очень расстроился, если бы пришлось с ним расстаться. А то, что это происходит так нагло, это не расстраивает, это просто возмутительно.
First World Problems, да. А по поводу чего переживаете вы? Голодающие дети Африки?
Ну, кому более чем достаточно, а кому, к примеру, module stability только в 5.1 завезли. А в 4.1 даже ABI stability не было, её завезли в 5.0. Вполне может быть, что каких-то фич, которые кому-то нужны, сейчас нет.
Для обеспечения высокой производительности Swift-приложения компилируются в машинный код, который выполняется в тестах Apple на 30% быстрее кода на Objective-C. Так, вместо сборщика мусора в Swift используются средства подсчета ссылок на объекты.
Читается так, будто в Objective-C используется сборщик мусора. Не используется. Точнее, он был в целой одной версии OS X много лет назад.
Сразу говорю, что не разбираюсь, поэтому вопросы – не критика, а скорее попытка прояснить для себя моменты, которые, возможно, у разбирающихся людей вопросов не вызывают:
1. А была ли там проблема с перегревом, чтобы её решать? Я имею в виду, что, возможно, инженеры NVidia посчитали, что 104 градуса для этих чипов – приемлемая рабочая температура, и мощность теплоотвода радиаторов лучше задействовать для охлаждения других компонентов?
2. Вытекающий из первого вопрос: если раньше радиатор охлаждал компонент А, а теперь охлаждает А и частично Б, то охлаждение компонента А должно было ухудшиться. Как эта доработка сказалась на температуре самого чипа GPU и, соответственно, на производительности?
Не говорю, что такого не было. Например, тот же UDID получать запретили. Просто это происходит настолько редко, что я даже сходу не вспомнил. А что за API с Касперским? История прошла мимо меня.
Тот же `UIAlertView` как работал, так и работает, хотя его объявили deprecated ещё в iOS 8.
Ну, как правило, у вас уже есть код, написанный под старую версию, который работает, значит, вам нужно написать код под новую версию. А если вам всё равно его писать, то можно просто обернуть его в условие проверки версии, почему бы и нет? :) Дополнительных усилий по поддержке это почти не требует (старый код уже отлажен), а пользователи будут довольны :) Конечно, будут куски, где части кода «дублируются», но я не сталкивался с ситуациями, когда это больше нескольких десятков строк на весь проект. Плюс, их очень легко потом убрать, когда вы решите отключить поддержку старой версии, потому что они явно помечены.
Как правило, просто в новой версии есть более оптимальный способ сделать что-то, благодаря новым API. Но если старый код работает, нет большого смысла в немедленном переписывании – вы только потеряете пользователей старых устройств. Ну и без этого можно жить.
Конечно, бывают ситуации, когда старый API вдруг стал работать не так в новой версии, и нужны специальные обработчики, но это не так часто и, как правило, это всего какие-нибудь несколько строк, отличающихся от версии к версии. Нет нужды отключать поддержку ради этого.
Последняя ситуация, которую я могу придумать – старые API пропали в новой версии совсем. Тут может теоретически понадобиться много переписывать, но, честно, я сходу не припомню у Apple ни одного API, которое бы пропало. Обычно API объявляют deprecated, но оно так и остаётся в системе на годы. Наверное, что-то и убирали, но были годы, чтобы к этому подготовиться.
Я веду к тому, что, как правило, если вы не хотите немедленно переписать всё на новых API, поддержка старой версии стоит очень мало и в плане времени, и в плане сложности кода.
Нет. Большинство компаний поддерживает несколько версий iOS. Допустим, конкретно мы увеличиваем deployment target, только если в более новой версии есть что-то, что нам действительно нужно. Разумеется, меньшая фрагментация действительно позволяет покрыть 90+% пользователей поддержкой только пары версий iOS, что многие делают. А некоторым нужны самые последние фишки, и без них приложение не будет работать. Но в целом ничто не заставляет вас отключать поддержку старых версий.
Xcode 12 (который вчера вышел) позволяет собирать приложения для iOS начиная с iOS 9.
Тут две проблемы. Первая – не совсем проблема Apple: многие разработчики привыкли тестировать на GM, потому что от GM до релиза всегда было время. Их можно понять, но лучше бы они начинали тестировать пораньше, на то беты и выкладывают.
Но даже если вы – ответственный и дальновидный разработчик, который заранее заготовил обновление под новую версию iOS, проблема в том, что его можно опубликовать только с новой версией Xcode. И бета-версии запрещены. Обычно можно опубликовать обновление с GM-версии, что даёт разработчикам (и Apple) неделю на то, чтобы пройти ревью до выхода новой версии iOS. Таким образом, из-за действий Apple, все разработчики вынуждены опубликовать свои обновления за 1 день. А ведь ревью! Для всех разом! Сколько оно займёт? То есть, если у вас есть ломающий приложение баг в iOS 14, который можно исправить только средствами iOS 14 (новый API, к примеру), То ваши пользователи минимум пару-тройку дней не смогут пользоваться вашим приложением, и вы ничего не можете со своей стороны с этим сделать.
Но и это ещё не всё! Обычно можно публиковать обновления приложений с помощью GM-версии Xcode. Но в этот раз несколько разработчиков, как минимум, столкнулись с тем, что нельзя. Ждите релиза. А GM версию вначале выложили с одним номером билда, потом с другим, но тем же контентом, а потом с другим номером билда и другим контентом. И всё это за сутки.
Я всё это прекрасно понимаю, я с этим работаю каждый день) Это очень стрёмно, да. Но это риск, на который идёшь, когда пишешь под закрытую платформу. Но закрытые платформы должны быть. Я, как пользователь, хочу, чтобы они были. Да и как разработчику мне в 99% случаев удобнее работать с закрытой экосистемой без зоопарка магазинов.
Ой, так это снова ко мне, я iOS-разработчик)) У текущего положения вещей есть свои минусы. Если разработчиков эти минусы не устраивают, они могут разрабатывать приложения только под Android (что многие и делают). Тогда хорошие приложения будут только под Android, и туда потянутся пользватели, ведь iOS не будет предоставлять сравнимой функциональности.
Либо разработчики могут опротестовать status quo, но проблема в том, что ваша свобода заканчивается там, где начинается свобода другого человека. Не отбирайте у меня мои закрытые экосистемы, пожалуйста. И как у пользователя, и как у разработчика тоже.
Ну и да, если бы меня звали Иван, и у меня был бы аккаунт ivan, я бы очень расстроился, если бы пришлось с ним расстаться. А то, что это происходит так нагло, это не расстраивает, это просто возмутительно.
First World Problems, да. А по поводу чего переживаете вы? Голодающие дети Африки?
Ну, кому более чем достаточно, а кому, к примеру, module stability только в 5.1 завезли. А в 4.1 даже ABI stability не было, её завезли в 5.0. Вполне может быть, что каких-то фич, которые кому-то нужны, сейчас нет.
Читается так, будто в Objective-C используется сборщик мусора. Не используется. Точнее, он был в целой одной версии OS X много лет назад.
1. А была ли там проблема с перегревом, чтобы её решать? Я имею в виду, что, возможно, инженеры NVidia посчитали, что 104 градуса для этих чипов – приемлемая рабочая температура, и мощность теплоотвода радиаторов лучше задействовать для охлаждения других компонентов?
2. Вытекающий из первого вопрос: если раньше радиатор охлаждал компонент А, а теперь охлаждает А и частично Б, то охлаждение компонента А должно было ухудшиться. Как эта доработка сказалась на температуре самого чипа GPU и, соответственно, на производительности?
Тот же `UIAlertView` как работал, так и работает, хотя его объявили deprecated ещё в iOS 8.
Как правило, просто в новой версии есть более оптимальный способ сделать что-то, благодаря новым API. Но если старый код работает, нет большого смысла в немедленном переписывании – вы только потеряете пользователей старых устройств. Ну и без этого можно жить.
Конечно, бывают ситуации, когда старый API вдруг стал работать не так в новой версии, и нужны специальные обработчики, но это не так часто и, как правило, это всего какие-нибудь несколько строк, отличающихся от версии к версии. Нет нужды отключать поддержку ради этого.
Последняя ситуация, которую я могу придумать – старые API пропали в новой версии совсем. Тут может теоретически понадобиться много переписывать, но, честно, я сходу не припомню у Apple ни одного API, которое бы пропало. Обычно API объявляют deprecated, но оно так и остаётся в системе на годы. Наверное, что-то и убирали, но были годы, чтобы к этому подготовиться.
Я веду к тому, что, как правило, если вы не хотите немедленно переписать всё на новых API, поддержка старой версии стоит очень мало и в плане времени, и в плане сложности кода.
Нет. Большинство компаний поддерживает несколько версий iOS. Допустим, конкретно мы увеличиваем deployment target, только если в более новой версии есть что-то, что нам действительно нужно. Разумеется, меньшая фрагментация действительно позволяет покрыть 90+% пользователей поддержкой только пары версий iOS, что многие делают. А некоторым нужны самые последние фишки, и без них приложение не будет работать. Но в целом ничто не заставляет вас отключать поддержку старых версий.
Xcode 12 (который вчера вышел) позволяет собирать приложения для iOS начиная с iOS 9.
Тут две проблемы. Первая – не совсем проблема Apple: многие разработчики привыкли тестировать на GM, потому что от GM до релиза всегда было время. Их можно понять, но лучше бы они начинали тестировать пораньше, на то беты и выкладывают.
Но даже если вы – ответственный и дальновидный разработчик, который заранее заготовил обновление под новую версию iOS, проблема в том, что его можно опубликовать только с новой версией Xcode. И бета-версии запрещены. Обычно можно опубликовать обновление с GM-версии, что даёт разработчикам (и Apple) неделю на то, чтобы пройти ревью до выхода новой версии iOS. Таким образом, из-за действий Apple, все разработчики вынуждены опубликовать свои обновления за 1 день. А ведь ревью! Для всех разом! Сколько оно займёт? То есть, если у вас есть ломающий приложение баг в iOS 14, который можно исправить только средствами iOS 14 (новый API, к примеру), То ваши пользователи минимум пару-тройку дней не смогут пользоваться вашим приложением, и вы ничего не можете со своей стороны с этим сделать.
Но и это ещё не всё! Обычно можно публиковать обновления приложений с помощью GM-версии Xcode. Но в этот раз несколько разработчиков, как минимум, столкнулись с тем, что нельзя. Ждите релиза. А GM версию вначале выложили с одним номером билда, потом с другим, но тем же контентом, а потом с другим номером билда и другим контентом. И всё это за сутки.
Либо разработчики могут опротестовать status quo, но проблема в том, что ваша свобода заканчивается там, где начинается свобода другого человека. Не отбирайте у меня мои закрытые экосистемы, пожалуйста. И как у пользователя, и как у разработчика тоже.