Date   

Re: Bugreporter ?

Quincey Morris
 

It’s working for me. I would try logging out, and go in via the link at the bottom of the main developer.apple.com page (which has an extra step).

On Sep 27, 2017, at 23:51 , Gerriet M. Denkmann <g@...> wrote:

Is the Bugreporter not working?


Bugreporter ?

Gerriet M. Denkmann
 

Logging in to: https://bugreport.apple.com I get a page “Bug Reporter” which does *not* lists my bugs, but just contains one line: “Apple Developer Program Support.”, which is a link to: https://developer.apple.com/contact/submit.php.

Is the Bugreporter not working? Or is this the new normal way of operation?

Gerriet.


Re: a mouse event problem on macOS

James Walker
 

On 9/20/2017 5:17 PM, Graham Cox wrote:

      
On 21 Sep 2017, at 3:53 am, James Walker <list2@...> wrote:

Thank you very much.  Your code didn't work for me at first, perhaps because of a complication that I did not mention in my original message:  The original mouse down happens in a Carbon window.  Anyway, the mouse events returned by -[NSWindow nextEventMatchingMask:untilDate:inMode:dequeue:] are for the wrong window and hence have the wrong mouse coordinates, so I had to convert the coordinates and create a new NSEvent for the right window before forwarding it on to my view's mouseDragged: method.  But it's working now.
OK, sounds a bit smelly, but whatever works, I guess.

The red flag here is the need to “create an event”. I don’t believe there’s ever any reason to do that in mainstream (i.e. app level) code.

NSView has a reference to its window, and the events for that window should have the -locationInWindow coordinate correct for the window. From that you need to convert to the view’s local coordinates using -convertPoint:fromView:, but other than that there’s nothing special to do. I’m not sure why Carbon windows make a difference (surprised they’re still a thing), and since you are creating the overlay window, then everything should be local to that. The original mouse down in the Carbon window is irrelevant in this case - you can simply discard it.

NSView’s trio of mouse methods - mouseDown: -mouseDragged: and -mouseUp: are conveniences - NSView internally implements a loop just like the one I showed which calls out to those methods, but you are not obliged to use them.

The docs on -[NSWindow nextEventMatchingMask:untilDate:inMode:dequeue:] says it forwards the message to -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:].  So, how does NSApplication know what window to send the event to?  It could check what's under the location of the mouse, but as Quincey Morris said elsewhere in this thread, maybe it just sends mouse dragged and mouse up events to the same target as the mouse down.


Re: a mouse event problem on macOS

Graham Cox
 

On 21 Sep 2017, at 3:53 am, James Walker <list2@...> wrote:

Thank you very much. Your code didn't work for me at first, perhaps because of a complication that I did not mention in my original message: The original mouse down happens in a Carbon window. Anyway, the mouse events returned by -[NSWindow nextEventMatchingMask:untilDate:inMode:dequeue:] are for the wrong window and hence have the wrong mouse coordinates, so I had to convert the coordinates and create a new NSEvent for the right window before forwarding it on to my view's mouseDragged: method. But it's working now.
OK, sounds a bit smelly, but whatever works, I guess.

The red flag here is the need to “create an event”. I don’t believe there’s ever any reason to do that in mainstream (i.e. app level) code.

NSView has a reference to its window, and the events for that window should have the -locationInWindow coordinate correct for the window. From that you need to convert to the view’s local coordinates using -convertPoint:fromView:, but other than that there’s nothing special to do. I’m not sure why Carbon windows make a difference (surprised they’re still a thing), and since you are creating the overlay window, then everything should be local to that. The original mouse down in the Carbon window is irrelevant in this case - you can simply discard it.

NSView’s trio of mouse methods - mouseDown: -mouseDragged: and -mouseUp: are conveniences - NSView internally implements a loop just like the one I showed which calls out to those methods, but you are not obliged to use them.


—Graham


Re: a mouse event problem on macOS

James Walker
 

On 9/19/2017 6:43 PM, Graham Cox wrote:
The mouseDragged goes to the view that handled the mouseDown. Since that’s not the same view, you don’t get the mouseDragged.

But it’s pretty easy to fix this. On the mouseDown, create and show your overlay view. Then call its mouseDown from your mouseDown.

Within the overlay’s mouseDown, implement your own mouse tracking loop which keeps control until the mouse goes up. This approach is sufficiently general that I have a handy category on NSView to deal with it. It’s also a documented and officially supported way to do this.

Thank you very much.  Your code didn't work for me at first, perhaps because of a complication that I did not mention in my original message:  The original mouse down happens in a Carbon window.  Anyway, the mouse events returned by -[NSWindow nextEventMatchingMask:untilDate:inMode:dequeue:] are for the wrong window and hence have the wrong mouse coordinates, so I had to convert the coordinates and create a new NSEvent for the right window before forwarding it on to my view's mouseDragged: method.  But it's working now.


typedef void(^GCEventTrackingBlock)( NSEvent* event, BOOL* shouldEndTracking );


@interface NSView (EventTrackingBlock)

- (void)	trackMouseEvent:(NSEvent*) initialMouseDownEvent usingBlock:(GCEventTrackingBlock) eventBlock;
- (void)	trackEvents:(NSEventMask) eventTypes usingBlock:(GCEventTrackingBlock) eventBlock;
- (void)	trackEvents:(NSEventMask) eventTypes untilDate:(NSDate*) date dequeue:(BOOL) dequeue usingBlock:(GCEventTrackingBlock) eventBlock;

@end




@implementation NSView (EventTrackingBlock)


- (void)	trackMouseEvent:(NSEvent*) initialMouseDownEvent usingBlock:(GCEventTrackingBlock) eventBlock
{
	// designed to be called from a -mouseDown: method, the initial event is passed to the block, and then unless the block cancelled it, it will
	// enter a tracking loop for all other LEFT mouse events.
	
	BOOL shouldEndTracking = NO;
	
	eventBlock( initialMouseDownEvent, &shouldEndTracking );
	
	if( !shouldEndTracking )
	{
		// tracks left mouse events plus flagsChanged. Tracks mouseMoved events if the view is set to report them.
		
		[self trackEvents:NSLeftMouseDownMask | NSLeftMouseDraggedMask | NSLeftMouseUpMask | NSMouseMovedMask | NSFlagsChangedMask usingBlock:eventBlock];
	}
}




- (void)	trackEvents:(NSEventMask) eventTypes usingBlock:(GCEventTrackingBlock) eventBlock
{
	[self trackEvents:eventTypes untilDate:[NSDate distantFuture] dequeue:YES usingBlock:eventBlock];
}


- (void)	trackEvents:(NSEventMask) eventTypes untilDate:(NSDate*) date dequeue:(BOOL) dequeue usingBlock:(GCEventTrackingBlock) eventBlock
{
	BOOL shouldEndTracking = NO;

	while( !shouldEndTracking )
	{
		NSEvent* event = [self.window nextEventMatchingMask:eventTypes untilDate:date inMode:NSEventTrackingRunLoopMode dequeue:dequeue];
		[self.window discardEventsMatchingMask:NSAnyEventMask beforeEvent:event];
		
		// if a timeout occurred and event is nil, the loop will end after invoking the block unless the block resets the flag to NO.
		
		if( event == nil )
			shouldEndTracking = YES;
	
		eventBlock( event, &shouldEndTracking );
	}
}

@end

The event tracking block needs to look at event.type to see whether it’s a drag, mouse up, flags changed, etc. Usually you do that in a switch statement.


—Graham





On 20 Sep 2017, at 10:54 am, James Walker <list2@...> wrote:

In response to a mouse-down event, I want to display an overlay window and have a view in that window process mouseDragged messages.  However, it does not get any mouseDragged messages, however much I wiggle the mouse.   If I let the mouse button up and click again, I can then get a mouseDragged, but that's not the user interface I'm going for.  I suppose it has something to do with the fact that my original mouseDown was not in the view in my overlay.  I tried making a fake NSLeftMouseDown event and calling -[NSApplication sendEvent:], but that didn't help.  Any ideas?



Re: a mouse event problem on macOS

Graham Cox
 

The mouseDragged goes to the view that handled the mouseDown. Since that’s not the same view, you don’t get the mouseDragged.

But it’s pretty easy to fix this. On the mouseDown, create and show your overlay view. Then call its mouseDown from your mouseDown.

Within the overlay’s mouseDown, implement your own mouse tracking loop which keeps control until the mouse goes up. This approach is sufficiently general that I have a handy category on NSView to deal with it. It’s also a documented and officially supported way to do this.


typedef void(^GCEventTrackingBlock)( NSEvent* event, BOOL* shouldEndTracking );


@interface NSView (EventTrackingBlock)

- (void) trackMouseEvent:(NSEvent*) initialMouseDownEvent usingBlock:(GCEventTrackingBlock) eventBlock;
- (void) trackEvents:(NSEventMask) eventTypes usingBlock:(GCEventTrackingBlock) eventBlock;
- (void) trackEvents:(NSEventMask) eventTypes untilDate:(NSDate*) date dequeue:(BOOL) dequeue usingBlock:(GCEventTrackingBlock) eventBlock;

@end




@implementation NSView (EventTrackingBlock)


- (void) trackMouseEvent:(NSEvent*) initialMouseDownEvent usingBlock:(GCEventTrackingBlock) eventBlock
{
// designed to be called from a -mouseDown: method, the initial event is passed to the block, and then unless the block cancelled it, it will
// enter a tracking loop for all other LEFT mouse events.

BOOL shouldEndTracking = NO;

eventBlock( initialMouseDownEvent, &shouldEndTracking );

if( !shouldEndTracking )
{
// tracks left mouse events plus flagsChanged. Tracks mouseMoved events if the view is set to report them.

[self trackEvents:NSLeftMouseDownMask | NSLeftMouseDraggedMask | NSLeftMouseUpMask | NSMouseMovedMask | NSFlagsChangedMask usingBlock:eventBlock];
}
}




- (void) trackEvents:(NSEventMask) eventTypes usingBlock:(GCEventTrackingBlock) eventBlock
{
[self trackEvents:eventTypes untilDate:[NSDate distantFuture] dequeue:YES usingBlock:eventBlock];
}


- (void) trackEvents:(NSEventMask) eventTypes untilDate:(NSDate*) date dequeue:(BOOL) dequeue usingBlock:(GCEventTrackingBlock) eventBlock
{
BOOL shouldEndTracking = NO;

while( !shouldEndTracking )
{
NSEvent* event = [self.window nextEventMatchingMask:eventTypes untilDate:date inMode:NSEventTrackingRunLoopMode dequeue:dequeue];
[self.window discardEventsMatchingMask:NSAnyEventMask beforeEvent:event];

// if a timeout occurred and event is nil, the loop will end after invoking the block unless the block resets the flag to NO.

if( event == nil )
shouldEndTracking = YES;

eventBlock( event, &shouldEndTracking );
}
}

@end

The event tracking block needs to look at event.type to see whether it’s a drag, mouse up, flags changed, etc. Usually you do that in a switch statement.


—Graham

On 20 Sep 2017, at 10:54 am, James Walker <list2@...> wrote:

In response to a mouse-down event, I want to display an overlay window and have a view in that window process mouseDragged messages. However, it does not get any mouseDragged messages, however much I wiggle the mouse. If I let the mouse button up and click again, I can then get a mouseDragged, but that's not the user interface I'm going for. I suppose it has something to do with the fact that my original mouseDown was not in the view in my overlay. I tried making a fake NSLeftMouseDown event and calling -[NSApplication sendEvent:], but that didn't help. Any ideas?


Re: a mouse event problem on macOS

Quincey Morris
 

On Sep 19, 2017, at 17:54 , James Walker <list2@...> wrote:

I suppose it has something to do with the fact that my original mouseDown was not in the view in my overlay.

I would assume that mouseDragged and mouseUp are sent to the NSResponder object that handled the mouseDown, but I couldn’t find anything documenting that. The other potential problem is that some views that respond to mouseDown don’t use a mouseDragged override, but handle events in a local modal event loop.

Are you trying to consume the mouseDragged events or monitor them? If you’re trying to monitor them, you can install a local event monitor via a NSEvent class method.


a mouse event problem on macOS

James Walker
 

In response to a mouse-down event, I want to display an overlay window and have a view in that window process mouseDragged messages.  However, it does not get any mouseDragged messages, however much I wiggle the mouse.   If I let the mouse button up and click again, I can then get a mouseDragged, but that's not the user interface I'm going for.  I suppose it has something to do with the fact that my original mouseDown was not in the view in my overlay.  I tried making a fake NSLeftMouseDown event and calling -[NSApplication sendEvent:], but that didn't help.  Any ideas?


NSTextContainer exclusionPaths not working on iOS

Steve Mills
 

I'm trying to use exclusionPaths for the first time and am not having any success. For now, I'm just creating the stuff on the fly in my drawLayer:inContext: method:. The string draws, but doesn't exclude any path no matter what I set it to. I'm also not that familiar with the whole NSTextStorage/NSLayoutManager/NSTextContainer family, other than using snippets of code in the past, so it could be I'm doing something dumb. Any ideas?

-(void)drawLayer:(CALayer*)layer inContext:(CGContextRef)ctx
{
if([layer.name isEqualToString:@"balloons"]) {
UIGraphicsPushContext(ctx);

CGRect box = CGRectMake(0, 0, 400, 400);
NSTextStorage* storage = [[NSTextStorage alloc] initWithString:@"I like little pigs who run and scurry away from the butcher, because the butcher is carrying a large cleaver and wants to chop them up into delicious sandwiches!" attributes:@{NSFontAttributeName:[UIFont systemFontOfSize:36]}];
UIBezierPath* bez = [UIBezierPath bezierPathWithRect:CGRectMake(100, 100, 100, 100)];
NSLayoutManager* lman = [NSLayoutManager new];

[storage addLayoutManager:lman];

NSTextContainer* cont = [[NSTextContainer alloc] initWithSize:box.size];

cont.exclusionPaths = @[bez];
[lman addTextContainer:cont];

// Trying different things to see if they make it work - nope.
[lman textContainerChangedGeometry:cont];
[lman invalidateLayoutForCharacterRange:NSMakeRange(0, storage.length) actualCharacterRange:nil];

[storage drawInRect:box];

UIGraphicsPopContext();
}
}

--
Steve Mills
Drummer, Mac geek


Re: qsort_b in Swift

 



On Sep 16, 2017, at 8:40 PM, Gerriet M. Denkmann <g@...> wrote:

This is the first time I have seen Swift working swifter than Objective-C (and not by a small margin too!).
I am very impressed with the Swift sort.
It would be interesting to know what kind of optimisation magic Swift does here.

The compiler probably inlines the call to the comparison function, as opposed to qsort_b which has (of course) already been compiled so it has to make a regular function call. That makes a big difference when the function is as cheap as comparing two integers.

Similarly, in the Swift code the size of the array elements is a compile-time constant, whereas to qsort_b it's a variable. That results in more efficient code.

—Jens


Re: qsort_b in Swift

Gerriet M. Denkmann
 

On 17 Sep 2017, at 13:05, Quincey Morris <quinceymorris@...> wrote:

On Sep 16, 2017, at 20:40 , Gerriet M. Denkmann <g@...> wrote:

It would be interesting to know what kind of optimisation magic Swift does here.
My guess is that this is not a compiler-related difference, but rather the effect of different algorithms. The performance depends on the initial ordering of the array. My recollection of this subject is hazy, but I think qsort is helped by an array that is already partially ordered, which yours is not.
From the man page:
The mergesort function is […] intended for sorting data with pre-existing order.
Normally, qsort() is faster than mergesort() which is faster than heapsort().
Memory availability and pre-existing order in the data can make this untrue.


I tried both Swift sort and qsort with different data (10,000,000): random, sorted, and sorted backwards:

Swift sort
random 7.25 n log(n) nsec
back sorted 1.45 n log(n) nsec
sorted 1.35 n log(n) nsec

qsort_b:
random 19 n log(n) nsec
back sorted 5.25 n log(n) nsec
sorted 0.83 n log(n) nsec


So in the dependence on the sortedness of the data the two algorithms differs quite substantially.


Kind regards,

Gerriet.


Re: qsort_b in Swift

Quincey Morris
 

On Sep 16, 2017, at 20:40 , Gerriet M. Denkmann <g@...> wrote:

It would be interesting to know what kind of optimisation magic Swift does here.

My guess is that this is not a compiler-related difference, but rather the effect of different algorithms. The performance depends on the initial ordering of the array. My recollection of this subject is hazy, but I think qsort is helped by an array that is already partially ordered, which yours is not. (This is not necessarily an artificial condition. For example, if you add 100 elements to the end of an array of 1000 elements that was already sorted, you will end up with a very non-random array to be re-sorted.)

Qsort is also limited to one algorithm. It’s not impossible that the Swift array sort function does a quick analysis of the array and chooses an algorithm that looks like it will work better than others.

So, yes, it’s very nice to know that Swift’s default sort is something that can be trusted.


Re: qsort_b in Swift

Gerriet M. Denkmann
 

On 16 Sep 2017, at 14:52, Quincey Morris <quinceymorris@...> wrote:

On Sep 15, 2017, at 21:18 , Gerriet M. Denkmann <g@...> wrote:

So I think the code looks like this (syntax-checked in Xcode 9 but not tested):

var sortedArray = [UInt32]()
qsort_b (&sortedArray, sortedArray.count, MemoryLayout<UInt32>.stride) {
(aPtr, bPtr) -> Int32 in
guard let a = aPtr?.load (fromByteOffset: 0, as: UInt32.self) else { return 0 } // or otherwise handle a nil pointer
guard let b = bPtr?.load (fromByteOffset: 0, as: UInt32.self) else { return 0 } // or otherwise handle a nil pointer
return a > b ? 1 : a < b ? -1 : 0
}
I tried this in Xcode Version 8.3.3 (8E3004b) (Swift 3) and:

1. it works: thank you very much. I never would have figured this out from the documentation alone.

2. qsort_b is about 2.25 times slower than sort (tested with arrays of size 1 mio to 100 mio)..
I also tried a C version with a malloced sortedArray: about the same speed as Swift with qsort_b.

This is the first time I have seen Swift working swifter than Objective-C (and not by a small margin too!).
I am very impressed with the Swift sort.
It would be interesting to know what kind of optimisation magic Swift does here.


Kind regards,

Gerriet.


Re: qsort_b in Swift

Quincey Morris
 

On Sep 15, 2017, at 21:18 , Gerriet M. Denkmann <g@...> wrote:

I would like to compare the efficiency of “sort” with “qsort_b”, but cannot figure out how to call it in Swift.

Yikes, this is masochistic!

This is the prototype:

public func qsort_b(_ __base: UnsafeMutableRawPointer!, _ __nel: Int, _ __width: Int, _ __compar: @escaping (UnsafeRawPointer?, UnsafeRawPointer?) -> Int32)

So I think the code looks like this (syntax-checked in Xcode 9 but not tested):

var sortedArray = [UInt32]()
qsort_b (&sortedArray, sortedArray.count, MemoryLayout<UInt32>.stride) {
(aPtr, bPtr) -> Int32 in
guard let a = aPtr?.load (fromByteOffset: 0, as: UInt32.self) else { return 0 } // or otherwise handle a nil pointer
guard let b = bPtr?.load (fromByteOffset: 0, as: UInt32.self) else { return 0 } // or otherwise handle a nil pointer
return a > b ? 1 : a < b ? -1 : 0
}

The “&sortedArray” relies on the compiler auto-bridging to the UnsafeMutableRawPointer. I don’t know if there’s an easier way to get the UInt32 values from the closure parameters, but perhaps “load” is the right way. Also, I may have the comparison test in the return backwards.


qsort_b in Swift

Gerriet M. Denkmann
 

I have an array:

var sortedArray = [UInt32]()
for _ in 0 ..< limit { sortedArray.append( arc4random() ) }
sortedArray.sort()

This works fine.

I would like to compare the efficiency of “sort” with “qsort_b”, but cannot figure out how to call it in Swift.
Any help would be greatly appreciated.

Gerriet.


Problem deriving custom object from UIScrollView

Rick Aurbach
 

macOS 10.12.6 / Xcode 8.3ß6 / Swift 4 / developing for iOS

I am working on a custom object which derives from UIScrollView (at least for now...see below). For initial testing, I am placing it on a view of a UINavigationController panel.
When I run the test application, I find that the contentOffset of my scrollView-subclass is being set to (0.0, -64.0). By putting a breakpoint in contentOffset (didSet), I was able to capture the following stack trace where contentSize was set:

Thread 1 Queue : com.apple.main-thread (serial)
#0 0x000000010bf4fe59 in SelectorStrip.contentOffset.didset at /Users/rlaurb/Projects/RLAUIObjects/RLAUIObjects/SelectorStrip.swift:67
#1 0x000000010bf4fe33 in SelectorStrip.contentOffset.setter ()
#2 0x000000010bf4fd48 in @objc SelectorStrip.contentOffset.setter ()
#3 0x000000010cbab956 in -[UIViewController _setNavigationControllerContentInsetAdjustment:] ()
#4 0x000000010cbf3b5a in -[UINavigationController _computeAndApplyScrollContentInsetDeltaForViewController:] ()
#5 0x000000010cbf3ebc in -[UINavigationController _layoutViewController:] ()
#6 0x000000010cbf474a in -[UINavigationController _updateScrollViewFromViewController:toViewController:] ()
#7 0x000000010cbe584d in -[UINavigationController _startCustomTransition:] ()
#8 0x000000010cbf5967 in -[UINavigationController _startDeferredTransitionIfNeeded:] ()
#9 0x000000010cbf6b41 in -[UINavigationController __viewWillLayoutSubviews] ()
#10 0x000000010cde860c in -[UILayoutContainerView layoutSubviews] ()
#11 0x000000010cad555b in -[UIView(CALayerDelegate) layoutSublayersOfLayer:] ()
#12 0x000000010fa3e904 in -[CALayer layoutSublayers] ()
#13 0x000000010fa32526 in CA::Layer::layout_if_needed(CA::Transaction*) ()
#14 0x000000010fa323a0 in CA::Layer::layout_and_display_if_needed(CA::Transaction*) ()
#15 0x000000010f9c1e92 in CA::Context::commit_transaction(CA::Transaction*) ()
#16 0x000000010f9ee130 in CA::Transaction::commit() ()
#17 0x000000010ca3d5e7 in _afterCACommitHandler ()
#18 0x000000010ee05717 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#19 0x000000010ee05687 in __CFRunLoopDoObservers ()
#20 0x000000010edea720 in __CFRunLoopRun ()
#21 0x000000010edea016 in CFRunLoopRunSpecific ()
#22 0x0000000112b25a24 in GSEventRunModal ()
#23 0x000000010ca12134 in UIApplicationMain ()
#24 0x000000010be9a6e7 in main at /Users/rlaurb/Projects/RLAUIObjects/RLAUIObjectsExample/RLAUIObjectsExample/AppDelegate.swift:12
#25 0x0000000110d8465d in start ()
So it appears that contentOffset is being set by layout actions of the UINavigationController, even though my custom class only scrolls horizontally and occupies only a small part of the screen.

Several questions come to mind:
  1. Is this a bug? It doesn't seem right that the UINavigationControlller should adjust the scrolling context of something that is well below the top layout guide.
  2. How do I understand this behavior?
  3. How can I work around this behavior (regardless of it being correct or incorrect)? Is there some InterfaceBuilder setting I'm missing? Or can I shield the UIScrollView by embedding it in an otherwise innocuous UIView?

All thoughts and/or suggestions will be most welcome.

Cheers,

Rick Aurbach


Re: NSAllowsArbitraryLoads

Bill Pitcher
 

Thanks, that’s what I suspected

love this Group!!!

cheers
Bill Pitcher
bill@...


Re: NSAllowsArbitraryLoads

 



On Sep 5, 2017, at 3:21 PM, bill@... wrote:

Provided the App Store review allowed it, would having a Preference that adds and sets the info.plist NSAppTransportSecurity/NSAllowsArbitraryLoads to true break my App Store App?

You can't edit your Info.plist, or change settings like these; the app bundle is immutable.

At WWDC this year Apple said that they're getting stricter about App Transport Security exemptions like this. You're going to need a justification for why your app requires arbitrary loads.

—Jens


Re: NSAllowsArbitraryLoads

Alex Zavatone
 


On Sep 5, 2017, at 5:21 PM, bill@... wrote:

Great list,

Provided the App Store review allowed it, would having a Preference that adds and sets the info.plist NSAppTransportSecurity/NSAllowsArbitraryLoads to true break my App Store App?

cheers
Bill
_._,_._,

At my last company, we used it in our iOS apps and they shipped.  



NSAllowsArbitraryLoads

Bill Pitcher
 

Great list,

Provided the App Store review allowed it, would having a Preference that adds and sets the info.plist NSAppTransportSecurity/NSAllowsArbitraryLoads to true break my App Store App?

cheers
Bill

1161 - 1180 of 1478