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?
Related
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 currently migrating my project to Swift3 as I know that there is one bug I have under iOS 10 that needs to be fixed.
So I installed iOS 10 on one of my devices.
Now I can't run my app on the device, getting the 'Could not find developer disk image' error.
So I downloaded the latest Xcode8-beta.
Now my code can't be compiled - I first have to convert it to the newest syntax.
So while fixing all the non auto-converted syntax issues, I'm getting errors for frameworks I'm importing, too:
"Module file was created by an older version of the compiler"
Which - to my understanding - means that this framework needs to be recompiled with the current version of XCode.
This would mean that I would have to cross my fingers that all the frameworks I use are up-to-date, or otherwise, fix those, too?
Is it not possible at all to use 'deprecated' frameworks?
Is this Apple being super strict to get rid of any Swift1/2 code as possible?
This would mean that I would have to cross my fingers that all the frameworks I use are up-to-date, or otherwise, fix those, too?
Is it not possible at all to use 'deprecated' frameworks?
Is this Apple being super strict to get rid of any Swift1/2 code as possible?
Yup. Swift 3 is it.
I feel bad for those that had to convert their C code to swift 2, and now swift 3 is coming xD
Hopefully they will make the transition easier with the final release version, and that shortly after that all of the major frameworks will have been updated (for you to recompile).
You need to recompile the frameworks. Even frameworks managed with dependency managers like Carthage (which recompile on each update command) are still having problems with XCode 8 Betas / Swift 3: https://github.com/Carthage/Carthage/issues/1440
I'm trying to compile a dependent libraries from the source code and I've got this error:
/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS9.0.sdk/usr/include/unistd.h:446:8:
note: 'fork' has been explicitly marked unavailable here pid_t
fork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
Is there any way to resolve this issue?
The thing is that I don't actually even need this functionality. When I compile this code for iOS and run it under tvOS then it works.
But I can not submit the application because it contains code compiled for iOS.
What would be the good trick to substitute there a dummy fork() function so it compiles OK (believing that it is not actually used by my specific use-cases).
I don't believe there is a way round this. You cannot create processes under iOS and tvOS is 90% iOS, so the same restriction applies.
You'll have to conditionally compile-out that section of code for iOS/tvOS.
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.
If I create an Xcode project with the iOS Single View Application template and choose Swift for the language, will the compiler exclude from the release build (binary) functions that never get called?
I'm wondering because I want to include a third-party library that has a lot of superfluous classes & functions, and I want to keep my app small & fast.
While I agree with comments, it is unlikely to impact performance in any significant way even if it was included...
Xcode 6 uses Apple LLVM Compiler Version 6.1, depending on how closely related it is to LLVM Developer Group's version the optimization feature is available http://llvm.org/docs/Passes.html with options such as -dce: Dead Code Elimination, -adce: Aggressive Dead Code Elimination.
One way to know for sure what is included is checking the assembly output using -emit-assembly option in the swift compiler and review the output, or opening the binary in a disassembler such as Hopper ( http://www.hopperapp.com/download.html )