object c架构，swfit，SwiftUI的关系与架构选择

一个完美的产品不是完成基本功就完事，要完美处理各种细节。SwiftUI在技术栈积累不够和各种组件前不建议实际应用。作为知识储备是必要，立即实施风险太大，没有必要。我们很欣赏SwiftUI简洁性和快速开发，很多细节需要我们解决。方便和功能强大是相悖的。正如java和C/C++的关系。使用java基本不关注指针使用和内存使用，方便好学。C/C++需要处理烦人的指针和内存使用问题，正因为它更接近底层，所以能实现java实现不了的问题和响应比java快30%。一个好的软件不取决于采用那种语言，而是取决于开发软件的人。SwiftUI还任重道远，不要过于追求新技术。
由于Struct内不能直接打印日志和立体图是乱码决定了SwiftUI是一个错误的产品，基本上相当于以前的storyboard。只是相当于以前直接拖入控件变成代码实现UI。一个好的软件缺少不了强大的日志系统，只靠接口和效果，单步跟踪，没有日志的软件，很难保证软件质量，更无法维护。我在很多公司见到许多app直接从来不打印日志，真不知道他们怎么开发出app的，这样的app质量可想而知，后期维护简直是噩梦。SwiftUI是一切皆view，大量使用Struct基本上是从设计上摒弃日志，真不知道设计他的人是聪明还是傻！为了节省一点内存，而放弃可维护性，得不偿失。以前全使用storyboard和xid的人有多少，用代码实现ui的又有多少。现在又换成这样不能打印日志和立体图的SwiftUI，简直是技术退步。Swift语言是语言的进步，他是强类型的语言，会自动约束程序员的语法错误。而object c是弱类型的语言，很多语法错误不检查，过于啰嗦，全靠程序员的严谨性和代码质量。弱类型也存在优点：在高质量的程序员手里灵活性很好。就像c语言和c++语言的进步一样。c++在某些应用中无法代替c 语言。新公司员工没有大公司的架构建议采用swfit开发，不建议采用SwiftUI技术，采用代码实现ui就可以。若是大公司对质量控制很好，有很好的object c的mvvm架构，建议采用mvvm架构。不建议为了追求新技术放弃优秀的object c的mvvm架构（带app网关，ReactiveObjC，页面路由）。咨询过许多大厂的框架，他们仍旧采用object c语言开发的居多，采用mvvm架构（带app网关，ReactiveObjC，页面路由）。swfit比object c语言更先进，但是限制也更多。好的软件，主要取决于开发软件的人和框架，而不取决语言本身。不是使用的先进的语言开发的软件就好。有人说大厂很多都是网页，开发的软件太多，无法转swfit。这样是一方面的原因，但是不是全部。主要是大厂的框架足够优秀，代码质量要求严格，灵活性好。不要认为SwiftUI有Swift这几个字就认为它是Swift更高级的形式，其实他只相当于原来的storyboard，是控制器和view的组合体。我不推荐使用SwiftUI。使用SwiftUI还是使用object c取决公司的技术积累，是否有十分好的架构。若是啥架构都没有，建议采用Swift；若有很好的大公司object c建构，建议采用object c架构。再次说不要采用SwiftUI技术。