¿Qué es lo más difícil en el desarrollo de una aplicación para iOS?

1. Depuración de problemas con el aprovisionamiento de perfiles, la firma de aplicaciones y la carga en la tienda de aplicaciones. Hay un par (o más) de complementos QuickLook * que pueden ayudar un poco, pero esta área sigue siendo un gran dolor de cabeza.

2. Monetizando su aplicación. Un porcentaje muy pequeño de todos los desarrolladores de aplicaciones obtiene la mayor parte de los ingresos, mientras que una gran cantidad de aplicaciones excelentes no recibirán ninguna atención y, por lo tanto, no habrá ventas, debido a la falta de exposición. Apple necesita:

• subir el listón en el envío de aplicaciones para que la tienda de aplicaciones no esté llena de la primera incursión de todos en la programación
• eliminar aplicaciones en la tienda de aplicaciones que el desarrollador no esté desarrollando activamente
• crear un descubrimiento más significativo y un mecanismo de búsqueda. La búsqueda de una aplicación o una palabra clave no debería dar como resultado decenas o cientos de aplicaciones que controlan marcas comerciales o marcas.
• trabajar para reajustar las nociones de “valor” y “valor” de los usuarios finales para que los desarrolladores puedan fijar el precio de las aplicaciones a puntos de precio más saludables y sostenibles por encima de $ 5 y $ 10. Las buenas aplicaciones siguen siendo una ganga a precios equivalentes a una bebida de Starbucks o al precio de un boleto de cine, sin embargo, los usuarios se han acostumbrado a que todo sea $ 0.99 o gratis.

3. La estabilidad de Xcode. En los últimos 8 años más o menos, he notado más comportamiento con errores en Xcode. A menudo recibo discos giratorios que bloquean cualquier otro trabajo, bloqueos inesperados, actualizaciones de pantalla inconsistentes y errores extraños que desaparecen una vez que Xcode se cierra y se reinicia. Apple realmente debería trabajar duro para hacer Xcode, y el SO * SOLO * que uno puede usar para desarrollar aplicaciones, más robusto y rápido.

* https: //www.google.com/url? sa = t & …

El desarrollo de aplicaciones iOS es una carrera que ningún ingeniero de software y consultor de trabajo puede socavar. De hecho, es un verdadero orgullo ver tus cosas creativas en iOS App Store. Sin embargo, hacerlo así exige una gran dedicación y brillantez. Como periodista tecnológico, a menudo interactúo con desarrolladores y diseñadores. Aquí, es lo que opinaron cuando les hice esta pregunta.

Diseño automático

Con la disponibilidad de dispositivos iPhone y iPad en diferentes tamaños y resoluciones de pantalla, se convierte en un desafío para un desarrollador decidir las restricciones requeridas en el diseño, es decir, la interfaz de usuario, para hacer que la experiencia del usuario sea increíble. Realmente necesitan quemar el aceite de medianoche para dominar Xcode y su diseño automático. Sin embargo, existen buenas alternativas, siempre que defienda la programación de Swift o sepa cómo aplicar las máscaras de tamaño automático. La dirección de diseño debe guiarse por el tipo de idioma utilizado en la aplicación. Por ejemplo, en inglés, se requiere una dirección de diseño de izquierda a derecha, mientras que en idiomas que se escriben de derecha a izquierda, iría al revés.

Multi-Threading

Los desarrolladores a menudo se quejan de problemas de subprocesos múltiples. Con los consumidores cada vez más demandados en términos de rendimiento y características y desafíos del mercado sin conocer límites, una mayor responsabilidad recae sobre los desarrolladores de iOS. Necesitan adquirir habilidades más prácticas relacionadas con el uso de Grand Central Dispatch (GCD), la API que hace posible el subprocesamiento múltiple. Si eres un principiante y no has oído hablar de él, permíteme explicarte el uso de subprocesos múltiples. En realidad, contiene múltiples procesos a través de múltiples hilos. Poner varias etapas en un hilo principal ralentiza la aplicación.

Crear certificados

