Why We Need Developer Tools for Server-Side Swift
It looks like the importance of developer tools isn’t realized right when you start a software development career. In the beginning, when you’re just learning, the only tools that matter are a compiler/interpreter and a debugger. Only later, after learning about a standard library, system SDKs and frameworks and 3rd-party libraries, after building a project or two you come to appreciate all of the complexity of IDEs and other more advanced tools. Or if you don’t like IDEs, adapt your favorite text editor to get some of the features of IDEs.
The most important state you can be in while working is the flow. Every smallest interruption breaks your focus and disrupts the flow. Remember the days when you were most productive, you were probably laser-focused on solving that specific problem and avoided any distraction on anything else. Every possible slowdown is frustrating when the only thing you care is the result and being able to deliver it on time. Slow compilation that stops you from iterating quickly, programming errors that are discovered only in runtime, obscure documentation that takes ages to figure out what’s going on and still unusable without StackOverflow. That’s why in the big picture auto-complete, advanced static analysis, linters, unit-tests, visual debuggers matter as much as the integration of these tools.
Having worked for the last few years with Apple’s ecosystems, I can say that developer tools from Apple are definitely something worth mentioning. The only comparable thing that I know of is probably Visual Studio suite. They do share both advantages and disadvantages, which apparently stem from the way these tools are published and developed. Both tools are closed-source and heavily integrated into corresponding ecosystems and development cycles tied to OS and hardware releases. The obvious consequence is that needs of developers are secondary to marketing and product development plans of those ecosystems. While there is tight integration and superior UI/UX when compared to open-source tools, reliability and predictability could be much better than they are now.
On a positive side, there are plenty of 3rd-party developer tools evolving these days, specifically for iOS: crash reporting, analytics, logging, visual debugging, continuous delivery etc. Not as many for Mac, and as my main interest these days is Swift on servers, there just a few utilities for this new ecosystem. Yes, it is is new, but that’s actually a ‘chicken and egg’ problem. If it takes huge effort to develop something because there are no dev tools, why would anyone care and develop something good? And if there are no good use cases, why would anyone make any dev tools for it in the first place?
This year was still particularly good for Swift on servers as Swift 3.0 with almost complete implementation of Foundation on Linux and improvements to SwiftPM was released, while multiple frameworks had a few major updates. SwiftyBeaver just released an adapter for Vapor, but there is so much more to be done to help with deployment, diagnostics and development of code written in Swift for servers.
We currently envision this as a service that allows you to capture crash reports and other events with arbitrary metrics from your apps. We also would like to provide a few helpers that, if installed, allow you to profile your application and detect memory leaks, run CPU instrumentation or benchmarks with little effort. Obviously, collating and reporting this data is as important, and data visualization will be a big focus of our work. But all of this in the early stage of development and depends on your feedback as a user. Sign up at our site for early access and we look forward to hearing from you!