在Xcode 11 GM中，使用TabBar的语法格式为：
struct Tabs: View {
@State private var selected = 0
var body: some View {
TabView(selection: $selected) {
MyFirstView()
.tabItem {
Image(systemName: (selected == 0 ? "star.fill" : "star"))
Text("One")
}.tag(0)
MySecondView()
.tabItem {
Image(systemName: (selected == 1 ? "star.fill" : "star"))
Text("Two")
}.tag(1)
MyThirdView()
.tabItem {
Image(systemName: (selected == 2 ? "star.fill" : "star"))
Text("Three")
}.tag(2)
}
.edgesIgnoringSafeArea(.all) // Important if you want NavigationViews to go under the status bar...
}
}
其中原来的TabbedView变为TabView，tabItemLabel变为tabItem，并且可以使用传入binding值的方式匹配tag，对当前选中的不同tab产生响应。
如果要改变TabBarItem被选中时系统显示的颜色，可以修改属性
.accentColor()
在其中传入要设定的颜色值，tabbar item被选中时就会呈现出指定颜色而不是系统默认的蓝色。但是要注意对于非系统icon，不会有对本地图片自动填充颜色的效果。
此外这次issue的教训是：
在进行merge请求时的代码也要注意优雅，特别是工程代码
逻辑层和数据层的代码要分开；如果已经有了大致框架，不同的逻辑也要写在不同的文件中
最好不要在传值的时候传入一个过长的表达式，这样代码的可读性会降低，可以通过计算属性取得状态值
在用switch语句时，尽量不要使用default语句，而是尽可能将所有可能的情况都枚举出来。这样在编译时编译器可以帮助检查是否对所有的枚举值进行了判断，防止添加新的case时部分代码忘记添加case情况直接执行default语句，最后运行出现bug
任何方法在制定时都要考虑到程序的健壮性，如果以后有添加/删除怎么办？不能只满足当前的情况，要对未来的修改有预见，让修改的程度降到最低。
最后：我的第一个还算优雅的（？）方法，纪念一下
判断是否选中tab的方法
在学习中起到帮助的：
stackoverflow-tabview的格式
apple developer-bug
