Cross-Platform en Mviles

Ana Silvia Gonzles Torres, 10194, Ingeniera en Ciencias de la Computacin y Tecnologas de la Informacin, UVG

I.

INTRODUCCIN

En computacin, Cross-Platform se refiere al desarrollo de software o hardware que es compatible con diferentes plataformas sin necesidad de hacer un desarrollo especfico para cada una de estas. Este trabajo se enfocar en el Cross-Platform para desarrollo mvil en las dos plataformas ms importantes en la actualidad, es decir para las plataformas Android y iOS. Se tomar como dispositivo mvil a los smartphones y tablets. En este trabajo se buscar explicar la arquitectura de cada una de las principales plataformas para telfonos mviles (Android y iOS), cmo funciona el desarrollo nativo (compilacin de aplicaciones o apps) y cmo funcionan diferentes herramientas para desarrollo CrossPlatform.

La importancia de los procesadores ARM en los dispositivos mviles es debido a su poca cantidad de transistores lo cual ofrece un consumo bajo de energa que es uno de los recursos ms limitados en los dispositivos mviles. Adems de su bajo consumo energtico, los procesadores ARM generan menos calor y por esta razn se estn haciendo ms populares en otras reas. (1) La arquitectura ARM est basada en la arquitectura RISC lo cual significa que incluye los beneficios de su arquitectura base, hay tres principales que son de suma importancia para el desarrollo en dispositivos mviles. La primera es que las operaciones de cargar y guardar se manejan por medio de registros y no por memoria. A esto se suma que las direcciones de carga y almacenamiento estn limitadas a uso solamente para contenidos de los registros y de instrucciones por lo tanto la generacin de direcciones es ms simple. El cdigo es corto. (2)

II. ARQUITECTURA DE MVILES En la actualidad, todos los dispositivos mviles utilizan la arquitectura ARM de 32 bits. Los procesadores ARM diseados con tecnologa RISC (Reduced Instruction Set Computing), lo cual quiere decir que buscan la optimizacin a la hora de llevar a cabo una instruccin. La arquitectura ARM se hizo popular entre los dispositivos mviles debido a su poco consumo de energa, factor importante que puede afectar de gran manera la forma en que se ejecuta el software en un dispositivo mvil ya que esta es ms limitada. (1)

III. PLATAFORMAS MVILES Una plataforma no es solamente el software sobre el cual estar corriendo el programa a desarrollar, la plataforma tambin incluye el hardware. Especialmente en los mviles, es importante tomar en cuenta el manejo del hardware debido a la gran variedad de dispositivos mviles que hay en el mercado. (3)

A. Android Los dispositivos Android trabajan bsicamente a partir de una pila de software la cual incluye el Sistema Operativo, Middleware1 y aplicaciones clave para el manejo del hardware. Esta pila est formada por 5 capas: 1) Aplicaciones Estas son aplicaciones nativas que han sido escritas en Java, incluyen cliente para correo electrnico, mensajera SMS, calendario, mapas, navegador de internet, contactos, entre otros.

A. Arquitectura ARM El procesador ARM fue creado con el objetivo de tener un procesador de alto rendimiento pero que consumiera pocos recursos, la primera versin de este sali en 1,983 por Acorn Proton y fue llamado ARM1. A finales de los 80 Apple empez a colaborar con esta empresa para crear procesadores para la Apple Newton y luego de esto muchas empresas importantes en la industria empezaron a interesarse en los procesadores ARM; en la actualidad son varias las empresas que crean o en algn momento crearon procesadores ARM, algunas de estas son: Sony, Samsung, Panasonic, Apple e IBM. (2)

Middleware: Es el software encargado de conectar una o varias aplicaciones con otro software y/o hardware.

