Как мобилното приложение да продължи да работи след обновленията на iOS и Android

Мобилното приложение продължава да работи след обновленията на iOS и Android, когато някой се грижи за него по график: тества всяка нова версия на операционната система още докато е в бета, поддържа актуални SDK, инструментите за компилиране и библиотеките, изпълнява изискванията на магазините за целева версия, преди да влязат в сила, и пуска малки версии за поддръжка няколко пъти в годината. Сървърната част е също толкова важна: API трябва да продължи да обслужва по-старите версии на приложението, които хората не са обновили. Приложение, оставено без грижа година или две, обикновено още работи, докато промяна в системата не счупи някоя функция или магазинът не спре да приема обновленията му.

#Защо приложението се чупи, без в него да е променено нищо

Кодът на приложението може да стои непроменен, но платформата под него се променя. Apple и Google пускат по една голяма версия на операционната система всяка година и по-малки обновления между тях, а всяка от тях може да промени поведение, на което приложението ви разчита.

• Промени в поведението на системата. Новите версии ограничават какво могат да правят приложенията във фонов режим, как стартират услуги, как четат файлове и как се доставят известията. Код, който е работил вчера, може тихо да спре, например синхронизация във фонов режим, която вече не се изпълнява.
• Промени в разрешенията. Разрешенията редовно се разделят, стесняват или стават изрични. В по-новите версии на Android изпращането на известия изисква разрешение от потребителя, а и двете платформи позволяват да споделите само избрани снимки или приблизително местоположение. Приложение, което разчита на стария, по-широк достъп, може да се срине или да показва празни екрани.
• Остарели и премахнати API. Функциите на платформата първо се обявяват за остарели (deprecated), а по-късно се премахват или променят. Предупреждението се появява в лога на компилирането много преди грешката да стигне до телефоните на потребителите.
• Изисквания на магазините. Google Play изисква новите приложения и обновленията да са насочени към скорошно ниво на Android API и вдига това ниво по редовен график. Apple периодично вдига минималната версия на Xcode и SDK за качване и добавя изисквания като privacy manifest файловете. Ако пропуснете някое, приложението може да продължи да работи при сегашните потребители, но вие няма да можете да пуснете обновление, дори спешна поправка.
• Обновления на SDK и библиотеки. SDK за плащания, аналитика, карти, вход и push известия имат свой цикъл на версии и спират поддръжката на старите. Междуплатформените рамки като React Native и Flutter също трябва да се обновяват, за да поддържат новите версии на системите, а плъгините им трябва да ги следват.
• Нови устройства и екрани. Нови форми на екрана, изрези за камерата, по-едър шрифт в настройките и сгъваеми устройства или таблети разкриват допускания в оформлението, които са били верни на по-старите телефони.

Конкретните изисквания се сменят всяка година, затова проверявайте актуалните нива и версии в официалната документация за разработчици на Google Play и Apple. Повече за страната на магазините ще намерите в статията ни за публикуване на приложение в App Store и Google Play.

#Тестване на бета версиите на системите

И двете платформи публикуват бета версии за разработчици на следващата голяма версия месеци преди официалното ѝ пускане. Apple обикновено обявява новата версия на iOS на конференцията си за разработчици в началото на лятото и я пуска през есента. Google публикува бета версии на Android за поддържаните устройства Pixel и за емулатора. Точно в този период работата по съвместимостта излиза най-евтино.

Разумна последователност при всяка бета:

1. Прочетете бележките на платформата за новостите и промените в поведението и си отбележете онези, които засягат приложението ви: разрешения, фонова работа, известия, файлове, мрежа.
2. Инсталирайте бетата поне на едно тестово устройство или симулатор за всяка платформа. Никога не я слагайте на телефон, от който някой зависи в работата си.
3. Пуснете автоматичните тестове и минете ръчно през основните сценарии: регистрация и вход, плащания, push известия, камера и качване на файлове, дълбоки връзки (deep links) и всичко, което работи във фонов режим.
4. Тествайте и с новото целево ниво, защото някои промени в поведението важат само когато приложението е насочено към новата версия.
5. Поправете и пуснете версия преди официалното обновление на системата, за да заварят работещо приложение потребителите, които обновяват още в първия ден.

