Android works on which platform

Android vs iOS: Which Platform to Build Your App for First?

Deciding whether to build a business app for Android or iOS (Apple) depends on 5 factors: your audience, project timeline, desired app features, app maintenance budget, and revenue goal. We compiled statistics on these factors to help you choose — android vs iOS.

Feb 22, 2018 · 6 min read

If you’re building an app, developing for iOS or Android is one of the first decisions you need to make.

While your goal may be to launch on both platforms eventually, it is risky and expensive to build an app for both iOS and Android simultaneously.

Instead, most developers choose to build an app for one platform to start and then launch the app on the other platform later — once the first version of the app is established and successful.

How do you decide whether to launch your app on Android or iOS first?

There are pros and cons to both platforms, but ultimately, the choice comes down to 5 factors:

• Audience
• Timeline
• Desired features
• Budget for maintaining your app
• Revenue goal

Building an App for Android or iOS Depends on Your Audience

For example, Android devices have the greatest global market share. However, Apple dominates the App Store for customer spending.

Consider your target audience’s geographic and demographic characteristics when deciding which platform to develop for first.

If you’re targeting a broad global audience, Android may be your best bet.

If your audience is in Western Europe or North America, or if you’re an e-commerce or enterprise app, Apple may be a better choice.

Android Best for Audience in Up-And-Coming Markets

• Android is dominant in global up-and-coming markets, including in Asia, Africa, and Latin America.
• Android users are more likely to work in technical jobs.
• Slightly more men prefer Android than iOS.

iOS Best for Affluent, Young Audience in Western Europe, Australia, North America

• iPhone users tend to be more affluent, earning 40% more than the average Android user.
• iOS users tend to be younger, with a greater share of the 18–24-year-old market.
• Women are more likely to use iPhones than Android.
• Apple users are more likely to have higher education degrees.
• Apple users tend to be in professional and managerial jobs.
• iOS has more penetration in the enterprise market, thanks to a reputation for better security.
• iOS leads in Western Europe, Australia, and North America.
• Apple users tend to be more engaged with their devices and spend more on apps.
• iOS users are more likely to shop and make purchases using their mobile devices.

Making an App for iOS is Faster and Less Expensive

It’s faster, easier, and cheaper to develop for iOS — some estimates put development time at 30–40% longer for Android.

One reason why iOS is easier to develop for is the code. Android apps are generally written in Java, a language that involves writing more code than Swift, Apple’s official programming language.

Another reason is that Android is an open source platform. A lack of standardization means more devices, components, and software fragmentation to account for.

Apple’s closed ecosystem means you’re developing for a few standardized devices and operating systems.

That said, the Apple App Store has stricter rules and quality expectations and a longer review process, so it may take longer for apps to be approved. Your app may even be rejected if it’s not up to Apple’s standards.

Developing an App for Android Allows More Flexibility With Features

What features will you offer through your business app? Because Android is open source, there’s more flexibility to customize your app — building the features and functions that your audience wants.

Of course, this open environment means Android is more susceptible to pirate apps and malware.

Apple is generally perceived as being more secure, due to its closed nature, which is largely why iOS has a larger audience in the enterprise market.

Maintaining App on Android or iOS Is Easier If Users Update OS

Developing for Android may mean spending more time ensuring that your app remains compatible with the platform and avoiding bugs and crashes for users running older operating systems.

Apple users are more likely to update their operating system.

Monetizing Your App Depends on Likelihood of Making Purchases on iOS or Android

If app monetization is one of your goals, there are some key platform differences to be aware of.

Android users tend to be less willing to pay for apps than iOS users, so free apps with in-app ads are more common.

Some other key app monetization differences include the following:

• Apple users are more likely to make in-app purchases and spend more on them.
• Apple users are more likely to pay for apps, except in one category — utility apps. Android outperforms when it comes to utility apps.
• Shopping apps generate the most revenue, and North America leads in sales.
• Asian users spend 40% more on in-app purchases, and China is the biggest driver of iOS revenue.
• Both Google and Apple are pushing subscriptions and offering developers a larger cut of the revenue.

