Pareciera que esta historia fue sacada directamente del departamento de ironía pero por desgracia es bastante real. Phillip Shoemaker, quien trabaja para Apple, es el director de “tecnología de aplicaciones” y a su vez vende aplicaciones en la App Store bajo una compañía de nombre Gray Noodle.

Entre varias de las joyas que produce su compañía se encuentra aplicaciones de flatulencias o de hacer pipí, todas con un diseño y arte pésimo y una calidad que nos hace cuestionar como es que fueron aceptadas en la App Store.

¿Cuál es la ironía de todo esto? Que Shoemaker, varias veces ha sido citado como uno de los principales involucrados en el proceso de aceptación y/o rechazo de aplicaciones.

Al parecer los empleados de Apple están prohibidos de vender aplicaciones en la App Store a menos que obtengan un permiso especial y no se sabe si Shoemaker obtuvo este permiso o no.  Curiosamente después de publicada la información de Phillip Shoemaker y su relación con Gray Noodle, se ha dispuesto a editar sus perfiles de LinkedIn y entradas en Twitter para tratar de eliminar cualquier evidencia de que exista un vínculo entre él y Gray Noodle.

Supongo que ahora sabemos por qué la App Store de Apple está llena de tantas aplicaciones de excelente calidad</sarcasmo>.

[Vía: Wired]

Ahora si parece que Apple esta tomando “en serio” a su comunidad de gamers, desde que Valve sacó algunos de sus juegos para Mac ha puesto muy contentos a muchos usuarios que tenían que usar Bootcamp para poder jugar en Windows, pero no todo es miel sobre hojuelas ya que el rendimiento de los juegos en la Mac no es nada comparable al de Windows..

Es por esto que Apple apenas sacó una actualización para Snow Leopard que mejora el rendimiento gráfico y estabilidad de algunos juegos, cómo Team Fortress 2, Portal o Starcraft 2. Si eres maquero con alguno de estos juegos te recomendaría descargar cuanto antes esta actualización y verificar el aumento de rendimiento.

Vía: MacRumors

Excelente parodia al mismo estilo de Apple en relación al famoso fiasco de las antenas del iPhone 4. ¿Lo mejor? Gregg Joswack, el supuesto vicepresidente de “recepción del iPhone” que nos muestra como todos los teléfonos pierden señal… siempre y cuando los sostengas de maneras extrañas, los cubras por completo y utilices guantes industriales.

David Gewirtz es un periodista principalmente relacionado con el mundo de la tecnología el cual actualmente escribe una columna en ZDNet llamada ZDNet Government. En esta columna generalmente escribe acerca de las tecnologías de información y computación empresarial en los ámbitos del gobierno federal y estatal.

El día de ayer, esta columna fue un poco diferente a la habitual. Gewirtz  escribió una carta abierta en la cual reflexiona sobre la importancia de Steve Jobs, su imagen, si en verdad está haciendo actividades que valgan la pena y como todo el fiasco relacionado con el iPhone 4 ha dañado su reputación y que sería prudente dejarle su puesto a Phil Schiller, quien ha probado ser alguien más que capaz para seguir delante de Apple.

Los invito a leer el artículo completo, independientemente de su opinión de Apple o de Steve Jobs, el cual es una reflexión bastante bien pensada de la cual podemos tomar citas memorables como la que incluyo a continuación y me he tomado la libertad de traducir:

Hace casi 30 años, John Sculley trabajaba en Pepsi y tú le preguntaste, “¿Quieres seguir vendiendo agua azucarada por el resto de tu vida o prefieres venir conmigo y cambiar el mundo?”

Así que, Steve, esta es la pregunta que yo te hago: “¿Quieres seguir vendiendo teléfonos malos y aparatos electrónicos por el resto de tu vida o prefieres dejar Apple y cambiar el mundo?”

Piénsalo.

En Estados Unidos, y en algunos otros lados del mundo, cuando un producto tiene problemas de fábrica, defectos conocidos que podrían provocar daños mayores u otros problemas, estos tienen que ser “llamados de vuelta”, es decir, la empresa hace un recall de todos los productos para arreglarlos debido a las fallas que presentan.

