https://learn.microsoft.com/ko-kr/dotnet/csharp/fundamentals/tutorials/safely-cast-using-pattern-matching-is-and-as-operators

즉, 강제 캐스팅은 https://learn.microsoft.com/ko-kr/dotnet/api/system.invalidcastexception?view=net-8.0 될 위험성이 있으나, as 키워드를 사용한 캐스팅은 내부에서 이를 검사하여 에러를 발생시키지 않고 null을 반환하도록 되어 있음.

이번 iOS 심사를 넣고 2번 리젝이 되었다.

이유는 네트워크 통신이 불가능한 상태..

리뷰어가 심사시 테스트한 환경과 맞추기 위해 IPV6를 로컬로 테스트할수 있는 환경을 만든후

iOS14.0.1 OS가 설치된 디바이스를 해당 WIFI에 물려본 결과..

전혀 네트워크 통신이 안되는 상황 발생 (앱뿐만이 아니라 SAFARI에서도 웹페이지 접근 불가)

iOS13까지는 무리 없이 테스트가능한 방법이었으나, 14로 올라오면서 네트워크와 관련된 변경점때문인지 위와 같은 방법으로는 테스트가 불가능했다.

최초 리젝된 이유는 앱이 크래시가 발생한다는 것이었는데, 이 문제는 네트워크 라인은 물린 상태에서 송신후 수신을

무한히 대기할 경우 프로젝트에서 쓰고있는 보안솔루션과 문제가 발생되어 크래시가 나는 것을 확인하여 이부분은 수정을 했다.

두번째 리젝은 말 그대로 크래시는 아니나 네트워크 통신이 불가능한 현상이었는데,

이때 게임 서버와의 프로토콜 통신이 일반 HTTP 였다.. SSL이 적용된 주소로 변경 후 재심사를 넣었고,

통과되었다..

의문점은 물리적으로 동일한 라이브러리를 쓰고 있는 다른 앱의 경우 SSL이 적용되지 않았음에도

무리없이 한방에 통과됬다는거다...

간혹 우리가 볼때는 문제가 없으나, 애플이 볼때, 그것도 원인을 찾기 매우 어려운 이슈일 경우

스트레스가 어마어마하다...

해결되었으니 일단 한숨돌리고..

https://stackoverflow.com/questions/50689859/download-large-file

https://forum.unity.com/threads/uwp-memory-leak-when-downloading-large-files.765122/#post-5103632

위 두 링크의 내용을 축약하면..

UnityWebRequest를 사용하여 텍스쳐를 다운로드를 한 후, 다운로드된 리소스를 처리하기 위해 직접 www.downloadHandler.data에 Access 하게 되면, 리턴을 위해 내부에서 새로운 바이트 배열이 생성되므로 메모리 관리에 매우 취약하다는 내용.

첫 번째 링크처럼 만약 다운로드한 리소스를 파일로 저장하거나 특정 목적으로 사용할 경우 그에 맞는 downloadHandler를 전송 전에 할당하여 처리할 수 있도록 해야 함.