Few years experienced using Android Studio does make me took for granted the power and ease of use of IntelliJ I have benefited from so far. Until I started using Xcode…

Xcode users, no offense. Just some experience to share, as a healthy comparison and personal preference. Hopefully from the article you would know what’s different if not nice out there. Let me know if I have perhaps miss out the feature of Xcode and perform an unfair comparison.

For the last 2 weeks I get myself wet into some iOS development using Xcode. After getting familiar with all the shortcut and able to maneuver around, my anxiety of using Xcode has greatly reduces.

Nonetheless, there are various areas that worth noting, and hope Xcode development team could find these useful and look into ways to further improve Xcode as they see fit.

FYI: I’m using Xcode 10.1 and Android Studio 3.3.2

1. Need faster response time of flag error

In Android Studio, whenever we have a typo or remove a variable, all it’s subsequent usage will be flagged out as error in no time (0 seconds). This applies even for a huge project.

The below diagram show when declaration of variable abc is commented out, all the use of abc is flag as RED immediately indicating it as an error. It happens in a tiny fraction of a second ( the below timer doesn’t reflect the time well, as my human respond to it is much slower than how fast it detect all the errors.

Using also a very small project in Xcode, and similar scenario, the error will only show after 4 seconds of waiting. That’s a huge delay to me who get used to wait no time to know I have a typo error.

To make this deficiency more obvious, if the commented code is a function that is used across files, the error doesn’t even get reflected until the project is rebuilt.

2. Deterministic goto next error (within the file)

When I make some changes to the code within a file that will generate some other errors within the file e.g. comment out the declaration of a member variable; the usage of the variable within the file will be detected as error. When this happens, we would want to go to these places to remove the variable usage.

In Android Studio, I just need to press F2 key, the cursor will go from the first encountered error to next error.

It will go from first error in the page to the last, and round robin to the first. Very deterministic.

The key cursor will reach the respective error area. Hence no mouse or arrow key is needed to move to the error location

With the cursor, it display clearly the error location it has reached.

All these will make the error detection and correction much easier.

In iOS, it is supposing to have the similar if not the same feature i.e. ⌘ ’ (Jump to next issue) and ⌘ ” (Jump to previous issue).

However it is relatively indeterministic.

The error sequence it moves is not really first to last (instead based on the error it detects as listed in the left panel), and across files.

The key cursor at times will stay where it was, and only the error message get selected (if it has more than one line).

Without the cursor move, at times we don’t even see that it actually move from an error to next, as illustrated below.

No wonder this is not a very popular short cut key used by most iOS developer I know of, since it is not as visible and not that deterministic.

3. Quick inbuilt code formatter

In Android Studio, it is a usual good habit after complete writing code within a file, we just press Alt ⌘ l , and enjoy seeing the code get formatted nicely to the style we wanted it to be (there’s a code formatter preference page to set). This is used even by experience coder, as it is better than human detection.

However, I didn’t find any such inbuilt feature in Xcode. There’s a third party tool Swiftlint though for the purpose. But I thought Xcode should come with something more convenient by default.

4. Quick inbuilt IMPORT sorter and optimizer

Sometimes we remove some function, and didn’t realize the its import module is no longer needed by the file. Or sometimes we add new import, and didn’t place it in a sorted position.

In Android Studio, we just need to type Control Option o , and it will perform the sorting and removal or imports automatically.

I didn’t find this feature in iOS. I’m not sure if Swiftlint will do this. Even if it does, it is still a third party tool not readily available in Xcode.

5. Need auto copy and paste when Shift ⌘ F

Shift ⌘ F is a friend to both Xcode and Android Studio users when one wanted to find something in the codes within a huge project.

In Android Studio, one could just double click to select a word, and Shift ⌘ F , then the word would be automatically copied and pasted on the search box. So convenient!

In Xcode, one has to click on the word, ⌘ c (copy the word) and Shift ⌘ F , follow by ⌘ v (paste the word). The 2 extra steps may not seems much effort, but given the frequency of Shift ⌘ F would be used, the removal of need to manually copy-&-paste would mean so much from usability point of view.

6. Use more detached Dialog Box (e.g. find, new file)

Find Feature

In Android Studio, when one perform a Shift ⌘ F ,

the find dialog is shown. It is a detached dialog box and doesn’t take up the existing space in the Project Navigation side. It’s result is shown in the dialog itself instead of the code editor. When move along the search result, it doesn’t replace the existing content of the code editor, as the result is in the dialog itself.

In iOS, when one perform a Shift ⌘ F ,

It replace the left panel with the search result panel. And it is result replace the existing shown editor. This also add to the stack of forward/backward navigation Control ⌘ → / Control ⌘ ← unnecessarily as one scroll through the search result. As user, I don’t want my Find affect my existing IDE view, unless I have found what I want, but not when I browse through the list.

New Class/File Feature

In Android Studio, a detached dialog is shown when we want to create a new file/class. This is good as I could still move the dialog around to see the the things behind (e.g. the code, if I need to refer to it for some reason)

However in iOS, it is sticky and not movable. This is preventing me from seeing what’s behind.

I once need to refer to the code behind to know the base class to inherit from, I can’t get to see it. So I have cancel the New File operation just to see the code, and redo the new File operation.

In short, if iOS uses detachable DialogBox for the above two examples, it would be much more user friendly.

7. Unintuitive breakpoint setting and removing

Below is the example of setting breaking in Xcode

Notice that

the breakpoint could be accidentally set on empty line or comment.

clicking on the breakpoint doesn’t remove it, but just disable it.

to remove it, one has to drag it to the right (I can’t figure out need to do this until I ask someone). Not an easy feat as sometime I would miss it (as could be seen in the illustration above, happens on line 16).

In Android, show as below

click to enable breakpoint (and not added if empty line or comment)

and click again to remove it. (to disable, just Option click — not shown in the illustration)

As a developer, I do create and remove tens of breakpoints daily. I would rather click to remove it than have to drag it away.

8. Pinch and un-pinch zooming editor

I firstly learn about this new gesture — pinch (zoom in) and un-pinch (zoom out) from iPhone/iPad. So intuitive. I didn’t expect any IDE to have that. If any IDE would have it, I would expect it would be from Apple (Xcode).

To my surprise, in Android Studio (IntelliJ), one could just pinch or un-pinch (mouse pad) to shrink or enlarge the code editor.

This is so cool when presenting the code to a larger group or doing pairing for clearer view by both parties.

I though Xcode would have it as well, since such intuitive item would be on Apple’s product. I was disappointed.

Nonetheless, Xcode could perform the same zoom in and out using ⌘ + and ⌘ - . It is just not as cool in my opinion.

9. In-build dependencies management system

Professional mobile development today no longer just a single module project. It is normal that we have multiple modules aside from importing 3rd party libraries in order to make a good complete project.

In Android Studio, we use the Gradle to manage such eco system. Whenever we want to sync all the dependencies, we’ll just need to click a single button (in Android Studio) that will Sync with File System . All will be done within the IDE.

Whenever the gradle file has been changed, the IDE will automatically prompt to sync as shown below. One just need to click on the Sync Now .

In Xcode, there’s no in-build system that allow management of different modules dependencies. Thankfully there’s a third party system CocoaPods.

As it is a 3rd party system, it’s operation can only be executed on the terminal. To sync all the project, one has to type

bundle exec pod install

If the Podfile has been change, no warning on the IDE, other than compile failed with confusing error messages.

How nice if Xcode has something inbuilt within, that we don’t need to leave to the terminal to do the dependencies sync process.

10. Editable/programmable user interface

This is not really an Android Studio and Xcode relater matter. But more towards Android development and iOS development.

In Android Studio, the main way to design the layout is using the XML code (at least for veteran Android Developer). The Design Interface is just secondary. It is used as reference most of the time since it was once not very reliable (though Google is trying hard to make it better and easier for people to use these days).

I love the coding approach, as when it is committed through Git, the PR process of reviewing it is possible. Check out the simple XML code below.

However in iOS, no one would write the XML to make the .xib file. It is auto generated by the Interface Builder. It is humanly impossible (for now) to manually write that. So user would use the Interface Builder as the main entry of designing the interface.

Look at the generated code (above), can’t imagine how one could review the code change easily! It probably contain lots of things that might not be needed. It is not really a developer preferred approach of designing.