목차

1. 소개

2. minSdkVersion

3. targetSdkVersion

4. maxSdkVersion

이 포스팅은 안드로이드 SDK Guides의 내용을 기반으로 작성되었습니다.

1. 소개

이클립스가 기본 IDE 였을 때에는 minSdkVersion, targetSdkVersion는 AndroidManifest.xml에 설정했습니다. 아래가 사용법입니다.

하지만 Android Studio로 넘어오면서 build.gradle 파일에 옮겨지게 되었습니다.

SdkVersion이라는 이름을 가지고 있지만 실제로 기입해야 하는 것은 API Level입니다. Android Platform의 버전도 아니구요. 차이점을 볼까요? 아래는 포스팅을 쓰는 날짜 기준으로 최신의 버전을 기입한 것입니다.

• SDK Version : installer_r24.3.3-windows.exe

• API Version : 22

• Android Platform Version : Android 5.1 (수정된 롤리팝 버전입니다~)

전혀 연관성이 없습니다. 참고로 API Level은 항상 양의 정수 값입니다.

2. minSdkVersion

안드로이드 앱이 실행될 수 있는 최소한의 API 레벨을 의미합니다. 만약에 앱이 선언해 놓은 버전보다 디바이스의 버전이 낮을 경우에는 앱이 인스톨되지 않습니다.

앱 개발시 필수적으로 선언해야 하는 필드이며 만약에 선언을 하지 않았을 경우 ‘1’이 디폴트로 선정됩니다.

3. targetSdkVersion

안드로이드 앱의 타겟 API 레벨을 의미합니다. 만약 선언이 되어 있지 않다면 minSdkVersion과 동일한 값으로 간주됩니다. ‘타겟 API’의 개념은 해당 앱이 개발시에 테스트 되어진 API 레벨을 의미합니다. 당연히 targetSdkVersion은 minSdkVersion 보다 같거나 높을 수 밖에 없습니다. 하지만 targetSdkVersion이 높다고 하더라도 앱은 minSdkVersion에서도 인스톨 및 실행할 수 있습니다.

그럼 targetSdkVersion은 언제 사용이 될까요?

당연하겠지만 안드로이드 API 버전이 올라가면서 플랫폼이 조금씩 바뀌게 됩니다. 아래의 상황을 가정해봅시다.

• App API Level : miSdkVersion : 4 / targetSdkVersion : 7

• Platform API level : 10

이 상황에서는 당연히 앱을 인스톨하고 실행하는데에 전혀 무리가 없습니다. 하지만 만약 안드로이드 API가 7버전에서 10버전으로 오면서 앱 실행과 관련된 API에 변경이 생겼다면 어떻게 될까요? 이 경우 앱의 실행이 개발자의 예상과 달라질 가능성이 있습니다. 때문에 안드로이드 플랫폼에서는 하위 호환성 관련 기능을 활성화를 시키고 앱을 실행시켜야 합니다. 즉, 최초 릴리즈시의 동작성을 최대한 보장하기 위해서 안드로이드 플랫폼에게 정보를 알려주는 역할을 담당하는 필드입니다.

앱을 유지보수 하는 입장에 대해서 이야기를 해봅시다. 신규 기능을 추가하지 않는 이상 minSdkVersion이 높아질 가능성은 없습니다. 하지만 버그 수정이나 로직 수정 등의 이유로 앱을 버전업 할 때, targetSdkVersion은 항상 업데이트 하는 게 좋습니다.

4. maxSdkVersion

안드로이드 앱이 실행될 수 있는 최대한의 API Level을 의미합니다. 지금까지의 지식을 바탕으로 앱은 [minSdkVersion ~ maxSdkVersion] 사이의 디바이스에 인스톨 및 실행이 가능하다는 거죠. 조금 더 알아봅시다.

아마도 API Level이 높아지면서 기존의 API들이 사라지거나 수정되는 것을 감안한 필드였을 것으로 생각됩니다. 하지만 이 필드는 아래의 문제점 및 제약사항을 가지고 있습니다.

• 향후 API가 어떻게 바뀔지 예측할 수 없으므로 앱을 개발하는 시점에서는 maxSdkVersion을 알 수 없습니다.

• ‘하위 호환성’은 유지하지 않는다는 주장과 동일합니다.

