Comparative Evaluation of iOS and Android API’s

AbstractThe purpose of this research is to compare two API’s provided by two main mobile application development platforms. Categorized aspects are user interface, device compatibility, security and general architecture.  Many developers/companies develop applications on different platforms to get most of the customers, but that comes with problems during development processes.

This paper includes detailed comparisons of the main features of each API, which aims to facilitate development processes of the application with the same features on different platforms.

I.Introduction

In the last decade, mobile phones has evolved remarkably from communicating devices to little computers with the same purposes of using: browsing on the web, social networks, online banking, and more. As the devices are being improved gradually, the companies are trying to develop smarter mobile applications to make the devices more useful. There are two main development platforms, spread because of their popularity and divergent approaches, iOS and Android. [1] In this paper, it will be compared the API’s that are supplied by Apple and Google, and how these API’s are affecting the mobile application development processes.

II.User Interface

  • Android

Android has a hierarchy    of Views                and ViewGroups that can be arranged in a simple or complex way. Graphical Layout (Figure 2) can be used for design in the layout design tool built-in the IDE or in XML file, view properties can be manageable by coding. Drag-drop feature is available while arranging objects on the screen.

fig1

Fig. 1: Android Layout Design Preview

Main difference from iOS API, Android has Activities and Fragments in the applications. Applications formed by many activities and every activity may behave independently from each other. Developers can use fragments as components on the screen which consists of many sub-objects like buttons, labels etc., and these fragments can also be used in different activities as components. That feature provides reusability in designing and coding, which results as time saving for the developer.

Android provides “Widgets” for the end-user. Widgets are an essential aspect of home screen customization [2], which can give a view of the applications data, and also give access to the application from the home screen.

fig2

Figure 2: Widget Example of “1Weather” App

Beyond the prebuilt UI components that provided in the Android application framework, it allows the developers to code customized components with using the prebuilt View and Viewgroup subclasses. This feature gives all control over the appearance and functions of a screen element. Developers can define their own customized UI components, and use them in their projects. For example, a customized submit button can be defined in the project, and can be used after that.

  • iOS

iOS has a development architecture with Models, Views, Controllers (uses MVC), thus Xcode can separate design and interface coding from backend functions.

  • Models: Works on logic and core data. Any change in the views does not need to revise the background services.
  • Views: The interface part of the application that intended to the end-user.
  • Controllers: Acts as intermediary between model and view. Objects connect to a ViewController which communicates with the Model.

As a result; models manage the data and the functions background, views interact with the user and viewcontrollers communicate two of these.

Storyboard is the tool used for designing user interfaces. In the screen, it allows to drag-drop the items from “The Objects Library” and uses them on the screen. Storyboard allows developers to create transitions between screens. This feature is the most beneficial part for iOS developers on the design process that works integrated with iOS API.

fig3

Figure 3: iOS Storyboard Preview

III. Device Compatibility

  • Android

Device compatibility is one the main problems that Android API is dealing with. There are many different manufacturers that produce mobile phones have Android OS, so that brings a diversity of devices with different features like screen size, variety of buttons, OS differences etc. Major differences between devices are the screen sizes and also OS version differences. Even though the Android API gives supports to solve these problems, there are many things that the application developer has to considerate about.

  •  iOS

Apple produces iPhone models with most common specifications, but in some versions of iPhone there are significant screen size difference between some models. (eg. iPhone 4/4S: 3.5 in – iPhone 5/5S: 4 in  [7,8]) As the models change, this caused many of the applications have to be revised. In newer iOS versions, API supports the changes for new device features. Also the new OS is forced to update, so that results same version of the OS by the most of the users except with the older versions of iPhone and iPads.

IV. Security

Security is a big issue which is even enough to discuss in another research, but main parts will be discussed as General Issues, Malware, Permissions, Restrictions and Application Submit Process.

  • General Issues