Los problemas de Apple con su iPhone 4 parecen no parar. Primeramente, la revista Consumer Reports, dedicada a reseñar y comparar productos y servicios tomando como base resultados de sus propios laboratorios, ha decidido no recomendar al iPhone 4 debido a los problemas de recepción. Apple, se ha hecho de la vista gorda y ha decidido borrar todas las referencias a Consumer Reports en sus foros de discusión y hasta ahora su postura oficial ha sido ignorar el problema.

Según varios expertos, o eso dicen serlo, de PR (Relaciones Públicas) Apple se verá forzado a actuar debido a estas problemáticas; primeramente deberán de lanzar un comunicado de prensa en el cual desmientan a Consumer Reports, o acepten que existe el problema y propongan una solución para el mismo.

En dado caso que Apple opte por hacer el recall de todas sus unidades el impacto económico, según analistas, sería de $1,500 millones de dólares y eso sin contar que dañaría extensivamente su imagen.

Estoy de acuerdo que estos analistas probablemente saben de lo que hablan, al fin se supone que son expertos en “manejos de desastres” y ellos pueden especular por todos lados que es lo que Apple debería hacer pero la triste realidad es que dudo que un recall vaya a tomar lugar.

He estado leyendo reseñas y opiniones de algunas personas con el teléfono, y la mayoría parece ser que están encantados con el teléfono a pesar de los problemas. Básicamente todo se reduce a “es un gran aparato multimedia, excelente para navegar la red y leer correos, pero como teléfono simplemente no es la gran cosa y en algunos casos no sirve para efectuar llamadas”.

Algunas de estas personas han aceptado que hay que sostener el teléfono de una manera “especial” y están conformes con esto; triste, pero cierto, han aceptado las reglas de Apple junto con las fallas de su producto alterando sus hábitos para poder usarlo.

Ya se han entablado diversas demandas, algunas en forma de demanda colectiva, en contra de Apple y AT&T en relación a los problemas de diseño y señal del iPhone 4.  Y el escenario que pienso que sucederá es el siguiente:

Apple no llevara a cabo un recall, las demandas seguirán en pie y es muy probable que la empresa pierda la mayoría de las demandas y tenga que compensar a aquellos que firmaron la demanda de alguna manera. Es posible que se les dé la opción a los usuarios de devolverles su dinero, o compensarlos económicamente por los problemas del teléfono. Aun así, estas compensaciones económicas supondrán una cifra mucho menor a los $1,500 millones de dólares que costaría el recall y mientras toda la gente feliz usando su teléfono para todo menos para hablar seguirá siendo feliz.

No sé por qué la gente está dispuesta a aceptar un producto defectuoso o ¿acaso a tales niveles llega el fanatismo que prefieren ignorar que el producto no es tan perfecto como ellos esperaban?  Por mientras los precios de las acciones de Apple siguen a la baja desde la salida del teléfono.

En cuanto a características ambos sistemas operativos son muy similares, aunque me atrevería a decir que Android 2.2 tiene una ligera ventaja sobre iOS 4, y aun no sabemos lo que Android 2.3 (Gingerbread) tiene guardado para nosotros.

Notas

• ¹ Multi-tasking selectivo.
• ² Con cargos adicionales.
• ³ No se puede hacer con cuentas en la aplicación oficial de Gmail.
• ⁴ Es posible, pero requiere Jailbreak.
• ⁵ Se puede hacer por aplicación si el desarrollador así lo incluyo.
• ⁶ Es posible utilizar “home screens” de terceros.

Desde hace algunos meses he expresado mi descontento con varias de las políticas de Apple y su creciente cambio de políticas y términos de uso; estos cambios y políticas por desgracia no solo aplican para los usuarios; también para los desarrolladores de la plataforma y al parecer cambian cada que a Apple le parece.

El primer cambio que me pareció en exceso fue al querer limitar compiladores de terceros y que todas las aplicaciones deberían ser desarrolladas bajo Objective-C con lo cual limitaba las opciones de los desarrolladores y por supuesto, le daba un golpe muy duro a Flash CS5 con su funcionalidad para portar aplicaciones al iPhone y de paso se llevó a otros proveedores de soluciones similares, como Unity, entre las patas.

El lunes pasado en la WWDC ’10 se efectuó otro anuncio que fue bastante sorpresivo en el cual se comentaba el cambio de algunas políticas:

3.3.9 You and Your Applications may not collect, use, or disclose to any third party, user or device data without prior user consent, and then only under the following conditions:

- The collection, use or disclosure is necessary in order to provide a service or function that is directly relevant to the use of the Application. For example, without Apple’s prior written consent, You may not use third party analytics software in Your Application to collect and send device data to a third party for aggregation, processing, or analysis.

- The collection, use or disclosure is for the purpose of serving advertising to Your Application; is provided to an independent advertising service provider whose primary business is serving mobile ads (for example, an advertising service provider owned by or affiliated with a developer or distributor of mobile devices, mobile operating systems or development environments other than Apple would not qualify as independent); and the disclosure is limited to UDID, user location data, and other data specifically designated by Apple as available for advertising purposes.

¿Notan algo curioso con el uso de las palabras por parte de Apple? En si Apple no está bloqueando a las empresas competidoras de publicidad móvil de tener acceso a la recolección de datos siempre y cuando estas empresas sean independientes y su negocio primario sea referente a la publicidad móvil.

Es decir empresas como Greystripe, Millenial Media y Medialets están libres de pecado, mientras que AdMob de Google estaría fuera de los límites. Y si por alguna razón Microsoft decidiera entra al negocio de la publicidad móvil también se las verían duras en la plataforma de Apple.

Si no te gustan las políticas de Apple búscate otra plataforma

Una de las respuestas más comunes a las quejas por parte de diferentes personas, en las que me incluyo, referente a la plataforma de Apple se puede resumir en “si no te gusta, eres libre de irte a otra plataforma, nadie te obliga a quedarte con Apple.”

Y si bien tienen razón esta respuesta tan solo muestra que, en primera, estas personas no son desarrolladores, y en segunda, que no pueden ver más allá de los cambios de Apple y las implicaciones que estos cambios significarían para el desarrollador; el problema no es con las políticas en sí, si no con la forma en que se efectuó el cambio.

Debido a que la App Store se encuentra controlada, y supuestamente monitoreada, por Apple nada le garantiza a un desarrollador que su aplicación estará en la App Store para siempre. ¿Qué pasara el  día de mañana que Apple decida que todas las aplicaciones de color azul no son bienvenidas en la App Store?

¿Por qué aplicaciones, que supuestamente, pasaron el proceso de validación de la App Store un día, para el día de mañana ya no cumplen con las reglas de Apple? Mientras que aplicaciones totalmente inútiles, y malas, se encuentran en la App Store, otras aplicaciones que si tienen potencial y son útiles son rechazadas por Apple por razones totalmente estúpidas.

Todas las aplicaciones creadas con Flash CS5, o con Unity por ejemplo, que fueron aprobadas en la App Store; de un día para otro dejaron de ser válidas. Aplicaciones que por capricho de Apple, por x o y razón, de un día para otro, mágicamente, dejaron de pasar el, supuesto, proceso de aprobación tan selectivo de Apple.

Si yo tengo una aplicación que use AdMob para generar ingresos, y ya ha estado en la App Store por meses, este cambio a las políticas de uso significa que mañana mi aplicación será retirada de la App Store por el simple capricho de Apple.

Simple. Estos cambios no están hechos, ni pensados, en el mejor interés de los desarrolladores (o de los usuarios). A lo largo de la historia de la innovación tecnológica está claro que la competencia es la mejor partidaria para todos; todos salimos ganando. Este tipo de barreras artificiales, que se limitan más que nada a un estúpido acuerdo de palabras, tan solo daña a los usuarios y los desarrolladores y en el largo plazo limita la innovación y el progreso tecnológico.

Durante un lapso de tiempo se calcula que los datos de 114,000 compradores de iPads (y se sospecha que hasta todos los compradores del iPad 3g tambíén), estuvieron disponibles para cualquier persona. Esto gracias a que un grupo de hackers llamados Goatse Security, encontraron una vulnerabilidad en el sitio de AT&T que les permitió usar un script que les diera acceso a los datos. La información que quedó disponible fueron sus correos electrónicos y su identificación para autentificarlos dentro de la red de AT&T, algo grave a resaltar es que entre los clientes se incluyen algunos del gobierno de Estados Unidos, de la Nasa y de grandes compañías como Google, Dow Jones y Viacom.

