Проєкт на вихідні, який затягнувся
Всім привіт!
Мене звати Олексій і я розробляю інструмент для дебаггінгу SwiftData.
Два роки тому Apple представила новий осучаснений фреймворк для збереження даних — SwiftData. Того ж року вони також представили новий механізм синхронізації з CloudKit — CKSyncEngine. Оскільки вбудована підтримка синхронізації у SwiftData була дуже лімітована, я вирішив створити свій механізм на основі CKSyncEngine. Ідея здавалася цікавою, доки не дійшло до дебагінгу стану бази — і стало трохи боляче.
Тоді я вирішив знайти інструмент, щоб дивитися все, що відбувається під час синхронізації, із зручним UI. Передивившись, що є в App Store, я зрозумів, що бачу дві категорії інструментів: занадто дорогі для разового дебагу і занадто трешові, щоб я хотів за них платити. Тож за пару вечорів я зробив власний, простий, як двері інструмент. Коли я нарешті відкрив початковий проєкт і почав синхронізацію, за менш ніж хвилину знайшов дві проблеми. Я усвідомив, що хоч інструмент і простий, але вже приносить користь, тож втратив інтерес до коду синхронізації й переключився на полішинг інспектора для публікації в App Store.
Перший реліз також був доволі базовим в імплементації — повністю на SwiftUI, просто мапить NSManagedObject і показує дані. Але я усвідомив одну проблему — SwiftUI на macOS це щось недієздатне: просте відображення таблиці займає неадекватну кількість часу, а скролл лагає (З апдейтом macOS 15.4 ситуація стала значно кращою). Такі фідбеки зачепили мене за живе, і я вирішив, що моя місія як дева — зробити щоб все працювало швидко.
Коротка спроба з AppKit показала, що з цим також є проблеми, а фіксити констрейнти в давньому UI-фреймворку не той тип активності, яким я хотів би займатися з цікавості. Тому єдиний адекватний варіант — кастомний рендерінг таблиці на основі Metal і UI-фреймворку на Rust 😀. Про це я вже писав детально, кому цікаво можете почитати тут.
Після цього я більше не бачив UI-лагів у таблиці, але список моделей у боковій панельці все ще підлагував, бо для List на macOS показати список текстів то важка задача.
Отже, в мене тепер частина UI на Rust, і я вирішив спробувати переписати ще дещо та порівняти перфоманс. Я переписав мапінг даних із прямим interop між Rust і Objective-C — і швидкість обробки даних теж значно зросла. Досі не впевнений, чи то менша кількість retain/release-ів через мануальний менеджмент пам’яті, чи то менша кількість коллів загалом через бріджи. З цього моменту я розширив спектр пошуку бібліотек ще на одну популярну мову, що дало більше можливостей для додатку, але описати все в одному повідомленні складно, а я навіть не впевнений, чи хтось дійде сюди.
Окремо додам, що найважчою фічею стала фільтрація з Predicate-макросом і комфортною підсвіткою коду з автокомплітом, але ця історія дуже довга й досі триває. Наразі я імплементував усі можливі білдери та примітивні типи. Сподіваюся, хтось оцінить мої старання.
Ось такий проєкт на «вихідні», який затягнувся вже на шість місяців, і беклог якого роздувся до неможливого. Я навіть ледь не імплементував «Minecraft mode» на перше квітня. Хто б не хотів подовбати свої дані кіркою! 😂
Дякую, якщо ви дочитали до кінця або просто скачали додаток.
Буду радий будь-якому фідбеку, особливо позитивному!
Цей допис створено для рубрики #проектизкомюніті у телеграм-каналі @bwswift
Немає коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів