SDKを使うことでスマートデバイスで稼働するアプリをより迅速かつ効率的に作成できます。SDKは一般消費社向けのB2Cアプリ及びビジネスで活用するためのB2B、B2Eアプリの作成にも対応しております。強化されたセキュリティと企業システムとの親和力が特徴と言えます。AppPotのSDKはデータの安全な永続化処理、サーバーとの同期、トランザクション管理、オフライン対応、プッシュメッセージ対応等、どのアプリでも必要な機能をノンコーディングで利用できます。アプリの開発者は実装したい機能だけにフォーカスできます。AppPotが提供する機能を使うためには以下の2つの方法があります。APIを使うことでAppPotのほぼ全ての機能をSDKを通さず直接利用することができます。APIを意識することなくOOPの手法だけでアプリを開発できます。SDKを利用することでアプリの開発者はネットワーク処理、セキュリティ対策、データの同期などの複雑な部分はSDKに任せて、アプリに必要な機能の実装に集中できます。AppPotはiOS、Android、JavaScriptに対応した3つのSDKを提供します。iOSとAndroid向けのSDKは各プラットフォームのネイティブアプリを作成するために使います。JavaScriptのSDKはビュー等にHTMLやCSSを利用してハイブリッドアプリを作成するために使います。制作するアプリの配布対象のプラットフォームと実装方式に適したSDKを選んで使って下さい。Object(以降、VOと称する)の定義によるデータモデルの自動生成アプリ開発者がVOを定義してビルドすることで端末内とサーバー側にデータモデルが自動生成されます。Objectの属性の指定によって端末と、サーバー、あるいはその両方を指定できます。自動生成したデータモデルはVOの定義を変更することでいつでも修正できます。結果的にアプリ内にデータベースの作成と操作が自動化され、サーバー側の開発も不要となります。Objectを操作することで自動的に永続化処理が行われます。端末に保管したデータは定期的にサーバーのデータと同期され、常に最新の情報を保ちます。端末に保管するデータの寿命を指定し、端末内のストレージを無駄に使うことを防ぐこともできます。SDKを任せて、各アプリ独自の処理を作ることに集中できます。全てのネットワーク関連の処理はSDKによって隠蔽されます。アプリ開発者がネットワーク処理を意識する必要はありません。端末がオフライン状態でもSDKがユーザーの操作を記憶し、ユーザーに意識させることなく、端末が再びオンラインになった時にサーバーに変更を反映することができます。アプリ開発者は必要に応じてネットワーク処理を同期型と非同期型から選択できます。SDKによって自動的に行われます。アプリの開発者はAppPotが提供する認証・認可の機能を使う事もできますし、社内の既存認証システムと連携して使う事もできます。ログイン、ログアウト及びユーザー権限に基づくデータへのアクセス制御機能がSDKによって提供されます。アプリ毎に同様の機能を作る必要がありません。ユーザーの認証情報は各プラットフォーム内の安全な場所に暗号化して保存されます。Objectの指定によって選択的に暗号化できます。悪意を持つ人が端末のアプリの内部を直接覗いても重要な情報が簡単に漏洩されることはありません。SDKが提供するモニタリング機能を使うことでアプリの使用状況をモニタリングできます。モニタリングのレベルはAppPotの管理画面から設定を変えることでアプリの運用中にも必要に応じて随時変更できます。モニタリング情報を活用することでアプリのKPIを測定し、更なる改善等に活用できます。SDKを使ってデバイスを登録しておくとAppPotの管理画面から各アプリに対して簡単にプッシュメッセージの送信ができます。プッシュメッセージの送信先はユーザーが属するグループ単位で制御できます。使うプッシュメッセージはテンプレートとして登録し、より効率的に使うことができます。SDKを利用したアプリ開発の流れを示します。SDKを利用した開発の流れAppPotサーバーの準備アプリ開発に入る前に先ずサーバー側の管理画面からアプリを新規登録する必要があります。アプリを登録する際にはアプリを使用できるグループを指定する必要がありますので、AppPot管理画面からグループとそれに属するユーザーを定義してあることが前提となります。SDKを使う前に管理画面で行うべき作業を記述します。各作業の詳細については管理画面のマニュアルを参照して下さい。iOSはObjective-Cで作成されておりますが、Swiftからもシームレスに使うことができます。SDKを使う方法について説明します。SDKを直接提供します。SDKをダウンロードします。SDKはzipファイルとして圧縮されております。ダウンロードが終わったら圧縮を解凍します。解凍後のファイル名は「AppPot.framework」となります。ここではXcodeを前提にした説明をします。XcodeはアップルのAppStoreから無償で入手できます。Xcodeは4.x以上のバージョンなら問題ありませんが、常に最新のバージョンを使うことをおすすめします。SDKの使用と関係のないXcodeの操作方法の詳細は記述しません。Xcodeの操作方法の詳細は別の書籍やアップルの文書を参考にして下さい。アプリを開発するためのプロジェクトを作成している場合はそのプロジェクトをXcodeで開きます。Application」を選んで「AppPotDemoApplication」という名前のアプリを作成するプロジェクトをサンプルとして使用します。新しいプロジェクトを作成すると下図のような初期設定済みのプロジェクトが表示されます。「Frameworks」という名前で新しいグループを作成します。(←この処理は必須ではありませんが、プロジェクト内のファイル管理がより便利になります。)先ほどダウンロードした「AppPot.Framework」ファイルを「Frameworks」フォルダにドラッグアンドドロップします。フレームワークをインポートする時のオプションを選択できるウィンドウが表示されます。下図のような設定にして「Finish」ボタンをクリックします。SDKがプロジェクトにインポートされます。下図では「AppPotDemoApplicationTests」というターゲットにも追加しておりますが、テストコードを記述しない場合はこのチェックは外します。SDKが提供するヘッダーファイルを確認できます。SDKを使うためには他にいくつかのライブラリーをプロジェクトにインポートする必要があります。Libraries」を選択します。次は「+」ボタンをクリックしてライブラリーを追加できます。検索窓を利用して以下のライブラリーを追加します。libsqlite3.tbdImageIO.frameworkSystemConfiguration.frameworkAppPotはエラーや警告などのメッセージを日本語で出すために、XcodeのLocalization機能を使っています。アプリが支援したい言語のstringリソースファイルをダウンロードし、アプリに取り込んで、アプリにもその言語の対応を設定します。SDKのヘッダーをプロジェクトのヘッダー検索パスに追加する必要があります。Paths」を探します。そこにAppPotのヘッダーへのパスを指定します。(ここではAppPot.frameworkをプロジェクトフォルダの直下に置いた前提での設定値を示しています。AppPot.frameworkの位置が異なる場合はその位置を指定します。Flagsに以下の値を設定する。SDK定義しているカテゴリーを認識させるためのものです。-ObjC上記の設定はXcodeのスキーム毎に行う必要があります。テストコードを書いている場合は、テストコード実行用のスキームにも同様の設定を行う必要があります。Headerを作ります。新規ファイルを作成します。ファイルの種類として「Source」から「Header」を選択し、「AppPodDemoApplication-Header.h」という名前で保存します。SDKを使うプロジェクトの名称です。プロジェクトの名称が異なる場合はそれを指定してください。)作成したファイルを開き、AppPotのヘッダーの記述を追加します。SDKを使うために必要なヘッダーファイルは「AppPot.h」だけです。Headerファイルの位置を指定します。Header」という項目を探して以下の値を設定します。Settings」の表示オプションが「All」と「Levels」になっていることを確認してください。最後にKeychainを使用するように設定を変更します。sharing」を選択し、オンにしてください。SDKは保護が必要な情報をKeychainの中に保持しますので、AppPotのSDKを採用したアプリはこの設定をオンにする必要があります。SDKを使うための準備は終わりました。SDKを使う方法について記述します。SDKを使うためにはSDKの初期設定が必要です。AppDelegate.swiftファイルを開き、「initAppPotSDK」というファンクションを下記のような内容で作成します。24)}AppID、appVersion、appKeyなど、各設定値はAppPotの管理画面のアプリ登録情報を参考に設定します。必要に応じてカスタムヘッダーをNSDictionaryの型で作成して追加することもできます。SDKはここに設定された情報に基づいてAppPotサーバーとのやりとりを行いますのでこの設定情報が正しいかを確認してください。このサンプルではサンプルという目的上、AppPotサーバーとの通信でSSLを採用してないので、上記の設定の他にinfo.plistに下記の記述を追加することでAppPotのサーバーとSSLを使わない通信を可能にする必要があります。この設定はSSLを採用する場合は不要です。</dict></dict>同ファイル内で下記のファンクションを探して、上記で作成した「initAppPotSDK」を呼び出すコードを追記します。true}ここまでできたらアプリをビルドして実行してみましょう。SDKの導入及び初期化が問題なく行われていればビルドに成功するはずです。このままではAppPotのサーバーに正しくつながっているか確認できないので、ログインを実行することで設定の正しさを確認してみましょう。同ファイルに下記の通り、テストコードの実行用のファンクションとログイン用のファンクションを追加します。}}ユーザーIDとパスワードはAppPot管理サーバーに登録されているものに置き換えてください。上記コードを実行し、ログインに成功するとログインしたユーザーの情報がコンソルに出力されるはずです。]}もし実行中にネットワークに繋がってない場合は以下のような内容が出力されます。ネットワークが繋がっているか確認してから再度実行して下さい。SDKの設定情報を確かめてから再度実行して下さい。SDKには上記の他により多様な設定項目を提供しております。SDKの設定項目の詳細についてはAPServiceクラスの文書を参照して下さい。これからの内容は例としてObjective-Cのコードを使っていますが、SwiftとObjective-Cは互換性があるためSwiftからもそのまま適用できます。Objectを定義します。SDKから提供するAPObjectの子クラスとして定義する必要があります。SDKによって自動化できます。アプリ作成のコストを低減するためにも、アプリ内のアーキテクチャを一貫性あるものにするためにも、データモデルを示すクラスはAPObjectを継承することをお勧めします。Objectの宣言は以下の二つのパーツに区分して考える事ができます。以下にAPObjectの子クラスとして定義したCaseReportとFollowというクラスを使って定義の例を示します。Objectは複数の属性で一つの固まりのデータを示します。データの属性はClassのpropertyとして定義します。これは定義するクラスの親クラスをAPObjectに指定する他には普通のObjective-Cのクラスの定義と何も変わりがありません。必要な属性をpropertyとして自由に定義できます。Objectの振る舞いを制御できます。setDefaultPropertiesメソッドの中で行います。ここで設定しない項目に対してはデフォルトの値が使われる事となります。Objectに振る舞いを指定する例を示します。データの保持場所を端末内とサーバーの両方に指定する。データをサーバーのデータで自動更新を行う。Objectに振る舞いを指定する例を示します。Followクラスについてはデータの保持場所を端末内だけに指定しているだけで、他についてはデフォルトの設定をそのまま踏襲してあります。データを端末内にだけ保持するように指定。Objectの振る舞いを指定する設定項目は下記の通りです。何も指定しない場合はデフォルトでサーバー側にのみ保存することになっています。以下のいずれを選択できます。データの保持場所を指定するための定数定義。定義順に、サーバーだけにデータを保持、端末内だけに保持、そして端末とサーバーの両方にデータを保持することを示す。SDKのデフォルト値はAPPersistentServerOnlyである。サーバーだけに保持します。端末内だけに保持します。端末内とサーバーに保持します。};データの自動更新の指定これはデータの保持場所が端末内及びサーバー側の両方(APPersistentLocalAndServer)が指定された場合のみ有効な指定です。その他の保持場所が指定されている場合は以下の設定は無視されます。該当データが自動更新対象であるかの指定。この設定はpersistentTypeがAPPersistentLocalAndServerの場合のみ有効です。SDKは該当データを後述する条件で自動更新し、端末内のデータを最新のものに保ちます。自動更新の間隔を秒数で指定します。SDKはこの値を使って定期的にサーバーのデータを確認し、端末のデータを最新の状態に更新します。自動更新するデータの権限の指定。ユーザー、グループ、全部から指定可能です。Objectを利用できる権限を指定します。以下のいずれかを指定できます。データの権限を指定するための定数定義。定義順に、全使用者が使用可能、同じグループの人が使用可能、データの作成者だけが使用可能であることを示す。SDKのデフォルト値はAPScopeGroupである。データを作成したユーザーだけが参照・編集できる。データを作成したユーザーと同じグループに属するユーザーだけが参照・編集できる。誰でもデータを参照・編集できる。Objectの属性は暗号化することができます。Objectに対してのみ適用されます。暗号化されたデータはアプリが使用する際には自動で複号化されメモリーにロードされます。この指定によって重要なデータを安心して端末の中に保持することができます。以下にデータの暗号化の指定に使う属性を示します。暗号化する必要がある属性がある場合はYESを指定する。暗号化対象の属姓名を指定する。この属性はhasEncryptedPropertiesがYESの場合のみ評価される。SDKによって自動的に行われるのでアプリの開発者は上記のPropertyを指定するだけで、処理を意識する必要はありません。Objectを登録します。登録するには先述したinitAppPotSDKメソッドに以下のコードを追加します。Objectの一覧を作成する。サーバー側のDBを新規作成、修正する場合のみYESにする。Objectを登録する。SDKに登録しています。Objectの値を格納するためのデータ保存場所を作成します。Object単位でテーブルが作成され、SQLiteデータベースにデータが格納されます。上記のコードを実行したら以下のログが表示されます。ObjectがAPObjectの子クラスとして宣言されていない場合は以下のようなログが出力されます。[問題を起こしたクラスの一覧]このメッセージが表示されたら問題を起こしたクラスのヘッダーファイルを確認し、APObjectの子クラスとして宣言されているかを確認して下さい。毎回上記の処理が行われるのはあまり効率的ではありません。初回のアプリ実行でデータベースが作成されたら、上記のcreateOrUpdateDataBaseの値をNOに変えてデータベースの生成処理はスキップします。Objectの定義を変えた場合にはまたcreateOrUpdateDataBaseの値をYESに変えて一回アプリを起動することで変更をデータベースに反映します。これで全ての準備は終わりました。これからは普通のアプリの作り方に基づいて、アプリの画面や画面遷移を自由に作成します。Objectの操作方法の詳細は次の章を参照して下さい。SDKはアプリで使用するデータの操作を簡単に行うためにAPObjectというクラスを提供します。SDKに任せて、アプリの画面遷移やビューの処理に集中できます。objectに対する操作方法を示します。新規データの作成は普通のクラスのインスタンス生成と同じです。以下にCaseReportのデータを新しく一つ生成する例を示します。保存に失敗した場合のエラーハンドリングの記述}saveObjectメソッドが呼ばれるまではデータはメモリー上に存在するだけです。saveObjectを呼んだ時にデータの保存処理が行われます。データの保存に成功するとnewReportのobjectIdと言う属性に値が設定されます。objectIdはデータのユニークなキーであり、一件のデータの固有な識別子として使うことができます。saveObjectは以下の二つの種類があります。このオブジェクトの情報をデータストーアに同期型で反映する。保存先のデータストーアはpersistentTypeによって制御される。保存されたオブジェクトを返す。このメソッドはオブジェクトの状態によってデータストーアに新しいデータを追加、あるいは既存のデータを更新する。新しいデータであるか否かはobjectIdの有無で判断する。objectIdがない場合は新しいデータとして追加する。このオブジェクトの情報をデータストーアに非同期型で反映する。保存先のデータストーアはpersistentTypeによって制御される。オブジェクトの更新が終わった後に実行されるコードを渡す。保存されたオブジェクトの識別子を返す。このメソッドはオブジェクトの状態によってデータストーアに新しいデータを追加、あるいは既存のデータを更新する。新しいデータであるか否かはobjectIdの有無で判断する。objectIdがない場合は新しいデータとして追加する。saveWithBlock:(APObjectResultBlock)block;saveObjectメソッドは同期で、saveWithBlockメソッドは非同期で処理されます。saveObjectメソッドは処理が終わるまでアプリの画面及び他の処理が待たされることとなります。処理の順が必ず守られる必要がある場合を除いてはsaveWithBlockを使った方が効率的です。SDKの殆どのメソッドは同期型と非同期型のメソッドを提供します。非同期型のメソッドはWithBlockで終わる名前となっています。データが保存される場所は各クラスの設定によって異なります。上記の例で使っているCaseReportクラスはpersistentTypeがAPPersistentLocalAndServerに設定されているためデータは端末内のデータベースとサーバー側に保存されます。saveObjectメソッドが呼ばれた時点で端末がオフラインの状態である場合はデータは端末内だけに保存され、後でオンラインになった時点でサーバー側にもデータが送信され保存されます。端末がオフラインの状態では端末内とサーバー側に異なるデータを持つ事になる場合があります。各データのユニークなキーであるobjectIdを指定することで一件のデータを取得できます。APObjectクラスに定義されている以下のメソッドを使う事ができます。オブジェクトのユニークなキーであるobjectIdを指定して一件のデータを取得する。error:(NSError**)error;以下に上記のメソッドをSwiftから使う例を示します。Objectのpropertyを修正し、以下のメソッドの何れかを使います。二つのメソッドの差は同期型に処理するか非同期型に処理するかです。このオブジェクトの情報をデータストーアに同期型で反映する。保存先のデータストーアはpersistentTypeによって制御される。保存されたオブジェクトを返す。このメソッドはオブジェクトの状態によってデータストーアに新しいデータを追加、あるいは既存のデータを更新する。新しいデータであるか否かはobjectIdの有無で判断する。objectIdがない場合は新しいデータとして追加する。このオブジェクトの情報をデータストーアに非同期型で反映する。保存先のデータストーアはpersistentTypeによって制御される。オブジェクトの更新が終わった後に実行されるコードを渡す。保存されたオブジェクトの識別子を返す。このメソッドはオブジェクトの状態によってデータストーアに新しいデータを追加、あるいは既存のデータを更新する。新しいデータであるか否かはobjectIdの有無で判断する。objectIdがない場合は新しいデータとして追加する。saveWithBlock:(APObjectResultBlock)block;新規に作成したデータも既存データも更新には上記のメソッドを使う事ができます。SDKはobjectIdの有無を見て新規データか既存データかを判断します。その判断結果に基づき、新規データである場合はデータの挿入、既存データの場合はデータの更新処理が行われます。Objectとなります。複数のデータを更新するにはAPEntityManagerクラスの以下のメソッドを使います。パラメータに更新対象のクラスを配列として渡します。対象のデータオブジェクト一覧を保存する。この処理は同期型で行われる。保存するデータオブジェクトの一覧。対象データオブジェクトが新規の場合は新規データの追加、既存のものである場合は既存データの更新が行われる。正常時は更新が終わったデータオブジェクトを返す。Objectの以下のメソッドの何れかを呼び出します。二つのメソッドの差は同期型で処理するか非同期型で処理するかです。データを同期型で削除する。データを非同期型で削除する。block;APEntityManagerクラスの以下のメソッドを使うことで複数のデータを一括で削除することもできます。対象データオブジェクトの一覧を削除する。この処理は同期型で行われる。削除するデータオブジェクト。Objectタイプの全てのデータを削除するにはAPEntityManagerクラスの以下のメソッドを使います。Objectのクラスインスタンスを渡します。該当する全てのデータが削除されるのでこのメソッドの使用には注意が必要です。指定したクラスの全てのデータを削除する。データストレージ内のデータが全て削除されるので使用には注意が必要。ローカルストレージでは物理削除、サーバー側では論理削除が行われる。deleteAllDataFor:(Class)_class;データ一覧の取得データの一覧の取得にはAPQueryと言うクラスを使います。Objectの一覧を取得する例を示します。Objectのクラスインスタンスを渡す。上記のコードではFollowクラスの全てのデータを取得してNSArrayとして返します。APQueryでデータの一覧を取得する際に以下のpropertyを設定できます。単純にデータの一覧を取得するのではなく、条件を絞って取得するにはAPQueryに対して検索条件を指定します。以下のメソッドの何れか、あるいは複数を組み合わせて検索条件を指定することができます。各メソッドが指定する条件はメソッド名を参照する。scopeType;以下にAPQueryに取得するデータの条件を指定するための処理の例を示します。以下では2つの条件がANDで指定される。SDKはAPServiceクラスを通していくつかの便利で再利用性が高い機能を提供します。以下にその機能を説明します。以下のクラスメソッドを利用してAPServiceのインスタンスを取得します。APServiceクラスのシングルトンインスタンスを取得する。@discussionこのインスタンスはシングルトンインスタンスで、一回生成されるとアプリが終了するまで存在する。(instancetype)sharedInstance;ユーザー認証(ログインとログアウト)AppPotはログイン、ログアウトのためにAPServiceクラスの以下の二つのメソッドを提供します。ユーザー認証に使われるユーザーの情報はAppPotの管理画面から事前に登録されている必要があります。AppPotはアプリからのユーザー登録の機能は現在提供しておりません。onError:(APErrorBlock)errorBlock;ログインの認証はAppPotのサーバー側で行われますが、アプリ開発者はAppPotサーバーによる認証、あるいは専用の認証ソリューションによる認証を選択できます。専用の認証ソリューションをAppPotと連携して使用するには事前に環境の整備が必要となります。サーバー側のログアウト処理が必須か否かの指定。mustSyncWithServerがFALSEの場合、オフライン、エラー等によってサーバー側のログアウト処理が済まなくても端末はログアウト状態になる。TRUEの場合はサーバー側のログアウト処理の成功が必須となる。onError:(APErrorBlock)errorBlock;ログインとログアウト処理は非同期通信によって行われます。ログインとログアウト後の処理はブロックの中に記述します。ログインはサーバー側の認証を必須とするため必ず端末がオンラインの状態で行う必要がありますが、ログアウトは端末がオフラインの場合でも実行できます。端末がオフライン状態なのでオンラインになるまでログアウトできないのならセキュリティの視点から良くないからです。その一方、アプリによってはユーザーのログインとログアウトの状態を正確にサーバーでも制御・記録したいかもしれません。AppPotのAPServiceクラスはこの二つのケースを考慮したログアウトメソッドを提供します。ログアウトメソッドを呼び出す際にパラメータ「mustSyncWithServer」の値を指定することでサーバー側のログアウト処理を必須にするか否かを選択できます。ログアウトメソッドは基本的にサーバーにログアウトのリクエストを送りますが、「mustSyncWithServer」の値をNOにするとサーバーでのログアウト処理が成功したかどうかとは関係なくアプリのログアウト処理が行われます。端末がオフライン状態でも端末側の認証情報はなくなるので再びログインするまでユーザー認証が必要な処理はできなくなります。「mustSyncWithServer」の値をYESにするとサーバーでのログアウト処理が成功しない限りエラーを返します。ユーザー情報の取得ログイン中のユーザーの情報及びユーザーが属するグループ、ロール等の情報を取得するにはAPServiceクラスの以下のプロパティを使います。権限によるアプリの画面表示の制御等が必要な場合に活用できます。APAuthInfoクラスから取得できる情報の詳細はクラスのドキュメントを参照して下さい。ログインユーザー、ユーザーの属したグループやロール、及び認証トークン等、認証・認可に必要なデータを格納するオブジェクト。*)deviceTokenメソッドの実装として以下のAPServiceのメソッドを実装します。AppPotサーバーからのプッシュメッセージを受信するためにはデバイストークンをAppPotサーバーに登録する。errorBlock;アプリのログをサーバーに送信APServiceはアプリの使用状況や問題発生の監視のために二つのログ出力用メソッドを提供します。このメソッドを使ってどのような内容でもログとして残す事ができます。エラーログをサーバーに送信する。エラー発生時のログをこのメッソドで記述する。ログは端末内のデータベースに保管され、適時にサーバーに送信される。サーバーからのアプリに対するログレベルの指定がNoneの場合は何も送信されず、ログは削除される。モニタリングログをサーバーに送信する。モニタリングが必要な内容をログとしてこのメッソドで記述する。ログは端末内のデータベースに保管され、適時にサーバーに送信される。サーバーからのアプリに対するログレベルの指定がNoneあるいはErrorの場合は何も送信されず、ログは削除される。log;これらのメソッドで記述された内容はコンソールとかには出力されず、アプリ内のデータベースに保管され、適時にAppPotサーバーに送信されます。SDKによって制御され、アプリ開発者が意識する必要はありません。送信するログの種類はAppPotサーバーの管理画面から指定できます。モニタリング用のログとエラー発生時のログをアプリ実装用のコードの中に記述しておけば管理画面から適時ログ収集レベルを指定できます。ログ収集レベルをモニタリングに設定すれば全てのログが収集されます。ログ収集レベルをエラーに設定すればエラー発生時のログだけが収集されます。この仕組みによってアプリの運用状況に合わせたログ収集をサーバー側の管理で行う事ができます。アプリ配布初期はユーザーの使用状況等を見るためにモニタリングをログ収集レベルとして設定しより細かい情報を収集できます。アプリがある程度使われ、使用者の使用傾向が把握できたらログ収集レベルをエラーに修正して収集するログの量を減らすこともできます。SDKはアプリのテストと配布に対する何の制約もありません。アプリ開発者はXCText、OCUnit、TestFlight等、既存の一般的な方式でアプリをテスト及び配布することができます。SDKを使用するアプリはAppPot管理画面で登録したAppIdやバージョン、アクセスするサーバーアドレス等をSDKに設定してあります。実際のアプリの変更とは関係なく、AppIdが変わるとそれは別のアプリとして扱われます。バージョンが変わると同じアプリの別バージョンとして扱われます。バージョンが変わるとAppPotサーバー上で異なるデータベースを使う事になります。従って、既存のデータをそのまま使いたい場合はアプリのバージョンをそのまま維持するか、データの移行を行う必要があります。AppPotで管理するアプリのバージョンはAppStore等で公開する際に指定するバージョンには依存せず、個別に運用できます。