Что такое нативная программа

Что такое нативная мобильная разработка? Нативная разработка — это решение, при котором создается отдельное мобильное приложение под каждую из платформ, с использованием нативных, то есть родных, языков программирования.

Нативный подход позволяет по-максимуму задействовать все ресурсы операционной системы, будь то Android или IOS , а также инструменты аппаратной части гаджета: камеру, микрофон, GPS-навигатор, акселерометр и другие. Также нативный подход позволяет добиться максимальной гибкости, функциональности и безопасности итогового продукта.

Языки программирования для iOS

Objective-C и Swift — основные языки программирования, которые используются при разработке программ для устройств под управлением iOS, iPadOS, tvOS, macOS, watchOS. Они объектно-ориентированы и позволяют группировать схожие задачи в процессе написания кода, что значительно ускоряет и упрощает задачу при фронтенд-разработке.

Кроме того нативная разработка под iOS может осуществляться с помощью: С#, HTML5, Java.

Что такое нативная реклама?

Основной средой разработки является Xcode, который включает в себя все необходимое для создания, тестирования и распространения приложений на всех платформах Apple.

Языки программирования для Android

Начиная с 2019 года Kotlin является официальным языком для разработки под Android. Это кроссплатформенный язык программирования, который можно использовать в качестве альтернативы Java для разработки Android-приложений. Kotlin может взаимодействовать с Java и работает на ее виртуальной машине.

До Kotlin официальным языком разработки для Android был Java и, следовательно, это также наиболее используемый язык. Многие приложения в Google Play созданы с использованием Java, и Google также поддерживает этот язык чаще всего. Вдобавок ко всему этому у Java есть большое онлайн-комьюнити для поддержки в случае возникновения каких-либо проблем.

Также для нативной разработки под Android могут использоваться C++, C#, Python, HTML, CSS, JavaScript.

Официальная среда разработки — Android Studio.

Преимущества нативной разработки

• Широкий функционал

‍Нативная разработка мобильных приложений открывает доступ ко всем API и инструментам, предоставляемым платформой, с которой вы работаете. То есть технически нет никаких ограничений на то, как программисты могут работать с новым приложением. Сложность разработки ограничивается только вашей фантазией и бюджетом: вы можете заложить в приложение любой функционал, который захотите, в том числе нестандартный.‍‍

• ‍Высокая производительность и скорость работы

‍Прямое взаимодействие между кодом и базовыми ресурсами обеспечивает высокую скорость и производительность приложения. Отчасти поэтому нативная разработка для создания мобильных игр является предпочтительным выбором.

Нативные или гибридные мобильные приложения на iOS и Android

Нативные приложения обычно имеют лучше UX-показатели. Мы можем использовать максимум возможностей аппаратной части устройства, более точно соответствовать гайдлайнам, а соответственно, реализовать более привычный интерфейс и user experience для аудитории конкретной платформы.

• Легче масштабировать

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

• Безопасностью и стабильностью в работе

Нативные средства разработки обеспечивают надежную защиту данных. Здесь приложения не зависят ни от каких сторонних программ и фреймворков. Они используют только официальные API, которые множество раз тестировались на разных версиях системы. То есть операционная система сама обеспечивает приложению многоуровневую защиту.

• ‍Поддержка сторов

‍Нативное приложение легче опубликовать, и оно обычно занимает более высокое место в магазине конкретной платформы, поскольку обеспечивает более высокую производительность и скорость.

Недостатки нативной разработки

• Дороговизна

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

Вам необходимо написать две базы кода, адаптировать UX/UI-дизайн под каждую из платформ, а затем протестировать все это. Нативная разработка требует много времени, поскольку работа, проделанная для одной платформы, не может быть продублирована для другой.

Что следует учитывать при выборе подхода к созданию мобильного приложения

• Сложность приложения

Если вы создаете приложение, которое просто отображает информацию, полученную из сети, кроссплатформенный подход будет хорошим выбором. Однако, если это связано с тяжелой обработкой или требует доступа к низкоуровневым API, таким как Bluetooth, вам следует использовать нативную разработку.

Нативная разработка создает приложения с высокой производительностью, но ее создание может быть дорогостоящим. Если у вас ограниченный бюджет для работы, кроссплатформенная мобильная разработка — идеальный выбор. Вы сэкономите около 30%-40%, поскольку для приложения, которое работает как на Android, так и на iOS, создается только одна кодовая база.

• Время разработки