2) Framework para aplicaciones Permite que los desarrolladores de aplicaciones puedan acceder al hardware del dispositivo, correr servicios en el background, agregar notificaciones, etc. Esto habilita la posibilidad de reusar componentes que ya han sido creados por otras aplicaciones e incluso reemplazar las aplicaciones nativas del dispositivo. 3) Libreras Las libreras nativas de Android estn escritas en C/C++ y estas pueden ser accesadas por los programadores a travs del framework. El fin de estas libreras es tener control sobre funciones bsicas tales como reproduccin multimedia, bases de datos locales, graficas 2D y 3D, etc. 4) Runtime Cada vez que se corre una aplicacin en Android, esta corre bajo su propio proceso. Esto se hace a partir de una mquina virtual Dalvik (se explicar ms sobre el proceso en las siguientes secciones) de modo que un dispositivo Android es capaz de correr varias mquinas virtuales al mismo tiempo. La mquina virtual Dalvik depende de un kernel2 de Linux para asegurar que el manejo de memoria sea ptimo. 5) Kernel de Linux Los servicios bsicos de Android, tales como seguridad, manejo de memoria, y manejo de procesos, son llevados a cabo a travs de Linux 2.6. (4) B. iOS El sistema operativo iOS corre en los dispositivos iPhone, iPod touch y iPad. El sistema operativo incluye las herramientas para poder manejar el hardware de los dispositivos lo cual es necesario a la hora que se desee desarrollar aplicaciones. Al igual que Android, iOS est diseado por capas. Los servicios bsicos para el funcionamiento del sistema operativo se encuentran en las capas ms bajas y las ms altas contienen la tecnologa que permite a los desarrolladores abstraer funcionalidades de las capas ms bajas, sin embargo estas siempre estarn disponibles. Las capas son las siguientes:

iOS. Las funcionalidades principales que cubren estos frameworks son: multitasking, ingreso por touch, notificaciones, gestos, servicios peer-to-peer, display por medios externos y mensajera. 2) Media Las tecnologas necesarias para manejar grficas, audio y video del dispositivo se encuentran dentro de esta capa. Generalmente el camino ms fcil para un programador es utilizar los frameworks que se encuentran en la capa Cocoa Touch, sin embargo habrn ocasiones en las que el procesamiento de multimedia es ms complejo y para esto se encuentran los frameworks que trabajan reas especficas del procesamiento multimedia. 3) Capa de Servicios Bsicos Estos son los servicios utilizados por el sistema y que la mayora de aplicaciones debe utilizar para poder correr en iOS, si no son utilizados directamente por la aplicacin lo ms probable es que algn componente sobre el cual este corriendo utilice uno de estos servicios. Los servicios bsicos de iOS incluyen herramientas que son necesarias en la fase de compilacin, principalmente para el manejo de memoria. 4) Sistema Operativo Base Aqu se encuentran todas las funcionalidades en base a las cuales estn construidos los frameworks de las capas superiores. Estas funcionalidades son utilizadas cuando el programador necesita lidiar con seguridad o comunicacin que involucre hardware externo. (5)

1) Cocoa Touch Esta capa contiene los frameworks que los desarrolladores necesitan para construir aplicaciones para
2

Kernel: Es la parte encargada de hacer el procesamiento de informacin del lado del hardware, une el hardware con el software. Esto incluye manejo de memoria y acceso a controladores.

IV. DESARROLLO NATIVO

A. Android Android posee el Android Software Development Kit (SDK) el cual incluye todas las libreras y herramientas necesarias para desarrollar en Android nativo. Dentro del SDK se incluye un emulador para correr las aplicaciones sin necesidad de pasarlas a un dispositivo real, el emulador est basado en QEMU (Quick Emulator) que se encarga de virtualizar hardware incluyendo el procesador ARM que es el corazn de los dispositivos mviles. (6) Figura 2 Oficialmente Android no cuenta con un IDE exclusivo o nativo para desarrollo de aplicaciones, hasta ahora cuenta con un plugin para Eclipse Android Development Tools (ADT) y este tambin es soportado por NetBeans. En el Google I/O 2013 hicieron el anuncio del Android Studio, es el nuevo IDE para desarrollo en Android el cual es gratis y por el momento se encuentra con posibilidad de acceso previo antes de que sea lanzado oficialmente. En la Figura 1 se puede observar cmo ser el Android Studio. (7)

