Пытаюсь стать Swift-разработчиком… Ничего личного, просто бизнес… Ну, и понятно, что целевая платформа находится в экосистеме Apple.

Так вот – не так красив чорт как его рисуют! Начать решил с macOS – т.к. стояащая идея приложения имеется под неё. И, как оказалось, хрен вы где найдёте хороших гайдов под это дело! Вот под iOS – вагон и маленькая тележка, и в хвост и в гриву! Но вот с десктопом всё намного плачевнее. Кое-что есть, но никакого сравнения с мобильной осью! Просто крупицы информации…

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

На данный момент приложение вполне себе запускается и делает примерно половину от нужного. Это приложение для меню-бара. Меню-бар такая хрень сверху, которая в других системах называется треем с панелью задач. Здесь это глобальнео меню + область уведомлений. Вот в эту област можно пихать свои приложения. Но приложения менюбар-онли не рекомендуются, т.к. меню имеет приоритет и если у вас куча приложений в области уведомлений, а меню активного приложения не помещается – область уведомлений будет сужена и часть приложений станет не видна.

Нас эта проблема не касается, т.к. суть приложения быть там. И примеры для создания такого приложения имеются: https://www.raywenderlich.com/450-menus-and-popovers-in-menu-bar-apps-for-macos

Проблема в другом – в интерфейсе! Казалось бы самая восхваляемая часть платформы очень коряво документирована. Для языка Swift по-крайней мере. Т.е. есть референсные доки к AppKit, но референсные доки это такое себе подспорье, когда ты толком не понимаешь к какому месту их прикладывать. В общем нужны гайды, а вот гайдов по построению интерфейсов для macOS практически нет. А те что есть по кругу рассказывают одну и ту же песню про базовое использование редактора интерфейсов.

Моя же проблема в необходимости динамического вывода и скрытия элементов. Это я даже победил. Но что пока остаётся непобеждённым – изменение размеров поповера, особенно после удаления в нём элементов. Т.е. расти-то он растёт при добавлении, а вот сужаться при удалении не хочет…

В общем есть всякие сторонние библиотеки для управления интерфейсом, но с первых дней не хочется пускаться во все тяжки и заменять всё подряд на “более чоткие версии”. Хочется сделать сначала как по учебнику (которого нет, бялд), а потом уже думать и сравнивать…

Накидаю завтра чё-нить полезное про использование NSStackView с добавлением/удалением внутрь NSButton и ограничения их (кнопок) размера через NSLayoutConstraint!

Ну, или потом накидаю всё вместе… 🤔

#swift #macos #ui

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

#swift #macos #ui

Есть один герой наваявший больше сотни видосов (ладно хоть так) по разработке под macOS:

https://medium.com/macos-app-development/100-days-of-osx-development-e61591fcb8c8

Собсна плейлист непосредственно: https://www.youtube.com/watch?v=G552ChPH82U&list=PLU03ExiIcAUsqTHAiZTY-zV8B5bfRHqg9

#swift #macos

NSButton с многострочной надписью:

https://telegra.ph/NSButton-with-multiline-label-09-30

#macos #swift #ui

Самое геморное в этом всём вашем десктоп девелопменте – это потрахиньо с интерфейсами (имеются в виду те что к людям, а не API). Как только начинаешь выводить их руками начинается секас с пикселями, отсутпами, изменениями размеров и т.п. В общем то ещё веселье… Конечно в итоге всё довольно мило (это я ещё не слышал критики заказчика 😉), но сколько это отняло времени! Надеюсь дальше пойдёт побыстрее, т.к. примерный принцип вывода всей этой лабуды на экран ясен.

По времени:
- неделя на чтение https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html (можно бесплатно скачать в эплокнигах в виде книги)
- неделя на разработку, при том что на работу с данными ушло пару дней, а на вывод их и взаимодействие юзера с ними – все 5 😅

В итоге первая сборка с половиной функционала отъехала к заказчику.

#macos #swift

NSScrollView – потрахамшись… Делаю так чтобы сама область скролинга до определённых размеров росла вместе с контентом, после чего появлялся бы скролл. В обратном порядке тоже – сначала сжимается контент, при исчезании скрола вся область сжимается вслед за ним. Навеселившись с разными вариациями констрэйнтов пришёл к версии когда самый внутренний вид идущиий вместе с NSScrollView (тот что просто NSView, а не NSClipView ) биндится нулевыми отступами к содержимому и при изменении содержимого мы ресайзим именно этот "просто вид" руками. Он изменяет за собой содержимое через констрэйнты и корректно влияет на скролл. Ну а сама область снаружи как обычный вид биндится к окружению как нужно.

