Making great apps requires solid skills in different areas. One of the steps on how to succeed as a software engineer is your daily habits. Their primary goal is to enhance your productivity, code quality, and overall Swift apps performance.

Let’s take an in-depth look at the daily practices of a productive Swift app developer and how to improve your software engineering skills.


Let’s start with simple things you face every day using Xcode.

  • Use Xcode Groups to combine common files.
  • Break large storyboards, files, and classes.
  • Use modern platform features whenever it is possible.
  • Throw away any code craps:
    • duplication
    • unused code
    • old comments
  • Address the root cause of warnings. If there is a vast amount, it becomes unmanageable, and you may not pay attention to important ones or skip them at all.

In other words, do everything that helps you focus on a small number of essential things at a time.


Perhaps every Swift app uses source control today to save and combine everyday results.

  • Keep commits small, independent, and isolated.
  • Write useful commit messages: describe what and why conditions.
  • Select a git workflow and use it in your project.


When you build new functionality on top of the existing one, you create a new level of abstraction. Comments play a crucial part in understanding what is behind this abstraction. Otherwise, you have to go deeper to understand what the method does and what restrictions are.

Good comments:

  • Describe background (context) and reasoning: why this is done and done this way.
  • Give descriptive variable and method names.

Use Ctrl + Cmd + / to generate a documentation template on a Swift method.


Unit tests ensure that functionality still works as expected when you make changes.
Here are some tips to make regularly:

  • Write unit tests to your code before making a commit. If you do not write them right away, most likely, you won’t do this in the future.
  • Cover at least a happy path. It’s much better than code without tests at all.
  • Run unit tests before making a commit. It saves time to you, code reviewer, and CI.
  • Set up Continuous Integration, run tests, measure the code coverage, and report it to the Slack/whatever channel.

I would recommend these articles to learn advanced details about unit testing:

Unit Testing Best Practices on iOS with Swift

Real-World Unit Testing in Swift


It is a good idea to analyze your app quality and performance to uncover unspotted trends and behaviors. This will help you better understand how your code influences the app and thus improve your software engineering skills.

To ensure your users have the best experience:

  • Simulate a poor network connection.
  • Use sanitizers and static/runtime checks.
  • Measure performance and efficiency with profilers.


To guarantee the project health perform a code review and similar techniques for each commit. It allows controlling a code, documentation, and test quality. What’s more, it familiarizes your team with new changes.

  • During a code review, understand every change no matter it’s a new or removed one.
  • Build and run the app when you are done a feature, performed a merge, and ideally during a code review.

I also recommend familiarizing yourself with a Google guide on how to perform good code reviews.


As software developers, we are searching for simple solutions to complex tasks. Decoupling things into single components helps to win a fight against complexity.

Here what you can do:

  • Determine functional and common segments of code and extract them to reusable functions and frameworks.
  • Xcode Frameworks allow including code once and share it between the main app and extensions. What’s more, it helps to reduce the binary size.

You can also use common parts between different projects or share them with the Open Source community. Hence, it’s crucial to fully document your code so everyone can understand and more likely include it to the project.


Open Source allows reusing existing solutions, but let’s use them responsibly:

  • Investigate a dependency thoroughly before you include it to the project.
  • Ensure that they do only what you expect them to do.
  • Know what’s inside:
    • What they do with data.
    • Make sure they don’t collect unnecessary data or device information.
    • Make sure this data is not sent out of the device.
  • Investigate dependencies that the solution depends on and apply the same steps above.

One more questions to take into account before you include a new framework:

  • What would you do if there is a bug?
    • Would you open an issue or submit a fix?
    • What would you do in the time-bound environment?
  • What if it’s no longer supported or just disappears?
    • Would you fork and maintain it?

Every of the described consequences may take an unpredictable amount of time to find a solution. Hence, you have to create a troubleshooting plan in advance.

Generally speaking, including an external framework means that your code becomes dependent on the security and success of the entire chain. Even a simple decision you made at the beginning of the project may have crucial consequences at the end.

Here is even humorous aphorism — Ninety-ninety rule meaning:

The last 10% of the project may take just as long as first 90% of the project.


I hope the mentioned daily habits will be handy for your projects and personal growth as a Swift developer so you can improve your software engineering skills.

I also recommend my other articles to get a deeper understanding of Swift String's performance and the concept of Side Table.

By the way, let’s be friends on Twitter.

I used my experience and this WWDC talk to prepare the article.
It takes 5 min to read instead of watching 35 min video. I believe I can save you time.