- Apple cierra automáticamente los bugs reportados a través de Feedback Assistant si el usuario no verifica personalmente que “todavía no se ha corregido”
- En un bug de filtración de privacidad relacionado con la extensión de filtro de red (FB12088655) que no había recibido respuesta durante 3 años, Apple de repente pidió confirmación y dijo que si no había respuesta en 2 semanas lo consideraría corregido
- Sin embargo, aunque los desarrolladores de Little Snitch confirmaron que el mismo problema seguía presente incluso en la versión más reciente de macOS, Apple cerró el reporte
- Este procedimiento funciona como una estructura que reduce artificialmente la cantidad de reportes de bugs, con el efecto de ocultar problemas reales de calidad
- Como resultado, se señala que la forma en que Apple gestiona los bugs debilita la confianza de los desarrolladores y perjudica una cultura de retroalimentación colaborativa
El problema del cierre automático de reportes de bugs en Apple
- Un desarrollador que reportó un bug mediante Apple Feedback Assistant criticó la práctica de Apple de cerrar reportes arbitrariamente sin confirmación del usuario
- Apple cierra automáticamente el reporte si el usuario no confirma personalmente que “el bug todavía no se ha corregido”
- Tras años sin responder, de pronto envía una solicitud de verificación y, si no hay respuesta en 2 semanas, lo da por “corregido”
- En el caso de FB12088655 “Privacy: Network filter extension TCP connection and IP address leak”, enviado en marzo de 2023, Apple no respondió durante 3 años y recién en marzo de 2026 pidió verificarlo en macOS 26.4 beta 4
- Como no tenía instalada permanentemente una beta del sistema operativo, era difícil comprobarlo, y aunque preguntó a Apple si realmente se había corregido, no obtuvo una respuesta clara
- Apple notificó que, “si no se verifica en 2 semanas, se considerará corregido y se cerrará el reporte”
- Los desarrolladores de Little Snitch informaron que el mismo problema seguía reproduciéndose en macOS 26.4 beta 4
- El mismo bug también seguía presente en la versión final de macOS 26.4
- Se señala que exigir verificación directa del usuario para bugs no corregidos es un procedimiento ineficiente e irracional
- Se menciona la posibilidad de que internamente esté operando una estructura de incentivos orientada a reducir la cantidad de reportes de bugs
- Esto hace que el número de “bugs abiertos” disminuya y que, en las métricas internas, parezca que la calidad mejoró
Otros casos de reportes de bugs
- También se menciona el bug FB22057274 “Pinned tabs: slow-loading target="_blank" links appear in the wrong tab”
- Aunque era un problema reproducible al 100%, Apple lo marcó como “Investigación completa - Unable to diagnose with current information”
- El 9 de marzo se solicitó información adicional, pero Apple no respondió
- En la beta de iPadOS 26.4 apareció además un nuevo bug de cierre inesperado de Safari, y Apple no lo corrigió antes del lanzamiento de la versión pública
- El autor criticó que “parece que el objetivo de la beta no es corregir bugs, sino molestar a quienes los reportan”
Cambios tras Hacker News y respuesta de Apple
- Justo después de que este texto llegara a la portada de Hacker News, Apple actualizó el reporte FB22057274
- Apple pidió enviar un sysdiagnose log por un problema de UI
- Ya se habían proporcionado pasos de reproducción y una grabación de pantalla, y se señaló que el sysdiagnose implica riesgos de privacidad y es material innecesario
- El autor respondió a la solicitud de Apple de la siguiente manera
- “Para un bug de UI no hace falta sysdiagnose y no ayuda”
- Como método reproducible incluso sin Little Snitch, propuso usar Network Link Conditioner de Xcode Additional Tools y configurar el perfil de latencia de uplink en 3000ms para reproducir el mismo comportamiento
Guía sobre Xcode Additional Tools
- Xcode Additional Tools incluye varias utilidades útiles y
puede descargarse desde la página de Apple Developer Downloads (requiere iniciar sesión)
Evaluación general
- La forma en que Apple gestiona los reportes de bugs impone una carga innecesaria a los desarrolladores y
funciona como una estructura más enfocada en reducir la cantidad de reportes que en resolver los problemas reales
- Debido a reportes sin respuesta durante largos períodos, solicitudes de verificación poco razonables y pedidos de información ineficientes,
se está debilitando la confianza de los desarrolladores y su disposición a colaborar
1 comentarios
Comentarios en Hacker News
Parece que el autor no ha vivido el mundo del software empresarial
Cuando un desarrollador recibe un reporte de bug, la táctica típica es decir “no lo puedo reproducir, ¿ya lo verificaste en la versión más reciente?” mientras no hace nada y deja pasar el tiempo
Si no puede confirmarlo, lo cierra como “error del usuario” o “no reproducible”
La única defensa es decir “sí, ya lo confirmé” aunque en realidad no lo hayas confirmado
Si ven un antivirus en los logs, lo cierran de inmediato diciendo “consúltalo con ellos”
Hay muchas prioridades de negocio más importantes que un bug reportado por una sola persona
Aun así, desde el lado del usuario es lamentable
La mayoría de los desarrolladores no sabe probar su propio producto o le da flojera hacerlo
Cuando trabajaba en soporte técnico empresarial, tenía que recibir al menos dos casos nuevos al día y gestionar más de 20 al mismo tiempo
Se sentía un gran alivio cerrar como “desactivado por inactividad” los casos que no avanzaban
Después pusieron una regla de contactar tres veces antes de cerrar y fue una pesadilla
Al final, la burocracia de las grandes empresas arruina todo
Apple parece tener una actitud de rezar para que el bug desaparezca solo
Yo también ya dejé de enviar reportes de errores
Que me ignoren no me molesta tanto, el problema es cuando me tratan como personal de QA no remunerado
Exigen un esfuerzo enorme para demostrar que el bug existe
La idea es “es tu software, así que depúralo tú”
Los proyectos de código abierto también hacen algo parecido con el cierre automático de issues stale
No tiene sentido asumir automáticamente que algo quedó resuelto solo porque pasó cierto tiempo
La ventaja del código abierto es que puedes arreglarlo tú mismo, enviar un PR o hacer un fork y resolverlo
Es más razonable filtrar los tickets viejos
Como usuario es frustrante, pero no todos los bugs son fáciles de reproducir
A veces, después de cambiar el código relacionado, es eficiente pedirle al usuario que vuelva a probar
Aun así, da mala espina cerrar bugs viejos que no se pueden ejecutar o verificar
Eso en realidad significaba que no se reproducía dentro de la red interna de Apple
Cerrar solo sirve para esconder el problema, y mantenerlo abierto no cuesta nada
Instalar una beta es mucho más ineficiente para el usuario
Yo hasta proporcioné un proyecto de ejemplo de Xcode y pasos para reproducirlo
Estoy convencido de que Apple no hizo nada
Parece más bien un show de limpieza de bugs para preparar macOS 27 antes de la WWDC
Cuando trabajé en Facebook y Google vi muchos trucos de gestión de bugs
Después de introducir SLA, bajaban artificialmente la prioridad de los bugs o se los aventaban al usuario con un “¿sigue siendo un problema?”
Con el tiempo lo cerraban diciendo que “esa versión ya quedó obsoleta”
Incluso a veces los fusionaban a la fuerza con otros bugs para esquivar la responsabilidad
Al final, todo esto existe por las métricas de desempeño organizacionales (SLA)
Por eso ahora casi no reporto bugs
Pero la dirección les dice “ahorita concéntrense en proyectos de IA”
Y luego los regañan diciendo que “hay demasiados bugs”
Me parecía más honesto ignorarlo que cerrarlo
El liderazgo empujaba este tipo de triaje forzado
Bloquear las notificaciones automáticas es un problema
Pero en la práctica la calidad de los datos es tan mala que no sirve para reportes
Por eso un solo valor de prioridad es más práctico
stalebot termina cerrando estos issues ignorados en su lugar
Llevaban por separado la severity para clientes y la priority interna
Salesforce “Lightning Experience”, a pesar del nombre, es muy lento
Las herramientas internas eran mucho más rápidas y eficientes
En ElevenLabs pasó lo mismo
Si enviabas un reporte de bug, una IA respondía automáticamente y a las 48 horas lo marcaban como stale
Parece que pronto los agentes LLM resolverán este problema
Podrán comentar automáticamente “todavía no está corregido” y hacer bump automático de forma periódica con algo como “esto afecta un flujo de trabajo importante”
Una vez envié un bug a Microsoft y meses después me respondieron “no reproducible”
En realidad, entre tanto, otro arreglo lo había resuelto indirectamente
Me di cuenta de que yo era como el ciego que solo tocó una parte del elefante
Soy ex empleado de Apple
El rastreador interno de bugs de Apple se llama Radar, y todos los issues tienen que pasar por una etapa de “Verify” antes de poder cerrarse
En apariencia parece un proceso de aseguramiento de calidad, pero en la práctica muchísimos Radar se quedan atorados para siempre en estado Verify
Como evalúan a los equipos por la “cantidad de Radar sin verificar”, después de cierto tiempo los fuerzan a cerrarlos
La ilusión de tener “0 bugs” produce métricas de desempeño distorsionadas
No necesariamente significa que un ingeniero de Apple haya intentado arreglarlo de verdad
En la empresa, junto con mis colegas, hacíamos reuniones de limpieza del backlog
para depurar bugs viejos de una sola vez
Este tipo de proceso es muy común