iOS development is now done using only the latest SDK.
Is there any way to search my code base for calls not present in older SDKs, generate warnings when compiling code that requires newer SDKs, or some other way to find where the code will fail on older iOS versions?
A workaround that broke compiling entirely would also be acceptable. This is not something I want to ship with, just something I want to do to verify that I've handled everything properly. The application seems to run on devices running earlier versions of iOS, but I'd like to be able to prove this.
No, I don't believe that there is a good way to find new calls not available in older SDK's. It's something I've wanted for a while.
The best thing I know of is to test your app thoroughly on a device running the oldest version of the OS that you plan to support.
It looks like this will do it...
Add this to your prefix:
#define __IPHONE_OS_VERSION_MAX_ALLOWED __IPHONE_3_1
Do not ship without removing this, though. In fact, you'll probably have to disable huge chunks of code to get your app to build this way. And even so, the coverage is nowhere near complete. But it's better than nothing.
Related
I checked all the other variants of this, and don't see the answer here. It seems a lot of folks are thinking of Xcode 4.1, and the issues therein.
First of all, I am very happy with Xcode 4.2. It fixes the huge plethora of problems I was having, and, once again, makes the simulator a useful tool. I am very glad for this, because it is a MUCH faster workflow than using the devices.
Now, 4.2 introduces something in their Edit Scheme dialog (Go to the "Run" page, then "Options"). This is called "Core Location [checkbox] Allow Location Simulation". It allows you to pick from a list of pre-defined locations.
This seems to obviate the horrendous hack that I had introduced when I first encountered the issue in Lion.
However, it no workee. I'd like to find out what I am doing wrong. Has anyone gotten this working?
Remember: THIS BEGINS IN 4.2, WHICH JUST CAME OUT YESTERDAY. So the rules from 4.0 and 4.1 don't apply. It is a new capability.
Thanks!
First, I created the GPX file as mentioned in this question.
In addition to updating the Run Scheme to select the Allow Location Simulation option and specifying the Default Location as you mentioned, you also need to make sure that your Scheme is set to iPhone 5.0 Simulator. This made the trick for me, when I debug my project, the app asks me if I want to allow it to use my current location, and I can see the Debug -> Location menu in the iPhone Simulator.
There's a thread on this bug in the Apple developer forums. One suggestion is to reset the simulator.
Does anyone know if version 2.2 (the latest) of Apple's iOS 'Reachability' example code will run on iOS 3.0?
I want to support iOS 3.0, and Reachability.h and .m is the first non framework code I'm using in my app. In my own code I usually read the docs for all methods I use, and use respondsToSelector: to implement methods that won't run on 3.0.
When people use third party code, how do they confirm which iOS it supports without checking every method individually against the docs?
Alternatively, does anyone know how I can get my hands on the old version of the example code? (Reachability version 2.1 might help.)
I don't mean to snipe an answer from #Matt and #Martin, but I feel like this question deserves an answer for posterity. If they come back and post their comments as answers please feel free to accept them.
Anyway, my own answer is that I would highly advise against using Apple sample projects directly in a production application, especially Reachability. Many of their examples are badly written and, as you've noticed, outdated. I've filed a lot of bugs against them without many results.
That said, one other point is that you should really think twice about relying on Reachability for control logic. If you just want to notify the user when their connection changes or something, okay. But don't rely on what Reachability says to decide whether to try communicating with the network or not. It's often wrong about your network status. Just open up a connection, and if it succeeds great, otherwise you'll get an error response letting you know there's no connection.
EDIT - Regarding your other question about how to tell what IOS a third party app supports. The answer is, unless they've documented it, you might not be able to. Best indicator is usually taking a look at the build target's "Base SDK" and "iOS Deployment Target" settings. Base SDK will be the latest iOS version they've built against, and Deployment Target will be the earliest iOS version they support.
Cheers
I have, after many months of work, finally got my app updated for iOS4.
The first release was complied for iOS3.2 and has been in the AppStore for a while, I was very impressed to see it continued to work and be downloadable for iOS4 users all this time, even though my version failed to compile for iOS4.
However, now I've got the new version (complied for iOS4.2) waiting for review - I'm unsure what will happen to the existing app! If it is used overwritten, what will people with old versions of iOS see? Am I closing the door to anyone without iOS4.2+?
Many thanks
Ben.
p.s. apologies if this has been covered - I did look and failed to find :-)
When you specify the minimum OS required in the bundle, that filters what users will be notified of the upgrade. So users of your app that have yet to upgrade the underlying OS will not get pushed the update.
You can actually specify the target OS Level to an earlier version. The app will be allowed to install on that and any newer version. Generally, Apple is very good about forward-compatibility.
As Peter said, you probably don't want to compile it to only run on 4.2. If you added features that use newer versions of iOS, you can actually do a check prior to calling the method (I've done this with gesture recognizers) to ensure that the running OS version is capable. If you don't validate the OS, the app will simply crash on users with too-old operating systems, which could cause Apple to reject it.
Also, 4.3 is almost out, so you might as well wait a week :)
If your app only supports 4.2+, then only users with a device with 4.2+ iOS will be able to install and use your app. The version currently on the store will be overwritten. In short, yes you are "closing the door" to anyone with a lower version iOS.
Dear Scholars.
I have created a simple application using the latest SDK (4.2.1), Which runs smoothly and error free on all devices with iOS 4.x.x.
Lately I am getting some comments from users with older iOS version complaining the application is crashing on start, on Apple's crash log I see nothing at all.
Pushing my investigation forward, the only suspect I have at the moment is the use of EventKit class, which if memory serves, where introduced only after iOS4.
I am using it very lightly in one of my classes, and it works perfectly on iOS4.2.1
#import <EventKit/EventKit.h>
//some time later
[self setADateInCal: [MyTimeArray objectAtIndex:0] :formatterDate];
Thus my Questions:
Can this be the issue that crashes my application on iOS < 4 ?
How can I prevent it without dropping the feature for people with iOS4
In general, How can I test this? I have the latest official iOS on my device and SDK, the simulator is limited to how back it can go in regrading to iOS version... any magical way to do so?
1.) Yes. If it wasn't in the API in <4.0 than anyone not running >4.0 will crash.
2.) Test to see if the class is available using NSClassFromString (Google for examples) and respondsToSelector in correspondence to see if the method you want is available to use in the OS version the client is running. You will also probably need to weak link the EventKit framework (again Google for how to do this).
3.) The only real way to test this is to keep a device at the OS you want to test. Personally, I have an old iPhone that I never update running 3.1.3 for things just like this. Alternatively, you can keep old installs of xcode+iOSSDK on different partitions or something and use their simulator. (for future updates i guess since you obviously haven't done this for <4.0). But no, there is no magical way to do this. sorry.
edit for clarity on Number 2: Basically you will check to see if the class/method you want is available on the OS version you are currently running, if it is you can use it, if not you will have to find a work around (omit completely or do it another way that is compliant with older versions).
Yes it could be causing the crash. Issues with missing libraries do not report anything in the apple crash log.
To prevent it from happening you need to do two things,
Weak link the event kit library in xcode.
Check for its existence in your code with something like
,
if(!NSClassFromString(#"EKEventKit")){
//do stuff with event kit
}
The only way to test on the actual iOS version is to get hold of a physical device running ios < 4.
Something really weird is going on with Xcode and an iPhone project I'm working on, when I'm building for the simulator, the project has 2 active executables (MyApp - iPhone Simulator (2.0) and MyApp - iPhone Simulator (2.1)) Almost all of the time, I want to use the the 2.1 active executable, but Xcode will occasionally silently change to the 2.0 one.
There doesn't seem to be any pattern to this or any trigger that I can notice. Googling has found a couple of people out there who are having the same problem, but no solutions.
Help me stackoverflow-kenobi! You're my only hope!
Ok, it was a bug. The good news: it's fixed in the fresh new 2.2 SDK.
That is weird -- I've been doing iPhone/XCode development for a while, now, and never seen anything like that.
Are you absolutely certain that you're not poking around some place that's causing the change?
Might you have a corrupt XCode or .xcodeproj? If it persists, I'd try re-creating my project and, if that didn't help, reinstalling XCode.
Very strange, indeed...!
I have the same problem. I need to set the active Executable to 2.1 for openAL to work. The pattern I observed is that it switches back everytime I switch to export to the device. Isn't that what happens with you?
I've seen the issue commented a couple of times on the official iphone dev forum, but no solutions. Looks like a bug.
So.. why are you actually doing that? It is probably better, given the nature of the iPhone (with multiple frameworks for multiple architectures), to set up different Targets for your various projects. The executable produced will be the result of the build phases for your targets.