Generar y aplicar certificados SSL / TLS es otra tarea desalentadora en el desarrollo de aplicaciones iOS que ayuda a asegurar la comunicación hacia y desde el clúster administrado Swift Stack. Al hacerlo, la comunicación a través de la aplicación es segura. Los pasos comunes involucrados son los siguientes:

1. Cree una clave privada (para mantener en secreto y almacenar de forma segura).
2. Genere una solicitud de firma de certificado (CSR, .csr).
3. Use su CSR para comprar un certificado firmado comercialmente.
4. Reciba su certificado de servidor y certificados intermedios del emisor del certificado.
5. Ensamble y aplique los certificados a su clúster.

Hasta el paso número 4, el proceso se ejecuta sin problemas. Los únicos obstáculos aparecen en el paso 5. El desafío es recuperar los certificados requeridos por el emisor del certificado.

He estado desarrollando aplicaciones iOS desde mediados de 2014, y estoy desarrollando aplicaciones iOS y Android como una profesión de tiempo completo desde hace un año y medio.

La dificultad, es relativa, algo que puedo hacer sin esfuerzo puede no ser posible para otro desarrollador, y viceversa.

Diseño automático

Como muchos sugirieron, el diseño automático es un desafío para muchos desarrolladores. Personalmente, me encantan los diseños automáticos, ya sea a través del guión gráfico o por código. Estoy un poco orgulloso de que me encanta el autolayout y puedo hacer cosas exactamente como quiero.

Almacenamiento en caché de imágenes

Algo que debe haber perseguido a casi todos los desarrolladores de iOS en algún momento cuando implementan un UITableView o un UICollectionView, que tiene que mostrar imágenes de un servidor, en su celda correspondiente. ¿Por qué es esto un problema?

Bueno, las celdas se reciclan cada vez que la celda entra y sale de la pantalla. Obtener una imagen de un servidor es una tarea que debe realizar en el subproceso de fondo de forma asincrónica, mientras que la actualización de la imagen en la interfaz de usuario debe realizarse en el subproceso principal. ¿Suena bien?

Bueno, cuando el usuario se desplaza por las imágenes, se disparan solicitudes bastante rápidas para la imagen, pero la respuesta del servidor tarda un poco en llegar al dispositivo. Entonces, lo que sucede es que a veces obtienes la imagen incorrecta en la celda.

No es una tarea imposible de recorrer. Es simple una vez que comprende cómo funciona el almacenamiento en caché y cómo se deben manejar las solicitudes. Pero esto es algo que casi todos habían enfrentado en algún momento.

SpriteKit y Metal

Los objetos animados en 3D no son algo que deba implementar en cada una de sus aplicaciones. Es posible que aún no tenga que lidiar con una API de bajo nivel como Metal y trabajar más cerca de la GPU para implementar simulaciones 3D para sus aplicaciones.

(SpriteKit es un juego de niños comparado con Metal)

Dime, cuántos desarrolladores de iOS conoces pueden implementar esto:

Imagen de Wikipedia

No muchos de ellos, supongo. Si las personas tienen problemas con AutoLayout, ni siquiera consideren la API de Metal. Eso será como la ciencia espacial.

Compatibilidad de código

Swift se actualiza cada año. Su aplicación C objetiva está desactualizada, al igual que sus aplicaciones Swift 1 y Swift 2. La conversión de Swift 1 a Swift 3 no es tan fácil como parece, XCode no lo hace por usted. La mayoría de las veces, tendrá que volver a escribir el código nuevamente para este propósito. Ahora que Apple ha anunciado que las nuevas incorporaciones a Swift a través de la comunidad de código abierto no deben ser destructivas (es decir, no deberían inutilizar el código Swift 3 y posterior) es un alivio.

Sin embargo, aún existen problemas que algunos de los métodos o propiedades que usa ahora pueden quedar obsoletos más adelante. Sin embargo, no lo llamaría algo malo. Tendrá que actualizar su código regularmente. Aunque su aplicación aún puede funcionar, no es agradable ver 14 advertencias en su código completado.

Mismo diseño para Android e iOS