Luego de que la aplicacin sea compilada se empaqueta en un archivo APK el cual incluye todo el cdigo del programa en Bytecode que se encuentra en archivos .dex (Dalvik Executable) los cuales pueden ser ejecutados por medio de una mquina virtual Dalvik. B. iOS Para poder desarrollar aplicaciones nativas de iOS es necesario utilizar una computadora Macintosh (esta puede ser reemplazada con otras opciones tales como mquinas virtuales) con procesador Intel y Xcode tools. Xcode contiene las herramientas para poder manejar proyectos, editar cdigo, crear interfaces y construir cdigo ejecutable, entre otras funcionalidades. Este IDE permite al desarrollador ejecutar la aplicacin en un simulador antes de ejecutarla en un dispositivo real. En la Figura 3 se puede observar una de las vistas de Xcode.

Figura 1 El ADT permite bajar las diferentes versiones de Android que se encuentran en el mercado hasta el momento, esto permite enfocarse en que el desarrollo funcione eficientemente en la versin que ms interese o hacer pruebas de compatibilidad con versiones anteriores a la versin que se tiene como target. (6) El lenguaje para desarrollo en Android tiene la misma gramtica que el de Java (pueden ser considerados los mismos lenguajes) pero no significa que haya compatibilidad entre ambas plataformas. En la Figura 2 puede verse un ejemplo de una clase sencilla implementada para Android.

Figura 3

Aunque el lenguaje para aplicaciones iOS sea Objective-C, Xcode es capaz de compilar cdigo escrito en C, C++, Java y Applescript. El cdigo que se encuentra en la Figura 4 muestra un ejemplo del constructor de una clase llamada ScaryBugData en Objective-C.

El primer paso est dividido en tres fases, la primera es la generacin de los archivos de Java a partir de los recursos (iconos, Strings, etc.) que utiliza la aplicacin para Android. Este primer paso se lleva a cabo con ayuda de una herramienta llamada aap la cual compila todos estos recursos a un solo archivo .java. Luego se hace la compilacin de las interfaces que se usen en el programa, estas son almacenadas con su mismo nombre solamente que la extensin es .java. Por ltimo se hace la compilacin final de los archivos .class que contienen el cdigo fuente con los otros generados en los pasos anteriores, se genera el Bytecode que incluye todas las libreras del API3 de Android. Lo siguiente es convertir el Bytecode de Java a Bytecode de Dalvik. Al terminar la compilacin, se utiliza la herramienta dx que convierte todos los .class a un solo archivo ejecutable .dex. Por ltimo, el ejecutable debe ser comprimido en un paquete APK. Con el fin de realizar este paso se utiliza la herramienta apkbuilder el cual empaqueta: El ejecutable .dex Los recursos (imgenes, sonidos, etc.) que utiliza la aplicacin Libreras nativas (9) Antes que los .class sean convertidos a .dex estos podran ser ejecutados en una JVM pero no seran compatibles con la MV Dalvik. Esta MV tiene una arquitectura de registros que es totalmente lo opuesto a la JVM ya que esta est basada en Stacks, tiene una Constant Pool de 32 bits para simplificar la interpretacin del cdigo, las instrucciones ejecutadas por la JVM son de 8 bits y las de la Dalvik son de 16 lo cual permite que s se puedan tener variables globales y mejore el proceso de interpretacin. Dentro del proceso de empaquetado a APK se lleva a cabo un paso llamado alineamiento el cual hace todas las instrucciones de 8 bits sean alineadas correctamente y de forma eficiente a instrucciones de 16 bits, esto se hace por medio de la herramienta Zipalign. (10) Este cambio de mquina de Stack a mquina de registro result ser de mucha importancia para Google ya que los procesadores ARM llegan a ser hasta 3 veces ms rpidos con aplicaciones para Android que con aplicaciones para Java.

