User Profile

Can anyone explain why an iPhone might always be returning true for the UIScreen.isCaptured property, even after the device has been fully restarted and there is no screen mirroring or recording taking place? Are there any non-obvious scenarios where it would always be true? We have a user reporting an issue that can only be explained by this property incorrectly or erroneously coming back as true.

I have some customers reporting extreme keyboard lag when typing anything in our app. I have two movies demonstrating this behavior: As well as this movie: I really don't believe that this is related to any of our code -- this is the standard keyboard in both cases, and if somehow our code was blocking the UI thread the OS would kill our app. We are unable to reproduce this behavior in-house and this only seems to apply to a handful of our customers. If you search "keyboard lag" on Apple dev forums you will see numerous threads: https://developer.apple.com/forums/thread/5071 https://developer.apple.com/forums/thread/79442?answerId=235108022#235108022 https://developer.apple.com/forums/thread/665191?answerId=656127022#656127022 https://developer.apple.com/forums/thread/671132 However, most of these threads are very old and it's not clear that there is or was a resolution. This issue seems to have persisted across multiple releases of iOS 14 for our members. We opened a ticket with Apple DTS but they were unable to offer any guidance. Has anyone here experienced this issue themselves, and can anyone offer a workaround beyond hoping that this is an iOS issue that Apple will fix in the future?

When using uploadTask(with:fromFile:) - https://developer.apple.com/documentation/foundation/urlsession/1411550-uploadtask to perform an upload in the background, should the fileUrl be kept in the temp directory: NSTemporaryDirectory() Or should it instead be the Caches directory? NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES) I ask because I am starting to see this crashing stack: Fatal Exception: NSInvalidArgumentException Cannot read file at file:///private/var/mobile/Containers/Data/Application/XXXXXXXX-XXXX-XXXX-XXXX-CB39D5E080D9/tmp/org.alamofire.manager/multipart.form.data/XXXXXXXX-XXXX-XXXX-XXXX-28C54136FC0A Coming from: Request.swift - Line 583partial apply for closure #2 in UploadRequest.Uploadable.task(session:adapter:queue:) + 583 And I suspect that the file is maybe being deleted while also being actively used by a background uploadTask? The Apple File System basics docs - https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW2 say this about data in the temporary directory: [you] cannot rely on these files persisting after your app terminates It says this about caches: Cache data can be used for any data that needs to persist longer than temporary data, but not as long as a support file NOTE: though this crashing stack is coming from Alamofire, - https://github.com/Alamofire/Alamofire I am in the process of re-writing it from scratch using pure-native Apple APIs, so assume for the purposes of this question that Alamofire is not part of the stack. Where should I be writing temporary files for upload?

Hi,I am seeing clipping of text in a UITextView which (historically) has been symptomatic of incorrect text measurements. While investigating this issue, we discovered that in the latest iOS 12 beta (iOS 12 build (16A5357b)) running on an iPhone X device, we are seeing a regression in the boundingRectWithSize method. Specifically, the value seems to come back too large on an actual device compared to a simulator.If you run the following code: NSString *text = @"x *** *** *** xx xxxx, xx x xxxx xxxx *** *** xxxx xxxx xxxxx... *** xxxxxx xxxxx x *** xxxx xx xxxx x xxxxxx xx xxxx xx xxxxxxx xx x *** xxxxxxxx... *** xxxxxxxxxxx xx x xxxx *** xxxxxxxx *** xxxx xxxx xx xxxxxxxxxx xx xx xxxxxxx xx xxxx?"; CGRect boundingRect = [text boundingRectWithSize:CGSizeMake(285, CGFLOAT_MAX) options:(NSStringDrawingUsesLineFragmentOrigin | NSStringDrawingUsesFontLeading) attributes:@{ NSFontAttributeName : [UIFont preferredFontForTextStyle:UIFontTextStyleBody] } context:nil];On the simulator, it shows:Rect is {{0, 0}, {283.521484375, 152.287109375}}When the code above is run on a physical iPhone X device running iOS 12 build (16A5357b), it shows:Rect is {{0, 0}, {283.521484375, 169.393867505}}Should I expect this difference between Simulator and a real device, or is this a bug?Thanks!