Firebase A/B TestingがA/Bテスト

Firebase A/B Testingとは

Remote Config または Cloud Messaging を使ってA/B テストを簡単に実行，分析するサービスです。

分析後に、アプリのアップデートなしに変更を反映することも可能です。

流れとしては

テストで評価するグループを作成して、

成功測定のための目標値を設定し、

テストをモニタリングして最良のグループ（施策）を見つける。

です。

A/Bテストとは

主にマーケティングで行われる、施策判断のためのテスト。

• 施策の良し悪しを判断するために、２つ以上(基本は２つ)の施策同士を比較検討することです。
• 測定したい基準を元に、コントロールグループとテストをさせたいグループに分けて後者にチャレンジをさせて結果を比較します。

• 新しいものを２つ同時にチャレンジさせて比較するものではないようです。

  メリット

• コンソールで設定して実行するだけなので、簡単に操作してテストを開始することができる。

• それぞれのパターンを設定すれば、出し分けする値を元にアプリの外観や動作を変更してテストできる。

デメリット

• 事前にAnalyticsのイベントだったりユーザープロパティを定義しておかないと細かい出し分け、 期待通りのデータの集計がしづらいので、準備のコストがかかるand設計が難しい。
• A/Bを分けるときのルールを考えるのが難しそう。
• 検証数が少ないと結果が出づらい。

後半は特にこのサービスに限ったことではないデメリットも。

使い方

1.わかりやすいテスト名,どのようなテストかを書く

2.ターゲットを設定する。

ターゲットの条件とターゲットユーザーの割合、オプションでアクティベーションイベントを設定できる。

3.目標を設定する。

メインの指標を設定します。デフォルトで定着率、クラッシュの影響を受けていないユーザーが設定されています。

4. バリアントを設定する。

別のバリアントを追加ボタンを押せば２つ以上のパターンで分析できる。

その後のアクション

検証結果が溜まってくるとFirebaseのコンソール上で結果を確認することができ、

テストの結果を利用するには早すぎるかどうかなどもFirebaseが教えてくれる（らしい）です。

新規機能やデザインの評価が良ければそちらを反映させ、悪ければ既存のものを利用する、といったことをしていきます。

最後に

実際のレビューではバナーの画像URLをRemoteConfigからURLをA/Bで振り分け

どちらの画像の方がタップ数が多いかをテストするケースを作成しました。

デフォルト値が決まっているもの、必ず表示させるべきものが決まっていれば良いですがフェッチに失敗して、

見せてはいけないものや見せたいのに見せれないものは使用しない方が良いですね。FCMとRemoteConfigだけど。

Firebase In-App Messagingが良かったゾ〜

どうもおはようございます、こんにちは、こんばんは。

はじめに

現場で3月以降のプロダクトがなかなか決まらず、 技術的に使えそうなものを調査・検証する機会があったので運用はしていないですが調査検証内容を共有ということで投稿しました。

In-App Messagingとは

Firebaseのコンソールから、ポップアップに表示したい画像や文字を設定して、アプリ側で表示する機能です。

起動したいタイミングや表示させたいターゲットも絞り込むことができます。

例えば、割引広告のようなものが実現可能です。

参考：Firebase公式サイト

メリット

★４種類のデザインから（カード、モーダル、画像のみ、トップバナー）選べる。

設定項目は

• 本文
• タイトル
• 画像
• ボタン名
• ボタンの遷移先
• 表示対象
• 表示タイミング
• 配色

★一度組み込めば表示、非表示、遷移先の変更など柔軟に対応できる。

★Firebaseのログイベントをトリガーに表示タイミングが設定できる。

★表示に対してのクリック数などがグラフで分かりやすく見れる。

★表示によるOS差分が出ない。

デメリット

★カスタマイズ性がネイティブ実装に比べて低い。 　アニメーションや、アプリ特有のデザインにしたい場合は難しい。

実装方法

以下iOS実装方法。

検証環境

