除了功能开发和错误修复之外,iOS开发人员还必须密切注意WWDC每年宣布的内容。 在发布的著名新SDK中,iOS开发人员需要进行一些更改以保持其应用程序与平台兼容。
随着Swift升级到版本4,以及iOS SDK本身的改进和更改,开发人员需要仔细检查更改并制定策略来更新其代码库。 所有这些都不会破坏它们的任何现有功能! 一切都取决于项目的优先级:要使您的应用与iOS 11兼容,您需要做的最低工作是什么? 您可以向项目涉众或项目经理提出最简单的情况是什么?
重要功能是第一位的,其次是iOS 11带来的不错但不是必需的改进,从优化应用程序到视觉美感,这些将进一步丰富应用程序的交互性和功能。 考虑到这一点,本教程将指导您逐步完成升级应用程序的步骤,并以务实的方式进行必要和可选的改进。
本教程的目标
本文将为您提供概述,以进行iOS 11应用更新,从架构更改到外观更改,以及App Store发布更改。 此外,本教程将组织各节,从所需的必要更改以及所需的范围和工作开始,到不错但不是必需的功能,这些功能将通过iOS 11增强您的应用程序。
在本教程中,我们将介绍以下内容:
- 为iOS 11准备您的应用程序(和您自己)
- 建筑变化
- App Store发布变更
- 使用者介面变更
假设知识
本教程假定您具有Swift或Objective-C和Xcode的中级知识,并且熟悉核心iOS SDK(例如UIKit和Core Foundation)。
建筑变化
与iOS的每次迭代一样,最重要的更改通常是体系结构更改。 在iOS 11中,这涉及到迁移到Swift 4,因此更新Xcode 9的构建设置将是我们要研究的第一项任务。
增量迁移到Swift 4
重要| 需要
对于去年不得不从Swift 2迁移到3的用户而言,该过程非常痛苦,并且许多更改破坏了现有的代码库。 幸运的是,从Swift 3.2迁移到4并不是这种情况,因为大多数机会被认为是加法的,而不是弃用的,因此Xcode 9迁移工具执行了令人钦佩的工作,将您的代码过渡到最新的Swift。
而且,与以前的版本不同,您不会被迫一次性升级到4。 也就是说,Xcode项目同时支持Swift 4和Swift 3.2,这意味着您可以在项目中使一个目标在Swift 3.2下进行编译,而在Swift 4中进行另一个编译。迁移工具将使您知道成功迁移了哪些类和函数。 ,哪些错误需要您手动干预才能解决,以错误或警告的形式。
这些错误意味着您将需要修复不向后兼容的内容,而许多警告将表明Swift 4中有一种新的方式来执行某些操作,例如更改新的API。 修复错误,并将上述警告作为单独的任务进行优先处理。
要访问迁移工具,请转至Xcode中的“ 编辑”>“转换”>“转换为当前Swift语法” ,然后按照提示进行操作,在此阶段选择要迁移的目标。
迁移工具将让您知道重新编译应用程序所需的最少工作,因此,建议的最佳实践是逐步将应用程序从3迁移到4,这不足为奇。在大型项目中,逐个目标测试和转换。 您不必一次迁移所有内容,并且可以分阶段,在何时何地计划迁移路径。
接下来,我们将快速了解一下Swift 4中的哪些变化不是强制实施的,但应了解。
32位架构弃用
重要| 需要
iOS 11的另一个主要变化是,由于不再支持32位应用程序,因此App Store中的所有应用程序现在都必须为64位,事实上,甚至在运行iOS 11的设备上也无法使用。 Apple一直警告开发人员已经有一段时间了,这不足为奇,但是如果您的应用仍未进行过渡,则可以遵循Apple关于将您的应用转换为64位Binary的准则。
Swift 4的新功能
不重要| 可选的
除了使目标成为Swift 4兼容所需的强制性工作之外,您还可以选择重构现有代码以利用新的Swift API更改,这些更改根据以下API级别的改进而细分:
弦乐
在Swift 4中,String受到了很多关注,最显着的变化是回溯到Swift 1.0,在该版本中,再次将String定义为集合,因此您可以使用一个字符逐个字符( SE-0163 )遍历String对象。 for循环。 Strings类的其他显着更改包括:
馆藏
作为集合的一部分,字典和集合在Swift 4中也进行了改进,从过滤字典开始,到现在为止返回了由键/值对组成的元组数组。 要访问特定元素,可以使用以下下标,如数组中所示:
listOfCars[4].value
在Swift 4中,您取而代之的是返回字典,提供了更一致的语法,随后,您像访问普通字典一样访问返回的字典。 现在,对于map()
函数也会发生同样的情况,您还可以在其中返回一个字典。 字典访问下标的新功能,可以在键不存在的情况下提供默认值,从而使代码更安全。
let tomTheCat = animal[“name", default: “id”]
集合的其余更改包括:
- SE-0148通用下标
- SE-0154提供字典键和值的自定义集合
- SE-0165词典和集的增强功能
- SE-0172单面范围
- SE-0173添加
MutableCollection.swapAt(_:_:)
其他值得注意的变化
最后,作为此版本的一部分,与该语言有关的其他变化值得一提:
- SE-0104面向协议的整数
- SE-0142允许where子句约束关联类型
- SE-0156类和子类型存在
- SE-0160限制@objc推断
- SE-0164删除协议扩展中的最终支持
- SE-0169改善私有声明和扩展之间的交互
您可以在 Swift.org上 找到详尽的更改列表和原始建议 。
App Store发布变更
App Store的iOS 11用户可能已经注意到,它正在采用全新的设计以及全新的部分,从而为开发人员提供了新的方式来推广自己的应用程序并与用户进行交流。
我们将首先查看新的营销图标,现在需要将其与应用程序更新一起上传。
营销图标
强制性| 更高的优先级
从iOS 11开始,对于任何新提交的内容,无论您的应用是新应用还是现有应用,您都需要添加icon-1024.png(大小为1024x1024的营销图标)。 十分方便,您无需通过iTunes Connect提交图标,而只需通过Xcode, 转到Images.xcassets并添加适当大小的图像,就像管理其他图标的方式一样:
营销图标用作新的App Store设计过程的一部分,以在“今日”部分或放大了应用程序图形的其他部分中显示代表您的应用程序的较大图像图标。
促进应用内购买
可选| 低优先级
苹果使应用内购买过程更加突出和透明,允许用户直接通过与应用产品展示相同的级别查看所有应用内购买选项,实际上,甚至可以针对应用内购买发起应用内购买应用程序,同时下载实际的应用程序。 考虑一个订阅应用程序,下载您的应用程序的用户可能已经在其中购买了他们的订阅。 iOS 11使此操作更快,更方便。
从iOS 11开始,开发人员可以在其应用程序的产品页面上宣传多达20种应用程序内购买,例如订阅。 这些购买选项也将出现在搜索结果中。
促进应用内购买也可以鼓励您下载应用。 如果用户未安装您的应用程序,但想购买促销的应用程序内购买商品,则他们会收到提示,要求您首先下载该应用程序。 下载应用程序后,交易将继续在应用程序中进行。 ( 苹果 )
为了提高应用程序内购买促销的可见性,您需要在iTunes Connect中包括以下元数据:
- 图片:这是代表您的应用内购买的独特促销图片,显示在App Store产品页面,“今日”,“游戏”和“应用”标签以及其他突出区域中。 它不应包含屏幕截图或代表您应用的图标,而应代表应用内购买的功能。 图像还应该为PNG格式,并且具有1024 x 1024的高质量图像。
- 名称:应用内购买商品的显示名称,最多30个字符。 这应该是特定的,以适合特定的应用内购买功能。 如果是订阅,请说出来,并确保订阅的持续时间包含在标题中,例如“一个月的全部访问订阅”。
- 说明:长度为45个字符,说明为用户提供了上下文,供用户理解和欣赏您特定应用内产品的好处。
有关推广应用内购买的更多信息,请参阅 Apple的官方指南 以及Apple的 Product Page指南 。
与客户沟通
可选| 低优先级
可以直接响应用户评论的功能肯定已经过期了,并且Android开发人员已经享受了很长一段时间。 从iOS 11开始,开发人员现在还可以直接回复用户的评论和评论。 尽管这不需要任何技术上的更改,并且参与是可选的,但开发人员可以通过iTunes Connect( 应用程序 > 活动 > 评分 )来回应赞美和批评。
通过显示正在审查和响应他们的反馈意见,并积极听取他们提出的问题,可以利用个性化的开发人员响应来建立更牢固和更亲密的关系,促进更深入的参与。 要回复评论,只需转到iTunes Connect,即可在其中查看反馈并单独回复。
除了新的开发人员评论功能外,Apple还提供了新的形式化SDK,以提示用户对应用程序进行评分和评论。 应该使用新的SKStoreReviewController
代替任何第三方或用户手动提示进行评论,因为Apple希望操作系统能够控制提示的频率及其外观。 因此,Apple将在365天的时间内将提示限制为不超过三次。
要实现SKStoreReviewController
,只需导入StoreKit并调用requestReview()
,如下所示:
...
import StoreKit
...
SKStoreReviewController.requestReview()
...
尽管Apple尚未完全禁止其他提示用户反馈的方法,但希望这种情况在不久的将来会改变,因此最好开始考虑在明年实现Apple的即时审核引擎。
增量部署
可选| 低优先级
iOS 11给开发人员带来的另一个非常有用的功能是能够逐步向用户发布其应用程序。 苹果将其称为分阶段发布,其目的是降低生产环境一次过载的风险,而不是在7天的时间内发布更新。
在iTunes Connect的“ 版本发行”下,有一个名为“自动更新的分阶段发行”的新部分,它使您可以选择立即发行还是在7天的期限内发行。 开发人员还可以将分阶段推出的过程最多暂停30天,如果发现并报告了主要问题,通常会发生这种情况。
分阶段推出不会阻止用户从App Store手动获取更新,而是针对使用App Store中的iOS自动下载设置的用户。
接下来,让我们看一下iOS 11中引入的视觉变化,我们将讨论重要主题和次要主题。
用户界面更改
在查看了iOS 11的体系结构以及应用商店发布的更改之后,我们现在就可以剖析外观更改,并帮助您确定应该首先解决哪些UI更改的优先级。
重要的是,虽然我们当然可以在不执行本节中的任何更改的情况下构建iOS应用程序,仅解决体系结构和App Store的更改,但您可能首先要确保您的应用程序在视觉上支持新的iPhoneX。这意味着对导航栏,以解决顶部的新物理“缺口”。
考虑到这一点,我们将首先考虑更新您的iPhone X用户界面,然后进行其他一些快速更改,以确保您的应用程序看起来是现代的和最新的。
为iPhone X更新UI
强制性| 更高的优先级
更新iOS应用程序中最重要的任务之一是确保在不破坏以前的设备支持的情况下,确保应用程序在新设备上看起来良好且运行良好。 这就是为什么苹果一直努力为开发人员提供诸如自动版面设计之类的工具来设计与屏幕无关的版面的原因,无论是iPhone 4、5C还是6和6 Plus。 从今年开始,我们现在拥有的手机不仅具有新的尺寸,而且在顶部还具有物理缺口。
请注意,我们不再具有矩形视口,并且物理传感器的顶部具有新的缺口,Apple建议您如何处理呢? 一方面,Apple不想让您在顶部放置黑条以隐藏缺口! 相反,他们提倡开发人员接受它。
不要掩盖或特别注意关键的显示功能。 请勿尝试通过在屏幕顶部和底部放置黑条来隐藏设备的圆角,传感器外壳或用于访问主屏幕的指示器。 也不要使用括号,边框,形状或说明文字之类的视觉装饰来引起对这些区域的特别注意。 ( iOS人机界面指南 )
您需要进行全屏体验设计,利用新设备的无边框设计,同时不使设备的圆角或传感器外壳(缺口)遮盖用户界面的一部分。
好消息是,Apple的UIKit提供的系统提供的UI元素(如UINavigationBar
已经符合并适应了开箱即用的新设计要求。 但是,对于任何自定义UI元素,您都需要自己进行一致性工作。
查看iPhone 4.7与上面的新iPhone X相比的图像,您会注意到状态栏现在的实现方式有所不同,从其高度开始,高度从iPhone X上的20 pt增长到了44 pt。
苹果公司建议那些一直隐藏状态栏的应用程序开发人员应根据iPhone X重新考虑该决定,并且仅将其隐藏在横向模式下,而不是纵向模式下。
最后,通过利用“自动版式”作为主要措施来使用“ 安全区域版式指南” ,以确保您的应用适合其适当的空白,并确保没有视觉障碍,例如重叠状态栏或导航栏。
以下WWDC视频有两个很好的资源可帮助您开始设计iPhone X:
实施拖放
可选| 低优先级
拖放是今年WWDC上讨论最多的新SDK之一。 这是台式机用户已经习惯了很长时间的事情,但是iOS平台中缺少它,意味着iPad和iPhone从未真正采用多任务处理。 在iOS 11中,情况有所改变,因为新的iOS将不仅支持将UI元素拖动到同一屏幕内,而且还可以将UI元素从一个应用程序拖动到另一个应用程序。
利用iOS的多点触摸引擎,用户可以通过点击并按住图像,文件,文本或特定的UI元素来拖动,从而轻松自然地在iPad上的应用程序之间移动内容(或仅在iPhone的同一屏幕内)。它。 它已经集成在iOS的系统范围内,例如,允许用户将Safari中的文本拖到扩展坞的Reminders应用程序中,以创建新的提醒项。
尚未将其标记为强制实施,但是由于它在系统范围内的普遍性将很快成为一种预期的行为,因此建议您尽早对此进行优先级划分,以便使应用的UX符合新的标准系统UX行为。
UIKit内置了对UITables
和UICollectionViews
组件的某种程度的拖放支持,但是您将需要使用代码来桥接和调整元素,以便其他组件可以接收被拖动的组件。 可能涉及到一些问题,这不在本文的讨论范围之内,但是我将在下周的后续文章中更全面地介绍拖放支持。
现在,简要地说,您将通过实现以下所示的两个委托,在ViewController
的viewDidLoad()
方法中添加并支持拖放操作:
class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, UITableViewDropDelegate, UITableViewDragDelegate {
...
func viewDidLoad(){
...
firstTableView.dragDelegate = self // You associate the drag delegate to this table
secondTableView.dropDelegate = self // You associate the drop delegate to this table
firstTableView.dropDelegate = self
secondTableView.dragDelegate = self
firstTableView.dragInteractionEnabled = true
secondTableView.dragInteractionEnabled = true
...
}
...
func tableView(_ tableView: UITableView, itemsForBeginning session: UIDragSession, at indexPath: IndexPath) -> [UIDragItem] {
//(1) Drag is being initiated
}
func tableView(_ tableView: UITableView, performDropWith coordinator: UITableViewDropCoordinator) {
//(2) Drop is being initiated
}
请继续关注我们即将发布的有关如何向iOS 11应用添加拖放支持的文章。
其他UIKit和自动布局更改
可选| 低优先级
最后,让我们看一下iOS 11剩余的UIKit更改,从UINavigationBar
开始,它具有一些显着的改进,包括SearchViewController
和大标题的集成。 然后,我们来看看UITableView
的改进,从新的和改进的滑动操作到自动调整大小的表格视图单元格。
导航
在讨论iPhone X以及它如何与新的状态栏尺寸对齐时,我们已经在前面提到了导航栏。 除此之外,iOS所倡导的新的现代设计风格包括导航栏中的新较大标题,该标题最初出现在iOS 10的Apple Music App中,此后便在iOS的所有其他系统应用程序中确立了设计模式。
较大的标题文本会更加强调导航栏中屏幕的上下文,并有助于在导航各个选项卡时将用户定向到活动选项卡。 标题文本的大小不是静态的,而是随着用户向下滚动而缩小,还原为iOS 11之前的样式。 相反,当您向下滚动视图时,标题文本将略有增加。
当您需要特别强调上下文时,请使用大标题。 在某些应用中,大标题的粗体文本可以帮助人们在浏览和搜索时进行定向。 例如,在选项卡式布局中,大标题可以帮助澄清活动的选项卡并在滚动到顶部时通知用户。 Phone使用这种方法,而Music使用大标题来区分内容区域,例如专辑,艺术家,播放列表和广播。 当用户开始滚动内容时,大标题将转换为标准标题。 大标题并非在所有应用程序中都有意义,因此永远都不应与内容竞争。 尽管“时钟”应用程序具有选项卡式布局,但由于每个选项卡具有独特的,可识别的布局,因此不需要大标题。 ( iOS人机界面指南 )
作为开发人员,您可以根据Apple的《 人机界面指南》来决定是否以及何时实施大字体样式,Apple建议您仅将大字体标题仅用于顶层导航屏幕,而不应跨所有级别使用。 要启用大文本,只需将以下属性添加到您的UINavigationController
:
navigationController?.navigationBar.prefersLargeTitles = true
从层次结构上,由于父级继承,导航栏下的主视图和详细视图控制器默认情况下都将启用大文本模式,并且如上所述,建议仅使顶级导航屏幕实现大文本模式。 要在详细信息屏幕中取消大文本继承,请转到视图控制器,然后将以下内容添加到其初始化程序中(必须在初始化时进行设置):
required init?(coder aDecoder: NSCoder) {
super.init(coder: aDecoder)
navigationItem.largeTitleDisplayMode = .never
}
上面的largeTitleDisplayMode
设置为.never
。 如果没有该行,则默认值为.automatic
,这是细节视图控制器继承其父视图控制器的属性的位置。
搜索视图控制器
现在可以将搜索直接集成到导航栏中,而无需将UISearchViewController
实例与主题视图控制器(及其表标题视图)分别关联。 从iOS 11开始,您可以在搜索栏中优雅地嵌入搜索栏:
navigationItem.searchController = UISearchController(searchResultsController: nil)
当然,您还需要遵守UISearchResultsUpdating
才能对搜索词做出反应。 iOS会根据表格视图中的行数自动隐藏搜索栏,但您可以通过以下方式强制搜索栏始终处于可见状态:
navigationItem.hidesSearchBarWhenScrolling = false
UITableViews
最后,我们看一下自iOS 11起UITableViews
引入的两个新的独特功能:自动调整大小和改进的滑动操作。 自调整大小是在iOS 8中引入的,以减轻开发人员必须手动调整表格视图单元格的负担,并具有使用自动布局动态调整单元格大小以适合行内容的能力。 到目前为止,您必须使用以下命令显式请求自动调整大小:
tableView.rowHeight = UITableViewAutomaticDimension
tableView.estimatedRowHeight = 100
从iOS 11开始,默认情况下它处于打开状态且未设置任何额外代码,但是您仍然可以根据需要显式指定自己的行高。 iOS 11还带来了新的前导和尾随滑动操作,在许多系统应用程序(例如苹果自己的Mail应用程序)中很普遍。
除了能够向左或向右滑动外,您还可以附加图像以与这些操作关联。 您将两个委托方法作为UIContextualAction
一部分UIContextualAction
,以进行前导和尾随滑动操作:
override func tableView(_ tableView: UITableView, leadingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration? {
let trash = UIContextualAction(style: .normal, title: "Delete") { action, view, completionHandler in
print("Delete")
completionHandler(true)
}
delete.backgroundColor = UIColor.red
delete.image = UIImage(named: "delete")
let actionGroup = UISwipeActionsConfiguration(actions: [delete])
actionGroup.performsFirstActionWithFullSwipe = false
return actionGroup
}
..
override func tableView(_ tableView: UITableView, leadingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration? {
let archive = UIContextualAction(style: .normal, title: "Archive") { action, view, completionHandler in
print("Read")
completionHandler(true)
}
archive.backgroundColor = blue
archive.image = UIImage(named: "archive")
let move = UIContextualAction(style: .normal, title: "Move") { action, view, completionHandler in
print("Move")
completionHandler(true)
}
move.backgroundColor = purple
move.image = UIImage(named: "move")
let actionGroup = UISwipeActionsConfiguration(actions: [archive,move])
actionGroup.performsFirstActionWithFullSwipe = false
return actionGroup
}
使用上面的代码,您可以创建多个上下文操作,并将其添加到UISwipeActionsConfiguration
分组实例中,以进行多个操作。 这是一个简单但引人入胜的改进,可以以最小的代码更改为表视图带来更大的弹性,虽然不是强制性的,但值得在sprint计划委员会中分配几个小时的时间。
结论
在本文中,我概述了iOS 11的体系结构,App Store和可视化组件的变化,使您了解了需要立即采取的措施以及可以推迟到以后执行的措施。时间。 迁移到iOS 11和Swift 4将比前几年的更新要容易得多。
除了需要进行的迫在眉睫的更改之外,我们还经历了Swift 4更改,这些更改改进了字符串和集合,并对UITableView
和Search Controller进行了可视化改进。 这应该使您更轻松地计划工作以对应用程序进行更新!
翻译自: https://code.tutsplus.com/tutorials/updating-your-app-for-ios-11--cms-29653