Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 1 year ago.
Improve this question
Previously with objective-c code, I could "Analyze" - CMD + Shift + B and Xcode would warn me of all kinds of wrongdoings on my part.
It seems that with Swift, I can do no wrong! No warnings of any kind! But clearly there is a memory leak in my code.
Is there some setting I have to enable to get Swift to analyze my code properly? (I am aware I should use the profiler and test on an actual device, which I do, but I wonder why "Analyze" doesn't do anything.
Unfortunately no. Even many releases later, the latest version of XCode (6.4) still cannot do Swift analysis. The 'Analyze' option only works for the Objective C files in your project.
Let's hope the next version will have it, along with the refactoring capabilities which also are still limited to Objective C code.
To this moment (Xcode 8.3.x) Static Code analysis skips Swift code. Some Swift warnings cover some of the issues previously detected by the analyzer.
Also the upcoming Xcode 9 (presented in WWDC 2017) does not announce any change in this direction.
Many issues detected by the static Analyzer of Obj-C are for the most part prevented by the actual Swift language (e.g. unintended fall-through in switch statements). Other issues and scenarios formerly caught by the analyser, are now caught directly by the Swift compiler.
Many flows and scenarios leading to program crash - (e.g. accessing null pointers, leaving dangling pointers, or accessing released memory blocks) are hardly possible in Swift. Swift strong typing, heavy use of optionals, the requirement to completely cover protocols, and switch-case over enums, etc. remove another bunch of issues previously found by the analyzer.
A Swift static code analyzer will need to go to another level in analyzing program logic, which is much harder, and theoretically impossible to do completely.
So - although I'm quite thrilled to think of some future Xcode Analyzer, I wouldn't hold my breath waiting for it
Update:
As more and more people are down voting my post, just small update from my side. It seems that indeed apple just did allow for pressing option "Analyze" but in the background it does nothing (state for 2016.04.21, though I am not working on iOS for the moment and probably I don't have the latest version of Xcode).
below my original post:
Just for next readers of this article. At this moment Xcode 7 is already able to analyze also Swift projects. Refactoring is still not working though.
BR,
Darek
Related
I work with an App that's 100% Objective-C and I'd like to start transitioning over to include Swift. Due to the size of the codebase, it's unrealistic that I'll have a 100% Swift app anytime soon.
As soon as a swift file is added, I noticed that the app size increases because now, the app needs to the include Swift run-time.
How else does things change? As soon as you include a Swift file, what is the process that the compiler and linker undergoes to ship a binary that is now multiple language & related frameworks?
Are there any other caveats in transitioning into a mixed language world in a somewhat large codebase?
In my experience, it works surprisingly well. It is advisable however, to wait to Xcode 7 / Swift 2.0 / Objective-C with generics support as that will eliminate a round of updates, allow you to interop from Objective-C with more elegant Swift code, and eliminate the Swift RT linking concern now that they have stabilized the runtime.
Aside from that, both compilers need to run, Swift first, Objective-C second, the swiftc compiler can be pretty fast or really really slow, depending on what innocent and otherwise legal Swift code that you write (this is also true of a Swift-only app of course).
Getting started, you need to read the interop guide, learn how the bridging header works, and are then mostly on your way. I would say that having a mixed app is actually a blessing as you are not pressed to learn and do everything at once. Opinions will vary of course, but this is mine.
I'm working on a project that draws functions on a plane (Similar to Apple's Grapher utility).
I'have already compiled this app few months ago in Obj-C, and was running clean and fast.
With Swift, I changed a bit the scheme of the app, but I'm still using CGMathParser, a great collection of classes to manipulate and evaluate strings like y=sin(x) or y=log(tan(x))
However the app is now slow and laggy, and I'm thinking that the reason hides in the fact that I'm mixing Swift with Obj-C.
Do you know if there is any kind of parser already optimized for Swift that will be fast enough?
The Swift compiler enforces bounds checks and various other 'safety' features. If you compile with the -Ofast option these checks are removed, which typically makes your app run a lot faster.
If I distribute an iOS app with debugging turned on how much of the code can be reconstructed by an evil person?
I am asking about an evil person being able to quickly reconstruct the source code, not about philosophical questions.
The core of my question is: what aspects of the source code are inserted by the compiler (gcc or llvm in my particular case) into the source code.
When creating a simple app with Monocross (using MonoTouch) and compiling for an iOS device I get some bad warnings, like this:
Warning MT4112: The registrar found a generic type: MonoCross.Touch.MXTouchViewController`1. Registering generic types with ObjectiveC is not supported, and will lead to random behavior and/or crashes. (MT4112).
I've read all I can find about using MonoTouch with generics on an iOS device and it's mostly not supported. My app currently works on an actual device, but the warnings worries me.
I guess my question is, what is the state of Monocross when you get these warnings even with the simplest of apps? Is it still not ready for professional use or are the warnings not relevant for the way generics is used in Monocross?
I can also add the following from Xamarin.iOS docs:
"Xamarin.iOS does not currently support creating generic subclasses of the NSObject class"
Which is exactly what Monocross does, with for example the MXTouchTableViewController class.
There is some history to this: creating generic subclasses of NSObject has never been a supported scenario, but unfortunately MonoTouch never enforced, nor warned about this fact. So people of course ended up doing exactly this.
Then one day I had to track down something that looked like a true heisenbug, and it turned out (after many hours of frustrating debugging) to be because the project in question was using generic subclasses of NSObject. The exact details are not important, but that's when the warning was added to MonoTouch.
My point here is people have been using generic subclasses of NSObject for a long time, without running into any problems. If you test your app extensively (which you should do anyway), don't worry about this.
But if you do run into strange and inexplicable behavior, we'll most likely ask you to fix these warnings before looking into any claims that you've found a bug in MonoTouch.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I've heard that apple drops a lot of app submissions due to their stiff terms.
I dont want to get too far with my project because i know that it will be hard
to rewrite it later.
Now i began rewriting it to Objective-C (from c++) because i got somehow the
impression that apple takes only pure objective-c code. In some places on the
net, people offers solutions in c\c++ for problems which cannot be solved
with objective-c which makes me kinda think rewriting again.
In order to clear things out, can someone please give me a direction to where can
i find those iphone-code-terms of apple?
You can use C++ or Objective C++ in an iPhone app for the AppStore. There's no problem with that. Obviously you'll need some Objective C or Objective C++ in order to present a UI to the user, but everything else can be straight C++ if you're so inclined. Many applications (particularly game ports) take this approach, using C/C++ code developed on other platforms, and 'wrapping' it in an Objective C shell.
You can use any language you like, provided it is compiled code. Interpreters are banned, which means no Python or Ruby... but you can use Lua, lisp, C, C++, Obj-C, Java (using something like gcj, not a JVM), D, Haskell, or anything else that can compile to ARM code or a static LLVM backend.
At least the SpeakHere sample application makes extensive use of C++. If that has, chances are that many sample apps do (and hence that your app may use C++/Objective-C++).
Objective C is a super set of C++, so it should be no problem if you use C++. The full terms and condition are at http://developer.apple.com/iphone which is a must for any iPhone developer. The SDK is part of the 99US$ membership and includes tools you will need, such as the iPhone simulator and tools to allow you to test your app on your real iPhone. Additionally, you will need this membership to submit your app to the appstore.