A lot of people are taking the plunge, like it or not, into iOS7 “optimized” apps. Some folks were going to take their time and transition slowly but Apples recent announcement to developers that February was it and that like it or not they HAD to build iOS7 apps by February has pushed timelines into hyperdrive.<\/p>\n
Here are a few useful things I’ve learned along the way that might may others transition to iOS7 a little easier:<\/p>\n
1. iOS7 or not<\/strong> can easily detect if you’re running on iOS6.1 or older. Of course the opposite is also true. You can use this code<\/p>\n can detect if you’re running on iOS7 or newer. Very helpful if you want to keep your old code in place, to look nice for your customers running iOS6.1 or older.<\/p>\n In case you have<\/strong> to continue supporting iOS6 \/ Xcode 4 then creating the following header file<\/p>\n will ensure that your code behaves properly when compiled with Xcode 4 or Xcode 5. By the way a quick look in 2. Mind the gap<\/strong> 3. Wrapping table cells<\/strong> will do the trick. 4. Popovers<\/strong> in a category class for 5. Searching Popovers<\/strong> Well, that’s all for now. As I discover more of the tips I’ll post the.<\/p>\n","protected":false},"excerpt":{"rendered":" A lot of people are taking the plunge, like it or not, into iOS7 “optimized” apps. Some folks were going to take their time and transition slowly but Apples recent announcement to developers that February was it and that like … Continue reading
\nThis little bit of code<\/p>\n\r\nif (floor(NSFoundationVersionNumber) <= NSFoundationVersionNumber_iOS_6_1)\r\n<\/pre>\n
\r\nif (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber_iOS_6_1)\r\n<\/pre>\n
\r\n#ifndef PK_Xcode4_support_h\r\n#define PK_Xcode4_support_h\r\n\r\n#ifndef NSFoundationVersionNumber_iOS_6_0\r\n #define NSFoundationVersionNumber_iOS_6_0 993.00\r\n#endif\r\n\r\n#ifndef NSFoundationVersionNumber_iOS_6_1\r\n #define NSFoundationVersionNumber_iOS_6_1 993.00\r\n#endif\r\n\r\n#endif\r\n<\/pre>\n
NSObjCRuntime.h<\/code> will confirm that both NSFoundationVersionNumber_iOS_6_0<\/code> and NSFoundationVersionNumber_iOS_6_1<\/code> are supposed to be defined as 993.00<\/code>. <\/p>\n
\nOne of the new features<\/em> of iOS7 is that your views can slide under the navigation bar. If you want to do this on purpose then more power to you but if you’re just trying to get your app to look reasonable then this little bit of code<\/p>\n\r\nif (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber_iOS_6_1) {\r\n \/\/ Setting traslucent make sure that the view doesn't slide under in iOS7\r\n self.navigationController.navigationBar.translucent = NO;\r\n}\r\n<\/pre>\n
\nSome code relies on the fact that the superview of a UITableViewCell<\/code> to be a UITableView<\/code>. This is no long true under iOS7. As of iOS7 UITableViewCell<\/code> superview is actually UITableViewCellScrollView<\/code> (which is so to support sliding table cells for delete etc). In general it’s probably a bad idea to depend on the view hierarchy (Apple can and does change it) but if you’re going to this little bit of code<\/p>\n\r\nid cellSuperview = [cell superview];\r\nif (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber_iOS_6_1) {\r\n cellSuperview = [cellSuperview superview];\r\n}\r\n<\/pre>\ncellSuperview<\/code> should, at the end of this code, point to the UITableView<\/code> that the cell lives in.<\/p>\n
\nOne problem that became apparent very quickly, as I was transitioning code to iOS7, is that UIPopoverController<\/code>‘s we’re a very happy bunch. All of the popovers looked wrong. After much digging and searching I discovered that iOS7 UIPopoverController<\/code>s looked at the contents preferred<\/em> content size. To that end I wrote this method<\/p>\n\r\n- (void)setContentSize:(CGSize)contentSize animated:(BOOL)animated{\r\n if (floor(NSFoundationVersionNumber) > NSFoundationVersionNumber_iOS_6_1) {\r\n CGSize size = contentSize;\r\n if (size.width == 0){\r\n size.width = 320;\r\n }\r\n if ((size.height == 0) || (size.height == 44)){\r\n size.height = 1100;\r\n }\r\n [self.contentViewController setValue:[NSValue valueWithCGSize:size] forKey:@"preferredContentSize"];\r\n } else {\r\n [self setPopoverContentSize:contentSize animated:animated];\r\n }\r\n}\r\n<\/pre>\nUIPopoverController<\/code>. This code checks if we’re running under iOS7 or 6. If we’re running under iOS7 it looks at the size being passed in. The code assumes that the argument contentSize<\/code> is from a call to the contents UIViewController<\/code> method contentSizeForViewInPopover<\/code>. Under iOS7 this method has been deprecated and returns width=0<\/code> and height=0<\/code>. Previously this method would have returned width=320<\/code> and height=1100<\/code>. This category method then sets the size back to the original default and then sets the preferredContentSize<\/code> of the contentViewController<\/code> so that the UIPopoverController<\/code> will once again be happy.<\/p>\n
\nOne problem I came across, which is less of an iOS6 to iOS7 problem and more of an iOS7 to iOS7.1 problem, is searching in popovers. There seems to be a problem with the search view not properly managing the search view. The result is that as you type and get results for the search the view overwrites the underlying view BUT the underlying view remains active. This is a serious mess. So far I haven’t found a good answer other then using iOS7.1. Apparently this is a good solid iOS7 SDK bug that Apple has fixed. As of yet I haven’t found a good backwards fix.<\/p>\n