• 플랫폼이 안정화가 되면 하위 호환성을 유지하는 형태로 발전합니다. 따라서 이 필드는 일시적으로 사용될 가능성이 높습니다.

개발자 문서에서도 더이상 이 필드를 사용하지 말라고 합니다.

기존의 안드로이드 버전들에서는 (1.5, 1.6, 2.0, 2.0.1) 이 값을 앱 인스톨시에 사용했다고 합니다. 만약 플랫폼의 API Level이 maxSdkVersion 보다 높을 경우 인스톨이 거부되었습니다. 만약 소프트웨어 업데이트로 플랫폼의 버전을 높일 경우에도 이미 인스톨되어 있던 앱들을 뒤져서 maxSdkVersion이 낮은 앱을 제거 했었습니다. (생각해보면 인스톨 된 앱을 지워버리는 정책은 어이없는 것 같네요. 소프트웨어 업데이트를 했더니 잘 쓰고 있던 SNS가 지워진 상황이라니!)

하지만 최신의 안드로이드 버전에서는 (2.0.1 이후) 더이상 maxSdkVersion을 체크하지 않는다고 합니다. 심지어 maxSdkVersion이 설정되어 있으면 컴파일도 실패한다고 하네요. 하지만 이미 포함되어서 앱스토어에 올라가 있는 앱의 경우에는 구글 플레이 앱스토어에서 필터링에 사용된다고 합니다.

출처: https://kkangeva.tistory.com/58 [kkangeva의 IT]

Error: 

Finally solved the problem. Need to update CocoPods.sudo gem install cocoapods

sudo gem install cocoapods

[출처]

stackoverflow.com/questions/64623288/framework-not-found-usermessagingplatform-xcframework-in-react-native

[링크] https://december.tistory.com/1522

UnityでiOSとAndrodのランタイムパーミッションの確認と要求を行う方法

Unityでアプリのカメラ権限の確認＆要求ってどうやるの？

これまでのUnityでのアプリ開発では、iOS/Android端末の機能の権限のチェックやリクエストをするために、ネイティブプラグインを利用する必要がありました。
最近になってやっと、ランタイムパーミッション関係のAPIが追加されたようなので、自分なりに使い方を調べてみました。

[iOS] Application.RequestUserAuthorizationクラス

https://docs.unity3d.com/ja/2018.2/ScriptReference/Application.RequestUserAuthorization.html
Unity2018.1以降で利用可能
iOSでウェブカメラまたはマイクを使用するための承認をリクエストします。
（カメラとマイクの権限のみチェックとリクエストが可能）

[Android] Android.Permissionクラス

https://docs.unity3d.com/2018.3/Documentation/ScriptReference/Android.Permission.RequestUserPermission.html
https://docs.unity3d.com/ja/current/Manual/android-RequestingPermissions.html
Unity2018.3以降で利用可能
Androidでユーザーに、デバイスリソースまたは承認が必要な情報へのアクセスを許可するよう要求します。
（クラスで定義されていない権限でも文字列で指定してチェックとリクエストが可能）

それぞれのプラットフォームに対応している新しく追加されたAPIを使用することで、簡易的な処理ならばネイティブプラグインを使用しないで目的を達成できそうです。
今回はカメラとマイクの権限の確認と要求をセットで行う例の作成を試みました。
そして、何回も試行錯誤した結果、導きだしたコードがこちら。

ランタイムパーミッション要求の例

using UnityEngine;
using System.Collections;
using System;

#if UNITY_ANDROID && UNITY_2018_3_OR_NEWER
using UnityEngine.Android;
#endif

