BlocksKit do not work in iOS8 beta5

[whuxujiyuan]

No description provided.

[zwaldowski]

We will investigate, thanks for the report. We do not support iOS 8 at this time, but will soon.

[vickeryj]

My company will be shipping an app soon that we would like to continue to work after iOS 8 ships, so we will investigate this failure.

Has anyone else started looking at this?

[SquaredTiki]

The issue I'm seeing is that the handler blocks are not getting called, for example for bk_showAlertViewWithTitle:message:cancelButtonTitle:otherButtonTitles:handler:

[segiddins]

@zwaldowski is it possible that apple has changed the way they access their delegate properties (maybe due to swift)?

[Mazyod]

@vickeryj If the app was built against the iOS 7 SDK and broke on iOS 8, that would be a problem so serious, I'd say more than 70% of apps on the store would crash. Most of the time, these issues only arise if you submit against the new SDK, which probably has 2 more months to be of any significance.

With that said, spending a lot of time debugging beta iOS is probably not worth it. History shows tons of examples where issues were knocked out in each subsequent beta release, up until the GM seed, which is what really matters.

Well, as far as my testing takes me, I hope the issue is clear below. Apparently, the bk_dynamicDelegate that we see in the UIAlertView method is different that the one accessed and modified in the - (void)implementMethod:(SEL)selector withBlock:(id)block. Not sure if that is actually the issue, but when the time to trigger the handler comes, that NSMapTable is empty, when it shouldn't be.

(lldb) po self.bk_dynamicDelegate
<A2DynamicDelegate:0x7b855800; protocol = UIAlertViewDelegate>

(lldb) po [self.bk_dynamicDelegate invocationsBySelectors]
NSMapTable {
}

(lldb) po self
<A2DynamicDelegate:0x7ae820f0; protocol = UIAlertViewDelegate>

(lldb) po selector
"alertView:didDismissWithButtonIndex:"

(lldb) bt
* thread #1: tid = 0x114949, 0x000dca48 yaaaay`-[A2DynamicDelegate implementMethod:withBlock:](self=0x7ae820f0, _cmd=0x000ea983, selector=0x01788e2a, block=0x000f6170) + 440 at A2DynamicDelegate.m:187, queue = 'com.apple.main-thread', stop reason = step over
    frame #0: 0x000dca48 yaaaay`-[A2DynamicDelegate implementMethod:withBlock:](self=0x7ae820f0, _cmd=0x000ea983, selector=0x01788e2a, block=0x000f6170) + 440 at A2DynamicDelegate.m:187
    frame #1: 0x000d7ce8 yaaaay`__53+[NSObject(.block_descriptor=0x7ba46370, delegatingObject=0x7b9a80e0, block=0x000f6170) bk_linkProtocol:methods:]_block_invoke36 + 584 at NSObject+A2BlockDelegate.m:228
  * frame #2: 0x000c73e7 yaaaay`+[UIAlertView(self=0x01bc2cf4, _cmd=0x000e9cdc, title=0x000f6c08, message=0x000f6c18, cancelButtonTitle=0x000f6c28, otherButtonTitles=0x7e045510, block=0x000f6170) bk_showAlertViewWithTitle:message:cancelButtonTitle:otherButtonTitles:handler:] + 743 at UIAlertView+BlocksKit.m:144
    frame #3: 0x000c20f5 yaaaay`__29-[ViewController viewDidLoad]_block_invoke(.block_descriptor=<unavailable>) + 197 at ViewController.m:23
    frame #4: 0x02db7c2a libdispatch.dylib`_dispatch_call_block_and_release + 15
    frame #5: 0x02dd508f libdispatch.dylib`_dispatch_client_callout + 14
    frame #6: 0x02dbc715 libdispatch.dylib`_dispatch_after_timer_callback + 156
    frame #7: 0x02dd508f libdispatch.dylib`_dispatch_client_callout + 14
    frame #8: 0x02dcb65e libdispatch.dylib`_dispatch_source_latch_and_call + 361
    frame #9: 0x02dc39b1 libdispatch.dylib`_dispatch_source_invoke + 367
    frame #10: 0x02dbe346 libdispatch.dylib`_dispatch_main_queue_callback_4CF + 473
    frame #11: 0x008a9f3e CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 14
    frame #12: 0x00868d40 CoreFoundation`__CFRunLoopRun + 2256
    frame #13: 0x008681ab CoreFoundation`CFRunLoopRunSpecific + 443
    frame #14: 0x00867fdb CoreFoundation`CFRunLoopRunInMode + 123
    frame #15: 0x044d424f GraphicsServices`GSEventRunModal + 192
    frame #16: 0x044d408c GraphicsServices`GSEventRun + 104
    frame #17: 0x00e92386 UIKit`UIApplicationMain + 1526
    frame #18: 0x000c258d yaaaay`main(argc=1, argv=0xbff3e3a4) + 141 at main.m:14
    frame #19: 0x02dffac9 libdyld.dylib`start + 1