Да, XCode показывает красное предупреждение в сториборде при таком раскладе, но похоже это полная хрень, т.к. ни при сборке ни при использовании ошибок не вылетает.

#macos #swift #ui

О Swift – не покидает ощущение искуственности языка. Т.е. как бы Apple не выставляла его опенсорсным и универсальным – сам по себе язык и то что из него компилируется мало пригоден к современным реалиям без сторонних библиотек. А точнее без библиотек написанных Apple для своих систем. Потому что та же многопоточность делается на уровне этих библиотек, которые не попадают в опенсорс поставку. В отличие от того же Go или Rust.

Такие вещи как аттрибуты, такой синтаксический сахар начинающиеся с @. Очень напоминают по функционалу декораторы Python, но их нельзя создавать самому! Т.е. они типа есть в языке как зарезервированные слова, но – зачем в опенсорс версии @available("macOS") при отсутствующем @available("linux") например? 🙂

В разработке же под экосистему Apple язык кажется просто осовремененным интерфейсом в Objective-C, а никак не самодостаточным языком разработки. Всё-таки интересно будет посмотреть когда все SDK будут переписаны на Swift, появится возможность создавать свои аттрибуты и в стандартную библиотеку войдёт многопоточность (в последнем очень сомневаюсь).

Впрочем отсутствие встроенной многопоточности не мешает не таким избалованным разрабам как я вполне успешно использовать сторонные решения: kitura.io web фреймворк на swift… Судя по бейджикам в репозитории он должен работать под linux.

#blog #swift

За несколько часов добил оставшийся функционал. Удивительно ускорился процесс, учитывая как мало ещё опыта в разработке под macOS! Всё-таки возможности структурирования кода в Swift существенно облегчают рефакторинг и расширение функционала.

#blog #swift

И есть идея ещё одного приложения – по ходу пьесы попробуем осилить разработку без стоирборда и вывод текста в менюбар.

#blog #swift #macos

Создание .dmg оказалось задачей тривиальной, хотя, почему-то, не встроенной в XCode – делается сторонними утилитами.

А вот автозапуск приложения при входе в систему сопротивляется. Удивительная муть с приложением-хелпером которое находится в правильной папке, регается основным приложением как запускаемое при входе и оно уже запускает основное приложение… Руками проверяю – всё ок, а когда захожу в систему – ничего не происходит… Может что-то в сендбоксе, как это было с сетью.

https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLoginItems.html

#blog #swift #macos

Автозапуск вроде заработал, хотя не до конца уверен в некоторых косяках. То ли надо чистить папку сборки постоянно, то-ли я ещё что-то не учёл…

#macos #swift

Штош, разработка есть, упаковки для дистрибуции есть, локализация есть… Остаётся тестирование и можно идти в коммерческую разработку.

Не смотря на мелкие косяки, разработка на Swift, оставляет очень позитивное впечатление. Косяки действительное мелкие, если бы на всех платформах были только такие проблемы - мир ПО был бы совершенно другим. По той же причине понятно, почему под macOS софт для пользователя пишется, а под Linux - когда есть коммерческая целесообразность или мотивированность. Всё-таки проблем, которые нужно будет решить для предоставления пользователю возможности юзать твой софт под линуксом несравненно больше. И главная проблема в том что вместо разработки собственно продукта придётся тратить время именно на войну с проблемами окружения…

В экосистеме Apple в 99% ты просто берёшь и делаешь продукт. Можно сказать рай для разработчика. Наверняка это просто эйфория после вакханалии опенсорса и я ещё хлебану проблем с запрещёнными API и прочими обновлениями требований. Но пока что это выглядит так, что если вы готовы играть по правилам и не хотите тратить время на построение сопутствующей экосистемы - Swift под Apple это то что нужно.

Ну и всё это сопровождение разработки и обеспечение базовыми фреймворками - это очень хороший пример для подражания.

#blog #macos #swift

Просмотрел 3 доклада WWDC по тестированию – запись UI действий это прям огонь! Осталось написать тестов к своему приложению… Тяну резину 🙂 Они же навернякак вскроют косяки которые придётся править, а это опять топтание на месете. Собственно единственный минус тестов – заставляют топтаться на месте, когда хочется нестись вперёд и волосы назад… Но сколько багов они вскрывают и не позволяют им повториться – это, конечно, дорогого стоит!

#blog #swift

