Web ios что это
Web разработка под iPhone
Способ первый – просто и со вкусом
Само собой, можно просто написать веб сайт и его адаптировать. Об этом на Хабре уже писали. К написанному в той статье мне бы хотелось добавить две вещи.
Во-первых, с появлением html 5 появилась возможность работы с локальными базами данных. И все браузере на движке WebKit (само собой последние апдейты) уже поддерживают эту возможность. Работать с ней более чем просто.
Во-вторых, стоит сказать об оффлайновом режиме работы с помощью создания manifest-файла. Подробно об этом можно прочитать на сайте Apple.
Вкратце что это такое. Манифест это обыкновенный файл, такой же, как например, css или js, содержащий в себе информацию о кэше приложения. Когда вы первый раз заходите на страницу, ресурсы, указанные в этом файле кэшируются.
Теперь как все выглядит на деле:
1. Указываем ссылку на файл на нужной нам странице
2. Создаем сам файл
demoimages/clownfish.jpg
demoimages/clownfishsmall.jpg
demoimages/flowingrock.jpg
demoimages/flowingrocksmall.jpg
demoimages/stones.jpg
demoimages/stonessmall.jpg
И после этого все работает. С кэшем можно работать — апдейтить его, обрабатывать события и так далее.
Все это мне очень понравилось, но мне стало интересно, а есть ли какие-то специальные фреймворки. Оказалось есть.
Способ второй — jQTouch
О jQTouch уже немного писали. Хочу рассказать немного подробнее о том, что он умеет.
jQTouch — Это такой плагин к известному JavaScript-фреймворку jQuery, позволяющий очень просто создавать веб-приложения для тачфонов — телефонов с сенсорным экраном, причём с пальцеориентированным интерфейсом. Каким и является iPhone. А так же HTC Hero, Dream, Magic — на Android — и куча разных WM-коммуникаторов с оболочками. © (оригинал)
Плагин очень приятный, но все таки на выходе мы имеем не полноценное приложение. Почему? У нас нет доступа к таким вещам как акселерометр, вибрация, звук и так далее. После этого я снова полез в гугл и нашел такую отличную вещь как PhoneGap.
Способ третий — PhoneGap
Суть данного фреймворка состоит в том, что написав один раз приложение с помощью html и js, мы сможем транслировать его в приложение под нужную платформу. А платформы он поддерживает вот такие: iPhone, Android, Blackberry (OS 4.5), Symbian, Windows Mobile, Palm, Maemo. В случае айфона мы опять возвращаемся к тому, с чего начали — нужен макбук, лицензия и все дела. Но фреймворк все равно отличный.
Ниже представлен roadmap данного проекта.
Приятный бонусом данного продукта является наличие симулятора, на котором можно оттестировать написанное приложение. Рекомендую поставить и поиграться.
Необходимость трансляции немного напрягала и дальнейшие поиски вывели меня на конкурента PhoneGap — MotherApp
Способ четвертый — MotherApp
Как видите, сервис хорошо монетизирован =)
А если серьезно вполне серьезная и мощная по своим возможностям вещь. По ссылке список возможностей с картинками.
Способ пятый — Big5
Здесь все еще проще.
Пишем свое приложение с использованием js-библиотеки, скачиваем приложение из аппсторе и вводим адрес своего сайта.
В своей сути, big5 — это альтернативный бразуер, но с доступом к нативным функциям телефона. Большой вопрос, как к этом отнесется Apple и не повторится ли здесь судьба PhoneGap. Но факт остается фактом, написав веб приложение, мы в итоге получаем полноценное приложение под айфон. Насколько полноценное зависит от пользователя, так как в аппстор есть две версии приложения big5: бесплатная lite и платная за 10$.
На сайте big5 заявлено, что разработка под их приложение, это просто веб разработка, так что все что было описано в первом пункте так же справедливо и тут.
Ну и в завершении, хочется представить еще одного кандидата. Но он, пожалуй, больше придется по душе тем, кто выбрал Ruby on rails. Итак, встречайте — Rhodes.
Способ отдельный — Rhodes
Этот продукт отчасти напоминает процессом своей разработки, который представлен ниже, MotherApp.
Rhodes опять же работает со всеми нативными вещами, вплоть до файловой системы. Поддерживает он следующие платформы: iPhone, Windows Mobile, BlackBerry, Symbian и Android. Язык у данного фреймворка очень похож на ruby, так что рубисты дерзайте. Пока что сложно найти какие либо отзывы.
И в завершении, тем, кого данная тема увлечет, хочу порекомендовать книгу от O`Reilly — Building iPhone Apps with HTML, CSS, and JavaScript
Making App Store Apps Without Objective-C or Cocoa. По ссылке ее официальный электронный вариант.
Я сделал PWA и выложил в трёх магазинах приложений. И вот что я выяснил
Недавно я опубликовал прогрессивное веб-приложение Chavah Messianic Radio, музыкальный проигрыватель вроде Pandora, и выложил его в трёх магазинах приложений (Google Play, iOS App Store, Windows Store).
Процесс выкладывания был тяжёлый и поучительный. Вот что я выяснил.
Зачем?
Вероятно, вы удивились: «Зачем ты вообще выложил приложение в сторах? Пусть бы оно жило в открытом вебе!». Дело в том, что пользователи сконцентрированы в сторах. Выросло поколение людей, которых мы приучили искать приложения в соответствующих магазинах приложений, а не в открытом доступе в сети.
Что касается моего приложения, то у меня было две большие причины выложить его в магазинах:
До недавнего времени я отвечал:
«Да вам не нужно приложение, просто зайдите с телефона на сайт! Он работает!».
Настоящие веб-приложения лишь приблизительно работают на мобильниках. И это привело меня ко второй причине: ограничения для веб-приложений со стороны Apple некоторых мобильных платформ.
Разработчиков мобильных платформ, вроде Apple, полностью устраивают приложения, которые используют ваши телефоны на всю катушку: получают доступ к вашей геолокации, проигрывают звук в фоновом режиме, получают ваши GPS-координаты, читают все ваши контакты, проигрывают видео и аудио без взаимодействия с приложением, читают вашу почту, перехватывают набираемый текст, одновременно исполняют несколько процессов, используют микрофон и камеру, получают доступ к фотографиям, и делают многое другое.
Apple это полностью устраивает.
Если вы хотите использовать в старом веб-приложении что-то из вышеперечисленного, то, чёрт побери, Apple просто этого не позволит. Она даже не позволит вам запросить разрешение.
Для моего приложения типа Pandora это кошмарное бессилие проявилось по-разному. Начиная от мелких неприятностей, вроде «iOS Safari не позволит вам проигрывать аудио без предварительного взаимодействия со страницей», до крупных проблем, вроде «iOS Safari не позволит вам проиграть следующую песню, если ваше приложение находится в фоновом режиме или если экран выключен».
В общем, чтобы моё музыкальное HTML5-приложение нормально работало на пользовательских устройствах, необходимо было выложить его в магазине.
Барьеры для входа
В идеальном мире публикация приложения в магазинах выглядит так:
Ваш веб/облачный хост или CI-провайдер:
Вы опубликовали прогрессивное веб-приложение. Хотите опубликовать в магазинах приложений?
iOS App Store
Google Play
Windows Store
Или, как экспериментирует Microsoft, ваше PWA автоматически появится в магазине, как только оно будет проиндексировано ботом Bing.
Но увы, наш мир не идеален. Так что мы сталкиваемся со всевозможной проприетарной нативной фигней, когда пытаемся выложить наши веб-приложения в магазины. У каждого магазина есть барьеры для входа: то есть создаются определённые трудности для размещения готового приложения в конкретном магазине.
Вот некоторые из них.
Стоимость
Раньше Apple понимала это. Когда появился первый iPhone, Стив Джобс твёрдо верил, что будущее за HTML5 и что все приложения станут с приставкой «веб-». Не существовало нативного iPhone SDK для сторонних разработчиков. Однако с тех пор мнение Apple изменилось.
Microsoft, похоже, просто старается увеличить количество приложений в магазине, невзирая на качество.
Победитель: Microsoft. Трудно победить бесплатное.
Добавление нативных возможностей
В идеальном мире мне не пришлось бы написать ни строчки дополнительного кода, чтобы интегрировать моё веб-приложение в операционную систему. Или, как сказал Стив Джобс в 2007-м:
«Движок Safari находится целиком в iPhone. Поэтому вы можете писать невероятные Web 2.0 и Ajax-приложения, которые выглядят и ведут себя точно так же, как и приложения под iPhone. И все ваши приложения будут идеально интегрированы с сервисами iPhone. Они смогут звонить, смогут отправлять почту, смогут искать места в картах Google Maps».
Для меня это означает, что моё веб-приложение должно играть музыку в фоновом режиме, используя стандартные HTML5-средства работы с аудио, замечательно работающие во всех ОС. То есть моё приложение объявляет, какой файл оно проигрывает, а операционные системы учитывают это и показывают на экране блокировки текущую песню. При этом моё приложение воспроизводит с помощью стандартного аудио-API HTML5, а ОС отображает на экране блокировки средства управления: воспроизведение, пауза, переход к другому файлу, изменение громкости, перемотка.
К сожалению, наш мир не идеален. Всё вышеперечисленное не работает из коробки на всех трёх платформах.
Моему веб-приложению нужна возможность проигрывания в фоновом режиме. И возможность загрузки URL’ов из моей CDN. Звучит разумно, не так ли? А что насчёт отображения текущей песни на экране блокировки? А управление воспроизведением с того же экрана? Насколько это сложно?
iOS-магазин. Вашему веб-приложению нужно проигрывать аудио в фоне? Используйте Cordova-плагин. Нужно показывать текущую песню на экране блокировки? Используйте Cordova-плагин. Нужно управлять воспроизведением с экрана блокировки? Используйте Cordova-плагин. Ну, вы поняли. По сути, Cordova позволяет Apple считать вас нативным приложением. И поскольку вы не мерзкое веб-приложение, Apple позволяет вам делать всё то же, что позволено нативным приложениям. Для это нужны лишь нативные хитрости — Cordova-плагины.
Google Play. Замечательно, что я могу написать лишь JS-код, и всё будет работать. Не нужно никаких Cordova-плагинов. Конечно, этот JS не будет работать нигде за пределами Chrome на Android… но вдруг однажды (в идеальном мире!) все мобильные браузеры реализуют эти веб-API… и мир объединится. Я почти пою утопический хиппи-гимн Джона Леннона.
Windows Store. Хотите проигрывать аудио в фоне? Извините! Не получится до тех пор, пока не объявите о своих намерениях в нашем проприетарном манифесте свойств (это просто) И не реализуете этот проприетарный медиа-интерфейс с помощью window.Windows.SystemMediaTransportControls (не так просто). Иначе выключим звук, когда приложение перейдёт в фоновый режим.
Победитель: Google. Мне достаточно писать лишь на JavaScript, а ОС просто получает сигналы от моего приложения.
Догоняющий: Windows. Всё ещё могу писать старый добрый JavaScript, но приходится общаться с проприетарным Windows JS API, внедрённым в мой процесс при исполнении под Windows. Не слишком страшно.
Регистрация в магазинах
Чтобы опубликовать PWA в магазине, нужно зарегистрироваться, пройти бизнес-проверку и преодолеть бюрократические препоны:
Сначала я зашёл на сайт и зарегистрировался как разработчик. Ввёл своё имя и информацию о компании (полагаю, Apple не позволит выложить приложение, если вы не являетесь зарегистрированной легальной компанией?). Нажал «Далее».
«Введённая информация не соответствует вашему D&B-профилю».
Немного погуглил и выяснил, что «D&B-профиль» — это Dun and Bradstreet. Никогда раньше о них не слышал, но оказалось, что Apple пользуется услугами этой компании для проверки информации о легальных компаниях.
И очевидно, что мой D&B-профиль не соответствует тому, что я ввёл при регистрации.
Ещё погуглил и узнал, что Apple-форум для разработчиков завален такими постами. Толкового ответа никто не получил.
Написал в поддержку. Через 24 часа мне ответили на почту, чтобы я связался с D&B.
Решил им написать… но Apple сказала, что получение ответа займёт несколько дней.
В тот момент я задумался, не плюнуть ли мне на всю затею.
Пока ждал ответа службы поддержки D&B, решил снова зайти на их сайт, проверить мои данные и обновить информацию о компании, которую, вероятно, они взяли из государственной базы данных.
Я уже говорил, какое это паскудство? А ведь всего лишь хотел опубликовать готовое приложение в магазине.
Пошёл на сайт D&B, чтобы обновить бизнес-профиль. Сюрприз! У них JavaScript-баг в логике проверки, который не даёт обновить профиль. К счастью, я искусный разработчик. Добавил прерывание в их JavaScript, нажал «Отправить», изменил флаг isValid на true, и готово! Я обновил свой D&B-профиль.
Вернулся на сайт Apple для разработчиков –> пробуем снова. Регистрирую свою компанию…
«Ошибка: Введённая информация не соответствует вашему D&B-профилю».
Снова пишу в Apple. «Ой, обновление информации из D&B в нашей системе может занять 24-48 часов».
Ну вы понимаете, потому что цифровой информации нужно два дня на путешествие с сервера А на сервер Б.
Пытаюсь зарегистрироваться через два дня… сработало! Теперь я участник программы Apple Developer и могу отправлять приложения на утверждение.
Победитель: Google и Microsoft. В обоих случаях регистрация заняла 5 минут.
Проигравший: Регистрация в Apple Developer была медленной и болезненной. У меня ушло на это около недели. Мне пришлось связаться с двумя разными чёртовыми компаниями. И потребовалось исправить runtime-баг в JavaScript-коде на чужом сайте, чтобы обойти их кривую клиентскую проверку, чтобы моя информация отправилась в Apple, чтобы я мог отправить приложение в магазин. Ну просто… ух-ты.
Упаковка, сборка и отправка приложения
Сделав веб-приложение, вам придётся с помощью волшебства превратить его в нечто, что можно отправить на утверждение.
Но собрать XCode-проект и отправить его на сайт недостаточно. Пришлось на сайте для разработчиков сгенерировать сертификат безопасности, затем на отдельном сайте iTunes Connect создать новый профиль приложения, и там уже отправлять пакет на утверждение.
Но и это не всё: поскольку Apple враждебна к веб-приложениям, мне пришлось установить специальные фреймворки и добавить Cordova-плагины, позволяющие моему приложению проигрывать музыку в фоне, добавлять текущую песню на экран блокировки, там же управлять воспроизведением, и прочие действия.
У меня неделя ушла на то, чтобы всякими ухищрениями довести приложение до рабочего состояния, прежде чем я смог отправить его в магазин.
Победитель: Microsoft. Представьте: можно пойти на сайт, генерирующий пакет из вашего веб-приложения. Или можно вообще скачать инструменты для командной строки, которые сделают всё это. Предпочитаете графические интерфейсы? К вашим услугам бесплатная Visual Studio.
Догоняющий: Google. Требуется Android Studio, но она бесплатная, работает везде и проста в использовании.
Проигравший: Apple. Я не должен покупать Мас за несколько тысяч долларов, только чтобы собрать приложение. Путаница с Apple Dev Center –> iTunes Connect выглядит как попытка оторванного от реальной жизни начальства загнать разработчиков в iTunes. Надо было просто объединить всё в один Apple Developer Center.
Тестирование приложения
Когда наконец-то прочитаете все заклинания, превращающие ваше веб-приложение в пакет мобильного приложения, возможно, вы захотите отправить его тестировщикам, прежде чем допускать к нему толпу немытых пользователей.
Утверждение приложения
Когда ваш продукт готов к прайм-тайм, вы отправляете его на утверждение. Приложение проходит автоматический чек-лист (например, у вас есть иконка для запуска?) и проверяется людьми («ваше приложение — клон Х, мы его отклоняем»).
Конечно, как разработчику мне нравится, что моё приложение мгновенно попало в Google Play. Но я подозреваю, лишь потому, что его не просматривал человек.
И что касается проверки человеком, то у Apple на это уходит меньше всего времени. Обновления также утверждаются в течение 24 часов.
У Microsoft получилось кое-как: первоначальное утверждение заняло 3-4 дня, а последующее обновление утвердили за сутки. А второе обновление, добавленное для платформы Xbox, опять утверждали 3-4 дня.
Заключение
Взять готовое PWA, довести его до рабочего состояния на мобильных платформах и разместить в магазинах тяжело и стоит денег.
Победитель: Google. В их магазин приложению попасть проще всего. Также у них самое простое интегрирование с нативной платформой благодаря стандартизации веб-API, к которым обращается ОС (привет, любимый navigator.mediaSession).
Догоняющий: Microsoft. Проще всего с помощью волшебства превратить PWA в пакет, который можно отправлять в магазин (это можно сделать бесплатно с помощью сайта PWABuilder!). Интегрирование с их платформой подразумевает автоматическое внедрение в JavaScript-пространство имён API window.Windows.*. Пойдёт.
Проигравший: Apple. Не заставляйте меня покупать Мас для сборки iOS-приложения. Не заставляйте меня использовать нативные обёртки для интегрирования с вашей платформой. Не морочьте мне голову своими сертификатами безопасности, пусть ваши средства сборки делают их для меня сами и автоматически привязывают к моему аккаунту в Dev Center. Не заставляйте меня использовать два разных сайта: Apple Dev Center и iTunes Connect.
Веб победит и в мобильном сегменте. Разработчики не хотят разрабатывать три отдельных приложения для основных платформ. Компании не хотят платить за разработку трёх приложений. Мы можем создавать мощные веб-приложения — PWA — и упаковывать для всех магазинов приложений.
У Apple есть соблазн остановить развитие веба. Тот же соблазн обуревал Microsoft в конце 1990-х и начале 2000-х: она хотела быть платформой для хороших приложений. PWA разрушили эти планы, теперь они везде.
Вангую: в конце концов PWA одержат верх и над нативными мобильными приложениями. Через 5-10 лет нативные iOS-приложения станут такими же распространёнными, как Win32 С-приложения. Apple будет пинаться и верещать, стараясь удержать iOS Safari в стороне от этой тенденции, всячески блокируя развитие PWA (даже их недавняя «поддержка» PWA в iOS Safari 11.1 — просто изуродованные PWA).
Предлагаю мобильным платформам автоматически добавлять в магазины приложений качественные PWA, или позволить разработчикам легко (например, бесплатно и в три клика) добавлять PWA самостоятельно.
Из веба и банков в iOS-разработку: личный опыт программиста Apiqa
Команда Apiqa занимается продуктовой разработкой для специфической сферы ЖКХ. Найти опытных разработчиков в Екатеринбурге непросто — здесь за ними охотятся крупные IT-компании, многие кандидаты уезжают в столицы или покидают страну, а удалённое сотрудничество на текущем этапе нам не подходит. Мы выращиваем сотрудников внутри компании, идём им навстречу и стараемся обеспечивать комфортные условия работы. Так, один из наших веб-разработчиков в прошлом году решил попробовать себя в программировании для iOS. Мы помогли ему совершить этот переход плавно, сейчас он параллельно занимается и вебом, и мобильной разработкой. А теперь он готов поделиться своей историей от первого лица. Добро пожаловать под кат.
Кто я
Привет, Хабр! Я — Саша Калинин, разработчик в Apiqa. Мне всегда нравилось писать сайты, собирать компьютеры, разбираться в сложных технических штуках, но по настоянию родителей я получил экономическое образование и пошёл работать в банковскую сферу.
В 2015 году начал изучать программирование и устроился на стажировку в УрЗПИ («Уральский завод программных изделий»), который позже объединился с интерактивным агентством «Всё ясно», и появилась Apiqa. Так я погрузился в мир веб-разработки. В прошлом году мне захотелось попробовать себя на просторах iOS, и компания пошла мне навстречу.
Начало: веб-программирование
УрЗПИ занимался разработкой сайтов: «Золотого яблока», «Лиги ЖКХ», ювелирного бренда, салонов красоты и других. Мы сделали масштабный проект Digital Pathology — это платформа для исследования онкологических заболеваний. Параллельно с основной работой я был наставником в двух онлайн-школах: Loftschool и HTML Academy.
В 2018 году якорным клиентом Apiqa стал ПИК-Комфорт — крупнейшая управляющая компания в России — в результате чего определилась специализация, и мы стали заниматься продуктовой разработкой в сфере ЖКХ.
В мае прошлого года у нас появился спрос на мобильные приложения, и в компанию пришли нативные разработчики. К тому моменту я устал от веба и захотел попробовать себя в мобилке. Так как я большой фанат Apple, решил писать для iOS.
Погружение в мобильный мир
В первый день я попросил нашего iOS-разработчика посоветовать мне, с чего начать. Он оказался отзывчивым и сыграл роль моего наставника, помогая на разных этапах обучения. Ближе к осени я начал читать книги: «Swift. Основы разработки приложений под iOS и macOS» (4-е издание) Василия Усова и «Swift 3. Разработка приложений в среде Xcode для iPhone и iPad с использованием iOS SDK» (3-е издание) Молли Маскри. Полгода читал, выполнял задания, параллельно что-то писал, получал идеи приложений от наставника, чтобы прокачать скиллы.
Swift мне понравился — он оказался достаточно простым и схожим с TypeScript по синтаксису, на котором я пишу веб. С инструментами для разработки под платформы Apple сложнее — там очень много наследия из времён Objective-C, старого и неудобного системного API. Вторую книгу дочитал со скрипом.
Первый pull request провалился, и мне впервые захотелось всё бросить, но я этого не сделал. И процесс выстроился примерно за полгода: сейчас я пишу и для веба, и для iOS.
Текущие задачи мы распределяем. Мне нравится заниматься чем-то необычным, недоступным веб-разработчику — например, 3D Touch, а вот анимации пока не поддаются, нет у меня дизайнерского чувства. На вебе анимировать интерфейс, конечно, проще — там код получается понятнее, нет сложных заморочек.
Мобильная разработка и веб: в чём разница
На вебе весь визуал создаётся с помощью кода. Его можно читать и представлять себе конечный продукт. В Xcode, это IDE для iOS-разработчиков, есть Interface Builder — инструмент, который позволяет верстать при помощи графического интерфейса, перетаскивая курсором элементы — то есть для визуальной части код писать не нужно.
Звучит круто, но работает весьма нестабильно — то глючит, то зависает, то ломается. Иногда происходят конфликты между собственным кодом и Interface Builder — в консоль падает много ошибок, может упасть само приложение, может вообще всё полететь к чертям.
Что выбрать: веб или мобилку?
Решение за вами. Нужно понимать, что у них принципиально разная рыночная ситуация. Веб — это свободная платформа, а законодателями в мобилке выступают компании, которым принадлежат iOS и Android, — они решают, куда развиваться, какими инструментами пользоваться разработчикам. При программировании для веба можно юзать разные фреймворки, писать на разных языках, использовать разные IDE, в то время как для iOS есть только Swift, Cocoa и Xcode. Если для Xcode выходит какая-то новая фича, то она появляется у всех разработчиков, но если нет — то нет. Такая ограниченность Apple обеспечивает порядок при написании кода, на вебе же этот порядок приходится устанавливать самостоятельно.
Плюсом веба также могу назвать большое количество решений open source, которых нет для iOS. Когда я начинал писать мобильные приложения, искал инструменты, аналогичные вебу, которые бы что-то автоматизировали, но здесь приходится писать руками.
В свою очередь, плюс разработки для iOS в нативности, Apple даёт разработчику больше свободы в плане реализации функциональности — Face ID, iCloud, хранилище и многое другое. У тебя есть большой доступ к пользовательскому железу. А в браузере ты ограничен тем, что тебе этот браузер позволяет.
Дальнейший путь
Моё потенциальное развитие на вебе — это изучение вещей, которые не сильно востребованы в повседневной работе. В iOS же у меня до сих пор много вопросов, есть куда развиваться, расти и учиться. Меня привлекает возможность практического применения навыков в рамках повседневной жизни и работы: нужно для телефона что-то написать — напишу, нужно для Mac — помучаюсь, поразбираюсь и напишу, для часов и Apple TV — тоже. Я уже хотел писать игрушки, но потом понял, что это отдельное сложное направление, погружение в которое отнимет слишком много времени. К такому я пока не готов.
Сейчас больше занимаюсь разработкой для iOS, но в любой момент могу вернуться обратно. Я слежу за частыми обновлениями веба, получаю release notes и понимаю, куда всё движется. На мобильных платформах обновление происходит фактически раз в год.
В целом подход со SwiftUI мне понравился гораздо больше, чем тот, с которым мы работаем сейчас — Auto Layout. SwiftUI прост и понятен, пишешь код и сразу видишь, что у тебя получается. По сути это схоже с вебом: пишешь код, а в браузере всё сразу появляется, это не требует какого-то долгого компилирования и постоянной сборки приложения.
Что в итоге?
Я не жалею, что прошёл такой путь. Если вы захотите повторить мой опыт, оценивайте свои навыки и возможности своей компании. Коллеги в Apiqa пошли мне навстречу, но не факт, что у вас будет так же, поэтому перед тем, как начать подобный переход, обсудите его с менеджментом.
Если вы совсем не знакомы с программированием, учитывайте, что на вебе планка входа ниже, доступно намного больше образовательных ресурсов на русском языке. iOS сложнее для освоения и в плане написания кода — здесь требуется мыслить, как программист, иметь достаточно базовых знаний.
Стать веб- или Android-разработчиком может любой человек, который поставил себе такую задачу — нужно лишь искать информацию, изучать её, нарабатывать опыт. А вот чтобы посвятить себя iOS, как минимум придётся раздобыть Mac.