DEV Community: Oleksandr Masliukivskyi

Most essential Xcode shortcuts every developer should know

Oleksandr Masliukivskyi — Mon, 11 Sep 2023 14:53:23 +0000

As iOS developers, we spend most of our time at work in the Xcode. To put it into perspective - It's about 20–35 hours per week! What if I told you that you may use this time inefficiently, and you can optimise it?

Imagine having an elevator in your house, but still using stairs to get to the top floor.

At the end of the day, you'll reach the same floor, but at the cost of time and exhaustion. The same is applicable to using Xcode without shortcuts.

In this article, I'll show you a few Xcode shortcuts that will boost your productivity and elevate your skills in writing code.

We'll separate them by Project View and Navigation, Code Editing, and Project Build sections. Some of them might be well-known, and some - can be new to you, but I'm sure all of those mentioned are essential to every iOS developer.

Plus, there's a very helpful bonus at the end of the article 👀

First things first, let's agree on the dictionary of the symbols. In this article, I'll follow this setup:
⌘ – Command key
⌃ – Control or Ctrl key
⌥ – Option or Alt key
⇧ – Shift key

Project View and Navigation

In this section, we'll focus on the shortcuts that will help you to navigate through your Xcode project and understand its file system way faster than you used to.

The first one is ⌘ + ⇧ + O. To open a file by its name, just press this combination, type the filename, and you'll see a list of options matching your input.You can search by class/struct name and methods declaration.This is the fastest way of getting around the big projects when trying to find something, especially when onboarding into a new project.

The next one is ⌘ + J - focus on a file in the navigator. It's very helpful while working on projects with complex structures - you can easily end up in some unknown location, and this shortcut will show you exactly where you are right now.

⌘ + N - create a new file. A common shortcut for all IDEs, but in combination with the previous one, you can create a new file in the right place of your project very fast.

⇧ + ⌘ + Y - show/hide debug area. Also comes in very handy for quickly accessing the debug area view.

⌘ + ⌥ + Enter - toggle SwiftUI Preview/Canvas. While working with SwiftUI, this one is helpful to toggle the additional Previews view when needed.

^ + ⌘+ J - Jump to the definition. After selecting a property or function, just use this shortcut, and it will navigate you to the definition of the selection.

⌘ + ⌃ + left/right arrows - jump between the previous and next opened file.

⌘ + ⇧ + 0 (zero) - show a documentation view. I encourage you to use this one from time to time or when dealing with some unknown Swift issues, Apple's documentation is very user-friendly and easy to navigate through.

Code Editing

Now we'll focus on how to boost your code editing with shortcuts.

⌘ + ⌃+ E - Select all in scope. Very useful shortcut for refactoring small chunks of code in a local scope. Let's say you've misspelled your property name, and you want to fix it quickly in all local-scope usages. You can do so by selecting a word and using this shortcut:

⌘ + ⌥ + E - find in the current file. Just select a word and press this shortcut to jump to the next usage of this word.

But be careful, this shortcut is case-insensitive and matches by parts, not the whole word.

⌃ + I - Re-indent code. After making some changes to your functions, you may notice that code indentation can mess up. Use this shortcut to quickly fix your code.

⌘ + ⌥ + Up/Down arrows - fold/unfold method or class. It will cover the selected part of the code. Very helpful to use this in big and complicated parts of code, just in order to focus on what's important right now.

⌘ + ⌥ + / - create a documentation. It just pastes a documentation template right above the selection, which is way faster than writing it all by yourself.

Project build

As for the project build shortcuts, I consider these most helpful:

⌘ + R - run current target
⌘ + B - build current target
⌘ + U - build and run testing target. Add ⇧ (⌘ + ⇧ + U) to just build without running. Or add ⌃ (⌘ + ⌃+ U) to skip building when it's not needed
⌃ + ⌥ + ⌘ + G -re-run a previous test case. Very helpful while fixing just one problematic test. If your last testing action was running the whole class, it will run the whole class again
⌘ + ⇧ + K - clean build

Bonus time!

For a quick multiline change in your code, you can use ⌃ + ⇧ + up/down arrows. This way, you will activate a multiline cursor, which can be very handy for refactoring chunks of code without repetitions. And, to make it sound even better, you can use mouse clicks to select the specific parts of lines to edit!

