更新履歴
古場 正行
2023/02/09 11:50
現在との差分
History → Now
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# はじめに
|
|
2
|
-
- iOS
|
|
2
|
+
- iOS および iPadOS や Android 用のアプリを App Store や Google Play でリリースするというプロジェクトをスタートしたい場合、開発に必要となる作業や要件がよくわかってないと、それらにかかる工数をうまく見積ることができない。
|
|
3
3
|
- 本ナレッジでは、App Store と Google Play にアプリをリリースする開発プロジェクトをスタートすることになったという前提で、必要となる作業や要件について思いつく限りまとめてある。
|
|
4
4
|
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -13,9 +13,9 @@
|
|
|
13
13
|
2. マルチプラットフォーム開発
|
|
14
14
|
- [MVC (Model-View-Controller) 構造](https://ja.wikipedia.org/wiki/Model_View_Controller)を持つアプリのモデル (Model) やビジネスロジックのコードを複数のプラットフォームで共通化できる。
|
|
15
15
|
- UI の共通化もある程度は可能だが、ネイティブで実現できることの全ての [UX](https://ja.wikipedia.org/wiki/%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%9A%E3%83%AA%E3%82%A8%E3%83%B3%E3%82%B9) の実現は無理で、かなりの制限が入る。
|
|
16
16
|
- ネイティブ開発よりはデバッグやメンテナンスが困難になるので、そこで予想以上に工数が膨らんでしまい、工数削減に失敗してしまう可能性がある。
|
|
17
|
-
- 採用したマルチプラットフォーム開発環境が提供するフレームワークを学習するだけで iOS と Android 両方で動作するアプリを開発できるが、Apple (iOS) や Google (Android) という必須のベンダーロックに加えて、そのマルチプラットフォーム開発環境へのベンダーロックが更に一つ増えてしまう。
|
|
17
|
+
- 採用したマルチプラットフォーム開発環境が提供するフレームワークを学習するだけで iOS と Android 両方で動作するアプリを開発できるが、Apple (iOS および iPadOS) や Google (Android) という必須のベンダーロックに加えて、そのマルチプラットフォーム開発環境へのベンダーロックが更に一つ増えてしまう。
|
|
18
18
|
|
|
19
19
|
## 開発方式を選択する時の判断基準
|
|
20
20
|
1. ネイティブ開発
|
|
21
21
|
- ストアにリリースするような UX が重視されるコンシューマ向けのアプリは、ネイティブ開発が向いている。
|
|
@@ -23,9 +23,9 @@
|
|
|
23
23
|
- 長期にわたってエンハンスされるアプリは、ネイティブ開発が向いている。
|
|
24
24
|
2. マルチプラットフォーム開発
|
|
25
25
|
- iOS と Android で全く同じアプリをリリースする計画がある場合に、プロジェクトの方針としてある程度のコードの共通化を図りたい時には、マルチプラットフォーム開発が有効である。
|
|
26
26
|
- ネイティブ開発に必要となる言語やフレームワークについて熟知しているエンジニアをどうしても確保できない時に、代替案として考えられる。
|
|
27
|
-
- UX が重視されないアプリ (組織内利用を前提とした業務アプリなど)
|
|
27
|
+
- UX が重視されないアプリ (組織内利用を前提とした業務アプリなど) の開発に向いている。
|
|
28
28
|
|
|
29
29
|
## 開発方式の違いによるトータル工数は？
|
|
30
30
|
- トータル工数を見た場合、初期リリースにかかる工数についてはネイティブ開発とマルチプラットフォーム開発はどちらもほぼ同じであり、エンハンスを続けていくとマルチプラットフォーム開発の方がコスト増になるというのが個人的な見解になる。
|
|
31
31
|
1. ネイティブ開発
|
|
@@ -34,9 +34,9 @@
|
|
|
34
34
|
- 開発環境も、デバッガやパフォーマンス計測ツール、コードカバレージ計測ツール、メモリリーク解析ツール、自動テストツールなどのツールが多数揃っている。
|
|
35
35
|
- 最新の iOS や Android への追従も、もちろん最速である。
|
|
36
36
|
2. マルチプラットフォーム開発
|
|
37
37
|
- マルチプラットフォーム開発は、採用している開発環境ではどうしても簡単には実現できない外部仕様への対応、実装が完了した後のデバッグやメンテナンスなど、開発工程の中盤以降に様々なトラブルが発生し、そのあたりの工数が予想以上に増大してしまう傾向がよく見られる。
|
|
38
|
-
- マルチプラットフォーム開発環境が採用している開発言語 (JavaScript や C#) やフレームワーク (HTML5 / CSS3 や .NET) を見ると iOS や Android の開発言語を使うよりも簡単に作れそうな気になるが、それは幻想である。「誰でも簡単に始められる」ことと「誰でも簡単に作れる」ことの間には、大きな溝が存在する。
|
|
38
|
+
- マルチプラットフォーム開発環境が採用している開発言語 (JavaScript や C#) やフレームワーク (HTML5 / CSS3 や JavaScript や .NET) を見ると iOS や Android の開発言語を使うよりも簡単に作れそうな気になるが、それは幻想である。「誰でも簡単に始められる」ことと「誰でも簡単に作れる」ことの間には、大きな溝が存在する。
|
|
39
39
|
- マルチプラットフォーム開発環境にはネイティブ開発環境ほどの便利なツールは揃っていない。
|
|
40
40
|
- 最新の iOS や Android への追従が遅れがちになる。
|
|
41
41
|
- 何か一つのプラットフォームへの対応のためだけにエンハンスを実施した場合に、全プラットフォームでのテスト、及びデグレードしていないことの確認作業が発生する。(これを怠ったために、新型コロナウイルス接触確認アプリ COCOA の Android 版は4ヵ月もまともに動作してなかったという事故を起こした。)
|
|
42
42
|
- 長期にエンハンスされることが予想できるアプリは、ネイティブ開発の方が、マルチプラットフォーム開発よりもエンハンス時の工数が圧倒的に少なく済む。
|
|
@@ -47,9 +47,9 @@
|
|
|
47
47
|
- ネイティブ開発の場合は、以下の言語とフレームワーク、そして開発環境について習得しなければならない。
|
|
48
48
|
|
|
49
49
|
|プラットフォーム|言語|フレームワーク (SDK)|開発環境 (IDE)|
|
|
50
50
|
|:---|:---|:---|:---|
|
|
51
|
-
|iOS
|
|
51
|
+
|iOS および iPadOS|[Swift](https://www.apple.com/jp/swift/)|iOS SDK、[SwiftUI](https://developer.apple.com/jp/xcode/swiftui/)|[Xcode](https://developer.apple.com/jp/xcode/)|
|
|
52
52
|
|Android|[Kotlin](https://ja.wikipedia.org/wiki/Kotlin) (もしくは Java) ※1|Android SDK、[Android NDK](https://developer.android.com/ndk?hl=ja)|[Android Studio](https://developer.android.com/studio)|
|
|
53
53
|
|
|
54
54
|
※1 Android の第1言語は、いまや Java ではなくて Kotlin である。
|
|
55
55
|
|
|
@@ -59,14 +59,14 @@
|
|
|
59
59
|
- マルチプラットフォーム開発の場合は、採用する開発環境をどれにするかを慎重に決めること。
|
|
60
60
|
- 現在良く使われている開発環境は以下になる。
|
|
61
61
|
1. [Apache Cordova](https://cordova.apache.org/)、[Vue Native](https://vue-native.io/)、[React Native](https://reactnative.dev/)、[Capacitor](https://capacitorjs.jp/)
|
|
62
62
|
- モデルやビジネスロジックのコードを JavaScript で実装し、UI を HTML5 と CSS3 と JavaScript のフレームワークで実装する。
|
|
63
|
-
- インタプリタ言語の JavaScript
|
|
63
|
+
- インタプリタ言語の JavaScript のコードが動くので、ネイティブほど処理は速くない。また、ネイティブと比較するとメモリ管理の面でも不利である。
|
|
64
64
|
- Web エンジンの中で処理が走るのだが、Web エンジンは脆弱性がよく見つかるコンポーネントとして有名である。
|
|
65
65
|
- Apache Cordova の場合、JavaScript や HTML だけでは実現できない機能はプラグイン等でカバーすることになるが、要求仕様を実現する高品質のプラグインが存在しないと開発が破綻する。Cordova の標準機能だけでは実現が難しい外部仕様は、基本的に諦めなければならない。
|
|
66
66
|
- [Vue Native](https://vue-native.io/) の場合は、[Vue.js](https://jp.vuejs.org/) に精通しているエンジニアを開発に流用できる。
|
|
67
67
|
- [React Native](https://reactnative.dev/) の場合は、[React](https://ja.reactjs.org/) に精通しているエンジニアを開発に流用できる。
|
|
68
|
-
- [Capacitor](https://capacitorjs.jp/) は、[ionic フレームワークを前提として Web
|
|
68
|
+
- [Capacitor](https://capacitorjs.jp/) は、[ionic フレームワークを前提として Web アプリをネイティブアプリに変換する](https://dev.classmethod.jp/articles/capacitor-getting-started/)。
|
|
69
69
|
2. [Xamarin](https://docs.microsoft.com/ja-jp/xamarin/get-started/)
|
|
70
70
|
- モデルやビジネスロジックのコードを C# と .NET で実装し、UI を共通の [Xamarin.Forms](https://docs.microsoft.com/ja-jp/xamarin/get-started/what-is-xamarin-forms)、もしくはネイティブな UI クラスに1対1でマッピングされているクラスで実装する。
|
|
71
71
|
- UI を共通の [Xamarin.Forms](https://docs.microsoft.com/ja-jp/xamarin/get-started/what-is-xamarin-forms) で実装する場合は、ネイティブと比べると表現力が落ちる。
|
|
72
72
|
- ネイティブな UI クラスに1対1でマッピングされているクラスで UI を実装する場合は、ネイティブ UI 部品に関する知識が必要になる。つまり、Xamarin に加えてネイティブ 2種と、計3種の学習コストが発生してしまう。
|
|
@@ -95,22 +95,23 @@
|
|
|
95
95
|
- 開発対象となる言語やフレームワークに精通しているエンジニアを自部署で育成、もしくは調達しなければならない。
|
|
96
96
|
|
|
97
97
|
|開発環境|言語|フレームワーク|備考|
|
|
98
98
|
|:---|:---|:---|:---|
|
|
99
|
-
|iOS
|
|
99
|
+
|iOS および iPadOS ネイティブ|[Swift](https://www.apple.com/jp/swift/)|iOS SDK、[SwiftUI](https://developer.apple.com/jp/xcode/swiftui/)|iOS アプリを開発する場合の標準開発環境|
|
|
100
100
|
|Android ネイティブ|[Kotlin](https://ja.wikipedia.org/wiki/Kotlin) (もしくは Java)|Android SDK、[Android NDK](https://developer.android.com/ndk?hl=ja)|Android アプリを開発する場合の標準開発環境|
|
|
101
101
|
|[Apache Cordova](https://cordova.apache.org/)|JavaScript、HTML5 / CSS3|Apache Cordova|フレームワークの実装内容が古いので非推奨|
|
|
102
102
|
|[Vue Native](https://vue-native.io/)|JavaScript、HTML5 / CSS3|Vue Native、[Vue.js](https://jp.vuejs.org/)|メンテナンスされなくなったので非推奨|
|
|
103
103
|
|[React Native](https://reactnative.dev/)|JavaScript、HTML5 / CSS3|React Native、[React](https://ja.reactjs.org/)|React に命運をかける覚悟が必要 (突然メンテナンスされなくなるリスクあり)|
|
|
104
104
|
|[Capacitor](https://capacitorjs.jp/)|JavaScript、HTML5 / CSS3|ionic フレームワーク|ionic フレームワークに命運をかける覚悟が必要|
|
|
105
105
|
|[Xamarin](https://docs.microsoft.com/ja-jp/xamarin/get-started/)|C#、[XAML](https://ja.wikipedia.org/wiki/Extensible_Application_Markup_Language)|Xamarin、Xamarin.Forms.、.NET、iOS SDK ※2、Android SDK ※2|2024年5月1日でサポートが終了するので非推奨|
|
|
106
106
|
|[.NET MAUI](https://dotnet.microsoft.com/ja-jp/apps/maui)|C#、[XAML](https://ja.wikipedia.org/wiki/Extensible_Application_Markup_Language)|.NET MAUI、.NET、iOS SDK ※2、Android SDK ※2|スマートデバイスの分野で出遅れてしまった Microsoft に命運をかける覚悟が必要|
|
|
107
107
|
|[Flutter](https://flutter.dev/)|[Dart](https://ja.wikipedia.org/wiki/Dart)|Flutter エンジン、Dart 用の基本ライブラリ|Dart 言語に命運をかける覚悟が必要|
|
|
108
|
+
※2 マルチプラットフォーム開発環境では実現できない外部仕様を実装する場合はネイティブ開発の知見が必要になる。
|
|
108
109
|
|
|
109
110
|
## ソースコード管理 (構成管理)
|
|
110
|
-
- 例えば iOS
|
|
111
|
+
- 例えば iOS および iPadOS アプリのネイティブ開発では Xcode がローカルな SCM (Source Control Management) 環境を作ってくれるが、その場合、ローカルな開発環境が壊れてしまったらそれでおしまいである。ソースコードを安全に保管したり、複数の人でコードレビューできるようにするためにも、リモートで利用できる構成管理システムを採用すべきである。
|
|
111
112
|
|
|
112
|
-
- iOS
|
|
113
|
+
- iOS および iPadOS ネイティブ開発の場合、Xcode と連携可能な構成管理システムとしては以下が存在する。
|
|
113
114
|
1. [GitHub](https://github.co.jp/)
|
|
114
115
|
- クラウド環境でソースコードを構成管理してくれるサービスである。
|
|
115
116
|
- [GitHub Enterprise](https://github.co.jp/enterprise) を契約すると、企業向けにセキュリティを強化されたサービスを利用できる。
|
|
116
117
|
2. [GitLab](https://gitlab.com/)
|
|
@@ -119,20 +120,21 @@
|
|
|
119
120
|
|
|
120
121
|
## 輸管問題
|
|
121
122
|
- App Store、Google Play 共に海外のサーバになるので、輸管問題 (輸出管理問題) が発生する。関連部署への連絡と調整を忘れないようにすること。
|
|
122
123
|
|
|
123
|
-
# ③ iOS
|
|
124
|
+
# ③ iOS および iPadOS 特有の作業・要件
|
|
124
125
|
|
|
125
126
|
## Mac の調達
|
|
126
|
-
- iOS
|
|
127
|
+
- iOS および iPadOS アプリは [Mac](https://www.apple.com/jp/mac/) がないと開発できない。ということで、開発用の Mac をレンタルするか購入すること。
|
|
127
128
|
- Mac がないと App Store のライセンスを管理したりアプリを提出したりすることができない。つまり、請負でアプリ開発する場合は、請負元の顧客も Mac の調達が必要になる。
|
|
128
129
|
|
|
129
130
|
## サポート対象の決定
|
|
130
|
-
1. どのバージョンの iOS
|
|
131
|
+
1. どのバージョンの iOS および iPadOS をサポートするのかを決めること。これがテスト工程の工数に影響する。
|
|
131
132
|
- 一般的に、アプリをリリースする時期のメジャーバージョンとその一つ前のメジャーバージョンをサポートすれば十分だと言われている。
|
|
132
|
-
⇒ 例えば、2023年3月リリースであれば
|
|
133
|
+
⇒ 例えば、2023年3月リリースであればiOS および iPadOS 15 と 16 をサポートするのが妥当である。
|
|
133
134
|
- 参考資料：[App Store - Support](https://developer.apple.com/support/app-store/) (iOS and iPadOS usage)
|
|
134
135
|
- テストが大変になるが、可能であれば、まだセキュリティアップデートが配信されているバージョンをサポートすべきである。ちなみに、2023年2月の時点で2023年1月23日にセキュリティアップデートが配信されたバージョンは iOS 12.5.7 と iOS 15.7.3、そして iOS 16.3 になる。
|
|
136
|
+
- ただ、iOS 12 をサポートすると必然的に iOS 13 と 14 もサポート対象になってしまうので、2023年2月の時点では iOS 15 と 16 をサポートすれば十分だろう。
|
|
135
137
|
2. どのデバイスをサポートするのかを決めること。
|
|
136
138
|
- 最近の iPhone や iPad は画面サイズが様々だが、基本的に全てのデバイスをサポートすることになる。
|
|
137
139
|
- iPhone の場合は Touch ID 搭載モデルと Face ID 搭載モデルの2種類を調達し、両方のデバイスで画面表示まわりの確認を行うことをお勧めする。
|
|
138
140
|
- Face ID 搭載モデルには [Safe Area](https://developer.apple.com/documentation/uikit/uiview/positioning_content_relative_to_the_safe_area) という概念が導入されており、UI 部品はこの Safe Area に隣接するように画面配置しなければならない。UI 部品を画面の端にくっつくように配置してしまうと、Touch ID 搭載モデルでは問題なく表示されいていても、Face ID 搭載モデルではコンテンツの一部がノッチで隠れてしまったりソフトウェアキーボードの一部が隠れて文字入力しにくくなったりする。
|
|
@@ -141,9 +143,9 @@
|
|
|
141
143
|
## iPhone や iPad の調達
|
|
142
144
|
- 開発、デバッグ、テスト (評価) 用の実機が必要になる。
|
|
143
145
|
|
|
144
146
|
## 開発ライセンス
|
|
145
|
-
- iOS
|
|
147
|
+
- iOS および iPadOS のアプリをApp Store にリリースするためには [Apple Developer Program](https://developer.apple.com/jp/programs/) のライセンスが必要になる。このライセンスをアプリをリリースする組織に取得してもらわなければならない (既に取得済みであれば問題ない)。
|
|
146
148
|
⇒ ライセンスの取得には (手戻りやトラブルが発生しなければ) 2週間程度を見ておくといいだろう。
|
|
147
149
|
|
|
148
150
|
## Apple の審査ガイドラインの熟読
|
|
149
151
|
- App Store からリリースされるアプリには Apple の審査が入る。この審査でリジェクトされたアプリはリリースできない。
|
|
@@ -172,9 +174,9 @@
|
|
|
172
174
|
- 審査ガイドラインに沿って開発を進めたのなら、ほとんどの場合小さな指摘の対応だけで済むはずである。その場合は1週間程度を見込んでおくと大丈夫だろう。
|
|
173
175
|
|
|
174
176
|
## Apple のアナウンスのチェック
|
|
175
177
|
- Apple は、開発者に対して[ニュースとアップデート](https://developer.apple.com/jp/news/)というページを公開しており、ここに、今後のとても重要な変更点を逐次アナウンスしている。
|
|
176
|
-
- iOS
|
|
178
|
+
- iOS および iPadOS アプリをリリースしたプロジェクトは、少なくとも週～月に一回はこのページをチェックし、今後必ず発生するであろうエンハンスの概要を把握してメンテナンス計画を立てなければならない。
|
|
177
179
|
- [ニュースとアップデート](https://developer.apple.com/jp/news/)のページの右上に RSS (feed://developer.apple.com/jp/news/rss/news.rss) が公開されているので、RSS を使った通知を受け取りたい人はこれを使うとよい。
|
|
178
180
|
- ちなみに、過去には以下のような重要なアナウンスが流れている。
|
|
179
181
|
|
|
180
182
|
|アナウンス日|内容|
|