My iOS App was written with the iOS 5 SDK. the iOS target version of 5 was never modified when I switched to newer version of the SDKs as required by apple.
with the new SDK (9) I can't get it to compile with the old setting and i'm attempting to switch over to a newer target. (6,7,8,9, I get the same issues). the app has mixed code, some files use ARC and some don't. when i switch to newer OS target I get many errors regarding ARC, mostly around dispatch queue management (dispatch_retain/dispatch_release). if i add the -fno-objc-arc the app crashes, if i remove the dispatch_retain/release calls the app crashes. my questions are:
Does anyone knows what was changed in the SDK compilation regrading ARC between iOS 5 and 6?
Any recommendations how to move forward? is there a way to keep arc enabled but tell the compiler to allow manual handling of the dispatch queues?
Nothing significant.
You have to manage queues manually anyway. The only way that ARC interacts with dispatch_* is when you use a block. It's likely that this has always been a problem and that optimisations in the new compiler expose it.
Without seeing the code it's difficult to make any specific recommendations. In general, I tend to set up a queue when the app launches and never deallocate it. trying to find the right times to retain/release a queue just feels like a problem that I don't need to deal with.
Related
Working with this team and I need to release next build to app store. After cloning project I have 37 compile warnings. Should I bring this to someones attention, fix these myself, or leave as is? How would I handle the warnings from 3rd party frameworks Unlock the file and fix myself? id rather not make changes to the 'socketEngine.swift` file that I don't know how works.
Below I've listed the types of warnings I'm getting.
- "characters is deprecated, please use storing or substring directly", and various other deprecations.
- "when calling this function in swift 4 or later, you must pass a () tuple.
- "This block declaration is not a prototype" - About 30 of these
When I run the app everything runs smoothly.
This project is objective-c and Im much better with swift so I don't want correct all of these changes at the moment if I don't need to.
Warnings do not prevent you from building and releasing an app. You can ignore the warnings.
What you should do is talk to your team and ask about any warnings that are part of their code. Why not talk to a teammate?
Do not unlock the files. If you are using a dependency manager, your edits may be lost and need to be repeated in the next release.
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 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).
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.