Esto sucede cuando su superior o el cliente realmente no entienden cuán diferente es el diseño de la interfaz humana para Android e iOS y esperan que implemente el mismo diseño tanto para iOS como para Android.

Android tiene una guía de diseño de materiales bien definida que puede seguir para crear impresionantes aplicaciones listas para el diseño de materiales. Es divertido y se adapta bien a las aplicaciones de Android.

Para iOS, es un poco diferente. La directriz de la interfaz humana (como la llaman) no está tan bien definida como Android. Esto le permite utilizar los componentes ricos de UIKit junto con Core Graphics para crear UI / UX muy animados e interesantes. No me gustaría implementar un NavigationController o un botón de acción flotante en mi aplicación iOS. Las cosas deben permanecer si pertenecen, por favor no le pida al desarrollador que haga su aplicación de iOS exactamente como la de Android, o viceversa.

Hay más, por supuesto. Pero estas son las cosas en las que puedo pensar por ahora.

Debe ser diferente de desarrollador a desarrollador

pero en mis 7-8 años de experiencia, esto es lo que encuentro difícil de implementar en iOS

• Escribir código comprobable de unidad en ios
• Uso eficiente de GCD o NSOperationQueue
• Subclase flowlayout en UICollectionView
• Implemente con precisión el monitoreo / rango de la región ibeacon

Creo que el problema principal es que Apple cambia las cosas tan rápido después de la muerte de Steve Jobs que no podemos adoptar fácilmente.

Primero, introdujeron el iPhone de 4 pulgadas después del iPhone 5 con pantalla 3.5, lo que provocó que todos los desarrolladores volvieran a mirar sus aplicaciones para ver cómo funciona en el iPhone 5 y tratar de hacerlas de alguna manera usando el tamaño automático que funciona bien en ambos tamaños de pantalla. Luego, introdujeron iOS 7, que cambió a la interfaz de usuario completa y nos hizo un gran trabajo para arreglar nuestra aplicación existente, tanto en iOS 6 y 7 cuando iOS 6 fue ampliamente utilizado al principio. Luego, cuando nos acostumbramos a problemas anteriores, introdujeron un lenguaje de programación completamente nuevo y Xcode 6. mientras que Xcode 3 duró 4 años y Xcode 4 duró 2 años, Xcode 5 duró solo 1 año y se reemplazó con Xcode 6 cuando se estabilizó después de 5.1 .1. Empeora cuando al mismo tiempo otro tamaño de pantalla está disponible con el lanzamiento del iPhone 6. Todavía no me adoptaron para el diseño automático porque era difícil de aprender cuando Apple introdujo otra cosa llamada Clases de tamaño, que tampoco tengo idea de eso, así que desmarco ambas cuando creo un nuevo proyecto.

Ahora tenemos 2 lenguajes de programación:

-Objetivo C va a quedar en desuso y no valdrá la pena aprender más y comenzar grandes proyectos en el que queremos brindar apoyo durante años.

-Swift es tan nuevo y aún está en fase de cambio y desarrollo, y carece de suficiente comunidad para buscar ayuda que lo hace inútil para una programación real y se convirtió en una herramienta para divertirse en el patio de recreo.

Además, la combinación de uso de ambos idiomas en un solo proyecto está haciendo que todo el desarrollo de iOS sea más complejo.

Lo que quiero es que Apple simplemente se calme durante 2-3 años y deje que el cambio existente lo haga estable y las tecnologías más antiguas se vuelvan obsoletas antes de introducir otras nuevas.

La dificultad proviene de no entender las cosas y no acostumbrarse a ellas.

1. La situación más difícil sería agregar parches al código escrito para cambios de alcance por parte de su administración. Algunas veces, el código estándar no se puede mantener debido a cambios en el alcance y para cumplir con el cronograma.

2. Interactuar con SOAP Api es un poco desafiante en iOS, en particular SOAP API que le pide que firme el cuerpo del mensaje con Certificados.

3. La migración de un backend a otro backend para una aplicación en producción debe tratarse con cuidado. Pruebe varias veces con un nuevo back-end antes de cambiar y alcanzar la producción.

