iOS 6 Project gives #synthesize error when deployment changed to iOS 5.0 - objective-c

When i ran my iOS 6 Project on an older xCode using iOS 5.0. It issues warning and fire exception on executing project.
Property 'window' requires method 'window' to be defined - use #synthesize , #dynamic or provide a method implementation
what is the science behind it ? why do i need to explicitly add #synthesize in 5.0. while it works fine in iOS 6.

This has nothing to do with iOS 6 or iOS 5. This has to do with the version of the compiler used in Xcode. The latest versions of the compiler, used in the latest version of Xcode, support many new features not found in older versions of the Objective-C compiler. One of those features is no longer needing an explicit #synthesize statement. Once you take advantage of these newer features, you can't use an older version of the compiler to compile your code.
So now the question becomes - why are you trying to build this project in an older version of Xcode? What is your goal? Why not use the latest Xcode and simply change the project's Deployment Target to iOS 5.0 and leave the Base SDK as "latest".

Related

In a static library, Xcode 8.1 does not detect when an objective-c method is not implemented

My objective-c project uses a static library and recently I just discovered that Xcode 8.1 does not give some warnings for the library.
When a method implementation is missing in the app itself, I get a warning. But if a method implementation is missing in the library, I get no warning. It just crashes at run time.
Same for the switch statement with an enum. If a case is missing, Xcode would signal a warning, but not in the static library.
In previous versions of Xcode, I am sure I received those warnings in my library. And I never changed any Build Settings, I just keep all the default values.
More info:
When I open the static library itself as a project, I get all warnings. But when I open another project that includes the library (I dropped the mylibrary.xcodeproj file in my project and add it in the Link phase), I don't have the library warnings
It was a bug in Xcode. It is now working well in Xcode Version 8.3 (8E162)

Embedded Content Contains Swift Code with Xcode 8 Beta

I am developing a command line macOS application(with Objective-C) which uses other 3rd party Swift libraries. I am retrieving an error says
"dyld: Library not loaded: #rpath/libswiftAppKit.dylib"
Previous answers recommend to set "Embedded Content Contains Swift Code" flag to true. However, this flag is missing with Xcode 8 beta.
I have tried "ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES", which i believe a new flag for Xcode 8. It doesn't work either :(
Is anyone tried to compile and execute a command line application with Xcode 8 beta that is;
- developed using Objective-C
- having 3rd party swift library dependencies
Update:
I ended up copying everything under "/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx" into the folder where the executable stands. Not a perfect solution but it works.
Check this mentioned in Xcode 8 beta 2 Release Notes:
The new build setting ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES replaces the use of EMBEDDED_CONTENT_CONTAINS_SWIFT. This setting indicates that Xcode should always embed Swift standard libraries in a target for which it has been set, whether or not the target contains Swift code. A typical scenario for using this setting is when a target directly uses or embeds another product which contains Swift code.
Note: EMBEDDED_CONTENT_CONTAINS_SWIFT has been deprecated. (26158130).

xcode upgrade to 7.3.1 from 7.2.1

Right now i'm using xcode 7.2.1 and planning to upgrade to 7.3.1, my question is, xcode 7.3.1 has swift 2.2 and 7.2.1 has swift 2.1. there are some new functionalities added and old ones are removed by apple. so, is it ok to upgrade to 7.3.1? will it affect my current project? (which is in swift 2.1)
It definitely will affect your current project. But the changes shouldn't be that bad. Of course this depends on your project.
That's the situation with Swift right now and that won't change until the language becomes more stable.

XCode Objective-C - Legacy to Modern [duplicate]

I'm trying to compile sources with Xcode 4.6, for 32bit architecture, but getting this error:
error: -fobjc-arc is not supported on platforms using the legacy runtime
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1
What's wrong?
You're mixing ARC (automatic reference counting) with the older Objective-C 1.0 runtime, which does not support ARC.
32-bit apps on OSX, automatically use the 1.0 Runtime, so you'll have to disable ARC for your project, and use Manual Reference Counting.
This problem recently resurfaced because Xcode 5 removes the ARCHS parameter - if you let it. But if you have a build server with Xcode 4 this defaults there to building 32 and 64 bit, which fails if you have ARC enabled.
See my writeup for a more detailed explanation.

ARC enabled App will run in lower version of ios

I have developed an application using xcode 4.3.2 with ARC enabled ,my app users having ios3.2, ios4.0,ios5.0 devices how can I give support to lower version ios device uses .Should I need to do anything in code side . or Is there any way set ARC dynamically like.
Any have any idea regarding this plz share with me.
Thanks
ARC is not device- or OS-dependent (see note below). It is a LLVM compiler feature (which can be disabled using the -fno-objc-arc compiler flag). The compiler manages the memory instead of the programmer. The final executables will not be very different from one another and will work on the minimum OS specified for your project (if you are not using ARC-specific keywords, etc.).
Note:
According to Apple's Transitioning to ARC Release Notes from Apple, ARC-compiled executables will only run on iOS 4 and above. In addition, weak references are only supported on iOS 5.
Just set the target deployment to the lowest iOS version your users might be on.. AutoMatic Reference Counts only while compiling the app in Xcode. The memory of app enabled ARC is managed by compiler (Xcode). So you need not to worry about the target iOS version of the device. Just set the Target Deployment to 3.2 or 4 etc.
I think at least it is not guaranteed to work correctly on iOS 3.x. See Transitioning to ARC Release Notes from Apple:
ARC is supported in Xcode 4.2 for Mac OS X v10.6 and v10.7 (64-bit applications) and for iOS 4 and iOS 5. Weak references are not supported in Mac OS X v10.6 and iOS 4.