Figura 4

El lenguaje de programacin que utilizan las aplicaciones nativas de iOS es Objective-C, este est basado en el lenguaje C por lo tanto es posible compilar un programa escrito en C con un compilador de Objective-C. Este es un lenguaje orientado a objetos y es utiliza un compilador GCC (ser explicado con ms detalle en las siguientes secciones). (5)

V. COMPILACIN NATIVA A. Android Android utiliza una mquina virtual Dalvik para ejecutar las aplicaciones en su sistema operativo. Los pasos de compilacin antes de que la aplicacin sea ejecutada en el dispositivo son los siguientes (mostrados en la Figura 5): El programa escrito en lenguaje nativo de Android o Java son compiladas a cdigo fuente Bytecode utilizando ya sea el IDE Eclipse o NetBeans. Los archivos .class son convertidos a .dex antes de ser instalados en el dispositivo. Los archivos .dex son empaquetados a un solo archivo .apk que ser el ejecutable ya en el dispositivo.

Figura 5 (8)

Application Programming Interface, es una librera que contiene la informacin sobre como estarn interactuando distintos componentes del software.

A partir de Android 2.2 la MV Dalvik posee un compilador en tiempo de ejecucin o JIT (Just-In-Time), esto quiere decir que el Bytecode generado (los archivos .dex dentro del .apk) ser traducido a lenguaje de mquina hasta que se est ejecutando el programa. De esta forma es posible hacer optimizaciones al cdigo fuente antes de ser ejecutado, es decir en su traduccin a Bytecode, permitiendo que la ejecucin sea ms rpida. (11) B. iOS Las aplicaciones para iOS son desarrolladas con el lenguaje Objective C el cual es compilado por GNU Compiler Collection (GCC). GNU es un sistema que soporta varios lenguajes de programacin, la mayora, derivados de C y una de las razones por la cual fue elegido como compilador para Objective C fue por su compatibilidad con la arquitectura ARM. (12) La sintaxis de este lenguaje de programacin est basada en C, por esta razn es posible insertar cualquier cdigo escrito en C y este ser ejecutado sin ningn problema. Objective C es un lenguaje orientado a objetos pero C no lo es, para complementar esto utiliza la sintaxis de SmallTalk. SmallTalk es diferente a otros lenguajes orientados a objetos como Java, C#, etc. gracias a su estilo de programacin, este no hace llamadas a mtodos sino enva mensajes. Los mensajes son interpretados por el objeto que est siendo receptor y lo hace en tiempo de ejecucin, esto permite que no exista la revisin de tipos y por lo tanto slo hasta que el programa se est ejecutando se podrn producir los errores los cuales son manejados por medio de excepciones. (13) Objective C tiene dos tipos de archivos; los .m son los que almacenan el cdigo con las implementaciones mientras que los .h son los que contienen las interfaces. (13) GCC funciona como cualquier otro compilador, luego de revisar el cdigo fuente pasa a la fase de generar el cdigo objeto. Para iOS el cdigo objeto que se utiliza es Mach-O y tiene la estructura que se muestra en la Figura 6.

Figura 6 En el archivo Mach-O, el encabezado contiene la informacin bsica sobre la arquitectura sobre la cual se ejecutar y las banderas utilizadas a la hora de ser ejecutado. En la siguiente seccin estn las instrucciones de carga, estas especifican la siguiente informacin: El espacio inicial del archivo en memoria Ubicacin de la tabla de smbolos Estado inicial de la mquina Nombres de libreras externas

En los siguientes segmentos se encuentra informacin sobre espacios de memoria, direcciones de memoria, etc. El ltimo de estos segmentos contiene la tabla de smbolos e informacin sobre libreras. (14) El cdigo objeto Mach-O que se genera tiene la extensin .o. Este archivo entra al ltimo proceso llamado Vinculacin (Linking). Aqu se toman todos los archivos .o generados y los empaqueta en un solo ejecutable, el ejecutable incluir otros archivos como libreras y recursos que necesita la aplicacin. (13)