namespace PermissionAuthorizationTest
{
    // iOS/Androidプラットフォームで動作するランタイムパーミッション要求のサンプル
    // 参考URL: https://forum.unity.com/threads/requestuserauthorization-as-a-coroutine-bugged.380666/
    public class PermissionAuthorizationExample : MonoBehaviour
    {
        IEnumerator Start ()
        {
            #if UNITY_IOS && UNITY_2018_1_OR_NEWER

            // iOS
            //
            // カメラパーミッションが許可されているか調べる
            if (!Application.HasUserAuthorization (UserAuthorization.WebCam)) {
                // 権限が無いので、カメラパーミッションのリクエストをする
                yield return RequestUserAuthorization (UserAuthorization.WebCam);
            }
            // マイクパーミッションが許可されているか調べる
            if (!Application.HasUserAuthorization (UserAuthorization.Microphone)) {
                // 権限が無いので、マイクパーミッションのリクエストをする
                yield return RequestUserAuthorization (UserAuthorization.Microphone);
            }
            // リクエストの結果、アプリ機能に必要なパーミッションが全て許可されたか調べる
            if (Application.HasUserAuthorization (UserAuthorization.WebCam) && Application.HasUserAuthorization (UserAuthorization.Microphone)) {
                // 権限が許可されたので、権限が必要なAPIを使用する処理へ進む（iOSでは権限拒否された状態でAPIを使用しようとするとアプリが落ちる）
                findWebCams ();
                findMicrophones ();
            } else {
                // 権限が許可されなかったので、ユーザーに対して権限の使用用途の説明を表示して自分でOSのアプリ設定画面で権限許可を行うようにアナウンスする必要がある。
                // (iOSでは初回の権限リクエストが拒否された場合は、次回からはリクエスト自体が表示されなくなる)
            }       

            #elif UNITY_ANDROID && UNITY_2018_3_OR_NEWER

            // Android
            //
            // カメラパーミッションが許可されているか調べる
            if (!Permission.HasUserAuthorizedPermission (Permission.Camera)) {
                // 権限が無いので、カメラパーミッションのリクエストをする
                yield return RequestUserPermission (Permission.Camera);
            }
            // マイクパーミッションが許可されているか調べる
            if (!Permission.HasUserAuthorizedPermission (Permission.Microphone)) {
                // 権限が無いので、マイクパーミッションのリクエストをする
                yield return RequestUserPermission (Permission.Microphone);
            }
            // リクエストの結果、アプリ機能に必要なパーミッションが全て許可されたか調べる
            if (Permission.HasUserAuthorizedPermission (Permission.Camera) && Permission.HasUserAuthorizedPermission (Permission.Microphone)) {
                // 権限が許可されたので、権限が必要なAPIを使用する処理へ進む
                findWebCams ();
                findMicrophones ();
            } else {
                // 権限が許可されなかったので、ユーザーに対して権限の使用用途の説明を表示してから再度のリクエストを行う。
                // もしも拒否時に「今後表示しない」がチェックされた場合は、次回からリクエスト自体が表示されなくなる、
                // そのためユーザーには自分でOSのアプリ設定画面で権限許可を行うようにアナウンスする必要がある。
                // （Permissionクラスにはそれらの違いを調べる方法は用意されていない）
            }

            #endif

            yield break;
        }

#if (UNITY_IOS && UNITY_2018_1_OR_NEWER) || (UNITY_ANDROID && UNITY_2018_3_OR_NEWER)
        bool isRequesting;

        // OSの権限要求ダイアログを閉じたあとに、アプリフォーカスが復帰するのを待ってから権限の有無を確認する必要がある
        IEnumerator OnApplicationFocus(bool hasFocus)
        {
            // iOSプラットフォームでは1フレーム待つ処理がないと意図通りに動かない。
            yield return null;

            if (isRequesting && hasFocus)
            {
                isRequesting = false;
            }
        }

        #if UNITY_IOS
        IEnumerator RequestUserAuthorization(UserAuthorization mode)
        {
            isRequesting = true;
            yield return Application.RequestUserAuthorization(mode);
            // iOSではすでに権限拒否状態だとダイアログが表示されず、フォーカスイベントが発生しない。
            // その状態を判別する方法が見つからないので、タイムアウト処理をする。

            // アプリフォーカスが戻るまで待機する
            float timeElapsed = 0;
            while (isRequesting)
            {
                if (timeElapsed > 0.5f){
                    isRequesting = false;
                    yield break;
                }
                timeElapsed += Time.deltaTime;

                yield return null;
            }
            yield break;
        }
        #elif UNITY_ANDROID
        IEnumerator RequestUserPermission(string permission)
        {
            isRequesting = true;
            Permission.RequestUserPermission(permission);
            // Androidでは「今後表示しない」をチェックされた状態だとダイアログは表示されないが、フォーカスイベントは通常通り発生する模様。
            // したがってタイムアウト処理は本来必要ないが、万が一の保険のために一応やっとく。

            // アプリフォーカスが戻るまで待機する
            float timeElapsed = 0;
            while (isRequesting)
            {
                if (timeElapsed > 0.5f){
                    isRequesting = false;
                    yield break;
                }
                timeElapsed += Time.deltaTime;

                yield return null;
            }
            yield break;
        }
        #endif
#endif