I can guarantee that after using it a few times, you'll love it and will not imagine your Xcode development without this shortcut!

And also, as a bonus-bonus, you can change and create your own shortcuts in Xcode. To do so, go to Xcode → Settings → Key Bindings.

Be careful not to use some macOS system shortcuts though, because the OS will treat it with a bigger priority

In conclusion, I'd say that the usage of the Xcode shortcuts is a pretty good marker of how proficient a developer is. After hosting multiple iOS job interviews with live coding/debugging sessions, I always paid attention when an interviewee was using them. It shows that the person is not totally new to iOS development and is interested in becoming more proficient by learning how to use a tool a bit more than just creating a project and being able to run it.

And that's it! I hope you've learned something new from this article and that I've helped you become an even more productive iOS Developer than you were before.

Have I missed some interesting shortcuts? Let me know in the comments, let's learn together!

Development of a Multiplatform project from iOS Engineer's perspective

Oleksandr Masliukivskyi — Wed, 05 Jan 2022 15:27:06 +0000

How an unthinkable thing turned out to be an interesting experience

Throughout my career, I was always focused on learning only native iOS technologies such as Objective-C and Swift. I considered (and still consider) myself as a "non-believer" in cross-platform solutions like React Native or Flutter - it's interesting and usable for small-scale projects and not really for bigger ones, because of its maintenance problems and scalability. And recently, at FootballCo, we started building brand-new Goal news and live scores application for Goal.com, which will be developed using Kotlin Multiplatform, and in this article, I want to share my experience of writing and maintaining a Multiplatform code.

Humble beginnings