Both Android and iOS has a sandboxing feature for every application that installed. Application Sandbox includes a limited portion of the hard disk that assigned for the application and gives access to device features (via user permissions). Android API allows the developer to decide the files of the application are accessible by the other applications. This storage mechanism controlled by Content Providers, thus the developer can define the controls in manifest file to give access or not to the other applications. iOS does not have this control, but it gives the ability to share the files on cloud (iCloud), so the application that installed on different devices can work on the same application files.

In general, Android has a policy to give most of the control on the features to the developer, unlike iOS has many restrictions and features that are controlled by OS mostly. In common, these are the security features provided by two APIs; [15]

  • App Permission Notification
  • App Vetting Process (to publish the application in the store)
  • App Digital Signing
  • App Binary Encryption
  • App Sandboxing
  • Data Encryption
  • Damage Control
  • Address Space Layout Randomization

 

  • Malicious Threats

In order to prevent malicious attacks on mobile phones, both Android and iOS use review processes and user permissions. The most malware application attacks are collecting user information and sending premium-rate SMS messages. [15] Other attacks are named as credential theft, SMS spam, search engine optimization fraud, and ransom. There is no definite answer which OS defends user against vulnerable attacks better, but we can say each API has many solutions for every case.

There are three types of threats: malware, grayware, and personal spyware. [15]

Malware applications use two methods, making user to install the malicious application or remote access to the mobile phone using the device’s vulnerability. Grayware are the legal applications that are published in the App Store or Play Store, which collect the user data to use in user profiling or marketing. This type of applications does not harm users, collected data is used by the companies only. Personal spywares are used for collecting user data and transferring it to another device.

Each API has own methods and solutions against these attacks by the applications, it will be discussed as permissions and restrictions by the OS in the next topics.

  • Android

Android users can download applications from any resource. This entails security vulnerability of some cases, because within flexible boundaries of development on Android, developers may benefit with malicious applications. For the applications in Google Pay, Google has a review process for submitting applications [12], not much detailed as the Apple review process. Review process consists of default controls as memory management, personal info access etc. Before installing an application, an app permission notification is shown to the user so that the user would know which system features will be used by the application. That is a precaution for the malicious applications.

  • iOS

Malware in iOS is prevented mostly during the review process to submit the application to App Store. [6] The applications must follow Apple standards like Objectivity, Consistency as Transparency to get “Approved”. That concludes a strict review process does not allow developers to use malware in their applications, otherwise the application is “Rejected”.

Users cannot install from anywhere else but App Store. On the other hand jailbreaking iOS gives the ability to the user to install applications from unknown resources, which depends on user responsibility.

  • Permissions

  • Android

Android has a core element of security model that is called manifest file. This file includes all the necessary information to the Android platform for running the application. Developer defines the permissions that the application needs in this file and before installing it, user is asked to accept for these permissions. Please refer to [6] to find the complete list. These permissions have control for two states: (a) the way the application interacts with the Android API to use resources, and (b) the way the API and the other applications interact with the application’s component to use. [18]

Users cannot choose which permission to give separately, all of them has to be accepted before installing the application. Some researches claim that Android is better since the application shows all permissions list to the user before installing, so the user can choose to install or not. For example, if a sound effect application requesting access to contacts, there is probably a reason to think before installing the application. There is only one problem with the permissions list in Android applications, there is no option like choosing separately between the permissions, user has to accept all of them to continue installing.

  • iOS

An iOS application asks to use location data, push notifications, contacts reminders, calendars and photos. It asks for user permission, when it is required, from the user runtime consent for the first time the service is called.  When the method called, system asks the user to allow it. With iOS 7, user is asked for permission of microphone and motion activity also. Unlike Android applications, iOS API does not ask for permissions just before installing the applications. In contrast, iOS allows users to give permissions separately while running the application, which leads user can decide for each permission.

  • Restrictions

  • Android

Android OS allows applications to run services in the background, so developers can develop services with Android API. Services watch some conditions that defined and respond in actions without user starting the application. These services run under OS controls, so that memory management and preventing suspicious requests can be provided by the OS.

