You Know Programing?

설명

런처이미지 사이즈에 대해서 포스팅 하겠습니다. 3.5인치에서 4인치 화면만 있다가 4.7인치와 5.5인치가 추가될때 런처이미지를 추가 하지 않으면 4.7과 5.5인치에서는 그냥 확대된 상태로만 나오던 적이 있었습니다. 애플에서 설명을 하는 런처이미지는 이렇습니다.

A launch screen appears instantly when your app starts up.
The launch screen is quickly replaced with the first screen of your app,
giving the impression that your app is fast and responsive.
The launch screen isn’t an opportunity for artistic expression.
It’s solely intended to enhance the perception of your app as quick
to launch and immediately ready for use. Every app must supply a launch screen.

앱이 시작되면 즉시 런처이미지가 나타납니다. 런치이미지는 빠르게 앱의 시작화면으로 바뀌어서 빠르게 반응하는 것 같은 인상을 줍니다. 런처이미지는 예술적으로 표현하는 곳이 아닙니다. 다만 앱이 즉시 사용 준비가 된 상태라는 것을 알려주기 위한 용도로만 사용도비니다. 모든 앱에서는 런처이미지를 제공해야됩니다. (직역입니다. 틀린부분이 있을텐데 그냥 넘어가주세요.. 영어공부 열심히 하겠습니다…)

앱이 시작되는 부분에서 나타나는 화면이고, 앱이 사용할 준비가 끝나면서 사라지는 장면이라는 것입니다.

이미지 사이즈 표

맞치며

사실 LaunchScreen.storyboard 여기서 통합적으로 해주면 되기는 합니다. 오토레이아웃도 사용할 수 있고요. 아이폰x에서 탭바가 네이비게이션 이동을 탭바를 사라지게 하는 hidesBottomBarWhenPushed 옵션을 주게 되면 위로 올라갔다가 사라지는 이슈가 있는데,, 아이폰x 런처 이미지를 넣어주면 해결 된다는 글을 본적이 있습니다. (적용을 해봤지만 실패 해서 일단 다른 방법을 사용 하고 있습니다.) 필요로 하면 넣어주는게 맞는거 같습니다. 포스팅에 잘못된점이 있으면 댓글 달아주시면 수정하도록 하겠습니다.

iOS 리젝사유) Apple 소프트웨어 또는 하드웨어에 대한 언급

앱을 업데이트 할때 ‘이 버전에서 업그레이드된 사항’ 이라는 메타데이터 항목이 있습니다. 거기에

• iOS11 대응 업데이트

라고 적었던 부분이 문제가 되었습니다. 다른 앱들이 업데이트내역을 볼때 ‘iOS11 지원’ 이런식으로 써놨기에 문제가 되지 않는다고 생각했는데 리젝을 맞았습니다.
리젝 사유는 아래와 같습니다.

리젝 사유

Your app or its metadata contains references to a pre-release version of Apple software or hardware.
 Apps with compatibility references to a pre-GM version of iOS SDK or pre-released Apple hardware are not in compliance with the Apple Developer Program License Agreement.

Specifically, section 2.3 states:
"Apple may provide You with pre-release versions of the Apple Software or related services that 
constitute Apple Confidential Information and are subject to the confidentiality obligations of this Agreement."

해결 방안

해결방안은 매우 간단합니다. 앱 및 메타 데이터에서 시험판 버전의 Apple관련 소프트웨어 및 하드웨어 언급을 모두 제거 하거나 변경 하면 됩니다.

마치며

소프트웨어나 하드웨어 관련 언급을 다 제거 하라고 해결 방법을 가르쳐줬는데,, ‘iOS11 지원’ 이라는 문구는 왜 통과가 되는지 애매모호 한거 같습니다. ‘iOS11 지원’으로 변경 한후 다시 심사에 맡겼는데 심사를 한번 지켜 봐야겠습니다. 추후 결과는 이글을 통해 업데이트 하겠습니다  (무사히 통과되었습니다.)

여담이지만 심사기간이 정말 빨라진거 같습니다.

EUC-KR 인코딩 하기

설명