        void findWebCams ()
        {
            foreach (var device in WebCamTexture.devices) {
                Debug.Log ("Name: " + device.name);
            }
        }

        void findMicrophones ()
        {
            foreach (var device in Microphone.devices) {
                Debug.Log ("Name: " + device);
            }
        }
    }
}

読みにくくてすみません、コードの意図は必要以上に詳細なコメントを読んで理解してください。
iOS/Android実機でコードを試した結果、とりあえず期待通りに動作していることを確認しました。

OnApplicationFocus()を使用してアプリフォーカスの復帰を待機する処理は、
RequestUserAuthorization as a coroutine - bugged?
のスレッドのやりとりをヒントにしています。
このためコードがかなり複雑化してしまいました。

とにかく、権限が必要なAPIを利用する前に、あらかじめこのような処理を挟んでおくこで、アプリがクラッシュするなどの事態を避けることが出来るようになりました。

APIが追加される前の古いUnityバージョンではどうする？

Androidでは以下の記事の方法で可能です。ネイティブプラグインが必要無いので気軽に導入できる方法です。
UnityでAndroidのランタイムパーミッションに対応する
iOSでもAndroidでもAssetプラグインを使えば同様の事が実現可能です。たぶん無料のものも存在するはず。

最新のUnityのAPIでも権限の処理には不十分な点も

UnityのAPIは必要最小限の簡易的なものしか用意されていません。
ネイティブアプリと同等の権限の処理をしたい場合は、やはりネイティブプラグインの利用を検討する必要があるでしょう。

参考リンク

UnityにおけるAndroidアプリのパーミッション付与について

[출처] qiita.com/utibenkei/items/65b56c13f43ce5809561

[링크] perafan.blog.me/30113207479

[설명 링크] boogong.tistory.com/42

[Nexus Font Download] www.xiles.net

[File] dp4 Font Viewer(64bit) v3.4

[Link] us.fontviewer.de/

크롬 엔코딩 자동감지 기능 삭제, 확장 프로그램을 이용한 인코딩 변경 

안녕하세요. 고코더 입니다. 

개발을 하던 중 크롬에서 아무리 찾아봐도

인코딩 강제 변경 기능이 없습니다. 

▼익스플로러에서는 마우스 오른쪽 버튼을 누르면 쉽게 인코딩을 바꿀 수 있는데요.

이상하게 생각이 들어 구글 포럼에서 알아본 결과

55버전 이후부터 "자동 인코딩 감지" 기능으로 인코딩 지정 메뉴를 삭제 하였다고 합니다.

▼ 해당 페이지에서 자세히 확인 가능합니다.

https://productforums.google.com/forum/#!topic/chrome/-Ul20dPvbbo

하지만 한글은 고급 언어라 쉽게 감지가 안되는지 여전히

잘못 감지해 외계어로 보입니다. 

메타 태그나 페이지 인코딩을 우선순위로 인코딩을 지정하는 듯 합니다

->

[IT_팁/ASP] - 메모장으로 파일 인코딩 변경하기

[IT_팁/ASP] - 에디터플러스 에서 인코딩 변경하기

결국 메뉴에서 사라진 인코딩을 

확장 프로그램을 통해 변경 해야 겠습니다.

▼아래 URL에 접근해서 "Set Character Encoding" 을 설치 해보겠습니다.

https://chrome.google.com/webstore/detail/set-character-encoding/bpojelgakakmcfmjfilgdlmhefphglae?hl=ko

▼추가 버튼으로 설치를 진행 합니다.

▼로컬에서 php파일을 만들어서 한글을 아파치에 그대로 크롬에서 실행하니

외계어로 표출 됩니다. (자동 감지라면서요ㅠ)

▼마우스 오른쪽 버튼을 눌러 설치한 확장 프로그램에서 인코딩을 utf-8로 변경 해보았습니다.

▼역시 제대로 표출 됩니다.

특히 개발시에는 필요한 지정이기에

개발자라면 설치 해놓고 사용 하시면 좋을거 같습니다.

크롬 개발자를 위한 컨텐츠