В некоторых проектах требуется как можно скорее запустить приложение MVP. Здесь стоит рассмотреть кроссплатформенную разработку, так как вам не придется работать с двумя версиями приложения. Вместо этого потребуется только один цикл разработки для выпуска приложения для Android и iOS.

• Пользовательский интерфейс/UX

Если вы ищете потрясающие визуальные эффекты и опыт, то разработка нативных приложений — ваш вариант. Разработчики имеют доступ к компонентам UI/UX при разработке в нативной среде. Выбор кроссплатформенности сильно ограничит элемент UI/UX приложения.

Итак, нативная разработка подойдет, если:

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

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

Источник: terabit.ai

Что такое «Нативное приложение»?

Разумеется, у меня были подобные беседы с клиентами, когда я был фриланс-разработчиком на Titanium. И уж конечно, как Developer Advocate, я частенько слышу это когда начинаю объяснять Titanium разработчикам, которые ищут кросс-платформенное решение для создания приложений.

Titanium !== HTML

Каждый раз при сравнении с Phonegap (Cordova), Ionic и чем-либо еще, я начинаю мотать головой, махать руками и громко кричать о том, что в Titanium нет HTML.

Приложения на Titanium – это не сайты, которые чудесным образом обернуты в приложения.

Но при общении с клиентами или людьми, не очень подкованными в техническом плане, для которых JavaScript вызывает ассоциации с этими технологиями, представление HTML как просто еще одного технического термина не всегда помогает. Кроме того, определение Titanium как чего-то, чем он не является, не совсем правильно.

Что ты имеешь в виду под «Нативной» разработкой?

В ответ я стал спрашивать:

А что делает приложение нативным?

Может быть, то что…

• Разработчик использует предоставленные Apple, Google и Microsoft инструменты?
• Разработчик использует стандартный для платформы язык?
• Приложение использует строительные блоки (API), которые предоставляет платформа?
• Приложение работает так, как ожидает пользователь на этой платформе?

После короткого разговора о том, чего, по их мнению, JavaScript предложить не может, чаша весов всегда склонялась к четвертому пункту. Это подтверждает опрос в Твиттере, который я недавно провел.

Что такое хороший User Experience?

Итак, что же значит соответствующий платформе UI и UX? Ну, в первую очередь то, что мы не печемся о технологии, только о том, что она нам дает; Как приложение выглядит и чувствуется пользователем. Во вторую то, что поведение приложения зависит от платформы.

Выглядит и ведет себя ожидаемо

iOS, Android и Windows имеют различные требования к дизайну (iOS, Android,Windows) и если вы опираетесь на них, ваше приложение более предсказуемо и следовательно, проще в использовании.
Отличный пример – TabGroups. На Андроиде они, как правило, встроены в Action Bar и будут прокручиваться если их много. На iOS Tab Bar расположен внизу и если у вас больше пяти табов, то пятый будет вести на экран выбора нужного таба. На Windows Pivot Tabs работают почти как на Андроиде, но выглядят немного по-другому, они не являются частью Command Bar, который расположен внизу экрана.

Так что технология, которая используется для разработки нативного приложения, не должна иметь собственные UI контролы, вместо этого она должна использовать те, которые предоставлены платформой.
В Titanium есть кросс-платформенные API почти для всего, и он всегда переводит их в платформенные UI-компоненты. Например, Ti.UI.TabGroup даст вам результат как на картинке выше, но напишете вы при этом один код (Alloy):

Tab A Tab B Tab C

Для тех API, которые представлены не во всех платформах, мы используем пространства имен, например, Ti.UI.Android.CardView.

Единство API там, где это возможно, платформо-зависимые API – там, где нет. Всегда с уважением к целевой платформе.

Чувствуется ожидаемо

Но есть еще один, менее заметный фактор, который влияет на UX. Взаимодействие с приложением должно вызывать правильные чувства. Здесь мы имеем в виду, что время реакции и визуальный отклик такие, какие вы ждете от платформы.
Исторически этот момент всегда был большой проблемой для кросс-платформенной разработки. Все решения так или иначе имеют некий уровень абстракции над платформенными API. Это потенциальное узкое место. В Titanium мы посвятили массу времени оптимизации. Возьмите например, ListView, он может быть на 60% более отзывчивым, чем его предок, TableView.
В приложениях, которые используют HTML, это продолжает быть проблемой. Плоский интерфейс сделал все для того, чтобы такие приложения выглядели хорошо, но не нужно быть семи пядей во лбу, чтобы заметить разницу в том, как UI реагирует на взаимодействия. Часто он просто «не такой», и вот в чем задача UX: сделать его «таким».