• XCode 11.3
• auMaasAppDev
• iOS13.1
• CocoaPods 1.8.4

組み込み方法

組み込みについては公式のドキュメントを見ながらやればできます。→Firebase アプリ内メッセージングを使ってみる

ただ、自分の場合そのままやるとduplicate symbols for architecture arm64というエラーが出ました。 ライブラリで使っているファイルや変数が被ると出るやつ。 自分のやり方がよくなかったのだろうけど。。

公式に書いてある通りにPodsに以下を追加して pod installすると出ました。

pod 'Firebase'

pod 'Firebase/InAppMessagingDisplay'

Firebase/InAppMessagingDisplayをインストールすると Firebase/InAppMessagingというライブラリも一緒にインストールされるのですが その二つで重複している箇所があって先ほどのエラーが出るというもの。

バージョンがいけないのかもと思い pod updateすると InAppMessagingが削除されビルドが通るように。

でも今度はやはりInAppMessagingがないと機能が使えなく

pod 'Firebase/InAppMessaging'

も別途追記してインストール。そしたらいきました。

※ちなみにpod instalとupdateの違いはpod.lockのバージョンを保持したままインストールするか更新するかの違い。

使ってみる

1.Firebaseコンソールから新規キャンペーンを作成する

2.宛先を設定

3.スケジュールを設定

4.任意でカスタムキーやコンバージョンイベントの設定

コンバージョンイベントを設定していると、ポップアップがどのくらい行われて、そのうちタップした人数が何人かなどが後々グラフで見やすくなります。 カスタムキーはAnalitycsと一緒。

で、こんな感じ。

最後に

結構現場の開発陣、PO陣問わずチームから良い反応が多かったです。 カスタム性が低いので、とりあえず入れておいて何かあった時にみたいな緊急手段として併用も良いかなという話も出ました。

ブログの投稿は基本毎日19時頃する予定です。

Firebase Cloud Messaging[2020年]

どうもおはようございます、こんにちは、こんばんは。

ちるたろうです。

はじめに

現場でFirebaseを使っているのですが、ナレッジとしてまとめる機会があったのでこちらに投稿します。

興味があってこれからやりたい方、一応サービス概要は知っておきたい方の参考になれば幸いです。

Firebase Cloud Messagingとは 独自にサーバーを立てずにリモートプッシュ通知ができるサービスです。

リモートプッシュ通知を実現するためには、

iOSであればAPNs(Apple Push Notification Service)という機構に則り、

独自にサーバー構築をする必要ありましたが、（→色々面倒）

Firebase Cloud Messagingを使えば、サーバーを用意せずに、APNs証明書(またはAPNsキー)を用意するだけでリモートプッシュ通知を実現できるようになります。

公式ドキュメント

できること

Firebaseコンソールから、カスタムしたメッセージをリモートプッシュ通知配信。

User Properties などターゲティングした通知。

スケジュール配信。

プッシュ通知配信からのイベントコンバージョントラッキング。 通知音ON/OFF設定、バッジ設定、カスタムパラメータ送信など。 ※それぞれコンソールのスクショを下記貼ります。

1. Firebaseコンソールから、カスタムしたメッセージをリモートプッシュ通知配信。

2.User Properties などターゲティングした通知。

3.スケジュール配信。

4.プッシュ通知からのイベントコンバージョントラッキング。

5.通知音ON/OFF設定、バッジ設定、カスタムパラメータ送信など。

料金

無料。

https://firebase.google.com/pricing

• Firebaseはモバイルアプリ向けのリモートプッシュ通知特化。
• Firebaseはモバイルネイティブアプリ側、実装簡単。
• Firebaseはサーバー側の実装不要。

実装方法(iOS)

詳しくは公式ドキュメント 　参照してください。

以下、ざっくり書きます。

Firebaseコンソールでのやること

• Firebaseコンソール上でアプリを登録して、GoogleService-Info.plist をダウンロードする。

