2023.6.26
古いInHouseアプリをカスタムAppに移行する場合の注意点
日々色んなお問い合わせを頂くのですが、実は、無償でご回答さしあげて解決してしまうケースがそこそこあったりします。(問い合わせをされた企業様にとってはお得ですね☺️)
そんな無償解決したお問い合わせストックの中から、シェアするのが有用と思われるものを紹介するケーススタディ企画を始めることにしました。具体的な課題や背景・ストーリーがあるほうがより分かり易い場合もあるからです。
記念すべき(?)第一回目は、古いInHouseアプリをカスタムApp化したいというご相談です。実際にはメールやビデオ会議で数回に分けてやりとりしていますが、本稿では、質問→回答、とシンプルな構成で書いてます。また、その後に解説も記しています。
- 質問 : 7,8年前のアプリをカスタムApp化したいのですが？
- 回答 : 作り直したほうが早いです。開発体制も再考の余地ありです
- 解説1 : 自社アプリのカスタマイズ版を他社提供する方法
- 解説2 : App Store アプリの開発経験を持った外注先を選ぶ
それでは質問からいってみましょう。
質問 : 7,8年前のアプリをカスタムApp化したいのですが？
Q. 当社はシステム開発事業を行っている上場企業です。7,8年前に、社内のある事業で作ったB2B向けの業務アプリを顧客のADEP(InHouse)を使って提供していたことがあります。アプリは諸般事情で提供をやめたのですが、ここに来て当該のアプリを復活させることになりました。
貴サイトを見て、業務用アプリはカスタムApp化が必要なことを知って取り組み始めたところです。開発には外部の開発会社を使っていますが、Xcodeでうまくビルドできないと言われてて進捗は良くありません。deprecated というエラーや警告が多発したり、SDK が見つからないと言われたりして、ipa ファイルが生成できないとのことです。どう進めていけば良いでしょうか？
回答 : 作り直したほうが早いです。開発体制も再考の余地ありです
A. deprecated や SDK が見つからない等の警告やエラーは、廃止されたAPIを使っていたり古いSDKを参照するソースコードで発生します。代替の実装を行う必要がありますが、軽微で済むものからインパクトの大きなものまで様々です。
App Store への申請が伴うアプリ開発では、deprecated となるAPI情報をチェックし、SDK も新しくして、継続的かつ計画的にiOS エコシステムの進化に追随していく必要があります。
(deprecated の例。上図はUIKit)
App Store と無関係でいられたADEP(InHouse)の場合は Xcode や iOS SDK を自社都合や顧客都合で固定できていたため、deprecated を意識することは余り無かったかも知れません。良い意味でも悪い意味でもやりたい放題だったというわけです。
7,8年もの間に蓄積したiOSアプリとしての「遅れ」を、ツギハギや小手先の調整で取り戻すのは困難な作業になると思われますし、実装の見直しが広範囲に及ぶ可能性も高いと推測します。残念ながら、御社は「カスタムApp を考える以前の状態」と言えるでしょう。
(Swiftの登場は2014年ですっかり定着。Android版の同時開発でもない限り昨今はSwiftがスタンダード)
当該アプリのソースコードは Objective-C のようですが、最新のXcodeを使ってSwift言語で今風に作り直す方針を推奨します。昨今ではそのほうが外注先開発会社の選択肢も増えます。また今後のビジネス持続性も考えて、App Store 向けアプリの経験がある開発会社を選ぶほうが良いでしょう。
既存ソースについて補足すると、全部捨てることが常に正解だとは限りません。基本的に捨てる方針としながら、一部流用できるビジネスロジックがある場合は Objective-C のまま当該部分を抜き出して再利用するのが賢明でしょう。とはいえ Swift と Objective-C を混在させるデメリットもありますので、そのあたりも含めて相談できる開発会社を探されると良いと思います。
解説1 : 自社アプリのカスタマイズ版を他社提供する方法
ここからは相談内容に関連する解説となります。さて、今回のご相談のように、
- 自社で開発したソースコードをビルドして
- 他社のADEP(InHouse)契約配下の証明書・秘密鍵・Provisioning Profileで署名する
というやり方は、自社開発の業務用iOSアプリを他社販売する時に行われてきました。しかし、ADEPが使えない(使えなくなっていくと思われる)今、今後はこの方式は使えない(使えない前提でビジネスを組み直さなければならない)と考えるべきです。
カスタムAppでは、
- 販売先企業毎にそれぞれアプリを作る
- 自社 ADP にカスタムAppとして個別に申請
- App Store Connect 上の配信設定で販売先企業の組織IDと組織名を指定
- 販売先企業にはABM+MDMの導入必須であることを説明
を行う必要があります。
(研修資料より。提供先企業がMDM+ABMを持っている前提でカスタマイズ版を他社向けABMに放り込む)
このことから分かるのは、業務用自社開発iOSアプリを他社提供するメーカ企業がADEP(InHouse)からの移行を目指す場合、メーカ企業自身にもABMとMDMの理解が必要になるということです。これらの理解なく、事業を営むのは今後難しくなっていくでしょう。該当する企業におかれは、以下を参照のうえ準備することをお勧めします。
解説2 : App Store アプリの開発経験を持った外注先を選ぶ
本サイトで度々強調していることですがカスタムApp は App Store アプリです。そして App Store アプリには、ADEPの InHouse アプリと全く異なる、複雑で沢山のノウハウが求められます。
(App Store Connect は豊富な機能を備える。カスタムAppで必要なのは一部だけだが、それでも知るべきことは膨大)
ADEP では触れる事のなかった App Store Connect の基礎理解は必須であり、アプリ審査に関係するワークフローや審査結果に対するオペレーションも押さえる必要があります。テストの仕方もそもそも変わります(TestFlightを使用)し、前述の deprecated の対応も常に必要です。
ADEPとは比較にならない知識と経験が必要になるわけです。ipa ファイルを作って、審査もなく、本番・テストの区別なく自由にバラまけたInHouse配布のADEP時代とは全く違う世界だと認識しなければなりません。ADEPからEが取れた程度…と安易に考えてはいけません。
(アプリの詳細画面。たった1つのアプリでも、多くのタブと多数のメニュー、そして膨大な入力項目がある)
また、カスタムApp化で大きな課題になるのがiOS の API の進化に追随しなければならないという点です。
iOSは進化とともに古いAPIが使えなくなります。App Store アプリでは、この廃止予定のAPIを使っているとそもそも申請を受け付けてくれませんので、代替の実装に置き換えることをしばしば行います。
(iOS Release Noteから。上図は iOS16で UIKitの一部関数が廃止されることを示している)
開発者視点でiOS最新情報を確認できる iOS Release Note のページをチェックし、対応し続けられる開発体制かどうかは非常に重要です。App Store アプリの開発経験のない企業の場合、そもそもそういったことに慣れていない可能性があります。
「現場の iOS 端末で動けば良い」
この発想ではダメで、今後はアプリ審査に耐えうるクオリティの実装が必要です。では審査に耐えうるクオリティとは一体？…そうしたことに知見を持って対応できる、業務アプリの持続可能性を高める体制作りが必要になるのです。
そのために、App Store アプリの経験のある企業に発注する、または内製するなら経験者を雇うのは良い選択でしょう。それが適わないなら、最低限、その知見や経験を持った企業や個人に技術支援を依頼することをお勧めします。
今回はケーススタディ企画の第一弾ということで古いInHouseアプリをカスタムAppに移行したいというご相談への回答および関連解説をお届けました。他にも学びのある無償相談は沢山ありますので、また紹介したいと思います。
