I'm updating my app to support iOS 11 and I added the large titles options in the interface builder. Now I'm getting these "Attribute unavailable - prefers large titles before iOS 11.0" warnings.
I know I can set the options programmatically, but that's causing some other problems, so I was hoping I could keep it at the storyboard and just ignore the warnings. If the options aren't available that's fine, just don't use them. Is there a way to do that?
I know there are other questions asking the same thing, but they're pretty old and the answers end up working around it instead of really dealing with the warnings.
As the error states, your app is probably targeting iOS <11 so the attribute will not be used for earlier versions.
Have you tested your app in iOS 11 and 10 ?
Solutions:
Disable that feature
Set it in code using if #available (Best option if you want to maintain compatibility with earlier iOS versions and use that feature)
Set the target of your project to iOS 11
Suppress all warnings / Storyboard files only (Not recommended)
Since the OP does not state whether Swift or Objective-C is being used, I will post both versions.
Swift 2.0+: if #available(iOS 11, *) {}
Obj-C: if (#available(iOS 11, *)) {}
Courtesy of How to check iOS version?
As a side note I was able to suppress the specific warning with
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunguarded-availability"
... your code here ...
#pragma GCC diagnostic pop
Not recommending that - but as a quick fix it works.
Related
What is the min iOS which works well with Swift 5.1 or incoming Swift 5.2?
Are there any references to check this?
A similar question has been asked before, when Swift 4 came out. You can find the question and answer here.
Having that said, the swift.org site and the release notes only specify the compatibility with previous Swift versions, the operating systems and the toolchain (Xcode). So, a straight forward answer can't be given to this question.
Since Swift 5.1 is compatible with Swift 4, you can safely assume the code will run iOS 11 and probably iOS 10 as well. There are, however, some incompatibilities between Swift 5.1 and Swift 4, see for the details this link. I think you should also be aware of the fact that as of iOS 11 32 bit is not being supported anymore.
The next issue you will definitely run into are the deprecated functions in iOS. You have to build your code in the productive version of Xcode and that tool will throw errors and warnings for deprecated functions or variables being changed. For instance, the key "[UIImagePickerControllerOriginalImage" has been changed to "UIImagePickerController.InfoKey.originalImage". at the moment Xcode 11.3 doesn't let you specify below 12.1, so you will run into these problems when updating source code written in an older version.
I have used AlertView in my project. Since it is deprecated now it shows warnings. If I suppress these warnings without clearing it (by using AlertController) will it affect my project later.
no it won't affect your projcet for the moment, but since they are deprecated, AlertView in the future may be deleted by swift, and then you will have serious problems, so better change them while you are in time. :)
Let's say I have a Xcode project with the deployment target of 8.0 and iOS 10 got released. The app gets build and released - the deployment target stays the same.
My questions are:
Do the newly added deprecations impact the stability of the app for a device running iOS 10?
Do I have to adjust my implementations to get rid of the deprecated code even Xcode does not show me any warnings? (the warnings when I would set the deployment target to iOS 10)
Currently I only add if #available checks for deprecated code that Xcode shows as warnings.
Yes and no... Normally code is deprecated because it's no longer maintained, and or has known issues. Nothing should directly change for deprecated code between the time before it was deprecated and afterwards, so nothing should reduce stability etc. However, the fact that it is deprecated should make you keener to change it to the recommended replacement.
It should probably be noted that deprectaed methods tend to not disappear, despite that being the intention of deprecation. As the backwards compatibility would be broken, unless there are very serious security / privacy concerns, it's not likely a deprecated method would be removed.
It should also be noted that unlikely things happen with a greater frequency than one would expect ;)
"Deprecated" means it will disappear in a future version, so you should replace the code as soon as possible.
There are many deprecated methods that are trivial to replace, or almost trivial with the replacement having better functionality; in those cases you should replace the method now.
There are cases where there is non-trivial effort. Worse, there are some cases where a method may be deprecated in iOS 10 with a nice replacement method - which isn't available in iOS 8. In the first case, I'd replace it when you have some spare time, as soon as possible. In the latter case, I'd replace it as soon as I don't need to support anything where the replacement method is not available.
I'm new to the update/versioning process of an app and Xcode, so here are a few questions:
I create the app and was approved by apple running in the old xcode and simulator 5.1. I DIDN'T have any warning messages. Now when running in new xcode and simulator 6.0, I get 20+ new warning messages.
Does Apple expect NO warnings in any build in any version?
Do I need to fix all of the warnings or only certain ones?
(i.e. my app files VS external 3rd party frameworks/libraries that I included/imported into the app)
Fixing them for this version 6.0 may break for older version, correct?
The app was create with a target of 5.1, but wanted to move that back to 4.3 (more user coverage), I can only test that on the simulator is that okay?
Here are some example warnings:
- JSONKit.m - Semantic Issue - Direct Access to objective-c's isa is deprecated in favor of object_setClass() and object_getClass()
- Many types ones like - Format specifices type 'unsigned long' but the argument has type 'NSUInteger' (aka 'unsigned int')
- Cocoa API Issue - Using 'stringWithString:' with a literal is redundant
Thanks for the help.
Apple has no idea what warnings you got compiling your code. All they see is a signed binary, one that either works (approve) or doesn't (reject).
Why are you getting them now? Because the new version of Xcode has better heuristics for checking suspicious code. Deprecation warnings are because you're now using a newer version of iOS as a target.
Should you fix them? Probably. I do release code with compile warnings but you need to consider the risks of not fixing the warning on a case-by-case basis. Some are more important or dangerous than others.
The convention is that compilers generate errors and warnings.
Errors are fatal problems that prevent the compiler being able to parse the source and generate code.
Compiler warnings are about potential issues which do not prevent the compilation succeeding but may cause issues at run-time, or flag issues you should be aware of.
You should understand the issue that each of the warnings is describing, and decide whether to take action.
Specifically, deprecation warnings are a 'heads-up' that future versions of iOS (or a library, or whatever) may no longer support the API you're using, and it's time to think about moving to the new API, or remove the code that relies on that API.
Often, warnings can be safely ignored, but it's best practice to keep your code clean of warnings so any new warnings are apparent, and grab your attention.
Apple will not reject an app based on compilation warnings. Apple only see the submitted binary, and don't have access to the source code and any associated warnings.
In the case of using JSONKit I would recommend wrapping your code around an adapater class so you can use NSJSONSerialization for versions above or equal to 5.0.
How large is the user base with iOS version lower than 5.0? I read that its less than 1 percent?
I have to make apps for that work on both iOS 4 and iOS 5. The iOS 5.0 SDK has nice features like ARC, storyboard etc, which are not available in iOS 4.
My question is: In order to make an app optimized for iOS 4 and 5 what should do? Should I develop an app in a classic way without ARC, storyboard etc?
For instance, how can I switch off automatic garbage collection for iOS 4? If I do, of course iOS 5 will not benefit from having ARC. Also, if you mark reference as weak/string - that will not compile for iOS4, won't it?
As Andrey indicates in his comments, while automatic reference counting was introduced with the LLVM Compiler 3.0 that came with Xcode 4.2 and the iOS 5.0 SDK, you can use it in applications that target back to iOS 4.0. There's no good reason not to use it for applications that will run on iOS 4.0+. Also, it's different from garbage collection, as I explain in this answer.
__weak pointers are only available for applications that use ARC and target iOS 5.0 and greater. For iOS 4.0, you'll need to fall back to using __unsafe_unretained as a pointer type when you want to avoid retain cycles.
However, storyboarding is not available for applications targeting anything earlier than iOS 5.0. It's a nice convenience, but I don't personally use it for anything. Jonathan Wight has, and he has some complaints about its current implementation, so you might not be missing much if you gave that feature a pass.