The takeaway: If you want to monetize your app without ads, whether through subscriptions, freemium models, or in-app purchases, then Apple may be your best bet. The same applies to e-commerce apps.

However, revenue from Android apps is growing. Though Apple is expected to remain the dominant App Store, Google Play and third-party Android stores combined are expected to overtake the App Store in terms of revenue.

Android vs Apple: Choose One Platform to Develop for First

Where your audience lives, who they are, the features they want, and your development timeline and budget determine whether you should build a business app for Android or iOS first.

If you need to build a minimum viable product quickly and cheaply, then iOS may be the way to go.

Similarly, if you have want to make money with your app or build an e-commerce app, look to iOS.

However, if you’re targeting global or emerging markets, especially in Asia and Latin America, or if your app involves features that Apple doesn’t support, then Android is your best bet.

Whichever platform you choose, once you’ve worked out the kinks and built a user base on your initial platform, you may find that users on the other platform begin clamoring for a version of your app.

When this happens, it’s a sign that it’s time to build another version of your app for the other platform.

Need help finding an Android or iOS app developer? We create shortlists of the top 15 developers for each platform to help you find the best match:

This article was published on The Manifest on February 22, 2018 and was written by Ashley MacQuarrie.

Источник

Как работает Android, часть 1

В этой серии статей я расскажу о внутреннем устройстве Android — о процессе загрузки, о содержимом файловой системы, о Binder и Android Runtime, о том, из чего состоят, как устанавливаются, запускаются, работают и взаимодействуют между собой приложения, об Android Framework, и о том, как в Android обеспечивается безопасность.

Немного фактов

Android — самая популярная операционная система и платформа для приложений, насчитывающая больше двух миллиардов активных пользователей. На ней работают совершенно разные устройства, от «интернета вещей» и умных часов до телевизоров, ноутбуков и автомобилей, но чаще всего Android используют на смартфонах и планшетах.