https://firebase.google.com/docs/cloud-messaging/ios/client#register-app

• Apple Developer ConsoleのCertificates, Identifiers & Profilesから、該当アプリのKeysを作成し、ダウンロード。

• そしてそれをFirebase Console上でアップロードする。

https://firebase.google.com/docs/cloud-messaging/ios/client#upload_your_apns_authentication_key

アプリ側の実装(Xcode上)

https://firebase.google.com/docs/cloud-messaging/ios/client#add-sdks

• CocoaPodsを使ってFirebaseをiOSアプリプロジェクトにインストール
• GoogleService-Info.plistを組み込み
• アプリプロジェクトの設定>Targets>Signing&Capablitiesから「+」ボタンを押してPush Notificationsを追加
• コードを書く　

https://firebase.google.com/docs/cloud-messaging/ios/client#initialize_firebase_in_your_app

まとめ

今回は従来からあるAPNs証明書を使用しましたが、

更新をする必要がないことからAPNsキーを使用したやり方のほうが良いと思います。

今回は、3月末まででサービス終了するアプリだったので証明書でやりました。

ブログの投稿は基本毎日19時頃する予定です。

コメントいただけると嬉しいです！

Firebase Analyticsやってみたった[2020年]

どうもおはようございます、こんにちは、こんばんは。

ちるたろうです。

はじめに

現場でFirebaseを使っているのですが、ナレッジとしてまとめる機会があったのでこちらに投稿します。 興味があってこれからやりたい人方、一応サービス概要は知っておきたい方の参考になれば幸いです。

Firebase Analyticsについて

Google アナリティクスが中核となっている、アプリの使用状況や動作に関するデータについて 分析することができる無料のアプリ測定ソリューションです。 そのためFirebaseConsoleだけでなく従来のGoogle アナリティクスの管理画面でもデータを確認することができます。

元々、Googleがモバイルアプリの計測をするためのモバイルアプリ向けGoogleアナリティクスを提供していました。

2019年9月以降から、そのモバイルアプリ向けGoogleアナリティクスのサービスが終了し、 Firebase 機能と統合されているGoogleアナリティクス（Firebase Analytics）に移行する必要が出てきたのもあり活発になっています。

参考：Firebase Analytics公式ドキュメント 　　　GoogleAnalyticsを使ってみる

実装方法

プロジェクトの作成やアプリの追加は公式のドキュメントを参考にするとわかりやすいです。 Console画面はほとんど日本語化されているのでわかりやすいです。

Firebase – 公式ドキュメント

Firebase – コンソール

主な流れとしては

FirebaseSDKインストール　→　Google設定ファイルインポート　→　FirebaseSDK初期化　→　イベントログ追加　→　コンソールで確認

です。

注意点かどうか分かりませんが、自分がやった時バージョン指定をしてpod install したらうまくFirebaseと繋がらなかったことがありました。（pod 'Firebase/Analytics', ' ~> 5.6.0'）

できること

従来のGoogleアナリティクスでは 滞在時間やセッションごとのスクリーンビューなども集計されていましたが、 Firebase Analyticsはイベントを基にしたデータの集計を行なっています。 そのため、標準レポートで閲覧できるレポート内のグラフのほとんどは、イベント単位での集計がされており以下のような分析ができます。

• プッシュ通知の分析
• クラッシュレポート
• ユーザー層のその他の行動を把握
• アプリ内の行動分析

など。

自動で収集されるイベントとアプリに埋め込んで集計するイベントとがあり、

ユーザがログインしたとき(login)、ユーザがチュートリアルを開始したときのようなGoogleが推奨しているイベントもあります。

参考：推奨されているイベント一覧

実際に各機能で確認できる内容をざっくりまとめました。

Events

Eventsタブでは集計されたイベントの一覧を確認でき、総数やユーザー数などが確認できます。

また、イベントの詳細画面ではイベントに付随したパラメータの内容が確認できます。

分析は基本的にはこちらのタブから確認できます。