Как достичь классного UX?

Кроме всего прочего, вам нужно классный разработчик. Плохие приложения можно и в XCode со Swift сделать, так что без сомнения, вы можете сделать его и с помощью любой (кросс-платформенной) технологии. Используйте нужные платформо-зависимые UI компоненты в нужных местах, избегайте утечек памяти, пишите чисто и с умом.
Плюс ко всему, используйте имеющиеся в вашем распоряжении строительные блоки, не имитируйте их. Помните, Titanium !== HTML и наши 4 пункта списка. Мы с уверенностью полагаем, что для нативного UX нужно использовать нативные UI и системные API. Для достижения пункта №4 нужно выполнить пункт №3.
Вот поэтому Facebook отказался от HTML приложений и создал React Native.
И да, у нас в Titanium это было с 2009.
Code Strong, Code Native… In JavaScript!

• JavaScript
• Разработка мобильных приложений

Источник: habr.com

Отличие нативных мобильных приложений от всех остальных

С каждым годом число мобильных приложений растет. Пандемия, мировые катаклизмы и войны становятся бустом для развития технологий. Сегодня мы готовы положить в карман всю нашу жизнь: за первую четверть 2022-го года в App Store для скачивания доступно 2 110 063 приложений, а в Google Play Market доступно для загрузки 3 298 329 приложений, согласно данным statista.com. По оценкам Statista Digital Market Outlook, выручка в большинстве сегментов вырастет в течение следующих нескольких лет и к 2025 году достигнет около 613 миллиардов долларов США.

Вы готовы создать свое мобильное приложение? Для начала прочитайте этот материал.

Виды мобильных приложений

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

Нативные приложения

«Native» с английского — «родной». Нативное мобильное приложение — это приложение, которое создается под конкретную платформу. Нативное мобильное приложение написано на «родном» для платформы языке программирования: для Android — Kotlin и Java, для Apple iOS — Objective-C и Swift.

Нативное мобильное приложение имеет доступ ко всем нативным технологиям и аппаратным возможностям конкретной платформы. Нативные мобильные приложения необходимо загружать и устанавливать на устройство, например, через официальные магазины Google Play Market и App Store.

Преимущества:

• доступ к аппаратной части устройства (геолокации, камере, микрофону, акселерометру, датчикам освещенности, календарю, push-уведомлениям) и широкий функционал за счет этого;
• могут закрыть больше различных запросов заказчиков и пользователей;
• данные пользователя можно легко собирать и анализировать;
• обычно, работают более стабильно и эффективно с любыми применяемыми девайсами на своей ОС;
• нет ограничения функционала скоростью и качеством Интернет-соединения, приложение может работать без выхода в сеть;
• лучше подходят для проектов с кастомизированными интерфейсами и сложной бизнес-логикой.

Недостатки:

• дорогие в разработке;
• для разработки нужно больше времени;
• проходят верификацию каждым магазином приложений;
• охватывают мало платформ и несовместимы с другими операционными системами;
• даже легкие изменения требуют регулярных обновлений.

Веб-приложения

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

Это похоже на хранение данных в облаке или на жестком диске компьютера. Часто веб-приложение дополняет мобильное нативное приложение и наоборот. При качественной разработке веб-приложения работают почти как нативные. Разберемся в этом “почти”, в чем же разница?

Преимущества:

• веб-приложения могут функционировать на платформе с любой ОС;
• разработчикам не нужно утверждать приложение с магазинами;
• цикл разработки CSS, HTML и JavaScript идет в разы быстрее.

Недостатки:

• нет доступа к аппаратной части устройств пользователей, что значительно урезает функционал веб-приложений (например, невозможно сделать веб-приложение, которое задействует акселерометр на устройстве или включит камеру);
• использование возможно только через Интернет и зависит от его наличия, скорости и стабильной работы;
• приложения не каталогизированы в одном месте и их сложнее искать.

Гибридные приложения

Гибридные приложение — компромисс между нативными и веб-приложениями. Они размещаются в рамках нативного приложения и работают через WebView. У них есть доступ к информации на устройстве пользователя.

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

WebView — это системный компонент, который открывает веб-страницы в рамках других приложений. Когда вы открывали ту или иную ссылку в социальной сети или клиенте электронной почты, то она открывалась в интерфейсе самой социальной сети или клиенте электронной почты, вместо перехода в браузер. Это работа WebView.

Преимущества:

• широкий функционал и высокая степень кастомизации;
• можно создать приложение, которое будет работать с несколькими платформами;
• удешевляют и ускоряют разработку MVP или несложного готового продукта для заказчиков;
• являются серединным решением между функционалом и производительностью нативного приложения и дешевизной веб-приложения.

Недостатки:

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

Попробуйте no-code платформу AppMaster

AppMaster поможет создать любое веб, мобильное или серверное приложение в 10 раз быстрее и 3 раза дешевле

Кросс-платформенность (или кросс-платформенные приложения)

Кросс-платформенная разработка приложений значит, что приложение разработано с такой технологией/языком/фреймворком, который позволяет использовать его сразу на нескольких разных ОС — Android, iOS, Windows, Linux и т. д. Например, приложения, разработанные с использованием React-Native, могут работать на Android и iOS.

Разработка гибридных приложений значит, что приложение разработано с использованием нескольких языков/технологий, но это не всегда означает, что оно будет кросс-платформенным. Приложения могут быть гибридными, но не обязательно будут считаться кросс-платформенными.

Приложение может считаться кросс-платформенным, но не обязательно будет гибридным, оно может быть веб-приложением или даже нативным (например, фреймворк React Native использует среду выполнения JavaScript для рендеринга JavaScript-кода и возможности последующей публикации приложения как в Google Play Market, так и в App Store).

Аналогично, приложения могут быть гибридными и иметь свойство кроссплатформенности одновременно (например, React-Native + родной язык платформы).

Подходы при разработке мобильного приложения можно комбинировать. Например, создавать критичные к производительности экраны на нативных технологиях, а второстепенные — на кросс-платформенных.

Преимущества:

• кросс-платформенная разработка намного быстрее разработки нативных мобильных приложений сразу под несколько разных платформ по отдельности;
• отлично подходит для стартапов, которым необходимо быстрее выйти на рынок с MVP, чтобы проверить теорию;
• подходит для создания ивент-приложений, например, для деловых конференций, ярмарок и т. д. из-за быстроты создания;
• кросс-платформенная разработка чаще способствует более эффективному развитию девелоперов, так как задействует работу с несколькими технологиями и средами, а также стимулирует навык решения проблем;
• кросс-платформенность удобна при написании простого приложения с малым количеством экранов для нескольких платформ (идеальная задача для кросс платформы — простая мобильная игра).

Недостатки:

• iOS и Android существенно различаются и это вызывает сложности в разработке и множество лагов в работе готового приложения (чаще это касается элементов интерфейса и их рендеринга, показатели Animation FPS и Animation RAM могут отличаться на 3-5 раз в худшую сторону);
• кросс-платформенные приложения чаще крашатся, дольше думают и тормозят;
• поддерживать кросс-платформенный код сложнее — обновление систем приводит к частому обновлению программных интерфейсов, что требует больше времени девелопера;
• в кросс-платформенном мире небольшое сообщество и часто приходится решать проблемы самостоятельно, высокий риск столкнуться с проблемой, о которой мало кто знает;
• разработка кроссплатформенных приложений может значительно упростить жизнь и сэкономить деньги заказчику и владельцам бизнеса, которые ограничены в финансовых возможностях, и добавить головной боли разработчику;
• но кросс-платформенное приложение может потребовать огромных усилий девелоперов и больших вложений заказчика при переходе из MVP в готовый продукт и при масштабировании продукта;
• кросс-платформенное приложение может использовать больше ресурса батареи устройства пользователя, причем, даже в полтора раза, что неудобно при частом использовании приложения.

Таким образом, кросс-платформенность выступает скорее свойством, нежели видом мобильного приложения. Разные виды мобильных приложений могут быть как кросс-платформенными, так и не кросс-платформенными. Многие источники путаются и используют эти термины («кросс-платформенное приложение» и «гибридное приложение») как синонимы, хотя все разница между ними есть.

Как выбрать вид приложения под свой проект?

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

Учитывайте сразу несколько факторов при выборе вида приложения:

