Xcode: Set up warning if using iOS 8 and targeting 7.1 - xcode

I accidentally shipped a product that's using the new iOS 8 UIAlertController API instead of UIAlertView while targeting 7.1 users.
Is there a way to set up the compiler to warn me about using iOS 8 API on a 7.1 target?

Not directly in what ships with Xcode, but there are tools that can help you.
For example there's Deploymate (which costs $20 USD) but may be well worth the investment.
There's also the MJGFoundation/MJGAvailability.h open source header file, which solves the problem of knowing when you’re using APIs that are not available in the deployment target. It solves the problem by tricking the compiler into thinking that such APIs are deprecated. Of course, they’re not, but the compiler thinks they are and warns as necessary.
(b.t.w., I copied that last sentence from the "Identifying Backwards Compatability Issues" section of this tutorial).

Related

Can you run and compile Swift code on Windows?

With the release of Swift 3.0 being available for Mac OS and Windows, does this mean you can compile and run Swift code on Windows? If so what compiler do you use for Windows?
There is an open source project on GitHub that (quote) "provides an easy-to-use development environment for Swift programming for Windows applications": Swift for Windows.
System Requirement
Windows 10 64bit, Windows 7 64bit
NOTE
The project was initially hosted on Microsoft CodePlex, but then moved to GitHub.
Since Swift got open sourced, many more platforms were supported by Swift.
Linux was added shortly after it was open sourced, and just recently, the Android support for Swift was merged into the master branch.
You can track the progress of porting Swift to Windows here. As you might see, it's not currently being worked on actively by the Swift team, there is, however, a community port on Github trying to port Swift to Windows.
It is possible to write, build and run Swift code on Windows. With "Siver" and "Elements".
Silver is a free implementation of Apple's Swift programming language. With Silver, you can use Swift to write code directly against the .NET, Java, Android and Cocoa APIs.
Elements is a compiler and development tool chain for Oxygene, C# and Swift which targets the .NET runtime, Java/Android virtual machines. Elements is developed by RemObjects Software (https://en.wikipedia.org/wiki/RemObjects_Software).
HelloWorld.exe example here:
https://github.com/alexbaban/Various-Programming-Languages/blob/master/Swift/Building%20Swift%20Code%20On%20Windows.md
You say:
With the release of swift 3.0 being avaliable for Mac OS and Windows
But this hasn't been announced officially.
There's some projects, but nothing from Apple... yet.
And anyway, the site where you read this:
swift.im/releases.html
is not about Apple's Swift, it's an entirely different project with, unfortunately, the same name.
As far as I know: Swift is available for linux and you can expect swift for Windows, Android soon in the future.
If you want to use Swift language on windows, you must be rely on web based platform. For example: http://swiftstub.com , http://www.runswiftlang.com , etc.
Silver runs on Windows and allows you to compile Swift code to Java and .NET.
Yes, as of September 2020 Swift is available as a binary download for windows. There are even windows-specific instructions for getting started.
The OP asked about which compiler is used. I believe the swift binary is what actually builds the code into an executable. (As of the blog post in 2020, it was CMake, but swift packages are now supported, as well as the swift build command.)
This question is quite old, so no doubt the other answers were all correct when they were written, but this shows up prominently in search results, and should probably have a community wiki answer.

Why do Swift standard libraries need to be copied and embedded in every Swift app? [duplicate]

I have just create a simple project using swift language, then i compile and archive it to generate .ipa file. IPA file is so big, it is about 5 MB.
is it right(no problem) at there? when i create it in Objective-C, it is only about 500kb.
Yes, that's about right. The libraries containing the entire Swift language have to be embedded in the IPA. Those libraries are part of the app, not part of the system - because Swift has to work even with backwards compatibility, in part because it is constantly changing (independently of system updates), and in part in order to work on iOS 7 (where the system has never heard of Swift). And they are about 5MB in size.
To expand on matt's answer, here's a quote from the Swift blog on compatibility:
You can trust that your app will work well into the future. […] This is possible because Xcode embeds a small Swift runtime library within your app’s bundle. Because the library is embedded, your app uses a consistent version of Swift that runs on past, present, and future OS releases.
So if your newest app version was built with Xcode 6.0, and a user of your app is running iOS 8.1, and breaking changes to Swift were introduced to your app in between, your app won't break due to the iOS update. If your app just used system libraries, it could.
This allows the developers of Swift to iterate more quickly without needing to build backwards compatibility between every version.
An additional warning:
While your app’s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together.