크롬 - 캐쉬 지우면서 새로고침 하기 / Clear Cache

크롬 - 사이트 로딩속도 체크 하기 / 개발자도구

console.log - 개발자도구 콘솔 창에 안보이게 하기

크롬 - 해외 무료 VPN / Browsec VPN

크롬 - 개발자 도구 다크테마(Dark theme)로 변경

쿠키 - 크롬에서 Cookie 변조(삭제,수정,변경) 하기

마무리

우리나라도 영어권 국가였으면..

출처: https://gocoder.tistory.com/215 [고코더 IT Express]

원문 : Unity Application.persistentDataPath のパスは Android のバージョンと Write Access によって異なる。

Unity Application.persistentDataPath의 경로는 Android의 버전과 Write Access에 따라 달라짐

Android에서 Application.persistentDataPath가 돌려주는 값이 Write Access에 따라 달라지기에 조사해봤습니다.
Unity 5.3.6에서 돌려주는 경로에 사양변경이 있었으므로, Unity 5.3.6 이전 버전에서 작성한 애플리케이션을 Unity 5.3.6 이후로 버전업할 때 주의를 기울이지 않으면 데이터가 사라질 위험이 있습니다.
갖고 있는 Android기기와 Unity 4.7.2f1, 5.3.6f1에서 검증했습니다.

Application.persistentDataPath

지속되는 데이터 디렉토리 경로.
세이브 데이터 등 유저 데이터를 저장하는 장소.
https://docs.unity3d.com/kr/current/ScriptReference/Application-persistentDataPath.html

Player Settings / Write Access

Internal Only로 지정해도 Application.persistentDataPath이 개발환경과 실제환경에서 돌려주는 값이 다를 수 있으므로 주의가 필요합니다!
외부 저장소라면 특별히 권한을 요구하지 않고 읽어들일 수 있으므로 디버그하기 쉽기 때문일지도?

External (SDCard)로 설정하면, SD 카드같은 외부 저장소에 대한 쓰기 접근을 가능하게 합니다. 개발 빌드(Development Build)에서는 자동적으로 켜집니다. https://docs.unity3d.com/kr/current/Manual/class-PlayerSettingsAndroid.html

External Storage

외부 저장소라고 불리는 영역이지만 SD 카드가 아니라 빼낼 수 없게 내장된 저장소를 참조하는 기기도 있음.
Android 4.4 이후에는 권한을 요구하지 않고 외부 저장소에 읽고 쓰기가 가능.

Windows PC를 예로 들면
오래된 Android 기기
C드라이브: 내장 드라이브 (Android 내부 저장소)
D드라이브: USB로 접속된 외장 하드디스크 (Android 외부 저장소)
최신 Android 기기
C드라이브: 내장 드라이브 파티션 0 (Android 내부 저장소)
D드라이브: 내장 드라이브 파티션 1 (Android 외부 저장소)
E드라이브: USB로 접속된 외장 하드디스크 (Android 외부 저장소)

모든 Android 호환 기기는 파일을 저장하는 데 사용할 수 있는 공유된 "외부 저장소"를 지원합니다. 해당 저장소는 제거할 수 있는 저장소 미디어(예: SD 카드) 또는 (제거할 수 없는) 내부 저장소일 수 있습니다.
https://developer.android.com/guide/topics/data/data-storage.html#filesExternal

Android 4.4 이상에서 앱 전용 디렉터리 파일 읽기 또는 쓰기는 READ_EXTERNAL_STORAGE 또는 WRITE_EXTERNAL_STORAGE 권한이 필요하지 않습니다.
https://developer.android.com/guide/topics/data/data-storage.html#AccessingExtFiles

일부 기기는 이동식 저장 장치 없이도 영구 저장소 공간을 "내부" 그리고 "외부" 파티션으로 나누어 항상 두 개의 저장소 공간을 제공하며, API의 동작은 외부 저장소의 이동식 유무에 상관없이 일관적입니다.
https://developer.android.com/training/basics/data-storage/files.html#InternalVsExternalStorage

Unity 5.3.6에서의 사양변경

Android: Application.temporaryCachePath and Application.persistentDataPath always return external paths starting KITKAT. (789870) https://unity3d.com/kr/unity/whats-new/unity-5.3.6