StreamView

イベントが集計された30分〜1時間以内のリアルタイムデータの閲覧が行えます。

1分あたりのユーザー数や、その時間帯のイベント数などリアルタイムで詳しく把握することが可能です。

DebugView

開発時にさらに秒単位で細かく確認したい場合にDebugViewが使用できます。

※iOSで確認するにはBuildターゲットのスキーマの設定を変更する必要があります。

Xcode で次のコマンドライン引数を指定します。

-FIRDebugEnabled

詳しくは先に載せた、Firebaseの公式ドキュメントを参照してください。

注意点

• イベントが集計され、表示されるまでに24時間ほどかかる場合がある。
• イベントに付与したパラメータはStreamViewでは即時確認できるが、
• Eventsでは確認できるまでに1日以上かかる（実際２週間後くらいにProdででた例あり。。）
• Eventsでパラメータを確認するにはパラメータレポートを編集する必要がある。

まとめ

GAに比べてUIは分かりやすくなったと思いますが、その分見れる部分も減ったということ。 ただ、従来のGoogleアナリティクスコンソールでも使えるので（データとしては集計していない部分はあるが）適材適所でしょうか。 実際にBigQueryにエクスポートしてデータポータルを使用して活用したり 一部をGoogleアナリティクスコンソールで確認とかもしていました。

ブログの投稿は基本毎日19時頃する予定です。

コメントいただけると嬉しいです！

iOSアプリアーキテクチャ比較検討(Cocoa MVC,MVVM,MVP,CleanArchtecture)

どうもおはようございます、こんにちは、こんばんは。   今回は、アーキテクチャをまとめてみました。備忘録。

アーキテクチャを取り入れる理由

アーキテクチャはアプリを綺麗に開発・継続的に運用していくための設計方法。

UI（プレゼンテーション）とそれ以外のUIに関連しない処理（ドメイン）にざっくり分けられる。 分けられると何が良いのか。

• 処理が理解しやすい
• 重複コードの排除
• 分業がしやすい
• テスタビリティの向上 など。

これによって、品質や開発スピードの向上につながる。 アーキテクチャによって特徴が異なるため、開発人数や環境、期間などによってどれが最適か検討する必要がある。

各アーキテクチャごとの概要

アーキテクチャ	概要	役割	メリット	デメリット
Cocoa MVC	Appleが推奨しているアーキテクチャ。 CocoaMVCの大きな特徴は、ViewとModelが完全に独立しているところ。 ModelとViewが独立していることによって、再利用性が高まり、Controllerだけ作り直せば流用できる。	Model - データの処理 - ビジネスロジック - Entityの保持 ViewController - UIの更新 ユーザーのアクション通知 - Modelの操作	- 開発スピードが早い、シンプルな構成で学習コストが低い。 - 経験が浅くても保守しやすい。 - Modelのテストが可能になる。	ViewControllerの肥大化や重複コードにより可読性の低下。
MVP（PassiveView）	MVP の特徴はテスト容易性と作業分担のしやすさを実現させるところ。 フロー同期（対象データを更新してからUI更新する）のため データフローが追いやすく書き易い。 protocol 化して疎結合にすることで、Presenter単体でのテストが行える。	Model - データの処理 - データの更新 - ビジネスロジックView - タップイベントなどをPresenerへ通知 - UIの更新 Presenter - Modelの操作 - Viewを更新 - Viewの状態を保持 - UI関連のロジック	- MVVMやCleanArchTectureなどに比べるとシンプルな構成。 - View（viewController）の肥大化が抑えられ可読性が向上する。 - 画面ごとに書き方が統一しやすい。	- コード量が増える。 - MVCに比べると学習が必要。
MVVM	MVVM の特徴はViewとViewModelをデータバインディングと呼ばれるしくみで関連付けることで、 ViewModelの状態を更新するだけで、 Viewの状態も更新され画面に反映される。 ネットを見ていると最近よく使われているパターンの一つ。	Model - データの処理 - ビジネスロジックView - ユーザーのアクションをViewModelへ通知 - ViewModelの変更を元にUIの更新 ViewModel - ViewとViewModelのバインディング - Viewの状態を保持 - ViewとModelの仲介	- 可読性の向上 - テストの容易性 - Viewへの更新通知、指示の部部分のコードが不要。 - 学習コストが高い。	- 小規模、少人数のプロジェクトではコストに対してリターンが少ない。
Clean Archtechture	サーバー通信や例外処理などもModelに切り分けられることが多いが、 より責務を細分化して定義することで 変更に強く可読性が高い。 Clean Architectureは依存関係に重きを置く設計であるため、 各層を単一方向につなげる。	Entity - データ - 使用する外部オブジェクトに依存しないロジックUseCase - ビジネスロジックRepository - データの処理 View - UIの更新 - タップイベントなどをUseCaseへ通知 - データとViewのバインディング - Viewの状態を保持	- OSに非依存のロジックはAndroid,iOSで同じように書きやすい。 - 「何をどこに置く」という規約として機能し、コードの粒度を揃える	- 学習コストが高い。 - 責務を細分化するためファイル数が多くなる。