1. бюджет разработки — маленький бюджет перенаправит вас к веб-приложению, средний позволит остановиться на разных вариантах гибридных приложений с кросс-платформенными возможностями, а высокий позволит создать сразу нативное мобильное приложение с максимальной скоростью и производительностью;
2. цели проекта и этапа проекта — если вы хотите только протестировать идею стартапа и выпустить MVP, то не стоит сразу тратить деньги на полный цикл разработки нативного приложения, лучше ограничиться другими вариантами;
3. нужна ли кросс-платформенность и с помощью каких технологий вам будет легче ее реализовать в своем проекте;
4. целевая аудитория продукта и ее реальные потребности в сравнении с ее возможными ожиданиями — это приложение пользователи будут использовать часто? нужна ли графика и анимация? нужна ли высокая скорость работы приложения для пользователя? нужны ли мультипользовательские возможности или доступ к аппаратным функциям устройства? какое количество экранов будет у приложения? и так далее;
5. скорость выхода продукта — полный цикл разработки нативного мобильного приложения может занять месяцы, для быстрого выхода необходимо реализовать гибридное приложение или веб-приложение;
6. планы по масштабированию продукта — возможно ли масштабирование вашего продукта на изначально выбранном виде приложения (веб- или гибридном) или придется перейти на нативную разработку в будущем.

Попробуйте no-code платформу AppMaster

AppMaster поможет создать любое веб, мобильное или серверное приложение в 10 раз быстрее и 3 раза дешевле

Все ответы на эти вопросы помогут адекватно стартовать начало проекта и двинуться в нужную сторону.

Есть ли способ сохранить лучшие качества всех видов приложений?

No-code платформа AppMaster.io предлагает концепцию all-in-one (все включено) для разработки мобильного приложения.

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

В сложившемся рынке no-code конструкторов приложений с этим вообще не заморачиваются, так как создание нативных no-code приложений — слишком сложный процесс. В итоге, no-code платформы предлагают своим клиентам собирать веб-приложения или гибридные приложения, тяготеющие к веб, которые могут работать везде, но их функционал — ограничен, ведь аппаратными возможностями устройств пользоваться нельзя.

В AppMaster.io используется более продвинутый вариант:

1. разделение бэкенда и фронтенда приложений, за счет чего возможно отдельно создание серверных приложений для бэкэнда и пользовательских приложений для фронтенда, которые, в свою очередь, делятся на веб-приложения и мобильные приложения;
2. созданное на платформе мобильное приложение работает с привязкой к устройству и может пользоваться его аппаратными возможностями;
3. можно создать универсальное приложение, которое изначально будет фактически идентичным на iOS и Android — в него можно добавлять свои особенности, например, вносить изменения в интерфейс для одной из операционных систем.
4. Доступ к аппаратной части устройств дает невероятный функционал в мобильных приложениях, например:
5. Взаимодействие с датчиками освещенности — приложение может получить информацию об уровне освещенности в помещении от устройства и, на основании этих данных, поменять тему оформления с ночной на дневную;
6. Доступ к камере устройства — использовать ее для сканера QR-кода, который доступен на AppMaster.io в виде бесплатного модуля;
7. Назначение триггера, — действия на устройстве,— которое произойдет, если устройство потрясти;
8. Возможности запускать какие-либо триггеры при сворачивании приложения или даже выключении устройства;
9. Получение сведений о геолокации устройства и использование их в созданном приложении;
10. Проверка уровня заряда батареи и корректировка работы приложения в соответствии с ним.

Кодовая база уже создана и выполняется автогенерация кода в соответствии с требованиями к приложению, а значит не нужно искать разработчиков или учить новый язык. В конструкторе мобильных приложений легко вести разработку под разные платформы и это занимает в десятки раз меньше времени, чем классическая разработка любого вида мобильного приложения. Стоимость не зависит от выбора ОС — тариф для iOS и Android один и тот же и цена подписки несравнимо мала в сравнении со стоимостью классической разработки нативного мобильного приложения.

Server-driven UI убирает зависимость от обновлений для внесения изменений в пользовательский интерфейс. Достаточно один раз опубликовать приложение в AppStore или PlayMarket, а все обновления интерфейса и логики будут доставлены пользователям мгновенно, нужно лишь внести изменения в конструкторе AppMaster.io и одним нажатием переопубликовать фронтенд и бэкенд.

Это совершенно новый уровень для no-code платформы, который подводит no-code к созданию нативных мобильных приложений, но без основных недостатков классической разработки нативных мобильных приложений. Это означает, что вы можете использовать только их преимущества — получить все и сразу.

Итоги

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

Если полностью нативное и полностью веб-приложение можно определить четко, то степень гибридности приложения можно представить как спектр — оно может тяготеть к нативному или же опираться на веб-функционал.

Попробовать создать свое первое приложение разных видов вы можете прямо сейчас на no-code платформе AppMaster.io без написания единой строчки кода, только с помощью удобного визуального редактора.

Источник: appmaster.io