1

Possible Duplicate:
Can Blocks built for the iPhone 4 SDK work when deployed to iPhone OS 3.0?
Check for availability of blocks at runtime on iOS

I want to use the new Twitter support in iOS 5, but instead of using a delegate, the main Twitter controller requires clients of the class to pass in a block as a completion handler.

I love blocks and want to use them, but I've so far been able to maintain iOS 3.1.3 compatibility. If I use blocks, do I need to raise my deployment target to iOS 4 and abandon any pre-iOS 4 users? Is there any way to maintain 3.1.3 support?

If I do end up having to require iOS 4, what happens to my older users? Will they just not see the new update in their Updates tab in App Store or will the app download and fail to work? Is there any documentation on how changing the deployment target interacts with the App Store?

Community
  • 1
  • 1
Bill
  • 44,502
  • 24
  • 122
  • 213
  • 3
    http://stackoverflow.com/questions/4231965/check-for-availability-of-blocks-at-runtime-on-ios – Evan Mulawski Oct 17 '11 at 13:43
  • In addition to the suggestions of those two, you might need to add a linker flag to avoid errors, as described in this question: [iOS 4 app crashes at startup on iOS 3.1.3: Symbol not found: __NSConcreteStackBlock](http://stackoverflow.com/questions/3313786/ios-4-app-crashes-at-startup-on-ios-3-1-3-symbol-not-found-nsconcretestackbl) – Brad Larson Oct 17 '11 at 18:10

1 Answers1

-2

This is a bad idea even if you can get the blocks working. You don't know if there are any other iOS 4 specific functions in the Twitter library that might break once you get the blocks working. You should stick with the minimum OS usable between your code and the Twitter client.

James
  • 2,346
  • 1
  • 16
  • 18
  • Not sure what you mean. I'd obviously test this on a 3.1.3 device before shipping. – Bill Oct 18 '11 at 22:25
  • I'm saying you should never use a library compiled/written for a newer version of iOS with an older version. – James Oct 19 '11 at 12:35
  • I don't think that's true. Apple recommends that developers always compile against the latest SDK and simply lower the Deployment Target to the oldest version that will run your code. – Bill Oct 19 '11 at 15:06
  • You're missing what I'm saying. Apple does recommend this, but part of their instructions include NOT using any APIs or functionality that is not part of the lowest deployment target. Twitter's lowest deployment target is higher than yours. Therefore, you shouldn't use it. – James Oct 19 '11 at 15:10
  • @James - You can certainly use newer APIs, as long as you place proper checks around them and test on the lowest OS version from your deployment target. They are not telling you to completely avoid them, but to provide good conditional checks for their presence. They even have sample applications that use newer OS functionality, but still maintain support for older OS versions through testing. – Brad Larson Oct 19 '11 at 15:23
  • Right. I do this in several cases in code in production - check at runtime to see if a feature is supported and route around the feature if the OS is too old. – Bill Oct 19 '11 at 15:51
  • @everyone You're missing the point. It's fine to use newer APIs in your own code. What I'm advising against is using someone else's library where you have no control over what APIs they are using. – James Oct 19 '11 at 17:11
  • 1
    @James You know that the Twitter library I'm referring to is part of iOS 5, right? That is, it's an Apple API? – Bill Oct 19 '11 at 18:09
  • Yes. You have no control over what methods it's calling internally, regardless of whether you surround it with the proper if statements. I can see that you didn't truly want an honest answer, so I will just wish you luck. – James Oct 20 '11 at 13:31
  • @James, this is what testing is for. – Bill Nov 16 '11 at 03:52