参考：Apple Document Archve(MVC)

　　　iOSアプリ設計パターン入門（書籍）

検討結果

各アーキテクチャを比較検討した結果、MVCのまま実装するのが良いと考えた。

理由は以下の通り。

開発人数とスキルセットの考慮

Flux,CleanArchtecureなどのレイヤーが細分化されたアーキテクチャパターンは、

「何をどこに置く」という規約として機能し、コードの粒度を揃える機能がある。

そのため開発人数が5人以上の規模かつ、アーキテクチャパターンの理解が浅いメンバーが多い場合に有用であるため

今回のような少人数の場合、MVC のようなある程度自由の効くアーキテクチャパターンが良いと感じた。

プロジェクトの期間と規模

MVVM,CleanArchtecureは、スタートアップで根本的な概念、仕様の見直しが発生するプロジェクトでは効果が出づらく

MVCやMVPのような最低限のパターンでの方が、今回のプロジェクトの場合レビュワーの負担の減少や開発スピードという点で良い。

プロジェクトの優先項目

今後商用化に向けてはテストの容易性なども必要になってくるとは思うが

開発、保守のしやすさなどからMVCで問題ないと感じる。

アーキテクチャ変更によるリスク

現状一定の品質を担保しながら開発スピードを上げるためMVCを採用している。

変更のバックログを作成し期間を確保すれば問題ないが、今後開発人数が増えないことや上記の理由などから

リスクを取る必要のある恩恵がないと判断される。

まとめ

現場のアーキテクチャはCocoa MVCを採用してますが、現在技術検証ということでMVPの反映とかやっているのでまた実際に実装した所感も書ければと思います。

ブログの投稿は基本毎日19時頃する予定です。

コメントや反応あると嬉しいです！

既存のプロジェクトをMVPにして気づいた点、注意点

どうもおはようございます、こんにちは、こんばんは。

はじめに

現場ではCocoaMVCだったのですが、まぁ今後のプロダクトでどのよーなアーキテクチャが良いか 比較して、実際に既存のプロダクトの１画面作り変えてみました。 実装→iOSチームでレビューの過程ででた所感や気づきを共有します。

MVP自体はネットにゴロゴロありますし、 MVP自体についてざっくり知りたい方はアーキテクチャ比較も投稿したのでよければ。

ざっくり所感

• 各コンポーネントの役割が決まっているので、読みやすい。

• ユーザーの入力部分について（ViewController）とPresenter,Modelと作業分担しやすい。 ただ、作る際にある程度認識合わせ、ルールを考えておかないと実装漏れやコンフリクトのような問題が起きそう。

• ViewControllerの肥大化は抑えられるが、FatPresenterになってしまう恐れがある。 例）Presenterは画面遷移やViewの操作も全て行うのか。 　　今回は全部行うようにしたが、「Delegate多すぎ」って意見もあったので。

