最近，我在开发iOS的Markdown应用的时候遇到一个问题，应用是使用DocumentGroup开发的，但是默认会显示标题，从而导致留给工具栏的空间太小，工具栏的图标经常被折叠起来。
我一开始只是想把后退去掉，换成三个点的菜单，然后去掉标题。结果发现后退去不掉。于是我就想看看苹果自己是如何做的。于是我打开了苹果自己的Notes和Numbers。不过Notes其实是有内部库的，于是主要参考的Numbers。
我把Numbers截图给AI，说想要弄一个这个风格的。结果AI搞不定。它虽然设置了标题为空，但是标题始终显示。于是我有把这个描述给Grok，Grok说，这是因为DocumentGroup自动包含了一层Navigation，你需要将它禁用。结果我禁用了，还是不行。又去问Grok，它又说，这是因为iOS的某些版本，有bug，不执行这个操作。但是网友总结了三种办法，1，2，3，然后挨个试。结果第一种就可以了。
这个是我应用最终的效果。
最核心的代码只需要如下的部分。
fork 了一个第三方 macOS 应用，原 release 版本未签名，但提供了源码，为Swift Package格式，需要重新签名并公证后分发。
问题：使用 swift build 构建的可执行文件，无法通过签名添加 hardened runtime。公证时一直报错：
The executable does not have the hardened runtime enabled.
原因：Swift Package Manager 构建时不会启用 hardened runtime，签名时添加也不被认可。
解决：使用 XcodeGen 生成 Xcode 项目，在项目配置中启用。
问题：最初只有 Apple Development 证书（用于开发调试），公证时报错：
The binary is not signed with a valid Developer ID certificate.
原因：公证必须使用 Developer ID Application 证书，不能用 Apple Development。
解决：在 Apple Developer 账号中添加 Developer ID Application 证书。
问题：签名缺少安全时间戳：
The signature does not include a secure timestamp.
解决：在签名配置中添加 --timestamp 参数。
问题：分发版本包含开发用 entitlement：
The executable requests the com.apple.security.get-task-allow entitlement.
解决：在 entitlements 配置中明确设置 com.apple.security.get-task-allow: false。
| 证书类型 | 用途 |
|---|---|
| Apple Development | 开发调试，不能公证 |
| Developer ID Application | 分发和公证 ✅ |
# 安装 XcodeGen
brew install xcodegen
# 配置 project.yml（关键设置）
targets:
YourApp:
settings:
base:
ENABLE_HARDENED_RUNTIME: YES
CODE_SIGN_STYLE: Manual
CODE_SIGN_IDENTITY: "Developer ID Application: Your Name (TEAM_ID)"
OTHER_CODE_SIGN_FLAGS: "--timestamp"
entitlements:
properties:
com.apple.security.get-task-allow: false
# 生成项目
xcodegen generate
# 构建
xcodebuild -project YourApp.xcodeproj -scheme YourApp -configuration Release build
codesign -dvv YourApp.app/Contents/MacOS/YourApp
确认输出包含：
flags=0x10000(runtime) - hardened runtime 已启用Timestamp=... - 有时间戳# 1. 创建 zip
zip -r YourApp.zip YourApp.app
# 2. 提交公证（需要 App 专用密码）
xcrun notarytool submit YourApp.zip \
--apple-id "your@email.com" \
--password "app-specific-password" \
--team-id "TEAM_ID"
# 3. 等待完成
xcrun notarytool wait <submission-id> --apple-id "your@email.com" --password "password" --team-id "TEAM_ID"
# 4. 附加票据
xcrun stapler staple YourApp.app
最简单有效的方式：
project.yml 中配置好签名和 hardened runtime不要试图用 swift build + 手动签名的方式来处理需要公证的分发版本，SPM 的构建产物不兼容。
使用
.toolbar(removing: .sidebarToggle)
可以隐藏侧边栏切换按钮。但是注意，这个不是放在作用在NavigationSplitView上面的。而不是作用在sidebar的视图上面。即必须按照如下的方式使用：
NavigationSplitView(columnVisibility: $columnVisibility) {
sidebar
.toolbar(removing: .sidebarToggle)
} content: {
content
} detail: {
detail
}
NavigationSplitView是三栏的，但是如果你要使用两栏，则有两种方式。
使用sidebar的好处是，sidebar可以隐藏，也可以显示。
使用sidebar+detail的方式。
如果你希望永远显示为两栏，不希望隐藏任何一个栏隐藏，那么使用此方式。
NavigationSplitView(columnVisibility: .constant(.doubleColumn)) {
EmptyView()
.toolbar(removing: .sidebarToggle)
} content: {
content
} detail: {
detail
}
这个的重点在于，通过sidebar设置隐藏了切换sidebar按钮。同时，选择两栏模式，默认不显示sidebar。这样sidebar就无法被调用出来了。并且一直是两栏。
在使用Settings时候，包含sidebar的NavigationSplitView的sidebar按钮会导致出现问题。因此，必须使用上面的第二种方式，隐藏sidebar，并且使用一直存在的两栏。
目前的SwiftUI，如果你希望通过工具栏的按钮直接切换标签，可以使用TabView，也可以使用Picker，不过在细节上，二者有所不同。
TabView是最简单的方式，只要你应用的根视图为TabView，那么你的系统架构会自动转成Navigation Tab Bar的方式，自动在工具栏显示Tab的标签。
不过这个方式有一种缺陷，就是应用的标题不会在工具栏上显示。如果你想强制限制，必须引入AppKit然后，覆盖Window的相应设置。
使用Picker的方式则更为友好。之需要在toolbar里添加Picker，然后使用segment样式，就可以获得同样的显示效果。然后使用Switch切换视图即可。
这么做不如直接使用TabView简单，但是可定制化强，并且不会影响标题的显示。
如果不需要设置标题栏，使用TabView更为简便。否则就使用Picker，这样效果更好。
一直以来都是使用的菜单栏单图标的方式。今天心血来潮，想在Focus原本的图标旁边新增一个刷新的图标，可以用来快速重置计时器。
把任务分配给AI，AI很快完成了第一版。我运行一看，怎么没看到新图标，再仔细一找，的确是两个图标了，但是两个图标是各自独立的，彼此之间还间隔了几个其它的图标。这和我看到的不一样，我其实希望的是像音乐播放器那样的，几个图标一体的方式。于是我和AI说明了要一体的。AI表示了解，然后重新生成了代码。AI特意解释说，一体之后，点击时就需要用点击的位置进行二次判断，还确定用户点击的是哪个图标。
最终结果我实验了一下，的确和音乐播放器的一样。看来他们也是这么做的。
我们知道SwiftUI应用本身没有应用窗口的概念，它是使用WindowGroup来自动管理窗口的。这在用户手动启动应用的时候没有问题。但是如果你设置了应用伴随系统登录后自动启动后，SwiftUI的应用会存在一些问题。
这是因为这种方式启动应用后，SwiftUI的应用不会主动创建窗口，视图会在用户手动点击应用之后才创建。而这可能不是我们所需要的。因为如果我们有使用onAppear来执行一些代码。我们实际上是希望代码可以在应用启动时就运行，而这个机制会导致执行会推迟到用户点击时。
因此，我们需要保证即便SwiftUI没有生成Window，也要自己主动来生成Window。
要解决这个问题，我们首先要了解这个启动的整个过程，然后才能知道如何来改进。具体调试的过程我就不讲了，最终我确认启动的过程是这样的：
我们可以使用NSApplication.shared.windows.count来判断。如果是用户手动打开的应用，SwiftUI会创建SwiftUI.AppKitWindow的窗口。而如果是跟随系统登录后后台启动，则不会有这个窗口。
我使用的判断函数是这个：
func isLaunchedAtLogin() -> Bool {
NSApplication.shared.windows.count < 2
}
之所以用2，而不是1判断。是因为我还使用了菜单栏图标，菜单栏图标使用的是NSStatusItem，因此还会包含一个叫NSStatusWindow的窗口。
func applicationDidFinishLaunching(_ notification: Notification) {
createContentViewWindow()
}
/// 用户启动时SwiftUI的窗口会先创建，因此window不会为nil，但是有可能存在延迟，因为是通过.updateWindow还获取的。
/// 所以这里使用其他的方式进行判断，而不是使用window是否为nil
private func createContentViewWindow() {
/// 若是用户点击，会有两个窗口，一个是SwiftUI创建的主窗口，一个status窗口。后者应该是对应菜单栏图标的。
/// 如果是伴随系统启动，则SwiftUI创建的主窗口不存在，只有status的窗口。
func isLaunchedAtLogin() -> Bool {
NSApplication.shared.windows.count < 2
}
if isLaunchedAtLogin() {
let contentView = ContentView()
.environment(\.managedObjectContext, ModelProvider.shared.container.viewContext)
let window = NSWindow(
contentRect: NSRect(x: 0, y: 0, width: 400, height: 240),
styleMask: [.titled, .closable, .miniaturizable, .resizable],
backing: .buffered, defer: false)
window.setFrameAutosaveName("Main Window")
window.contentView = NSHostingView(rootView: contentView)
window.center()
window.makeKeyAndOrderFront(nil)
self.window = window
}
}
传统上，如果我们使用loginItem来实现应用伴随系统启动，那么为了区分是用户手动启动，还是伴随系统启动，需要使用传递参数的方式。但是传递参数，就需要使用额外的launcher辅助应用。
设置辅助应用的步骤是很复杂的。因此，我们现在大多都是直接使用下面的代码来直接使用自动伴随系统登录启动。
try SMAppService.mainApp.register()
这个办法虽然大大简化了设置系统启动后启动应用的步骤。但是这么做之后，由于没有辅助应用，也就没法使用传递参数的办法了。
本文给出的使用NSApplication.shared.windows.count，用窗口数量来间接判断的方式，利用了SwiftUI在后台启动后，不会主动创建窗口的特性，解决了这个问题。
最近我在做应用适配iOS/macOS 26的特性。今天在Xcode Cloud打包的时候遇到打包失败的错误。
Macro “DefaultsMacrosDeclarations” from package “Defaults” must be enabled before it can be used.
这个问题是我应用所使用的第三方的库 “Defaults”在其内部使用了宏。这个宏在Xcode本地编译时，需要用户手动点击确认才能继续。但是Xcode Cloud中，没有点击确认的位置。因此，就无法完成打包应用的过程。
通过运行脚本的方式，在克隆完文件夹之后，运行脚本，规避掉对于宏的验证。
#!/bin/sh
defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES
必须在Xcode中的根部位置，创建一个新组，命名为ci_scripts，然后在这个组中创建ci_post_clone.sh，内容是上面的内容。
必须在Xcode的根部位置创建组，并且命名也不能错。
我其实最开始是像GPT 4.1提出了这个问题。GPT 4.1的解答只对了一半。它提出了创建文件夹和脚本，文件夹是正确的，脚本名字是错误的。并且它也没有告诉需要在Xcode中创建组，而只是说在项目的根目录创建就可以。最后，它创建的脚本内容不完全正确。
之后我使用了Google搜索。Google搜索默认的AI总结的是正确的，但应该就是从stackoverflow里的答案总结的。我最后是看的SO里的回答，进行的总结。
另外，我建议你完整阅读下面的第一个引用。我使用了里面最为简便的方案。而非最安全的。也许你看了之后，会选择一条不同的手段。
一年以前，我就踩过一次AccentColor的坑。没想到，一年之后我又掉进来了。
事情的起因是这样的。因为苹果的新系统发布了嘛。我不能免俗的也要改进我之前的应用，添加对于新系统特性的一些支持之类的。
但是我在修改代码后测试时发现，当使用ZStack模拟弹窗之后，弹窗后面的视图的颜色会出错。我一开始以为是ZStack的问题，于是将模拟弹窗改成了.fullScreenCover的方式。这个问题在当时看起来时解决了。但是今天我在使用中发现，这个问题又重新出现了。
于是我在Google上搜索了一下，没想到这还是一个SwiftUI长期存在的一个问题。
How do I stop the AccentColor from turning Gray when a sheet is being presented?
原来在SwiftUI中实际使用时。原本应该一致的Color.accentColor和Color("AccentColor")在实际使用中是不一致的。说得更具体些，就是Color.accentColor会使用应用设置和用户的系统设置。而Color("AccentColor")则是将AccentColor作为颜色资源从Asset文件夹直接读取。因此，虽然它的名字也叫"AccentColor"，但是实际上它只是名字叫"AccentColor"的一个颜色，你改成别的名字，比如"MyAppColor"也是一样的。虽然这样会失去Color.accentColor一些独特的个性，但是能保证颜色的一致，即颜色不会莫名其妙的改变。
系统弹sheet的时候，Color.accentColor会改变的问题，应该就是sheet本身可能存在某种机制，将应用内设置的Color.accentColor从Asset文件夹设置的内容，改成了系统默认设置的内容。比如下图红色圈起来的部分，就是系统允许用户自定义用户AccentColor偏好的地方。