[zwaldowski]

Excellent debugging info, @Mazyod. Looking into it right now.

[zwaldowski]

@segiddins If they did (re: Swift), it should only be in a way to use self. accessors more consistently. I suspect that these issues are cropping up for UIActionSheet and UIAlertView mean that Apple is doing some trickery to forward the old interfaces to the new alert APIs.

[zwaldowski]

There's an experimental fix on the next branch. @Mazyod, it should also address your misgivings with the UIActionSheet initializer.

[Mazyod]

Nice one! 🏆

[pawelkata]

Works like a boss on iOS8b5. Thanks @zwaldowski :-)

[pawelkata]

Ha! Works in iOS8b5 but it's not backward compatible and breaks in iOS7.1 (simulator) on (NSObject+A2BlockDelegate.m):

• (void)bk_registerDynamicDelegateNamed:(NSString *)delegateName forProtocol:(Protocol *)protocol

in line containing:

NSCAssert(property, @"Delegate "%@" does not exist on class %s", delegateName, class_getName(self));

[SquaredTiki]

@pawelkata I can confirm this, successfully works on iOS 8 Beta 5 but crashes immediately on that assert back on iOS 7.1.

[kommen]

We just ran into the issue and as far I can see, this also affects apps compiled against iOS 7 sdk running on iOS 8 beta 5, which means it would indeed break a lot of apps currently in the store as soon as the user upgrades to iOS 8, if this is not fixed by Apple until iOS 8 ships.

I'd like to file a radar on this, but looking through @zwaldowski's commits in the next branch, I don't see what's the actual root cause for the breakage is. Anybody can help me out here?

[zwaldowski]

It's not something that's radar-worthy, unfortunately. Apple has switched to more consistently using self.delegate in their classes (vs. _delegate). Previously, we only assumed they would do this in subclasses that wouldn't have access to the private ivar (i.e., UIImagePickerController inheriting from UINavigationController). We would swizzle the delegate to return the "real delegate" that you could use on a block-based delegate; since this was only completing the façade, we felt no real problem with removing it. The other changes in the branch are cleaning up to not rely on the getter returning what it does.

[SquaredTiki]

@zwaldowski Would it be possible to backwards support iOS 7 in what you've done on the next branch?

[zwaldowski]

@SquaredTiki I pushed a fix, iOS 7 should be supported on the next branch now according to my testing. Please let me know if it doesn't work.

[kommen]

@zwaldowski I see, thanks for elaborating. I've filed rdar://17988191 anyway, as Apple usually want to know when they break existing apps in the app store.

[jmkk]

@zwaldowski "next" branch changes fixed it for us. What is the ETA to publish this branch out and tag it through CocoaPods? Thanks!

[jgale]

Same question here. It seems even more relevant because the word on the street is that there won't be an iOS b6, b5 was the last. (Old article by 9to5mac believe their source was accurate) http://9to5mac.com/2014/07/23/apple-tentatively-plans-mid-september-iphone-event-as-ios-8-nears-completion/

[zwaldowski]

If it works for folks I'll tag it very soon. Thanks.

[zwaldowski]

Addressed. Thanks! :)

[jgale]

Awesome, thanks very much! Glad that I'll get a chance to have our customers get the fix well before iOS 8 officially roles out.

Have you run pod trunk push yet? It still shows 2.2.3 on http://cocoapods.org/?q=blockskit.

Thanks!

[jmkk]

Nice!

@zwaldowski please push the pod spec, thanks!

[johndpope]

Thanks for your efforts zwaldowski. Working great.