VI. VENTAJAS Y DESVENTAJAS DEL DESARROLLO CROSSPLATFORM A. Ventajas Reduccin de costos debido a la rapidez de desarrollo adems que luego de que la aplicacin sea lanzada, se puede utilizar el mismo cdigo como base para dar mantenimiento y tener a los usuarios satisfechos en lapsos de tiempo cortos. Disponibilidad de plugins que facilitan el acceso a servicios y/o hardware como GPS. Generalmente las herramientas cross-platform tienen la posibilidad de integrar plugins que evitan que el desarrollador escriba cdigo para servicios bsicos que ya han sido implementados en incontables ocasiones. Soporte para servicios en la nube lo cual facilita al desarrollador poner a disposicin del pblico su aplicacin ya que no es necesario que cuente con toda la tecnologa necesaria para armar este negocio. Facilidad de compilacin. debido a que solamente se compila una vez, el desarrollo cross-platform ahorra a los desarrolladores que deban compilar varias veces un mismo producto.

VII. HERRAMIENTAS PARA DESARROLLO CROSSPLATFORM Existen tanto Engines como Frameworks para lograr este tipo de desarrollo, estos pueden utilizar un lenguaje de programacin diseado especficamente para la herramienta o adecuan uno que ya sea popular entre los desarrolladores. La mayora de herramientas, cualquiera sea su tipo, utilizan lenguajes para desarrollo web debido a su flexibilidad y popularidad. (16) A. PhoneGap PhoneGap es un Framework Open Source que permite crear aplicaciones para mviles utilizando lenguajes de desarrollo web (HTML, CSS y Javascript). Actualmente es capaz de compilar para las plataformas iOS, Android, Blackberry OS, WebOS, Windows Phone, Symbian y Bada pero est investigacin se enfocar nicamente en iOS y Android. Como se mencion anteriormente, una de las desventajas de trabajar con herramientas cross-platform es la limitacin que se puede tener con el hardware y algunos servicios que brinde el sistema operativo nativo. PhoneGap tiene estas limitaciones en algunas de las plataformas con las que trabaja, sin embargo para iOS y Android es capaz de utilizar todos los servicios y hardware que estas plataformas ofrecen y estn especificados en la Figura 7. (17)

B. Desventajas Desactualizacin en el framework de la plataforma original, esto pasa cuando, por ejemplo, Google o Apple agregan una funcionalidad a su framework. Por obvias razones la herramienta no tendr acceso inmediato a esta nueva funcionalidad y por lo tanto el desarrollador deber esperar hasta que esta sea aadida a ambiente cross-platform El tiempo de ejecucin suele ser ms lento que cuando se trata de una aplicacin nativa. El uso del hardware encargado de mostrar y procesar grficas es limitado y generalmente se debe usar alguna herramienta que incluya el ambiente de desarrollo. Cuando hablamos de dispositivos mviles nos enfrentamos a una gran variedad, por esta razn el diseo es de suma importancia y una aplicacin en Android no es lo mismo que una aplicacin en iOS. El cross-platform elimina la posibilidad de hacer un diseo eficiente para cada una de las plataformas. El desarrollador debe pagar la herramienta para poder colocar la aplicacin en venta. Este es el caso de la mayora de herramientas cross-platform.

Figura 7

(15)

