페이지

2010년 12월 16일 목요일

동적인 UIActionSheet 와 취소버튼 붙이기

- (void)presentSheet
{
UIActionSheet *menu = [[[UIActionSheet alloc] initWithTitle:nil delegate:self cancelButtonTitle:nil destructiveButtonTitle:nil otherButtonTitles:nil] autorelease];
for (int i = 0; i < URLStringArray.count; i++) 
 [menu addButtonWithTitle:[URLStringArray objectAtIndex:i]];
[menu addButtonWithTitle:@"취소"];
[menu setCancelButtonIndex:menu.numberOfButtons - 1];
}

2010년 12월 14일 화요일

아스키코드표



GMT로 시간데이터를 받아올 경우, 시차 적용법

NSDate *currentRealDate = [NSDate date];
NSTimeZone *timeZone = [NSTimeZone defaultTimeZone];

NSDateComponents *offsetComponents = [[NSDateComponents alloc] init];
[offsetComponents setSecond:(-1*[timeZone secondsFromGMTForDate:currentRealDate])];
NSCalendar *gregorian = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar];
NSDate *currentDate = [gregorian dateByAddingComponents:offsetComponents toDate:currentRealDate options:0];

2010년 11월 29일 월요일

인덱스패스로 셀 찾긔

NSIndexPath *firstIndexPath = [NSIndexPath indexPathForRow:1 inSection:1];
UITableViewCell *cell = [[self tableView] cellForRowAtIndexPath:firstIndexPath];

2010년 11월 14일 일요일

Declared Properties

header file에서 @property 선언은 getter/setter가 구현되있음을 알리는 것이고, implementation에서 @synthesize는 이것을 자동으로 구현해 주는 것이다. @synthesize를 사용하지 않으면 직접 구현해주면 된다.
@property class명 instance명;
여기서 @property와 class명 사이에 () 안에 ,로 구분지어진 속성을 넣을 수 있는데
Writability에 관한 : readwrite, readonly
Setter Semantics에 관한 : assign, retain, copy
Atomicity에 관한 : nonatomic, atomic
getter/setter naming에 관한 : getter=getterName, setter=setterName
이 있다.
Markup and Deprecation 또한 지원한다.
예를들자면

@property CGFloat x
AVAILABLE_MAC_OS_X_VERSION_10_1_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_4;

이런 식,
IBOutlet 또한 선언할 수 있다. (formal part는 아님)

위에서 @synthesize로 자동구현한다고 했는데 @dynamic도 사용할 수 있다.
property=ivar to indicate that a particular instance variable should be used for the property!
즉 ivar이라는 instance variable이 property로 사용된다는 얘기


@synthesize firstName, lastName, age = yearsOld;

예를들면 이렇다.
@dynamic의 경우는 getter/setter method가 동적으로 (파일 임포트라던가?) 로딩될 때 사용한다. 반드시 어디서 구현되있는지 프로그래머가 알고 사용해야 에러가 나지 않겠쬬
(Core Data 를 사용할때에는 NSManagedObject가 관리하기 때문에 property들의 getter/setter method를 구현할 필요는 없지만 propoerty를 사용한다면 @dynamic 으로 선언해줘야한다.)






Copy

If you use the copy declaration attribute, you specify that a value is copied during assignment. If you synthesize the corresponding accessor, the synthesized method uses the copy method. This is useful for attributes such as string objects where there is a possibility that the new value passed in a setter may be mutable (for example, an instance of NSMutableString) and you want to ensure that your object has its own private immutable copy. For example, if you declare a property as follows:
@property (nonatomic, copy) NSString *string;
then the synthesized setter method is similar to the following:
-(void)setString:(NSString *)newString {
if (string != newString) {
[string release];
string = [newString copy];
}
}
Although this works well for strings, it may present a problem if the attribute is a collection such as an array or a set. Typically you want such collections to be mutable, but the copy method returns an immutable version of the collection. In this situation, you have to provide your own implementation of the setter method, as illustrated in the following example.
@interface MyClass : NSObject {
NSMutableArray *myArray;
}
@property (nonatomic, copy) NSMutableArray *myArray;
@end
@implementation MyClass
@synthesize myArray;
- (void)setMyArray:(NSMutableArray *)newArray {
if (myArray != newArray) {
[myArray release];
myArray = [newArray mutableCopy];
}
}
@end

* 아래는 그냥 이점~
Declared properties address the problems with standard accessor methods by providing the following features:
  • The property declaration provides a clear, explicit specification of how the accessor methods behave.
  • The compiler can synthesize accessor methods for you, according to the specification you provide in the declaration. This means you have less code to write and maintain.
  • Properties are represented syntactically as identifiers and are scoped, so the compiler can detect use of undeclared properties.

Your First iOS Application

간략히 정리를 해보고 찾기힘든 링크들 정리 @_@
- 어떤 UIViewController를 application과 동일한 lifetime을 가지게 하고싶다면 application delegate의 instance로 선언하면 된다. 자세한건 > Memory Management Programming Guide
단순 UIViewController의 subclass를 instance 변수로 선언해두면 어떤 class를 사용할 것이라고 미리 선언해주어야 하는데, header파일을 import해도 되지만 이렇게 미리 import할 필요 없이 사용할 클래스명만 미리 선언해서 에러가 없도록 해주고 이 클래스 어디선가 쓰인다는 메시지만 전할 수 있다. 이를 forward declaration이라고 하며 @class와 같이 설정한다.
( 이 방법은 두 클래스가 서로의 header파일을 참조해야하는 circle이 생기는 것 또한 방지해준다. 그러므로 header file의 import는 .m 파일에서하고, header file에서는 forward declaration만 사용해야 하겠죠??)
Resource Programming Guide
Memory Management Rules
Accommodating Multitasking.

