¿Y si nos rechazan la aplicación?

Ocurre, incluso con todo bien hecho, y se responde con el motivo delante. Lo que de verdad reduce los rechazos es enviar la ficha de privacidad ajustada a lo que la app recoge en realidad, y eso solo se puede hacer si se sabe qué recoge cada librería que lleva dentro.

¿React Native o desarrollo nativo?

React Native cuando las dos plataformas comparten casi todo, porque abarata el mantenimiento; nativo cuando hay rendimiento gráfico o funciones muy pegadas al sistema. Se decide con vuestro caso delante y queda escrito en el presupuesto, para que la elección no aparezca como sorpresa a mitad del proyecto.

¿Quién publica las actualizaciones cuando ya no trabajemos juntos?

Vosotros o quien elijáis. Las cuentas de tienda están a nombre de vuestra empresa y el procedimiento de publicación queda escrito con capturas, paso a paso. Es media hora de documentación que ahorra semanas el día que cambia el equipo, y casi ningún proveedor la escribe.

APPS WebCoding · Berlín

Desarrollo de apps en Berlín

Aplicaciones iOS y Android para empresas alemanas. Es el único de los nueve servicios donde no se puede evitar depender de un tercero, así que el trabajo consiste en decidir hasta dónde le dejáis entrar.

Pide presupuesto sin compromiso WhatsApp directo

Respondemos el mismo día · Presupuesto en 24 h · Agencia con sede en Vilanova i la Geltrú

Aplicaciones Móviles en Berlín

Cómo trabajamos en Berlín

El mismo nivel técnico y de proceso que aplicamos en proyectos de cualquier escala. Lo que cambia es el conocimiento del mercado local.

Un desarrollador de WebCoding trabajando con portátil y monitor en la oficina

Apple y Google ponen las reglas y no se negocian

La comisión, las normas de revisión y los plazos los decide otro, y cambian cuando ellos quieren. Conviene contar con eso desde el presupuesto en lugar de descubrirlo con una fecha de lanzamiento ya comprometida. Quien os diga que eso se gestiona no ha publicado muchas aplicaciones.

La lógica en vuestro servidor, la app como cliente

Precios, reglas de negocio y datos viven en una interfaz de programación vuestra; la aplicación pinta y envía. Así una norma nueva de tienda obliga a cambiar la app, no el producto, y esa misma interfaz sirve después una versión web sin volver a construir el mismo trabajo por segunda vez.

Cada librería de terceros se justifica o se quita

Analítica, notificaciones, informes de errores, publicidad. Cada una es código ajeno dentro de vuestra aplicación, una línea más que declarar en la ficha de privacidad y algo que puede romperse en la próxima versión del sistema operativo. Revisamos la lista una por una: varias se quedan, pero por una razón concreta.

Una versión web para lo que no cabe en la tienda

Hay funciones que las tiendas no admiten y ventas por las que cobran comisión si ocurren dentro. Tener el mismo servidor detrás de una web permite mover ahí lo que convenga sin duplicar el desarrollo. No se trata de esquivar la tienda, sino de no depender de ella para absolutamente todo.

Resolvemos dudas