March 29, 2018
TABLE OF CONTENTS
This is a guide for Xcode users looking for tips and tricks for using Visual Studio Code. Visual Studio Code (VS Code) is a popular free and open source text editor and integrated development environment (IDE) built by Microsoft. It’s a great tool for developers to use in addition to Xcode for developing on Apple’s macOS or iOS platforms. However, it can be a little foreign to users accustomed to Xcode, due to VS Code’s differing idioms and behaviors.
Xcode is great at editing, building, and debugging Swift and Objective-C projects, but it falls short at some related development tasks, such as documentation and dependency management tasks. Typically project documentation, such as README files, are written in Markdown. For example, even Apple ships their sample application projects with their README files formatted in Markdown.
Even though Xcode 9 ships with a built-in Markdown editor it is currently very limited. For instance, it doesn’t allow opening links to relative files, syntax highlighting code blocks, and editing and previewing Markdown files in the same project. VS Code has all these features and more through downloadable extensions. Xcode also has official support for extensions now, but they are very limited and typically used for snippets and refactoring.
Most Xcode users are familiar with the great Xcode project dependency manager CocoaPods. Mac and iOS developers edit a Ruby file called a Podfile to specify which dependencies they would like to use and run
pod install and
pod update in the terminal to install and update these dependencies.
Just like with Markdown, Xcode has a limited Ruby editor when compared to VS Code and its extensions. For example, iOS Common files is a VS Code extension that tells VS Code to interpret Podfiles as Ruby files every time.
VS Code can also be used to run these common Fastlane,
pod install, and
The first step in navigating VS Code is to read the docs of course, but most developers are familiar with the different features of IDEs and just need to know where they differ and where the features they care about are located.
The first difference to note is that because VS Code is an Electron-based app and not a native app, it doesn’t always have all the features of a native app, such as native tabs and Cocoa text views. Xcode groups not only multiple editors but also panes per project into each native tab, whereas non-native tabs in VS Code only group files open in an editor pane and not other panes. These editor panes are called editor groups, and up to three may be opened at once. When navigating these tabs in VS Code if the last file is selected in an editor group and the next tab is selected via a keyboard shortcut, then the first file in the next editor group is opened.
Figure 1: VS Code’s UI
The editor in Xcode is based on a Cocoa text view that exists in most native apps, such as TextEdit and Pages. These views share the same code. They also share the same keyboard shortcuts (such as Emacs navigation) and extensibility (such as quick access to the services menu and user-created text expansions).
The services menu is useful for quick text manipulations, such as sorting a sequential list of text lines, which I use when sorting import statements to avoid conflicts. While VS Code has a large number of extensions for text manipulation, you’ll have to fight muscle memory to avoid trying to use them in other applications.
Figure 2: Xcode’s UI
For Xcode users transitioning to VS Code, it probably helps to have a familiar landmark, and that landmark is the Activity and Side Bar (Figure 1), which kind of looks and works like Xcode’s Navigator area. Even the first item in this area, called the Explorer in VS Code, and the Project Navigator in Xcode have the same basic function of navigating the root folder structure. Other common functions in this group are the SCM and Search functionality, though their order is different, and thus their keyboard shortcuts are different—which I will get to later.
While the Search pane is similar enough, the SCM panes are fairly different. The Xcode SCM pane is used for exploring and switching branches, tags, and remotes, while the VS Code SCM pane is for staging commits. To switch branches in VS Code, go to the bottom Status Bar and click the current branch name to see a list of available branches. The next closest Navigator panes are the Debug and Breakpoint panes, which are grouped together in the Debug pane in VS Code.
Other functionality is swapped in different locations. Xcode’s Issue Navigator functionality is located below, in what VSCode calls the panel, under a tab called Problems. Also, Xcode’s Variables View in the Debug area is in the Debug panel in the Side Bar in VS Code.
Then there is functionality that doesn’t have an equivalent in the other app. For example, VS Code doesn’t have a Symbols Navigator, Jump Bar, or the concept of an Assistant Editor exactly. And on the other side, Xcode doesn’t have an integrated terminal, extensions browser, or command palette.
Finally, for the topic of keyboard shortcuts, I am not going to list every difference. However, at a high level, VS Code’s strategy is to assign keyboard shortcuts based on mnemonics (Shift+CMD+E for Explorer, Shift+CMD+D for Debug), whereas Xcode focuses mainly on location (Navigator area functions are accessed by CMD+1 through 8 in order), even if that means retraining every Xcode user’s muscle memory when they add a new Navigator in the middle of the Navigator area. To make the transition easier for Xcode users, I’ve created a Xcode Keymap extension that installs familiar keyboard shortcuts into VS Code’s keybindings.
Steve Moser is an Engineering Manager at Levvel focusing mainly on iOS. He is passionate about leveraging software to deliver great experiences.
API design is crucial, giving structure to application interaction. Given cross-functional teams and applications, development time is reduced with a clear, intuitive way to access data. API development often follows two approaches: REST and GraphQL.
As of June 2018, the state of California passed a new privacy law that could lead to more consequences for US-based companies than the European Union’s General Data Protection Regulation (GDPR). Here's what you need to know and how to be compliant.
Before your data scientists wring value out of your reams of data, it has to be accessible and, on some basic level, coherently arranged. To harness all that brainpower, you need to keep the data wrangling to a minimum. Enter the data lake.
Legacy applications get no respect. The developers who wrote them have aged out and no new developers want to work on career-killing software stacks. But they are still faithfully doing the job they were created to do long ago. So what's the problem?