Apple rechazó mi aplicación de dictado por usar la API de accesibilidad

Artículo original ↗ Discusión en Hacker News ↗

Rechazo de la App Store y API de accesibilidad

  • La versión de la app para la Mac App Store fue rechazada bajo la directriz 2.4.5 por usar la API de Accesibilidad (AX) para pegar automáticamente en otras apps mediante pulsaciones de teclas sintetizadas (CGEventPost).
  • Una versión reducida para la App Store que solo escribe en el portapapeles (sin permiso AX; el usuario pulsa Cmd+V) fue aceptada.
  • La versión con todas las funciones se distribuye directamente desde el sitio del desarrollador, firmada y notarizada por Apple, así que la restricción es específica de la App Store, no de todo el sistema operativo.
  • Algunos señalan experiencias similares: las apps de dictado o automatización basadas en accesibilidad a menudo son bloqueadas en macOS, pero a veces pasan en iOS, o viceversa, con resultados de revisión inconsistentes.

Seguridad, privacidad y la justificación de Apple

  • Muchos comentaristas sostienen que Apple tiene razón al vigilar de cerca la API de Accesibilidad porque, en la práctica, concede control sobre todo el sistema: pulsaciones de teclas, cursor, capturas de pantalla y rutas de datos entre apps.
  • Entre las preocupaciones figuran apps maliciosas que peguen texto en campos sensibles (por ejemplo, bancarios) o exfiltren datos. Algunos enfatizan que los usuarios ingenuos concederían permisos demasiado fácilmente.
  • Otros argumentan que los usuarios ya deben otorgar explícitamente permisos AX y que se les debería permitir aceptar herramientas potentes; prohibir clases enteras de apps se ve como una extralimitación y posiblemente anticompetitivo.

Diseño de la API de Accesibilidad

  • Varios comentarios critican que la API es demasiado amplia; obliga a las apps a pedir más poder del que realmente necesitan.
  • Una solución propuesta: dividir AX en capacidades de alcance limitado, autorizables por separado (por ejemplo, pegar, capturar pantalla, control del cursor) en lugar de un único permiso de “superpoder”.
  • Contraargumento: para algunas discapacidades, el control arbitrario total mediante una sola interfaz es precisamente lo que se necesita, así que dividirlo no debe hacer engorrosa la habilitación de tecnología asistiva.

Plataformas, jardines amurallados y alternativas

  • Este caso alimenta un debate más amplio sobre ecosistemas cerrados. Algunos lo ven como otro ejemplo del régimen controlador e inconsistente de Apple en la App Store y abogan por plataformas abiertas y sideloading.
  • Otros defienden las tiendas curadas como algo valioso para la seguridad y dicen que los usuarios pueden elegir otros sistemas operativos si no les gustan estas restricciones.
  • Varios abogan por escritorios Linux como flexibles, con flatpaks, tiendas de apps y buen soporte de hardware, pero reconocen lagunas de compatibilidad (por ejemplo, Microsoft Office, algunos juegos) y fricción de migración para muchos usuarios.

Soluciones alternativas, impacto comercial y estrategia de desarrollo

  • Las sugerencias incluyen:
    • Tratar la Mac App Store como un “ancla de descubrimiento + licencia” para una versión más capaz de descarga directa.
    • Ofrecer una compilación limitada/de prueba en la App Store y vender una app “pro” aparte, fuera de la tienda.
  • Algunos cuentan que mantienen versiones separadas “seguras para la App Store” y “completas” de utilidades, especialmente las que dependen de AX.
  • Hay frustración por reglas opacas y aplicadas de forma inconsistente, pero también aceptación pragmática: muchos desarrolladores esperan múltiples rechazos y aprenden a diseñar alrededor de las restricciones de Apple.