Як розповсюджувати iOS-додатки: 4 кейси
Що робити, щоб твій застосунок побачив увесь світ, лише друзі чи конкретна компанія? Залежно від цілей — різні шляхи вирішення. У статті для Anywhere Club їх описує iOS Developer Надзея Савіцкая, яка заповнила форму «Стати героєм клубу».
Якщо ви також хочете поділитися експертизою у своїй царині, чекаємо вашу заявку.
— Щойно розробник написав свій перший “Hello World!”, з'являються думки — кому, як і куди можна було б встановити цю програму, — ділиться Надзея, — У цій статті я хочу описати основні варіанти розповсюдження програми: від встановлення на свій телефон до публікації програми в App Store.
Кейс 1. Як розробнику протестувати програму на своєму телефоні
— Якщо iOS-розробник хоче написати програму виключно для себе, все, що потрібно, — це Apple developer акаунт (безкоштовний), MacBook, Xcode, iPhone та кабель. Пишемо бажану програму, підключаємо телефон кабелем до макбука і заливаємо програму на телефон. Тепер програма, якою можна користуватися на телефоні, готова, — пояснює Надзея.
Але я не просто так почала з цього банального кейсу. Тут я хочу докладно розглянути, що відбувається під капотом Xcode та облікового запису розробника, а також що саме дозволяє нам запускати наші додатки на телефоні.
Під час створення проєкту був зареєстрований унікальний bundle id та Development Provision Profile, який буде мати список девайсів, на яких можна запустити цю програму. Коли ви запустили програму через кабель на своєму девайсі, UDID вашого девайса автоматично записався в провіжн профайл. Важливо пам'ятати, що в development провіжн профайл можна додати кінцеву кількість девайсів. Це будуть знайомі вам девайси. Їх потрібно або під'єднати до комп'ютера через кабель і встановити на них додаток, або додати їхні UDID в developer.apple.com.
Кейс 2. Як розробнику встановити свою програму друзям або надіслати клієнту
— Що, якщо ми не хочемо зупинятися лише на власному девайсі? Тоді ми заплатимо Apple 99$ і маємо рік, щоб використати всі можливості платного акаунту, — продовжує Надзея.
До стартер-паку у нас тепер додались:
- Paid apple developer acc;
- Internal група тестувальників в Test Flight;
- External група тестувальників в Test Flight;
- Тестування за посиланням — до 1000 тестувальників.
Але в еплівських інструментів є й недоліки:
- Усіх інтернал-тестувальників треба додавати як юзерів у ваш App store конект, плюс їхня кількість обмежена;
- Якщо говорити про екстернал-тестувальників, то ліміти — 1000 людей і доступ за посиланням. Але треба проходити мінімальне рев'ю від Apple, а це означає, що додаток має бути робочим, зрозумілим і підходити під усі гайдлайни епла. Отже, випустити щось швидко з цікавості або зовсім сире не вийде.
З таким сетапом цілком можна жити та працювати з якимись замовниками та своїми додатками. У дрібних компаніях на цьому можуть зупинитися.
— Тестфлайт, звичайно ж, має альтернативи для поширення білду друзям, замовникам, тестувальникам — не еплом єдиним, — посміхається Надзея.
Найпростіший варіант, щоб розшарити друзям або замовниками щось, що не пройде абияке рев'ю від епл, навіть для екстернал-тестування — це додати в провіжн профайл udid всіх потрібних нам девайсів і скористатися, наприклад, цим прекрасним сайтом — diawi.com. Також є і Visual Studio App Center — сервіс, який дуже допомагає в компаніях розробки. Visual Studio App Center об'єднує кілька сервісів, які зазвичай використовуються мобільними розробниками, включно зі складанням, тестуванням, розповсюдженням, моніторингом та діагностикою. В апп-центрі також можна створювати різні групи тестування, після заливання білдів приходять нотифікейшн для тестувальників, з апп-центру можна заливати білди відразу в апп стор коннект, а там вже — і на рев'ю для стора. З апп-центром разом працює Azure Dev Ops для складання білду і заливання в апп-центр. Якщо система налаштована добре, то через пуш в потрібну вам гілку в github запускатиметься збирання білду і відправлення його в апп-центр. Але не варто забувати, що девайси для тестування повинні бути додані в провіжн профайли.
Кейс 3. Як розробнику опублікувати свій додаток в App Store
— На цьому етапі від публікації в сторі нас відділяють два кроки:
- Оформити продуктову сторінку: скріншоти, кейворди, посилання на прайвасі та термси;
- Пройти рев’ю.
Декілька моментів про проходження рев’ю. Якщо програма йде перший раз на рев'ю в стор і це 1.0 версія, то в неї краще не додавати покупок та підписок. Краще підготувати максимум можливого функціоналу, щоб програма була красива і не була точною копією вже наявних. На 95% ймовірно, що перше рев'ю буде реджектом, але це нормально. Змінюєте щось залежно від зауважень і надсилаєте знову.
Кейс 4. Як розробнику опублікувати свій додаток тільки для конкретної компанії
— Що робити, якщо ми хочемо зарелізити додаток не для всіх, а лише для конкретної компанії? Ми, звісно, можемо це зробити на простому Apple Developer Program і поширювати застосунок через тестування в TestFlight за посиланням. Але знову впираємося в ліміти, тому нам приходить на допомогу Apple Developer Enterprise Program. Це окремий вид акаунту, він коштує 299$ на рік і має можливість розповсюджувати свій додаток тільки потрібній групі осіб. Щоправда, не всі мають право на корпоративний обліковий запис. Це лише для внутрішнього використання пропрієтарних додатків у сценаріях, які не можна вирішити за допомогою загальнодоступного Apple App Store, Apple Business Manager, бета-тестування або розповсюдження Ad Hoc. Додаток має бути розроблений організацією, ще й спеціально для використання на платформах Apple.
Інші кваліфікаційні вимоги включають:
- Мінімум 100+ співробітників;
- Треба юридична особа;
- Мають бути вжиті заходи для гарантії того, що програма буде доступна тільки для співробітників, а всі облікові дані будуть захищені;
- Має пройти процес перевірки Apple.
Також існує така річ як Apple's Volume Purchase Program (VPP) для B2B App Distribution. З її допомогою установи освіти можуть видавати епловську техніку з уже встановленим програмним забезпеченням, яке не знайти в загальному доступі.
— Я постаралася розповісти про основні варіанти заливання додатків для різних потреб, — підсумовує Надзея, — Сподіваюся, що ця стаття була корисною. Буду рада фідбеку.