A explicação mais simples pode ser uma das duas coisas:
. -
Recursos limitados simples - Tempo finito para QA e teste. Isso é sempre algo para considerar - para cada dispositivo que executa código, você precisa fornecer dispositivos para os codificadores, teste durante o desenvolvimento, teste durante o QA, suporte ao longo do período de 2 a 3 anos que o sistema operacional estará sob o suporte principal, etc. . Basicamente, as características tecnicamente viáveis ficam espalhadas pelo piso da sala de corte o tempo todo devido ao fato de que os recursos não são infinitos, existem cronogramas, e os orçamentos existem.
-
A Apple da estrutura usa para implementar isso simplesmente não suporta ou não foi escrita para o hardware mais antigo. Sim - Você pode escrever código no Basic 1 + 1 = 2 por apenas qualquer chipset ou framework. Meu palpite é o turno nocturno é escrito em metal ou uma API de nível inferior. A documentação da Apple explica o hardware necessário para apoiar o metal e o Opengles v 3.0:
- https://developer.apple.com/library/ios /documentation/deviceinformation/reference/iosdevicecompatibilidade/Openglesplatforms/openglesplatforms.html
Se você olhar para todos os dispositivos OpenGl2.0 e não-metálicos que agora não suportam Night-Shift Pode ser uma razão técnica convincente para não enviar esse recurso sem as capacidades de metal / 3.0 da API de gráficos e suporte de hardware para fazer o backup do que o código descreve.
Meu palpite é solidamente no acampamento de limitação de hardware + API, mas vale a pena afirmar que há um grande custo para todas as mudanças e todas as decisões no ecossistema do IOS neste ponto com a maioria dos 1 bilhão de usuários ativos de produtos da Apple são iOS usuários.