• iOS单例模式

    2016-07-12 21:54:27
    1 单例模式它是一种设计模式(常见的设计模式有:观察者模式、工厂模式、门面模式等)。单例设计模式中,一个类只有一个实例,只分配一次内存空间,节约内存等,特别适合在移动端使用。 实现单例的思路:1 只能分配...

    1 单例模式

    它是一种设计模式(常见的设计模式有:观察者模式、工厂模式、门面模式等)。单例设计模式中,一个类只有一个实例,只分配一次内存空间,节约内存等,特别适合在移动端使用。

    实现单例的思路:

    1 只能分配一次内存—-要拦截 alloc 方法
    2 alloc 方法的底层是 allocWithZone 方法
    3 每个类只有一个对象,需要有一个全局变量来存储这个对象
    4 需要考虑线程安全

    1.1 单例基本形式(ARC)–懒汉模式

    1.1.1 .h文件

    @interface MusicTool : NSObject
    //给外界快速生成单例对象使用
    +(instancetype)sharedMusicTool;
    @end
    

    1.1.2 .m文件

    @implementation MusicTool
    
    //①定义全局静态变量,用来存储创建好的单例对象,当外界需要时,返回
    static id _instance;
    
    //②实现头文件中的方法
    +(instancetype)sharedMusicTool
    {
        //避免每次线程过来都加锁,首先判断一次,如果为空才会继续加锁并创建对象
        if(_instance == nil)
        {
            //避免出现多个线程同时创建_instance,加锁
            @synchronized(self)
            {   
                //使用懒加载,确保_instance 只创建一次
                if(_instance == nil)
                {   
                    _instance = [[self alloc]init];
                }
            }
        }
        return _instance;
    }
    
    //③重写 allocWithZone:方法---内存与 sharedMusicTool方法体基本相同
    +(instancetype)allocWithZone:(struct NSZone *)zone
    {
        //避免每次线程过来都加锁,首先判断一次,如果为空才会继续加锁并创建对象
        if(_instance == nil)
        {
            //避免出现多个线程同时创建_instance,加锁
            @synchronized(self)
            {   
                //使用懒加载,确保_instance 只创建一次
                if(_instance == nil)
                {   
                    //调用父类方法,分配空间
                    _instance = [super allocWithZone:zone];
                }
            }
        }
        return _instance;
    }
    
    //④重写 copyWithZone:方法,避免实例对象的 copy 操作导致创建新的对象
    -(instancetype)copyWithZone:(NSZone *)zone
    {
        //由于是对象方法,说明可能存在_instance对象,直接返回即可
        return _instance;
    }
    
    @end
    

    1.1.3 代码解释

    (1)为什么全局变量要使用 static?

    ① static修饰局部变量
    * 其生命周期与全局变量相同,直到程序结束,只有一份内存空间
    * 作用域不变
    ② static修饰全局变量
    * 只有一份内存空间
    * 全局变量,在其他文件中,可以通过 extern id _instance来声明,然后直接在其他文件中调用。用 static 修饰后 在其他文件不能通过 extern id _instance 声明后 引用

    (2)加锁且懒加载的原理

    懒加载是为了,确保整个类只有一个_instance,做到单例
    加锁:多线程中,可能多个线程都发现当前的_instance==nil,那么就会同时创建对象,不符合单例的原则,所以加锁。但是加锁容易引起效率降低,不能每次线程过来就加锁,所以在加锁之前首先判断一次是否为空,不为空根本不需要创建,直接返回。为空则说明可能需要创建对象,那么再加锁。

    1.2 GCD简化单例(ARC)

    在allocWithZone方法和 sharedSoundTool中,每次需要判断是否为空,然后加锁,其目的是为了保证 [[self alloc]init]和[super allocWithZone:zone]代码只执行一次,那么可以使用 GCD 的一次性代码解决,另外,GCD 一次性代码是线程安全的,所以不需要我们自己来处理加锁问题。

    //修改 sharedSoundTool 方法
    +(instancetype)sharedSoundTool
    {
        dispatch_once_t onceToken = NULL;
        dispatch_once(&onceToken)
        {
            _instance = [[self alloc]init];
        }
        return _instance;
    }
    
    //修改 allocWithZone 方法
    +(instancetype)allocWithZone:(struct NSZone *)zone
    {
        dispatch_once_t onceToken = NULL;
        dispatch_once(&onceToken)
        {
            _instance = [super allocWithZone:zone];
        }
        return _instance;
    }
    

    1.3 GCD 简化单例(MRC)

    在 MRC 环境中,我们需要考虑如果创建出来的单例对象,被手动 release 了怎么办?所以我们在设计单例模式的时候,需要考虑这种情况。如下:
    * retain,单例对象创建后,全局只有一个对象,所以一定要保证 retain 后仍然是自身,且引用计数不变
    * release,由于只有一个对象,被 release 后不能被释放掉,所以 release 操作需要拦截
    * autorelease,与 release 一样
    * retainCount,始终保证引用计数器为1
    所以在 MRC 环境中,设计单例模式时,还需要重写下面四个方法

    //重写 retain 方法,不作计数器加1的操作
    -(instancetype)retain
    {
        return _instance;
    }
    
    //重写 release 方法,不做任何操作
    -(void)release
    {
    
    }
    
    //重写 autorelease 方法,返回自身
    -(instancetype)autorelease
    {
        return _instance;
    }
    
    //重写 retainCount 方法,返回1
    -(NSUInteger)retainCount
    {
        return 1;
    }
    

    1.4 饿汉模式的单例(不常用)

    单例通常被分为两种模式:懒汉模式和饿汉模式。

    懒汉模式

    当使用这个单例对象的时候,才创建对象,就是_instance 的懒加载形式。由于移动设备内存有限,所以这种方式最适合。

    饿汉模式

    当类第一次加载的时候,就创建单例对象,并保存在_instance 中。由于第一次加载就创建,内存从程序开始运行的时候就分配了,不适合移动设备。

    load和initilized 方法

    load方法

    ①当程序刚开始运行的时候,所有的类都会加载到内存中(不管这个类有没有使用),此时就会调用 load 方法            
    ②如果某种操作想要在程序运行的过程中只执行一次,那么这个操作就可以放到 load 方法中
    ③基于第二点,我们的饿汉模式的单例对象创建就放在 load 方法中
    

    initialized方法

    ①当类第一次被使用的时候调用(比如,调用类的方法)。
    ②如果子类没有重写该方法,那么父类的initialized方法可能会被执行多次。所以饿汉模式不能使用这个方法
    
    .h文件
    @interface SoundTool():NSObejct
    //提供外界访问的方法
    +(instancetype)sharedSoundTool;
    @end
    
    .m文件
    @implementation SoundTool
    //①定义静态全局变量
    static id _instance;
    //②实现方法
    +(instancetype)sharedSoundTool
    {
        return _instance;
    }
    //③重写load方法
    +(void)load
    {
        //不需要线程安全,类加载的时候线程还没开始呢
        _instance = [[self alloc]init];
    }
    //④重写allocWithZone方法
    +(instancetype)allocWithZone:(struct _NSZone *)zone
    {
        if(_instance == nil)
        {
            _instance = [super allocWithZone:zone];
        }
        return _instance;
    }
    
    @end
    

    1.5 ARC和MRC的适配

    上面的单例的设计,分为ARC和MRC环境。MRC较ARC多了关于retain、release相关的代码。为了能够用同一份代码适配不同的环境,我们可以是用条件编译指令。

    #if __has_feature(objc_arc)
    //ARC编译环境
    
    #else
    //MRC编译环境
    
    -(instancetype)retain{return _instance;}
    -(void)release{}
    -(instancetype)autorelease{return _instance;}
    -(NSUIngeter)retainCount{return 1;}
    
    #endif
    

    1.6 宏实现单例

    由于单例的h文件和m文件一成不变,所以可以抽成宏定义。抽成宏定义需要注意
    1 宏定义后面如果要替换字符,需要用##拼接

    #define SoundToolH(name) +(instancetype)shared##name;
    //调用宏定义SoundToolH(MusicTool)时,就相当于
    +(instancetype)sharedMusicTool;
    

    2 宏定义后边如果出现换行,需要用符号“ \ ” 来标记下一行也是宏定义的部分,但最后一行末尾不需要

    #define SoundToolM(name) \
    static id _instance;\
     +(instancetype)shared##name\
     {\
        dispatch_once_t onceToken = NULL;\
        dispatch_once(&onceToken)\
        {\
            _instance = [self alloc]init];\
        }\
     }
    
    展开全文
  • [iOS]App Store审核指南

    2019-11-04 17:29:41
    App Store审核指南 ...最后更新日期:2019 年 9 月 12 日 App 正在改变世界,丰富人们的生活,并为像您一样的开发者提供前所未有的创新机会。因此,App Store 已成长为一个激动人心且充满活力的生态系统,正为数百万的...

    App Store审核指南

    https://developer.apple.com/cn/app-store/review/guidelines/
    最后更新日期:2019 年 9 月 12 日

    App 正在改变世界,丰富人们的生活,并为像您一样的开发者提供前所未有的创新机会。因此,App Store 已成长为一个激动人心且充满活力的生态系统,正为数百万的开发者和超过十亿的用户提供服务。不管是开发新手,还是由经验丰富的程序员所组成的大型团队,我们都非常欢迎您为 App Store 开发 app,并希望能够帮助您了解我们的准则,以确保您的 app 能够快速通过审核流程。

    在提交 app 之前,请务必熟悉《App Store 审核指南》中列出的审核人员审核 app 时所依据的技术、内容和设计标准。

    目录

    简介

    提交之前

    开发指南

    设计指南

    品牌和营销指南

    1. 安全

    1.1 令人反感的内容

    1.2 用户生成的内容

    1.3 儿童类别

    1.4 人身伤害

    1.5 开发者信息

    1.6 数据安全

    2. 性能

    2.1 App 完成度

    2.2 Beta 测试

    2.3 准确的元数据

    2.4 硬件兼容性

    2.5 软件要求

    3. 商务

    3.1 付款

    3.1.1 App 内购买项目:

    3.1.2 订阅:

    3.1.2(a) 允许的用途:

    3.1.2(b) 升级和降级:

    3.1.2(c) 订阅信息:

    3.1.3(a)“阅读器”App:

    3.1.3(b) 多平台服务:

    3.1.4 硬件相关内容:

    3.1.5 (a) App 之外的商品和服务:

    3.1.5 (b) 加密货币:

    3.1.6 Apple Pay:

    3.1.7 广告:

    3.2 其他业务模式问题

    3.2.1 可以接受

    3.2.2 不可接受

    4. 设计

    4.1 抄袭者

    4.2 最低功能要求

    4.3 重复 App

    4.4 扩展

    4.5 Apple 站点和服务

    4.6 备选 App 图标

    4.7 HTML5 游戏与聊天机器人 (Bot) 等

    4.8 通过 Apple 登录

    5.1 隐私

    5.1.1 数据收集和存储

    5.1.2 数据使用和共享

    5.1.3 健康和健康研究

    5.1.4 儿童

    5.1.5 定位服务

    5.2 知识产权

    5.3 游戏、赌博和彩票

    5.4 VPN App

    5.5 移动设备管理

    5.6 开发者行为准则

    提交之后


    简介

    App Store 的指导原则非常简单 - 我们希望为用户获取 app 时提供更安全可靠的体验,并为所有开发者提供借助 app 获得成功的契机。为此,我们精心打造了 App Store,其中的每个 app 都会经过专家审核,而且还有编辑团队每天帮助广大用户发现新的 app。至于别的一切,可以考虑在开放的互联网上分享。如果 App Store 模式和准则与您的 app 或经营理念不能完美契合,那也没关系,我们的 Safari 浏览器也能提供出色的 Web 体验。

    在以下页面中,您会发现我们已把最新的准则清晰地划分为五个部分:安全、性能、业务、设计及法律。App Store 一直在不断变化和改善,紧跟我们客户和产品的需求。您的 app 也需要做出改变与改进,才能留在 App Store 上。

    另外,请将以下几点谨记在心:

    • 很多儿童会从我们这里大量下载各种 app。尽管家长控制功能能为儿童提供有效保护,但您也必须做好自己份内的工作。因此,您要知道,我们时刻都在关注这些儿童。
    • App Store 是向全球数亿人分享 app 的好方法。如果您开发 app 只是为了分发给亲朋好友,那么 App Store 并不是最适合的途径。这时可考虑使用 Xcode 将 app 免费安装到设备上,或者使用面向 Apple Developer Program 会员推出的 Ad Hoc 分发。如果您刚开始开发 app,请进一步了解 Apple Developer Program
    • 在 App Store 上发布的所有观点,我们都非常支持 — 只要这些 app 尊重用户的不同意见,并能带来良好的 app 体验。如果我们认为 app 的任何内容或行为超出了可接受的范围,我们将拒绝该 App。您可能会问,这个可接受的范围是什么?套用最高法院大法官的一句话:“当我看到的时候,我就知道了”。而且,我们相信,当您超出这个范围时,您自己也会意识到。
    • 如果您试图欺骗系统 (例如,试图在审核流程中弄虚作假,窃取用户数据,抄袭其他开发者的作品,操纵评分或 App Store 上的发现方法),我们会从商店中移除您的 app,并将您从 Developer Program 中除名。
    • 您要确保 app 中所含内容全部符合这些准则的要求,包括广告网络、分析服务和第三方 SDK 等;因此,在审核和选择这些内容时务必要慎重。
    • 某些一般不提供给开发者的功能和技术可能会以授权的形式提供,供开发者在受限情况中使用。例如,我们提供 CarPlay 车载音频、HyperVisor 和特权文件操作的授权。请查看 developer.apple.com 上的文档,进一步了解各种授权。

    我们希望这些准则能帮助您顺利通过 App Review 流程,并使批准和拒绝标准在整体上更加一致。本文是一个动态文稿;如果新的 app 引发了新的问题,我们可能会随时制定新的规则。也许,您的 app 就将促成新的规则。我们同样热爱 app 开发,并且尊重您所做的一切。我们正竭尽全力为您营造世界上最优秀的平台,既能让您展示才华,还能让您获得回报。

    提交之前

    为了帮助您尽可能顺利地通过 app 审批,请查看下方列出的常见错误行为,这些行为可能会导致审核流程延误或导致 app 被拒。这些内容不能代替准则或保证 app 获批,但确保核对这个列表中的每一项会是一个良好的开始。如果您的 app 无法再按预期方式工作,或者您不再积极地对其提供支持,那么这个 app 将从 App Store 中移除。进一步了解 App Store 所做的改善

    请确保:

    • 测试 app 是否会发生崩溃、是否存在错误
    • 确保所有 app 信息及元数据完整且正确
    • 更新您的联系信息,以便 App Review 部门在需要时与您取得联系
    • 提供有效的演示帐户和登录信息,以及审核 app 时所需的任何其他硬件或资源 (例如,登录凭证或示例二维码)
    • 启用后台服务,以使其在审核期间处于活动和可用状态
    • 在 App Review 备注中附上与非明显功能及 App 内购买项目相关的详细说明,包括支持文稿 (如适用)。
    • 检查 app 是否遵循了其他文稿中的相关指南,如:

    开发指南

    设计指南

    品牌和营销指南

    1. 安全

    当用户通过 App Store 安装 app 时,他们希望获得安全的体验:app 不含令人不快或具有攻击性的内容,不会损坏用户的设备,不会在使用中造成人身伤害。我们在下方列出了主要的安全隐患。如果您想恐吓、攻击他人,则您的 app 不适合出现在 App Store 中。

    • 1.1 令人反感的内容

      App 不应包含具有攻击性、不顾及他人感受、令人不安、惹人厌恶、低俗不堪或只是让人感到毛骨悚然的内容。此类内容的示例有:

      • 1.1.1 诽谤、歧视或恶意的内容,包括有关宗教、种族、性取向、性别、国籍、种族起源或其他目标群体的引用或评论,特别是当 app 很可能对特定的个人或团体进行羞辱、恐吓、或造成伤害时。通常情况下,专业政治讽刺和政治幽默作家不受此要求限制。
      • 1.1.2 人类或动物遭到杀害、残害、酷刑、虐待的写实描绘,或者鼓励暴力的内容。在游戏中,“敌人”不能单单针对特定种族、文化、真实存在的政府或企业,或是任何其他真实存在的实体。
      • 1.1.3 鼓励非法使用或不负责任地使用武器和危险物品的描述,或者促进军火或弹药购买的描述。
      • 1.1.4 过于色情的内容 (韦氏词典对“色情”一词的定义是:对性器官或性活动的露骨描述或展示,目的在于刺激性快感,而非带来美学价值或触发情感)。
      • 1.1.5 具有煽动性的宗教评论,或者对宗教文本进行错误或误导性的引用。
      • 1.1.6 虚假信息和功能,其中包括不准确的设备数据或用于恶作剧/开玩笑的功能,如虚假的位置跟踪器。即使指明 app“仅供娱乐”,也不能违背这一准则。支持匿名或恶作剧电话或短信/彩信的 app 会被拒绝。
      • 1.1.7 App Store 评论:
        • App Store 客户评论是 app 体验中不可或缺的一部分;因此,在回复客户的评论时,您应当对他们保持尊重。另外,您的回复应直接回应客户评论的主题,请勿在回复中包含个人信息、垃圾信息或营销广告。
        • 利用我们提供的 API 提示用户评价您的 app:通过这项便利功能,客户无需离开 app,就可直接在 App Store 中留下评分和评论;不允许使用预定的评论提示。
    • 1.2 用户生成的内容

      对于包含用户生成内容的 App,有特定的难题需要解决,比如知识产权侵权、匿名欺凌等。为了避免滥用,包含用户生成内容或社交网络服务的 app 必须满足以下条件:

      • 采用相应的方法来过滤令人反感的内容,以免这些内容在 app 中发布
      • 制定一个机制,以举报攻击性内容并在出现问题时及时作出回应
      • 若用户发布攻击性内容,可以取消其使用服务的资格
      • 公布联系信息,以便用户与您联系

      如果 App 中所含的用户生成内容或服务最终主要用于色情内容、客观化现实生活中的某人(如“性感与否”投票)、进行人身威胁或欺凌,则这些 App 不适合出现在 App Store 中,它们可能会在未经通知的情况下被移除。如果应用中所含的用户生成内容来自于基于 Web 的服务,则可显示意外产生的“NSFW(公众场所不宜)”内容,前提是这些内容是默认隐藏的,只有当用户通过您的网站打开时才会显示。

    • 1.3 儿童类别

      “儿童类别”可帮助用户轻松找到专为儿童设计的 app。如果您希望参与“儿童类别”,则应该致力于为年纪较小的用户量身打造卓越的使用体验。这些 app 不得提供 app 外链接、购买机会或其他会对儿童造成干扰的内容,除非其保留在受家长监控的指定区域中。请谨记,一旦客户认为您的 app 能够满足“儿童类别”要求,您的 app 就需要一直满足后续更新中的相应准则;即使您决定取消选择此类别,也是如此。进一步了解家长监控

      您必须遵守世界各地与在线收集儿童数据相关的适用隐私法。请务必查阅本指南的“隐私”部分,以了解更多信息。此外,“儿童”类别的 app 不得向第三方发送个人身份识别信息或设备信息。“儿童”类别中的 app 不应包含第三方数据分析或第三方广告。这些做法可为儿童提供更安全的体验。在少数情况下,可能允许包含第三方数据分析,前提是相关服务不会收集或传输 IDFA 或关于儿童的任何身份识别信息 (如姓名、出生日期、电子邮件地址)、儿童所在位置或其设备。这包括任何设备、网络或其他可直接用来或结合其他信息来识别用户及其设备的信息。在少数情况下,也可能允许包含与页面内容相关的第三方广告,前提是该服务拥有适合“儿童”类别 app 的公开备案做法和政策,包括人工审核广告创意以确保适合相应年龄段。

    • 1.4 人身伤害

      如果 app 的行为方式可能会造成人身伤害,我们可能会拒绝该 app。例如:

      • 1.4.1 如果医疗 app 可能会提供错误的数据或信息,或用于诊断或治疗病患,则这些 app 可能会面临更加严格的审核。
        • App 必须清楚地披露相关数据和方法,用于佐证声明的健康测量准确度,如果准确度或方法得不到验证,我们会拒绝该 app。例如,如果 app 声称仅通过设备上的传感器就能照 X 光、测血压、测体温、测血糖浓度或测血氧含量,则这个 app 会被拒绝。
        • App 应当提醒用户,除了使用该 app,还应咨询医生的意见,然后才能做出医疗决定。
        如果您的医疗 app 已经获得监管部门的批准,请随 app 提交相关文稿的链接。
      • 1.4.2 药物剂量计算器必须来自药品生产企业、医院、大学、健康保险公司、药店或经过 FDA 或其相应国际部门的批准的其他实体。由于可能会对病患造成伤害,我们需要确保 app 将在长时间内获得支持,并保持更新。
      • 1.4.3 App Store 中不允许分发任何鼓励消费烟草及电子烟产品、使用违禁药物或摄入过量酒精的 app。鼓励未成年人摄入任何上述物品的 app 都会被拒绝。为大麻、烟草或管制物品的销售提供便利 (经授权的药店除外) 同样不被允许。
      • 1.4.4 App 只能显示由相关执法部门公布的酒后驾车检查点,不得鼓励酒后驾车和包括超速在内的其他鲁莽行为。
      • 1.4.5 App 不得促使客户参与赌博或挑战等活动,或以可能对自己或他人造成人身伤害的方式来使用他们的设备。
    • 1.5 开发者信息

      用户需要知道如何就疑问和支持问题与您取得联系。确保您的 app 及其支持 URL 中包含能轻松联系到您的联系信息;对于可能会在课堂中使用的 app 而言,这一点尤为重要。如果未能提供准确的最新联系信息,不但会让客户有不好的感受,可能还会违反某些国家/地区的法律。另外,请确保在钱包凭证中包含发卡机构的有效联系方式,以及分配给凭证的品牌或商标所有者的专用证书。

    • 1.6 数据安全

      App 应实施适当的安全举措,确保按照“Apple Developer Program 许可协议”和这些准则 (更多信息见“准则 5.1”) 妥善处理收集到的用户信息,防止对这些信息进行未经授权使用、披露或者被第三方访问。

    2. 性能

    • 2.1 App 完成度

      提交至 App Review 的申请 (包括可供预订的 app) 应为该 app 的最终版本,并应包含所有必要的元数据和有效网址。所有占位符文本、空白网站和其他临时内容应在提交前移除。在提交 app 之前,请务必在设备上对 app 的错误和稳定性进行测试;如果您的 app 需要登录,请提供演示帐户信息 (并打开您的后台服务!)。如果您在 app 中提供了 App 内购买项目,请确保审核人员能够看到这些内容,并确保这些内容处于完整且最新的状态,否则请在审核备注中说明相关原因。请不要将 App Review 视作软件测试服务。我们将拒绝不完整的 app 套装以及会出现崩溃或存在明显技术问题的二进制文件。

    • 2.2 Beta 测试

      App 的演示版、Beta 版和试用版不适合出现在 App Store 中 - 请使用 TestFlight。所有通过 TestFlight 提交以进行测试发布的 App 都应旨在公开发布,并应遵循“App Review 准则”。请注意,使用 TestFlight 的 app 不得分发给测试者用以换取任何类型的报酬,包括作为众筹资金的奖励。对于 beta 版 app 的大幅更新应先提交至 TestFlight App Review 团队,然后再分发给您的测试者。欲了解更多信息,请访问“TestFlight Beta 测试”。

    • 2.3 准确的元数据

      客户应该知道他们在下载或购买您的 app 时会得到什么,所以请确保 app 的描述、屏幕快照和预览能够准确反映 app 的核心体验,并记得不断更新,以便保持与新版本相应的最新状态。

      • 2.3.1 请勿在 app 中包含未记录的功能或隐藏功能;不管是对于最终用户还是 App Review 团队,app 功能都应清晰可见。同样,您不应该在 App Store 或离线情况下,营销您的 app 中实际并不提供的内容或服务 (例如基于 iOS 的病毒和恶意软件扫描工具)。如果出现恶劣或屡教不改的行为,则可能会从 Apple Developer Program 中除名。我们正努力将 App Store 打造成值得信赖的生态系统,并希望我们的 App 开发者也能如此;如果您不诚实以待,我们之间就不会有任何业务往来。
      • 2.3.2 如果您的应用包含 App 内购买项目,请确保应用的描述、屏幕快照和预览清楚地指明是否有需要另行购买的精选项目、关卡和订阅等。如果您决定在 App Store 中推广 App 内购买项目,请确保 App 内购买项目的显示名称、屏幕快照和描述适合所有公众,并遵循“推广您的 App 内购买项目”中的准则;此外,您的 app 也应正确使用 SKPaymentTransactionObserver 方法 (英文),以便客户可以在 app 内无缝完成购买。
      • 2.3.3 屏幕快照应展示 app 的使用情况,而非仅显示标题封面、登录页面或初始屏幕。屏幕快照还可以包括文本及图像说明 (例如:演示输入机制,如触控点或 Apple Pencil 的动画),并展示设备上的扩展功能,如触控栏。
      • 2.3.4 预览是让客户了解 app 外观和功能的好方法。为了确保客户理解他们将在 app 中获得的体验,预览只可使用从 app 中采集的视频屏幕。Stickers 和 iMessage 信息扩展可以将用户体验展示在“信息”app 中。您也可以添加旁白和视频,或添加文本说明,以帮助说明任何无法仅通过视频进行阐明的内容。
      • 2.3.5 请为 app 选择最适合的类别,并在需要帮助时参考“App Store 类别定义”。如果选择的类别与实际情况相差较远,我们可能会更改 app 的类别。
      • 2.3.6 请在 App Store Connect 中诚实地回答年龄分级问题,以便让 app 与家长控制功能的分级保持一致。如果 app 分级有误,客户在获得 app 时可能会感到诧异,或促使政府监管部门展开相应调查。如果 app 所含的媒体内容要求显示内容分级或警告 (如电影、音乐和游戏等),则需在销售 app 的每个地区内遵循当地要求。
      • 2.3.7 请选择一个独一无二的 app 名称,指定能够准确描述 app 的关键词,不要试图用商标术语、流行 app 的名称或其他不相关的短语来包装任何元数据,以此欺骗系统。App 名称必须限制在 30 个字符以内,且不得包含不属于 app 名称的价格、词语或描述。App 副标题是详细介绍 app 背景信息的绝佳之处。副标题必须遵循我们的标准元数据规则,且不得包含不当内容、提及其他 app 或做出无法证实的产品声明。Apple 可以随时修改不合适的关键字或采取其他相应步骤,以防止不当使用。
      • 2.3.8 元数据应适合所有受众,所以请确保您的 app 和 App 内购买项目的相关图标、屏幕快照和预览保持在 4+ 年龄分级;即使您的 app 分级更高,也应如此。例如,如果您的 app 是包含暴力的游戏,请勿选择包含惨烈的死亡或用枪瞄准特定角色的图像。只有“儿童类别”的 app 才能在元数据中使用类似“适合幼儿”和“适合儿童”等词语。请务必确保包括 app 名称和图标 (小图标、大图标、Apple Watch app 和备用图标等) 在内的元数据彼此相似,以免引起困惑。
      • 2.3.9 您应负责确保有权使用 app 图标、屏幕快照和预览中的所有材料,并应显示虚构的帐户信息,而非真实个人的数据。
      • 2.3.10 请确保您的 app 注重 iOS、Mac、Apple TV 或 Apple Watch 体验,并且不在 app 或元数据中包含其他移动平台的名称、图标或图像,除非存在已获批的特定互动功能。确保您的 app 元数据注重 app 本身及其体验。不要包含无关的信息,包括但不限于关于 Apple 或开发流程的信息。
      • 2.3.11 您提交至 App Store 可供预订的 app 必须为完整且可发布的状态。请确保您最终发布的 app 与其可供预订状态时所宣传的内容没有实质性差异。如果您对该 app 进行了重大更改 (例如更改其商业模式),则应重新开始其预订销售。
      • 2.3.12 App 必须在其“新功能”文本中清楚地描述新功能和产品更改情况。一些简单的错误修复、安全更新和性能改进可以通过一般描述来说明,但较为重大的更改必须列明在备注中。
    • 2.4 硬件兼容性

      • 2.4.1 为了确保用户能够充分利用您的 app,iPhone app 应尽量能在 iPad 上运行。我们鼓励您考虑开发通用 app,这样客户就可以在所有设备上加以使用。进一步了解 通用 app (英文)
      • 2.4.2 通过设计,让您的 app 节省能耗,且其使用方式不会带来设备损坏的风险。App 不应快速耗尽电池电能、产生过多的热量或对设备资源造成不必要的负担。例如,app 不得鼓励在充电期间将设备置于床垫或枕头下,或对固态硬盘进行过多的写入循环操作。App 及其中显示的任何第三方广告均不可运行无关的后台进程,如加密货币挖矿。
      • 2.4.3 对于 Apple TV app,应确保用户无需使用除 Siri Remote 或第三方游戏控制器之外的硬件输入,但您可以随意提供增强功能供连接其他外围设备时使用。如果需要用户配备游戏控制器,请务必在元数据中清晰说明,以便用户知晓他们需要额外的设备才能玩游戏。
      • 2.4.4 App 不得建议或要求重新启动设备,或者修改与 app 核心功能无关的系统设置。例如,请勿鼓励用户关闭 Wi-Fi 或停用安全功能等。
      • 2.4.5 对于通过 Mac App Store 分发的 app,还有几个额外要求需要您留意:
        • (i) 这些 app 必须妥当地沙箱化,并遵循“macOS 文件系统文档 (英文)”。另外,这些 app 只应使用相应的 macOS API 来修改其他 app 存储的用户数据 (如书签、“地址簿”或“日历”条目)。
        • (ii) 这些 app 必须使用 Xcode 中提供的技术来进行打包和提交;不允许使用第三方安装器。另外,这些 app 必须是单个的自包含 app 安装包,不能将代码或资源安装在共享位置。
        • (iii) 这些 app 不得自动启动或者在启动时包含其他自动运行的代码,不得在未经同意的情况下登录,也不得大量生成在用户退出 app 后仍在未经同意的情况下继续运行的进程。这些 app 不得将图标自动添加到程序坞中,或在用户桌面上留下快捷方式。
        • (iv) 这些 app 不得下载或安装独立的 app、kext、额外代码或资源,以向我们在审核过程中看到的 app 添加功能,或进行大幅更改。
        • (v) 这些 app 不得申请升级至 root 特权或使用 setuid 属性。
        • (vi) 这些 app 不得在启动时显示许可证屏幕、需要使用许可证密匙或实施自己的拷贝保护措施。
        • (vii) 这些 app 必须使用 Mac App Store 分发更新;不允许使用其他更新机制。
        • (viii) 这些 app 应在当前发布的 OS 上运行,不得使用已停用或选装的技术 (如 Java、Rosetta)。
        • (ix) 这些 app 必须在单个 app 套装内包含所有的语言和本地化支持。
    • 2.5 软件要求

      • 2.5.1 App 仅可使用公共 API,并且必须在当前发布的 OS 上运行。进一步了解已发布 APIs (英文)。及时更新您的 app,在未来的操作系统版本中不再支持的任何过时功能、框架或技术皆应被淘汰。App 使用的 API 和框架应该是为了实现预期用途,并在 app 描述中说明集成详情。例如,HomeKit 框架应提供家居自动化服务,HealthKit 则应该用于保持健康和健身目的,并集成在“健康”app 中。
      • 2.5.2 App 应自包含在自己的套装中,不得在指定容器范围外读取或写入数据,也不得下载、安装或执行会引入或更改 app 特性或功能的代码,包括其他 app。仅在特殊情况下,用于教授、开发或允许学生测试可执行代码的教育类 app 可以下载所提供的代码,但这类代码不得用于其他用途。这类 app 必须开放 app 提供的源代码,让客户可以完全查看和编辑这些源代码。
      • 2.5.3 如果 app 传输的病毒、文件、计算机代码或程序会对操作系统和/或硬件功能 (包括推送通知和 Game Center) 的正常运行造成负面影响或导致其中断,则该 app 会被拒绝。屡教不改或恶劣的违规行为会导致开发者从 Apple Developer Program 中被除名。
      • 2.5.4 多任务处理 app 只允许在实现预期用途时使用后台服务:VoIP、音频播放、地理位置、任务完成记录和本地通知等。如果应用使用定位后台模式,请提醒用户,这么做会大幅降低电池续航能力。
      • 2.5.5 App 必须能够在仅支持 IPv6 的网络上完全正常地运作。
      • 2.5.6 如果 app 会浏览网页,则必须使用相应的 WebKit 框架和 WebKit Javascript。
      • 2.5.7 基于蜂窝移动网络且超过 10 分钟的视频流内容必须使用 HTTP 实时流化,并包含一个 192 kbps 为底线的 HTTP 实时流化。
      • 2.5.8 如果 app 会创建替代的桌面/主屏幕环境,或者模拟多 app 插件体验,则该 app 会遭到拒绝。
      • 2.5.9 如果 app 会改变或停用标准开关 (如调高/调低音量和铃声/静音开关) 的功能,或者改变或停用其他的原生用户界面元素或行为,则该 app 会遭到拒绝。例如,app 不应屏蔽转向其他 app 的链接,或用户希望以某种特定方式运行的功能。进一步了解如何正确处理链接
      • 2.5.10 不得提交包含空白广告横幅或测试广告的 app。
      • 2.5.11 SiriKit 和快捷方式
        • (i) 集成 SiriKit 和快捷方式的 app 只能登记无需其他 app 支持便可处理的意图,而且这个意图应当与用户对所述功能的预期相符。例如,如果您的 app 属于膳食计划 app,则不应融入开始体能训练的意图,即使这个 app 共享了与健身 app 的集成也不可以。
        • (ii) 确保 plist 中的词汇和短语与您的 app 及它所登记意图的 Siri 功能相符。别名必须与您的 app 或公司名称直接相关,不得使用通用术语或者包含第三方 app 名称或服务。
        • (iii) 以最直接的方式解析 Siri 请求或快捷方式,不要在请求与实现之间插入任何广告或其他市场营销信息。只有在完成相关任务需要时 (例如让用户指定特定类型的体能训练时),才可以要求解疑。
      • 2.5.12 利用 CallKit 或包含 SMS Fraud 扩展的 app 应该只拦截已确认用于发送垃圾信息的电话号码。具有通话、短信或彩信拦截功能或垃圾信息识别功能的 app 必须在营销文本中清楚标识这些功能,并且说明归入拦截列表和垃圾信息列表的标准。通过这些工具获得的数据不得用于与运行或改进您的 app 或扩展没有直接关联的任何其他目的 (例如,不得出于跟踪或创建用户资料等目的来使用、共享或销售这些数据)。。
      • 2.5.13 若有可能,使用人脸识别进行帐户验证的 app 必须使用 LocalAuthentication (英文) (而非 ARKit 或其他人脸识别技术),且必须对未满 13 岁的用户使用备用身份验证方式。
      • 2.5.14 在录像、记录日志或以其他方式记录用户活动时,app 必须征得用户的明确同意,而且要提供清晰的视觉和/或听觉指示。这亦包括任何对设备摄像头、麦克风、屏幕录像或其他用户输入方式的使用。
      • 2.5.15 能够让用户查看和选择文件的 app 应包含“文件”app 中的项目和用户的 iCloud 文稿。

    3. 商务

    在 App Store 中,您可以通过多种方式让自己的 App 实现盈利。如果您的业务模式并不显而易见,请务必在其元数据和 App Review 备注中加以说明。如果我们无法理解 app 的工作方式,或者 App 内购买项目不是那么一目了然,则审核会有所延误,并可能会导致 app 被拒绝。尽管价格由您决定,但是我们不会分发要价明显过高的 app 和 App 内购买项目。对于试图以不合常理的高昂价格欺骗用户的 app,我们将予以拒绝。

    如果我们发现您试图操纵评价,通过付费、提供奖励、经过筛选或伪造的反馈来提高排名,或者要求第三方服务代您这样做,我们将采取相应措施以保持 App Store 的公正性,其中可能包括将您从 Apple Developer Program 中除名。

    • 3.1 付款

      • 3.1.1 App 内购买项目:

        • 如果您想要在 app 内解锁特性或功能 (解锁方式有:订阅、游戏内货币、游戏关卡、优质内容的访问权限或解锁完整版等),则必须使用 App 内购买项目。App 不得使用自身机制来解锁内容或功能,如许可证密钥、增强现实标记、二维码等。App 及对应元数据不得包含指引客户使用非 App 内购买项目机制进行购买的按钮、外部链接或其他行动号召用语。
        • App 可以提供 App 内购买货币,供客户在 app 内“打赏”数字内容提供商。
        • 通过 App 内购买项目购买的所有点数和游戏货币不得过期,并且您应确保为所有可恢复的 App 内购买项目设计一套恢复机制。
        • 请务必指定正确的可购买类型,否则您的 app 将被拒绝。
        • App 可以允许用户将符合 App 内购买项目条件的物品赠予他人。此类礼品只能退款给原始购买者,而且不可交货。
        • 通过 Mac App Store 分发的 app 可托管基于非 App Store 机制的插件或扩展。
        • 提供“战利品箱”或其他随机虚拟物品购买机制的 app 必须在客户购买前,向客户披露每种类型物品的获取几率。
        • 非订阅型 app 在提供完整解锁选项前可以提供按时间计算的免费试用期,方法是在“价格等级 0”中设置非消耗型 IAP 项目,并按照命名约定“XX 天试用”来命名。在开始试用之前,app 必须清楚指明试用期时长、试用期结束后不再能访问的内容或服务,以及用户为获得完整功能而需要支付的任何后续费用。进一步了解如何使用收据 (英文)设备检查 (英文) 来管理内容访问权限和试用期时长。
      • 3.1.2 订阅:

        • 无论属于 App Store 上哪一类别,app 都可以提供自动续订的 App 内购买订阅。在 app 内集成可自动续订的订阅时,请务必遵循下述指导原则。
      • 3.1.2(a) 允许的用途:

        • 如果您提供自动续订订阅,则必须为客户提供持续的价值,订阅期必须持续至少七天,并且能够在用户的所有设备上访问。以下并非详尽列表,适当的订阅示例包括:新游戏关卡;连载内容;多玩家支持;持续提供实质性更新的 app;对媒体内容的大型合集或持续更新的访问权限;软件即服务 (SAAS);以及云服务支持。此外:
          • 订阅可与单点式服务一起提供。例如,您可以提供整个影片库的订阅,以及单部影片购买或租赁。
          • 您可以在您的多个 app 和服务中提供跨 app 的订阅项目,但这些订阅不可扩展到第三方的 app 或服务。游戏订阅中提供的游戏必须由该开发者拥有或已受独家许可 (例如:非属于游戏发布平台的一部分)。所有游戏都必须直接从 App Store 下载。游戏须避免订阅用户的重复支付,且不应损害非订阅用户的利益。
          • 订阅必须适用于可使用该 app 的所有用户设备。进一步了解在您的多个 app 之间共享订阅项目 (英文)
          • App 不得强制要求用户为 app 评级或点评、下载其他 app,或执行其他类似操作,然后才能访问该 app 的功能、内容或者使用该 app。
          • 与所有 app 一样,此类服务订阅应当允许用户直接获得付费购买的项目而无需执行额外任务,如在社交媒体上发帖、上传通讯录,以及在 app 内签到特定次数等。
          • 订阅可以包含消耗性的积分、宝石或游戏内货币等。您也可以提供包含消耗性商品打折权益的订阅 (例如能以优惠价购买宝石包的高级会员资格)。
          • 如果要将现有 app 更改为基于订阅的业务模式,您不得减掉现有用户已付费购买的主要功能。例如,针对新客户引入订阅模式后,已购买“完整游戏解锁”的客户应能够继续访问完整版游戏。
          • 支持自动续期订阅的 app 可以通过提供 App Store Connect 中规定的相关信息,来为客户提供免费试用期。
          • 试图诓骗用户的 app 会从 App Store 中被移除。这包括试图通过虚假信息诱骗用户购买订阅或涉及“诱购”和欺诈行为的 app,这些 app 会被从 App Store 中移除,您也可能会从 Apple Developer Program 中除名。进一步了解订阅免费试用期
      • 3.1.2(b) 升级和降级:

        • 用户应能获得无缝的升级/降级体验,并且不会出现无意间订阅同一内容的多个不同版本。请查阅关于管理订阅升级和降级选项的最佳做法
      • 3.1.2(c) 订阅信息:

        • 在让客户订阅之前,您应当清晰描述付费后的具体权益。每月有几期?云存储容量有多大?具体能访问您的哪些服务?务必清晰地传达“协议、税务和银行业务”下“Apple Developer Program 许可协议”的“附件 2”中所述的要求。
      • 3.1.3(a)“阅读器”App:

        • App 可以允许用户访问先前购买的内容或内容订阅 (具体包括:杂志、报纸、图书、音频、音乐、视频、专业数据库访问权限、VoIP、云存储以及经批准的服务,如课堂管理 app),前提是您同意不会直接或间接引导 iOS 用户使用非 App 内购买项目机制进行购买,并且在您介绍其他购买方式的普通沟通中没有刻意阻止用户使用 App 内购买项目。
      • 3.1.3(b) 多平台服务:

        • 跨平台运行的 app 可以允许用户访问用户在别处获取的内容、订阅或功能,包括多平台游戏中的消耗品,前提是这些项目也在 app 中以 App 内购买项目的形式提供。您不得直接或间接引导 iOS 用户使用非 App 内购买机制进行购买,在您关于其他购买方式的一般说明中亦不可刻意阻止用户使用 App 内购买项目。
      • 3.1.4 硬件相关内容:

        • 在为数不多的情形中,例如当功能依赖于特定的硬件功能时,app 可在不使用 App 内购买项目的情况下解锁相应功能 (例如,天文 app 会在与望远镜同步后增加功能)。与经过批准的实际产品 (如玩具) 配合使用的可选 app 功能可在不使用 App 内购买项目的情况下解锁特定功能,前提是它同时也提供 App 内购买项目选项。您不得要求用户通过购买无关产品或参与广告或市场活动来解锁 app 功能。
      • 3.1.5 (a) App 之外的商品和服务:

        • 如果 app 允许用户购买将在 app 之外使用的商品或服务,则必须使用 App 内购买项目以外的购买方式来收取相应款项,如 Apple Pay 或传统的信用卡入口。
      • 3.1.5 (b) 加密货币:

        • (i) 钱包:App 可以协助虚拟货币储值,前提是它们由组织类别帐户的开发者提供。
        • (ii) 挖矿:App 不可参与虚拟货币挖矿,除非处理过程是在设备外进行的 (例如,云端挖矿)。
        • (iii) 兑换:App 可以通过经批准的交易所协助加密货币交易或传输,前提是它们是由交易所本身提供的。
        • (iv) 首次代币发行:App 如支持首次代币发行 (“ICO”)、数字加密货币期货交易以及其他数字加密证券或准证券交易,发布方须为已创立的银行、证券公司、期货经纪商 (“FCM”) 或其他经批准的金融机构,并遵守所有相关法律。
        • (v) 加密货币 app 不可通过完成任务来提供货币,如下载其他 app、鼓励其他用户下载,以及在社交网络发帖等。
      • 3.1.6 Apple Pay:

        • 如果 app 使用 Apple Pay,则在销售任何商品或服务之前,必须先向用户提供所有的基本购买信息,并且必须正确使用 Apple Pay 品牌和用户界面元素,具体要求可参考“Apple Pay 识别标志指南”和“Human Interface Guidelines (英文)”。使用 Apple Pay 提供重复付款服务的 app 至少需要披露以下信息:
          • 续订周期的时长;除非被取消,否则续订将会继续
          • 每个周期中会提供哪些服务
          • 将向客户收取的实际费用
          • 如何取消
      • 3.1.7 广告:

        • App 内显示的广告必须与 app 的年龄分级相符。应允许用户查看用于将他们定向至这个广告的所有信息 (不要求用户离开 app),并且不可涉及基于敏感用户数据的定向或行为广告。敏感的用户数据包括健康/医疗数据 (如来自 HealthKit API 的数据)、学校和课堂数据 (如来自 ClassKit 的数据),或儿童的数据 (如来自儿童类别的 app 的数据),等等。插播广告、会中断或阻止用户体验的广告必须清楚地表明它们属于广告,不得操纵或欺骗用户轻点它们,并且必须提供可以轻松访问和清晰可见的关闭/跳过按钮,按钮大小要足以让用户轻松解除广告。
    • 3.2 其他业务模式问题

      下方列表并非详尽清单,并且您提交的 app 可能会导致我们的政策有所更改或更新,但这里有一些额外的应做事宜和勿做事宜需要您谨记在心:

      • 3.2.1 可以接受

        • (i) 在您的 app 中,出于购买或促销目的而展示您的其他 app,只要您的 app 不只是简单地罗列其他 app。
        • (ii) 显示或推荐专为经批准的特定需求而设计的第三方 app (如健康管理、航空以及辅助功能等)。您的 app 应能提供持续不断的编辑内容,这样 app 才不会看起来像是个摆设。
        • (iii) 在租借期限结束后,禁止访问经批准的特定租借内容 (例如电影、电视节目、音乐、图书);所有其他项目服务不得存在过期时间。
        • (iv) 钱包凭证可用于付款或接收付款、传输交易或是提供身份验证 (例如电影票、优惠券和 VIP 凭据)。如将钱包凭证用作其他用途,则可能会导致 app 被拒,钱包凭据也有可能被撤销。
        • (v) 保险类 app 必须免费提供,并且必须遵守 app 发布地区的相关法律,且不得使用 App 内购买项目。
        • (vi) 经批准的非营利组织可以在他们持有的 App 或第三方 app 内进行筹款活动,前提是这些筹款活动必须遵守所有的 App Review 准则并提供 Apple Pay 支持。这类 app 必须披露资金的计划用途,遵守所有必要的当地和联邦政府法律,并且确保向捐款人提供相应的报税收据。在被要求时,还应向 App Review 团队提供其他信息。向捐款人介绍其他非营利组织的非营利组织平台必须确保 app 中列出的每一家非营利组织都已通过非营利组织批准流程。进一步了解如何成为受批准的非营利组织 (英文)
        • (vii) App 可允许个人用户使用非 App 内购买项目机制向另一位个人送赠货币式礼物,前提为:a) 送赠方拥有决定是否进行送赠的完全自主权,b) 获赠方收取 100% 的礼物金额。然而,礼物若在任何时间点对应或包含接收任何数字内容或服务,则必须使用 App 内购买项目。
        • (viii) App 如用于金融交易,投资或资金管理,发布方应为执行此类服务的金融机构,或必须使用由相应机构根据自身条款与条件提供的公共 API。
      • 3.2.2 不可接受

        • (i) 创建与 App Store 类似且用于显示第三方 app、扩展功能或插件的界面,或将其作为热门 app 的合集。
        • (ii) 通过由硬件或操作系统提供的内置功能 (诸如推送通知、照相机或陀螺仪) 或 Apple 服务 (如 Apple Music 访问或 iCloud 存储) 获利。
        • (iii) 人为地刷广告展示次数或者广告点进次数的 app,以及主要设计目的在于显示广告的 app。
        • (iv) 在 app 内为慈善机构和募款方筹集资金,除非您是经批准的非营利组织或依上文 3.2.1 (vi) 规定获得了许可。出于以上目的筹集资金的 app 必须在 App Store 上免费,并只能在 app 之外筹集,例如通过 Safari 浏览器或短信。
        • (v) 强行限制 app 的用户群,例如限制特定地区或运营商。
        • (vi) App 应当允许用户直接获得付费购买的项目而无需执行额外的任务,如在社交媒体上发帖、上传通讯录,以及在 app 内签到特定次数等。App 不得要求用户必须先为 app 评分或点评、观看视频、下载其他 app、点击广告或进行其他类似操作,然后才能访问 app 的功能、内容或使用 app,或者收到现金或其他补偿,包括但不限于礼品卡和代码。
        • (vii) 人为操纵用户在其他服务中的可见性、状态或排名,除非相关服务的条款和条件允许这样做。
        • (viii) App Store 中不允许分发协助进行二元期权交易的 app。请考虑使用网页版 app。App 如支持差价合约或其他金融衍生工具 (如外汇) 交易,则必须在提供服务的所有司法管辖区获得相应的许可。
        • (ix) App 不得强制要求用户为 app 评级或点评、下载其他 app,或执行其他类似操作,然后才能访问 app 的功能、内容或者使用 app。

    4. 设计

    Apple 客户非常注重简洁、雅致、创新且易于使用的产品,这也正是我们希望在 App Store 上看到的。您可尽情提供各种优秀设计,但要想获准在 App Store 上发布 app,至少需要满足以下标准。另请记住,即使在 app 获得批准之后,您也应当对其进行更新,确保 app 功能正常并持续吸引新客户和现有客户。停止服务或体验下降的 app 随时可能会从 App Store 中移除。

    • 4.1 抄袭者

      请拿出您自己的想法。我们知道您有自己的奇思妙想,那么请将它们付诸实际。请不要简单照搬 App Store 上的热门 app,或只是细微修改其他 app 的名称或 UI,就将其挪为己用。这么做不但有引发知识产权侵权索赔的风险,更会加剧在 App Store 中浏览的难度,并对您的开发者同仁来说也很不公平。

    • 4.2 最低功能要求

      App 应包含功能、内容和 UI,而不仅仅是一个经过重新包装的网站。如果 app 没有什么实用价值、毫无新意或者不太像是一个 app,那它就不适合出现在 App Store 中。如果 app 不能带来持久的娱乐价值,则可能无法获得批准。如果 app 只是一首歌曲或一部影片,则应提交到 iTunes Store。如果 app 只是一本图书或游戏指南,则应提交到 Apple Books Store。

      • 4.2.1 使用 ARKit 的 app 应提供丰富而完整的增强现实体验,仅将模型放入 AR 视图或重播动画并不足够。
      • 4.2.2 除了目录类 app 之外,app 不应只包含市场营销材料、广告、网络剪报、内容聚合或链接集合。
      • 4.2.3
        • (i) App 应能独立工作,无需安装其他 app。
        • (ii) 确保 app 发布时在其二进制文件中包含有正常运行所需的充足内容。
        • (iii) 如果 app 需要下载其他资源,请披露下载大小并在下载之前提醒用户。现有 app 在 2019 年 1 月 1 日后提交的所有更新都必须遵循这一准则。
      • 4.2.4 与表盘类似的 Apple Watch app 可能会令人感到困惑,因为用户会认为这些 app 能与各种设备功能 (如轻扫、通知和第三方复杂功能) 配合使用。将创意性的时间表现方式用作 app 界面是个好点子 (例如,供冲浪者使用的潮汐时钟),但是如果您的 app 与表盘过于相像,则可能会被我们拒绝。
      • 4.2.5 主要用作 iCloud 和 iCloud 云盘文件管理器的 app 需要包含更多的 app 功能,才能获得批准。
      • 4.2.6 利用商业化模板或 app 生成服务创建的 app 将被拒绝,除非这个 app 由相应内容的提供商直接提交。这些模板服务若要为不同的客户提供差异化的用户体验,可提供工具来帮助客户自行创建创新的 app,但不应代表客户提交 app。模板提供商也可以考虑创建单一的二进制文件,以汇总或“选取”的模型托管所有客户端内容 (例如:在搜索餐厅的 app 里为每个客户餐厅定制独立的条目或页面,或在聚会活动 app 里为每个客户的活动创建单独的条目)。
      • 4.2.7 远程桌面客户端:如果您的远程桌面 app 用作特定软件或服务的镜像,而不是主机设备的普通镜像,则必须符合以下规定:
        • (a) App 必须仅连接到归用户所有的主机设备 (即归用户所有的个人电脑或专用游戏控制台);主机设备和客户端皆须通过本地局域网连接。
        • (b) 客户端中显示的任何软件或服务应完全在主机设备上执行,在主机设备屏幕上完整呈现,并且不可使用超出远程桌面传输所需的 API 或平台功能。
        • (c) 所有帐户的创建和管理均必须从主机设备发起。
        • (d) 客户端上显示的 UI 不与 iOS 或 App Store 视图相似,不提供商店类界面,也不能供用户浏览、选择或购买用户尚未拥有或授权的软件。为明确起见,在镜像的软件中发生的交易不需要使用 App 内购买,前提是这些交易是在主机设备上处理的。
        • (e) 云端 app 的瘦客户端不适合在 App Store 上发布。
    • 4.3 重复 App

      请不要为同一个 app 创建多个套装 ID。如果您的 app 针对特定位置、运动队、大学等存在不同版本,请考虑提交单个 app,并提供 App 内购买项目以提供不同的功能。同时,请避免继续在已有大量类似 app 的类别下进行开发;App Store 上已经有太多模拟放屁、打嗝声音的 app,以及手电筒和爱经 app。上传大量相似版本 app 的开发者会遭到 Apple Developer Program 的除名。

    • 4.4 扩展

      托管或包含扩展的 app 必须遵循“App 扩展编程指南 (英文)”或“Safari 浏览器 App 扩展指南 (英文)”;如果可行,还应包含诸如帮助屏幕和设置界面在内的一系列功能。您应当在 app 的市场营销文本中清晰且准确地披露提供了哪些扩展,扩展中不可包含营销、广告或 App 内购买项目。

      • 4.4.1 Keyboard 扩展还需要遵循一些额外的规则。

        它们必须:

        • 提供键盘输入功能 (如可输入字符);
        • 如果键盘中含有图像或表情符号,请遵循贴纸准则;
        • 提供切换到下一个键盘的方法;
        • 在没有网络连接和不要求完全访问权限的情况下仍能使用;
        • 收集用户活动数据只是为了改进其 Keyboard 扩展在 iOS 设备上的性能。

        它们不得:

        • 启动“设置”之外的其他 app;或者
        • 将键盘按键用于其他行为,例如按住 return 键来启动相机等。
      • 4.4.2 Safari 浏览器扩展必须在 macOS 上的最新版 Safari 浏览器上运行。它们不得干扰系统和 Safari 浏览器 UI 元素,并绝不能包含恶意或误导性的内容或代码。违背此规则会遭到 Apple Developer Program 除名。除了正常工作所必需的网站,Safari 浏览器扩展不得要求访问更多网站。
      • 4.4.3 表情贴纸

        表情贴纸是让“信息”变得更动态、更有趣的绝佳方式,让人们能够以更巧妙、有趣、有意义的方式表达自我。无论您的 app 是含有 Sticker 扩展,还是您要创建单独的表情贴纸包,其内容均不得冒犯用户、造成负面体验或违反相关法律。

        • (i) 通常,不适合在 App Store 上发布的内容也不适合放入表情贴纸内。
        • (ii) 考虑地区敏感性,不要在难以接受或者会违反当地法律的国家/地区提供您的表情贴纸包。
        • (iii) 如果您的表情贴纸含义不易理解,请在审核备注中附上清晰的说明,从而避免导致审核流程的延误。
        • (iv) 确保您的表情贴纸在您的朋友与家人之外具有相关性;它们不应特定于个人活动、群体或关系。
        • (v) 您必须对表情贴纸中的内容,持有所有必要的著作权、商标权和形象权及授权许可,不得提交任何未经授权的内容。请记住,您必须能够在要求时提供可核实的文件。若 app 内含有您无权使用的表情贴纸内容,这个 app 会被从 App Store 中移除,屡次侵权者会被从 Developer Program 中除名。如果您认为自己的内容遭到其他提供商侵权,请点击此处提交申诉
    • 4.5 Apple 站点和服务

      • 4.5.1 App 可以使用获批的 Apple RSS Feed (如 iTunes Store RSS Feed),但不能抹除 Apple 站点 (如 apple.com、iTunes Store、App Store、App Store Connect 和开发者门户等) 的任何信息,也不能使用这类信息进行排名。
      • 4.5.2 Apple Music
        • (i) MusicKit API 可以让客户在使用您的 app 时访问自己的订阅。它们旨在为 Apple Music 订阅用户提供轻松简便的音乐播放体验。用户必须能够发起 Apple Music 流媒体播放,并且能够使用“播放”、“暂停”和“跳过”等标准媒体控件来浏览音乐内容。此外,您的 app 不得要求用户通过付款或间接的货币化方式来获取 Apple Music 服务的访问权限 (如 App 内购买项目、广告、要求使用用户信息等)。请勿下载、上传或分享源自 MusicKit API 的音乐文件,除非 MusicKit (英文) 文稿中已明确允许。
        • (ii) 使用 MusicKit API 并不能取代为获得更深入或更复杂的音乐集成而可能需要的授权许可。例如,如果您希望您的 app 在特定时刻播放特定的歌曲,或者创建可以在社交媒体上分享的音频或视频文件,您需要直接联系版权持有人来获得许可 (如同步或改编权利) 和资源。封面插图和其他元数据仅可用于与音乐播放或播放列表相关的用途 (包括展示 app 功能的 App Store 屏幕快照),未经版权持有人明确授权,不得用于任何市场营销或广告目的。在 app 中集成 Apple Music 服务时,请务必遵循“Apple Music 识别标志指南 (英文)”。
        • (iii) 访问 Apple Music 用户数据 (如播放列表和个人收藏) 的 app 必须在用途字符串中清楚披露这类访问行为。收集的任何数据均不得与第三方分享,也不得用于除支持或改进 app 体验之外的任何其他用途。这类数据不得用于识别用户身份或设备,也不得用于广告定向宣传目的。
      • 4.5.3 不得使用 Apple 服务 (包括 Game Center 或推送通知等) 发送垃圾邮件、进行网络钓鱼,或者向客户发送未经请求的信息。不得尝试进行查找、跟踪、关联、挖掘、获得或利用玩家 ID、别名以及通过 Game Center 获得的其他信息。否则将会遭到 Apple Developer Program 的除名。
      • 4.5.4 App 不得将推送通知列为必需条件,并不能将这项功能用于广告、推广或直接营销用途,或者用来发送敏感的个人或机密信息。不当使用这些服务可能会导致撤销您的权限。
      • 4.5.5 仅以 Game Center 团队批准的方式使用 Game Center 玩家 ID,并不得在 app 中显示或向任何第三方显示。
      • 4.5.6 App 可以在自身和 app 元数据中使用会呈现为 Apple 表情符号的 Unicode 字符。Apple 表情符号不可在其他平台中使用,也不可直接嵌入到您的 app 二进制文件中。
    • 4.6 备选 App 图标

      App 可以使用自定图标以传达特定信息 (例如表达对某个运动团队的喜爱),前提是每次更改都由用户发起,并且 app 中应包含恢复至原始图标的设置。所有图标变体必须与 app 的内容相关,并且更改内容在所有系统资源之间应保持一致,以便“设置”和“通知”等位置中显示的图标与新的 Springboard 图标相吻合。这项功能不可用于动态、自动或连续性更改,例如用于反映最新天气信息和日历通知等。

    • 4.7 HTML5 游戏与聊天机器人 (Bot) 等

      App 可包含或运行未嵌入二进制文件的代码 (如基于 HTML5 的游戏和聊天机器人等),前提是 app 的主要目的并非代码分发,代码亦没有在商店界面或类似商店的界面中提供,而且相关软件 (1) 为免费软件或需通过 App 内购买项目进行购买;(2) 仅使用标准 WebKit 视图中提供的功能 (例如,它必须在 Safari 浏览器中原生打开和运行,且无需修改也无需其他软件);您的 app 必须使用 WebKit 和 JavaScript Core 来运行第三方软件,且不得试图扩展或披露原生平台 API 给第三方软件;(3) 由已加入 Apple Developer Program 且签署“Apple Developer Program 许可协议”的开发者提供;(4) 不提供对真实货币游戏、彩票或慈善捐助的访问;(5) 遵守各个 App Review 指南中的条款 (例如,不含令人反感的内容);并且 (6) 不支持数字商务。在被要求时,您必须提供 app 中所含软件和元数据的索引信息。它必须包含软件提供商的 Apple Developer Program 团队 ID,以及可供 App Review 团队用于确认软件符合上述要求的 URL。

    • 4.8 通过 Apple 登录

      如果 app 专门使用第三方或社交登录服务 (例如,Facebook 登录、Google 登录、通过 Twitter 登录、通过 LinkedIn 登录、通过 Amazon 登录或微信登录) 来对其进行设置或验证这个 app 的用户主帐户,则该 app 必须同时提供“通过 Apple 登录”作为等效选项。用户的主帐户是指在 app 中建立的、用于标识身份、登录和访问功能和相关服务的帐户。

      在以下情况下,不要求提供“通过 Apple 登录”选项:

      • 您的 app 仅使用公司自有的帐户设置和登录系统。
      • 您的 app 是一款教育、企业或商务 app,要求用户使用现有的教育或企业帐户登录。
      • 您的 app 使用政府或行业支持的公民身份系统或电子身份证来鉴定用户身份。
      • 您的 app 是特定第三方服务的客户端,用户需要使用他们的邮件、社交媒体或其他第三方帐户直接登录才能访问内容。
         

    5. 法律

    只要 app 向某个地区的用户提供,那么就必须遵守该地区的所有法律要求 (如果您不太确定,请与律师联系)。我们知道这些东西非常复杂,但除了下方所列准则以外,同时理解所有本地法律,并确保您的 app 能满足所有法律要求,是您必须承担的责任。当然,如果 app 存在唆使、宣传或鼓励犯罪的行为或明显不负责任的行为,则会被拒绝。在发现涉及如方便人口贩卖和/或剥削儿童的 app 的极端情况下,我们将通知有关当局。

    • 5.1 隐私

      在 Apple 生态体系中,保护用户隐私总是第一要务。您要在处理个人数据时小心谨慎,以确保遵守了隐私保护最佳做法 (英文)、适用的法律和“Apple Developer Program 许可协议 (英文)”中的条款,并满足客户的期望。尤其是:

      • 5.1.1 数据收集和存储

        • (i) 隐私政策:所有 app 必须在 App Store Connect 元数据栏位和 app 内部包含可轻松访问的隐私政策链接。隐私政策必须明确而清楚地:
          • 指明 app/服务所收集的数据 (若有)、收集数据的方式,以及这些数据的所有用途。
          • 确认与 app 共享用户数据 (遵从这些准则) 的任何第三方 (例如,分析工具、广告网络和第三方 SDK,以及能够访问用户数据的任何母公司、子公司或其他相关实体) 会提供与 app 隐私政策所述及这些准则所要求相同或等同的用户数据保护措施。
          • 解释数据保留/删除政策,并且说明用户可以如何撤销同意和/或请求删除用户数据。
        • (ii) 许可 如果 app 会收集用户数据或使用数据,即使此类数据在收集当时或收集后即刻被匿名处理,app 也必须征得用户的同意才能收集。付费功能不得依赖于或要求用户授予访问这些数据的权限。App 还必须为客户提供简单易懂且易于操作的方式来撤销同意。确保您在用途说明中清楚且完整地阐述您对数据的使用。如果 app 依据欧盟《一般数据保护条例》(“GDPR”) 或类似法规,出于合法权益而不经事先同意就收集数据,则必须遵循此类法律的所有条款。进一步了解请求许可 (英文)
        • (iii) 数据最少化:App 仅可请求访问与 app 核心功能相关的数据,并且仅可收集和使用完成相关任务所需的数据。若有可能,请使用进程外选取器或共享列表,而不要请求“照片”或“通讯录”等受保护资源的完整访问权限。
        • (iv) 访问权限:App 必须尊重用户的权限设置,不得操纵、欺骗或强迫用户同意不必要的数据访问。例如,可发布照片到社交网络的 app 不得在允许用户上传照片前要求麦克风访问权限。若有可能,请为不同意的用户提供替代解决方案。例如,如果用户拒绝共享位置,请提供手动输入地址的功能。
        • (v) 帐户登录:如果 app 不包含基于帐户的重要功能,请允许用户在不登录的情况下使用。App 不得要求用户提供个人信息才能正常使用,除非个人信息与 app 的核心功能直接相关,或是法律要求时。如果您的核心 app 功能与特定的社交网络 (如 Facebook、微信、微博或 Twitter 等) 不相关,您必须提供无需登录或其他类似机制的访问权限。调取基本档案信息、分享到社交网络或邀请朋友使用 app 等不视为核心 app 功能。App 还必须包含用于撤销社交网络凭证的机制,以及从 app 内停用 app 与社交网络之间数据访问的机制。App 不可在设备外存储社交网络的凭证或令牌,而且只能使用此类凭证或令牌来在 app 使用期间从 app 本身直接连接社交网络。
        • (vi) 如果开发者开发的 app 试图暗中收集用户密码或其他用户私人数据,那么开发者会被从 Apple Developer Program 中除名。
        • (iv) 必须使用 SafariViewController 在显著位置向用户显示信息;不得隐藏这个控制器,也不能被其他视图或图层遮挡。此外,未经用户的知情和同意,app 不得私下利用 Safari 浏览器 ViewController 来追踪用户。
        • (viii) 汇编个人信息的 app,如果其来源未经用户的明确同意,或并非直接源自用户 (即使是公共数据库),则不可在 App Store 中发布。
      • 5.1.2 数据使用和共享

        • (i) 除非法律另有许可,否则您不得未经他人允许而使用、传输或共享他们的个人数据。您必须提供相应的信息,说明以何种方式在哪里使用这些数据。App 收集的数据只有在为了改进 app 或用于广告投放用途 (遵守 Apple Developer Program 许可协议 (英文)) 的前提下,才能与第三方共享。如果 app 在未经用户同意或未能符合数据隐私保护法律的情况下共享用户数据,则 app 可能会被下架,并且可能会导致您从 Apple Developer Program 中除名。
        • (ii) 除非法律另有明确许可,否则未经用户的额外同意,为一个用途而收集的数据不可用于其他用途。
        • (iii) App 不得试图暗中基于收集的数据构建用户资料,也不得尝试、协助或鼓励他人根据从 Apple 提供的 API 收集的数据,或您所谓以“匿名”、“汇总”或其他不可识别的方式收集的数据来识别匿名用户的身份或重建用户资料。
        • (iv) 请勿使用来自“通讯录”、“照片”或能访问用户数据的其他 API 的信息来构建联系人数据库,以供自己使用或出售/分发给第三方,也不要收集关于用户设备上安装有哪些 app 的信息,以用于分析或投放广告/市场营销。
        • (v) 请勿使用通过“通讯录”或“照片”收集的信息来联系用户,除非用户以个人方式明确主动发起联系;请勿包含“全部选择”选项,也不要默认选中所有联系人。在信息发送之前,您必须向用户清楚说明这个信息会如何呈现给收件人 (例如,信息中包含什么内容?发件人显示为谁?)。
        • (vi) 从 HomeKit API、HealthKit、消费者健康记录 API、MovementDisorder API、ClassKit 或深度图和/或面谱绘制工具 (例如 ARKit、相机 API 或照片 API) 收集的数据,不得用于市场营销、投放广告或基于使用情况进行其他数据挖掘,包括第三方在内。进一步了解实施 CallKit (英文)HealthKit (英文)ClassKit (英文)ARKit 的最佳做法。
        • (vii) 使用 Apple Pay 的 app 只能与第三方共享通过 Apple Pay 获得的用户数据,以帮助或改进商品或服务的交付。
      • 5.1.3 健康和健康研究

        健康、健身和医疗数据特别敏感,涵盖这些领域的 app 必须满足额外的规则,并确保客户隐私受到保护:

        • (i) App 仅能在获得批准的情况下,出于改进健康管理或健康研究的目的,使用在健康、健身和医疗研究背景下收集的数据 (包括从临床健康记录 API、HealthKit API、“运动与健身”、MovementDisorderAPI 或健康领域人体研究中收集的数据) 或将它披露给第三方,不得用于广告投放、市场营销或基于使用情况进行其他数据挖掘。不过,App 可以使用用户的健康或健身数据直接向该用户提供权益 (如保费减免),前提是 app 须由提供相应权益的实体提交,而且其数据不得与第三方共享。同时,app 必须清楚说明将从设备收集的具体健康数据。
        • (ii) App 不得将虚假或错误数据写入 HealthKit 或其他任何医疗研究/健康管理 App,不得在 iCloud 中存储个人健康信息。
        • (iii) 开展健康领域人体研究的 app 必须获得参与人员提供的知情同意书,如果涉及未成年人,则必须获得由其家长或监护人提供的知情同意书。上述知情同意书必须涵盖以下内容:(a) 研究的性质、目的和时长;(b) 具体规程,给参与人员带来的风险和益处;(c) 关于保密和数据处理 (包括与第三方共享信息的情况) 的信息;(d) 用于回答参与人员问题的联系人;以及 (e) 退出流程。
        • (iv) 用于开展健康领域人体研究的 app 必须获得一家独立伦理审查委员会的批准。一经要求,必须提供此类批准的证明。
      • 5.1.4 儿童

        出于诸多原因,您在处理儿童的个人数据时请务必小心谨慎。我们建议您仔细阅读所有要求,以遵循相关法律,如《儿童在线隐私保护法》(“COPPA”)、欧盟《一般数据保护条例》(“GDPR”) 以及任何其他适用的法律法规。

        App 只能出于遵守适用儿童隐私法规的目的要求用户提供出生日期或家长联系信息,但必须提供一些适用于各年龄层用户的实用功能或娱乐价值。

        主要面向儿童的 app 不应包含第三方数据分析或第三方广告。这样可以为儿童提供更安全的体验。在少数情况下,可能允许包含第三方数据分析和第三方广告,前提是这些服务遵守上文“准则 1.3”中所述的条款。

        此外,“儿童类别”中的 app,以及向未成年人收集个人信息 (例如姓名、地址、电子邮件、位置、照片、视频、图画、能否聊天、其他个人数据,或是将永久标识符与以上任何信息组合使用)、传输此类信息或能够共享此类信息的 app,则必须拥有隐私政策,且必须遵守适用的儿童隐私保护法规。为了清楚起见,“儿童类别”的家长监控要求,通常并不完全等同于在这些隐私法规下征得家长的同意后收集个人数据。

        特此提醒,“准则 2.3.8”要求只有“儿童”类别的 app 才能在元数据中使用类似“适合幼儿”和“适合儿童”等词语。不属于“儿童”类别的 app 不得在 app 名称、副标题、图标、屏幕快照或描述中包含任何暗示 app 主要受众为儿童的词汇。

      • 5.1.5 定位服务

        只有在定位服务与 app 提供的功能和服务直接相关时,才能在 app 中使用定位服务。基于位置的 API 不得用于提供紧急服务,不得对汽车、飞机和其他设备进行自主控制 (小型设备,如轻量无人机和玩具除外),不得遥控汽车防盗系统等。在收集、传输或使用位置数据之前,务必进行通知并获得用户同意。如果 app 会使用定位服务,请务必在 app 中说明相应的原因;请参考“Human Interface Guidelines (英文)”,了解相应的最佳做法。

    • 5.2 知识产权

      请确保 app 只包含由您创建或拥有使用许可的内容。如果您已越线并在未经许可的情况下使用了内容,您的 app 可能会被移除。当然,这也意味着如果他人抄袭了您的作品,则他们的 app 也可能会被移除。如果您认为自己的知识产权在 App Store 上受到了其他开发者的侵犯,请通过此网页表格提交权利主张。各个国家/地区的法律互不相同,但请务必避免以下常见错误:

      • 5.2.1 一般性:不得在未经授权的情况下,在 app 中使用受保护的第三方材料 (例如商标、版权作品、专利设计);也不得在 app 套装或开发者名称中包含虚假、抄袭或误导性的演示、名称或元数据。App 提交方应当是拥有或获授权使用知识产权和其他相关权利的个人或法律实体,并且应对提供 app 中的任何服务负责。
      • 5.2.2 第三方站点/服务:如果您的 app 会使用、访问第三方服务、通过访问第三方服务盈利或是显示第三方服务的内容,请确保您获得在该服务的使用条款下进行此类操作的特别许可。如有相应要求,则必须提供相关授权。
      • 5.2.3 音频/视频下载:app 不得促进非法文件共享,或在没有获得这些资源的明确授权的情况下,提供从第三方来源 (如 Apple Music、YouTube、SoundCloud、Vimeo) 保存、转换或下载媒体资源的能力。视频/音频内容流也有可能触犯使用条款,所以请务必在 app 访问这些服务前,进行检查。如有相应要求,则必须提供相关文稿。
      • 5.2.4 Apple 认可:不得误导或暗示 Apple 是 app 的来源或提供商,或者 Apple 以任何形式表示认可其质量或功能。如果您的 app 被选为“编辑选荐”,Apple 将自动显示相应徽章。
      • 5.2.5 Apple 产品:不得创建与现有 Apple 产品、界面 (如访达)、app (如 App Store、iTunes Store 或“信息”) 或广告主题外观相似或容易混淆的 app。App 和扩展功能 (包括第三方键盘和贴纸包) 不得含有 Apple 表情符号。iTunes 音乐预览内容不得用于其娱乐价值 (如用作照片拼贴画的背景音乐或游戏配音) 或其他未获授权的方式。如果 app 显示健身记录圆环,则不应以类似于“健身记录”控件的方式展示“活动”,“锻炼”或“站立”数据。请参考“Human Interface Guidelines (英文)”以了解关于如何使用健身记录圆环的更多信息。
    • 5.3 游戏、赌博和彩票

      游戏、赌博和彩票的管理难度大,是 App Store 上受到最多管制的应用类别之一。只有全面核实了即将发布您 App 的所有国家/地区的相关法律要求后,才能包含此功能,并且要做好准备此功能的审核流程需要更长的时间。您需要谨记以下事项:

      • 5.3.1 抽奖和比赛必须由 app 的开发者赞助。
      • 5.3.2 抽奖、比赛和抽彩的正式规则必须在 app 中注明,并且必须明确表示 Apple 不是赞助者,也没有以任何形式参与活动。
      • 5.3.3 App 不得通过 App 内购买项目购买点数或货币,以用于任何种类的真实货币游戏;不得向用户出售彩票或抽彩券;不得在 app 内进行资金转账。
      • 5.3.4 提供真实货币游戏(例如体育下注、扑克、赌场游戏、赛马)或彩票的 App 必须在使用该 App 的地区获得必要的许可和批准,且只能在这些地区发布,此类 App 在 App Store 中必须免费提供。不允许在 App Store 上发布非法的赌博辅助工具,包括记牌器。彩票 App 必须有报酬、几率及奖品。
    • 5.4 VPN App

      提供 VPN 服务的 app 必须利用 NEVPNManager API (英文),并且仅可由登记为企业的开发者提供。在用户进行任何操作来购买或以其他方式使用该服务之前,您必须在 app 屏幕上清楚地声明会收集哪些用户数据,以及将如何使用这些数据。无论出于任何目的,提供 VPN 服务的 App 不得出售、使用或向第三方披露任何数据;并且必须在隐私政策中做出这一承诺。VPN app 不得违反当地法律,如果您选择在需要 VPN 许可证的地区发布,则必须在 App Review 注释栏位中提供您的许可证信息。除此之外,经批准的提供商所提供的家长控制、内容拦截和安全 app 也可以使用 NEVPNManager API。不遵循这项准则的 app 会被从 App Store 中移除,您也可能会被从 Apple Developer Program 中除名。

    • 5.5 移动设备管理

      提供移动设备管理 (MDM) 服务的 MDM App 必须向 Apple 请求此功能。此类 app 仅可由商业企业 (如商业组织、教育机构或政府机构) 提供;在少数情况下,也可由使用 MDM 提供家长控制服务的公司提供。在用户进行任何操作来购买或以其他方式使用该服务之前,您必须在 app 屏幕上清楚地声明会收集哪些用户数据,以及将如何使用这些数据。MDM app 不得违反当地法律。无论出于任何目的,提供 MDM 服务的 App 不得出售、使用或向第三方披露任何数据;并且必须在隐私政策中做出这一承诺。不遵循这项准则的 app 会被从 App Store 中移除,您也可能会被从 Apple Developer Program 中除名。

    • 5.6 开发者行为准则

      请尊重每一个人,无论是在 App Store 中回复用户评论、回应客户支持请求时,还是与 Apple 沟通时 (包括您在解决方案中心的回复),都应做到这一点。请勿涉及任何形式的骚扰、歧视、恐吓或霸凌行为,也不要鼓励他人实施任何上述行为。

      客户的信任是 App Store 获得成功的基石。App 不得存在以下行为:掠夺用户或试图勒索用户;诱导用户进行非自愿的购买;强迫用户共享不必要的数据;以欺骗的方式抬高价格;针对未交付的功能或内容收取费用;或者在 app 内部或外部实施任何其他操纵行为。

    提交之后

    在 App Store Connect 中提交 app 和元数据之后,您随即就会进入审核流程。请谨记以下几点:

    • 时间:App Review 团队会尽快检查您的 app。不过,如果 app 比较复杂或者存在新的问题,则可能需要更深入的审查和考量。也请记住,如果 app 因为违反同一准则而一再被拒绝,或者您曾经试图操纵 App Review 流程,您的 app 将需要更长时间才能完成审核。进一步了解 App Review
    • 状态更新:App 的当前状态会反映在 App Store Connect 中,所以请多留意此处。
    • 加急请求:如果您遇到了严重的时间问题,可以申请加急审核 (英文)。请仅在您真的需要加快审核时才提出申请,以便其他开发者的加急请求不受影响。如果我们发现您滥用此系统,从此以后我们可能都会拒绝您的申请。
    • 发布日期:如果您设定了未来的发布日期,在此日到来之前,即使已经获得了 App Review 团队的批准,App 也不会显示在 App Store 上。请注意,最多可能需要 24 小时时间,您的 App 才能显示在所有选定的商店中。
    • 拒绝:我们的目标是公平、持续地遵循这些准则,但是人无完人。如果您的 app 被拒绝,但您存在疑问,或希望提供其他信息,请使用解决方案中心,以与 App Review 团队直接沟通。这样可以帮助您的 app 出现在商店中,也可帮助我们改进 App Review 流程,并在我们的政策中发现需要阐明的部分。如果您仍对结果不满意,请提交申诉 (英文)

    我们期待看到您开发出更多优秀作品!


     

    展开全文
  • iOS App Transprot Security

    2019-01-12 07:35:43
    随着iOS 9和OS X EI Capitan 的发布,苹果官方引入了应用通讯安全模式的概念。简而言之,应用通讯安全模式强制性要求应用需要使用最佳的安全通讯协议,比如TLS 1.2版本和前向保密技术。在不久的将来,苹果也将更新...

    随着iOS 9和OS X EI Capitan 的发布,苹果官方引入了应用通讯安全模式的概念。简而言之,应用通讯安全模式强制性要求应用需要使用最佳的安全通讯协议,比如TLS 1.2版本和前向保密技术。在不久的将来,苹果也将更新这些最佳实践以确保他们在保障网络数据安全的潮流中走在前列。

    在iOS 9 和 OS X EI Caption之后,当使用NSURLSession的时候默认会开启ATS。然而不幸的是,对于大多数开发者而言,这将意味着在他们基于新版本的操作系 统做开发时,情况有了很大的变化。好消息是,苹果官方提供了一些可选配置项来决定是否开启ATS模式,也就是可以选择开启或者不开启。

    开发者可以针对某些确定的URL不使用ATS,这需要在工程中的info.plist中标记NSExceptionDomains。在NSExceptionDomains字典中,可以显式的指定一些不使用ATS的URL。这些你可以使用的例子可以是:

    - NSIncludesSubdomains

    - NSExceptionAllowInsecureHTTPLoads

    - NSExceptionRequiresForwardSecrecy

    - NSExceptionMinimumTLSVersion

    - NSThirdPartyExceptionAllowsInsecureHTTPLoads

    - NSThirdPartyExceptionMinimumTLSVersion

    - NSThirdPartyExceptionRequiresForwardSecrecy

    这些关键字使我们可以更加细致的设置针对不使用ATS的域名情况下禁用ATS或者一些特殊的ATS选项。

    ATSInfoplist.png

    **在iOS 9 的beta1版本中,上述的关键字是错误的,应该使用如下关键字:**

    - NSTemporaryExceptionAllowsInsecureHTTPLoads

    - NSTemporaryExceptionRequiresForwardSecrecy

    - NSTemporaryExceptionMinimumTLSVersion

    - NSTemporaryThirdPartyExceptionAllowsInsecureHTTPLoads

    - NSTemporaryThirdPartyExceptionMinimumTLSVersion

    - NSTemporaryThirdPartyExceptionRequiresForwardSecrecy

    这些关键字在不久以后肯定会被替换掉。如果可以,你应该使用第一组的关键字,因为苹果官方支持这些关键字。虽然你正在使用临时的关键字,但它应该在将来的beta版本中还是可以继续使用的。

    下面是一些开发者可能会在开发过程中遇到的情况。

    例1 所有情况下都使用ATS

    这是最简单的情况。唯一需要做的事情就是使用NSURLSession。如果你的开发目标是iOS 9或者 OS X EI Capitan之后,ATS的最佳实践将会应用到所有基于NSURLSession的网络。

    例2 特殊情况除外,都使用ATS

    如 果你希望自己所有的域名,除了一些已知并不会使用ATS之外的,所有通信都使用ATS。这种情况下你可以指定一些不使用ATS的特殊情况,而其余的情况使 用ATS。对于这种场景,可以使用*NSExceptionDomains*来标识使用ATS默认设置的域。为了筛选出所有域或者子域,可以创建一个包含 想要排除使用ATS的URL的字典,然后设置其中的*NSExceptionAllowInsecureHTTPLoads*的值为true。如果想要对 于这些域完全禁用ATS,也可以指定更多的规则来限制,如使用*NSExceptionRequiresForwardSecrecy* 和*NSExceptionMinimumTLSVersion*关键字。

    ExampleB.png

    例3 除特殊情况外,都不使用ATS

    一 种与上例相反的情况,你可能进希望在你明确知道支持的域内使用ATS。比如,如果开发一个Twitter客户端,可能需要有难以计数的可能不支持ATS的 URL需要加载,可是你希望网络状况想发起登录请求和请求Twitter服务器的其他请求一致。在这种情况下,你可以设置禁用ATS为默认选项,然后指定 需要使用ATS的URL。

    这种情况下,需要设置*NSAllowArbitraryLoads*为true,然后 在*NSExceptionDomains*字典中定义需要保证安全性的URL。需要保证安全性的每个域都需要有自己的字典,而且字典中 的*NSExceptionAllowInsecureHTTPLoads*选项需要设置为false。

    ExampleC.png

    例4 低级的ATS

    在 某些情况下,可能ATS用于所有情况,或者一些,或者是自有的URL,但是并未针对所有的ATS最佳实践全部支持。也许你的应用服务器仅支持 TLS1.2,但是不支持之后的版本,与其把涉及到的所有域都设置为不用ATS,不如设置为支持版本较低的ATS。这种场景下,需要创建一 个*NSExceptionDomains*字典,这是一个对于每个域都要重用的字典选项,然后设 置*NSExceptionRequiresForwardSecrecy*值为false。类似的,如果你希望向前支持,但是需要最低版本的TLS,你 可以通过*NSExceptionMinimumTLSVersion*关键字定义你的应用服务器所支持的TLS版本。

    ExampleD.png

    例5 NSA-friendly 模式

    如果想完全不使用ATS(不建议使用这种模式,并且需要你完全理解其隐藏的危险。)你可以在info.plist中设置*NSAllowArbitraryLoads*属性为true。

    ExampleE.png

    第三方键值

    你可能注意到一些关键字像是使用了一些其他关键字中的词但是在前面加上了"ThirdParty"字样:

    - NSThirdPartyExceptionAllowsInsecureHTTPLoads

    - NSThirdPartyExceptionMinimumTLSVersion

    - NSThirdPartyExceptionRequiresForwardSecrecy

    在功能上,这些关键字与不含有"ThirdParty"的关键字有同样的效果。而且实际运行中所调用的代码将会完全忽略是否使用"ThirdParty"关键字。你应该使用适用于你的场景的关键字而不必过多考虑这些。

    Certificate Transparency

    虽然ATS大多数安全特性都是默认可用的,Certificate Transparency 是 必须设置的。如果你有支持Certificate Transparency的证书,你可以检查NSRequiresCertificateTransparency关键字来使用Certificate Transparency。再次强调,如果你的证书不支持Certificate Transparency,此项需要设置为不可用。

    如果 需要调试一些由于采用了ATS而产生的问题,需要设置CFNETWORK_DIAGNOSTICS为1,这样就会打印出包含被访问的URL和ATS错误在 内的NSURLSession错误信息。要确保处理了遇到的所有的错误消息,这样才能使ATS易于提高可靠性和扩展性。

    以上所有信息都 WWDC 2015 NSURLSession session 中有所体现。最后,苹果强调需要上报开发过程所有的问题并且需要密切关注将来beta版本中的可能产生的变化。

     

    适配iOS9新特性:http://www.leiphone.com/news/201509/sLMiLyOsK3qzhkRJ.html

    展开全文
  • iOS安全模型

    2013-03-09 17:43:44
    iOS安全模型概述 保持智能手机设备上的信息安全对每个人而言都是至关重要的,不管是公司信息、客户信息,还是个人照片、银行信息、地址本或邮件。所有的用户个人资料都是非常重要的,智能手机必须在操作系统...

    iOS的安全模型概述

    保持智能手机设备上的信息安全对每个人而言都是至关重要的,不管是公司信息、客户信息,还是个人照片、银行信息、地址本或邮件。所有的用户个人资料都是非常重要的,智能手机必须在操作系统层面和硬件设备层面部署高层次的安全机制。苹果的iOS平台在其核心层面实施安全,确保智能手机设备足够安全并做到不影响用户体验。

    iOS设备提供了最严格的安全机制和功能,并易于使用。iOS设备提供的安全接近于透明。许多的安全功能是预设的,对于一些关键的安全功能如设备加密,不是可配置的,所有也不会被用户不小心取消掉。

    iPhone、iPad、iPod touch设置了多个安全层。低层次的硬件和固件安全抵御恶意软件和病毒,高层次的系统级安全保护个人信息和企业数据,防止未授权访问和挫败攻击。iOS的安全架构透视图如下:

    图中上部为软件,整个文件系统都被加密,文件系统又分系统分区和用户分区,应用运行运行在用户分区并限制在一个安全沙盒中,应用的数据基于不同的数据保护类型,文件系统通过系统内核与硬件通信。下部分为硬件和固件,系统内核直接调用固化加密引擎加解密文件数据,固化加密引擎密钥依赖烧制在设备上的设备key,组key以及苹果根认证证书。

    iOS的安全模型可从四方面剖析:

    系统架构:iPhone、iPad、iPod touch的安全的平台和硬件。

    加密和数据保护:阻止未经授权的人试图去使用或修改数据,就算设备丢失或被偷也能保护数据。

    网络安全:工业级的网络安全协议提供了数据传输中的安全认证和加密。

    设备访问:阻止未授权访问设备,当设备丢失或被偷时能远程察除数据。

    1. 系统架构:

    iOS设备紧密整合了硬件和软件允许验证设备上所有层次的运行活动。从系统被引导启动到iOS软件安装到第三方应用,每一步都会分析和审查以确保每个运行活动是可信赖的、使用的资源是适当的。

    一旦系统启动,集成的安全框架依赖于完整和可信赖的XNU[1],它是iOS内核。XNU会强迫安全机制在运行时确保高级别的方法调用和应用是可信任的。

    1.1安全的启动链:

    系统启动过程中每一步包含的所有组件都已经过苹果签名,并且只有在验证了信任链后才会被执行。这包括引导加载程序、内核、内核扩展、基带固件。

    当iOS设备启动后,应用处理器立刻执行引导只读存储器(Boot ROM)中的代码。引导ROM中的不可变代码是在集成电路制作过程中放置进去的,绝对可信。引导ROM代码包含了苹果的根认证中心公共密钥(Root CA public key),该密钥用来验证引导加载程序[Low-Level Bootloader (LLB)]是否被苹果签名,验证通过才允许它加载。这是信任链中的第一步,每一步都需要确保下一步执行的代码是经过苹果签名的。当LLB完成工作时,会执行下一步引导加载程序,iBoot,会依次证实并运行iOS内核。

    这个安全引导链确保最低层次的软件不会被篡改,允许iOS只运行在通过验证的苹果设备上。

    如果在引导过程中的某一步不能载入或不能验证下一步,启动就会终止并在设备上显示“Connection iTunes”。这叫做恢复模式。如果Boot ROM不能载入或不能验证LLB,会进入设备固件更新[DFU (Device Firmware Upgrade)]模式。两种情况下,设备必须通过USB连接到iTunes并恢复到出厂设置。

    因此iOS启动有三种方式

    正常模式:

    Boot ROM

    Low Level boot loaderLLB

    iBoot2 stageboot loader

    OSkernel/Application

    恢复启动:

    Boot ROM

    Low Level boot loaderLLB

    iBoot2 stageboot loader

    KernelRamdiskcan be restored

    DFU设备固件更新[也可长按HomeSleep/Wake按钮8秒进入该模式,该启动模式存在安全漏洞被利用进行越狱。]

    Boot ROM

    iBSS

    iBEC

    KernelRamdiskcan be restored

    1.2 系统软件个性化

    苹果定期发布软件更新以解决新兴的安全问题。用户收到更新提示后可通过iTunesover-the-air (OTA)来更新设备解决最近的安全问题。苹果提供了一个叫做SystemSoftware Personalization的进程阻止iOS系统降级到旧版本。iOS更新可通过iTunesover-the-air(OTA)来完成安装。iOS安装或升级的过程中,会连接到苹果的安装认证中心(gs.apple.com)并发送安装包每个组件的一个加密值列表(如LLBiBootKernelOS镜像)、一个防重放攻击的随机数Nonce[2]Nonce=Number Once)、设备唯一IDECID)。服务端检查加密值的允许安装的所有版本,如匹配到允许安装的版本,添加ECID到加密值并签名结果。一个完整的签名数据发送到设备用于安装或升级处理。请求设备验证签名确实来自苹果后,利用载入组件的加密值,并结合ECID去匹配签名过的数据。利用ECID可确保授权仅仅针对特定设备,一台设备上旧版本的iOS不能拷贝到另一台设备上使用。Nonce可以防止黑客通过保存服务器的响应用来在今后降级用户设备的重放攻击。

    1.3 应用签名

    iOS内核一旦启动,它将控制哪个用户进程和app能够运行。为了确保所有的app都来自可知并信任的源并且没被篡改,iOS要求所有执行的代码拥有苹果发布证书的签名。苹果自己提供的MailSafari等一样被签名。第三方应用也必须经过苹果审核并签名。iOS不会执行未经苹果签名的代码。

    1.4 运行时安全

    所有的第三方应用都在沙盒中运行。每个应用是隔离的,都有一个唯一的home路径用来存放自己的文件,这个路径是在安装时随机分配的。如果要访问另一个应用的数据,只能通过iOS提供的APIservices

    系统文件和资源也是跟用户应用隔离开来。各个应用之间无法共享文件,如要互相通信,只能通过URLSchemashared key chain。对应用需要的特别操作可以授权,授权是键值对的形式,签名后打包进应用程序。

    采用ASLR技术。地址空间布局随机化[Address space layoutrandomization (ASLR)], )是一种针对缓冲区溢出的安全保护技术,通过对堆、栈、共享库映射等线性区布局的随机化,以及增加攻击者预测目的地址的难度,防止攻击者直接定位攻击代码位置,达到阻止溢出攻击的目的。

    XN (execute never) 标志位在ARMv6中被引入,不可以在此区执行指令,从而在硬件上支持执行保护。

    2. 加密和数据保护

    安全启动链、代码签名、运行时安全等确保受信任的代码和应用才能在设备上运行。iOS还提供额外的安全功能来保护用户的数据,即使是在其他的安全机制遭到破坏时(如设备被未经授权修改)。就像系统架构一样,加密和数据保护整合了硬件和软件技术提供保护能力。

    2.1 硬件安全特征

    对于移动设备,速度和电池效能是非常重要的。加密解密操作复杂,实现不当有可能影响性能或影响电池使用寿命。

    每款iOS设备都有一个专用的AES 256位的加减密引擎固化在直接存储器(DMA)上,该DMA在闪存(flash storage)和系统内存之间,使得文件加密效率极高。除了拥有AES固化引擎,在硬件上还实现了SHA-1,更多的减少了加密操作的消耗。

    设备UID和设备组(型号)ID(GID)是AES256的密钥。UID和GID在出厂前烧入,没有软件和固化件能直接读取它们,它们只会得到加密和解密操作的结果。UID对每个设备唯一,苹果和任何供应商都不保存它。GID指示不同类设备的处理器类型,在分发系统软件时会根据GID发送对应该设备类型的系统软件。烧制UID和GID在电路板上可防止篡改或绕过,并且保证只能被AES引擎访问。

    UID允许数据加密被绑定到特定设备。如文件系统的密钥链中包括了UID,所以存储器从一台设备移到另一台设备,存储器中的文件就不能访问(其实是没法解密)了,因为每台设备的UID不同。

    除了UID和GID,其他的加密key都是系统使用Yarrow算法随机生成的

    安全的擦除保存的key跟产生它们一样重要。这在闪存上是一个挑战。闪存上的Wear-Leveling技术保证各个存储单元抹除的次数尽可能平均[3]。为解决这个问题,iOS设备增加了Effaceable Storage,所有能抹除的key存储在这里,从而实现直接寻址并快速抹除几小块的数据。

    2.2 文件数据保护

    除了在iOS设备上的硬件加密功能,苹果还使用了一种数据保护的技术保护存储在设备闪存上的数据。这种技术的设计专注于手机设备,经常连接网络、随时接听电话、收发短信和Email等。

    2.2.1 概述

    每当一个文件在数据分区创建时,数据保护就创建一个新的256位的key。该key被交给硬件AES引擎,AES引擎使用该key加密要写入闪存的文件。

    如下图:文件的内容用File key加密,File keyclass key加密存储在文件的元数据Metadata中。文件的元数据被file system key加密。file system key是一个随机数,在iOS第一次安装时创建或在设备被抹除时重建。该key存在Effaceable Storage中,删除该key会导致所有文件无法访问,这就是苹果实现快速抹除设备数据的根源。Class keyUID保护,有些class key还受开机密码保护。Key的等级层次提供灵活性和高性能。如,改变文件的保护类型,只需要对File key用对应的class key重新加密;改变了开机密码,只需重新加密class key

    当一个文件打开时,它的元数据首先被解密(使用file system key)。元数据包括加密了的file key和文件的保护类型class,根据文件保护类型找到对应的加密的class key,利用开机密码和UID可解密class key,再利用class key解密file key,最后把file key提供给AES引擎,当从闪存读取文件时由它来解密文件类容。

    2.2.2开机密码

    iOS支持四个数字的简单密码和不限长度的包括数字字符的复杂密码。开机密码不仅能锁定设备,还能为加密提供额外的安全(如前述保护class key)。这意味着攻击者在没有开机密码的情况下不能访问由特定类型保护的数据。蛮力破解9位数字开机密码需要两年半,破解6为字符数字密码需要5年半。为防止暴力破解,用户还可设置输错10次开机密码可自动抹除设备数据。

    2.2.3  数据保护类型

    iOS设备上,当一个文件创建时,它被应用(app)分配了一个类型(class)。不同的类型在数据被访问时会应用不同的策略。基本的类型和策略如下:

    2.2.3.1 完全保护(NSFileProtectionComplete):

    class key受开机密码和设备UID保护。当用户锁定设备不久(10秒,如果Require Password设置为Immediately),解密的class key明文就会从内存丢弃,数据不能访问直到重新输入开机密码。邮件应用使用完全保护策略来保护邮件和附件。应用程序的启动镜像和位置数据等也都采用这种策略。

    2.2.3.2 非打开时保护Protected Unless OpenNSFileProtectionCompleteUnlessOpen):

    有些文件在设备锁定的情况下任然需要写入。如邮件附件在后台下载。除了普通的file key,数据保护还产生该文件的公钥/私钥对。另外还有一个密钥对Protected Unless Open class public key/Protected Unless Open class private key(该私钥受开机密码和UID保护),使用文件私钥和公钥Protected Unless Open classpublic key生一个共享秘密串,用该共享秘密串去加密file keyfile key与文件公钥一同存储在文件元数据中。对应的私钥被抹除。文件关闭后file key也很快从内存抹除。重新打开文件时,使用文件公钥与私钥ProtectedUnless Open class private key重新生成共享秘密串,利用该共享秘密串去解密file key,再用file key去解密文件内容。

    2.2.3.3 Pretected Until First User AuthenticationNSFileProtectionUntilFirstUserAuthentication):

    这种类型跟完全保护一样,只是解密的class key不会在设备锁定后从内存中抹除,直到重新启动设备。

    2.2.3.4 No ProtectionNSFileProtectionNone):

    Class key只被UID保护,不受开机密码保护,该class key存在Effaceable Storage中,主要是方便快速远程抹除数据。这是所有文件的默认保护类型。如果一个文件没有被指定数据保护类型,它依然是以加密的形式存储在iOS设备上的。

    iOSSDK提供了一整套API使得第三方伙伴和开发者能轻易的采纳数据保护机制来保护它们的应用。数据保护有文件和数据库的API,包括NSFileManagerCoreDataNSDataSQLite

    2.2.4  密钥链的数据保护

    许多应用需要处理密码和一些少量但很机密的数据,像key、登录凭证等。iOS密钥链(keychain)提供了一个安全的方法来保存这些数据。Keychain是No Protection保护类型存储在文件系统中的SQLite数据库实现的。它提供了与文件保护key层次对应的key等级。只有一个数据库,一个叫securityd的安全守护进程决定哪一个keychain的项可以被哪个进程或应用访问。Keychain访问API要求调用securityd框架,securityd框架会查询应用的“keychain-access-groups” “application-identifier”授权。access groups允许Keychain的项在不同的应用之间共享数据。

    Keychain的项只能在同一开发者不同的应用之间共享数据。Keychain中的数据使用一种类似文件保护类class体系的结构来保护。这些类型的行为跟文件保护类型类似,但是有不同的keyAPI

    有效访问

    文件数据保护

    Keychain数据保护

    仅解锁时

    NSFileProtectionComplete

    kSecAttrAccessibleWhenUnlocked

    锁定时也能

    NSFileProtectionCompleteUnlessOpen

    N/A

    从第一次解锁后都能

    NSFileProtectionCompleteUntilFirstUserAuthentication

    kSecAttrAccessibleAfterFirstUnloc

    始终

    NSFileProtectionNone

    kSecAttrAccessibleAlways

    每个Keychain类型都有一个设备相关的对应物,它始终被UID保护,Keychain数据被备份出去时,无法用不同设备恢复备份去得到它们。

    iOS内置的一些Keychain项:

    可用

    Wi-Fi passwords

    从第一次解锁后都能

    Mail accounts

    从第一次解锁后都能

    Exchange accounts

    从第一次解锁后都能

    VPN certificates

    始终,不能移植到另一台设备(non-migratory

    VPN passwords

    从第一次解锁后都能

    LDAP, CalDAV, CardDAV

    从第一次解锁后都能

    iTunes backup

    始终,不能移植到另一台设备

    Voicemail

    始终

    Safari passwords

    仅解锁时

    Bluetooth keys

    始终,不能移植到另一台设备

    Apple Push Notification Service Token

    始终,不能移植到另一台设备

    iCloud certificates and private key

    始终,不能移植到另一台设备

    iMessage keys

    始终,不能移植到另一台设备

    Certificates and private keys installed by Configuration Profile

    始终,不能移植到另一台设备

    SIM PIN

    始终,不能移植到另一台设备

    2.2.5 keybags 密钥包

    文件和keychain的两种数据保护类型的key都通过密钥包存储和管理。iOS有四个密钥包:SystemBackupEscrowiCLoud Backup

    System密钥包,设备常用操作的加密后的class key存储在这里。如开机密码输入时,完全保护类型NSFileProtectionCompletekeySystem密钥包中拿出并解密。System密钥包是一个二进制的plist(属性\值列表)的存储文件,该文件保护类型为No Protection,但是文件内容被存储在Effaceable Storage中的一个 key加密。为了提供更高的安全,该key在每次用户修改开机密码是被抹除并重新生成。System密钥包是唯一一个存储在设备上的密钥包。AppleKeyStore核心扩展了System密钥包,不管设备是否锁定均能查询。只有所有的class key能够访问并解密成功设备才能解锁成功。

    Backup密钥包,当iTunes执行一个加密备份时被创建并被存储在执行设备备份的计算机上。一个新的密钥包创建时总是创建一组新的key,备份数据可以用这组新的key恢复备份。像前文解释,Backup密钥包的non-migratory的项通过一个UID驱动的key加密,因此允许设备恢复原先的备份中重新得到它们,但其他设备恢复该备份时无法解密这些项。

    该密钥包受iTunes上设置的密码保护。密码强度决定保护力度。

    如果用户选择不加密的iTunes备份,则备份文件不会被加密不管是什么数据保护类型,但是密钥包任然受一个UID驱动的key的保护。

    Escrow密钥包用于iTunes同步和移动设备管理(MDM)。该密钥包允许iTunes在不输入开机密码时备份和同步数据,它允许MDM服务远程清除用户开机密码。该密钥包保存在对设备执行iTunes同步或MDM服务的计算机上。

    iCloud Backup密钥包类似于Backup密钥包,iCloud备份能在后台执行。

    3. 网络安全

    iOS提供了大量的标准网络安全协议。iOS不像其他平台,它不需要防火墙,因为iOS限制了监听端口的数量,移除了一些不需要的网络应用,如telnetshellsweb server。通过使用iMessgeFaceTime和苹果推送提醒服务来通信,有完整的加密和认证。

    3.1  SSLTLS

    iOS支持SSL v3TLS v1.1TLSv1.2Safari、日程管理、邮件以及其他的因特网应用都自动使用这些机制以确保通信通道的安全。也提供API使得开发者很容易使用这些网络安全机制。

    3.2 VPN

    支持Cisco等多种协议和认证方法。很方便的在iOS设备上使用VPN

    3.3 Wi-Fi

    支持工业级的Wi-Fi协议,包括企业级WAP2

    3.4 蓝牙

    iOS 设备支持EncryptionMode 3 Security Mode 4Service Level 1 的连接。

    4. 设备访问

    iOS提供灵活的安全策略,配置方式容易实施和管理。这些使得企业能有效保护集团信息并确保员工适应企业需求,就算他们使用自己的设备。

    4.1 开机密码保护

    4.2 配置实施

    4.3 移动设备管理(MobileDevice Management MDM

    4.4 设备限制

    4.5 远程抹除


    参考:

    [0].原作《iOS Security》

    [1]. http://blog.xanahopper.com/tag/xnu/

    [2]. http://en.wikipedia.org/wiki/Cryptographic_nonce

    [3]. http://blogread.cn/it/article/3221?f=sr

    展开全文
  • iOS 线程安全

    2019-02-21 01:13:03
    iOS 线程安全 简介:  操作系统在进行多线程调度的时候,为了保证多线程安全引入了锁的机制,以实现指定代码或资源在某时间内只可以被有限个线程访问。这里主要介绍iOS开发中,使用Objective-C开发所用到...

    iOS 线程安全

    简介:

      操作系统在进行多线程调度的时候,为了保证多线程安全引入了锁的机制,以实现指定代码或资源在某时间内只可以被有限个线程访问。这里主要介绍iOS开发中,使用Objective-C开发所用到的几种锁的用法。

     

    1      iOS开发中常用的几种锁

    1.1       OSSpinLock 自旋锁

    1.2       pthread_mutex

    1.3       pthread_mutex(recursive)

    1.4       NSLock

    1.5       dispatch_semaphore

    1.6       NSCondition

    1.7       NSRecursiveLock

    1.8       NSConditionLock

    1.9       @synchronized

    以上为OC作iOS开发语言时常用到的锁,其中pthread_mutex和pthread_mutex(recursive) 是C语言实现的,来源于遵循POSIX标准的pthread多线程库。

     

    2       各个锁的特点和使用方法以及性能总结

    2.1     OSSpinLock(已被弃用)

    OSSpinLock 是一种自旋锁,也只有加锁,解锁,尝试加锁三个方法,其中尝试加锁是非线程阻塞的。可用通过 #import <libkern/OSAtomic.h> 引入并调用, 使用示例:

    OSSpinLock theLock = OS_SPINLOCK_INIT;

    OSSpinLockLock(&theLock);

    //要执行的代码

    OSSpinLockUnlock(&theLock);

    OSSpinLock 不再安全,主要原因发生在低优先级线程拿到锁时,高优先级线程进入忙等(busy-wait)状态,消耗大量 CPU 时间,从而导致低优先级线程拿不到 CPU 时间,也就无法完成任务并释放锁。进入优先级反转状态。

     

    2.2     pthread_mutex pthread_mutex(recursive)

    pthread_mutex表示互斥锁, 当锁被占用,而其他线程申请锁时,不是使用忙等,而是阻塞线程并睡眠。

    示例:

    pthread_mutexattr_t attr; 

    pthread_mutexattr_init(&attr); 

    pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_NORMAL);  // 定义锁的属性

    pthread_mutex_t mutex; 

    pthread_mutex_init(&mutex, &attr) // 创建锁

    pthread_mutex_lock(&mutex); // 申请锁 

    //线程安全区域

    pthread_mutex_unlock(&mutex); // 释放锁 

     

    pthread_mutex(recursive)是递归锁,也就是允许一个线程递归的申请锁,只要把 attr 的类型改成 PTHREAD_MUTEX_RECURSIVE 即可.

     

    2.3     NSLock

    NSLock 是OC以对象的形式暴露给开发者的一种锁,它的实现非常简单,通过宏,定义了 lock 方法:

    #define    MLOCK \

    - (void) lock\

    {\

      int err = pthread_mutex_lock(&_mutex);\

      // 错误处理 ……

    }

    NSLock 只是在内部封装了一个 pthread_mutex,属性为 PTHREAD_MUTEX_ERRORCHECK,它会损失一定性能换来错误提示。

    这里使用宏定义的原因是,OC 内部还有其他几种锁,他们的 lock 方法都是一模一样,仅仅是内部 pthread_mutex 互斥锁的类型不同。通过宏定义,可以简化方法的定义。

    NSLock 比 pthread_mutex 略慢的原因在于它需要经过方法调用,同时由于缓存的存在,多次方法调用不会对性能产生太大的影响。

    OSSpinLock 和 NSlock的比较

    NSLock 请求加锁失败的话,会先轮询,但一秒过后便会使线程进入 waiting 状态,等待唤醒。而 OSSpinLock 会一直轮询,等待时会消耗大量 CPU 资源,不适用于较长时间的任务。

     

    2.4     dispatch_semaphore

    dispatch_semaphore 是 GCD 使用信号量控制并发,相关的三个函数:

    1.创建信号量,

    2.等待信号

    3.发送信号

    dispatch_semaphore_create(long value); dispatch_semaphore_wait(dispatch_semaphore_t dsema, dispatch_time_t timeout);

    dispatch_semaphore_signal(dispatch_semaphore_t dsema);

     

    当设置信号量为 1 时,一个 dispatch_semaphore_wait(signal, overTime); 方法对应一个 dispatch_semaphore_signal(signal); 类似NSLock 的 lock 和 unlock,区别在于有信号量这个参数,lock unlock 只能同一时间,一个线程访问被保护的临界区,而如果 dispatch_semaphore 的信号量初始值为 x ,则可以有 x 个线程同时访问被保护的临界区,即可以控制多个线程并发。

     

    2.5     NSCondition 

    NSCondition 的底层是通过条件变量(condition variable) pthread_cond_t 来实现的。条件变量有点像信号量,提供了线程阻塞与信号机制,因此可以用来阻塞某个线程,并等待某个数据就绪,随后唤醒线程,比如常见的生产者-消费者模式。

    示例:

            NSCondition *lock = [[NSCondition alloc] init];

        //线程1

            [lock lock];

            [lock wait]; // 线程被挂起

            [lock unlock];

        //线程2

            sleep(1);//以保证让线程2的代码后执行

            [lock lock];

            [lock signal]; // 唤醒线程1

            [lock unlock];

     

    2.6     NSRecursiveLock

    递归锁也是通过 pthread_mutex_lock 函数来实现,在函数内部会判断锁的类型,如果显示是递归锁,就允许递归调用,仅仅将一个计数器加一,锁的释放过程也是同理。

    NSRecursiveLock 与 NSLock 的区别在于内部封装的 pthread_mutex_t 对象的类型不同,前者的类型为 PTHREAD_MUTEX_RECURSIVE。

     

    2.7     NSConditionLock

    NSConditionLock 可以称为条件锁,只有 condition 参数与初始化时候的 condition 相等,lock 才能正确进行加锁操作。而 unlockWithCondition: 并不是当 Condition 符合条件时才解锁,而是解锁之后,修改 Condition 的值。

     

    NSConditionLock 借助 NSCondition 来实现,它的本质就是一个生产者-消费者模型。“条件被满足”可以理解为生产者提供了新的内容。NSConditionLock 的内部持有一个 NSCondition 对象,以及 _condition_value 属性,在初始化时就会对这个属性进行赋值:

    // 简化版代码

    - (id) initWithCondition: (NSInteger)value {

        if (nil != (self = [super init])) {

            _condition = [NSCondition new]

            _condition_value = value;

        }

        return self;

    }

    它的 lockWhenCondition 方法其实就是消费者方法:

    - (void) lockWhenCondition: (NSInteger)value {

        [_condition lock];

        while (value != _condition_value) {

            [_condition wait];

        }

    }

    对应的 unlockWhenCondition 方法则是生产者,使用了 broadcast 方法通知了所有的消费者:

    - (void) unlockWithCondition: (NSInteger)value {

        _condition_value = value;

        [_condition broadcast];

        [_condition unlock];

    }

     

    2.8      @synchronized

    这其实是一个 OC 层面的锁,主要是通过牺牲性能换来语法上的简洁与可读。

    @synchronized 后面需要紧跟一个 OC 对象,它实际上是把这个对象当做锁的唯一标识。这是通过一个哈希表来记录表示,OC 在底层使用了一个互斥锁的数组(你可以理解为锁池),通过对对象去哈希值在数组中得到对应的互斥锁。

    示例:

    @synchronized(self) {

          //线程安全代码

    }

     

    3       性能对比

    下图通过加锁耗时简单的比较了各种锁的加解锁性能

     

     

     

    性能测试源码:

    https://github.com/ibireme/tmp/blob/master/iOSLockBenckmark/iOSLockBenckmark/ViewController.m

     

     

    附:重要概念

     

    1. 原子操作

    狭义上的原子操作表示一条不可打断的操作,也就是说线程在执行操作过程中,不会被操作系统挂起,而是一定会执行完。在单处理器环境下,一条汇编指令显然是原子操作,因为中断也要通过指令来实现。

    然而在多处理器的情况下,能够被多个处理器同时执行的操作任然算不上原子操作。因此,真正的原子操作必须由硬件提供支持,比如 x86 平台上如果在指令前面加上 “LOCK” 前缀,对应的机器码在执行时会把总线锁住,使得其他 CPU不能再执行相同操作,从而从硬件层面确保了操作的原子性。

    1. 线程管理

    现代操作系统在管理普通线程时,通常采用时间片轮转算法(Round Robin,简称 RR)。每个线程会被分配一段时间片(quantum),通常在 10-100 毫秒左右。当线程用完属于自己的时间片以后,就会被操作系统挂起,放入等待队列中,直到下一次被分配时间片。

     

    参考链接:

    iOS 常见知识点(三):Lock
    不再安全的 OSSpinLock

    深入理解 iOS 开发中的锁

     

    posted on 2018-03-01 11:55 DavidVactor 阅读(...) 评论(...) 编辑 收藏

    展开全文
  • 苹果设计的 iOS 平台向来是以安全为核心,此次白皮书大概讲了以下几个方面的安全: • 系统安全性:集成和安全的软件和硬件,是iPhone,iPad和iPod touch的平台。 • 加密和防护:如果设备丢失或被盗,或未经授权的...
  • 更多移动安全专题请见:http://mobile.51cto.com/hot-293442.htm 1. 接入WiFi 1.1 无线对等保密WEP(Wired Equivalent Privacy) WEP在链路层采用RC4对称加密技术,用户的加密密钥必须与AP的密钥相同时才能获准存取...
  • 设计模式之单例模式

    2020-01-23 15:17:17
    单例模式介绍1.1 应用场景1.2 单例模式实现案例1.3 常用写法2. 单例模式实现2.1 饿汉式2.2 饿汉式2.3 注册登记式2.4 枚举式3. 注意 1. 单例模式介绍 单例模式属于创建型模式。 1.1 应用场景 保证系统启动到终止一个...
  • iOS run loop详解

    2016-05-11 19:32:17
    一、线程与run loop 1.1 线程任务的类型 再来说说线程。有些线程执行的任务是一条直线,起点到终点;而另一些线程要干的活则是一个圆,不断循环,直到通过某种方式将它终止。直线线程如简单的Hello ...1.2 线
  • iOS项目架构总结

    2019-11-05 17:01:55
    本文参考了Casa Taloyum 的文章, 并总结一些博主自身的经验, 总结归纳了此文章.从四层架构:视图层、业务层、网络层、本地数据层的各个方面来进行的总结
  • 今天看到一个整理的比较齐全的iOS适配笔记。就转载记录一下。 转自掘金 一、iOS12(Xcode10) 1.1、升级Xcode10后项目报错 不允许多个info.plist Xcode10是默认选中的最新的New Build System(Default),在这个...
  • iOS移动开发从入门到精通》连载一: iOS移动开发现状 iOS是Apple公司推出的一款操作系统,是用于Apple移动设备的移动操作系统,和Apple的macOS操作系统一样,属于类Unix的商业操作系统 。在2007年1月9日的...
  • 有一阵子没写技术分享文了,最近每个月写一篇个人空间日记。主要是觉得自己技术比较一般写不出有质量的东西,误人子弟。互联网信息膨胀,让我们获取信息更加便捷,然而获取个人所需的正确信息,却需要每个人具备更强...
  • iOS9新特性

    2019-06-29 21:00:07
    iOS 9加入了更多的新功能,包括更加智能的Siri,新加入的省电模式iOS 9为开发者提供5000个全新的API。 1. 限制HTTP协议,全部改用更安全的HTTPS iOS9让所有的HTTP默认使用了HTTPS,原来的HTTP协议传输都改成TLS...
  • iOS9适配系列教程

    2019-09-26 19:24:11
    网址 :file:///Users/xiaomaomao/Desktop/iOS9AdaptationTips:README.md%20at%20master%20·%20ChenYilong:iOS9AdaptationTips%20·%20GitHub.webarchive For more infomation ,welcome to followmy twitter .....
  • 二是在ROM Monitor模式下的操作失误,往往会对路由器造成致命的伤害(比如破坏flash中的IOS文件,导致系统崩溃),以至于很多人对它束手束脚,望而却步。 其实,ROM Monitor并不复杂,它只是Cisco路由器...
  • iOS 9加入了更多的新功能,包括更加智能的Siri,新加入的省电模式iOS 9为开发者提供5000个全新的API。 1. 限制HTTP协议,全部改用更安全的HTTPS iOS9让所有的HTTP默认使用了HTTPS,原来的HTTP协议传输都改成TLS...
  • IOS9适配技巧(转)

    2016-05-24 13:35:54
    转http://www.cocoachina.com/ios/20150929/13598.html Demo1_iOS9网络适配_改用更安全的HTTPS ...采用TLS 1.2 协议,目的是 强制增强数据访问安全,而且 系统 Foundation 框架下的相关网络请求,将不再默
  • iOS9适配

    2015-09-23 13:26:43
    本文是投稿文章,作者:ChenYilong(https://github.com/ChenYilong/iOS9AdaptationTips) Demo1_iOS9网络适配_改用更安全的HTTPS ...采用TLS 1.2 协议,目的是 强制增强数据访问安全,而且 系统 Found
1 2 3 4 5 ... 20
收藏数 6,845
精华内容 2,738
关键字:

1.2进安全模式 ios