• viewDidLoadなどのライフサイクルイベントもviewからのユーザー入力としてprotocol化したけど、分かりにくいという意見もあった。一応サンプルではそうなっていたし、PresentationLogicも全てってなった時にそのほうが自分的には抵抗なかった。

• 2人開発では必ずしも取り入れるものではないと感じた。

• viewController自体は100行~くらい減らせた。
• FatViewControllerの解消、可読性の向上は少し実感できた。
• UIテストしやすい。
• 既存のコードの変更は学習しながら1.5日くらい。慣れればもっと早くなる。
• Cocoa MVC,Delegate, protocolを理解していればそんなに学習コストは高くなさそう。

最後に

可読性ってそのターゲットによって違うと思うので、逆にMVPのパターンを知らないと見辛くなる場合もあるんだなと。 MVVM編も投稿しようと思います。

ブログの投稿は基本毎日19時頃する予定です。

遅いけど、Xcode11.4~6 リリース内容

どうもおはようございます、こんにちは、こんばんは。  

Xcode11.4 リリース

2020年3月24日に公開されました。macOS Catalina 10.15.2以降のMacでのみ実行できます。

・[リリースノート]

11.4

11.6

大きな変更点

• Swift5.2対応
• ユニバーサル購入
• Simulatorの変更・新規機能追加
• SwiftUI対応改善

Swift5.2対応

• Swift5.2新機能(Qiita記事]

ユニバーサル購入

ユニバーサル購入とは、App Store上で購入すると複数のプラットフォームを横断して利用することができる機能です。

プラットフォームはiOS、iPadOS、macOS、watchOS、tvOSがサポートされており、アプリ本体およびアプリ内課金が対象です。

Appをユニバーサル購入として一緒に配信するには、それらのAppに単一のバンドルIDを使用し、App Store Connectで同じAppレコードに関連付ける必要があります。

一度ユニバーサル購入対応アプリとして承認されると、ユニバーサル購入を無効化したり、Appレコードから1つのプラットフォーム向けのバージョンを削除したりすることはできません。

Mac Catalyst(iOSアプリのソースを流用してMacアプリを開発できるツールセット)で作成したアプリはデフォルトでユニバーサル購入が有効になっているので注意が必要です。

Simulatorの変更・新規機能追加

• タイトルバーの追加 Simulator11.4からはタイトルバーが追加され、「Save Screenshot」「Home」「Rotate Right」のボタンが利用可能になりました。

• プッシュ通知の送信 シミュレータへプッシュ通知を送信するには有効なApple Push Notification Service payloadファイルが必要です。

push.apns
{
    "aps":{
        "alert":"Test",
        "sound":"default",
        "badge":1
    }
} 

コマンドラインから送信する場合は、上記のファイルを以下のコマンドで送信することができます。

push通知送信コマンド

$ xcrun simctl push <シミュレータのデバイスID> <バンドルID> <apnsファイル名>

また、シミュレータへapnsファイルをドラッグ&ドロップして送信することも可能です。

その場合には下記のように該当アプリのバンドルIDを付与してください。

push.apns
{
    "Simulator Target Bundle": "バンドルID",
    "aps":{
        "alert":"Test",
        "sound":"default",
        "badge":2
    }
} 

便利な点

プッシュ通知の受信部分が正しく実装できているかの確認がシミュレータで確認できるようになります。

注意点

あくまでシミュレーションなのでASPNを介したプッシュ通知のテストは別途実施してください。

表示モードの変更

コマンドラインで表示モードを変更することが可能になりました。

表示モード変更コマンド

xcrun simctl ui <シミュレータのデバイスID> appearance dark // ダークモードに変更

xcrun simctl ui <シミュレータのデバイスID> appearance light // ライトモードに変更

Interface Builder

複数のシステムグレーが追加されました。

