Some background info: Syntax color/highlighting and auto-suggest stopped working correctly. I read a lot of questions about how to fix this but none of them helped me as they were related to Derived Data.
I'm learning Swift from some online tutorials, and noticed my syntax highlighting was different to that of the course teacher's. Then I noticed that when I create an instance of my struct, and use the dot syntax after the instance, Xcode didn't auto-suggest the struct's functions and variables, whereas it does in the downloaded version of the project. After some investigation I noticed that a key difference between my project and the teacher's is that my project has a Deployment Target of 8.1, whereas the teacher's has 8.0. I changed mine to 8.0 and immediately the syntax highlighting was restored and I could access the struct instance's functions and variables.
I'm guessing this may be a bug in Xcode, but perhaps I have something misconfigured in Xcode? I'd be grateful if anyone could explain how/why this bug occurred and what is best practice when choosing the Deployment Target.
The setting is located at Project > General > Deployment Info
I hope the above info may help others who encounter this issue.
Deployment Target is the iOS version that your app is intended for. This does not mean it is incompatible with other versions, simply that it is designed to work best on that version. Generally, using the app on a device with a newer version of the OS is much safer and less likely than using the app on a device with an older version of the OS. There's actually a lot of restrictions around installing an app with a deployment target higher than the OS version on the phone.
The most common deployment target right now is going to be 7.x, as most apps were updated when iOS 7 first came out (there was a pretty big change in UI standards and SDK functionality from 6 to 7), and iOS 8 isn't too terribly different from 7, so there's no need to restrict it and/or write new versions of the app for the new SDK. By having a deployment target of 7.x, you should ensure that the app works well on 7.x and all higher versions, including 8.x. You should also have the lowest deployment target you can that's reasonable - so, a purely iOS 8 app should ideally be targeting iOS 8.0. You'll save yourself a lot of PR and invalid bug reports from users who don't understand versioning.
In your scenario, it sounds like there may be a bug in Xcode when using the iOS 8.1 deployment target. You might want to check and see if your docs are downloaded. Go to Xcode -> Preferences -> Downloads and ensure everything is downloaded. I'm not sure if these are actually used in syntax highlighting and completion code, but it's possible. I would also do clean the build folder (Product -> Hold Alt -> Clean Build Folder). Again, I'm not sure, but I think there's just some small thing that's not clicking here. I'm assuming you cleared Derived Data based on your first paragraph - if not, do that (Window -> Organizer -> Select Project -> Delete).
Related
I just installed the Xcode 9 for iOS 11 for my older project to update.
But it's taking too much time to load the app in Simulator as well as in iOS devices.
Are there any settings that I need to change in Xcode?
Also, I found one major issue is hitting the Mac machine.
I found another problem with Xcode recommended settings for Pods.
If you accept recommended settings, Xcode changes optimization level for Pods project to "Fast, Whole Module Optimization". It changes both of Debug and Release. You can change manually only for Release. That fixed my unnecessary building problem.
If you accepted recommended settings before, close Xcode and update and re-install pods. Than change optimization level for Pods project manually.
My First Answer
Commit changes and try again. It worked for me.
If you don't use git or another source control, you can find commit in Xcode's "Source Control" menu.
I'm not sure but It's good to clean compiled things too.
(on XCode menu > Product > Clean)
Sometimes delayed launching is because of large chunks of data being bundled with the app.
For eg: If you are uplaoding a json with huge data, the app will take time to process , bundle and install it which subsequently will lead to a delayed launch of the app.
So you need to verify whether something like that has been added to your project.
I'm struggling with this problem for nearly half a year now with multiple XCode versions and Macs.
I can't reproduce bug steps exactly but the things go off when project has multiple targets like for Mac and iOS.
First of all XCode declines to take #if os into account and always highlight syntax only in one type of sections. E.g. if I have os(iOS) and os(OSX) somewhere it will chose only one and highlight only them.
Same goes for autocompletion. Things just not working in that type of projects.
I really dont know what to do since developmenet process turns into struggling. I dont want to split my project into multiple one, I'm happy with multi-target setup.
Is there a way to fix that?
Almost a year late.
Anyway I faced the same situation where a multi target OSX/iOS application in Xcode did not take into account the #if TARGET_OS_IPHONE conditional and failed to autocomplete method names from framework only showing the iOS variant.
Found a solution, based on this blog entry : you have to clearly state the Framework search path on each target in Build settings
Edit: This line was present in the iOS target settings. I copy/pasted it to the MacOS target in Xcode where it was automatically adjusted to the right path.
Edit 2: Loosely related but if you run in trouble with interface builder picking wrong classe files see this answer I just posted in another old thread.
Is there a way to have Xcode tell me when I'm calling a method that isn't available in the SDK of the minimum supported target?
For example, the method [NSURLConnection sendAsynchronousRequest:queue:completionHandler:]. This method is available on iOS5 and up. But my application's minimum target is iOS4.
If I use that method (sendAsync), I'd like Xcode to tell me that that method isn't available for the minimum target I'm trying to support.
I've tried putting __IPHONE_OS_VERSION_MAX_ALLOWED=40000 in the preprocessor settings, but that just triggers a bunch of Apple SDK errors that aren't helpful. (Probably because my active SDK is iOS5.1)
Is the only solution to get ahold of old SDKs and install them in Xcode?
Are there any easier solutions?
There is unfortunately no standard way of doing this. By setting the target OS to a lower number than the base SDK, Xcode will weakly link the libraries and frameworks. When doing that Xcode will not warn you for using methods that may not be available on the target OS.
You could temporarily set the base SDK lower, but that might not always work. Since you want to ignore most of the errors and warnings produced (because they are only called conditionally in your code path), and many warnings and errors are dependant on other error that you may need to resolve before the compiler will give any meaningful output.
I do not think there exist any static analysis tools for this, neither from Apple nor third party.
After doing some research, reading the Apple Doc about it, and trying a number of things. The solution is downloading an old Xcode DMG from Apple, grab the .pkg file for the same SDK as your deployment target and install it in your version of Xcode. Here's how:
Download older Xcode.dmg from Apple
Open the DMG
In Terminal, go into packages: "cd /Volumes/[DMG]/Packages; open ."
Find the SDK you want, something like iPhoneSDK_4.0.pkg
Install that package, but change the install directory to /Applications/Xcode/Contents/Developer
Restart Xcode if it was open.
Now that you have the same SDK as your deployment target, set your BaseSDK to the same. When you build you'll get warnings about missing methods. Your project may or may not successfully build with an older BaseSDK in a new version of Xcode, but that doesn't matter - you've just found the method calls you need to wrap in a feature check with respondsToSelector:.
As of Xcode 7.3, the compiler can now generate these warnings for you. All you need to do is set the -Wpartial-availability warning flag in the Build Settings, as described in this answer.
I recently added other language support to my ios project.
Then, I continued to develop.
Now if I turn my language back to English it runs an older (way older) version of the app and I don't know why since the storyboard and code are all correct in the project.
Any hint?
if I turn my language back to english it runs an older (way older) version of the app
This sort of thing is often caused by having old files lying around in the built app, even if they have been changed in the project. Try following my instructions for cleaning the caches and getting rid of all copies of the build app, here:
https://stackoverflow.com/a/6247073/341994
I have an old app I maintaining. The app was first compiled on XCode 4.2. If I take the exact same project that works find and compile it on XCode 4.6 I'll get weird bugs such as ViewControllers not refreshing, Back doesn't work as it should etc'. If I'll take the same project and recompile it on xcode 4.2 on my other machine everything will work fine. Before I'm digging into the code, can someone give me an idea why something like this may happen? My main suspect is the Base SDK of each Xcode. Does that make sense?
I couldn't tell you if there will be a difference between 4.2 and 4.6, but historically the iOS frameworks on the device (and, to a lesser degree, the simulator) do adapt slightly depending on what version of the SDK an application was compiled against. You can't rule it out.
A classic (though now ancient) example is backgrounding. Apps built against older SDKs were quit when the Home button was pushed, rather than getting the newer behaviour. More recent (but subtle) examples have included several changes to table views and changes to device rotation.
You should not attempt to build with an older SDK using a newer compiler. Apple doesn't support that kind of configuration. You should always use the latest SDK. And you wouldn't want to pretend these problems don't exist, anyway: The bugs are real, they were just hidden before.
It's unlikely that you won't be able to fix those bugs in such a way that the older versions of iOS continue to function (though you may discover it opens a can of worms that you decide isn't worth fixing for older OSes).