In compare to iOS, Android is more open. There are a few issues listed below as more free if it is compared to iOS;

  • Android apps can publish data, which other apps can consume. As an example, call history is available to reach from any application.
  • Apps can send notifications and other applications can subscribe to them. For example any application can subscribe to status change of outgoing and incoming calls.
  • Apps can invoke functionality from other apps just in a few lines of code.

 

  • iOS

It is allowed to prepare services that run in the background on Android OS, on the contrary, iOS does not provide to run background services. Services may use memory excessively, and may work as malicious programs which can cause security vulnerabilities and user experience problems. For that reason, iOS does not allow background services. Rather than this, there are some issues that handled by OS such as location services. iOS does not allow the developer to prepare some code to run in the background to monitor the location of the user via the application. Instead, the operating system is always (in case the user allows this feature) tracking the location of the mobile device, and triggers the code of the application that prepared by the developer and run it when the device enters an area that defined. In Android, OS allows the developer to run the services background, so it can collect its own data from system resources. Also because of iOS sandbox for applications, there are very limited possibilities                for communicating with the other applications.

  • Application Submit Process

  • iOS

Getting the application published in the App Store is the most tedious part for developers. [9] This process could take so long because review includes even the slightest errors. Although this approval duration (Apple’s vetting process) causes concerns about getting rejected, review teams report back with detailed reasons about the rejection which leads the review and improving mobile development skills for the developer. Also that maintains for the problems which can be skipped by developers and also testers. This review process leads to determine malware and potentially malicious in the applications, that is how Apple handles security issues as a precaution before accepting the applications to the App Store.

  • Android

In comparison with iOS review process, Android has an easy duration for submitting an application to Play Store. In App Store, it can take 3 or 4 days finishing the review, but in the Play Store it almost takes 5-6 hours to get your application listed in the store. Play Store has check list [10] for submitting application to the store, but not detailed review process therefore that may cause malicious applications to appear on the lists.

In addition to, Android application is required to be digitally signed by the developer to get published in the Play Store. However, signing the application by the certificate of the developer is mandatory, but it is not compulsory that the certificate has to be signed by a trusted certificate authority. Thus this leads anonymous developers to sign their applications as potential attackers.

V. General Architecture

  • Configuration

  • Android

Android app configuration is simple and elegant to work with, which is handled by a single manifest file and Eclipse builds the application in its entirety every time you save any file in the project.

  • iOS

iOS configuration is a little messy to work around with macros, header files, projects and targets, schemes, build configurations, build settings etc.

  • Programming Language

 

  • Android

Android apps are written in Java, which has the ability of using garbage collector and better stack traces.

  • iOS

iOS applications are written in Objective-C, and although syntax of Objective-C is much different from other object oriented languages it has many advantages in compare to Java for mobile application programming. It has blocks, categories and also it does not require to include try/catch exception-handling code blocks for error handling like in Java.

 

  • Development Environment

It is still available writing code in a notepad and command lines, yet still so many coders doing that, developers can use an integrated development environment for iOS and Android.

 

  • Android

Eclipse is used for Android development with customized Android plugins, but it need more time to be used effectively. The biggest problem with the usability of the IDE is Android emulator. It is still a big problem to develop application with an emulator that loads in approximately 10 minutes, and have many problems with the IDE when debugging.

  • iOS

Xcode is a fast, powerful IDE that has been developed by Apple, at it makes easy and joyful to develop an application for iOS devices. The debugger works usually seamlessly, and the simulator is fast and responsive.

 

  • Search

  • Android

Adding a search feature to the Android application is simpler/possible in compare to iOS. Developer can create a virtual table, using the FTS3[21] feature of SQLite that stored a user’s tasks.

  • iOS

Core data in iOS does not provide full text search natively, so an iOS developer has to implement a basic functionality through using “Like” clauses of SQL.

VI. Conclusion