Android — свободный и открытый проект. Большинство исходного кода (который можно найти на https://source.android.com) распространяется под свободной лицензией Apache 2.0.

Компания Android Inc. была основана в 2003 году и в 2005 году куплена Google. Публичная бета Android вышла в 2007 году, а первая стабильная версия — в 2008, с тех пор мажорные релизы выходят примерно раз в год. Последняя на момент написания стабильная версия Android — 7.1.2 Nougat.

Android is Linux

По поводу такой формулировки было много споров, так что сразу поясню, что именно я имею в виду под этой фразой: Android основан на ядре Linux, но значительно отличается от большинства других Linux-систем.

Среди исходной команды разработчиков Android был Robert Love, один из самых известных разработчиков ядра Linux, да и сейчас компания Google остаётся одним из самых активных контрибьюторов в ядро, поэтому неудивительно, что Android построен на основе Linux.

Как и в других Linux-системах, ядро Linux обеспечивает такие низкоуровневые вещи, как управление памятью, защиту данных, поддержку мультипроцессности и многопоточности. Но — за несколькими исключениями — вы не найдёте в Android других привычных компонентов GNU/Linux-систем: здесь нет ничего от проекта GNU, не используется X.Org, ни даже systemd. Все эти компоненты заменены аналогами, более приспособленными для использования в условиях ограниченной памяти, низкой скорости процессора и минимального потребления энергии — таким образом, Android больше похож на встраиваемую (embedded) Linux-систему, чем на GNU/Linux.

Другая причина того, что в Android не используется софт от GNU — известная политика «no GPL in userspace»:

We are sometimes asked why Apache Software License 2.0 is the preferred license for Android. For userspace (that is, non-kernel) software, we do in fact prefer ASL 2.0 (and similar licenses like BSD, MIT, etc.) over other licenses such as LGPL.

Android is about freedom and choice. The purpose of Android is promote openness in the mobile world, and we don’t believe it’s possible to predict or dictate all the uses to which people will want to put our software. So, while we encourage everyone to make devices that are open and modifiable, we don’t believe it is our place to force them to do so. Using LGPL libraries would often force them to do just that.

Само ядро Linux в Android тоже немного модифицировано: было добавлено несколько небольших компонентов, в том числе ashmem (anonymous shared memory), Binder driver (часть большого и важного фреймворка Binder, о котором я расскажу ниже), wakelocks (управление спящим режимом) и low memory killer. Исходно они представляли собой патчи к ядру, но их код был довольно быстро добавлен назад в upstream-ядро. Тем не менее, вы не найдёте их в «обычном линуксе»: большинство других дистрибутивов отключают эти компоненты при сборке.

В качестве libc (стандартной библиотеки языка C) в Android используется не GNU C library (glibc), а собственная минималистичная реализация под названием bionic, оптимизированная для встраиваемых (embedded) систем — она значительно быстрее, меньше и менее требовательна к памяти, чем glibc, которая обросла множеством слоёв совместимости.

В Android есть оболочка командной строки (shell) и множество стандартных для Unix-подобных систем команд/программ. Во встраиваемых системах для этого обычно используется пакет Busybox, реализующий функциональность многих команд в одном исполняемом файле; в Android используется его аналог под названием Toybox. Как и в «обычных» дистрибутивах Linux (и в отличие от встраиваемых систем), основным способом взаимодействия с системой является графический интерфейс, а не командная строка. Тем не менее, «добраться» до командной строки очень просто — достаточно запустить приложение-эмулятор терминала. По умолчанию он обычно не установлен, но его легко, например, скачать из Play Store (Terminal Emulator for Android, Material Terminal, Termux). Во многих «продвинутых» дистрибутивах Android — таких, как LineageOS (бывший CyanogenMod) — эмулятор терминала предустановлен.

Второй вариант — подключиться к Android-устройству с компьютера через Android Debug Bridge (adb). Это очень похоже на подключение через SSH:

Из других знакомых компонентов в Android используются библиотека FreeType (для отображения текста), графические API OpenGL ES, EGL и Vulkan, а также легковесная СУБД SQLite.

Кроме того, раньше для реализации WebView использовался браузерный движок WebKit, но начиная с версии 7.0 вместо этого используется установленное приложение Chrome (или другое; список приложений, которым разрешено выступать в качестве WebView provider, конфигурируется на этапе компиляции системы). Внутри себя Chrome тоже использует основанный на WebKit движок Blink, но в отличие от системной библиотеки, Chrome обновляется через Play Store — таким образом, все приложения, использующие WebView, автоматически получают последние улучшения и исправления уязвимостей.

It’s all about apps

Как легко заметить, использование Android принципиально отличается от использования «обычного Linux» — вам не нужно открывать и закрывать приложения, вы просто переключаетесь между ними, как будто все приложения запущены всегда. Действительно, одна из уникальных особенностей Android — в том, что приложения не контролируют напрямую процесс, в котором они запущены. Давайте поговорим об этом подробнее.

Основная единица в Unix-подобных системах — процесс. И низкоуровневые системные сервисы, и отдельные команды в shell’е, и графические приложения — это процессы. В большинстве случаев процесс представляет собой чёрный ящик для остальной системы — другие компоненты системы не знают и не заботятся о его состоянии. Процесс начинает выполняться с вызова функции main() (на самом деле _start ), и дальше реализует какую-то свою логику, взаимодействуя с остальной системой через системные вызовы и простейшее межпроцессное общение (IPC).

Поскольку Android тоже Unix-подобен, всё это верно и для него, но в то время как низкоуровневые части — на уровне Unix — оперируют понятием процесса, на более высоком уровне — уровне Android Framework — основной единицей является приложение. Приложение — не чёрный ящик: оно состоит из отдельных компонентов, хорошо известных остальной системе.

У приложений Android нет функции main() , нет одной точки входа. Вообще, Android максимально абстрагирует понятие приложение запущено как от пользователя, так и от разработчика. Конечно, процесс приложения нужно запускать и останавливать, но Android делает это автоматически (подробнее я расскажу об этом в следующих статьях). Разработчику предлагается реализовать несколько отдельных компонентов, каждый из которых обладает своим собственным жизненным циклом.

In Android, however, we explicitly decided we were not going to have a main() function, because we needed to give the platform more control over how an app runs. In particular, we wanted to build a system where the user never needed to think about starting and stopping apps, but rather the system took care of this for them… so the system had to have some more information about what is going on inside of each app, and be able to launch apps in various well-defined ways whenever it is needed even if it currently isn’t running.

Для реализации такой системы нужно, чтобы приложения имели возможность общатся друг с другом и с системными сервисами — другими словами, нужен очень продвинутый и быстрый механизм IPC.

Этот механизм — Binder.

Binder

Binder — это платформа для быстрого, удобного и объектно-ориентированного межпроцессного взаимодействия.

Разработка Binder началась в Be Inc. (для BeOS), затем он был портирован на Linux и открыт. Основной разработчик Binder, Dianne Hackborn, была и остаётся одним из основных разработчиков Android. За время разработки Android Binder был полностью переписан.

Binder работает не поверх System V IPC (которое даже не поддерживается в bionic), а использует свой небольшой модуль ядра, взаимодействие с которым из userspace происходит через системные вызовы (в основном ioctl ) на «виртуальном устройстве» /dev/binder . Со стороны userspace низкоуровневая работа с Binder, в том числе взаимодействие с /dev/binder и marshalling/unmarshalling данных, реализована в библиотеке libbinder.

Низкоуровневые части Binder оперируют в терминах объектов, которые могут пересылаться между процессами. При этом используется подсчёт ссылок (reference-counting) для автоматического освобождения неиспользуемых общих ресурсов и уведомление о завершении удалённого процесса (link-to-death) для освобождения ресурсов внутри процесса.

Высокоуровневые части Binder работают в терминах интерфейсов, сервисов и прокси-объектов. Описание интерфейса, предоставляемого программой другим программам, записывается на специальном языке AIDL (Android Interface Definition Language), внешне очень похожем на объявление интерфейсов в Java. По этому описанию автоматически генерируется настоящий Java-интерфейс, который потом может использоваться и клиентами, и самим сервисом. Кроме того, по .aidl -файлу автоматически генерируются два специальных класса: Proxy (для использования со стороны клиента) и Stub (со стороны сервиса), реализующие этот интерфейс.

Для Java-кода в процессе-клиенте прокси-объект выглядит как обычный Java-объект, который реализует наш интерфейс, и этот код может просто вызывать его методы. При этом сгенерированная реализация прокси-объекта автоматически сериализует переданные аргументы, общается с процессом-сервисом через libbinder, десериализует переданный назад результат вызова и возвращает его из Java-метода.

Stub работает наоборот: он принимает входящие вызовы через libbinder, десериализует аргументы, вызывает абстрактную реализацию метода, сериализует возвращаемое значение и передаёт его процессу-клиенту. Соответственно, для реализации сервиса программисту достаточно реализовать абстрактные методы в унаследованном от Stub классе.

Такая реализация Binder на уровне Java позволяет большинству кода использовать прокси-объект, вообще не задумываясь о том, что его функциональность реализована в другом процессе. Для обеспечения полной прозрачности Binder поддерживает вложенные и рекурсивные межпроцессные вызовы. Более того, использование Binder со стороны клиента выглядит совершенно одинаково, независимо от того, расположена ли реализация используемого сервиса в том же или в отдельном процессе.

Для того, чтобы разные процессы могли «найти» сервисы друг друга, в Android есть специальный сервис ServiceManager, который хранит, регистрирует и выдаёт токены всех остальных сервисов.

Binder широко используется в Android для реализации системных сервисов (например, пакетного менеджера и буфера обмена), но детали этого скрыты от разработчика приложений высокоуровневыми классами в Android Framework, такими как Activity, Intent и Context. Приложения могут также использовать Binder для предоставления друг другу собственных сервисов — например, приложение Google Play Services вообще не имеет собственного графического интерфейса для пользователя, но предоставляет разработчикам других приложений возможность пользоваться сервисами Google Play.

Подробнее про Binder можно узнать по этим ссылкам:

В следующей статье я расскажу о некоторых идеях, на которых построены высокоуровневые части Android, о нескольких его предшественниках и о базовых механизмах обеспечения безопасности.

Источник