Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am doing some research on Swift and its differences with Objective-C. From what I could gather, the current version of Swift is quite fast, faster even than Objective-C: see here.
However, since most of these tests are done with sorting algorithms and such, I am wondering if Swift will actually be faster than Objective-C when it is used for development of iOS apps. Can anyone enlighten me on this, preferably from their own experience.
Swift is claimed by Apple to be faster than Objective-C, and as you said it is faster in those sorting algorithms, but for the usage of iOS development, a simple user would not recognize the difference between an app developed in Swift or Objective-C. I developed a lot of apps in Objective-C that are in apple store, and now several in Swift and so far users can not tell the difference if one is much faster than the other.
Swift is unlikely to result in applications that run much faster than applications developed in Objective-C. Even though the two languages are quit different, both target the same Cocoa and Cocoa Touch APIs, iOS and OS X a, both are statically typed languages and both use the same LLVM compiler, so they are not that different after all. There will be performance differences, as the two languages aren't identical after all, but don't expect significant differences.
Swift is also developed from Apple to appeal to new programmers because it is similar to languages such as Ruby and Python than it is Objective-C.
There is a great blog-post about the improvement of Swift performance especially after the Swift 1.2 release.
The author ran several tests with different kind of code like Objc-like Swift code, Swift only and Objective-c only code. And the result was, that Swift 1.2 is much faster than before. He ran tests with JSON so it's a bit more practical than just algorithms.
Beside the 'real' performance, my personal experience about that is, that I'm developing much easier in Swift. I never liked the .h and .m files from Objective-C because it stopped the 'flow of programming'. Also I think the Syntax itself is much easier than in objective-c [with these brackets].
So I think, if you write a new Project from Scratch, Swift is much easier, faster and more elegant. (My opinion)
You can write slow code in any language and Swift is no exception. I haven't had time to fully evaluate the Swift 1.2 Beta but even before most code could be made reasonably fast but it was also very easy to make it very slow. Accessing non-final instance methods especially was very slow and Debug builds were horrifically slow (I have several cases of 100x slower than release builds). A little work to optimise the most deeply nested loops was usually enough to quickly get it somewhere close to C performance.
Most of the code you write is not that performance critical provided you can move slow operations off the main UI queue. More time will be spent in API calls and those will not be affected by the language used to call them. Even where performance is critical the amount of code that needs to be heavily optimised will tend to be small and you could switch to a faster language (e.g. C) for just those parts.
When comparing the Objective-C it is also worth considering what we mean by Objective-C. You can write C functions in Objective-C code and they will result in code as fast as C. I would say that they were C and that to meaningfully talk about Objective-C performance it should be code based on Objective-C message sending and probably NSArrays rather than raw C arrays. If that is the basis Swift (when optimised and using structs and final classes) will come out quite well. However if you are comparing with C code it will usually be the case that Swift will be slower at the moment.
I have a few blog posts about optimising Swift on my blog and I gave a short talk back in October.
Swift comparing to Objective-C has its own benefits like: Swift handles strings more easily, swift tuples offer compound variables, and furthermore, coders don't need to spend time annotating variables with type information and risk making mistakes; in most cases, the compiler can infer the type from the value that a variable is being set with.
Swift is faster compare to Objective-C; that's what Apple's Swift team claims, and it is certainly true. However, the fact is that you have to plan many things in order to write the responsive apps. Here are a few pointers:
Remove unused resources
Optimize resources for ex images
Caching
Compression
Reusable code
Object life management
Related
I want to migrate our large Objective-C-based iOS project to Swift. So what's the best way: Import Swift files into Objective-C, or import the Objective-C project into a fresh new Swift project? What will be the fastest ?
Thanks
After time I spent of the project migration to the Swift I can say that it is no silver bullet in this question. It is really depending on the flow that is set-app in the team that you are working.
From my point of view and experience you should take existing project and start to write all new logic using Swift and in parallel try to rewrite business lawyers of the application in the modern way. For example network layer, database layer. In this way you reduce regression of the application and receive controlled migration flow.
Pros:
New logic will be in Swift.
Step by step migration will balance
regression.
Suport of legacy code that impossible to rewrite to Swift
Writing code in Swift way (Protocols, Function, Generics, Structures)
Cons:
Time
Regression of the app
Quite big rewriting of the code.
If you are starting a fresh project with the aim to only use Swift in the future, then I would create a new Swift project and then link to your Objective-C framework. This is what we did where I work, and slowly over time we have been deleting from the Objective-C project anything that is not being used. This may not be quicker than importing everything into the same project, but will give your code some separation from the old Objective-C code.
It's a very complex question and the answer is: Depends...
I think there are a few questions to make before answer yours:
Is your project "open", your team is developing new features on the same code base? or has a solid and reliable code base and just a little changes?
Can your company afford a "NEW VERSION" entirely made in Swift with new engineering?
Basically, make a big refactor (as language migration) involves a re-engineering job too, most things will not work if you just transcript the code base and if you do so, you are losing all the Swift benefits and there is no Win situation to change your code.
In my point of view, creating a new project is just a good thing to do if you will make a new version of your app. Is cleaner, is better, but like I've said there will be a lot of job and re-engineering.
Otherwise, just embed Swift code into an Objective-C running app, will cause a lot of trouble and confusion. But is faster and you can continue with new features and implementing improvements on your app.
So, here is my 2 cents to your problem:
I would recommend slow code conversion or rather refactoring to Swift if required for new code parts.
Furthermore, if the converted code is currently being used in other side projects (feature branches etc.) you could not ensure that it would still work accordingly.
I hope you got unit tests in place, because those could make life easiert. Anyway, consider the aspect of regression testing of your application's features. Libraries you use, would now have to be frameworks (some Libraries might not compile as Framework, be aware of that).
IF you really want to convert the code base, I would do this hirarchically.
Consider an entire Application Layer and within this layer
specific classes.
Start writing tests for those classes (you can do that in Swift, too), Unit Test, Integration Test, UI Tests
Convert the class to a swift class (be aware that some logic might change and other functions would be affected, too)
Implement bridging header (if necessary) that you can use as Application Layer interface to the other interfaces - this would even improve your understanding of the different code parts play together. If you notice some weird declarations. Stuff being public, too much random accesses fro different classes or something. Don't touch that yet. In fact, note that down
Perform extensive tests of your small change
Start over again with the next class
If all classes have finished on your current Application Layer and you broke nothing. Good job. Now have a look for your notes.
Continue with the next layer.
In Short: I would only convert those parts to Swift that need to be changed anyway (refactoring, new features, bugs, whatever). If the code was working, and you don't see another reason than "well, now it is Swift", I would only take the conversion into account, if I really had time for that, else you might break working code or even the architecture that was setup, which differs for Swift and Objective-C in some ways.
If you really feel like you are the man for this: I would start to write tests ;-)
Unit-, Integration and UI Tests. This will help you with your CURRENT code base, but also with your future code base, whether is in Objective-C or Swift.
And it is a great help for converting the code into Swift.
I think the best way is to import the Objective-C project into a fresh new Swift. Because you can use objective c to swift converter. It saves thousands of work hours.
This question already has answers here:
Learn C first before learning Objective-C [closed]
(23 answers)
Closed 7 years ago.
I'm a novice programmer looking to build my own iOS app. I'm hearing a lot of mixed responses on how it may or may not be necessary to learn C before taking on Objective-C.
I'm leaning towards learning Objective-C first considering I can always look back into the C (I'm using Big Nerd Ranch Guide for Objective-C) for some concepts like structs, arrays, etc.
I'm open to hearing any advice on what any of you may think!
Learn C language first. Because most of the low level computer programming stuff might be covered by that and you may get to learn how to program with much primary capabilities provided within the language. Because this is mostly Procedure Oriented Programming (POP).
Then move on to learn Objective-C which is an Object Oriented Programming (OOP) Language. Here you can use the skills you used to program using that primary language and you might feel that you are provided much power within the Objective-C and also be able to describe and make use of world in more Object-Oriented manner!
And must remember, as you are going to implement iOS Applications, you better have a good knowledge about Objective-C before moving to learn Apples new language for its products like Mac OS X and iOS, which is Swift! Because Objective-C has been used by them for a long period of time, and still it's been used by them.
Here read the following question and it's answers if you want to clarify more:
Learn C first before learning Objective-C
Hint: Seems like your Question also might be closed sooner enough saying it's been duplicated or answered before! :-)
My advice would be to forget about both C and Objective-C and learn Swift. It's an easier, more contemporary language and the future of iOS development.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I was always frightened by Objective C syntax with all its *, -(), [[]] and so on. Now I am looking at Swift and from my JavaScript background as a frontend developer, I really like its elegance and clear-looking constructions. So, I wonder, do I really need to learn both Objective C (at least basics) and Swift to build apps for new iOS/OSX versions that are coming this fall?
Is there anything I won't be able to do with only Swift? Does Swift have as much access to the API and OS functionality as Objective C does? So, if I don't need to support current Objective C codebase, do I still need it in a real work or can I do all the same things with Swift?
Learning either ObjC or Swift is not the hard part. Work through your fear: it only indicates new things to learn!
Swift is also very much not like Javascript. Don't be fooled by its surface appearance (in fact, avoiding focusing on surface appearance in general is a pretty good plan).
To answer the question though: I would expect it to be a few more years before you won't get a significant benefit from knowing ObjC; there's a LOT of existing code, examples, docs, etc... all in ObjC. But there's little to nothing in the system APIs that will require it once Swift 1.0 is actually out.
Of course, this depends very much on what you are planning to do. But I think there are a some points you should consider:
Performance
According to this SO question the performance is not as good as Apple promised (yet). But if you care about high performance, you should wonder if Objective-C is your way to go.
C++ Code
Very important is the fact, that you cannot use C++ code in your Swift code without having a Objective-C(++) wrapper:
You cannot import C++ code directly into Swift. Instead, create an
Objective-C or C wrapper for C++ code.
from the Apple Swift Documentation.
Platform
Swift uses the same runtime as the existing Objective-C system and the idea of Automatic Reference Counting. So in my humble opinion a basic knowledge of Objective-C and the ideas behind helps to write better and more performant Swift code.
Existing Work
It will take some time that all frameworks, methods, classes, etc. have a pure Swift interface. Almost every demo project from Apple is written in Objective-C, too.
Conclusion
So I think, you will need some basic Objective-C knowledge in the future - maybe this changes over time. But it depends very much on what you are planing to do.
Is there anything I won't be able to do with only Swift?
Yep - if you need to support cross-platform or legacy code bases with C or C++ code there's no way yet (an not in the foreseeable future) this could be done with Swift.
I think, it's better to read about Objective-C, at least basic things in order to be able to read it, because if you are going to be an iOS/Mac developer, the chances are high that at some point you'll have to interact with Objective-C code somehow (for instance, you might need to take a look at some third party library code). Learning the basics doesn't take much time, Objective-C is actually a rather simple language. It's just not very pretty :)
The other possible necessity for Objective-C is a code optimization. High performance parts of code are often written in pure C/C++. You can't mix C/C++ code with Swift. The only way you can do it is by using an Objective-C/Objective-C++ wrapper for your C/C++ code. And that's when you're going to need Objective-C knowledge.
But actually it's possible, if I'm not mistaken, to use just Swift for development. So, my advice is the following: if you really hate Objective-C, use Swift as the main development language, but learn Objective-C basics in order to be able to read it (at least). Just in case.
Since the cocoa libaries (Foundation, UIKit, CoreData etc.) are written in Objective-C and not converted to Swift (yet?) do we still get the performance benefits which Swift offers, when calling these cocoa libaries in Swift vs. using the libaries along with Objective-C (which has been the case until now)?
Erm...
The system frameworks are the system frameworks. They will perform the same regardless of which language they are called from.
Apple has millions of lines of code in their frameworks. (probably hundreds of millions of lines.) I doubt if they are going to be mass-converting all those frameworks to Swift. Instead, as they update and expand their frameworks, they will probably use Swift rather than Objective C where it's appropriate, and then provide interfaces for both languages. The transition in Apple's code is likely to be limited to new APIs and/or APIs where they are doing a major overhaul for some other reason.
When you look at the performance of an app, it usually boils down to a small amount of code that is the bottleneck and takes the bulk of the time. Optimizing other parts of your program have very little effect.
If your program winds up spending most of it's time in application frameworks, then it doesn't matter if it's written in Objective C, Swift, native assembler, or Java.
Personally, I am very skeptical of Apple's claims of huge performance benefits from Swift. I suspect that their comparisons deliberately picked problems that have very bad performance characteristics when written in "pure" Objective-C (ignoring the fact that Objective-C is a true superset of C, and you can always write C code in an Objective-C program.)
I am an old assembler jockey, and a C programmer after that. When I do application design, I avoid creating objects that represent tiny atoms of data, minimize memory allocations in tight loops, and will even sometimes write critical code using C functions rather than Objective-C method calls. I already optimize my design and implementation with an awareness of what slows programs down. I would hazard a bet that with this approach, the difference between Swift and Objective-C code is small. If we have less control in Swift over what is an object and what is a simple array of scalar values, I would expect careful coding would still yield better performance with a mix of C and Objective-C.
Another point is that usually your algorithms make much more difference than your implementation. If you use a bubble sort on a million records, it's gonna be dog-slow even if you write the slickest, most highly optimized implementation of a bubble sort.
Example:
Our company has a Mac program, FractalWorks, (link) in the Mac App store. It is a very high performance fractal renderer. Internally, it allocates a block of memory to store results, and then uses carefully crafted C code to do the number-crunching. It is multi-threaded, and keeps every core on your Mac "maxed out" until the calculations are done. When possible, it also uses knowledge of the geometry of Mandelbrot and Julia sets to use a "boundary following" algorithm, and traces the outside of regions that have the same "iteration value", and then flood-fills the whole region, thus often saving millions or even billions of expensive floating-point calculations. The first part, using memory buffers and C code to calculate results, is implementation optimization. The second bit, the boundary following algorithm, is an algorithm optimization, and for problems where it's a good fit, it can reduce the number of calculations by 5X or even 10X.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We want to develop an application for iOS and Android smartphones. We are mainly using Microsoft technologies for developing our applications. We thought that if we would use MonoTouch and Mono for Android we would only have to maintain one code base with only a different UI layer for each device.
Because currently nobody in our small team ever developed a smartphone application and we need it quickly we want to outsource it. We asked other companies whether they perfer MonoTouch or Objective C for iPhone development. Most of them said, that the would choose Objective C. They said that Objective C offers more functionality and possibilities, it's faster and for MonoTouch there is a chance that Apple will not support it anymore in the future. Is all of that true or are there other reasons to prefer Objective C? I know there are other threads like this around, but they did not answer my questions, especially the one regarding Apple's support for MonoTouch.
applications. We thought that if we would use MonoTouch and Mono for
Android we would only have to maintain one code base with only a
different UI layer for each device.
this is a possibility IF you structure your app right. If not: no.
If you use Java+ObjC+C# (for WP7 / Win8 metro etc) then this is not an option AT ALL
Because currently nobody in our
small team ever developed a smartphone application and we need it
quickly we want to outsource it. We asked other companies whether they
perfer MonoTouch or Objective C for iPhone development. Most of them
said, that the would choose Objective C.
If you are outsourcing it, you should dictate what you want it written in, surely? If you need to support it in-house, and you only have C# skills, then MonoTouch etc makes more sense for you, the people paying the bills!
They said that Objective C
offers more functionality and possibilities,
FUD, and also incorrect. Monotouch has the full API available. If it's not there, as Xamarin to bind it (which they have done often before)
it's faster
I'd love to see the benchmark. Yes, technically, it can be faster in some circumstances, but in general use, MonoTouch the same or quicker.
Programmer error is a more common cause of iOS app performance problems. eg not getting things off the UI thread (which is easier to do in MonoTouch than in ObjC, tho blocks have helped that a lot), or taking too long to get out of FinishedLaunching (the "main" method, if you will, tho it's not really...)
Garbage collection and things like linq, xml/json parsing, generics and collections are also hugely valuable, and very quick.
and for
MonoTouch there is a chance that Apple will not support it anymore in
the future.
yes, there is a chance. There is also a chance that Tim Cook will run off with Apple's billions and buy all of Hawaii (rather than Larry Ellison's "I'll just have this island" purchase). But the chances are now rather slim.
Is all of that true or are there other reasons to prefer
Objective C? I know there are other threads like this around, but they
did not answer my questions, especially the one regarding Apple's
support for MonoTouch.
Apple doesn't support MonoTouch. Xamarin does, and they do it exceptionally well. Apple doesn't support anything except XCode, which is their product.
Apple DOES allow MonoTouch apps (there are lots). Another way to look at it: usually, 95% of the top 100 games are written using Unity3D, which is based on the same techniques (ahead-of-time compilation of C# code and embedding a cutdown version of the Mono/.NET framework).
There ARE reasons to prefer ObjC which would be:
You already know ObjC and CocoaTouch and like it.
Your team already knows ObjC and CocoaTouch or you can easily hire people who do (note: currently, as far as I know, iOS developers are CRAZY expensive to hire, if you can get them)
You need to use the beta's the day they come out. Keep in mind that you can use the current MonoTouch and deploy to your iOS[REDACTED] device with the beta on it. You just can't use the new stuff in iOS6 YET (Xamarin said "around 2 weeks" which should be about now...). Also keep in mind that you can not deploy an app to the store which is built with the beta SDK, even if you don't use any of the stuff in it. You can't even mention iOS[REDACTED] in your product description (I've tried)
you love [squareBrackets andTheOccasional:#"strange syntax things"];
Now, will building a cross platform, shared code app be an easy undertaking? HELL NO. It's a very complex piece of development for a non-trivial application. But thats the fun part of software development: if it was easy, it'd be boring! Grab Greg Shackles book ( http://www.amazon.com/dp/1449320236 ) to get an idea of whats needed for iOS+WinPhone+Android style development.
My hunch is that the companies you talked to simply are used to using Objective-C. That's where their skills lie, and that's the biggest reason why they would prefer not to deviate from their path. The other reasons can be argued both ways.
It's true that no one can predict what Apple will do, but there's a very small likelihood that Apple will ban third-party toolkits & APIs like they did in the summer of 2010. That was only a short period of time, and they completely reversed that decision. Their current focus is on making app development easier, which means keeping the field open to alternative development methods. I think MonoTouch is safe.
As for speed, C# generally produces very fast executables. They may not be quite as fast as Objective-C, but I doubt you'd notice a difference. I remember seeing a website somewhere that showed C# outperforming C/C++ in some tests, but that was in the .NET environment, not Mono... and unfortunately I can't find the reference anymore. I'll keep looking. But the bottom line on speed is that C# speeds are very good. It's not like BASIC vs C. More like Java/JIT vs C.
C# gives you many, many(!) advantages over Objective-C, and they have been enumerated in other Stack Overflow answers, so I won't repeat them here. You can find them easily enough.
I'm an obvious fan of MonoTouch, but I do have to say one thing: I think it's a mistake for companies to think that because they are fluent in C#/.NET that they will easily be able to develop and/or maintain iOS apps using MonoTouch. It's just not true, because MonoTouch is basically a C# layer over the CocoaTouch API, meaning that you have to learn the Apple way of doing things. You have app delegates and view controllers and all the UIKit stuff. There's a real learning curve there. But if you're fluent in C#, MonoTouch will be a huge help.
UPDATE:
I found the article on C# speed: Head-to-head benchmark: C++ vs .NET
I have actually used MonoTouch for every app I've ever developed. Performance has never been an issue, and I can't imagine how bad for me it would have been using Objective-C. I've had 2 top 10 apps in the US app store: "Draw A Stickman" and "Draw A Stickman: Episode 2" (don't worry we are working on more).
If you know C# and .Net your gains in productivity are going to be massive compared to what would happen trying to learn Objective-C. I was a C# .Net developer (Windows only) prior to iOS development and the transition to MonoTouch is great.
If you like Linq, parsing XML in fewer than 100 lines, garbage collection, generics, simple multi-threading, and no weird square brackets, MonoTouch is for you.
I use both Objective-C and c# (MonoTouch & Droid), and I really like both. When I'm coding in c#, there are plenty of features such as Linq which I'd love in Obj-C, & when I'm coding in Obj-C there are plenty of things I'd love to have in c#, but I adapt to whatever I'm coding in quickly enough. Re performance, I've detected no difference at all, even for fairly graphic-intensive stuff, so I wouldn't use that as a reason not to use c#.
I think it's ultimately down to what you're comfortable coding in, though of course with a well designed cross-platform project, you CAN have fully cross-platform core code if you use Mono, and you'll only have to do the UI stuff in a platform-specific way - when it comes to this obviously you'll need to know the native stuff to get your UIs working in a way which is appropriate to the platform and familiar to its users.
We have a line of business app that uses MS SQL as a data store, and has WinForms and web UI's. It integrates with our windows mobile 6.5 and tablet apps with web services. All c#.
We've fully committed to MonoTouch after some experiments in Objective-C and HTML-5 (we had working prototypes): we get to re-use our business logic, and we're comfortable developing new code in c#.
Our business logic is constantly being enhanced, and these enhancements are immediately visible to the mobile app - without having to replicate the logic in Objective-C or C++.
Our main issue is finding a c# programmer who's comfortable with the iPhone and iPad UI's.
MonoTouch is stable and we've encountered no limitations (we're binding to the same iOS API that Objective-C binds to). During our learning curve, we've had question, bumped into bugs and have had some misunderstandings - but the support from Xamarin is superb.
Performance has been a non-issue - our app is snappy even though it's doing a lot behind the scenes.
No body can tell you for sure what will apple support and what it will not support in the future, however apple had some issues with mono in the past, and since history tends to repeat itself, then it may be a possibility of that to happen again
Having said that, always go with the native application development SDKS and environments, it will be more flexible, and it will be updated real time, and performance will always be better in the native