iOS에서 EUC-KR로 인코딩 하는 문제가 프로젝트를 진행하면서 오랜 시간동안 Warning을 발생시켜서 눈에 가시처럼 보였는데 해결방안을 찾아서 포스팅 하게 되었습니다. 일단 먼저 EUC-KR(EUC-KR은 KS X 1001와 KS X 1003을 사용하는 8비트 문자 인코딩, EUC의 일종이며 대표적인 한글 완성형 인코딩이기 때문에 보통 완성형이라고 불린다. - 위키백과사전) 말그대로 한글 완성형 인코딩이기 때문에 오랜 시간 사용해왔습니다. 네이버,네이트,우체국등 오래된 한국기업 웹페이지는 EUC-KR로 되어있습니다. UTF-8을 사용하면 좋겠지만 용량문제, 전환비용등 때문인지 아직도 사용되고 있습니다. 특히 우체국 API를 통해 주소 검색을 구현할때는 쿼리를 EUC-KR로 인코딩 해서 보내야 올바른 값을 받을 수 있습니다.
기존에 사용 하고 있던 이 방식은 안타깝게도 iOS9버전 부터는 Warning을 발생시킵니다. iOS9에서는 더 이상 사용되지 않기 때문에 권장 UTF-8인코딩을 사용하라는 것입니다.

 NSString *queryString = [str stringByAddingPercentEscapesUsingEncoding:-2147481280];

    //first deprecated in iOS 9.0 - Use -stringByAddingPercentEncodingWithAllowedCharacters: instead, which always uses the recommended UTF-8 encoding, and which encodes for a specific URL component or subcomponent since each URL component or subcomponent has different rules for what characters are valid.

포기하고 있다가 다른분을 도와주다가 우연찮게 찾아서 이렇게 포스팅을 하게되었습니다.

사용환경

* Swift3.x
* Xcode 8.3.3

소스 코드

• Objective-C

- (NSString *)euckrEncodingObjectiveC:(NSString *)str {

    NSMutableString *outputQuery = [NSMutableString string];

    NSUInteger encoding = CFStringConvertEncodingToNSStringEncoding(kCFStringEncodingEUC_KR);
    const char * source = [str cStringUsingEncoding:encoding];
    NSInteger sourceLen = strlen((const char *)source);

    for (int i = 0; i < sourceLen; ++i)
    {
        const unsigned char thisChar = source[i];
        if (thisChar == ' ') {
            [outputQuery appendString:@"+"];
        } else if (thisChar == '.' || thisChar == '-' || thisChar == '_' ||
                 (thisChar >= 'a' && thisChar <= 'z') ||
                 (thisChar >= 'A' && thisChar <= 'Z') ||
                 (thisChar >= '0' && thisChar <= '9'))
        {
            [outputQuery appendFormat:@"%c", thisChar];
        } else {
            [outputQuery appendFormat:@"%%%02X", thisChar];
        }
    }
    return outputQuery;
}

• Swift

func euckrEncoding(_ query: String) -> String { //EUC-KR 인코딩

    let rawEncoding = CFStringConvertEncodingToNSStringEncoding(CFStringEncoding(CFStringEncodings.EUC_KR.rawValue))
    let encoding = String.Encoding(rawValue: rawEncoding)

    let eucKRStringData = query.data(using: encoding) ?? Data()
    let outputQuery = eucKRStringData.map {byte->String in
        if byte >= UInt8(ascii: "A") && byte <= UInt8(ascii: "Z")
            || byte >= UInt8(ascii: "a") && byte <= UInt8(ascii: "z")
            || byte >= UInt8(ascii: "0") && byte <= UInt8(ascii: "9")
            || byte == UInt8(ascii: "_") || byte == UInt8(ascii: ".") || byte == UInt8(ascii: "-")
        {
            return String(Character(UnicodeScalar(UInt32(byte))!))
        } else if byte == UInt8(ascii: " ") {
            return "+"
        } else {
            return String(format: "%%%02X", byte)
        }
        }.joined()

    return outputQuery
}

마치며

EUC-KR보다 UTF-8을 권장하지만 아직 한국내에서는 불가능한거 같습니다. 위에도 언급해듯이 전환비용, 용량문제등 아직 해결할 문제들이 많은거 같습니다. 오랫동안 눈에 밟히던 Warning을 없앤것만으로도 기분 좋은 일인거 같습니다. 틀린점이나 궁금한점이 있다면 댓글 남겨주시면 감사합니다 :)

참고 사이트

https://stackoverflow.com/questions/41270687/swift-euc-kr-korean-encoding-not-working-but-works-in-python