Parece que entre el iPhone 4 encontrado por Gizmodo, los problemas con los empleados de Foxconn en China, el problema de Wi-Fi en la WWDC y esto, las cosas no le han salido muy bien a Apple, tal vez deberán tener más cuidado.

A principios de esta semana Apple develo una página (HTML5 Showcase) en la cual, supuestamente, hacen una demostración utilizando varios ejemplos, siete en total, de todas las características y posibilidades que tiene HTML5 en el futuro desarrollo de aplicaciones web.

No me opongo a esto, al contrario, lo aplaudo, pero fue hasta darme cuenta que Apple está jugando un poco sucio que no me pareció la supuesta demostración.

Los demos funcionan… solamente en Safari

Si ustedes tratan de visualizar los demos en cualquier navegador que no sea Safari se encontraran con un pequeño mensaje que reproduzco a continuación:

Según Apple, es necesario que utilicemos Safari única y exclusivamente para poder visualizar los demos.  Y supuestamente es el único navegador, según ellos, que es capaz de visualizar las demostraciones. Por lo cual surge la siguiente observación: Si se supone que Apple está usando código 100% estándar entonces cualquier otro navegador que soporte los mismos estándares debería poder desplegar las demostraciones.

¿Por qué Apple llega a tal grado de utilizar un Javascript para detectar el navegador utilizado y así poder mostrarnos esa hermosa leyenda pidiéndonos que usemos Safari?

Probemos con Google Chrome

Técnicamente Google Chrome y Safari son la misma bestia. Ambos utilizan Webkit como motor con la única diferencia que Chrome es actualizado más rápido, es multi-plataforma, mucho más liviano, y en mi opinión, mejor que Safari.

Primeramente debemos de saltarnos el browser sniffer que Apple utiliza y esto lo podemos hacer de varias formas: Bloqueando la ejecución de Javascript o cambiando el user agent de Chrome.

Si bloqueamos Javascript es posible acceder a los demos pero nos encontramos con otro mensaje en cada uno de los demos: Es necesario tener Javascript activado para la ejecución de los demos. Extraño, ¿no se supone que era puro HTML5?

Cambiemos el user agent de Chrome entonces. Para hacer esto basta con crear un acceso directo a Google Chrome y añadir lo siguiente: –user-agent=”Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-us) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10″.

No era de sorprenderse que cada uno de los demos, con excepción de uno, funcionara a la perfección en Google Chrome. El demo de VR no es funcional debido a que utiliza CSS 3D Transforms, las cuales no están implementadas, aun, en Google Chrome.

Algo curioso es que el demo de video requiere forzosamente la utilización de quicktime; de no contar con quicktime el video no será reproducido, pero las opciones de Scale y Mask serán funcionales. A menos que me equivoque los archivos mov no se encuentran entre los formatos oficialmente soportados por la etiqueta de <video>, ¿o si?

Usan extensiones propietarias

Es normal que los desarrolladores de navegadores añadan algo denominado vendor prefix, que no es más que un prefijo específico para cada navegador que se antepone a algunas propiedades en CSS. Estos prefijos se utilizan normalmente cuando la propiedad aún se encuentra en pruebas o no está finalizada; el soporte está ahí pero no se ha implementado, por lo menos no de la manera propia.

Es así como tenemos -moz, para Mozilla, -o, para Opera y -webkit, para Safari y Chrome. Por ejemplo, la propiedad de border-radius, si queremos asegurarnos que funcione en Mozilla, Opera y Chrome, deberíamos de añadirla por lo menos cuatro veces: border-radius, -moz- border-radius, -o- border-radius y -webkit- border-radius.

Resulta que a Apple poco le ha importado utilizar la propiedad sin el prefijo y únicamente ha utilizado las propiedades con el prefijo propietario pertinente a webkit (-webkit). Es decir, si los otros navegadores soportan o no la propiedad, no lo han añadido, y mucho menos han añadido las propiedades con prefijos propietarios de otros navegadores.

Esto no es más que una campaña de adopción de Safari

El objetivo de este showcase es claro: limitar el uso de otros navegadores al hacerlos quedar mal en los demos de HTML5 y mostrar la supuesta superioridad de Safari; así mismo al fomentar el uso de Safari como el único navegador capaz de mostrar los demos trataran de incrementar su cuota de mercado.

