Also a lot of the verbosity of the Obj-C methods names in Apple’s frameworks carried straight over to Swift. And you can make your own method names as verbose a

Also a lot of the verbosity of the Obj-C methods names in Apple’s frameworks carried straight over to Swift. And you can make your own method names as verbose as you want. So I am not really sure what the complaint actually is. Not having header files has literally never been a problem for me. Xcode can auto generate a sort of pseudo-header definition file if you are pulling in someone else’s frameworks. And day to day app work mostly consist of writing code for the app, not writing a library or framework for others to use. You still have public and private methods. I guess not having separate header files makes it slightly easier to expose things you should probably keep private, but that really is just a thing that is solved by “just don’t do that.” Finally, a lot of times people will just have a private extension to a class that contains all the private methods anyway. So you basically just have everything combined in the same .swift file, where you have a “logical” header rather than a separate header file.