1 Нет, не у любого. Под санкциями подавляющее меньшинство компаний.
2 и 3 - если iOS разработчику плевать на пользовательский опыт приложения, которое он будет разрабатывать, то вряд ли он хороший и ответственный разработчик. Если таких и ищут, чтобы работал и не задавал вопросы (и сам тоже не пользовался), то вопросов нет.
Идеальных решений не бывает, и в статье хотелось бы услышать и про минусы частых релизов. Озвучу те, что вижу сам:
Release notes, как правило, не будут обновлять каждую неделю и переводить на десятки языков. Это требует усилий как редакторов/маркетологов, так и переводчиков. В итоге release notes превращаются во всеми ненавистные "bug fixes and performance improvements". Проверил - у inDriver в английском сторе примерно так и есть)
Частые релизы подталкивают разработчиков к атомарным мелким PRам и фича-флагам для включения фич. В итоге при ревью контекст кода всей задачи в голове имеет только тот, кто ее реализует, а полного ревью от начала до конца одними и теми же людьми не проводится (как минимум это не энфорсится). В результате в главную ветку может попасть что угодно, если разделить это на достаточно малые части). А обилие фича-флагов мешает пониманию, что в какой сборке приложения есть и в каком качестве - в итоге release notes даже если и будут, то будут бесполезны (фичи могут быть под a/b тестами, выключены/включены у части аудитории, перманентно выключены, но быть в коде и т.п.).
Следствие предыдущего - рост бинарника. Когда PR мелкие и ничего не меняют в боевом приложении (из-за фиче-флагов) их психологически легко принять, и код начинает резко расти. У Убера был кейс, когда приложение росло мегабайтами в неделю. Так же из-за этого сложно вычистить что-то из приложения - сложно понять, не используется ли это, не дописано ли ещё, или уже выпилено выключенным фиче-флагом.
Быстрые релизы не позволяют вносить фундаментальные ломающие изменения в процесс сборки без остановки релиз-поезда хотя бы на время. Когда до релиза три недели, можно сломать весь CI/CD и делать с ним что угодно пару недель. С еженедельными релизами сломать его так не получится. Далеко не всегда можно держать две системы параллельно, и недельные релизы проигрывают при важных изменениях (смена сервиса для переводов, смена провайдера удаленных машин, смена самой платформы, например, на self-hosted или обратно)
Да нет, все считают так. В мире приложений почти все ходовые приложения - нативные. Уже даже стартапы сразу пишут нативные приложения, потому что их потом при росте не нужно будет переписывать на нативные (а пользователи и разработчики обязательно попросят). Самые известные примеры - AirBnb (выкинули React Native) и Slack (переписали с Electron целиком).
В мире игр вообще кроссплатформенности почти нет. На моем маке могу запустить только 10% библиотеки Steam. Если "все считают", что кроссплатформенность нужна, то где версия под мак? Или под линукс без Proton?
Безлимитный отпуск - стандартная американская практика. Очень удобная для работодателя - можно не платить неотгуляный отпуск, разрешается 0 отпуска (раз он безлимитный и снизу тоже, то если никто не сходит, штрафа не будет), ну и peer pressure вынуждает сотрудников реже брать и в итоге не ходить (есть исследования на эту тему недавние почитайте).
Почему же, создаёте main.swift и пишете там что угодно, а потом зовёте UIApplicationMain. Делать так, конечно, не надо, но это же вполне возможно без load/initialize, конструкторов динамических либ и прочей изотерики. При этом создаваемый контейнер может быть и не синглтоном, а инициализировать свои поля может и лениво. А сделать контейнер, не являющийся god object, ещё надо постараться - это для подавляющего числа приложений (даже сложных) просто непрактично.
Например, в первом iPhone не было настоящей многозадачности не только из-за малой оперативной памяти, но и из-за отсутствия виртуальной памяти
Неверно, перечитайте исходные твиты. В первом iPhone была многозадачность, это был по сути OS X и на это был упор в маркетинге. Чего не было - доступности этой многозадачности в оболочке UI, но частично она все же была (можно было слушать музыку в iPod и скроллить Safari, например).
"Отсутствие виртуальной памяти" - тоже неправда, она конечно же была. Не было свопа (и в iOS, watchOS, tvOS его нет до сих пор). Оригинальные твиты именно про это, полагаю на написание их сподвиг автора именно анонс свопа в iPadOS 16.
Инженерам пришлось создать систему, известную как «jetsam», чтобы заставить iPhone запускать одно приложение за раз, автоматически завершая другие фоновые процессы, чтобы избежать проблем с производительностью.
Jetsam есть и сейчас, и принцип его не в "одном приложении за раз", а в убийстве фоновых (а в крайнем случае и активных) жрущих память задач.
В общем, проще перечитать исходные твиты, или перевести их буквально.
Благодарю за ответ! Жду следующих статей. В интернете сейчас мало информации по теме, за пределами простейших примеров мало кто ходит, а в продакшене и того меньше можно встретить.
В официальной документации, сессиях WWDC и книге SPL термин "корутина" не встречается. Думаю, неспроста. Не сбивайте людей, потому что корутины в Свифте официально так не называются.
Википедию может редактировать кто угодно, это не аргумент. Многозадачность у них все-таки вытесняющая - в любой момент выполняющийся на ядре код может быть приостановлен операционной системой. Не забывайте, что Darwin не DOS. Вытеснения нет только от других таких же "partial tasks", и кооперация у них только между собой, а не на уровне потоков ОС.
Фундаментального отличия от Kotlin нет, но есть мелкие, которые очень важны - компиляция (аналога Sendable, насколько я понял, нет, то есть компилятор полезть в shared state запретить не сможет, особенно если через java/инструментацию), в Свифте нельзя управлять Executor'ами, в отличие от котлина (попробуйте, например, заставить таски выполняться на нужных потоках в нужном порядке - в Свифте это сейчас невозможно), ну и вместо каналов используется совсем иная идея с акторами.
Может, в чем-то неточен, на котлине ежедневно не пишу, но в целом различия для меня достаточно разительные и влияют на ежедневную мобильную разработку непосредственно - точно управлять потоками в тестах, например, необходимо очень часто. Вы пишете "мы можем приостанавливать задачи и продолжать их исполнение", но на деле в Свифте "мы" мало что можем, все partials отдаются компилятору как есть и влияние на них программиста ограничивается cancel'ом и yield'ом. В котлине поближе к народу все-таки.
Как введение статья хорошая, однако разбор понятий concurrency и parallelism здесь приделан как-то сбоку и вообще непонятно, зачем нужен.
То же самое про корутины. В официальной документации и литературе по теме (Modern Swift Concurrency от Ray Wenderlich, например) этот термин не используется.
В голове от этого может сложиться ложное впечатление о связи свифтовского async/await с корутинами в Go и Kotlin, когда как на деле кроме синтаксиса в них мало что похоже.
Я про нетривиальность и сложность ничего не писал. Я писал про скучность.
Разрабатывать браузер тоже нетривиально и сложно (для мобильного разработчика), но ужасно скучно (по крайней мере для меня). А BDUI - это по сути и есть браузер.
А ещё красить кнопки и менять строки тоже может быть нетривиальной и сложной задачей, особенно "чем больше проект". Например, сделать нормальную дизайн-систему, способную пережить редизайн, или изобрести палитру, работающую со всеми кнопками, которые ей нужно покрасить, во всем многообразии экранов и настроек accessibility.
Только разрабатывая дизайн-систему, ты все-таки больше iOS-разработчик, а разрабатывая BDUI, ты больше разработчик движка рендеринга своего нигде больше не используемого языка. Для меня выбор очевиден.
Я, например, пишу на iOS. Нет гарантий, что завтра приложение не испарится из стора, как часть других приложений сбера. Мало убрать Сбер из названия, надо выкупаться, иначе рано или поздно все забанят. Уверен, вы уже со слака внутри слазите. А завести полноценную слушалку через браузер будет невозможно.
Новой (зарубежной) музыки в Звуке нет, и пока нет причин, что это изменится. Еще несколько месяцев, и мне эта подписка не нужна будет даже бесплатно.
Удобство приложения такое, что проще закачивать себе mp3 и слушать через VLC. Ни одна статья вроде такой не сделает рекламы лучше, чем само приложение. Нормально сделаете - люди сами прибегут.
Backend-driven UI для мобильного разработчика - абсолютное зло, которое превращает нативщика, учитывающего тонкие детали и отличия платформы в создателя очередного парсера.
Некоторые BDUI даже с сервера получают layout и реализуют свой декларативный велосипед для его отображения, собирая те же грабли, что html, RelativeLayout, autoresizing masks и другие достижения UI-рендеринга прошедших десятилетий.
Зло, конечно же, необходимое, но для меня скучнее работы, чем описанная в статье, придумать сложно. Завлечь разработчика такой, по-моему, будет трудно.
Конечно, все улучшается и проблемы решаемые, мой пойнт в том, что сейчас лондонское метро - это не круто (по сравнению с другими городами Европы и России). Как угодно можно обосновывать и ждать улучшений, но для меня пока так.
Да и скорость этих изменений удручающая - за период 2011-2021 в Москве открылось более 60 новых станций, без учета новых платформ между существующими.
Тем временем в Лондоне за тот же срок открылось... две.
Про 60 дней и переоформление визы не знал, спасибо. Хотя 60 дней все равно маловато, местный рынок небыстро ворочается.
Аргумент про Glassdoor вообще не понял. Я думал, и так всем известно, что работать в Амазоне, Accenture и визе - полный треш, зайдите хотя бы на blind и убедитесь в этом. И когда у них рейтинг такой же как у свежих стартапов, мне в них работать не хочется.
Есть куча компаний с рейтингом 4+. Как и в любой системе отзывов, смотреть надо на самые полярные мнения.
Точно знаю, что берут. У меня в команде новый прóдукт вот делает визу из Москвы в UK, одногруппники спокойно нашли в марте работу в Нидерландах, Сербии, Великобритании, Франции, кто-то уже уехал. Сам собеседую ребят из России почти ежедневно и никаких визовых ограничений сейчас нет (кроме пары европейских стран).
Выборка: у всех по 3-5 лет опыта, мобильные и бэкенд-разработчики, никто не из Яндекса или прочих топкомпаний. Разве что английский у всех выше среднего.
А хорошие выходные пособия, длинный notice period и другие условия вы получите только в ЕС, но с большей вероятностью в том же Революте вы будете работать в офисе UK, где вас даётся 60 дней на поиск новой работы и переоформление визы, так что попасть в просак про увольнении все же более чем реально.
Раз метро старое - то и возможностей сделать по-нормальному гораздо больше было. За 160 лет можно было и перекопать туннели, и расширить платформы, починить семафоры и обновить технологии. Хотя бы до уровня 1986 года.
Странно сейчас "рассматривать для трудоустройства" Кларну, в которой на днях сократили 10% сотрудников для оптимизации расходов.
Или револют, который собирается запустить свою крипту (или токен), но в то же время не может получить банковскую лицензию нигде, кроме Литвы. Зато приложение красивое.
Или N26, который через пару месяцев после выхода на американский рынок ушёл с него, не осилив.
В общем, призываю четко понимать, куда подаёте заявки, за красивыми числами не всегда радужно.
1 Нет, не у любого. Под санкциями подавляющее меньшинство компаний.
2 и 3 - если iOS разработчику плевать на пользовательский опыт приложения, которое он будет разрабатывать, то вряд ли он хороший и ответственный разработчик. Если таких и ищут, чтобы работал и не задавал вопросы (и сам тоже не пользовался), то вопросов нет.
Идеальных решений не бывает, и в статье хотелось бы услышать и про минусы частых релизов. Озвучу те, что вижу сам:
Release notes, как правило, не будут обновлять каждую неделю и переводить на десятки языков. Это требует усилий как редакторов/маркетологов, так и переводчиков. В итоге release notes превращаются во всеми ненавистные "bug fixes and performance improvements". Проверил - у inDriver в английском сторе примерно так и есть)
Частые релизы подталкивают разработчиков к атомарным мелким PRам и фича-флагам для включения фич. В итоге при ревью контекст кода всей задачи в голове имеет только тот, кто ее реализует, а полного ревью от начала до конца одними и теми же людьми не проводится (как минимум это не энфорсится). В результате в главную ветку может попасть что угодно, если разделить это на достаточно малые части). А обилие фича-флагов мешает пониманию, что в какой сборке приложения есть и в каком качестве - в итоге release notes даже если и будут, то будут бесполезны (фичи могут быть под a/b тестами, выключены/включены у части аудитории, перманентно выключены, но быть в коде и т.п.).
Следствие предыдущего - рост бинарника. Когда PR мелкие и ничего не меняют в боевом приложении (из-за фиче-флагов) их психологически легко принять, и код начинает резко расти. У Убера был кейс, когда приложение росло мегабайтами в неделю. Так же из-за этого сложно вычистить что-то из приложения - сложно понять, не используется ли это, не дописано ли ещё, или уже выпилено выключенным фиче-флагом.
Быстрые релизы не позволяют вносить фундаментальные ломающие изменения в процесс сборки без остановки релиз-поезда хотя бы на время. Когда до релиза три недели, можно сломать весь CI/CD и делать с ним что угодно пару недель. С еженедельными релизами сломать его так не получится. Далеко не всегда можно держать две системы параллельно, и недельные релизы проигрывают при важных изменениях (смена сервиса для переводов, смена провайдера удаленных машин, смена самой платформы, например, на self-hosted или обратно)
Да нет, все считают так. В мире приложений почти все ходовые приложения - нативные. Уже даже стартапы сразу пишут нативные приложения, потому что их потом при росте не нужно будет переписывать на нативные (а пользователи и разработчики обязательно попросят). Самые известные примеры - AirBnb (выкинули React Native) и Slack (переписали с Electron целиком).
В мире игр вообще кроссплатформенности почти нет. На моем маке могу запустить только 10% библиотеки Steam. Если "все считают", что кроссплатформенность нужна, то где версия под мак? Или под линукс без Proton?
Безлимитный отпуск - стандартная американская практика. Очень удобная для работодателя - можно не платить неотгуляный отпуск, разрешается 0 отпуска (раз он безлимитный и снизу тоже, то если никто не сходит, штрафа не будет), ну и peer pressure вынуждает сотрудников реже брать и в итоге не ходить (есть исследования на эту тему недавние почитайте).
Почему же, создаёте main.swift и пишете там что угодно, а потом зовёте UIApplicationMain. Делать так, конечно, не надо, но это же вполне возможно без load/initialize, конструкторов динамических либ и прочей изотерики. При этом создаваемый контейнер может быть и не синглтоном, а инициализировать свои поля может и лениво. А сделать контейнер, не являющийся god object, ещё надо постараться - это для подавляющего числа приложений (даже сложных) просто непрактично.
Неверно, перечитайте исходные твиты. В первом iPhone была многозадачность, это был по сути OS X и на это был упор в маркетинге. Чего не было - доступности этой многозадачности в оболочке UI, но частично она все же была (можно было слушать музыку в iPod и скроллить Safari, например).
"Отсутствие виртуальной памяти" - тоже неправда, она конечно же была. Не было свопа (и в iOS, watchOS, tvOS его нет до сих пор). Оригинальные твиты именно про это, полагаю на написание их сподвиг автора именно анонс свопа в iPadOS 16.
Jetsam есть и сейчас, и принцип его не в "одном приложении за раз", а в убийстве фоновых (а в крайнем случае и активных) жрущих память задач.
В общем, проще перечитать исходные твиты, или перевести их буквально.
Меня вымораживает подобный прикол. Позиционирует себя как "страна мигрантов", но для переезда все равно хочет местный опыт работы.
В других странах такого не наблюдается, "местный опыт" или "местное образование" даёт формальные преимущества почему-то именно в Канаде.
Благодарю за ответ! Жду следующих статей. В интернете сейчас мало информации по теме, за пределами простейших примеров мало кто ходит, а в продакшене и того меньше можно встретить.
В официальной документации, сессиях WWDC и книге SPL термин "корутина" не встречается. Думаю, неспроста. Не сбивайте людей, потому что корутины в Свифте официально так не называются.
Википедию может редактировать кто угодно, это не аргумент. Многозадачность у них все-таки вытесняющая - в любой момент выполняющийся на ядре код может быть приостановлен операционной системой. Не забывайте, что Darwin не DOS. Вытеснения нет только от других таких же "partial tasks", и кооперация у них только между собой, а не на уровне потоков ОС.
Фундаментального отличия от Kotlin нет, но есть мелкие, которые очень важны - компиляция (аналога Sendable, насколько я понял, нет, то есть компилятор полезть в shared state запретить не сможет, особенно если через java/инструментацию), в Свифте нельзя управлять Executor'ами, в отличие от котлина (попробуйте, например, заставить таски выполняться на нужных потоках в нужном порядке - в Свифте это сейчас невозможно), ну и вместо каналов используется совсем иная идея с акторами.
Может, в чем-то неточен, на котлине ежедневно не пишу, но в целом различия для меня достаточно разительные и влияют на ежедневную мобильную разработку непосредственно - точно управлять потоками в тестах, например, необходимо очень часто. Вы пишете "мы можем приостанавливать задачи и продолжать их исполнение", но на деле в Свифте "мы" мало что можем, все partials отдаются компилятору как есть и влияние на них программиста ограничивается cancel'ом и yield'ом. В котлине поближе к народу все-таки.
Как введение статья хорошая, однако разбор понятий concurrency и parallelism здесь приделан как-то сбоку и вообще непонятно, зачем нужен.
То же самое про корутины. В официальной документации и литературе по теме (Modern Swift Concurrency от Ray Wenderlich, например) этот термин не используется.
В голове от этого может сложиться ложное впечатление о связи свифтовского async/await с корутинами в Go и Kotlin, когда как на деле кроме синтаксиса в них мало что похоже.
Я про нетривиальность и сложность ничего не писал. Я писал про скучность.
Разрабатывать браузер тоже нетривиально и сложно (для мобильного разработчика), но ужасно скучно (по крайней мере для меня). А BDUI - это по сути и есть браузер.
А ещё красить кнопки и менять строки тоже может быть нетривиальной и сложной задачей, особенно "чем больше проект". Например, сделать нормальную дизайн-систему, способную пережить редизайн, или изобрести палитру, работающую со всеми кнопками, которые ей нужно покрасить, во всем многообразии экранов и настроек accessibility.
Только разрабатывая дизайн-систему, ты все-таки больше iOS-разработчик, а разрабатывая BDUI, ты больше разработчик движка рендеринга своего нигде больше не используемого языка. Для меня выбор очевиден.
Это все, конечно, круто, но рискованно.
Я, например, пишу на iOS. Нет гарантий, что завтра приложение не испарится из стора, как часть других приложений сбера. Мало убрать Сбер из названия, надо выкупаться, иначе рано или поздно все забанят. Уверен, вы уже со слака внутри слазите. А завести полноценную слушалку через браузер будет невозможно.
Новой (зарубежной) музыки в Звуке нет, и пока нет причин, что это изменится. Еще несколько месяцев, и мне эта подписка не нужна будет даже бесплатно.
Удобство приложения такое, что проще закачивать себе mp3 и слушать через VLC. Ни одна статья вроде такой не сделает рекламы лучше, чем само приложение. Нормально сделаете - люди сами прибегут.
Статья огонь! Приятно видеть, что навигатор догоняет лучшие мировые решения и перегоняет их.
(Однако идея вставлять в статью панорамы от главного конкурента - не самая лучшая, надеюсь, это троллинг)
Backend-driven UI для мобильного разработчика - абсолютное зло, которое превращает нативщика, учитывающего тонкие детали и отличия платформы в создателя очередного парсера.
Некоторые BDUI даже с сервера получают layout и реализуют свой декларативный велосипед для его отображения, собирая те же грабли, что html, RelativeLayout, autoresizing masks и другие достижения UI-рендеринга прошедших десятилетий.
Зло, конечно же, необходимое, но для меня скучнее работы, чем описанная в статье, придумать сложно. Завлечь разработчика такой, по-моему, будет трудно.
Конечно, все улучшается и проблемы решаемые, мой пойнт в том, что сейчас лондонское метро - это не круто (по сравнению с другими городами Европы и России). Как угодно можно обосновывать и ждать улучшений, но для меня пока так.
Да и скорость этих изменений удручающая - за период 2011-2021 в Москве открылось более 60 новых станций, без учета новых платформ между существующими.
Тем временем в Лондоне за тот же срок открылось... две.
Про 60 дней и переоформление визы не знал, спасибо. Хотя 60 дней все равно маловато, местный рынок небыстро ворочается.
Аргумент про Glassdoor вообще не понял. Я думал, и так всем известно, что работать в Амазоне, Accenture и визе - полный треш, зайдите хотя бы на blind и убедитесь в этом. И когда у них рейтинг такой же как у свежих стартапов, мне в них работать не хочется.
Есть куча компаний с рейтингом 4+. Как и в любой системе отзывов, смотреть надо на самые полярные мнения.
Точно знаю, что берут. У меня в команде новый прóдукт вот делает визу из Москвы в UK, одногруппники спокойно нашли в марте работу в Нидерландах, Сербии, Великобритании, Франции, кто-то уже уехал. Сам собеседую ребят из России почти ежедневно и никаких визовых ограничений сейчас нет (кроме пары европейских стран).
Выборка: у всех по 3-5 лет опыта, мобильные и бэкенд-разработчики, никто не из Яндекса или прочих топкомпаний. Разве что английский у всех выше среднего.
Вот и проверьте рейтинги.
Revolut: 3.9
Monzo: 3.7
N26: 3.4
Klarna: 3.8
Starling: 3.9
А хорошие выходные пособия, длинный notice period и другие условия вы получите только в ЕС, но с большей вероятностью в том же Революте вы будете работать в офисе UK, где вас даётся 60 дней на поиск новой работы и переоформление визы, так что попасть в просак про увольнении все же более чем реально.
Я с этим и не спорю.
Раз метро старое - то и возможностей сделать по-нормальному гораздо больше было. За 160 лет можно было и перекопать туннели, и расширить платформы, починить семафоры и обновить технологии. Хотя бы до уровня 1986 года.
Странно сейчас "рассматривать для трудоустройства" Кларну, в которой на днях сократили 10% сотрудников для оптимизации расходов.
Или револют, который собирается запустить свою крипту (или токен), но в то же время не может получить банковскую лицензию нигде, кроме Литвы. Зато приложение красивое.
Или N26, который через пару месяцев после выхода на американский рынок ушёл с него, не осилив.
В общем, призываю четко понимать, куда подаёте заявки, за красивыми числами не всегда радужно.