制約をつける際に0を入力するとStandardになるバグが修正されました。

->これ地味に嬉しい！てかSafeAeraじゃなくViewに0につけてるのにSafeAreaに対して0になるからほんとだるかった。

ブログの投稿は基本毎日19時頃する予定です。

iOSレビュー時ノウハウ、コメント例

投稿理由、内容

自分自身の振り返りを含めて投稿します。 仕様の指摘、OS・言語としてのベストプラクティス、デグレやアップデート時の確認など いろいろなレビュー時の観点があると多います。 今回の投稿ではiOS/Swiftで開発してのナレッジになります。

あと、SwiftLintとか入れると勉強になりますよね。٩( 'ω' )و

参考になったもの

今回２人体制での開発、相互レビューだったので教えてもらう部分もたくさんありつつ、以下の記事は観点と目的がまとまってたのでわかりやすかったです。 https://qiita.com/kkoide1332/items/4545bf8c2ffbfb05bb1f

コメント例

その他実際に意識してた部分、レビュー時にコメントされた中でプロジェクト関係なく必要なものを以下にざっくりまとめました。

また、Swift、Cocoaフレームワーク限定の観点もありますので全部が全部ではないです。（get/setはjavaとか普通に使うし）

• 名前get/setつけない。
• BooLでis使う時には考える。意味がおかしくなるのが多いのでhasやshouldなど場合に応じて適宜する。
• typo、インデント大事。
• デザイン確認。
• OS差分、端末差分確認。
• メソッドは何が必要でどのような結果になるかわかるように作る。 　例えば、返却値があったほうが結果がわかる。返却値がない場合はメソッド名をわかりやすく。 　引数を持たせる時もswiftやCocoaの思想に寄せる。
• メンバ変数はできるだけ作らない。というかスコープを狭く。
• Viewをtagで判定しない（UIButtonとかの）。enum作ったり、extentionして分かりやすく。
• 〜Array,Listという名前は使わない。複数形は〜s。
• 配列操作は.mapやfilter。FRPを意識する。 　ループはforinではなくてforEachを使った方が統一感が出て読みやすい（もちろん用途によるが）。
• 略記は使わない。（imgViewやVcはなし。imageViewやviewControllerと書く）
• 2行改行は使わない。（意図があればよし）逆に１行改行は見やすくするためよく使う。
• if文で条件複数の場合で１行が長くなるようだったら改行入れて見やすく。 　例）if let text = XXXXXXXXXXX.text, text.isEmpty {}
• 修飾子は基本privateつける。defaultはinternal。
• classには基本finalつける。
• 命名はUIKitのproperty名に合わせる。ScreenではなくてViewなど
• 読み手に分かりやすいコメントを。素材差し替えするなど修正する場合→TODO: で、不具合ある場合は、FIXME: ,理由や実装経緯はNote：、でコメント追加。
• ifNeededは使っていいと思うが嫌派もいる。
• プロジェクトでコーディングルールを決める。 例えば、コロンの後に必ず半角スペース。コロンは左の変数に対してかかっている。
• 基本的にメソッドコメントは残さなくて良い。なぜその処理をしているのかの説明のコメントを残す。
• TODOコメントや不要なテストコードはレビュー前に削除。
• 非公開APIはAppleの審査に通らないのでNG。
• 個人情報に関する表示、データの扱いはAppleの規約確認でリジェクト対応。申請時の理由模索。
• StoryboardでのViewの前後関係に注意（どちらが画面手前か）。
• guardで弾いて良いか、ifletで継続させるかチェック。
• didSetかviewDidLoadなどでの設定かは意識する。（funcにするくらい長ければ（10~40行目安）viewdidloadで。他でもそのfuncを使用するならなど。）
• if文内でBoolを変更する場合はelseで反対の値を入れる必要があるかチェック。
• タスク分解はMVC粒度とかが良い気がする。
• readOnlyか外からsetできる必要があるか考慮。コードを読むときの可読性向上。private(set)や変数{}など使用。
• 引数のdefault値を設定する場合、引数名がなくても外から分かりやすいか考慮する。
• typoの気づきが減るよう、大学受験レベルの英単語勉強は必要。公式APIは読めるように。
• 基本的にViewにaddsubViewする。buttonの上にbutton,imageViewの上にButtonなどaddsubViewしない。
• ViewにModelを持たせない。

