Re: Release mode bindings crash and release pools

[Charles Srstka]

> On Jun 16, 2017, at 4:32 PM, Quincey Morris 
>  wrote:
> 
> On Jun 16, 2017, at 13:48 , Charles Srstka  > wrote:
>> 
>> This is incorrect.
> 
> It’s incorrect as a 2-way binding, but it works as a pair of so-called 1-way 
> bindings, with the proviso that they may need to be unbound manually, to 
> prevent reference cycles, which it sounds like is what Jerry is doing.
> 
> The thing that I always said that no one believed is that there’s really no 
> such thing as 1-way binding, and NSObject’s default implementation of the 
> “bind:…” method does *not* establish a binding. It’s *part* of the 
> implementation of a proper 2-way binding (as explained in the documentation 
> you referenced), and for a given receiver class the method only establishes a 
> 2-way binding if it’s an override that provides the rest of the functionality.
> 
> But every time I said that (until I stopped saying it about 10 years ago), 
> people would jump in and say that the NSObject implementation really does 
> establish a binding, and if it’s only one-way, that’s 
> just-fine-with-them-thank-you-very-much.
> 
> Thanks for the mention of mmalc, BTW. Them were the times. 

The thing is, though… I can’t find the thread anymore, but I distinctly 
remember posting some code that used -[bind:::] two ways like that, and getting 
chewed out for it. :-P The thing is, NSObject’s implementation of bind is meant 
to be part of a two-way bindings mechanism to be fully implemented by a view 
object, and it’s not really meant to be called outside of that context—and on 
top of that, it’s preferred that bindings go either through an 
NSObjectController, an NSViewController, or something else that implements 
NSEditorRegistration. Just using using -bind twice both ways between two 
arbitrary objects may accidentally work, but it’s not as intended. If all you 
want to do is synchronize some properties on two distinct objects, you’re 
supposed to use plain old KVO for that (as you mention, the new closure-based 
API in Swift is quite nice for doing this). And I did manage to find a quote 
for that last bit, by none other than mmalc himself: 
https://lists.apple.com/archives/Cocoa-dev/2004//Feb/msg01228.html 


Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Release mode bindings crash and release pools

[Quincey Morris]

On Jun 16, 2017, at 14:41 , Jonathan Mitchell  wrote:
> 
> I sometimes use the default NSObject bind: to set up a simple one way 
> operation as you describe as opposed to a discrete observation.

With macOS 10.13, the new block/closure-based KVO “addObserver” method is 
probably an easier way, although you do have to remove it manually.

I’m looking forward to whatever replaces KVO observation and bindings in a 
future version of Swift.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Release mode bindings crash and release pools

[Jonathan Mitchell]

> On 16 Jun 2017, at 22:32, Quincey Morris 
>  wrote:
> 
> On Jun 16, 2017, at 13:48 , Charles Srstka  wrote:
>> 
>> This is incorrect.
> 
> It’s incorrect as a 2-way binding, but it works as a pair of so-called 1-way 
> bindings, with the proviso that they may need to be unbound manually, to 
> prevent reference cycles, which it sounds like is what Jerry is doing.
> 
> The thing that I always said that no one believed is that there’s really no 
> such thing as 1-way binding, and NSObject’s default implementation of the 
> “bind:…” method does *not* establish a binding. It’s *part* of the 
> implementation of a proper 2-way binding (as explained in the documentation 
> you referenced), and for a given receiver class the method only establishes a 
> 2-way binding if it’s an override that provides the rest of the functionality.
> 
I sometimes use the default NSObject bind: to set up a simple one way operation 
as you describe as opposed to a discrete observation.
It works fine.

I haven’t quite figured out yet how NSAutoUnbinder breaks the view <-> 
controller retain cycle when the binding object is the controller.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Release mode bindings crash and release pools

[Quincey Morris]

On Jun 16, 2017, at 13:48 , Charles Srstka  wrote:
> 
> This is incorrect.