4. Si no está haciendo un desarrollo nativo de IOS, es posible que esté utilizando algunos marcos de terceros como IONIC o Xamarin, lo más probable es que tenga que esperar a que actualicen sus bibliotecas si alguna actualización lanzada por apple.moreover es como un gran guerrero en un caballo lisiado

Muchos desafíos estarían en el futuro, se trata de acostumbrarse a ellos.

Objetivo-C, Swift sea lo que sea que realmente no importe, ambos tienen la misma dureza para aprender. Igual que los marcos, eso es solo una cosa de memoria / investigación.

La parte realmente difícil es crear una aplicación iOS realmente maravillosa. Puede crear una aplicación de menor complejidad en una o dos semanas, pero parecerá una mierda y la experiencia de usuario será mala. Cada característica que se te ocurra tiene un árbol exponencial de casos de uso que ni siquiera has pensado, y apuesto a que ni siquiera has comenzado a pensar en Accesibilidad o internacionalización. Nos guste o no, Apple HIG se basa en investigaciones concretas, así que tómese el tiempo para aprender las convenciones de la plataforma en torno a los elementos y las transiciones de la interfaz de usuario.

Entonces, sea lo que sea que esté pensando en hacer, piense nuevamente, bote el 50%, piense un poco más y bote un poco más. Luego, trabaje y cree la aplicación más fluida y fantástica que pueda. Pruébelo en personas reales, pruébelo en su abuelo vidente pobre. No tengas miedo de tirarlo todo y comenzar de nuevo.

¡Yo!

El mercadeo.

Debe aprovechar al máximo el conocimiento del mercado, el tiempo, las oportunidades de oportunidad y una intuición bien desarrollada.

He sido desarrollador de iOS por solo unos meses. Trabajo para esta empresa que crea aplicaciones para otras empresas como soluciones de marketing y demás. Dado que estas aplicaciones deben ser compatibles tanto con iOS como con Android OS, estoy teniendo dificultades para implementar características posibles en la plataforma Android pero limitadas en la contraparte de iOS. Estas cosas incluyen funciones de fondo limitadas y gestión de memoria más estricta.

Creo que las muchas cosas con las que se encontrarán los desarrolladores de iOS son las limitaciones adicionales en los permisos otorgados a las aplicaciones con respecto a las características del dispositivo.

Mis dos centavos,

1. Ya sea para usar storyboard o no. Muchas personas (por nombrar algunas, Big Nerd Ranch – Guías de desarrollo, capacitación y programación de aplicaciones móviles | Big Nerd Ranch) están firmemente en contra de ello, mientras que Apple ha estado presionando mucho para que lo usemos.
2. Cómo utilizar los instrumentos de manera efectiva para perfilar su proyecto. He estado desarrollando iOS desde 2011 y solo tengo un conocimiento limitado para usarlo para detectar pérdidas de memoria. Aparte de eso, no tengo idea de cómo los instrumentos me ayudarán.
3. Ya hay muchas aplicaciones geniales allí y la gente está acostumbrada a ellas. Así que a veces me siento frustrado porque ¿cómo puedo competir con eso o qué más puedo hacer (¡Lo han hecho todos!)?

Clientes que no entienden el proceso de desarrollo o no están dispuestos a darle tiempo para pulir la aplicación.

Lidiando con los 101 errores con UITextViews que han prevalecido desde la introducción de iOS7.

Las aplicaciones están desarrolladas principalmente para usuarios, lo que significa que debe ser fácil, simple y atractivo. El diseño y la funcionalidad son lo más importante en las aplicaciones. La mayoría de las aplicaciones son rechazadas por Apple debido al mal diseño o cualquier otra razón. Por lo tanto, asegúrese de que la aplicación esté diseñada de una buena manera.

yo diria
1. Aprendizaje Obj-c. Pero eso cambiará ya que ahora es rápido.
2. Desplazarse por XCode, es decir, si ha utilizado IDE que tienen mejores herramientas y son más amigables para los desarrolladores

Hacer una aplicación simple, hermosa y funcional.
Esto es lo más difícil.

Escribir el código y el diseño correctos en la aplicación