Application crashing on IOS 5 working on previous versions - iphone

My application was launched on the App Store on Oct. 5. It is working well on all iOS versions except iOS 5. On a particular class it is crashing on this statement:
[[self.tableView cellForRowAtIndexPath:lastIndex]
setAccessoryType:UITableViewCellAccessoryNone];
I am getting the error "Executing Bad Access."
Could this be because of ARC, introduced by Apple in iOS 5?

That indexPath should be retained.
Add [lastIndex retain]; before your statement.

Related

Adapt app from iOS7 to iOS6

I wrote my application for iPhone in xcode 5.0 and it supports only 7 ios.
How can I make it available for ios 6?
Also interested in how to prevent applications load on ipad?
First question: Make sure your deployment target is 6.0, don't use API's that are iOS 7 only, or check by using
if ([someObject respondsToSelector:#selector(ios7onlymethod)] {
// do your iOS 7 only stuff
} else {
// Fall back to iOS 6-supported ways
}
Or use
if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 7.0f) {
// do your iOS 7 only stuff
} else {
// Fall back to iOS 6-supported ways
}
New frameworks you want to use should be marked as optional in Xcode; to do that select your target, click general, and scroll to the "Linked Frameworks and Libraries" section.
What's really cool is that classes in frameworks marked as optional are replaced with nil on versions of iOS that don't have them. So suppose you write some code like this, using a class from the Sprite Kit framework, new in iOS 7:
SKSpriteNode *spriteNode = [SKSpriteNode spriteWithImageNamed:#"mySprite"];
On iOS 6, when the linker, which "links" frameworks to apps (apps don't copy frameworks, they just get them from the system), sees SKSpriteNode in your code, and the framework is marked as optional, that line of code will be replaced by this:
... = [nil spriteWithImageNamed:#"mySprite"];
Sending messages to nil in Objective-C does absolutely nothing, so the above code doesn't crash. No problem. So instead of lingering your code with if-statements checking for the existence of a class, you can just go with the flow and let the dynamic linker do the work.
Further reading:
iOS 7 UI Transition Guide: Supporting iOS 6
Supporting Multiple iOS Versions and Devices
Second question: There is no way to say that you want your app to only run on iPhones and iPod touches. You can require things that are specifical to the iPhone and iPod touch (like a certain processor architecture or the M7 motion coprocessor) but Apple won't like it if you require the M7 chip to exclude a certain device when you don't even need it. You should probably think about why you don't want your app to run on iPads.

UITableView of iOS SDK 6.1 don't compatible with iOS SDK 5.1

I have created UITableView project in XCode 4.6 with iOS 6.1 SDK, and set target sdk to 5.1, when the app calling dequeueReusableCellWithIdentifier in cellForRowAtIndexPath function, the app throw a exception, the simulator is 5.1, on simulator 6.x is ok.
1:
[UITableView dequeueReusableCellWithIdentifier:forIndexPath:]: unrecognized selector sent to instance
2:Terminating app due to uncaught exception NSInvalidArgumentException, reason: -[UITableView dequeueReusableCellWithIdentifier:forIndexPath:]: unrecognized selector sent to instance
1. dequeueReusableHeaderFooterViewWithIdentifier
Availability
Available in iOS 2.0 and later.
-> Minimum iOS version required to run this function is iOS 2.0
2 .dequeueReusableCellWithIdentifier:forIndexPath:
Availability
Available in iOS 6.0 and later.
-> Minimum iOS version required to run this function is iOS 6.0
EDIT
IF your want to use this function the you can check your current device version and then implement this
NSString *currSysVer = [[UIDevice currentDevice] systemVersion];
NSLog(#"curr version = %f",[currSysVer floatValue]);
if ([currSysVer floatValue] >= 6) {
//iOS 6.0 and later code
// dequeueReusableCellWithIdentifier:forIndexPath:
}
else{
//dequeueReusableHeaderFooterViewWithIdentifier
}
If you look at the Apple documentation, you'll see that dequeueReusableCellWithIdentifier: forIndexPath: came in with iOS 6.0.
That means if you try to call this method on iOS 5.X devices, it's going to throw an exception.
It would be better if you used the older "dequeueReusableCellWithIdentifier:" call if possible.
One big difference between the two calls is that the latter (older) one can return nil, in which case you need to alloc/init a new reuseable cell.

iOS 4 and iOS 5 backward compatibility

I have a question regarding iOS 4 and 5. I am really confused and hope someone will clear it out for me.
I am using iOS 5 SDK in my application. If i use the iOS 5 Twitter integration which is provided by apple, will it run on an iPhone that has iOS 4 installed ?
Does backward compatibility work ?
I have used Twitter as an example, but does backward compatibility really work with iOS 5 ?
If you set up your app properly, so that it can be run on devices running iOS 4 without crashing, then: yes, it will run on an iPhone that has iOS 4 installed.
Your app should implement logic such that the Twitter API is used when the app is being run on an iOS 5 device. When the app is running on an iOS 4 device, you can conditionally choose not to use the Twitter API.
Instead, you can use a different Twitter library (like MGTwitterEngine, or your own) - or just exclude Twitter functionality for those users.
To check whether the TWRequest Class exists, use NSClassFromString.
Class twRequestClass = NSClassFromString(#"TWRequest");
if (twRequestClass == nil) {
// TWRequest does not exist on this device (running iOS version < 5.0)
// ... do something appropriate ...
} else {
TWRequest *twRequest = [[twRequestClass alloc] init];
// ^ I didn't look up the proper initializer, so you should change that line if necessary
// ...
}
You would have to create ifs dependently of the iOS version the user is using. Exemple, in iOS 5 there is an Appearance API to modify most of the UI, but not in iOS 4, so you have to create a little if like that:
// not supported on iOS4
UINavigationBar *navBar = [myNavController navigationBar];
if ([navBar respondsToSelector:#selector(setBackgroundImage:forBarMetrics:)])
{
[navBar setBackgroundImage:[UIImage imageNamed:#"bg.jpg"] forBarMetrics:UIBarMetricsDefault];
}
If you set up your app properly, so that it can be run on devices running iOS 4, it will crash. This is because you're trying to access methods/features that arn't available.
The way to get around this is to check if a feature is available using
if(NSClassFromString(#"UIPopoverController")) {
// Do something
}
(Popover controller is just an example)
You could also check the version using
float version = [[[UIDevice currentDevice] systemVersion] floatValue];
And then depending on the version run a specific piece of code (i.e. if iOS 5, preform twitter stuff,else do something different)
No, if you use the Twitter APIs available in iOS5, they will not be able to run on iOS4.
The reason being that when app will run on iOS4, the system will not be having the APIs availability.
if you check the documentation, you can see the iOS version from where this Class/API is available.
I hope this helps..

ios: add printing, but keep compatibility with ios 3

i'm trying to add printing features to an ios app.
while printing itself works fine, and the app works on ios > 4, i haven't figured out yet how to keep the ios 3.1 compatibility...
i guess the issue is this: completionHandler:(UIPrintInteractionCompletionHandler)
A block of type UIPrintInteractionCompletionHandler that you implement to handle the
conclusion of the print job (for instance, to reset state) and to
handle any errors encountered in printing.
once i add the block:
void (^completionHandler)(UIPrintInteractionController *, BOOL, NSError *) =
^(UIPrintInteractionController *printController, BOOL completed, NSError *error) {
};
the app won't even launch on iOS 3.1
probably because blocks aren't available there.
yes, i made sure that this code won't be run when launched on iOS 3.1...
if (([[[UIDevice currentDevice] systemVersion] floatValue] >= 4.2) && ([UIPrintInteractionController isPrintingAvailable]))
so i wonder if there's a way to have printing support for iOS >4.2, but keeping it to run on iOS 3.1?
maybe there's a way to use a method instead of the "block"?
or how would be the correct way to have printing available on supported iOS devices, and remain backwards compatible to iOS 3.1?
just add -weak_framework UIKit to the project settings under "Other Linker Flags" and make sure you use conditional code for printing API.
Conditional code should check feature availability, not OS version:
if (NSClassFromString(#"UIPrintInteractionController")){
void (^completionHandler)(UIPrintInteractionController *, BOOL, NSError *) =
^(UIPrintInteractionController *printController, BOOL completed, NSError *error) {
};
}
Set your project target to iOS 3, and you're good to go.
The best practice for detecting if AirPrint is available is to use NSClassFromString. If you use this method in general, then you always know if exactly the class you want is available, without having to hard-code which features correspond with which version. Example code:
Class printControllerClass = NSClassFromString(#"UIPrintInteractionController");
if (printControllerClass) {
[self setupCanPrintUI];
} else {
[self setupCannotPrintUI];
}
That way your app can still work on previous iOS versions, although it won't be able to print from them.
I've been able to use this technique and run it on an iOS 3.0 device without any problems with the block code (the ^-based stuff). In my build settings, I have the Base SDK set to iOS 4.2, and the Deployment Target set to iOS 3.0.
I posted a sample Xcode project at the end of this blog post on printing in iOS. This is the project that successfully runs for me on a device with iOS 3.0 and another device with iOS 4.2. You may have to change the bundle identifier in the info.plist to get the code-signing to work for you, but that's independent of the printing stuff.
Set Deployment Target in your Project Settings to iOS 3.x. However, set the Base SDK to 4.2. Now you can use the 4.2 classes and iPhones running 3.x can install your app too.
Keep in mind that when you use a 4.2 class on an iPhone 3.x, the application will crash (so keep checking the system version on-the-go).
NSComparisonResult order = [[UIDevice currentDevice].systemVersion compare:#"3.2" options: NSNumericSearch];
if (order == NSOrderedSame || order == NSOrderedDescending && [[UIDevice currentDevice]isMultitaskingSupported]) {
// >4.2
}
else {
//< 4.2
}
Note:
also change UIKit framework setting from "required" to "weak" this will help you to run application on iOs < 4.2 as well as iOs >= 4.2

iPad App Crashes in 4.2 Distribution build only

I have a weird problem that hopefully someone could shed some light on.
I have an ipad app in the AppStore that was released when 3.2 was the only
available iOS for ipad. App ran fine on this iOS but as soon as 4.2.1 came out for ipad
and some of my users therefore updated to the new iOS the app now crashes when a
certain UIBarButtonItem is pressed. In the interim from iOS 3.2 to when iOS
4.2.1 came out i submitted no updates so it was the exact same app running on
each iOS yet i had this problem only on 4.2
After symbolicating in Organizer and viewing the Distribution build crash report
I am able to at least see the line of code that is causing this...
while(i < [filteredData count]) {
thats it!!...just a simple check during a while loop. The last thing in the crash
log points to the above line of code....
filteredData is a NSMutableArray that is definitely allocated/initialized at
this point. It is actually used in another piece of code before this with no
problems.
Again, this line of code gave my app no problems on iOS 3.2 but on iOS 4.2.1 it
causes EXC_BAD_ACCESS (SIGSEGV)
When i install the app on my device via xcode with a debug or release config it works perfect but when installing from AppStore (distribution build) it crashes and only on 4.2!
Just to clarify.....
app works perfect on debug AND distribution modes on 3.2
app works perfect on debug mode on 4.2 BUT app crashes on distribution mode on 4.2
Any thoughts? .....cuz i'm confused/lost
Thanks for taking the time
Possibly an optimisation made by the compiler in Release builds causes this, especially as you dont get the issue in Debug
Can you refactor to...
NSUInteger count = [filteredData count];
while(i < count) {
Or is filteredData mutating in the loop?
NSUInteger count = [filteredData count];
while(i < count) {
blah;
blah;
count = [filteredData count];
}