Уявіть: користувач створює повторювану зустріч у Москві, а через 2 години бачить її в Берліні в неправильний день і на годину раніше. Це — реальна помилка, яку ми виправляли у клієнта зі сфери HR. Коректна обробка часових поясів, синхронізація з системним календарем і повторювані події — три кити надійного планувальника. За 5 років ми набили гулі на 30+ проектах. Реалізація календаря та планувальника в мобільному додатку — наша спеціалізація. Ми гарантуємо якість і надаємо сертифікати на всі рішення.
Вибір бібліотеки для календаря та планувальника
У 80% проектів вистачає готової бібліотеки. Для iOS UIKit використовуйте FSCalendar з кастомізацією через appearance API. У SwiftUI простіше написати свою обгортку на LazyVGrid або взяти swift-calendar. На Android kizitonwose/calendar підтримує Jetpack Compose. Для Flutter table_calendar з 2000+ stars покриває базові сценарії. FSCalendar працює в 1.5 рази швидше за JTAppleCalendar, а table_calendar в 2 рази швидше за syncfusion_flutter_calendar.
Власна реалізація виправдана тільки при нестандартному дизайні або тисячах подій — вона в 2–3 рази дорожча за часом, але дає повний контроль.
Як обробляти часові пояси без багів?
Зберігайте дати в UTC (ISO 8601, наприклад 2023-03-15T14:30:00Z). Конвертуйте в локальний час тільки при відображенні. На iOS використовуйте Calendar(identifier: .gregorian) з timeZone = TimeZone.current. Для фіксованих подій задавайте timeZone явно.
На Android застосовуйте java.time.ZonedDateTime (API 26+) або ThreeTenBP. Уникайте java.util.Date — він став джерелом 80% часових багів у наших аудитах.
Чому повторювані події — це складно?
Стандарт iCalendar (RFC 5545) вимагає RRULE. Приклад: FREQ=WEEKLY;BYDAY=MO,WE,FR. Ми зберігаємо правило та список винятків (EXDATE) у базі, а екземпляри обчислюємо на льоту для діапазону відображення. Це економить до 30% часу обробки порівняно з генерацією всіх екземплярів.
Apple's EventKit повністю підтримує RRULE через EKRecurrenceRule. Для кастомного сховища підійдуть ical4j (JVM) або RRuleSwift.
Синхронізація з системним календарем
На iOS — запит дозволу EKEntityType.event, робота через EKEventStore. На Android — CalendarProvider з ContentResolver. Синхронізація двостороння: слухайте EKStoreChangedNotification на iOS та ContentObserver на Android.
Порада щодо продуктивності
Для відображення маркерів подій використовуйте CALayer або кастомний drawRect: — це в 10 разів швидше, ніж додавання UIView на кожну комірку.
Процес розробки
- Аналіз вимог — визначення типів подій, сценаріїв повторення та синхронізації.
- Проектування архітектури даних: модель події, зберігання RRULE, кешування.
- Інтеграція обраної бібліотеки або написання кастомного UI.
- Реалізація всіх видів відображення: день, тиждень, місяць з підтримкою жестів.
- Налаштування повторюваних подій та синхронізації з системним планувальником.
- Тестування на реальних пристроях з покриттям unit-тестами.
- Документація та передача коду.
Що входить у розробку планувальника
Реалізація мобільного додатка з календарем і планувальником включає:
- Налаштування видів: день, тиждень, місяць — для iOS та Android.
- Зберігання подій у локальній базі (SQLite/Room/CoreData).
- Синхронізацію з системним календарем пристрою.
- Обробку часових поясів і повторюваних подій за RFC 5545.
- Підтримку сповіщень та віджетів.
Розробку мобільного планувальника виконуємо під ключ — від прототипу до публікації в магазинах. Вартість визначається після аналізу вашого проекту.
Оцінка продуктивності при десятках тисяч подій
Для великих наборів даних використовуйте віртуалізацію. Завантажуйте лише видимий місяць плюс 30 днів вперед і назад. На iOS застосовуйте NSFetchedResultsController, на Android — Room з Flow. Це знижує навантаження на рендеринг на 40%.
| Тип календаря | Термін розробки | Орієнтовна вартість |
|---|---|---|
| Базовий місячний | 1–2 тижні | 1000–2000$ |
| Повноцінний планувальник | 3–6 тижнів | 3000–6000$ |
| Кастом з нуля | 6–12 тижнів | 6000–12000$ |
| Платформа | Рекомендована бібліотека | Підтримка Compose/SwiftUI |
|---|---|---|
| iOS (UIKit) | FSCalendar | — |
| iOS (SwiftUI) | swift-calendar / LazyVGrid | так |
| Android | kizitonwose/calendar | так |
| Flutter | table_calendar | так |
Строки та вартість розробки
Використовуючи готові бібліотеки, ми скорочуємо термін розробки планувальника на 2–3 тижні — це краще, ніж писати з нуля. При розробці з нуля середній строк — 8–12 тижнів проти 3–6 тижнів з бібліотекою. Оцінимо ваш проект за 1 день і надішлемо пропозицію. Понад 5 років ми реалізуємо мобільні додатки з календарями: від простих подійників до корпоративних планувальників з синхронізацією, сповіщеннями та віджетами. Наші клієнти скорочують час розробки на 40% завдяки нашому досвіду та готовим шаблонам. Замовте розробку мобільного додатка з календарем і планувальником — зв'яжіться з нами.