Cada una de los servicios o funcionalidades que se presentan en la Figura 7 estn integradas por diferentes APIs de PhoneGap (uno por cada elemento). (18) La forma en que trabaja PhoneGap es llamada hibrida debido a que no genera exactamente una aplicacin nativa para el dispositivo sino que es un WebApp4 que hace llamadas a las APIs nativas de la plataforma. Esto significa que en realidad el contenido visual que muestra una aplicacin desarrollada con PhoneGap no utiliza los frameworks de la interfaz de usuario que posee la plataforma nativa sino que lo hace a travs de vistas web. Debido a que PhoneGap s hace llamadas a las APIs nativas de la plataforma, se le permite al desarrollador que dentro de su cdigo ingrese llamadas directas a las APIs nativas que puede ser de utilidad para un manejo ms completo de los procesos. (19) El proceso de compilacin para PhoneGap consta de dos etapas, la primera se realiza desde el IDE y la segunda en la nube con la ayuda de los servidores de PhoneGap. La primera parte que se lleva a cabo en el IDE es simplemente el escaneo y parseo del cdigo fuente, este cdigo fuente incluye archivos HTML, Javascript CSS y plugins de PhoneGap. Estos archivos son comprimidos en una carpeta ZIP y subidos al constructor de PhoneGap en la nube para iniciar con la segunda etapa. (20) El PhoneGap Build se encarga de traducir todas las llamadas de las APIs de PhoneGap a llamadas de APIs nativas dejando todo lo visual como una aplicacin web que hace las llamadas a los procedimientos nativos, luego empaqueta todos los archivos al ejecutable indicado para cada plataforma y lo habilita para su descarga e instalacin. La traduccin a llamadas a APIs nativas las hace por medio del SDK de cada plataforma al igual que la generacin del archivo ejecutable. En la Figura 8 se muestra un diagrama con el proceso de compilacin y en la Figura 9 cmo se dividen los respectivos SDKs. (20)

Figura 8

Figura 9 En la Figura 10 se puede observar cmo interacta la aplicacin con el dispositivo. Todo lo relacionado con la interfaz se hace de forma web es decir con el HTML y CSS del cdigo fuente, luego el Javascript hace las llamadas a las APIs nativas que dan una respuesta y esta se muestra de nuevo en forma web. (20)

Web Application, es un conjunto de recursos (HTML, conexiones a servidor, etc.) que llevan a cabo una tarea por medio de una conexin a un servidor local o remoto.

manejo de la interfaz grfica. Pipetool se encarga de unir el cdigo objeto con estas libreras, puede ser comparado con el proceso de Linking en iOS con la diferencia que Pipetool tambin funciona como un compilador. La funcin de compilador la realizar al optimizar el cdigo generado luego de hacer el linking y despus genera una versin binaria de MoSync IL o cdigo Java dependiendo de cul sea su uso final. (22) En caso se genere cdigo Java, este ser compilado ya sea por el ambiente J2ME o por la mquina virtual Dalvik en caso se desee generar Bytecode para Android. Si en caso se genera MoSync IL, este se asigna al ambiente indicado para la plataforma en la cual se desee ejecutar la aplicacin. El cdigo binario MoSync es traducido al cdigo objeto de la plataforma deseada y este ya est listo para ser ejecutado. (22) Figura 10

B. MoSync A diferencia de PhoneGap, MoSync es un SDK completo que se integra a Eclipse para poder crear aplicaciones, estas son escritas en C/C++, HTML5 y Javascript. Otro factor que diferencia MoSync de PhoneGap es que este SDK s genera aplicaciones nativas para cada plataforma mvil. Las plataformas que este soporta son Android, iOS, Windows Mobile Classic, Windows Phone, Symbian, Moblin y Java Mobile. (21) El proceso de compilacin utilizando MoSync y ejecucin de la aplicacin en la plataforma mvil estn descritos en la Figura 11.

Figura 11 Al igual que Objective-C, MoSync utiliza el compilador GCC que ha sido modificado para que genere cdigo objeto MoSync que luego puede ser ejecutado por la plataforma virtual de MoSync. Esta plataforma est basada en registros para facilitar una re-compilacin hacia el cdigo de cada plataforma o hacia cdigo de ms alto nivel en lugar de cdigo objeto. (22) Las libreras de MoSync y el cdigo objeto generado por GCC entran a Pipetool. Las libreras contienen la informacin sobre procedimientos bsicos y

