Web sites on iphone

Лёгкий способ писать iOS приложения на вебе

Всем привет. Не так давно Габриель подарил нам игру 2048. Это тот самый удивительный случай, когда клон игры становится более популярный, чем оригинал. Не малая часть успеха Габриеля — открытый код и, вуаля, MIT лицензия. Набрав чуть больше 20к очков, захотелось поделиться результатом с друзьями, кроме как сделать скриншот не получилось. Глянул аппстор на наличие клона с геймцентром или чем-то подобным — пусто. И тут подумал, почему бы нет?
Забегая вперёд, на создание приложения и всех «ништяков» к нему ушло 4 дня. На выходе универсальный код, который от части работает и в вебе и легко портируется на иос/андроид. Однако, давайте по порядку.

Как вы уже поняли, речь пойдёт о разработке нативных приложений на веб технологиях. Для тех, кто в танке, работает всё достаточно просто. Создаётся проект с нативными SDK, цель которого — разместить на весь экран WebView и открыть конкретный html в нём. Т.е. получается, что всё приложение сводится к браузеру с зашитой адресной строкой. Можно долго спорить, хорошо это или плохо. В сети кучища холиваров по этому поводу, кто-то предпочитает html5, кто-то нативный код. Я пишу и так и так, но тут, имея исходники 2048 именно на вебе, было бы глупо переписывать всё на нативный objc. Да и потом, если речь идёт о небольшом приложении, основная задача которого — фронтенд + работа с сервером, опять же глупо городить objc, когда можно обойтись html5.
Скажем так, wunderlist прекрасно работает на веб технологиях. Как и официальный gmail клиент.

Наша команда на основном рабочем месте делает b2b проекты. Это такие проекты, где при минимальной посещаемости делается хорошая ебида. Так и у нас, минимальные значения уников в сутки. Поэтому мы можем «играть» технологиями. Пока некоторые верстают под ie8, своим клиентам мы сказали, что только firefox или chrome, и они безоговорочно поставили сотрудникам эти браузеры. Поэтому мы достаточно давно юзаем всякие html5 штуки и радуемся. Однако, когда в голову пришла идея сделать такой проект, я даже не представлял, насколько это будет интересно и ново, не смотря на то, что в общем я знал и частично применял почти все технологии, описанные ниже.
Начнём с окружения, далее пройдёмся по технологиям и обсудим ошибки, сделаем выводы.

1. Окружение.

