As a developer, how do you think Apple should improve its developer tools?

[[164459]]

My colleague Alex Denisov and I have discussed several issues in the past regarding the developer experience with Xcode and iOS development in general. This post is a summary of what we discussed.

Alex Denisov and I have obvious differences in our views on the final performance of our products and whether Xcode can improve developer productivity, so I am very willing to share our views with you.

There are mainly the following aspects:

Development environment issues

• Xcode
• project.pbxproj

Graphical vs. semantic ("mouse-driven development" vs. "keyboard-driven development")

• Auto Layout
• Xibs/Storyboards
• Focused tests

Why do integration tools with so many problems still exist today?

The criteria for measuring an integrated development tool are vague. In other words, there may be no criteria to measure it at all: Monoliths are Bad Design... and You Know It.

We all know that integrated development tools are the only way for things to emerge, grow and mature. But some people believe that integrated development tools need to be decomposed into components with different functional modules, so that each component can evolve according to the principle of single responsibility and have no impact on the rest of the system. From this perspective, LLVM was separated from the GCC integrated compiler, Carthage, the "founder of the theory of distributed dependencies" opposed more "integrated" tools like CocoaPods, and the modular AFNetwork 2 also evolved from the integrated AFNetwork 1. There are many more examples like this.

Here's an example of how Apple fixed one of its many integrated tools: Storyboards. It took years to get an "official" feature from Apple to split huge Storyboard files into smaller single-story-focused ones, and open source libraries like RBStoryboardLink were introduced much earlier, in 2012: RBStoryboardLink is deprecated.

In addition to the above examples of Storyboards being optimized, there are still many integration tools. Let's look at some of the most controversial ones.

Xcode

Obviously Xcode itself is the biggest integrated tool: its main modules include text editor and interface builder, and some others are related to build settings management functions, such as Apple account management, source code control integration, etc. Why Xcode sucks.

We don't understand the reason behind a huge application doing all this, but we can see that the conversion between pure code files and xib files in Xcode7 may take more than 10 seconds, and we can also see the simulator hanging, crashing or restarting (you may see a black screen more than 5 times a day). We never use the source control feature because it can't compare with professional source control tools such as SourceTree, even this tool is just the most ordinary command line.

Currently, more and more people are turning to AppCode, an integrated development environment that focuses more on code writing. It does not have the fear of graphical development and other embedded modules of Xcode, but provides better code analysis and refactoring tools. I believe that developers using AppCode are more efficient because they don't have to care about things that are not really needed, such as CocoaPods support, which I don't think is what a "smart" IDE like AppCode should have. Sometimes it seems that in order to keep up with the trend, some IDEs always want to have all the features.

project.pbxproj

project.pbxproj is what I consider the second most integrated tool after Xcode.

I bet if you ever had the chance to read this document from beginning to end, you would have the same impression as I do: this document is not suitable for human management, and I would think in my heart that its design is anti-human.

Ambiguous identifiers are everywhere in the project.pbxproj file (867CFE661BFFDC5E001F85A8 is a /* ViewController.m */ as you know), and besides the bad formatting, there are a lot of things that we can't control. Let's make this readable and editable, plain text files are easy for people to understand and maintain:

• Project structure
• Configurations
• Targets
• Schemes
• Build Settings
• Code signing details,
• Run Scripts (yo shellScript = "\"${SRCROOT}/Pods/Target Support Files/Pods/Pods-frameworks.sh\"\n";)
• Build Phases (yo 74E916613A2758307FB74A44 /* Embed Pods Frameworks */ = {),

We haven't managed to get CMake to work with iOS project structures yet, but I firmly believe that the next .pbxproj file replacement will be inspired by some mature build systems like Make, CMake, Ninja, Gradle, etc. They are all based on text files and, more importantly, are designed to be human-friendly.

Let's discuss some issues that may prevent us from abandoning the old .pbxproj structure.

Groups vs Folders

We don't need groups at all, because each group always corresponds to a real folder. It can even be considered that grouping is an anti-pattern. If a person uses grouping to design a project structure that is different from the structure of the real folder, it usually shows that he lacks an understanding of the real file structure of the project and only cares about the superficial logical structure.

I mentioned this a while ago: we are about to start replacing Xcode iOS project architecture with CMake, and we are about to start maintaining and developing our app project architecture using almost the same CMakeLists.txt that LLVM developers use.

I specifically asked my Android development colleague, and he confirmed that there is no concept of groups in Android development. So when you add a new folder to the project, Git's working tree will have nothing but the file added. This is exactly the opposite of Xcode: when we add a file in Xcode, the entry of the file will also be recorded in project.pbxproj, which will cause conflicts during merge/rebase operations.

xcconfig files: packaging and inheritance

Do we have better tools than xcconfig to manage and set up third-party components and abstract the configuration of the compilation environment?

We asked this question in 2006 and it's still here:

Automatic line wrap:

I wrote a line of code that is so long that it exceeds my screen: how can I truncate it? The C method is not feasible.

You can turn on wrapping settings in the editor, but .xcconfig files don't support automatic line wrapping very well.

The automatic line wrapping feature makes the code more readable and reduces the risk of potential conflicts when merging code (for example: a string like _-Warning-flags_).

Inheritance - How to add values ​​to variables in xcconfig files:

Has anyone successfully added new values ​​to variables in an xcconfig file?

Judging by the reasons others have given on this question, this value cannot be inherited in general.

We recommend adding a namespace for the corresponding variables and adding this sentence at the end of the xcconfig file:

merge.xcconfig:

 <span style= "font-size: 16px;" >OTHER_CFLAGS = $(inherited) $(APP_PLATFORM_CFLAGS) $(APP_PROJECT_CFLAGS) $(APP_TARGET_CFLAGS)<br></span>

Another way is to use CocoaPods, which will use its own generator to generate a specific xcconfig configuration file and add it to the Pods configuration file:

 <span style= "font-size: 16px;" > // Pods/Target\ Support\ Files/Pods/Pods.debug.xcconfig?<br>HEADER_SEARCH_PATHS = $(inherited) "${PODS_ROOT}/Headers/Public" "${PODS_ROOT}/Headers/Public/AFNetworking" "${PODS_ROOT}/Headers/Public/ObjectiveSugar"<br></span>  

You can also use the following instead:

 <span style= "font-size: 16px;" > // AFNetworking.xcconfig<br>HEADER_SEARCH_PATHS = $(inherited) "${PODS_ROOT}/Headers/Public/AFNetworking"<br>// FinalConfig.xcconfig<br>#include "AFNetworking.xcconfig"<br></span>  

Graphical VS Pure Code: Mouse Driver Development VS Keyboard Driver Development

Examples speak louder than words, and their order is random, so let's guess who is which:

• Press Command + U to run the test case instead of clicking the little red or green icon with your mouse
• Use the mouse to set automatic layout in Storyboard instead of using frameworks like Carthography to calculate the frame
• Build static libraries with Makefile or CMake instead of using Xcode
• Open the terminal to perform Git operations instead of the source code management tool that comes with Xcode

Yes, a few clicks of the mouse did help us quickly solve many simple problems in the early stages of the project, but as our system became more and more complex, it became difficult to manage it with a mouse or touchpad.

Our view is that Apple should invest its vast human resources into the development of semantic development tools (test frameworks being a good example) rather than researching tools that "have it all", because mouse-driven development is immeasurable, and semantic development, timeless object-orientation and SOLID principles make the system more extensible.

It seems like Apple favors mouse-driven developers right now, and whenever a new UI feature comes out we are more likely to get new clickable controls in Xcode first, but the corresponding APIs don't help us manage the complex system and make the difference compatible. Let's look at some more examples.

Often mentioned automatic layout and UI

If we look at web development, there was a clear separation between content (HTML) and style (CSS) in the early days. The fact that both content and style could be managed in plain text files inspired Apple to introduce some tools based on the same principle. I'm not sure there was any specific reason why the concept of these tools from Apple was so similar to the concept of style sheets, which hadn't been introduced yet.

Some native tools today may not handle complex Auto Layout very well: we have neither graphical tools to set complex constraints for views (unless you are a real mouse clicker) nor fine-grained DSL programming languages ​​officially developed by Apple (which is why sometimes seeing tons of addConstraint: code makes us willing to choose native tools).

That's why so many open source solutions seem to start filling the gap in native semantics support for their UIs: ComponentKit and other Auto Layout DSLs like Carthography, Snapkit, Parus are good examples. It's worth mentioning that AFAIK no one has tried to create graphical development tools so far, because no one wants to do anything for mouse-driven development.

There is no need for Xibs in our files, and no need to spend time processing them at runtime.

The difference between building an interface with a graphical tool and achieving the same effect with OC/Swift code is mainly because Storyboard and Xib cannot let us see the intermediate process of implementation. The final product we can get is only a binary file like a view controller or view generated in the runtime space of the application.

A complete alternative is to generate intermediate code in the form of classes, which are based on the factory pattern, so that Xib/Storyboard files are generated from the factory for a specific view controller or view. Not only will it allow developers to observe the intermediate files before the compilation process even starts at runtime, it will also eliminate the overhead of compile-time and runtime instantiation. Can you imagine having no Xib/Storyboard binary files in the source files of the application, can you expect better performance of the application in instruments?

If we continue to develop in this direction, we will eventually realize that the factory model is humane and may trigger a new UI programming revolution.

XCTest is gradually losing its testing features

I have been using Cedar test framework for three years: this framework is a markup specification. But when using XCTest, when you want to run a test case or a test class in markup mode, the only way is to click the small green/red icon with your mouse/touchpad, which not only adds extra complexity to the test-driven development flow that represents agile development, but also reduces development efficiency.

We can use a specification like - (void)ftest...` or better yet Clang annotations to instruct XCTest to execute the test cases we marked.

in conclusion

To be honest, I'd love to share more of my views on Apple if anyone wants to hear it. For example, I haven't written about the third major integration tool, xcodebuild, yet, so maybe there will be another article about it in Part 2.

Almost done: In addition to the examples given above, we found some simple and practical principles in development:

• Stay away from integration tools. If you want to think carefully and divide your functional modules as finely as possible, you can use the design principle of "high cohesion, low coupling".

• What mouse-driven development can't do, plain text files with carefully designed classes or declarative programming languages ​​at least have a chance of doing.