Push通知の証明書作ってみた in 最近

どうもおはようございます、こんにちは、こんばんは。

はじめに

あんまり頻繁に作るものではないですが 業務で得た内容をこちらに残します。

Push通知証明書って

iOSって証明書多いですよね。 ただ、developperサイトで一括管理できることは楽なのかも。

p12ファイル作成手順

①デスクトップのLaunchpadをクリック

②Launchpadのその他をクリック

③その他をクリック

④秘密鍵(画像内でいうとcries)が証明書内に入っていることを確認する

⑤右クリック（MACだと２本指タップ）で証明書を選択

⑥選択した証明書を書き出す…をクリックする

⑦名称にp12ファイルに適当な名前を入力し場所項目で出力先を決定し（画像の場合は書類）保存ボタンを押下する

⑧p12ファイルを別端末でインストールする際に必要な展開パスワードを入力しOKボタンを押下する

⑨キーチェーンで書き出すためにPCのログインパスワードを入力し許可ボタンを押下する

⑩手順⑦で指定した出力先にp12ファイルが書き出される。

iOSってプロビジョニングプロファイルとか証明書とかアプリBundle IdentifierとかUDIDとかアプリ作り始めるまでがやたらめんどいんだよなぁ...  

ブログの投稿は基本毎日19時頃する予定です。

SandBoxをふんわり調べてみたよ。

どうもおはようございます、こんにちは、こんばんは。  

はじめに

サンドボックス備忘録。

iOSのApp Groupsについて調べていく中で

• サンドボックス
• Keychain sharing
• App Extentions

の3つが結構な頻度で出てきました。 自分的によく分からないことだらけだったので見返せるように。 また、間違ったイメージで捉えているかもしれないので正してくれる方がいれば幸いです。

一般的なサンドボックス説明

以下、「サンドボックスとは？セキュリティを向上の仕組みと弱点」から引用

サンドボックスを直訳すると、「砂場」という意味になります。 子供が安全に遊べるように砂場が設けられているのと同じように、 コンピューター上に砂場のような仮想空間を設け、 サンドボックス内での動作がサンドボックスの外側に影響を与えないようにする仕組みのことです。

ふーん。

外側に影響を与えない、外側から干渉できないってことなのでしょうか。 App Gropsではこのサンドボックス領域とは別に共有できる領域を使えるということが 機能の概要として説明されていたのでそういうことなのかなと。

誰か教えてください。（他力本願）

セキュリティ的に「シグネチャ」というのが 今までのデータに基づく攻撃を防ぐのに対して サンドボックスは動作させた上でそのプログラムが危険かどうかを判断する…といったような説明でした。

iOSのサンドボックス

同じく以下、「サンドボックスとは？セキュリティを向上の仕組みと弱点」から引用

iOSのサンドボックスは隔離された空間として用意されており、 インストールされているアプリはサンドボックス内で動作します。 そのためアプリから生成された保存データもサンドボックス内に保存され、外部とは隔離されます。

おーん。

iPhone向けのマルウェア対策のセキュリティアプリがないのは サンドボックス内に隔離されているデータにアクセスすることができず ウイルススキャンできないためのようですね。

最後に

軽くイメージだけつけようと思って調べてましたが 簡単に分かるとか銘打った記事を読んでも結局ふんわりした理解にしか落ち着けませんでした。 手の空いた時にもうちょっと調べて更新できればと思います。

~参考サイト~

「サンドボックスとは？セキュリティを向上の仕組みと弱点」

ブログの投稿は基本毎日19時頃する予定です。