VIII. BIBLIOGRAFA 1. Espeso, Pablo. ARM, La "Navaja Suiza de los Procesadores". Xataka. [En lnea] 24 de diciembre de 2012. http://www.xataka.com/componentes-de-pc/arm-la-navajasuiza-de-los-procesadores-1. 2. ARM Ltd. ARM Processor Architecture. ARM. [En lnea] 2013. http://www.arm.com/products/processors/instruction-setarchitectures/index.php. 3. Bramble, Cate. Definition Platform. Search Server Virtualization. [En lnea] Septiembre de 2006. http://searchservervirtualization.techtarget.com/definition/pl atform. 4. Android, Inc. About Android. Developer Android. [En lnea] http://developer.android.com/about/versions/index.html. 5. Apple Inc. iOS Technology Overview. Developer Apple. [En lnea] 2012. http://developer.apple.com/library/ios/documentation/Misce llaneous/Conceptual/iPhoneOSTechOverview/iPhoneOSTe chOverview.pdf. 6. Android Open Source Project. Android SDK. Developer Android. [En lnea] http://developer.android.com/sdk/index.html. 7. Android Open Source Proyecto. Getting Started with Android Studio. Developer Android. [En lnea] 15 de mayo de 2013. http://developer.android.com/sdk/installing/studio.html. 8. Android Open Source Project. Building and Running. Developer Android. [En lnea] http://developer.android.com/tools/building/index.html. 9. Ostermeier, Daniel y Sankey, Jason. Understanding the Android Building Process. A Little Madness. [En lnea] 27 de junio de 2010. http://www.alittlemadness.com/2010/06/07/understandingthe-android-build-process/. 10. Queru, Jean-Baptiste. Zipalign: an easy optimization. Developer Android. [En lnea] 28 de septiembre de 2009. http://android-developers.blogspot.com/2009/09/zipaligneasy-optimization.html. 11. Bornstein, Dan. Dalvik JIT. Developer Android. [En lnea] 25 de mayo de 2010. http://androiddevelopers.blogspot.com/2010/05/dalvik-jit.html. 12. Apple Inc. GNU C/C++/Objective-C 4.2.1 Compiler User Guide. Developer Apple. [En lnea] https://developer.apple.com/library/ios/#documentation/De veloperTools/gcc-4.2.1/gcc/Invoking-GCC.html. 13. DeVoe, Jiva. Understanding the Compilation Process. Objective -C. s.l. : Wiley Publishing Inc, 2011, pg. 403. 14. Apple Inc. OS X ABI Mach-O File Format Reference. Developer Apple. [En lnea] 2 de abril de 2009. https://developer.apple.com/library/mac/#documentation/de velopertools/conceptual/MachORuntime/Reference/referen ce.html.

15. Warren, Christina. The Pros and Cons of CrossPlatform App Design. Mashable. [En lnea] 16 de febrero de 2012. http://mashable.com/2012/02/16/cross-platformapp-design-pros-cons/. 16. O'Dell, Jolie. 5 Cross-Platform Mobile Development Tools You Should Try. Mashable. [En lnea] 10 de agosto de 2010. http://mashable.com/2010/08/11/cross-platformmobile-development-tools/. 17. Adobe Systems Inc. Supported Features. PhoneGap. [En lnea] http://phonegap.com/about/feature/. 18. . API Reference. PhoneGap Documentation. [En lnea] http://docs.phonegap.com/en/2.7.0/index.html. 19. Trice, Andrew. PhoneGap Explained Visually. PhoneGap. [En lnea] 2 de mayo de 2012. http://phonegap.com/2012/05/02/phonegap-explainedvisually/. 20. Pukhalski, Ilya. How PhoneGap Really Works. SpeackerDeck. [En lnea] 12 de febrero de 2013. https://speakerdeck.com/witchfinderx/how-phonegapreally-works. 21. MoSync AB. MoSync SDK. MoSync Developer. [En lnea] 2013. http://www.mosync.com/docs/index.html. 22. Mosavian, Ali. Under the Hood. MoSync. [En lnea] 14 de enero de 2010. http://www.mosync.com/blog/2010/01/under-hood.