Немного уткнулся в тестирование при использовании Core Data. Там же всё автоматом… На столько, что даже не знал где вообще у меня лежат данные. Так что когда решил сменить Build ID приложения пришлось покопаться с миграцией (приложение в sandbox'e, это такой "chroot искаропке" если вы понимаете о чём я) ибо с новым ID стары данные успешно испарились...

Разрулил предусмотренным средством миграции в сэндбокс версию. Она работает и для миграции между сэндбоксами, как оказалось. Возможно ей можно спереть данные другого приложения (с другой девелоперской подписью) - надо проверить...

Гуглить: "container-migration.plist".

Пример:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Move</key>
 <array>
  <array>
   <string>${Library}/Containers/<otherAppBuildID>/Data/Library/Application Support/<appName></string>
   <string>${ApplicationSupport}/<appName></string>
  </array>
 </array>
</dict>
</plist>

#swift #macos #sandbox #coredata

Ах, да, отвлёкся на интересную мысль, начал же предыдущий пост про тестирование – так вот, кажется решение примерно такое: юзать во время тестирование БД в памяти… В общем попробуем этим путём – там посмотрим…

https://robkerr.com/flexible-and-easy-unit-testing-of-coredata-persistence-code-2b2cf456cfae

ЗЫЖ с моей колокольни выглядит сложновато, мы же можем менять опции инициализации контейнера данных в зависимости от тех же переменных окружения… Определить что мы в режиме тестирования и юзать память вместо диска… Или это не Apple-way?

Но в любом случае надо ставить на setUp чистку хранилища.

#swift #macos #coredarta #test

С моей колокольни сложновато - потому что я в принципе не так юзал Core Data… Сделаю-ка я лучше как умные люди советуют!

#swift #macos #coredata #test

Всем единственному подписчику (каждый который из них — это я) сообщаю. Докатился я до приобретения членства Apple Developer… Деньги списались, подтверждение будет в течение двух суток. После чего смогу протестировать на устрйостве и зарелизить первое приложение.

#apple #swift #ios

Штош. Этот момент наступил – первый самостоятельный релиз "коммерческого продукта" в официальном магазине приложений! В жизни! ☝️🏻👴🏻

Учитывая что "в индустрии" я, грубо говоря, с 92 года, а в коммерческой разработке с 2007 — то как-то долго тянулась резина… На самом деле, многие знают это чуство, идей было много, но они никогда не доводятся до конца. В этот раз я решил всё сделать по-другому.

Банально, но я решил сделать MVP. Не продумывать "покорителя рынка" и пилить до второго пришествия. Не победить всех и во всём. Не делать супериуниверсальный комбайн под любое стечение обстоятельств. А сделать максимально порезаный и ограниченный продукт.

Если честно, то получилось немного больше чем "максимально порезаный и ограниченный продукт". Например опции редактирования в начальной версии не планировалиь (дыа, у меня даже есть багтрекер с задачами). Но в основном это заслуга фреймворков и Swift… Это было слишком просто, чтобы не сделать это сейчас 😁 В итоге за несколько недель эпопея с разработкой была звершена и доведена до публикации в магазине. Были некоторые шероховатости, про которые, возможно, будет отдельный пост, но потом.

Спасибо брату за дизайн иконки и советы. Спасибо Артёму Новичкову за консультации по разработке. Как напродаётся на пиво — обязательно проставлюсь 🙃

Итак, без дальнейших разглагольствований представляю вам:

Stream Note

Приложение для стримеров. А точнее для быстрого сохранения меток к стриму. Добавляете нужные кнопки (можно использовать эмоджи) и жмёте их в нужный момент. Типа поржал — нажал смеющийся смайлик, задумался — нажал задумчивый смайлик.

Слайдером можно выбрать как давно момент наступил. Типа кто-то анектот травил минуту — сдвинул на 60 секунд и нажал ржущий смайлик. На 60 секунд назад будет сохранено начало метки с этим смайликом. Продолжительность метки будет эти самые 60 секунд. Т.е. от минуты назад по настоящий момент у вас будет метка что тут было что-то смешное.

Потом эти метки можно выгрузить как субтитры в формате SRT и загрузить/импортировать в видеоредактор (даже YouTube принимает этот формат сабов!). Смысл в том, что видеоредакторы показывают субтитры отдельной дорожкой. И по блокам начала-конца метки в субтитрах легко найти место в видео где у вас был тот или иной момент!

#apple #swift #ios #streamnote

https://apps.apple.com/ru/app/stream-note/id1466957432