At first, I was very confused (and a bit scared, there's nothing to be ashamed of).
Surely, I've already had some experience in building Android applications in Kotlin, but still, as an iOS Engineer, just the thought of working with Kotlin on a daily basis was frightening. Imagine - you just started a career with a pretty complicated language like Objective-C, then switched to much more pleasant Swift, developed your skills there and now you should change your paradigm and work on Kotlin and think as an Android developer (spoiler - not really).

Swift, Kotlin, and Objective-C "Loved vs. Dreaded" comparison, according to StackOverflow

But as an Engineer - you should be always open to new challenges and for learning new technologies, our world evolves so fast that you should be on the same pace with new technologies, and gaining new skills is a MUST if you want to succeed.
And surely I wasn't a totally new person in the Android world - my Uni thesis was about an application written in Kotlin, so life kind of prepared me for such a turn of things :)

Why did we decide to go with the Multiplatform approach?

The biggest benefit - code reusability and maintenance. In our legacy applications, we saw that big chunks of codebase could be shared between platforms - network layer, analytics, data persistence, most parts of business logic. All of these are pretty essential parts of any mobile application and we could easily write them once in cross-team collaboration, cover it with tests and use it on both platforms.

Every Multiplatform project in a nutshell

With it, comes the speed of delivery, better quality, and knowledge sharing. Just imagine - this big part of business logic, that your team worked on for months, could've been written by x2 amount of people, which could catch more bugs and come up with some interesting solutions.

MVP and our start with KMM

Along with KMM (from now on I'll use this as a shortcut for Kotlin Multiplatform), we decided to write our apps using brand new platform technologies such as SwiftUI and Jetpack Compose. We kicked off our process with an MVP project in order to test all of the frameworks which I mentioned above and it turned out pretty well. We built a simple proof of concept application, integrated and tested all frameworks which we would use in a production app, and prepared all necessary automations.

To learn more about our MVP project and our findings , check this article by our Android Engineer Aleksander Jaworski: https://akjaw.com/kotlin-multiplatform-mobile-poc-conclusions/

We decided to put all our automations into fastlane, most of our engineers are used to use it and it contains a lot of pre-built solutions suitable for our needs. From the get-go, we understood that, at the initial stages, we would need to rebuild the KMM framework regularly - pretty much with every minor change in it, so putting it to the separate repository and accessing it from there was not the way to go, so we needed to come up with a solution that builds shared framework fast enough. At later stages, when changes to the shared framework will occur more rarely, we will surely encapsulate it into a separate repository.

While creating this proof-of-concept, we also changed our approach to daily ceremonies and merged most of them, we "switched" our mindset from thinking that we are two different teams (Android and iOS ) and started to position ourselves as one mobile team. I think for every project and every company it's very important to have such close communication between Android and iOS folks - after all, we are building almost the same application but for two different platforms, and our end-users should have the same experience on both.
As part of this process, we introduced pair-programming sessions, during which iOS developer sits with Android folks and, in collaboration, they build a multiplatform part of some feature - from modeling, implementing, and covering it with tests to performing a basic platform integration and checking if everything works fine.

These sessions were the most helpful thing so far - they gave our team members a brief introduction to Kotlin and after just one session you can debug, test, and introduce changes to multiplatform code by yourself!

Pros and cons of the KMM approach

So, after 6 months of working in a multiplatform approach, we already noticed a lot of very cool things that changed our way of work in a positive way.

Some of them are minor and not widely applicable, some will be surely helpful for any team, so here's the list:

Pros:

You are a pioneer of new technology. I've heard only about 2–3 serious applications written in KMM and it's very exciting to try and work on something that fresh.
You can learn Kotlin and widen your horizons. Believe me - it's very similar to Swift and pretty easy to write in.
Shared codebase - write once and use by two teams. It is really very comfortable to write some big chunk of business logic just once and re-use it on a different platform (just imagine starting a sprint and receiving a message that we introduced a DB layer in our app and there's no need to build it!)
All core libraries are there to use! You are free to call iOS SDK libraries in KMM without any problems if needed.
You can see how the project works on Android and you can take part in the development of it. It's really crazy: Gradle, modules for features, co-routines, manifests - there's lots to learn about the d̶a̶r̶k̶ Android side of app development.
No need to test business logic on the app's side. All code that we share in KMM framework is covered by tests on the Kotlin side. This also means that you'll learn how to write and maintain tests in Kotlin
Our team and our possibilities doubled! Now it's not just two groups of people with different mindsets and proficiency in different technologies, but one big team of mobile engineers that collaborates on a daily basis, plans accordingly and solves problems much, much faster. In all approaches that I recollect thought my career, KMM was the only one that made it possible.
Knowledge sharing. I'm sure, your initial thought about the KMM approach was that only you, iOS Engineer, will need to adapt and learn, but that's not the case. The Android team also runs and debugs our code, so it works in both ways and is very beneficial for the team as a whole.

Cons:

In order to start - you'll need to invest some time into learning the basics of Kotlin and Android development. There's no way to go around it - you just need to do it.
Very similar to the first one - you should bear in mind that it's a very fresh technology, so be ready to come up with workarounds and solutions for some weird problems.
You'll need to have two IDEs on your Mac - Idea or Android Studio for Kotlin/Android side and Xcode for the iOS one (AppCode - please don't do it)
It takes time to familiarise yourself with a new language and IDE. You'll need to learn a lot of new shortcuts, terminal commands and in general how the project is structured in Android.
Slow feedback loop. As mentioned before, any change in the shared KMM framework requires rebuilding it, so changes could be used in the iOS environment. The only way around is to run KMM tests, which will build a shared framework much faster.
In order to use the KMM code in Swift, you'll need a lot of wrappers. Like a lot. Most of the things are returned to our iOS world as Flow/Suspended Wrappers and you need to know how to handle them properly, keeping in mind async calls and error handling. It sounds kind of like RxSwift, but you will use it not only in network calls - even in order to get some static data (hardcoded in KMM or taken from some DB). At first, it might sound like taking a sledgehammer to crack a nut
Debugging might be really painful. If anything crashes on KMM side - you'll need to scroll through the debugger a lot and do it very carefully in order to find a source of the problem. Also, familiarise yourself with InvalidMutabilityException - it will be there with you for quite some time :)

Conclusion

In general, our team (as a whole, not just the iOS part of it) is very happy with the KMM approach. Quality-wise, positive feedback that we have is much bigger than the cons of it - most of the problems, like learning Kotlin and IDE, will be resolved in the first months and later on - you'll just catch the wave and you'll forget you used to hate it :)

We do see a very big future in the Multiplatform approach and we are looking forward to seeing where it gets us.
If you have any questions regarding our process, interesting findings during building proof-of-concept application, maintaining KMM in the iOS environment - don't hesitate to ask!