In conclusion, as we discussed in main differences of two API, each of them has positive and negative aspects especially according to the developers. UX design is easily done using Storyboard of iOS, on the other hand, Android gives control of design by using visual designer and XML formatting together. Android API has fewer restrictions which seem that security has to be handled by developer mostly, nevertheless iOS API gives less control to the developer and has some strict restrictions.  Some resources claim that Android API is more secure because of open source development, against that iOS API does not allow the developers an open source development, but it gives almost more features than API within the restrictions and controls by the OS which results more secured applications to the end-user.

VII. References

[1] Mark H. Goadrich and Michael P. Rogers, “Smart Smartphone Development: iOS versus Android”, SIGCSE ’11 Proceedings of the 42nd ACM technical symposium on Computer science education Pages 607-612, March 2011

[2] Android Developers Reference – Widgets http://developer.android.com/design/patterns/widgets.html

[3] Neuburg, M.  2014. iOS 7 Programming Fundamentals. O’Reilly.

[4] Meier, R.  2010. Professional Android 2 Application Development. Wrox.

[5] M. Linares-Vásquez, G. Bavota, C. Bernal-Cárdenas, M. Di Penta, R. Oliveto, D. Poshyvanyk, “API Change and Fault Proneness: A Threat to the Success of Android Apps”, ESEC/FSE 2013: Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering, August 2013

[6] Android Developers Reference – Manifest.Permission. Retrieved from http://developer.android.com/reference/android/Manifest.permission.html

[7] Wikipedia – iPhone 5, retrieved from http://en.wikipedia.org/wiki/IPhone_5

[8] Wikipedia – iPhone 4, retrieved from http://en.wikipedia.org/wiki/IPhone_4

[9] Apple – App Review, Retrieved from

https://developer.apple.com/app-store/review/

[10] Android Developers Reference – Launch Checklist.

http://developer.android.com/distribute/googleplay/publish/preparing.html

[11] Jin Han, Qiang Yany, Debin Gaoy, Jianying Zhou, Robert Dengy, “Comparing Mobile Privacy Protection through Cross-Platform Applications”, Policies for Distributed Systems and Networks (POLICY), 2012 IEEE International Symposium on, July 2012

[12]  “Trend Micro: Android much less secure than

iPhone,” electronista News, January 2011. http:

//www.electronista.com/articles/11/01/11/trend.micro.warns.

android.inherently.vulnerable/.

[13]  “Why Android App Security Is Better Than

for the iPhone,” PCWorld News. August 2010.

http://www.pcworld.com/article/202758/three_reasons_why_android_app_security_better_than_iphones.html

[14] Jin Han, Qiang Yany, Debin Gaoy, Jianying Zhou, Robert Dengy, “Comparing Mobile Privacy Protection through Cross-Platform Applications”, Policies for Distributed Systems and Networks (POLICY), 2012 IEEE International Symposium on, July 2012

[15] Adrienne Porter Felt, Matthew Finifter, Erika Chin, Steven Hanna, David Wagner, “A Survey of Mobile Malware in the Wild”, SPSM ’11 Proceedings of the 1st ACM workshop on Security and privacy in smartphones and mobile devices, October 2011

[16] Jianying Zhou , Mobile Platform and Application Security, KACST IT’13, Riyadh, Saudi Arabia, November 19, 2013

[17] Minzhe Guo, Prabir Bhattacharya, Ming Yang, Kai Qian, Li Yang,

Learning Mobile Security with Android Security Labware, SIGCSE ’13 Proceeding of the 44th ACM technical symposium on Computer science education, June 2013

[18] Smartphone security evaluation – the malware attack case,

Alexios Mylonas, Stelios Dritsas, Bill Tsoumas, Dimitris Gritzalis, SECRYPT, 2011

[19] “iOS vs. Android Development Comparison”  http://www.passion4teq.com/articles/ios-android-development-comparison-1/

[20] “Android vs. iOS Development: Fight!” http://techcrunch.com/2013/11/16/the-state-of-the-art

[21] “SQL Lite FTS3 and FTS4 Extensions” http://www.sqlite.org/fts3.html

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s