Пазете малък набор от реални устройства със стари и нови версии на системата и с малки и големи екрани. Емулаторите хващат повечето проблеми, но не всички, особено при камерата, известията и бързодействието.

#Ритъм на версиите за поддръжка

Приложенията, които остават в добро състояние, обикновено следват предвидим ритъм, вместо да чакат нещо да се счупи. Един работещ вариант:

Кога	Какво се прави
Всеки месец	Преглед на сриновете и отзивите в магазините, поправки за сигурност, обновяване на библиотеки с известни проблеми.
Всяко тримесечие	Версия за поддръжка: обновени библиотеки и SDK, отстранени предупреждения за остарели API, регресионен тест на актуални устройства.
При излизане на бета версии	Тестване на бетата както е описано по-горе и версия за съвместимост преди официалното пускане на системата.
Всяка година	Вдигане на целевата и минималната версия на системата, обновяване на рамката, преценка кои стари версии на системата още си струва да се поддържат.

Точните интервали зависят от приложението. Банково или здравно приложение с много потребители иска по-плътен ритъм от просто вътрешно приложение за служители. Важното е работата да е планирана и на малки стъпки. Приложение, пропуснало две-три години обновления, често изисква голямо и рисковано обновяване на рамката и всички плъгини наведнъж, под натиска на срок от магазина.

Използвайте отчетите за сривове и аналитиката, за да видите кои версии на системата и кои устройства реално имат потребителите ви. Тези данни показват кога е безопасно да спрете поддръжката на стара версия и кои устройства заслужават време за тестване. Ако още избирате технология, лекотата на обновяване е един от факторите в сравнението ни между React Native и Flutter.

#API, съвместим със старите версии на приложението

В уеб всеки получава новата версия, щом презареди страницата. При мобилните приложения много потребители работят със стара версия с месеци, а някои никога не обновяват. API трябва да обслужва всички версии, които още се използват.

• Правете промените чрез добавяне. Добавяйте нови полета и адреси. Не преименувайте и не махайте полета и не сменяйте значението им, докато старите версии на приложението още ги четат.
• Версионирайте API, когато несъвместима промяна е неизбежна, и дръжте старата версия, докато използването ѝ не падне до ниво, което предварително сте решили, че е приемливо.
• Изпращайте версията на приложението с всяка заявка, например в заглавка, за да може сървърът да я записва, да измерва използването по версии и при нужда да променя поведението си.
• Определете минимална поддържана версия. Вградете екран за задължително обновяване още в първата версия, за да можете да помолите потребителите на много стари версии да обновят и да го изискате, когато старата версия е несигурна или вече не може да работи.
• Използвайте флагове за функции, управлявани от сървъра, за да изключите нова функция без нова версия в магазина, което отнема време.
• Тествайте старите версии на приложението срещу новия API, преди да пуснете промени на сървъра. Пазете последните няколко публикувани версии точно за тази цел.

#Кой трябва да отговаря за тази работа

Поддръжката се губи, когато никой не отговаря за нея. Уверете се, че някой има достъп до акаунтите за разработчици, ключовете за подписване, изходния код и настройките за компилиране и че всичко това е на името на вашата фирма. Уговорете писмено какво включва поддръжката: съвместимост с новите версии на системите, обновяване на библиотеките, промени в изискванията на магазините и колко бързо се пускат критичните поправки.

#Как може да помогне PN Scripts

PN Scripts разработва мобилни приложения за iOS и Android на React Native, Flutter, Swift и Kotlin заедно с API зад тях и се грижи за публикуването в магазините. Поддръжката и обновленията продължават след пускането толкова дълго, колкото клиентът желае, а акаунтите в магазините са на името на клиента. Ако планирате приложение или поддръжката на съществуващо, вижте страницата за разработка на мобилни приложения за iOS и Android.