El uso de estándares asegura que el contenido podrá ser visualizado por cualquier navegador, en cualquier plataforma, siempre y cuando el navegador soporte dichos estándares. No hay razón por la cual nosotros como desarrolladores debamos de utilizar browser sniffers y extensiones propietarias y limitar las opciones de nuestra audiencia.

Y curiosamente los chicos de Opera y los de OSNews se están haciendo las mismas preguntas que yo.

Si en verdad quieren ver demostraciones de HTML5 que funcionan y son mucho más impresionantes que cualquier cosa que Apple pueda mostrar hasta ahora los invito a visitar CanvasDemos.

Gracias Apple, pero seguiré usando Firefox y Chrome.

Esta “solución” supone un uso mucho más considerable del CPU por parte del servidor, además de que su desempeño no es exactamente estelar y carece de sonido, por ahora.

Las posibilidades a futuro son bastante alentadoras; en desarrollos bastara con utilizar esta solución por parte del servidor para que la experiencia entre dispositivo móvil y computadora sea prácticamente nula.

Vía: artefact

Por favor, por favor, por favor, espero que a Apple, ni a nadie, se le ocurra crear este horrendo (y ridículo) concepto de iWatch. Aunque por otro lado, probablemente podría diluir bastante a la marca, ¿así que por qué no?

Via: ADR Studio

Después de una larga espera de un poco más de dos meses HTC por fin ha reaccionado ante la presión de Apple y ha contra-demandado a la compañía de la manzana por la violación de 5 de sus patentes en productos Apple como lo son el iPhone, iPod e iPad.

A continuación la lista de patentes, si bien, son mucho menos que las patentes de Apple, aun sirven para ser utilizadas como defensa en contra de Apple.

• 6999800: Method for power management of a smart phone (Metodo para la gestión de energía en un smart phone) emitida el 14 de Febrero de 2006.
• 5541988: Telephone dialler with a personalized page organization of telephone directory memory (Marcador de teléfono con organización de memoria de directorio telefónico personalizada) emitida el 30 de Julio de 1996.
• 6058183: Telephone dialler with a personalized page organization of telephone directory memory (Marcador de teléfono con organización de memoria de directorio telefónico personalizada) emitida el 2 de Mayo de 2000.
• 6320957: Telephone dialler with easy access memory (Marcador de teléfono con acceso fácil a memoria) emitida el 20 de Noviembre de 2001.
• 7716505: Power control methods for a portable electronic device (Métodos de control de energía para un dispositivo portátil electrónico) emitida el 11 de Mayo de 2010.

¿Qué sucederá ahora?

Entre las exigencias de Apple, y las contra-demandadas por HTC, se pide que se retiren del mercado los productos que infrinjan con las patentes, pero la verdad es que muy rara vez este tipo de casos llegan a esos extremos.

Aún faltan unos años para que este caso llegue a una resolución pero la única solución viable es llegar a un acuerdo fuera de corte y terminar con el asunto.

¿Pero qué tan viable es hacer este reemplazo? iBrent se ha dado a la tarea de probar varios demos de HTML5 en el iPad y los resultados son bastante desalentadores. Aún nos falta mucho.

Finalmente Adobe decidió resignarse y parar el desarrollo de su compilador de Flash a iPhone, que era una de las características principales que iban a ofrecer en la suite CS5.  A partir de ahora se enfocarán a otras plataformas como Android, ya que vieron el éxito que ha estado teniendo en el Nexus One o el Motorola Droid además de los demás dispositivos basados en Android que vienen en camino.

Uno de sus argumentos es que Flash siempre ha tenido el objetivo de ser multi-navegador, multi-plataforma y puede ayudar al desarrollo de aplicaciones, pero desgraciadamente es todo lo contrario a lo que Apple quiere, es decir, obligar a los desarrolladores a utilizar solo su plataforma bajo sus propias reglas y reducir opciones para que sea más complicado desarrollar en otras plataformas.

Ya que se dieron cuenta que Apple no es la única opción, se han estado enfocando a llevar Flash 10.1 y Adobe Air 2.0 a dispositivos móviles, con resultados muy prometedores en estos momentos. ¿El drama con Apple?, aún no sabemos que mas pasará pero a mi me gustaría que trataran a Apple, como ellos trataron a Adobe.