It’s incorrect as a 2-way binding, but it works as a pair of so-called 1-way 
bindings, with the proviso that they may need to be unbound manually, to 
prevent reference cycles, which it sounds like is what Jerry is doing.

The thing that I always said that no one believed is that there’s really no 
such thing as 1-way binding, and NSObject’s default implementation of the 
“bind:…” method does *not* establish a binding. It’s *part* of the 
implementation of a proper 2-way binding (as explained in the documentation you 
referenced), and for a given receiver class the method only establishes a 2-way 
binding if it’s an override that provides the rest of the functionality.

But every time I said that (until I stopped saying it about 10 years ago), 
people would jump in and say that the NSObject implementation really does 
establish a binding, and if it’s only one-way, that’s 
just-fine-with-them-thank-you-very-much.

Thanks for the mention of mmalc, BTW. Them were the times. 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Release mode bindings crash and release pools

[Charles Srstka]

> On Jun 16, 2017, at 3:48 PM, Charles Srstka  wrote:
> 
>> On Jun 16, 2017, at 3:27 PM, Jerome Krinock  wrote:
>> 
>>> On 2017 Jun 16, at 10:35, Quincey Morris 
>>> >> > wrote:
>>> 
>>> it takes additional custom code (like in the joystick example) to implement 
>>> the other direction. At least, that’s what I’ve been saying for years, 
>>> though I don’t think I’ve ever found a developer who believes me.
>> 
>> I believe you.  I think it was on your advice I've done this:
>> 
>> foo.bind("xxx", to: bar, ... );
>> bar.bind("yyy", to: foo, ... );
>> 
>> It works, but only in both directions with both statements.
> 
> This is incorrect. The recommended way to implement a two-way binding is to 
> override .bind(…) on the target object and set up KVO observations there. See 
> this page in the docs:
> 
> https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html
>  
> 
> 
> Charles

For more information (and a ton of sample code), see mmalc’s old page on the 
subject. Sadly, it fell off the Web when MobileMe shut down, but archive.org 
 still seems to have most of the info, including the 
project .zip files:

http://web.archive.org/web/20120620180050/http://homepage.mac.com:80/mmalc/CocoaExamples/controllers.html
 


Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Release mode bindings crash and release pools

[Charles Srstka]

> On Jun 16, 2017, at 3:27 PM, Jerome Krinock  wrote:
> 
>> On 2017 Jun 16, at 10:35, Quincey Morris 
>> > > wrote:
>> 
>> it takes additional custom code (like in the joystick example) to implement 
>> the other direction. At least, that’s what I’ve been saying for years, 
>> though I don’t think I’ve ever found a developer who believes me.
> 
> I believe you.  I think it was on your advice I've done this:
> 
> foo.bind("xxx", to: bar, ... );
> bar.bind("yyy", to: foo, ... );
> 
> It works, but only in both directions with both statements.

This is incorrect. The recommended way to implement a two-way binding is to 
override .bind(…) on the target object and set up KVO observations there. See 
this page in the docs:

https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html
 


Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Release mode bindings crash and release pools

[Jerome Krinock]

> On 2017 Jun 16, at 10:35, Quincey Morris 
>  wrote:
> 
> it takes additional custom code (like in the joystick example) to implement 
> the other direction. At least, that’s what I’ve been saying for years, though 
> I don’t think I’ve ever found a developer who believes me.

I believe you.  I think it was on your advice I've done this:

foo.bind("xxx", to: bar, ... );
bar.bind("yyy", to: foo, ... );

It works, but only in both directions with both statements.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Deep linking from 1 tvOS app to another

[Eric E. Dolecki]

Thank you so much!

On Fri, Jun 16, 2017 at 3:15 PM Jens Alfke  wrote:

>
> On Jun 16, 2017, at 8:00 AM, Eric E. Dolecki  wrote:
>
>let modified = supplied.replacingOccurrences(of: " ", with: "+")
>
>
> Don’t use “+”, use “%20”. The “+” is only valid in some contexts IIRC,
> like form values.
>
> Actually don’t do the substitution by hand. Let NSString URL-encode it for
> you. Otherwise your URL will break again when someone decides to type a “/“
> or “#”, etc. into your text field.
>
> —Jens
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Deep linking from 1 tvOS app to another

[Jens Alfke]

> On Jun 16, 2017, at 8:00 AM, Eric E. Dolecki  wrote:
> 
>let modified = supplied.replacingOccurrences(of: " ", with: "+")

Don’t use “+”, use “%20”. The “+” is only valid in some contexts IIRC, like 
form values.

Actually don’t do the substitution by hand. Let NSString URL-encode it for you. 
Otherwise your URL will break again when someone decides to type a “/“ or “#”, 
etc. into your text field.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Release mode bindings crash and release pools

[Quincey Morris]

On Jun 16, 2017, at 08:15 , Jerome Krinock  wrote:
> 
> Typically the only reason you would explicitly unbind an object is if you 
> modify the user interface programatically and want to remove a binding. If 
> you change an objects binding’s values it should first clear any preexisting 
> values.
> 
> If you implement a custom view or controller with custom bindings, you should 
> ensure that it clears any bindings before it is deallocated—in particular it 
> should release any objects that were retained for the specified binding in 
> the bind:toObject:withKeyPath:options: method and should deregister as an 
> observer of any objects for which it registered as an observer. It may be 
> convenient to implement this logic in an unbind: method that you then call as 
> the first step in dealloc.
> 
> # # # #
> 
> I’m confused.  The first paragraph says not to worry about it, and the second 
> says, well, maybe you do.

I doubt this is ever going to be cleared up. The document you refer to was 
written for Tiger (look at the screenshot of the Bindings inspector), so around 
2004. Although it’s been slightly updated several times since, the updates have 
been un-substantial, and I swear the last time an Apple documentation writer 
actually understood bindings was about 2005. Still…

The first paragraph is talking about invoking “unbind:” on a UI object *when 
the object is not being deallocated*.

The second paragraph is talking about “clearing” bindings when the bound object 
is deallocated. It’s just saying you need to ensure you didn’t create any 
retain cycles, and remove KVO observations, and suggesting you might 
encapsulate this cleanup in an “unbind:” method. It’s not (AFAICT) actually 
talking about unbinding anything in any more formal sense (although if you did 
it wouldn’t be wrong).

Part of the conceptual problem is that the kinds of bindings described in the 
document you linked to are bi-directional bindings. The kinds of bindings 
established by “bind:name:object:keyPath:options” are only uni-directional, and 
it takes additional custom code (like in the joystick example) to implement the 
other direction. At least, that’s what I’ve been saying for years, though I 
don’t think I’ve ever found a developer who believes me.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Deep linking from 1 tvOS app to another

[Eric E. Dolecki]

That makes perfect sense. I was talking to a tvOS engineer @ WWDC 2017 and
was told I don't have to worry about URLencoding app to app URLs. I thought
that sounded weird, tried it, sure didn't work ;)

Thanks Aandi.

On Fri, Jun 16, 2017 at 12:48 PM Aandi Inston  wrote:

> Spaces are not legal in a URL. So failure or unpredictable results is
> expected. See for example discussion here
> https://stackoverflow.com/questions/497908/is-a-url-allowed-to-contain-a-space
>
>
> On 16 June 2017 at 16:00, Eric E. Dolecki  wrote:
>
>> I have deep linking working, but if I introduce spaces into the URL, it
>> fails. Is this expected or can I do this another way?
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Property in class mirrored to user defaults

[Jonathan Taylor]

Thankyou Charles and Keary for your replies. I somehow hadn't thought of using 
NSDefaults as backing for the properties. There are a lot of properties 
involved, but with a macro or something I should be able to set it up without a 
massive code bloat. Will give that a go.
Cheers
Jonny

On 12 Jun 2017, at 16:01, Charles Srstka  wrote:

>> On Jun 12, 2017, at 4:04 AM, Jonathan Taylor  
>> wrote:
>> 
>> Hi all,
>> 
>> This feels like a very basic question, but one that I have not had any luck 
>> searching for (maybe I am using the wrong terms?).
>> 
>> At the moment I have properties in a (singleton) class that are bound to UI 
>> elements. At the moment they have the same automatic values every time the 
>> app is launched, although the user can change them while it is running. What 
>> I would like is for the user's previous choice to be remembered when the app 
>> is next launched. Obviously this would seem to be a job for NSUserDefaults. 
>> I am not sure quite what the right way to structure things is, though.
>> 
>> All the simple examples I have seen bind to NSUserDefaults and then if the 
>> program actually wants to know what the value is, it simply accesses the 
>> values directly on NSUserDefaults. I would prefer not to do that, though 
>> (see below).
>> 
>> What I ~think~ I would like is to still be able to access the values as 
>> properties of my class. That seems to me like the natural way, and it would 
>> seem odd to have two categories of value, some accessed through properties 
>> on the class, and some accessed some other way via NSUserDefaults. However, 
>> if I bind the UI elements to the shared user defaults object, is that not 
>> what will happen? Or is there some way that I can "link" my class and the 
>> user defaults object, so that the properties are saved in user defaults but 
>> I can still access them in a fairly seamless way from my class? I do like 
>> the idea of having the properties (and their types) explicitly declared as 
>> part of my class, rather than being mysterious objects that only exist in 
>> the user defaults.
>> 
>> Does anyone have any advice on how I can achieve this, or on how I should be 
>> thinking about all this differently?
>> Thanks
>> Jonny
> 
> If performance isn’t an issue, as it usually isn’t for properties linked to 
> UI elements, and you don’t want to bind the UI elements directly to an 
> NSUserDefaultsController, you can just use UserDefaults as the backing for a 
> property, like this:
> 
> class MyClass: NSObject { 
>   // this is a property only so we can make key paths that will go 
> through it
>   @objc private let userDefaults: UserDefaults
>   private static let fooDefaultsKey = "Foo"
>   
>   @objc private static let keyPathsForValuesAffectingFoo: Set = 
> ["\(#keyPath(userDefaults)).\(MyClass.fooDefaultsKey)"]
>   @objc dynamic var foo: String {
>   get { return UserDefaults.standard.string(forKey: 
> MyClass.fooDefaultsKey) ?? "" }
>   set { UserDefaults.standard.set(newValue, forKey: 
> MyClass.fooDefaultsKey) }
>   }
>   
>   override init() {
>   self.userDefaults = UserDefaults.standard
>   
>   super.init()
>   }
> }
> 
> This is pretty cool; on recent releases of macOS, it’ll respond to changes in 
> the defaults even if they come from outside the process. So, if you observe 
> the “foo” property, and then manually use /usr/bin/defaults to change the 
> defaults, your notifications in the app will fire.
> 
> Alternately, you can just set up the property at init time and then update 
> the defaults whenever it changes, like this. You won’t get the cool 
> observation behavior, though, unless you use KVO’s infamously ugly 
> observation APIs (the slick new closure-based one won’t work here, since 
> we’re stuck with using string keys for this).
> 
> class MyClass: NSObject { 
>   private static let fooDefaultsKey = "Foo"
>   
>   @objc dynamic var foo: String {
>   didSet { UserDefaults.standard.set(self.foo, forKey: 
> MyClass.fooDefaultsKey) }
>   }
>   
>   override init() {
>   self.foo = UserDefaults.standard.string(forKey: 
> MyClass.fooDefaultsKey) ?? ""
>   
>   super.init()
>   }
> }
> 
> Charles
> 

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Deep linking from 1 tvOS app to another

[Aandi Inston]

Spaces are not legal in a URL. So failure or unpredictable results is
expected. See for example discussion here
https://stackoverflow.com/questions/497908/is-a-url-allowed-to-contain-a-space

On 16 June 2017 at 16:00, Eric E. Dolecki  wrote:

> I have deep linking working, but if I introduce spaces into the URL, it
> fails. Is this expected or can I do this another way?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Release mode bindings crash and release pools

[Jerome Krinock]

Quincey is correct that closing of windows in macOS is a complicated, tricky 
process which may have edge case bugs.  Also, although you mentioned invoking 
-bind: (also known as “manual” binding), you have not mentioned -unbind:.

In complicated window controllers, I implement a -tearDownOnce method which is 
invoked by -[NSWindowControllerDelegate windowWillClose] and also by 
-[NSDocumentController removeDocument].  After checking that it has not been 
run, -tearDownOnce invokes -unbind: on anything which I have “manually” bound.

I started doing this many years ago.  I think I remember reading somewhere that 
such *unbinding* is no longer necessary in recent versions of macOS.  Does 
anyone know of reference on that?  I just looked at the documentation on this, 
Cocoa Bindings Programming Topics > Unbinding, and found this:

# # # #

Typically the only reason you would explicitly unbind an object is if you 
modify the user interface programatically and want to remove a binding. If you 
change an objects binding’s values it should first clear any preexisting values.

If you implement a custom view or controller with custom bindings, you should 
ensure that it clears any bindings before it is deallocated—in particular it 
should release any objects that were retained for the specified binding in the 
bind:toObject:withKeyPath:options: method and should deregister as an observer 
of any objects for which it registered as an observer. It may be convenient to 
implement this logic in an unbind: method that you then call as the first step 
in dealloc.

# # # #

I’m confused.  The first paragraph says not to worry about it, and the second 
says, well, maybe you do.  So, whether unbinding is really necessary nowadays 
or just defensive programming, I don’t know.  But I’ve found that as long as I 
-unbind early, as I described above, and ensure that I carefully balance -bind: 
and -unbind:, I don’t get those pesky NSAutoUnbinder crashes.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Deep linking from 1 tvOS app to another

[Eric E. Dolecki]

I have deep linking working, but if I introduce spaces into the URL, it
fails. Is this expected or can I do this another way?

textfield value "hello my name is Eric"

@IBAction func editingEnded(_ sender: Any) {
if let supplied = textEntry.text {

 *   //If I don't do this, url is nil*
let modified = supplied.replacingOccurrences(of: " ", with: "+")
let url = URL(string: "(mySchemeHere)://article/\(modified)")
UIApplication.shared.open(url!, options: [:],
completionHandler: nil)
}
}

--> comes in to my other tvOS application as

"hello+my+name+is+Eric"

URLs need encoded for real-world use, so I assume that it needs done for
app to app comm too?

Eric
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Unable to extract JPEG from PHAsset

[Glen Huang]

Hi,

I'm trying to extract the JPEG data from a PHAsset. I did it like this:

let fetchOptions = PHFetchOptions()
fetchOptions.sortDescriptors = [NSSortDescriptor(key: 
"creationDate", ascending: true)]
let assets = PHAsset.fetchAssets(with: fetchOptions)
jpg(for: assets[0])

where jpg(for:) is

func jpg(for asset: PHAsset) {
let size = CGSize(width: 100, height: 100)
PHImageManager.default().requestImage(for: asset, targetSize: size, 
contentMode: .aspectFit, options: nil) { image, info in
if let image = image {
let jpg = UIImageJPEGRepresentation(image, 0.8)!
}
}
}

It works in the simulator running iOS 11, but fails on iPhone 5S every time with

fatal error: unexpectedly found nil while unwrapping an Optional value

And the thing caused that error was the bang after the 
UIImageJPEGRepresentation function.

I'm using Xcode 9 beta, Swift 4, new build system, and the phone runs iOS 10.3.2

Any idea why that happens and how I can extract the JPEG data from PHAsset? 

Thank you.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com