KITKAT은 Android 4.4의 코드네임. Android 4.4 이후에는 Write Access의 값에 관계없이 외부 저장소의 경로를 돌려주도록 사양변경. Android 4.4 이후 권한을 요구하지 않고 읽고 쓰기가 가능하게 되었기 때문일 것.

Player Settings / Write Access 별 Application.persistentDataPath의 값

Write Access: Internal Only

Unity 4.7.2

AndroidPath실체

Unity 5.3.6

AndroidPath실체

Write Access: External (SDCard)

Unity 4.7.2

AndroidPath실체

Unity 5.3.6

AndroidPath실체

결과

Write Access: External (SDCard)로 지정하면 androidmanifest.xml에 외부 저장소에 읽고 쓰기 권한 요구가 추가됩니다.
WRITE_EXTERNAL_STORAGE 권한으로 읽고 쓰기도 가능.

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

WRITE_EXTERNAL_STORAGE를 추가한 경우, Android 6 이후에는 Permissions Storage의 물음에서 ALLOW를 선택할 때까지는 기동할 때마다 물어봄.
ALLOW를 선택한 후에도 Application의 설정에서 Permissions Storage 허가의 변경은 가능.
4.1.2 (200SH): Write Access: External (SDCard) 만이 SD 카드의 경로를 돌려줌.
SD 카드를 뽑았을 경우에는 Internal Only와 같은 경로를 돌려줌.
그 외에는 내부 저장소를 참조.
Unity 4.7.2 Android 6.0.1는 Permissions Storage의 허가 유무로 돌려주는 경로가 달라짐.
Unity 5.3.6 Android 4.4 이후는 Permissions Storage의 허가 유무와 상관없이 돌려주는 값이 같음.

Unity 4.7.2에서 작성한 애플리케이션에서 Application.persistentDataPath에 저장한 데이터를 Unity 5.3.6에서 작성한 애플리케이션에서 덮어씌웠을 경우 읽어들일 수 있을까?

internal-storage: /data/data/{package name}/files/
external-storage: /storage/emulated/0/Android/data/{package name}/files/

Android 4.1.2 (200SH)

Unity 4.7.2 Write AccessUnity 5.3.6 Write Access읽기 가능?거동

Android 4.2.2 (SO-02F)

Unity 4.7.2 Write AccessUnity 5.3.6 Write Access읽기 가능?거동

Android 5.0.2 (HTV31)

Unity 4.7.2 Write AccessUnity 5.3.6 Write Access읽기 가능?거동

Android 6.0.1 (SCV31)

Unity 4.7.2 Write AccessUnity 5.3.6 Write Access읽기 가능?거동

결과

Internal Only, External (Permissions Storage: DENY)일 때에는 internal-storage를 external-storage에 복사한 후에 읽어들이도록 되어 있음.
external-storage로 변경해도 internal-storage는 복사 시점 그대로 변경은 되지 않음.

정리

Internal Only -> External (SDCard)로의 변경은 데이터를 이어받지 못하는 경우가 있음. 그 경우, 수동으로 /data/data/{package name}/files/ 를 복사하는 등의 대응이 필요.
External (SDCard) -> Internal Only로의 변경은 오래된 Android 기기기에서 정상으로 처리되지 않을 가능성이 있음.
Android 6 이후에는 Unity 4.7.2의 Write Access가 어느쪽이든 Unity 5.3.6의 Write Access: Internal Only로 해두면 데이터를 이어받아 읽고 쓰기가 가능.

[출처] gist.github.com/overworks/541fcb519bc23cd14cf622c2baa28d3b

[패키지 다운로드]

[에셋] assetstore.unity.com/packages/vfx/shaders/fullscreen-camera-effects/colorblind-effect-76360

Colorblind Effect

View on Asset Store User Manual​
Colorblind Effect (CBE) is a Fullscreen Camera Effect for Unity 5

Up to 8% of men (and about 0.5% of women) are affected by some type of color vision deficiency. Use this plugin to help you design better user experience and see how is your game perceived by colorblind people.

Screenshots made with Painterly Nature package.

Features

• Three most common types of colorblindness
• Simple setup and control
• Compatible with all Unity rendering paths (Forward, Deferred and Legacy) and anti-aliasing
• No perceptible performance hit
• Works with GUI components (with Canvas render mode set to Screen Space - Camera)
• Plugin is not tested on mobile devices.

Changelog
1.0

• Initial release