Para ilustrar el problema, consideremos una aplicación hipotética para el iPad llamada Ed’s App World (EAW). EAW nos permite descargar elementos llamados EdApps, que consisten en instrucciones que la aplicación ejecuta. Cualquier desarrollador puede crear una EdApp que interpretara sus instrucciones en el lenguaje de programación Ed. Es perfectamente posible crear una aplicación como EAW.

El problema de regulación de Apple es que Ed’s App World es en realidad una tienda de aplicaciones competidora – Las EdApps pueden hacer cualquier cosa que las aplicaciones nativas puedan hacer, y cualquier desarrollador puede crear y distribuir una EdApp. Si Apple quiere evitar la competencia de App Stores, ellos deben evitar que aplicaciones como EAW existan.

Apple ha tratado durante mucho tiempo mantener a tecnologías específicas, como Adobe Flash, fuera del iPhone/iPad debido a que estas tecnologías tienen características como EAW. Ahora Apple ha ampliado sus regulaciones al decirnos  que sólo ciertos métodos de programación son aceptables. En la sección 3.3.1 del acuerdo de licencia de desarrollador se establece:

3.3.1 – Las aplicaciones sólo podrán utilizar APIs documentados en la forma prescrita por Apple y no deben usar o llamar a cualquier API privado. Las aplicaciones deben haber sido escritas originalmente en Objective-C, C, C + + o JavaScript ejecutado por el motor de Webkit, y sólo el código escrito en C, C + + y Objective-C puede ser compilado y enlazado directamente con los APIs documentados (por ejemplo, las aplicaciones que tienen enlaces a los APIs documentados a través de una traducción intermedia o una herramienta de compatibilidad de nivel superior están prohibidas).

Esto deja fuera a muchos lenguajes de programación y herramientas comunes. Para los desarrolladores, parece que Apple está tratando de micro-gestionar cómo deben hacer su trabajo

La prohibición de Apple de aplicaciones programables va más allá de Flash. Esta semana Apple prohibió Scratch, una herramienta educativa ampliamente utilizada que introduce a los estudiantes al mundo de la programación e informática al permitirles construir animaciones. ¿Por qué Apple veto a Scratch? Presumiblemente por que las animaciones de Scratch contienen elementos de programación.  Los educadores no se encuentran contentos, por decir lo menos. Mark Guzdial de Georgia Tech lo expresó así: “¿Quieren ser realmente letrados en  informática, en donde pueden escribir, así como leer? No hay una aplicación para eso.

Lo que es realmente interesante es que pese a los esfuerzos de Apple para bloquear estas aplicaciones, hay un enorme sistema de tipo EAW que Apple no ha tenido las agallas de bloquear: la web. Gracias a las tecnologías Ajax, la web se ha convertido en un vehículo para poder entregar funcionalidades de tipo aplicación (dentro de las páginas web). El navegador Safari de Apple en el iPhone y iPad soporta estas aplicaciones. Es difícil imaginar que Apple podría salirse con la suya al bloquear todos los sitios habilitados con Ajax que usamos todos los días. Y el problema de Apple con Ajax será aún peor a medida que HTML 5 surja con un mejor soporte para aplicaciones basadas en web.

Si no son aficionados a la tecnología, este tema puede parecer como de otro mundo. Pero sí afecta lo que pueden hacer y ver. Es posible que no conozcan todos los detalles del por qué la App Store empieza a verse más y más como Disneylandia, pero se darán cuenta que esto está sucediendo.

Por último, me gustaría abordar la objeción común que la mayoría de las personas no se preocupan por los límites en la programación, porque no saben programar. Para mí, esto es como decir que no les importa el cierre de restaurantes porque nadie en su casa sabe cocinar. Si ustedes no pueden cocinar ustedes mismos, les debería importar más la calidad del restaurante. Si todos los buenos restaurantes cierran, los buenos cocineros terminaran por cocinar sus propias comidas – pero ustedes no tendrán la misma suerte

* Nota: Este articulo apareció originalmente en Freedom To Tinker por Ed Felton y yo me he encargado de traducirlo al Español.