Apple змінює вектор розробки з Java в сторону Swift

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Внутрішня команда розробників Apple повідомила, що поступово відходить від розробки на Java. Причина — зростаючі вимоги до продуктивності й ефективності, з якими Java, за їхніми словами, вже не справляється.

В даному випадку команда зупинилася на мові Swift і першим переписали сервіс, який перевіряє, чи не потрапили паролі користувачів у відкриті витоки. Він щодня обробляє мільярди запитів, працює на Linux і використовує шифрування — тобто досить «важкий» у плані навантаження. Стверджується, що завдяки переписанню на Swift Apple досягла 50% зниження при використанні обладнання, 90% зменшення використання пам’яті та 40% збільшення пропускної здатності.

«Протягом багатьох років наша команда покладалася на Java для підтримки масштабованих критично важливих сервісів завдяки її перевіреній стабільності та продуктивності», — зазначають розробники.

Проте вони вирішили шукати іншу мову через проблеми з garbage collection. Навіть із покращеннями в Java, GC все ще створює затримки під навантаженням і дає додаткове навантаження на систему.

Ще один момент — масштабування. Навантаження на сервіс сильно коливається, тому Apple постійно запускає нові екземпляри системи. Для цього важливо, щоб все стартувало швидко, а Java — як мова з керованим середовищем — запускається довше, ніж хотілося б. Наприклад, AWS намагається вирішити це через SnapStart, але проблема залишається.

Swift, окрім більш стабільної роботи з памʼяттю через ARC, також дозволив суттєво скоротити сам код. Команда каже, що кількість рядків зменшилась майже на 85%. Це пояснюється тим, що Swift пропонує інший підхід: більше роботи через протоколи, менше наслідування, асинхронність через async/await, і типова безпека, яка усуває потребу в постійних null-перевірках.

Swift не був автоматичним вибором після Java, але з огляду на те, що це внутрішня мова Apple, вибір був цілком логічним. У компанії не виключають, що перехід на Go або Rust теж міг би дати схожі результати — імовірно, так і є, але маємо, що маємо.