User Profile

I'm seeing a weird interaction between UIPageViewController and dragging. When a drag hovers over a UIPageViewController set up to scroll horizontally, it'll randomly scroll a full page's worth leftwards, into blank space. Dragging the page-controller view slightly restores it to where it should be.I can replicate this in a trivially simple project, but I can't find a good workaround. It feels like something in the internals is spring-loaded that shouldn't be, but I'm not sure how to squish this behaviour.My app is build around a UIPageController as the main container vc and makes heavy use of drag and drop, and this behaviour is not just an occasionaly glitch, but an absolute killer.Anyone got any ideas what I can poke at?Edit: rdar://34926095

Anyone else seeing bad behaviour on zooming UIScrollViews in the first iOS 12 beta?I've got a minimal app with a scrollview containing an imageview, set up using autolayout as you'd expect - imageview constrained to the scrollview, scrollview constrained to the view-controller's view. The scrollview's delegate returns the imageview from viewForZooming .On iOS 11 it behaves as you'd expect, but on iOS 12 the imageview is offset by some amount proportional to the zoomScale, as if it had a contentInset (it doesn't)Filed it as rdar://40799147 , but it seems like an obvious enough problem that I'm wondering if I'm doing something dumb.Edit: More specifically, it looks like the viewForZooming's center is bad. Previously the scrollview would this scale up and down with the zoomScale, whereas on iOS 12 it is fixed to the view bounds center. Since a view's center is in the superview coordinate space (in which the view has been scaled), this seems wrong.Edit2: Come to think of it, I don't understand how zooming scrollviews ever actually worked with autolayout. It seems like the iOS 11 behaviour actually only works by silently breaking a bunch of constraints when you zoom in or out - when you zoom, nothing changes that autolayout cares about (only transforms and frames are changed) but it still somehow comes up with a different answer for your view's center. Whereas the iOS 12 behaviour seems like autolayout behaving as-advertised.I don't get why this change doesn't break more apps than it does...

Should I be seeing the new payment sheet when I test IAPs in my (unpublished) app?Right now I'm getting the old-skool UIAlertController no matter what I try. I'm using the latest XCode & iOS betas, deployment target is iOS 11, and I've tried both the debugger and internal testflight. IAP status is 'Ready to Submit'.Is there some special magic I'm missing?

I want to keep an object alive until an async block of code has run. Is the following guaranteed to work?func test() { let x = ObjectToKeepAlive() doSomethingAsyncronously(completion: { _ = x }) }Or can the optimiser discard the "_ = x" and cause the deinit to happen earlier?

So my understanding is that when you pass Swift structs around - Data, Array and so on - Swift won't do a full copy but instead use references, and will only allocate a real copy when you try and write through one of these references.So I'm wondering - given that Swift's collection types are generally not thread-safe, is this copy-on-write behaviour thread-safe?If I make 10 copies of an array, and then have 10 threads each start writing to their own copy, will Swift handle this gracefully? From a programming-model standpoint, the threads are each working on their own, independent piece of data, but under the covers there are 10 threads all trying to fork the same object which makes me a little unsure.

The following alternates between appending an item to a collection-view, and reloading the collection-view with 1 item, at an interval of 0.1s.(assume it has a cell hooked up in the storyboard with reuse ID "cell")@interface ViewController : UICollectionViewController { int numItems; } @end @implementation ViewController - (void)viewDidAppear:(BOOL)animated { [super viewDidAppear:animated]; [self insert]; } - (UICollectionViewCell*)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath { return [collectionView dequeueReusableCellWithReuseIdentifier:@"cell" forIndexPath:indexPath]; } - (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section { return numItems; } - (void)insert { numItems++; [self.collectionView insertItemsAtIndexPaths:@[[NSIndexPath indexPathForItem:numItems-1 inSection:0]]]; dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 100*NSEC_PER_MSEC), dispatch_get_main_queue(), ^{ [self reload]; }); } - (void)reload { numItems = 1; [self.collectionView reloadData]; dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 100*NSEC_PER_MSEC), dispatch_get_main_queue(), ^{ [self insert]; }); } @endIt crashes with an assertion in the iOS9.3 simulatorrequest for index path for global index 8070459302346493018 when there are only 2 items in the collection view'which is an error I'm occasionally seeing in my app.If I replace reloadData with reloadSections, it works fine. If I increase the delay from 0.1s to 0.2s, it works fine.It seems like a very basic use of the API. I am sure I'm missing something really really obvious here, but I can't for the life of me see it. If someone could point it out and make me feed dumb, I would surely appreciate itEdit: rdar://27354858Edit: Looks fixed in iOS 10 beta 4.

So Apple just added this to the requirements specifically for social-networking apps.But it's not clear whether the store metadata support link covers this, or if it requires an in-app link. Anyone got any insight into what it actually means?

I'm seeing a fairly repeatable crash in CoreAnimation, generally when scrolling around a collectionview or pushing / popping in and out of it's viewcontroller.The location of the crash varies, but the cause is always the same as far as I can tell: It fetches a pointer (which always seems to be 16k-aligned) from 24 bytes into some struct and derefs it, which triggers EXC_BAD_ACCESS, code=1. The pointer doesn't look obviously bad, or different to non-crashing calls, so presumably it's something that got unmapped.The tricky thing is, I can only reproduce it on-device (iPhone 6) with malloc-scribble enabled, but I see no evidence of actually scribbling anywhere. Which leads me to believe maybe the scribbling is just exposing a race-condition - a couple of times I've caught the CA Layer destructor memsetting the scribble-pattern on the main thread while the crash happens on a background thread, which is suggestive.Anyone else seen this? Do I need to worry about it?Sample callstack (main thread):#0 0x00000001865395f8 in CA::Render::release_shmem_bitmap(void const*, void*) () #1 0x0000000186528b08 in CA::Render::Image::~Image() () #2 0x0000000186526f74 in CA::Render::Image::release_data() const () #3 0x000000018651b43c in CABackingStoreReleaseImages(CABackingStore*) () #4 0x0000000186544c40 in backingStoreFinalize(void const*) () #5 0x00000001838f0c34 in CFRelease () #6 0x0000000186500ea4 in CA::Layer::~Layer() () #7 0x0000000186500ad4 in -[CALayer dealloc] () #8 0x00000001865008e8 in CA::Layer::free_transaction(CA::Transaction*) () #9 0x00000001864fc89c in CA::Transaction::commit() () #10 0x00000001864f5de4 in CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) () #11 0x00000001839cc728 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ () #12 0x00000001839ca4cc in __CFRunLoopDoObservers () #13 0x00000001838f4c70 in CFRunLoopRunSpecific () #14 0x00000001851dc088 in GSEventRunModal () #15 0x0000000188bde088 in UIApplicationMain () #16