Some iOS Developers prefer Swift, some deal with Objective-C. What reasons do they have to be for one language against the other? What are the pros and cons? And how can programmers help each other to build the best apps possible in the most efficient way? XSolve set two iOS developers on the ring and let them fight. So, let’s start the clash!

swift_vs_objective_xsolve

Marek Kojder, iOS developer, Obj-C advocate:

What I like in Objective-C?

1. It has been developed for a long time (1983) and it does not change the syntax but expands it by adding new classes and opportunities.

Radek Budzik, iOS developer, Swift believer:

Due to the fact that this language has been developed for a long time, and a lot of new elements have been added, such as blocks for example, this language has become a bit messy for me. It’s like a designing a passenger and then modifying it on the truck. Of course you can do it, but once there will come a moment that I will show you that it’s better to start from scratch with a new project of the truck. Apple has come to this point and praise them for it.

Marek: The programming language as well as natural language is created by people and for people and it naturally evolves. The same will happen with Swift.

Marek: 2. This is an extension of the C language, so you can use the modules and libraries written in C and it even allows low-level programming (which is not often necessary, but it happened to me).

Radek: As far as I know, you can still use the things written in C and provide low-level programming.

Marek: 3. The syntax for people getting to know the language can be a bit strange, but after getting used to calling methods in square brackets (the biggest change from C or C ++) the code turns out to be very clear and transparent; in particular, I like the ability to format the code so that the following parameters method can be found in the following lines, one under the other.

Radek: I have never treated Objective-C syntax as its advantage. But I don’t think this is a major flaw. You can be used to this inconvenience. A small drawback is the unreadable code for programmers writing in other languages. Also, it’s a bit difficult to work on two projects simultaneously with Objective-C and another language. 

Marek: 4. The use of files with the extensions * .h and * .m allows you to display clearly separate public and private parts of the class. The vast majority of libraries for iOS or OSX are written in it and connecting them does not cause problems.

Radek: Public variables are stored in the .h file and the private variables in the .m file. You need to toggle between these files. You also have almost twice more files in the project. Moreover, in the protected mode where you have to create another pair of files .m + .h the result is that many developers make the job public to expedite the work. How does it look in Swift? Just like in other languages. You just use the modifier “public”, “internal”, “private” at the declaration of variables. 

Our iOS app developers during hot discussion

Objective-C-Beast vs Captain Swift

Marek: What I don’t like in Swift?

1. With every update, method names change as well as syntax.

2. Dynamic typing. When you watch a code it’s hard to determine what type it is. During programming the biggest problem is when you need to have a object of particular type and you must cast it.

3. A new type of “optional”, which is a structure consisting of a null value (nil), and the object of the class (optional ‘String’ is a structure consisting of ‘nil’ and the ‘String’, and you write it as ‘String?’). In my opinion this is the assumption that the programmer can’t take care of checking if the object is not empty. It causes more problems than facilities.

Radek: In Objective-C, nothing happens if you call out a method on an uninitialized object. This leads to many difficulties in debugging unpredictable problems. In Swift such error can be noticed already at the stage of compilation. Debugging such errors is just a waste of time and money.

Marek: It’s not true! If something is optional type, compiler will be silent as the grave! 

Radek: The same as in Objective-C but in Swift you can use variables without optional type so such error can be noticed already at the stage of compilation.

Marek: 4. No need to attach other classes of our project. Sure, it reduces the amount of written code by about few lines, but it doesn’t give us the control over what must be visible and where. Rarely there’s a need to have a class available in every file of the project.

Radek: Hard to claim whether no imports is an advantage or disadvantage. Apparently, this is a drawback, but if you begin to use a class in another class, it means that you need it. If you need it, in Swift you just have to access it without any additional steps. The downside is that you don’t have that one place at the top of the file where you can realise what the class uses. 

Marek: This is a flaw and I am not discussing with this. Cases with the use of a single classthroughout the following project can be counted on the fingers of one hand. This practice is even discouraged. That is probably the result of environmental problems in prompting syntax.

