去年的 WWDC 2019 举行前夕，我在少数派发表了一篇文章，阐述了我对 iOS 13 的 10 个期待，虽说到目前为止没有几个能实现，但希望也还是有的，例如其中的「允许添加小组件到桌面」这一点，据网上透露的消息，有可能出现在今年的 iOS 14 中，这也说得上是一个大好消息了。
转眼间一年过去，WWDC 2020 也即将到来，历经了一年的系统更迭，我们对 iOS 也一定有了新的体验，同时不可避免也有一些新的需求。如今网络上对于 iOS 14 的消息依旧层出不穷，诸如以悬浮卡片显示的来电、通话过程可以录音等等的传闻，都吸引着大家的眼球，使人们对 iOS 14 更加充满期待。
在跟去年提出的 10 个期待不重复的前提下，我决定承接去年的做法，在今年也以 iOS 13.5.1 为例和大家说一说，我个人对于 iOS 14 的 10 个期待：
不知读者们有没有这样的需求，就是要把系统相册里的一堆相片，保存到其它 App 里，然后回到系统相册里删除它们。我们的一般操作都会是在系统相册中点击右上角的「选择」，然后勾选出你需要保存到其他 App 的相片，再点击左下角的分享菜单，点击相应的 App，把相片保存进去。
接下来画面回到系统相册，我们下一步当然是想把刚才勾选的相片从系统相册里删除，但是问题却来了，我们发现之前勾选的相片，没有了我们打上去的标记，意味着系统在你点击分享菜单进行操作后，已经不再为你记住你所勾选的相片，
也就是说，当我们把勾选的相片保存到其他 App 后，又想删掉原先保存在系统相册里的相同相片的话，则必须把这些相片重新勾选一次。但如果所选的相片数量比较多的话，再选一次实在太容易造成无辜相片被误删了，而且有时候勾选的相片还是不连续的，中间间隔了好几张或好几行，要重新判断哪些相片应该勾选时，就太考验用户的记忆力了，往往会无意中删除了别的相片，或者漏删了该删的相片。
这显然不是一个人性化的安排，用户勾选相片来进行了一次操作后，针对相同的相片，要重新勾选一次才能继续下一步操作，不但造成用户的操作繁琐，而且也不利于效率的提升。
希望在 iOS 14 中， Apple 能针对这个问题作出一些改进，例如在分享菜单中提供「存储到文件并删除」的选项，或者干脆在用户把相片存储到其他 App 后，仍然保留用户勾选的相片，方便用户继续操作，如果用户已经没有下一步操作了，那点一下「取消」也不是什么难事，总比重新选一遍要好。
虽然 iOS 在输入文字的时候支持很多非常便捷的手势操作，例如直接在自带键盘上按压，可以快速控制光标移动；在一段文字上按压并拖动，可以快速用光标选定该段文字等等，但是当涉及到在双引号内粘贴内容的时候，一个很不 Apple 的奇怪问题就出现了：光标总会移向双引号的左侧或右侧。
众所周知，不像 macOS 或 Windows 可以用快捷键来复制粘贴，iOS 原生只能通过点按光标，触发光标上方出现的菜单来进行操作。因为必须先点一下光标，所以系统如何判断光标的位置就显得很重要了。当手指触碰光标的时候，用户有可能是想把光标移动，也有可能只是想触发菜单，在没有双引号的情况下，iOS 都能正确地判断用户的操作，不过一旦要把内容粘贴进双引号内，就会出现判断失误，原本在双引号内的光标，一旦被点击，在很多时候不但不会弹出菜单，而且还会跳到双引号的外面，需要用户不断尝试把光标拖回双引号内，在进行多次尝试之后，才有机会成功在双引号内触发菜单进行粘贴，使原本简单的复制粘贴操作变得非常复杂。
虽然这或许并不是什么大问题，但是在需要粘贴文字到双引号内却屡不成功的时候，倒是有一种系统在犯低级错误的感觉，希望在即将面世的 iOS 14 系统中，能对这个细节上的小问题作出一些优化，相信会对改善用户的体验有莫大的帮助。
虽然标题是这么写，但是我心里的想法是，如果能支持一键关闭所有通知就完美了。
但我还是选择折衷一下，不写一键关闭所有通知，而只是写一键关闭所有横幅，其原因是因为 iOS 中其实已经有一些效果不错的方法，用以对付那些扰人的通知了。
例如勿扰模式，只要开启了勿扰模式，所有的通知甚至来电都会变为静音。
又如 「设置 → 通知」 里的 「显示预览」 功能，可以控制横幅是否显示通知内容，若设为 「从不」 ，则弹出来的横幅只会显示 「xx，1个通知」 。
但是即便如此，横幅依然会在你阅读、看视频、玩游戏的时候弹出来，分散你的注意力，甚至当你正在进行屏幕录制的时候频繁弹出，简直让人抓狂。如果你想取消所有软件的横幅推送，你必须进入设置，一个一个 App 点进去关闭横幅。
如果在 iOS 14 中，能够增加进一步控制横幅推送的方法，在现有 「显示预览」 的基础上，允许用户直接一键关闭所有横幅推送，直到有需要的时候，再通过一键开启，来恢复横幅推送到之前的状态，那么不但能使功能更加完善，而且也更能满足用户在不同场景之下的需求。
隔空投送的方便之处在于它能快速在多台 Apple 设备之间分享文件，但有待改进的地方在于它并没有提供文件收发记录，以及一些文件关联问题。
目前，我们无法查看曾经使用隔空投送发送或接收文件的记录，更无法查看那些文件是从谁的设备发过来的。
另外，当我们接收到诸如 .mkv、.docx等文件时，系统会询问我们保存到哪个 App，但当我们接收到图片或 .mp4 、.mov文件时，系统则会直接把它们放入相册，不过，如果你接收到一个 .torrent 文件的话，比较奇葩的现象就出现了，系统会直接调用 「迅雷beta」 来打开它，而且你似乎只能马上下载，不能先保存在手机里。
可见隔空投送对于不同种类的文件，都有不一样的处理方法，加上缺乏文件收发记录，使隔空投送显得有些美中不足。
在 MacOS 中，凡是通过隔空投送接收的文件，都会默认放在 「访达」 的 「下载」 目录里，这个目录充当了一个收件箱的作用。其实在接收文件的时候，我们应该先不必考虑把文件保存到哪里，而是先采用收件箱集中放好，在明确了文件的性质后，再逐一把收件箱里的文件进行分类保存也不迟，正如主流待办清单应用都标配收件箱一样。
在接下来的 iOS 14 中， Apple 也不妨参照这个模式来改进一下隔空投送功能。例如允许用户在设置里改变隔空投送规则，可以选择将所有接收到的文件统一保存在 File App 里的 「下载项」 中，同时也应该允许用户设置一些例外情况，如「所有接收到的文件均保存至下载项，但如果遇到 .docx 文件则拷贝到 WPS」。
至于收发文件记录，可以考虑在 「设置 → 通用 → 隔空投送」 中显示，除了显示文件名称之外，也应显示该文件来自哪个设备，以及允许用户在此界面直接跳转至文件保存位置。
如果在 iOS 14 中，真的能对隔空投送作出上述优化的话，那简直就像是为它赋予了生命，不但使功能更加完善，相信也更能博得用户的喜爱。
Files App 把手机上几乎所有云服务里的文件都归于一处，单从这一点来说，是挺让人一目了然的。而我们使用云服务存储文件的其中一个重要目的，就是让这些文件能够在所有设备上均保持最新，而且在一个设备上作出修改，能立即同步到其他设备上，但当你想在 iOS 设备上直接用 Files App 修改一篇存储在云端的文稿时，你却发现效果未如理想。
以坚果云为例，我们在 MacOS 或 Windows 端打开同步文件夹里的一篇 docx 文档，系统自然便会调用相对应的文字处理软件来打开，例如 Word ，当你修改完文档后，保存并关闭 Word ，坚果云就会自动同步，而如果你不想使用 Word ，可以在 Windows 的属性或 MacOS 的 「显示简介」 里修改关联，例如改成使用 WPS 打开。换句话说，它既能够让你选择合适的软件打开，又能无缝同步到云端。
我们感觉这应该是很正常的一件事。
但回到 iOS 后，上述的情景貌似就实现不了了，在 Files App 中的坚果云里，打开任意一个 docx 或 xlsx 文件时，你会发现 iOS 并不会调用你手机上的 WPS 来打开这些文件，也不会询问你想要的打开方式，而似乎是直接在 Files App 内打开，显示出来的是一个非常简陋的界面，而且你无法修改文档中的任何内容。
如果你的 iPhone 装有微软的 Office App 的话，打开 docx 或 xlsx 文件时则是可以调用 Office App 来打开，虽然如此，但是由 Office App 打开后的文件，仍会出现 「只读 - 无法将更改保存到此文件」 的提示。
如果要想实现 iOS 端修改再同步要怎么办呢？恐怕只有先把文件共享到 WPS ，用 WPS 修改好文档后，先保存到 WPS 里，再共享回去 File App ，位置选择坚果云，然后一层一层地进入到这个文档原来所在的坚果云路径，只有这样，坚果云才会把新的文件覆盖旧的文件，实现「无缝」同步。
这样做不仅需要用户记得该文件保存在坚果云的什么路径，而且还会在 WPS 留下一个副本，加上操作相当繁琐，过程非常容易出错。
所以在 iOS 14 中， Apple 应该要加强对第三方软件文件关联的支持，让第三方软件能够充分参与到 Files App 当中去，不但要允许用户自由选择文件的打开方式，而且要让第三方 App 不再局限于只读 Files App 内的文档，而是要能直接修改文档内容，只有使用户能够借助第三方软件，轻易地对 Files App 的云文档作出改动，并立即实现同步，才能让 iOS ，尤其是 iPadOS 的效率更上一层楼。
六、Safari 书签支持多选
Safari 是我在手机上最常用的浏览器，没有之一，几乎所有需要在手机浏览的网页，都被我添加到了 Safari 的书签中，久而久之，整理书签便是必不可少的操作。在整理书签时，最常见的一个方法是，把性质相似的若干个书签归纳到一个文件夹里。
然而在目前版本的 Safari 中，你无法选择多个书签并把它们移动到一个文件夹，只能在书签界面选择右下角的 「编辑」 后，逐个逐个书签点开，在 「位置」 下选择相应的文件夹。
而且不仅 iOS 端如此，iPadOS 也是如此，iPadOS 虽然可以在拖动书签的时候选择多个书签，但是仍无法将它们拖动至文件夹内。
希望 Apple 在开发 iOS 14 的过程中，除了为 Safari 注入新功能之外，也能解决一下上述提到的问题，这将使用户整理书签变得一气呵成，并且就算是整理大量书签，也不见得是一件繁琐的事。
前段时间，一位朋友来问我，别人家的 iPhone XS 只要一拿起手机就能显示锁屏界面，是怎么做到的？这其实就是 iOS 的 「抬起唤醒」 功能，只要进入 「设置 → 显示与亮度 → 抬起唤醒」 就能开启或关闭该功能。
过了几天，另一位朋友来问我，他说看见人家的 iPhone 只要点一下屏幕，就能显示锁屏界面，而他的 iPhone 必须按一下侧边按钮，该怎么弄才能和别人一样？这就涉及到另一个 「唤醒」 ——「轻点唤醒」 了。只要进入 「设置 → 辅助功能 → 触控 → 轻点唤醒」 打开开关后，就可以跟别人的一样了。
朋友感到疑惑，同样是唤醒功能的开关，一个在 「设置 → 显示与亮度」 里，另一个却在 「设置 → 辅助功能 → 触控」 里，难免让人觉得有点无所适从。
其实在设置里，与之相关的功能还有一个，就是 「需要注视以启用面容ID」 ，它藏在 「设置 → 辅助功能 → 面容 ID 与注视 → 需要注视以启用面容 ID 」 ，如果对这些设置不是比较熟悉的话，查找起来还是比较费心的。
虽然设置里有搜索功能，但并不是每个用户都能记得住这些功能的正确名字，如果名字本身记不清，单靠搜索也是不一定能准确找到目标的，倒不如在 iOS 14 中重新排列一下这几项设置的分布，给它们一个更合理的归宿，或许能使用户更容易地使用它们。
随着 iCloud 的文件夹共享功能在 iOS 13.4 中回归，正如少数派的一篇文章介绍所言，你已完全可以将 iCloud Drive 当作一个具有在线分享功能的网盘来使用。 但是，在这个具有在线分享功能的网盘中，仍有一些美中不足的地方需要加以改进。
在 iOS 的 iCloud 中，我们可以通过按压文件，点击 「共享」 ，选择 「添加成员」 的方式与其他用户分享文件，被分享的文件都会在文件名下方显示 「由我共享」 四个字，提示用户这个文件是自己分享出去的。
但随着我们日复一日的使用，iCloud 中的文件只会越来越多，与人共享的文件也会越来越多，当我们有一天突然想到，之前与人共享过的一些文件如今已经不需要再共享的时候，我们就很需要 iCloud 提供一个列表，显示所有处于共享状态的文件。
而遗憾的是，现阶段的 iCloud 并没有这个功能，无论你使用的是 iOS 版、Mac 版，还是网页版的 iCloud ，要想查看有哪些文件处于共享状态，都必须进入到每一个文件夹中，根据文件名下方有没有 「由我共享」 的标识来判断这是不是一个处于共享状态的文件。
如果你想要取消分享的文件分布在不同的文件夹中，而你的 iCloud 又拥有大量文件的话，想要仅找到那些已经共享的文件，难免会有一种大海捞针的感觉。
其实在这方面，建议 Apple 参考一些第三方网盘的做法，以百度网盘为例，其网页版的左侧菜单有一个 「我的分享」 选项，里面不仅列出所有已经分享出去的文件，而且还有文件的浏览次数、保存次数等信息，如果用户想取消分享，也可以直接在这个界面取消多个文件的分享。
希望 Apple 能够在更迭 iOS 系统的同时，也考虑到 iCloud 的部分功能仍有待完善。期待在 iOS 14 中打开 iCloud 时，能够看到其对已共享的文件有更清晰的分类，只需选择一个菜单，就可以方便地筛选出所有已经分享的文件，并且能对它们进行取消分享等操作。
记得我第一次使用 iOS 的听写时，简直是感到喜出望外，它可以把我说的话转换成文字，对于不方便发语音但又不想打那么多字的时候，听写功能就显得非常有帮助。
但是熟悉听写功能的用户都应该有所了解的是，它并不能识别你说话的断句位置，然后在该处自动加上相应的标点符号，你需要在一句话说完后，说出 「逗号」 、 「句号」 或 「问号」 来为语句添上标点符号，特别是 「逗号」 两个字，如果你没有喊出 「逗号」 的习惯，那你生成的就只有一大堆没有标点的文字。
再看 App Store 中许多热门的第三方输入法的语音输入功能，基本上不需要用户说出标点符号的名称，你只要在断句停顿一下，它就会自动输入标点符号。
然而不同的输入法有不同的使用体验，很难说用某个输入法可以完全取代系统原生的输入法，而对于原生输入法中的不足之处， Apple 也应该随着系统的升级而将其改善，期待在 iOS 14 系统中，会有更好的听写体验。
相信很多用户在使用 Apple Music 的过程中，都会经常使用到 「插播」 和 「最后播放」 这两个功能，前者可以将歌曲插入待播清单的最前面，让其在下一首播放；后者则是将歌曲放到待播清单的最后面，它将会在待播清单中原有的歌曲播放完毕后才开始播放。
当我在听歌这事儿上出现选择困难的时候，我往往会从资料库中随便打开一首歌，然后转到 「为你推荐」 界面，一边浏览系统为我推荐的内容，一边把认为值得一听的歌曲用 「插播」 或 「最后播放」 添加到待播清单中，久而久之，待播清单中已经有相当数量的歌曲，这个时候我的想法是，明天通勤的时候，就按这个顺序来播放音乐吧！
为了避免因杀后台或听其他歌曲而造成的待播清单丢失，最好的办法就是把当前的待播清单原原本本地复制成一个播放列表。但是，在目前的版本中，你并不能把待播清单里的所有歌曲直接添加到播放列表，而是需要一首一首地添加，而所谓的一首一首添加，并不是说你可以在待播清单里进行多选，而是你必须在待播清单界面按压歌曲名称，在弹出来的菜单中选择 「添加到播放列表」 ，然后如此类推重复这个步骤。
这个过程简直让人望而却步，要知道，你想添加到播放列表的歌曲有多少首，你就要在待播清单中重复这个操作多少次，以至于我经常打消这个念头。就这样，随着 App 从后台退出，或者待播清单的歌曲越积越多，在系统问我 「保留还是清除之前加入队列的音乐」 时，我只好无可奈何地选择 「清除」 ，然后，原本喜欢的待播清单队列也就不复存在了。
这显然是 Apple Music 有待改进的地方， Apple 应该在 iOS 14 中，对该问题加以改善，在用户建立了一个待播清单后，要允许用户直接将整个待播清单添加到播放列表，或者在待播清单中提供一个 「多选」 功能，选择若干首歌后，可以一并添加到播放列表，或者一并添加到资料库，让用户喜爱的音乐能够以更简便的方式得以保留。
从我的第一台 iOS 设备所运行的 iOS 7.0.3 系统，到现在使用的 iOS 13.5.1 系统，可以说，每一次 iOS 的升级换代，都总会给我带来新的惊喜。或许正是因为这样，使我更热衷于沉浸在 iOS 构建出来的生态环境中，逐步了解到 iOS 是如何满足各种不同的使用需求的。与此同时，我也在不经不觉地留意到不少 iOS 可以做得更好的地方，于是将其写成此篇拙作，盼能与大家互动交流。
Apple 将于北京时间 6 月 23 日凌晨 1 点线上召开 WWDC 2020 主题演讲活动，届时 iOS 14 将正式与我们见面。如果你也对 iOS 14 系统有自己独特的观点与见解，或者你对 iOS 14 有着怎样的期待，都欢迎你在评论区留下你的真知灼见，以供大家交流讨论！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。