Caramelo 🫠
(Así me entretengo para no llorar por tener que esperar 2 semanas más para mi iPhone Duo).
Si tenéis el iPhone Duo, a parte de @FitWoody_Camp, decidle a vuestro ortodoncista que pruebe OrthoKit que ya está también adaptada al Duo 😛
Alberto retweeted
Apple empieza a poner freno al descontrol del Vibe Coding. El vibe coding (crear apps casi enteras con IA y prompts) ha explotado. Cualquiera puede generar una app en minutos. El problema es que eso ha inundado el App Store de productos de bajísima calidad: clones, plantillas reetiquetadas, apps de linterna, fondos de pantalla, temporizadores, etc. que no aportan nada.
Apple no ha creado una norma que diga “prohibido el vibe coding”, pero sí está aplicando y endureciendo las reglas que ya tenía contra el spam y las apps de bajo esfuerzo. Especialmente la Guideline 4.3 (Spam). Vibe Coding como tal no es el problema, lo es crear productos de bajo valor o clones sin sentido de la versión 985 de un tracker de hidratación.
En la práctica, esto se traduce en:
1. No envíes en masa apps casi iguales con distintos Bundle ID. Apple lo prohíbe explícitamente para evitar fraudes masivos y spam de apps.
2. No copies productos que ya existen en grandes cantidades. Apps indistinguibles de las que ya hay degradan la calidad del App Store. Aquí entran incluso copias de los iconos o intentos de parecerse a otras apps famosas para intentar engañar a un usuario despistado.
3. En categorías maduras (fondos de pantalla, linternas, temporizadores simples, efectos de sonido, etc.) si no hay una mejora real de la experiencia, no pasan. ¿Sabías que hay casi 1.000 apps de hidratación y decenas de miles de gestores de tareas iguales unos a otros?
4. Enviar repetidamente apps de baja calidad y bajo valor puede acabar en la eliminación de la cuenta del Programa de Desarrolladores. Ya está pasando. Hay developers (son más de 60 millones en 2025) que se le están borrando todas sus apps al no aportar nada o ser una pantalla con 4 botones. Sobre todo si intentan monetizar de alguna manera.
Estas reglas ya existían, pero en 2026 Apple las ha matizado y endurecido. Ahora dejan claro que las apps de bajo esfuerzo no solo se rechazan, sino que pueden llevar a expulsar al desarrollador.
El mensaje es simple: puedes usar IA para crear apps, pero el App Store ya no es un vertedero de productos mediocres generados en masa. Si no aportas algo útil, único o mejorado, Apple empieza a cortar el grifo.
El descontrol del vibe coding de baja calidad tiene los días contados en el App Store.
Alberto retweeted
I don’t know man, I feel like devs bringing their apps to the Duo ought to be able to get their Duo’s on launch day :/
Alberto retweeted
Qué asco de gente. Tengo conocidos que son desarrolladores y no lo han conseguido comprar en la fecha de lanzamiento. 🤬
iPhone Duo pre-orders for launch day are currently selling on eBay for $3000+
Apple sigue intentando encajar Siri IA en sus tradicionales ciclos de producto (con modelos que llegan tarde y capacidades fragmentadas) mientras la competencia avanza a velocidad relámpago sin depender de un calendario de lanzamientos.
Alberto retweeted
Conozco una app muy buena para seguir el stock en las tiendas. Os dejo en enlace 😉
apps.apple.com/es/app/fruitw…
No sé yo si una IA hubiese tenido la sensibilidad suficiente como para aburrirse un sábado por la tarde y hacer que la interfaz reaccione al color de vestimenta de cada paciente 🫠
Alberto retweeted
Cultured Code, la empresa detrás de Things, hace casi todo al revés que el resto del software. Son 11 personas, llevan casi 20 años, no tienen capital riesgo y pasan de suscripciones, solo tienen pago único.
Su CEO dice que tienen "el modelo de negocio de los dinosaurios". Calcula que no han vendido ni al 1 % de su mercado posible y le da igual el crecimiento interanual. Él mismo dice que "si le dijera esto a uno de capital riesgo, se acabaría la conversación".
La IA no le preocupa. Con ella cualquiera se hace una demo de gestor de tareas en una tarde (hasta yo me la hice), pero a partir de cierto tamaño no crece. Sobre el código que genera dice que "casi seguro que no está bien pensado, porque no hay nadie pensando".
Un detalle muy @culturedcode: hicieron su propio motor de animaciones porque el de Apple no les terminaba de convencer. Cuando despliegas una tarea, la expansión y la sombra tienen curvas distintas y ajustadas por separado. Alguien decidió que la sombra merecía su propia curva. Es justo lo que el CEO echa de menos en el código que escribe la IA: que alguien lo haya pensado.
Entrevista de @macpowerusers a @jainek: youtube.com/watch?v=HjrwHFjP…
Replying to @lacort
En general parecen una empresa que decidió estancarse en varios sentidos: nada de versión web (en los años '10 muchas apps pasaron a ser pestañas de navegador). Nada de suscripciones. La innovación que la hagan otros.
Some updates can’t be delivered through the App Store. @lindadong , your next 3D OrthoKit icon v2.0 might require another trip to Apple Park 🌈 👀
Alberto retweeted
Back by popular demand we're hosting 2 more iPhone Duo Group Labs.
Tonight 10/13 at 6PM PST
10/15 at 9AM PST
For tonight you can tune in on YouTube: youtube.com/live/GWz8siwQk8M…
And ask questions through Apple Developer:
developer.apple.com/events/v…
Alberto retweeted
¿Un Toggle necesita un Bool, pero tu modelo guarda la selección en un Set?
Binding(get:set:) resuelve esa adaptación. Si la repites en muchas filas, otra opción es expresar la lectura y escritura con un subscript del modelo y conectarlo mediante $model[isSelected: item.id].
La lógica queda encapsulada y SwiftUI puede representar la proyección mediante un key path.
Eso no hace que cada elemento del Set se observe de forma independiente. Tampoco convierte los bindings con closures en una mala práctica: siguen siendo útiles para adaptaciones puntuales.
Rescato esta Swift Pill para comparar ambos enfoques y comprobar las reevaluaciones con herramientas de diagnóstico, sin confundir llamadas a body con rendimiento real.
Enlace en el hilo 👇
#SwiftUI #Swift #Observation


