Отцом WebView для мобильников, несомненно, является phoneGap. Он не плохо документирован (чего там документировать то?) и достаточно прост. Что же он делает? Как и другие фреймворки, позволяющие делать нативные приложения на базе веб технологий, phonegap проталкивает нативные возможности в JS код и обратно. Т.е. вы пишите как писали раньше, адаптируете дизайн под мобильное устройство + имеете JS вызовы, позволяющие работать с камерой, нотификейшенами, контактами, СМС и прочим. Список возможностей и платформ доступен на спецстранице. Построен он на базе Cordova.
Так же советаю посмотреть в сторону Sencha, ребята пошли немного дальше и дают возможность не просто получить доступ к нативным фишкам телефонов/планшетов через JS, но так же дают нативные UI. Т.е. делая одно приложение, выглядеть оно будет как нативное и в андройде и в ios`е. Однако, сенча это extjs со всеми вытекающими. Это как с кинзой, есть люди, которые без ума от неё и люди, которые её терпеть не могут ) Однако для общего ознакомления я советую посмотреть и её.
Так же я бы хотел подробней остановиться на Cordova. Фонгэп, это больше окружение. Там есть платная поддержка, облачные сервисы для генерации приложений итд итп. Cordova же это платформа. Непосредственно нативные модули и JS обвязка.

В данном случае, мы не будем использовать ничего из вышеперечисленного. Во-первых, хотелось попробовать сделать всё с нуля. Для себя я решил, дальнейшие приложения только Cordova, идеальное соотношение гибкости и скорости. Во-вторых, у меня не получилось быстро разобраться с окружением фонгэпа или кордовы. Не говоря уже про сенчу. Все они предлагали делать приложения с вшитыми html, а мы сейчас рассмотрим ситуацию, когда код лежит на внешнем сервере.
Почему именно внешний сервер? Мне хотелось сделать приложение, которое я бы смог обновлять не тогда, когда его промодерируют в appstore (обычно занимает неделю), а тогда, когда я нахожу в нём баги. Давайте по порядку.

1.1 TopCoat

В сети много фреймворков для создания мобильных UI, в том числе с аля-нативными UI. Уже говорили про сенчу, так же стоит обратить внимание на PhoneJS, JQ Mobile, Intel AF и многие другие. Гугл подскажет )
В данном случае я выбрал topcoat. Я уже встречался с ним на другом проекте и мне он очень понравился. Во-первых, это не плохие кастомные UI, которые отлично смотрятся и на андроиде и в иосе. Во-вторых, топкоат очень простой, отсюда гибкий. После Bootstrap было немного не привычно, в виду отсутствия сетки, напирмер, итп. Но к этому быстро привыкаешь )
Топкоат имеет ветку с иконками icomatic, не рекоммендую. Font Awesome лучший.

1.2 iScroll

UPD: Хабрапользователь radist2s подсказал, что iScroll в целом и не нужен, если требуется реализовать близкий к нативному скролинг. Оказывается, достаточно заюзать
Несомненно, свайпы и скролинг — визитная карточка мобильных решений. iScroll даёт очень близкий к нативному скролинг. В сети распространена iScroll4 не меньше, чем последняя iScroll5. Соответственно, новая более продвинутая и безбажная. На оффсайте много примеров, в общем всё понятно.

1.3 Zepto

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

1.4 Lodash

Просто вспомогательная надстройка над JS. Мы часто юзаем backbonejs в проектах, lodash там дефакто обязателен. Ну и на практике он ни сколько не медленнее нативного кода. Порой быстрее.

1.5 Moment

Работа с датами/временем в JS. Без комментариев, без этой библиотеки головной боли было бы в разы больше.

Я не стал использовать Backbone в проекте, хотя он тут очень даже просится. Опять же, экономим на спичках. Бэкбон удобен и незаменим в более-менее сложных приложениях, однако тут он ни к чему. По крайней мере мне так казалось )
Не могу не отметить rad-js, это кастомные backbone объекты, заточенные под разработку мобильных приложений. Приятная штука, но достаточно замудрённая. Так же очень жаль, что RAD во многом используется старый код. Например, цепляет старый iScroll и undercore, вместо lodash. Опять же, в данном проекте её использование показалось лишним.
С окружением разобрались. У нас нет MVC или подобного фреймворка, весь функционал приложения кладётся в простой js объект. Мы имеем готовый css фреймворк и необходимый набор JS библиотек для быстрой разработки.

2. Технологии

Удивительно, как за последние 2 года выросли технологии и браузеры. 2 года назад я выбирал между веб технологиями и нативным кодом. Под большой проект я выбрал нативный код. И на тот момет это было верным решением. Сейчас, по хорошему, переписать всё на веб и развивать дальше веб. Но уже жалко, тысячи строк нативного obj-c, будь он не ладен. Про яву молчу.

2.1 LocalStorage

Ну тут всё понятно, хранилище. 5 метров более чем, тем более, что нам он нужен под текст/js-объекты. Те, кто работал хоть раз с мемкешом/редисом, будет счастлив. Если 5 метров недостаточно, можно сделать обвязку через нативный UserData, например. В сети много решений. Кто-то предлагает кеш складывать в файлы, кто-то через UserData, кто-то рекомендует WebSQL, что, кстати, тоже удобно. Нам хватит localStorage.

2.2 AppCache

Пожалуй, только благодаря этой технологии мы и делаем приложение с внешним кодом. Ещё раз, наше приложение хостится не в локальных html файлах, а на удалённом сервере. Логично, что если у вас в телефоне в данный момент нет интернета, внешние сайты не откроются. Тут то нас и спасёт appCache. Про Application cache вышло много статей, кто не сталкивался с этой технологией, советую ознакомиться. Смысл достаточно простой. С помощью специального manifest файла, мы указываем браузеру все файлы, что нужно разместить в кеш. Прелесть в том, что размещённые в кеше файлы будут работать, даже если в устройстве нет интернета. Логика работы аппкеша в приложении простая.
Клиент первый раз запускает приложение, оно подсасывает контент в webview, webview кеширует приложение. Дальше при каждом запуске приложения, проверяется изменение manifest файла. Если он изменился — кеш полностью перезаписывается. Если изменений не было, работа продолжается. Соответственно, если у пользователя нет интернета, просто цепляется кеш без обновлений.
Таким образом мы можем делать не просто нативные приложения на базе веб технологий, но и размещать непосредственно код у себя на сервере. Для чего это нужно я писал выше — моментальный багфикс и быстрое публикование новых фишек.

2.3 CSS3

Ну и, конечно, глупо игнорировать все возможности вебкита. Вообще, делая на вебе мобильное приложение стоит всегда помнить, что мы делаем его под один-два браузера, которые супер современны и чаще поддерживают новые технологии, чем игнорируют их. Т.е. будет хорошим тоном использовать flexbox, свободно юзать анимацию и забыть про pngfix )
В данном приложении почти вся анимация сделана на базе css3. Во-первых, это проще и быстрее, чем писать километры JS кода. Во-вторых, работает сверх быстро благодаря аппаратному ускорению, которое можно включить в вебките для анимации.

Пожалуй, этого хватит ) Далее, надо подготовить проект в XCode.
Как уже говорил, всё достаточно просто, нам нужен только UIWebView на весь экран и ничего более. К проекту я подключил JSONKit, т.к. он быстрее нативного парсера + VK-SDK, Facebook-SDK для интеграции с соц.сетями. Конечно, можно было сделать интеграцию на вебе, однако для привлекательности я хотел сделать нативную поддержку vk+facebook. Не стоит забывать о возможностях ios sdk. Т.е. веб технологии это круто и мощно, но есть задачи, которые лучше реализовывать нативно. Интеграция с соц.сетями — одна из таких задач, как мне кажется.
Всё, что нам остаётся — наладить связь между нашим html кодом и приложением. Тут тоже всё достаточно просто. WebView, что мы разместили, нужно сделегировать в наш контроллер.
Сообщения из приложения в веб всё очень просто, из любого места дёргаем:

Сообщения из веба в приложение работают следующим образом. Проделегированный WebView снифает все переходы, мы можем делать нужные нам ссылки и перехватывать их в методе shouldStartLoadWithRequest:

Соответственно, если мы перехватили нужный нам адрес, не забываем делать return NO, иначе веб версия попытается таки перейти на адрес vk:auth.
Вот в целом и всё, у нас есть веб морда, которая умеет жёстко кешироваться и работать в оффлайне и общаться с нативным приложением. Что ещё нужно для счастья? )

Ошибки и заметки на будущее

В следующей статья я опишу, как использовать Cordova с внешним кодом. Несомненно, ошибкой #1 было решение писать свою оболочку на xcode. Но опять же, задачей было изучить процесс, чтобы понимать всю подноготную. Поэтому это не совсем ошибка. Я не рекомендую использовать свои оболочки, разве что для ознакомления. В любых других проектах нет ничего лучше, чем Cordova. А всё, что она не умеет, можно реализовать в виде плагинов для ней.
Так же игнорирование backbone было ошибкой. Приложение уже начинает разрастаться, дольнейшая доработка была бы намного проще и понятней, если бы сразу был бы использован mvc фреймворк типа backbone.
Помимо прочего, я жёстко лоханулся с настройкой NSURLRequest. Это объект запроса для WebView, который, собственно, и открывает нужный нам урл. Один из параметров которого cachePolicy, куда нужно передавать политику кеширования. Скажем, вы можете использовать стандартную политику (примерно соответствует браузерной), либо, например, указать, что запрос вообще никогда не должен кешироваться или наоборот, браться только из кеша вне зависимости от заголовков. Прочитав про флаг NSURLRequestReloadIgnoringLocalAndRemoteCacheData, решил использовать именно его. Приложение работало очевидно, его я и оставил. И только потом оказалось, что данный флаг не реализован в ios sdk )))

Что касается самой игры, на момент отправки бинарника на модерацию, в аппсторе не было ни одной игры 2048. На момент публикации их было больше 60. Сначала я встроил в html код мобильный adsense. Однако перед самой публикацией я его убрал и сделал приложение платным, т.к. все эти 60+ игр были бесплатные с рекламой внутри. Вроде как какой-то кастом ) метод замены переменной. Стоит понимать, что у меня нет задачи заработать на этой игре, однако поддерживать её бесплатно смысла тоже нет. Основное отличие от конкурентов — интеграция не с GameCenter, а с соцсетями. Мне лично интересней посмотреть кого я обогнал среди своих друзей во вконтакте, чем в незаполненном профиле GameCenter. Ну и проще следить за «хакерами», т.к. база у себя на сервере. Если подобные штуки покажутся группе пользователей интересней и народ будет не против потратить 33 рубля за игру, её можно развивать и дальше. Были идеи строить глобальные рейтинги, кто больше набирает. Например, мужчины или женщины, взрослые или подростки. МГУ или МГИМО итп. Все эти данные собираются из соцсетей.

В любом случае, это лишь «проба пера». Больше всего геморроя я заработал прорисовывая иконки в разных размерах. Всего 18 иконок разных размеров + 13 стартовых скринов.

UPD: Что касается законности подобных приложений в AppStore, рекомендую почитать комментарии @mifki, если всё так, как он говорит, то приложению достаточно пройти ревью и его не удалят за использование кода на стороне. Однако, alamantrah утверждает, что его приложение удалили за внешние lua.
Так же на StackOverlow найдено подтверждение, что раньше за внешние скрипты приложение не пускали, однако сейчас политика безопасности поменялась и всё ок.

Источник

Test app and website on iPhone & iOS devices

Easiest way to test mobile apps & websites on an exhaustive range of real iOS devices like iPhone 12, 12 Pro, iPhone 11, X, XS Max, iPhone 8, 7, etc. Say goodbye to your iOS device lab.

Get Started for Free

Latest Devices: iPhone 12, 12 Pro & iPhone 12 Mini, now available on Real Device Cloud for testing. Get Started Free

Trusted by more than 50,000 customers globally

Features

Wide range of iPhone devices

Test your apps and websites on physical mobile iOS devices for most accurate testing results. Choose from our wide range of iOS devices including iPhone 12, 12 Pro, iPhone 11 Pro, iPhone X, XS, XS Max, iPhone 8, iPhone 7, 7 Plus, iPhone 6, 5s, etc.

Real iOS Device Cloud

No need to build or maintain expensive iOS device labs. Instant, browser-based access to the latest and the most popular mobile devices including iPhone, iPad, etc. whenever you want.

Natural gestures

Interact with your website or mobile app on the remote device, just as you would with a device in hand. Tap, scroll, zoom, swipe and more.

Test development environments

Using our local testing feature, test your website and mobile apps, out of the box on internal development and staging environments.

Real-time debugging

Debug your websites & mobile apps, view crash reports and logs, and use stacktrace to find and fix bugs instantly.

Secure and private

Security is a primary focus, and our policies are constantly upgraded. We provide pristine devices for testing and all data is wiped clean from the device after the session ends.

iPhone Devices we support

Frequently Asked Questions

How can I test iOS apps on iPhones with Testflight?

BrowserStack App Live provides the option to install and test iOS apps via TestFlight. Simply follow the steps below to do so:

1. Sign Up for App Live.
2. Log In.
3. Click on View All Sources at the bottom of the menu.
4. Select Install via TestFlight.
5. Choose the iPhone the app must be tested on.
6. Start a test session.

If you have Apple’s Two-factor authentication enabled for your Apple ID, follow the steps below:

• Open the App Store. Click on the Blue User icon on the top right corner of the App Store Home Page.
• Enter your Apple ID and Password.

Note: You will not be able to see passwords being typed in iOS 13+, because, for security reasons, Apple blocks showing the password field during streaming. Simply complete typing the password and proceed to Sign in.

• Enter the verification code when prompted and complete the sign-in.
• OR open the Testflight App, and click ‘Continue’ to view and test your iOS Apps.

For a more detailed explanation, explanation, visit this page.

How to test app on iPhone?

It is essential to test iOS apps on iPhones before releasing them for public download and usage. Given the differences in hardware and software specifications between different iPhones, one cannot expect that an app will work on all iPhones just because they work on a couple of them.

App developers and QAs can test apps on real iPhones with BrowserStack App Live. They simply need to follow the steps below:

1. Sign up Free for App Live
2. Upload the relevant .ipa file
3. Once the App Live dashboard opens, choose the iPhone the app is to be tested on. There will be a vast number of options to choose from.
4. On selecting the phone, the interface will open to offer access to that particular device.
5. Users can choose from a variety of features to run comprehensive tests on their iOS app. For example, they can throttle internet speed to various speeds (2G, 3G, Edge, etc.), change device location, language, capture screenshots, and much more. They can scan through every one of the app’s features to ensure that they are performing as expected, regardless of the iPhone it is used on.
6. Having tested the app on one iPhone, the user can switch to another device directly from this screen itself via the Switch Device option. They do not have to return to the dashboard and start the process all over again.

App Live provides a multitude of features that facilitates thorough app testing for a wide range of real user conditions. Some of these include:

• Testing from multiple sources – direct and URL uploads, beta distribution tool integrations, build tool integrations, App Store installation.
• Test published apps on App Store.
• Test native device features – geolocation testing, network throttling, push notifications, etc.
• Test localized versions of an app.
• Test apps in development environments with Local Testing. Try now.

What is an iPhone Emulator and what is an iPhone simulator?

An iPhone simulator is actually an iOS simulator that mimics an iPhone device. These simulators allow developers and QA testers to do a quick check of their apps and websites on iPhones. The simulators have limited capabilities when running on Windows.

Interestingly, there are no iPhone emulators since Apple devices use custom binaries and proprietary chipsets, which cannot be mimicked. Thus iPhone emulator is just a misnomer.

Why use Real Device Cloud instead of an iPhone simulator?

Real device cloud supports testing of natural gestures, battery consumption, simulate GPS and IP geolocation. QA testers can share bugs via JIRA, Trello, Slack and Developers can replicate these bugs with ease and fix them. You can also integrate using CI/CD plugins with tools like Jenkins, CircleCI etc. BrowserStack provides instant access to real iPhone devices like iPhone X, iPhone 8, iPhone 7 and others. Thus, companies need not compromise by testing on iPhone emulator or simulators and they don’t need to setup expensive real device labs. So, Get Started for Free with iPhone Real Device Cloud.

What are the disadvantages of using an iPhone simulator?

Running iPhone emulator on Windows or Mac, are normally slow

Accuracy of such emulators can be below par/ sub-standard, based on the creator

Limitation towards number of applications that can be supported

Testing on iPhone simulators or emulators can mean compromising on user experience. Simulators cannot mimic the exact performance on a real iPhone device. In fact, Apple recommends testing apps and websites on real devices since simulators cannot mimic all functionalities of the real device. For example, the official Apple iOS simulator does not have the Schoolwork app, which is important to test how Classkit will behave in a real world scenario.

Why do users opt for iPhone simulators (also referred to as iPhone emulator)?

Given iPhone’s high market share and their superior spending capacity, testing on iPhones is a must

Setting up and running a real iPhones device lab is expensive and hence companies prefer simulators

Since tests on iPhone simulators are only used for quick sanity tests, it works well

Why is testing your website and apps on iPhones critical?

iPhones have a 23% global market share. iPhone users are known to spend nearly double of what users of other phones spend. Therefore, ensuring iPhone users get the best user experience is critical.

iPhone runs on Apple’s iOS and users predominantly browse using Safari. iOS behaves differently from Android and Safari supports CSS in a different form versus Chrome, IE. Therefore, testing on iPhones for responsive design and cross browser compatibility is important. Test Now on Real iPhone.

Источник