Marek: 5. All variables and methods within a class are seen as global, so we don’t need to call them by referring to itself (‘self’). Because of that, when we read the code we don’t know whether the variable is declared locally in the method, or perhaps in the class. In addition it can cause problems with naming the variables. Xcode has also problems with formatting and syntax prompting.

Radek: Swift has much more coherent memory management. In Objective-C there is no ARC for procedural C and CoreGraphics. Thus, the programmer has to take care of memory management. Huge leakage due to errors in Swift developers no longer happens.

Marek: Not everything can be automatized. The programmer is intended to be a professional who knows what and how he or she wants to achieve. I don’t like machines to relieve me in what I want to accomplish in my own way, even if the machine can do it better than I…

Radek: Maybe you should write in assembler? 😉 Swift does not need new code as much as Objective-C. Swift has many features to make your code more expressive such as:

#Tuples and multiple return values

#Native error handling using try / catch / throw

#String concatenation with the + operator

There’s a lot of similar improvements. In Swift there is no conflict in the open source projects, because there are namespaces. In Objective-C, you avoid this problem by adding the company prefix to each class, so XSolve have to use the class XSCar to avoid collision with another class called Car. This is not perfect and safe solution and possible conflict are hard to detect.

Marek: Even Swift needs to use a String (format:”…”) if you want to display, for example, floating-point numbers with a certain accuracy, so your argument is invalid. In addition, the names of methods may be long, but a great advantage is that the code written in Objective-C is self-commenting and it facilitates the work very much. Moreover, the environment made the prompting of syntax in Objective-C quite well, which cannot be said about Swift. Returning multiple values ​​can be a nice hack, but it is difficult to read and can augment errors. For example, you get back two Ints and if someone uses your method how do you know which place is returned?


OK, let’s finish the clash. You’ve got one hit to go.

Radek Budzik

Apple has replaced Objective-C with Swift. Who quickly adjusts, gains. It is known that there are some cases when Objective-C can be better than Swift. For example, a project that needs to be done in a very short time, and then developing is over. But it’s a very specific exception. Each project which will no longer be maintained should already be written in Swift. Swift is the future. It is almost guaranteed that Objective-C will no longer to be supported and switch to Swift will be a necessity. So, it’s better for us to anticipate the upcoming future and jump up to Swift.

Marek Kojder

Swift is a BETA! Swift has been created by several developers and released for testing. It doesn’t matter that Swift is promoted as a something wonderful. This language is going to be developed and improved for a long time. I see the fascination only with developers who didn’t have much to do with Objective-C. Experienced programmers treat Swift very suspiciously and they will not use it until Swift goes through its childhood diseases.

Radek: No, it is not BETA! Current version is 1.2 and version 2.0 was announced at WDCC.

Marek_radek_xSolve_ios

Who’s the winner? Objective-C or Swift? Post what you think in the comments below!


Photo credits: XSolve, devmonologue.com, wikia.com.


XSolve is a company with more than 10 year experience, including Mobile App Development. Last time we’ve finished some great projects – games, management tool for Scrum teams or apps for sales representatives in pharmaceutical market, used by top brands around the world. If you have any questions, please contact us!

Comments
  1. melling
  2. Kamal
  3. Kamal
  4. Arun
  5. alek432

Leave a Reply

Your email address will not be published.

white Land Rover
Business Featured Post

How BlaBlaCar beat the competition in the race for market domination in 27 countries.

When BlaBlaCar approached XSolve, they were at a stage of rapid growth with around 24 million users already buzzing about their excellent carpooling platform. But the visionaries at BlaBlaCar...

ebook cover
Business Featured Post

E-book: How to Create an Agile Office

We present to you an e-book which collects all our experiences and thoughts regarding creation of an agile office. Hands on, practical, functional. This resource was created primarily for...

Holacracy why it’s a good idea to share the power
Business Featured Post

Holacracy: why it’s a good idea to share the power

We are on standing on the brink of the AI revolution. Researchers at the University of Oxford predict that in the next two decades up to 66% of American...

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies.

To find out more click here

Ok, Thanks