What exactly does this mean? I've seen Availability: iOS (6.0 and later) and other version numbers, but I don't think thats exactly what it means. Does it truly mean that its only available with iOS 6 and up? If thats the case, then why is the comparable method for iOS 2.0f and later depreciated? Shouldn't I still be using it when the iOS version is less that 6.0 or the specified availability?
An example is NSTextAlignmentCenter. It specifies that it is Availability: iOS (6.0 and later), but I'm building an app for iOS 4.3 and up. I'm currently performing a check on the iOS version of the device and choosing the text alignment between NSTextAlignmentCenter and UITextAlignmentCenter. To me, this seems odd. Shouldn't it be for iOS SDK 6.0 and later, rather than iOS 6.0 and later?
I know this seems like nitpicking, but it makes a pretty big difference.
I've seen Availability: iOS (6.0 and later) and other version numbers,
but I don't think thats exactly what it means. Does it truly mean that
its only available with iOS 6 and up?
Yes, it truly means only available in iOS 6 and later.
Most of the Apple-provided frameworks that you link into your app are dynamic -- they're not built into your app, but linked in when the app launches. They exist on the device as part of the operating system. That means that making retroactive changes such as adding a new method is somewhere between difficult and impossible. Important changes, such as security fixes, are typically made in minor OS updates. Feature changes to the API are usually reserved for more significant upgrades.
Some changes do happen retroactively. For example, object literals work not just in iOS 6 but also in 5 and (I think) even 4. That's because in the case of object literals, the change is in the compiler, not in the operating system or frameworks. As long as you're using a compiler that understands the object literal syntax, the object code that the compiler emits will be compatible with older systems.
It means what it says. If it says "2.0 and later" then you can safely use it in any app that target SDK 2.0 or later.
It means that you can use it starting from this x.x OS version.
Think about this in following way - each feature including API has initial version on which it's born (x.x). It lives for some time (through several versions) and at some point it becomes old (new features can do the same thing, but better) and it's marked as deprecated. It's still could be used, but it's not recommended anymore. And at some moment this feature/API dies (becomes unsupported).
So, if you plan to support iOS 4.3 and up, you will have to choose features which alive in iOS 4.3 to 6.0 (already born, but aren't dead yet).
It doesn't refer to SDK version - it iOS version. Every version of iOS adds new APIs that it it supports so you can't use an API (like NSTextAlignmentCenter) that don't exist in that version.
Related
The app I developed (with Swift 3 and xcode 8) is ready for iOS 10, but my boss wants it to work with iOS 8 because he has an iPhone with 8.2: when I plugged his iPhone to my Mac and started to build the project, it failed because some features are available only on iOS 9.0 or higher.
I did some research and came across some options, but since I'm a beginner I don't know what would be better. Let me share them with you:
rewrite the whole app with Objective-C: I think the less convenient, since I never studied this language and my boss wants the app to be uploaded to the store as soon as possible;
call Obj-C code from Swift for iOS 8 needs;
upload the app anyway: I managed to modify the app and make it compatible with iOS 9, do you know any recommendation or proposal from Apple to not develop app for too much old iOS versions so that I can convince my boss to not obsess over this matter? 87% of devices are using iOS 10 so we would not cut off too many people;
upload the app AND add iOS 8.0 compatibility in a future update: can I change iOS target in next updates?
use Appcelerator or React Native.
The best solution would be to check the iOS version programatically and only call the problematic methods if the user's phone actually supports them. Otherwise keep that functionality hidden from the user.
This is how you can check iOS version from code:
if #available(iOS 9, *) {
// iOS 9 Swift code
} else {
//Hide the methods from the users on older OS versions
}
That wouldn't work, since most system APIs are not language dependent. If a certain API/feature was only added in a certain iOS version, that requirement stays the same regardless of whether you use Objective-C or Swift.
Same as 1.
This is a feasible option of course.
AFAIK, you can change the target iOS version in a later update.
If you want to achieve a functionality that uses an API which was only introduced in iOS9, even hybrid frameworks need that iOS version if they use built-in iOS APIs.
To add iOS 8 compatibility you must change the deployment target version to 8.0 and resolve every warning/issue that Xcode give you when you try to build/run.
You will need to use if #available(iOS 9, *) {} code if you use APIs that changed between the versions 8 and 10.
You don’t need to rewrite anything in objective c. For the features that are getting called out, research the iOS 8 compatible way to implement them (if even possible) and add checks in your code for iOS version so that certain blocks only execute for certain os’s. (See technical answers already provided)
But, first show your boss how to update his phone.
Then show your boss that 97% of users are using 9 or 10.
https://developer.apple.com/support/app-store/
Next remind him that the 3% of out of date users are also the 3% least likely to be downloading apps and only part of that 3% are on iOS 8. Many are even more out of date.
Then calculate the number of hours required to support iOS 8. Multiply that by your hourly rate. Then ask your boss if it’s worth $X to expand your app’s user base by, at best,1%.
If he says yes, then go for it.
There is an iOS app developed in iOS 4.3. Now I want to upgrade this app to iOS 9 and later. I can able to run the application even on iOS 10 devices. But there are lot of deprecated warnings regarding the latest SDK.
The main reason I'm posting this question is, while upgrading the app from lower version to latest version, what are the action items to be consider to make the application perfect on latest SDK?
Here are few points I've noted,
Clear all deprecated warning.
Do analyser for memory leak.
Enable ARC if not enabled yet.
Proper unit testing.
Please advice me some more point.
Note: I'm not converting the app to Swift, using Objective-C only.
Update: I know the basic things like changing the deployment targets, update the used libraries / Frameworks to latest one, etc., I want more high level points those features are available in latest SDK comparing with lower one.
Thanks
Here are some more points you have to consider for latest iOS support,
Change deployment target in general setting.
Check for device compatibility for design constraint. There are new devices.
Change the version of your app in general settings.
If there are any functionality for touch event than check if it is possible to implement 3D touch for newer device.
And go for proper testing of functionality and design.
Hope it will help you.
If i create an iOS application in XCode 7.2 with SDK 9.2, will that application work in iOS 6 in iPhone 4?
In general, this is possible - that is where the availability information in the apple documentation comes into play.
You may use iOS 6 as your deployment target and only use the API available on iOS 6.
This will mean your code completion on the current Xcode will suggest unavailable methods and you will be very limited in terms of what the API can do for you.
Also, to cherry pick one of the problems you might run into:
iOS 6 has a whole different approach to authorization for location usage than iOS 9, so you would have to (partly) clutter your code with a lot of version checks to give different implementations for the different versions (and version checks were not available back then). Because, a iOS 9 device will not even ask the user for permissions if you do it the way iOS 6 documentation says you have to do it.
The very fact that you do ask this question might already give away that in general, the answer is
Yes, that can be done with a lot of work that is almost intractable for a single person and in almost all cases not needed.
as the market share of iOS 6 is only a tiny fraction, but in your case, the answer might even be
You will probably fail horribly at some point and should reconsider if this is really necessary. The market share of iOS 6 is really small and you are basically putting in weeks of extra work for basically a hand full of potential users.
Also, as you might have guessed from this (and other answers), if your question is if this works out of the box, the answer is
No.
in general yes or no terms.. yes it is possible.
(Our app spans between 7 and 9)
Supporting ios6 will require a lot of work though since you must take care not to use any features that aren't available on ios6 and iOS sdk6 and iOS sdk9 differ quite a bit :)
I'd consider if it is worth the effort.
I'm currently in the planning stages of developing an iOS app, and I need to decide what versions to support. This is my first app, and I'm leaning towards iOS 5. The app will be pulling most data from the web and won't be very processor intensive. My main concern is that if I develop for iOS 5 or 6 some individuals won't be able to use it. So what factors should be taken into consideration when deciding on this?
Apple has dropped the iOS 4 simulator from any version of Xcode used on Mountain Lion and is likely about to drop iOS 4 support entirely. That's speculation but based on the facts that:
iOS 4 will probably be almost two years old whenever iOS 6 comes out;
iOS 4.3 dropped support for ARMv6 devices, so continuing to allow builds for pre-4.3 adds a significant maintenance cost to the developer tools;
iOS 4 has lesser support for automatic reference counting, which is now pretty much a fundamental feature.
These things aren't announced in advance, someone will just flip the switch one day.
I'd also argue that if you're new to it then iOS 4 is worth avoiding because it lacks:
story boards; and
a built-in JSON parser.
The former is an easier way to design the user interface and the latter is probably what you're going to want for decoding your web results, statistically speaking.
So I'd vote iOS 5.
You should develop for the lowest version possible while taking into account performance requirements and any necessary features that may be present in newer versions. If you want to use iOS5 and 6 features but they aren't necessary to the base line functionality of your app you can still target 4 and just do conditional checks against those features to see if they are available to you.
One of the main reasons you would purposely choose a higher version would be to intentionally leave out devices that won't support it(iPhone 3g or lower and iPad 1st gen)
1) Do you need to support earlier versions of iOS? If you do, you have to pay attention to NOT use the API's that were realeased before your deployment target (aka the lower version you're going to support).
2) If you don't need/want to support earlier versions, Apple says that you should always target the higher iOS version, so you can use the most recent APIs... There are some stuff that you just can't do using older APIs.
What devices do you want your app to run on? If you want your app to run on older devices, this is going to effect what iOS you develop for.
Also, here is a chart with iOS version usage statistics. This will be useful in deciding what to support and what to ignore. iOS Version Usage Statistics
It is true that a number of users will not be fully up-to-date on the current version of iOS. However, that number is very small. The typical user will not immediately upgrade to newest version, but they will usually transition within 1 month.
The users who do not upgrade are very specific. Jailbroken users are the largest community I can think of that will have to typically wait before they can upgrade their iOS version. Other users would be those with older devices such as the iPhone 2g and the 3g, which aren't supported by new versions of iOS.
With this is mind, it is recommended to always program for the highest version number. That code will be the most maintained and the most lasting. Programming for lower versions typically involves many difficult work arounds that are easily accomplished in newer versions of iOS. Also, anytime a new version comes out (think about iOS 7, 8, 22?), you will have to make sure your legacy code still works on the new version. This means you will need access to a device with that version installed.
All in all, the majority of users will be using the newest version of iOS.
If the SDK adds new features, will these things work on the older devices? If the API gets new methods, does the compiler handle these new methods to get to some internal native code, or will the new features added not be able to be used on devices not running the new OS?
When Apple add new SDK features, they almost always rely on new frameworks or runtime features that are simultaneously added to the OS and unavailable on earlier iterations. There are rare exceptions, but they're always to do with an SDK feature being added to the compiler. For example, per the disclosed information on automatic reference counting in the iOS 5 SDK it seems reasonable to assume you'll be able to build iOS 4 applications with all ARC features except self-zeroing weak pointers because that requires some runtime support. Though we won't know for certain until the tools as Apple intends to supply them come out of NDA.
Apple instead expect you to use the dynamic nature of the Objective-C runtime to use new features only as and when they are available and to set your base deployment target to the lowest supported version of the OS on which your application functions to a reasonable extent.
For example:
if(![someObject respondsToSelector:#selector(relevantNewMethod)])
{
// this version of the OS doesn't actually have relevantNewMethod
// so we'll do something else instead; attempting to use it will
// raise an exception on this device
}
Or:
if(NSClassFromString(#"ShinyNewiOSClass"))
{
// ShinyNewiOSClass is implemented on this version of the OS, so
// we can use it. Otherwise we'd better find something else to do
// instead...
}
NSClassFromString returns either the Class instance or nil if no class with that name exists, so you can instead take the result of NSClassFromString and do the customary alloc init on it if you prefer.
A classic example would be showing an 'email' button only if MFMailComposer is available (if you had wanted to support iOS 2 while using iOS 3 methods where available).
For entirely new frameworks standard practice is to weak link (which means your program would like them to be loaded but the OS shouldn't raise an exception if they don't exist) and then to use the same reflective features to check if the relevant classes are available at runtime.
As I understand it, an SDK update generally coincides with an OS update. Therefore, any features added to the SDK will only be available in OS versions that support that SDK.
I'll give an Android-based example, but I believe the process behind it is the same for iOS:
Android 2.1 == SDK v7 (API level 7)
Android 2.2 == SDK v8 (API level 8)
Any features available starting in SDK v8 will not be available to phones running Android 2.1 or earlier.
An SDK goes with a particular iOS version. The SDK for iOS 5.0 gives apps compiled with it an interface to the 5.0 features (as well as to all older features or APIs). Those features that are new in 5.0 can only be used on devices that have 5.0 installed. The app can detect whether it is running on a device that has the feature and avoid using the feature if the device does not have the iOS version that supports the feature. If an app attempts to use a 4.0 feature (for example) while it is running on a device that has iOS 3.1.3 installed the app will get an exception and crash.
Some devices, like the original iPhone, cannot load the latest iOS versions. The original iPhone is stuck at 3.1.3. The iPhone 3G gets 4.X but it some features are disabled (like multitasking). This wikipedia article has a useful what the maximum iOS version the various devices can run.
For the most part, to maintain backwards compatibility, new features added to SDKs are "opt in" and would require you to release a new version of your application taking advantage of them. There is always an exception to the rule, but this is usually the case.
I originally read the question wrong...
If the question is... if I program for an iOS5 feature, will that feature be supported on iOS 4?
Then the answer is... no.
Unless you do something like the defensive measures mentioned by Tommy, your application will either not compile at all, or will crash when those features are accessed.