Explicitly set base SDK to 3.2 to catch compiler errors

We're building an iPad app and don't plan to use any APIs that are not available in iOS 3.2. Our deployment target is already set to 3.2, but I would like to set our base SDK to 3.2 so that we get compiler warnings/errors if we accidentally invoke APIs not available in 3.2, rather than runtime failures.
Is this a good idea? If so, is the 3.2 sdk still available for download, and will older sdks work with newer XCode versions, like 4? Thanks.
There's no guarantee Xcode will support older SDK versions but as an example the current install of Xcode 4 goes all the way back to 3.0. I would drop 3.2 if I were you (few iPad users are on that; most iOS apps enforce 4.X in the App Store so I'd bet most people have upgraded) but if you are going to support it perhaps you should consider using conditional code for different OS' versions.

Is Xcode 4 ready for iOS development or still too beta?

I am just starting iOS/iPhone development and I would like to start using XCode 4 instead of XCode 3.2. Is XCode 4 stable/feature complete enough for beginning iPhone development or should I stick with XCode 3.2?
I have run into far too many problems using beta versions of XCode, especially since you can't really have two versions of XCode one the same system. Apple already has a history of releasing things to developers before they are truly ready (just look at iAds for the iPad which were released months ago and have yet to deliver a single ad). So, if even Apple isn't ready to label XCode 4 as ready-to-go then you can rest assured its not really ready to go.
I recommend sticking with 3.2. That's what I'm doing until XCode 4 is officially supported.
Using XCode 4 calls everything you do into question. Having a problem with an API? Maybe it's XCode, maybe its your code, maybe its a bug in the API. You just don't know.
I would say no, it's not ready. I tried using it as my main development environment for about a week, and eventually switched back to 3.2. For one thing it crashed fairly regularly, but I could get passed that.
The big thing that caused me to switch back was a bug where the iOS simulator would think that certain resources existed in my app that didn't. Deleting the app from the simulator didn't work, cleaning the project didn't work, and deleting the derived data folder didn't work. Since it's not officially released, finding help for problems like this is a pain as well.
This is just one instance of the kind of problems you'll run into while using it, so I'd recommend avoiding it for now.
You can use Xcode 4 if you do not plan on using the current version (Preview 6) for submitting apps to the App Store.
iOS Dev Center:
Xcode 4 Developer Preview 6 includes
iOS SDK 4.2, bug fixes, and additional
features. To compile submissions for
the App Store, continue to use Xcode
3.2.5 and iOS SDK 4.2.

Do I have to compile my iPhone app with 4.2?

I have iPhone application in the App Store. Do I have to compile my app with iOS 4.2 SDK in order to allow it run on iOS 4.2 devices? Or compiling using iOS 4.2 is required only to allow using new features of new iOS?
I will appreciate if you can clarify this issue...
Thanks!
Yoash
Do I have to compile my app with iOS
4.2 SDK in order to allow it run on iOS 4.2 devices?
No, it will run on the new firmare just fine. At least if the new firmare does not reveal some bugs in your code (which happens).
You don't need to recompile it to let it run on newer OS versions, but like you already guessed, you need to recompile it when you want to use the newer features (eg. AirPlay, "Multitasking" etc).
The old version should still run.
The app might not play well with new features like multitasking on iPad, so it is worthwhile trying to get some testing and feedback done as soon as you can in case there are issues.
If you download the XCode 4 pre-release from the developer portal, you can use the new static analyser to look for problems in the code: this is not just for SDK issues but also things like memory leaks.
Apple recommends that you always compile with the latest SDK, even if you are targeting older versions.
Unless you run into a specific issue that is causing incompatibilities, it is wise to take this advice. A lot of small bugs and performance issues are fixed with each new iteration of the SDK.
That being said - you can continue to use the older SDK's, and Apple will still accept the apps you build. For mature apps that are only going through minor tweaks, this is probably the safest course to avoid introducing new bugs.

Resources