2010년 11월 10일 수요일

libxml 라이브러리를 참조하는 방법

/Developer/~의 절대경로를 쓰고싶겠지만 이것을 Header Search Paths에 추가해봤자 참조되지 않는다!
그것은 바로가기일 뿐..
방법은 /usr/include/libxml2를 추가할 것 (Mac에 존재하는 path란다.)
이것은 framework와 다르게 .dylib파일이므로, 저렇게 프로젝트에 더한후 Header Search Path를 추가하는 작업이 필요하다.
흑흑.
아래는 stackoverflow에서 줏은 답변의 원문

Form the link of @Matt Ball,
I found following helpful to me.
You need to add libxml2.dylib to your project (don't put it in the Frameworks section). On the Mac, you'll find it at /usr/lib/libxml2.dylib and for the iPhone, you'll want the /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS2.0.sdk/usr/lib/libxml2.dylib version.
Since libxml2 is a .dylib (not a nice friendly .framework) we still have one more thing to do. Go to the Project build settings (Project->Edit Project Settings->Build) and find the "Search Paths". In "Header Search Paths" add the following path on the Mac:
/usr/include/libxml2

2010년 11월 9일 화요일

OAuth


OAuth란?

Open API를 사용하기 위해선 인증이 필요합니다.

인증방식의 표준이 없기 때문에 제 각각의 방법으로 개발되고 있는 실정인데요

구글의 AuthSub, AOL의 OpenAuth, 야후의 BBAuth

OAuth는 제각각의 인증방식을 표준화하고 가장 좋은 방법만 가져다 만들었습니다.

즉 매쉬업 서비스로 만들어진 어플리케이션이 다른 어플리케이션의 사용자 정보를 접근할 수 있는

표준화된 방법을 제공하는 스펙입니다.

OAuth 인증방식을 이해하기 위해선

용어를 미리 숙지하셔야 합니다.

◦ 서비스 프로바이더(Service Provider) – OPENAPI를 제공하는 서비스를 말합니다
◦ 사용자(users) - 서비스 프로바이더 혹은(그리고컨수머를 사용하는 이를 말합니다
◦ 컨수머(Consumer) – API를 사용하여 개발된 애플리케이션 서비스를 말합니다.
◦ 보호된 자원(Protected Resources): 서비스 프로바이더에 존재하는 사용자의 데이터를 의미합니다.
◦ 컨수머 개발자(Consumer Developer) : 컨수머를 개발하는 개인 혹은 단체
◦ 컨수머 키(Consumer Key) : 서비스 프로바이더에게 컨수머 자신임을 인증하기 위한 키
◦ 컨수머 시크릿(Consumer Secret) : 컨수머의 컨수머 키 소유권한이 있는지 인증하기 위한 키
◦ 토큰(Tokens) – 컨수머에서 서비스 프로바이더에 있는 사용자의 보호된 자원에 접근하기 위해 사용되는
                       사용자의 인증정보입니다.

  리퀘스트 토큰(Request Token) :  컨수머가 사용자에게  접근권환을 획득하는 과정에서 사용하는   
                                               값이며, 이것은 차후 액세스 토큰으로 교환됩니다.
  리퀘스트 토큰 시크릿(Request Token Secret) :  리퀘스트토큰이 사용자의 것임을 인증하기 위한
                                                                 값입니다.
  액세스 토큰(Access Token) : 컨수머가 사용자의 서비스 프로바이더를 통해서가 아닌 컨수머를
                                          통해서 보호된 자원에 접근할 수 있는 권한을 받기 위한 값입니다.
         ▪  액세스 토큰 시크릿(Access Token Secret) : 액세스토큰이 사용자의 것임을 인증하기 위한
                                                                      값입니다.

OAuth 인증방식의 흐름도입니다.


OAuth 인증 방식에는 7가지의 인증과정으로 이루어져 있습니다.

A; Consumer가 Request Token 요청
B; Service Provider가 Request Token 발급 
C; Consumer는 사용자를 Service Provider로 이동사용자를 인증하고 토큰 발급을 확인함
D; Service Provider는 사용자를 Consumer로 이동 
E; Consumer는 Access Token 요청 
F; Service Provider는 Consumer의 신원과 Request Token 확인Access Token 발급
G; Consumer는 Access Token으로 사용자 정보에 접근

끝으로 관련 사이트입니다.


현재 오픈마루에서 OAuth 인증방식을 지원하고 있습니다.


OAuth 인증 관련 예제


출처 : Naver OPEN API 공식CAFE

2010년 10월 28일 목요일

필요한 랜덤수의 개수를 담으면, 랜덤수를 담은 배열을 리턴하는 메소드

+ (NSArray*)makeRandomIndexArray:(NSUInteger)countOfIndices
{
srand(time(NULL));
NSMutableArray* indices = [[NSMutableArray alloc] initWithCapacity:countOfIndices];
NSMutableArray* tempArray = [[NSMutableArray alloc]initWithCapacity:countOfIndices];
for (NSUInteger i = 0; i < countOfIndices; i++) 
{
[tempArray addObject:[NSNumber numberWithInt:i]];
}
for (NSUInteger i = 0; i < countOfIndices; i++) 
{
NSUInteger randomNumber = (rand()% (countOfIndices-i) );
NSNumber* number = [tempArray objectAtIndex:randomNumber];
[indices addObject:number];
[tempArray removeObjectAtIndex:randomNumber];
}
[tempArray release];
return (NSArray*)[indices autorelease];
}

2010년 10월 17일 일요일

UINavigationBar에 Background image설정하기

UINavigationBar에 Background image를 설정하는 간단한 방법으로는

UIImage *backImage = [UIImage imageNamed:@"title-bar.png"];
UIImageView *backImageView = [[UIImageView alloc] initWithImage:backImage];
[self.navigationController.navigationBar insertSubview:backImageView atIndex:0];

와같이 0번 index에 이미지뷰를 서브뷰로 더하는 것이다.

하지만 이렇게 할 경우 다음 depth로 넘어가자 타이틀이 가려지는 현상이 발생했다.
검색을 해보니 다양한 문제가 발생하기도 했는데 이를 완연히 방지하기 위해서는
UINavigationBar에 카테고리를 더해

#import "UINavigationBar+BackgroundImage.h"


@implementation UINavigationBar (BackgroundImage)

- ( void )drawRect:( CGRect )rect
{
    [ [ UIImage imageNamed:@"title-bar.png" ] drawInRect:CGRectMake( 0, 0, self.frame.size.width, self.frame.size.height )];
}

@end

와같이 drawRect를 구현해주면 별도의 설정없이 이미지가 더해진다.

2010년 10월 12일 화요일

MPMoviewPlayerController


Supported Formats

This class plays any movie or audio file supported in iOS. This includes both streamed content and fixed-length files. For movie files, this typically means files with the extensions .mov,.mp4.mpv, and .3gp and using one of the following compression standards:
  • H.264 Baseline Profile Level 3.0 video, up to 640 x 480 at 30 fps. (The Baseline profile does not support B frames.)
  • MPEG-4 Part 2 video (Simple Profile)
If you use this class to play audio files, it displays a white screen with a QuickTime logo while the audio plays. For audio files, this class supports AAC-LC audio at up to 48 kHz, and MP3 (MPEG-1 Audio Layer 3) up to 48 kHz, stereo audio.

 네트워크로 받아온 동영상을 재생하고 싶은 경우 성능상의 이유로 먼저 파일을 다운로드한 후에 local file을 재생하는 것이 좋습니다.

2010년 10월 6일 수요일

UIWebView가 자동으로 bounces되는 것 막기

subview중 scrollView를 찾아서 해결
for (id subview in testWebView.subviews)
    if ([[subview class] isSubclassOfClass: [UIScrollView class]])
        ((UIScrollView *)subview).bounces = NO;

2010년 10월 5일 화요일

구글맵에서 찾은 장소의 위치와 경도 알아내기

구글맵에서 원하는 장소를 찾은 뒤 주소창에
javascript:void(prompt('', gApplication.getMap().getCenter()));
라고 입력하면 된다.

2010년 9월 30일 목요일

Model View Controller

 Smalltalk 에서 처음 소개되었던 Model View Controller(이하 MVC)패턴은 Cocoa frameworks의 전반적인 기반으로 사용된다.  모든 Object를 세가지 종류 중 하나로 분리하는 작업이 필요하다.
Model : Model은 어플리케이션의 단일한 능력이나 정보를 제공하는 객체이다.  View나 Controller와 의존성이 없어야 한다.
View : View는 Model과 합쳐진 정보를 나타내거나, 사용자와 상호작용을 하는데 사용된다. View는 웹기반이 될 수도, Command line기반이 될 수도, GUI가 될 수도 있다. 이러한 다양한 View는 같은 Model과 작용할 수 있어야 한다.
Controller : Controller의 목적은 Model과 View의 기능을 분리 시키는 데에 있다. View에서 사용자와의 상호작용의 결과를 이용해, Model의 정보를 변화시킨다.
 MVC의 기본적인 목적은 Model과 View, Controller의 기능을 분리시켜 각각의 변화가 생겨도 서로 간의 영향을 주지 않도록 하는데에 있다.

MVC in Cocoa
 Model은 Core Data가, View와 Controller는 Application Kit이 제공한다. Foundation framework은 위의 3 subsystems에서 사용되는 class를 제공한다. Model은 Cocoa framework외에 다른 subsystems에서도 사용될 수 있도록 구현되기도 한다. 하지만 Core Data frameworks는 강력하고 유연한 기능을 제공하므로, Cross-platform이 필요하지 않다면 Cocoa 기술을 이용해서 Model을 설계하는것이 유리하다.

Core Data / Model
 Model은 영구정보저장과, Object relationship management의 문제를 해결해야한다. Binary file 혹은 사람이 읽을 수 있는 Text file 등 여러 방법으로 저장할 수 있다. Core Data는 XML, binary flat files, SQLite database 3가지의 file format을 가지고 있다.
 Core Data는 3가지의 file format을 개발과정에서 자유롭게 바꾸거나 3가지 모두 동시에 지원가능하도록 해준다.
 대부분의 Model은 여러 objects간의 관계를 관리해준다. Core Data는 one to one, one to many 관계를 지원한다. 각 관계는 옵션이거나 필수일 수 있다. Core Data는 relationships, constraints, default values 를 개발자가 정의할 수 있도록 제공하고, relationship을 validate해준다.
 Apple의 Xcode tool의 Graphical object modeler를 이용하면, graphical하게 Model object를 정의할 수 있다.

Application Kit / View
 모든 Cocoa application은 OS와 연결을 유지하기 위해서 NSApplication의 Instance를 사용한다. NSApplication, NSView, NSWindow는 모두 NSResponder의 Subclasses다. NSResponder는 Responder Chain design pattern을 구현한다.
 NSView는 Hierarchies pattern을 구현한다. 모든 NSView는 Subviews를 가질 수 있다.
 Cocoa의 대부분의 UI Components는 NSControl의  Subclasses이다. NSControl은 Targets and Actions와 Responder Chain patterns의 중요한 역할을 한다.
 NSCell은 Flyweight pattern을 구현한다. Flyweight는 수행시간과 Memory소비를 최적화한다. NSControl의 Instances는 최적화와 유연성을 더하기 위해서 NSCell의 Subclasses를 사용한다.

Application Kit / Controller

2010년 9월 19일 일요일

(한글) 앱스토어 리뷰가이드 라인

우리는 당신이 iOS를 위한 어플리케이션을 개발하려고 하는 것을 매우 기쁘게 생각합니다. iOS 앱 개발은 직업적, 금전적으로 수많은 개발자들에게 도움을 주고 있는 작업이며, 우리는 당신이 이 성공적인 개발자들의 대열에 합류하길 기원합니다. 우리가 앱스토어 리뷰 가이드라인을 작성한 것은 이번이 처음입니다. 우리는 이 리뷰가 당신이 앱을 개발하는데 발생할 수 있는 문제에 대해 명확한 지침을 제공해줄 수 있을거라고 기대하며, 그로 인해 앱 승인 절차를 빠르게 할 수 있을거라고 생각합니다.

우리는 앱을 책이나 노래 따위의 우리가 취급하지 않는 것들과는 다르게 보고 있습니다. 만약 당신이 종교를 비판하고 싶다면 책을 쓰십시오. 만약 당신이 섹스에 대해 묘사하고 싶다면 책을 쓰거나 노래를 만들거나, 혹은 의학적 서류를 만드십시오. 구분하기 다소 복잡할 수 있습니다만, 우리는 그런 류의 컨텐츠들을 앱스토어에 등록하지 못하도록 결정하였습니다. 하기의 지침들을 인지하는 것이 당신들의 앱 개발에 도움이 될 것입니다.

 많은 아이들이 앱들을 다운받고 있으며, 부모들이 별도로 아이들을 위한 컨트롤 장치를 세팅하지 않는 한 아이들의 앱
    다운로드를 제어할 수 있는 방법은 없습니다. (많은 부모들이 보통 그 장치를 세팅하지 않습니다.) 우리가 아이들에게
    나쁜 영향을 주지 않도록 항상 주의하고 있음을 주지하십시오.


 앱스토어에는 250,000개가 넘는 앱들이 있습니다. 더 이상의 의미없는 앱들은 필요없습니다. 당신이 만든 앱이 실용적
    으로 쓸모있거나 혹은 지속적인 즐거움을 제공할 수 없다면 우리는 그 앱을 승인하지 않을 수 있습니다.


 만약 당신이 만든 앱이 고작 며칠 사이에 조잡하게 만들어졌다고 보이거나, 당신의 친구들에게 보여주기 위해 연습용
    으로 만든 앱을 스토어에 올릴 경우 해당 앱들은 승인 받지 못할 것입니다. 많은 전문 앱 개발자들은 자신들의 양질의
    개발물이 아마추어들이 유희로 만든 것들과 같이 앱스토어에 전시되는 것을 원하지 않습니다.


 우리가 판단하기에 선을 넘었다고 보이는 컨텐츠나 행동을 다룬 앱은 승인을 거부당할 수 있습니다. 당신이 그 기준이
    무엇이냐고 묻는다면, “보면 알것입니다.” 라고 대답하겠습니다. 우리는 당신들 역시 그 기준을 충분히 인식할 수 있을
    거라고 생각합니다.


 만약 당신의 앱이 승인을 거부당했을 경우, 당신은 우리가 제공하는 Review Board를 통해서 이를 어필할 수 있습니다.
    당신이 이런 프로세스를 따르지 않고 언론사에 우리를 비난한다고해서 그 문제를 해결하지는 못할 것입니다.


 이 가이드라인은 지속적으로 업데이트될 수 있습니다. 만약 새로이 개발된 앱이 새로운 문제점을 야기할 경우 우리는
    새 룰을 언제든 추가할 수 있습니다.

 어쩌면 당신이 만든 앱이 그것을 불러올지도 모릅니다.
 
마지막으로, 우리는 당신이 개발하는 앱을 매우 좋아하며 당신이 하는 일들에 존경심을 가지고 있습니다. 우리는 앱 개발에 있어서 당신의 능력을 최대한 발휘할 수 있는 최고의 플랫폼을 구축할 수 있도록 노력하고 있습니다. 어쩌면 당신이 보기에 우리의 통제가 지나치다고 생각할지도 모르지만, 만약 그렇다면 그건 우리가 고객의 입장에서 생각하고 그들이 우리의 제품을 통해 양질의 경험을 할 수 있도록 신경쓰기 때문 일 겁니다. 그런 생각은 당신들 대부분도 아마 마찬가지일겁니다.
목차
1. 약관
2. 기능성
3. 메타데이터, 등급, 순위
4. 지역
5. 알림서비스 (푸쉬 노티피케이션)
6. 게임센터
7. 전자광고
8. 상표, 상품외장
9. 미디어 컨텐츠
10. 유저 인터페이스
11. 구입, 통화
12. 긁어오기, 종합
13. 기기에 손상
14. 개인적인 공격
15. 폭력성
16. 거부감을 주는 컨텐츠
17. 사생활
18. 포르노그래피
19. 종교, 문화, 인종
20. 컨테스트, 경품, 복권, 추첨
21. 자선, 기부
22. 법적 요구사항
1. 약관
1.1     앱스토어의 어플리케이션을 개발하는 개발자로서 당신은 Program License Agreement (PLA), Human Interface
          Guidelines (HIG), 그 외에 다른 애플과 맺은 라이센스 혹은 계약들에 종속된다. 하기의 룰과 예시는 당신이 만드는
          앱이 승인을 받는데 도움을 주기 위한 것이지 다른 협의문을 수정하거나 그에 종속된 조항을 무효화하기 위함이
          아니다.
2. 기능성
2.1     (시스템을) 고장내는 앱은 승인하지 않는다.
2.2     버그가 발견되는 앱은 승인하지 않는다.
2.3     개발자가 명시한대로 작동하지 않는 앱은 승인하지 않는다.
2.4     문서 상의 설명과는 일치하지 않는 숨겨진 요소 혹은 불법적 요소를 포함한 앱은 승인하지 않는다.
2.5     공개되지 않은 API(어플리케이션 프로그래밍 인터페이스)를 사용한 앱은 승인하지 않는다.
2.6     할당된 공간 외의 곳에서 데이터를 읽거나 쓰는 앱은 승인하지 않는다.
2.7     어떤 방식이나 형태로든 코드를 다운받는 앱은 승인하지 않는다.
2.8     다른 실행 가능한 코드를 인스톨 혹은 실행시키는 앱은 승인하지 않는다.
2.9     “베타”, “데모”, “체험판” 혹은 “테스트” 버전인 앱들은 승인하지 않는다.
2.10   아이폰 앱은 별도의 조정없이 아이패드에서도 사용할 수 있어야한다. 해상도는 아이폰과 동일, 아이폰3GS의 2배
          이다.
2.11   앱스토어에 이미 있는, 그중에서도 특히 유사한 종류 여럿이 존재하는 앱을 복제한 앱은 승인하지 않는다.
2.12   실용적으로 유용하지 않거나 지속적인 오락적 가치를 제공하지 못하는 앱은 승인하지 않는다.
2.13   마케팅이나 광고가 주목적으로 제작된 앱은 승인하지 않는다.
2.14   명확하게 명시되지 않은 속임 혹은 가짜 기능을 제공하기 위해 만들어진 앱은 승인하지 않는다.
2.15   20메가가 넘는 크기의 앱은 무선 네트워크를 통해서 다운로드할 수 없다. (앱스토어에서 자동적으로 이를 방지함)
2.16   멀티태스킹 앱은 백그라운드 서비스를 그것들의 기본적인 목적에 맞게 사용해야한다.
          (예: 인터넷전화, 오디오 플레이백, 지역, 과제수행, 지역 공지 등)
2.17   웹브라우징하는 앱은 IOS WebKit framework와 WebKit Javascript를 반드시 사용해야한다.
2.18   알코올 혹은 법적으로 금지된 물질의 과도한 소비를 조장하거나, 미성년자의 음주 및 흡연을 조장하는 앱은 승인
          하지 않는다.
2.19   잘못된 진단결과 혹은 기타 부정확한 기기 정보를 제공하는 앱은 승인하지 않는다.
2.20   앱스토어에 유사한 앱의 여러가지 버전을 올려서 “스팸질”을 하는 개발자는 iOS 개발자 프로그램에서 퇴출한다.
3. 메타데이터 (이름, 설명, 등급, 순위 등)
3.1     다른 모바일 플랫폼의 이름을 명시한 메타데이터를 포함한 앱은 승인하지 않는다.
3.2     플레이스홀더 텍스트를 포함한 앱은 승인하지 않는다.
3.3     앱 설명에서 앱 컨텐츠, 기능과 상관없는 기술을 한 앱은 승인하지 않는다.
3.4     아이튠스 커넥트 상에 표시되는 앱의 이름과 기기 상에 표시되는 앱의 이름은 서로 비슷해야한다.
          이는 혼란을 피하기 위한 목적이다.
3.5     앱의 큰 아이콘과 작은 아이콘은 혼란을 피하기 위해 서로 비슷해야한다. 
3.6     4세 이상 등급을 지키지 않은 앱 아이콘과 스크린샷을 포함한 앱은 승인하지 않는다.
3.7     앱 컨텐츠에 맞지 않는 카테고리, 장르를 표기한 앱은 승인하지 않는다.
3.8     개발자는 자신의 앱에 적합한 등급을 매길 책임이 있다. 부적합한 등급은 애플이 수정할 수 있다.
3.9     개발자는 자신의 앱에 적합한 키워드를 부여할 책임이 있다. 부적합한 키워드는 애플이 수정하거나 삭제할 수
          있다.
3.10   거짓 리뷰, 돈을 주고 작성한 리뷰, 혹은 기타 부적합한 방법으로 유저 리뷰 혹은 앱스토어 상의 차트 순위를 조작
          하거나 부풀리려는 시도를 한 개발자는 iOS 개발자 프로그램에서 퇴출한다.
4. 지역
4.1     지역 데이터를 수집, 전송, 혹은 사용하기 전에 해당사항에 관해 사용자의 합의를 공지하지 않거나 득하지 않은
          앱은 승인하지 않는다.
4.2     지역 데이터에 근거한 API를 통해 자동차, 비행기 혹은 기타 기기들의 자동, 자주적인 조작을 하고자 하는 앱은
          승인하지 않는다.

4.3     지역 데이터에 근거한 API를 통해 발송, 차량관리, 혹은 긴급 서비스를 하고자 하는 앱은 승인하지 않는다.
5. 알림서비스 (푸쉬 노티피케이션)
5.1     APN(애플 푸쉬 노티피케이션) API를 사용하지 않은 알림서비스를 제공하는 앱은 승인하지 않는다.
5.2     애플로부터 푸쉬 어플리케이션 ID를 득하지 않고 APN 서비스를 사용하는 앱은 승인하지 않는다.
5.3     사용자 합의를 먼저 득하지 않고 알림서비스를 보내는 앱은 승인하지 않는다.
5.4     알림서비스를 통해 민감한 개인정보, 혹은 비밀정보를 보내는 앱은 승인하지 않는다.
5.5     알림서비스를 통해 원하지 않는 메시지를 전하거나, 피싱 혹은 스팸의 목적으로 만들어진 앱은 승인하지 않는다.
5.6     앱의 알림서비스를 이용하여 광고, 프로모션, 혹은 어떠한 직접적 마케팅도 해서는 안된다.
5.7     앱의 알림서비스 사용료를 사용자들로 하여금 부담하게 해서는 안된다.
5.8     알림서비스를 통해 네트워크 용량 혹은 APN 서비스의 대역폭을 과도하게 사용하거나 기기에 지나친 부담을 주는
          앱은 승인하지 않는다.
5.9     바이러스, 파일, 컴퓨터 코드, 혹은 APN 서비스의 정상적인 기동을 방해하거나 손상을 끼치는 프로그램을 전송하는
          앱은 승인하지 않는다.
6. 게임센터
6.1     플레이어 ID를 최종사용자 혹은 제3자에게 보여주는 앱은 승인하지 않는다.
6.2     어떠한 목적으로든 플레이어 ID를 사용하는 앱은 승인하지 않는다. 단, 그것이 게임센터 약관에 근거하였을 경우는
          논외로 한다.
6.3     룩업, 트레이스, 릴레이트, 어소시에이트, 마인, 하베스트 등을 역추적하여 플레이어 ID, 가명 혹은 기타 게임센터를
          통해 얻을 수 있는 정보를 이용하고자 하는 개발자는 iOS 개발자 프로그램에서 퇴출한다.
6.4     순위권 점수 따위의 게임센터 정보는 게임센터의 승인을 받은 앱에서만 사용할 수 있다.
6.5     게임센터 서비스를 통해 원하지 않는 메시지를 전하거나, 피싱 혹은 스팸의 목적으로 만들어진 앱은 승인하지
          않는다.
6.6     게임센터 서비스를 통해 네트워크 용량 혹은 APN 서비스의 대역폭을 과도하게 사용하는 앱은 승인하지 않는다.
6.7     바이러스, 파일, 컴퓨터 코드, 혹은 게임센터 서비스의 정상적인 기동을 방해하거나 손상을 끼치는 프로그램을
          전송하는 앱은 승인하지 않는다.
7. 전자광고
7.1     인위적으로 광고의 시청수나 조회수를 올리고자 하는 앱은 승인하지 않는다.
7.2     아무 내용이 없는 전자광고 배너를 달고 있는 앱은 승인하지 않는다.
7.3     광고를 보여주는 것이 주목적인 앱은 승인하지 않는다.
8. 상표, 상품외장
8.1     개발자들은 애플 상표 및 저작권 사용에 관한 가이드라인과 애플 상표 리스트에 명시된 모든 약관에 근거하여 앱을
          제작해야 한다.
8.2     애플이 앱의 소스나 공급자라고 주장하거나 애플이 앱의 품질이나 기능을 보증한다는 내용을 주장 혹은 암시하는
          앱은 승인하지 않는다.
8.3     애플 제품이나 광고 주제와 혼동할 수 있을 정도로 유사한 앱은 승인하지 않는다.
8.4     앱 이름 상에 애플 제품 이름의 철자를 잘못 적었을 경우 (예, GPS for Iphone, iTuz) 해당 앱은 승인하지 않는다.
8.5     법적으로 보장되는 제3자의 권리(상표, 저작권, 기업비밀, 기타 등록된 컨텐츠)를 사용할 경우 요청 시 서류화된
          사용권을 제출해야한다.
8.6     오리지널 컨텐츠의 기능에 변화가 없고 해당 브랜드에 관해 모든 것을 명확히 확인할 수 있다는 전제 하에서 구글
          맵스 API를 통해 습득한 구글 맵스 및 구글 어스 이미지는 어플리케이션 내에서 사용할 수 있다.
9. 미디어 컨텐츠
9.1     음악 라이브러리에 접속 시 MediaPlayer framework를 사용하지 않는 앱은 승인하지 않는다.
9.2     아이팟 인터페이스를 흉내낸 사용자 인터페이스를 가진 앱은 승인하지 않는다.
9.3     무선 네트워크를 통한 오디오 스트리밍 컨텐츠는 5분 간 5메가 이상 사용하지 않도록 한다.
9.4     무선 네트워크를 통한 비디오 스트리밍 컨텐츠는 10분을 초과하는 경우 HTTP 라이브 스트리밍을 사용해야하며,
          기본 64kbps 오디오만 사용한 HTTP 라이브 스트림을 포함해야한다.
10. 사용자 인터페이스
10.1   모든 앱은 애플 아이폰 Human Interface Guidelines과 애플 아이패드 Human Interface Guidelines에 맞춰 제작해야
          한다.
10.2   앱스토어, 아이튠스스토어, 아이북스토어를 포함한 아이폰 상에 기본으로 제공되는 번들 앱과 유사한 앱은 승인
          하지 않는다.

10.3   애플 아이폰 Human Interface Guidelines과 애플 아이패드 Human Interface Guidelines에 명시된대로 버튼이나
          아이콘 등을 제대로 제공하는 시스템이 없는 앱은 승인하지 않는다.
10.4   변경된 데스크탑/홈 스크린 환경을 만들거나 멀티앱 위젯 환경을 시뮬레이션하는 앱은 승인하지 않는다.
10.5   볼륨 업/다운 및 벨소리/진동 스위치 같은 기본적인 스위치 기능을 변경하는 앱은 승인하지 않는다.
10.6   애플과 애플의 고객들은 심플하고 세련되며 창의적이고 좋은 아이디어에서 나온 인터페이스를 높이 평가한다.
          이러한 인터페이스를 만들기 위해서는 더 많은 노력이 필요하지만, 그럴만한 가치가 있는 일이다.
          인터페이스에 관한 애플의 기준치는 높다.
          만약 당신의 사용자 인터페이스가 복잡하거나 좋지 않을 경우 해당 앱을 승인하지 않을 것이다.
11. 구입, 통화
11.1   락을 풀어서 앱스토어 이외의 메커니즘에서 추가적인 기능을 사용할 수 있도록 하는 앱은 승인하지 않는다.
11.2   앱 상의 구매 API (IAP) 이외의 시스템을 통해 앱 상의 컨텐츠, 기능, 혹은 서비스를 구매할 수 있도록 하는 앱은
          승인하지 않는다.
11.3   IAP를 통해 어플리케이션 외에서 쓰이는 상품이나 서비스를 구입할 수 있도록 하는 앱은 승인하지 않는다.
11.4   IAP를 통해 신용이나 다른 통화를 구입하는 앱의 경우 해당 신용을 어플리케이션 내에서 소비해야한다.
11.5   IAP를 통해 만료된 신용이나 다른 통화를 구입하는 앱은 승인하지 않는다.
11.6   IAP를 통한 컨텐츠 가입은 최소 30일 동안 유지되어야하며, iOS를 사용하는 기기를 가진 모든 사용자들에게 공개
          되어야한다.
11.7   IAP를 통해 물품을 구입하는 앱의 경우 정확한 구입기능이 있어야한다.
11.8   IAP를 통해 카메라나 자이로스코프 따위의 iOS에 내장된 기능에 접속할 수 있는 권한을 구매할 수 있도록 하는 앱은
          승인하지 않는다.
11.9   “렌탈” 컨텐츠나 일정 기간이 지나면 만료되는 서비스를 포함한 앱은 승인하지 않는다.
11.10   보험 어플리케이션은 무료여야하며, 배포되는 지역의 법을 준수해야한다. 또한, 해당 앱은 IAP를 사용할 수 없다.
11.11   전반적으로, 당신이 만든 앱이 비쌀수록 우리는 더 철저하게 리뷰를 할 것이다.
12. 긁어오기, 종합
12.1   애플 사이트(예: apple.com, 아이튠스스토어, 앱스토어, 아이튠스커넥트, 애플 개발자 프로그램 등)로부터 정보를
          긁어오거나 애플 사이트와 서비스의 컨텐츠를 이용해서 순위를 만드는 앱은 승인하지 않는다.
12.2   어플리케이션은 아이튠스스토어 RSS feed 따위의 승인받은 애플 RSS feeds를 사용해야 한다.
12.3   웹상의 자료를 잘라온 것이나 컨텐츠 모음, 혹은 링크모음 따위의 앱은 승인하지 않는다.
13. 기기에 손상
13.1   사용자들로 하여금 애플 기기를 기기를 손상시키는 방향으로 사용하게 유도하는 앱은 승인하지 않는다.
13.2   기기의 배터리를 급격히 소모시키거나 과도한 열을 발생시키는 앱은 승인하지 않는다.
14. 개인적인 공격
14.1   명예훼손, 공격적, 비열한 내용을 포함하거나 혹은 특정인이나 집단에게 해를 끼칠 수 있는 앱은 승인하지 않는다.
14.2   직업적 정치 풍자가나 유머작가는 공격적, 비열한 코멘트로 인한 금지 항목에서 제외한다.
15. 폭력성
15.1   사람이나 짐승이 살해당하는 모습, 불구가 되는 모습, 총에 맞는 모습, 칼에 찔리는 모습, 고문당하거나 다치는
          모습의 실제 이미지를 표현한 앱은 승인하지 않는다.

15.2   폭력이나 아동학대를 묘사한 앱은 승인하지 않는다.
15.3   게임 상의 “적”은 특정인종, 문화, 실존하는 정부나 회사, 혹은 그 어떤 실제적 존재를 단독으로 지목하여 만들어서
          는 안된다.
15.4   무기를 통한 폭력을 현실적으로 보여줘서 무기의 불법적, 난폭한 사용을 독려하는 앱은 승인하지 않는다.
15.5   러시안 룰렛을 포함한 앱은 승인하지 않는다.
16. 거부감을 주는 컨텐츠
16.1   과도하게 거부감을 주거나 상스러운 컨텐츠를 보여주는 앱은 승인하지 않는다.
16.2   주로 사용자를 기분나쁘게 하거나 역겹게 하기 위한 목적으로 제작된 앱은 승인하지 않는다.
17. 사생활
17.1   모든 앱은 사용자 정보 사용에 관해 사전에 사용자의 허락없이, 그리고 사용자로 하여금 해당 정보가 어디서 어떻게
          사용될 것인지에 관해 알려주지 않은 채 사용자 정보를 전송할 수 없다.

17.2   구동을 위해서 이메일 주소나 생년월일 따위의 사용자 개인정보의 공유를 필요로 하는 앱은 승인하지 않는다.
17.3   미성년자를 대상으로 정보수집을 하는 앱은 승인하지 않는다.
18. 포르노그래피
18.1   웹스터 사전에서 정의한 “생식기관의 노골적 묘사, 그리고 미적이나 감성적인 느낌이 아닌 에로틱한 느낌을 유발
          하기 위한 목적의 노골적 행위를 표현한 것”에 해당하는 포르노물을 포함한 앱은 승인하지 않는다.
18.2   수시로 포르노물에 해당하는 내용이 등장하는 사용자 제작 컨텐츠를 포함하는 앱(예: “채트 룰렛” 앱)은 승인하지
          않는다.
19. 종교, 문화, 인종
19.1   특정 종교, 문화, 혹은 인종에 대해 명예훼손, 공격적, 비열한 태도를 취하고 있거나 해당 그룹에게 피해를 끼칠 수
          있는 코멘트 혹은 문헌을 포함한 앱은 승인하지 않는다.
19.2   앱이 종교적인 텍스트를 포함할 경우, 텍스트 상의 멘트나 번역은 정확해야한다. 코멘트는 선동적이라기보다는
          교육적이거나 정보전달 차원에서 그쳐야한다.
20. 컨테스트, 경품, 복권, 추첨
20.1   경품 및 컨테스트는 앱의 개발자/회사가 후원하여 제공해야한다.
20.2   경품 및 컨테스트에 관한 공식적인 룰이 앱 상에 표기되어야하며, 해당 행위에 관해 애플이 관련이 없다는 점을
          명확히 해야한다.

20.3   복권 앱을 만들기 위해서는 개발자가 법적 허가를 득해야하며, 복권 앱은 해당 3가지 특성을 모두 갖추고 있어야
          한다: 배려, 기회, 상금
20.4   사용자로 하여금 직접적으로 복권이나 추첨티켓을 살 수 있도록 하는 앱은 승인하지 않는다.
21. 자선, 기부
21.1   자선단체에 기부할 수 있는 기능을 포함한 앱은 무료여야한다.
21.2   기부금의 모금은 사파리 상의 웹사이트나 SMS를 통해 이뤄져야한다.
22. 법적 요구사항
22.1   앱은 사용자에게 공개되는 지역의 법적 요구사항을 충족시켜야한다. 모든 지역법을 이해하고 따르는 것은 개발자
          들의 의무사항이다.
22.2   허위사실, 사기, 호도된 정보를 포함한 앱은 승인하지 않는다.
22.3   범죄 혹은 난폭한 행위를 요청, 촉진, 장려하는 앱은 승인하지 않는다.
22.4   불법적 파일 공유를 가능케하는 앱은 승인하지 않는다.
22.5   카드 카운터를 포함한 불법적 도박을 조장하기 위해 만들어진 앱은 승인하지 않는다.
22.6   익명 혹은 장난스러운 전화나 SMS/MMS 메시지 전송이 가능한 앱은 승인하지 않는다.
22.7   부정한 방법으로 사용자의 패스워드나 기타 개인정보를 알아내고자 하는 목적으로 앱을 만든 개발자는 iOS 개발자
          프로그램에서 퇴출한다.
이 문서는 지속적으로 업데이트되는 문서임
이 문서는 개발자들이 앱스토어에 제출하는 앱을 우리가 어떻게 리뷰하는지 알려줍니다. 또한 우리는 이 가이드가 당신이 앱을 개발하고 제출하는데에 있어 도움이 될 수 있기를 바랍니다. 이 가이드는 새로운 앱과 상황이 발생함에 따라 지속적으로 업데이트되는 문서이며, 변경사항이 있을 경우 주기적으로 이를 반영할 계획입니다.

iOS의 앱 개발에 참여해주셔서 감사합니다. 비록 이 문서가 당신이 하지 말아야할 것들로 가득하긴 하지만, 그보다 훨씬 짧더라도 당신이 꼭 해야하는 것들의 리스트를 꼭 기억해두시길 바랍니다. 무엇보다도, 사용자들을 놀라게 하고 기쁘게 하는 것에 동참 해주시길 바랍니다. 그들에게 창조적인 길을 보여주고, 이전에는 볼 수 없었던 방법으로 소통할 수 있도록 해주십시오. 우리의 경험에 의하면 사용자들은 기능적으로나 사용자 인터페이스적으로 세련된 것에 적극적으로 반응합니다. 조금 더 노력하셔서 그들에게 그들이 기대하는 이상을 보여주십시오. 그들이 이전까지 본 적이 없는 세계를 보여주시기 바랍니다. 우리는 당신을 도울 준비가 되어있습니다.


출처 Appsnext.com