Post not yet marked as solved
I am seeing this crashes in 15.5 version, I am using flutter code base seeing like this and dlyd issues many crashes
Post not yet marked as solved
Trying to access value using NSUbiquitousKeyValueStore.default.object(forKey:) locking the main thread on iOS 16 beta 3, iPhone 11 Pro.
Is that known issue or something that only happens to me? :)
Post not yet marked as solved
I need any kind of help I can get on this question and am open to any solutions or workarounds.
When I archive FileManager.ubiquityIdentityToken with NSKeyedArchiver.archivedData(withRootObject:requiringSecureCoding:), what should I set the second parameter to in order to be able to unarchive later, and how do I unarchive the Data object using unarchivedObject(ofClass:from:) or any other method of NSKeyedUnarchiver?
My code currently uses the deprecated method of archivedData(withRootObject:), which gives me a code time warning saying:
'archivedData(withRootObject:)' was deprecated in iOS 12.0: Use +archivedDataWithRootObject:requiringSecureCoding:error: instead
I'm getting code time error messages in red for the argument to archivedData(withRootObject:requiringSecureCoding:) which is declared as type Any. I tried different arguments. The one I this should work is (NSCoding & NSCopying & NSObject).Type, which generates two error messages:
Static method 'unarchivedObject(ofClass:from:)' requires that '(NSObject & NSCoding & NSCopying).Type' inherit from 'NSObject'
Type '(NSObject & NSCoding & NSCopying).Type' cannot conform to 'NSCoding'
Setting the argument to (NSCoding & NSCopying & NSObject) generates the error message:
'NSObject & NSCoding & NSCopying' cannot be used as a type conforming to protocol 'NSCoding' because 'NSCoding' has static requirements
I haven't been able to discover what that means that 'NSCoding' has static
I get the idea to use (NSCoding & NSCopying & NSObject) because when run code:
print("type of FileManager.default.ubiquityIdentityToken: \(type(of: FileManager.default.ubiquityIdentityToken))")
the debug window shows
type of FileManager.default.ubiquityIdentityToken: Optional<NSCoding & NSCopying & NSObject>
but when I run the following code
print("type of FileManager.default.ubiquityIdentityToken: \(type(of: FileManager.default.ubiquityIdentityToken!))")
I get the following in the debug window
type of FileManager.default.ubiquityIdentityToken: _NSInlineData
I read on stackoverflow that "_NSInlineData" is not made available to us by Apple.
I'm open to doing this any other way, not necessarily with NSKeyedArchiver or NSKeyedUnarchiver, including using unsafe pointers if necessary.
In one of Apple's documentation or sample Xcode projects, I found code to check the login status of a user on iOS when an app logs on by checking FileManager.ubiquityIdentityToken and to check the current status with the previous status by checking the ubiquityIdentityToken that was saved in UserDefaults. Is there a better way of doing this?
Our (legacy) code to communicate with peripherals on local IPv6 networks (LAN) adds the zone identifier / interface name ("%en0") to link-local IP addresses (FE80::/10) discovered via SSDP. SSDP is implemented using CocoaAsyncSocket - yes, that part of our code is old... (from before the introduction of the iOS 12+ Network framework). We use these modified IP addresses as the host component of a URL in a URLSession.dataTask.
To insert the zone identifier we are using URLComponents (we modify the host and then request the string). This worked fine in iOS 15 and below, but no longer works in iOS 16 (Beta 1/2/3); the host is empty after inserting %en0 in the most recent beta.
We have reported this via FB10549269, but from the answer it is unclear to me whether Apple is planning to fix this ("Resolution: Potential fix identified"), or we are doing it wrong.
How should we handle IPv6 link-local addresses in iOS 16? (when using URLSession instead of Network)
PS: We recently dropped support for iOS 12, but we still need to support iOS 13 and up
Post not yet marked as solved
Can someone help me in identifying the source of this crash that I see in crash logs?
Post not yet marked as solved
I am trying to write a Swift standalone library to monitor a UserDefaults value and callback a function in Python. To do so, I need an event loop in the Swift code that allows the Observer code to run and, when needed, call the callback function.
I am monitoring the default via a KVO Observer class, which inherits a NSObject with UserDefaults.standard.addObserver in its init and implements observeValue as callback.
To keep the loop running, up to now I called RunLoop.current.run() in the end of the Swift library invoked function. As you can imagine, this works well when the library is called from a main thread, which can provide inputs to the RunLoop.
On the other hand, this fails (the library returns immediately) when the function is invoked from a secondary thread without e.g. the stdin attached.
I am looking for an alternative to RunLoop.current.run() that:
runs indefinitely
can run in a secondary thread with no inputs
does not block callbacks to observeValue
I tried the most obvious choices like an infinite while or DispatchQueue but so far I was not able to achieve what I need.
Further details about the issue can be found in a related StackOverflow question here: https://stackoverflow.com/questions/72982210/swift-and-python-get-a-runloop-that-can-run-in-threading
Thanks in advance for your help.
NSMutableAttributedString does strange things with 𝛑 and 𝒆. This is Unicode "Mathematical Bold Small Pi" and the 𝒆 that is near it in the Unicode table. Less exotic characters don't have this problem.
Changing the attribute map of an existing NSMutableAttributedString containing these characters with some foreground colors (like white, for instance) results in a strange doubling of the character when the resulting string is rendered in a CATextLayer. It doesn't happen if the NSMutableAttributedString is created with the different map. It only happens when you use #setAttributes on an existing string.
Displaying an NSMutableAttributedString containing these characters with various colors applied in a UITextField results in the strange doubling regardless of the colors involved. Furthermore, attribute ranges are thrown off by this.
Post not yet marked as solved
Has anyone else seen in Ventura B3 where you have a URL path as a source and you want to use the filename for that, aka lastPathComponent in a destination URL, so you have something like:
let destinationURL = destinationDIrectory.appendingPathExtension(sourceURL.lastPathComponent)
and lastPathComponent is a file name
but what you get for destinationURL is: destinationDirectory.lastPathComponent instead of destinationDirectory/lastPathComponent
or is it just me?
Post not yet marked as solved
Problem
My app needs to send an HTTP-like request over TCP, followed by periodic data and get back a stream of data in the foreground and background in return.
In the background, I need to open and close the socket after receiving a Bluetooth characteristic value, which is an unnecessary overhead that slows the user down and may lead to a lot of lost data.
Currently
In the foreground, it opens an NSSocket (through a framework), sends the initial request and periodically sends and receives data.
While in the background, the app is started when it receives a characteristic value from the bluetooth-central background mode. It then opens the socket to send some initial data, waits for some data in return, and closes the socket.
Considerations
The protocol I need to connect to is HTTP-like (NTRIP), so I considered using a URLSession, which can keep a socket open, even in the background. However, the protocol has some non-standard behaviors. Namely:
It can return a SOURCETABLE response (interchangeable with HTTP/1.1).
Some implementations have a non-standard second status line (e.g. HTTP/1.1 OK 200, followed by HTTP/1.1. Not Authorized 401).
Some rare implementations incorrectly fail to separate the status line and message body with CRLF.
The connection needs to be kept open to periodically send and receive data.
A future revision of NTRIP does enforce HTTP compliance, but is not yet widely used.
Post not yet marked as solved
Will user default values will be cleared if TestFlight build is installed on top of App Store build?
App is getting abnormal in some times when this action happens. But not sure if this could be an ideal reason. This action was not able to replicate when in debugging mode.
please help on clarifying the issue. Thanks
Post not yet marked as solved
Where is Apple's documentation of NSConcreteAttributedString?
I need to get the String from NSExtensionItem.attributedContentText property, which is of type NSConcreteAttributedString.
Post not yet marked as solved
So far have this custom API class and I'm wanting to create a custom URL delegate for the tasks that I will be performing with this API, this code below gathered from the Apple Docs -> Apple Docs URL loading/fetching Listing #2 to be exact... keep getting 'Argument type 'API' does not conform to expected type 'URLSessionDelegate''
var delegate: URLSessionDelegate?
static var requestObject: URLSession = {
let configuration = URLSessionConfiguration.ephemeral
configuration.allowsCellularAccess = true
configuration.waitsForConnectivity = true
return URLSession(configuration: configuration, delegate: self, delegateQueue: nil)
}()
}
protocol URLSessionDelegate{
var delegate: URLSessionDelegate? {get}
}
Not sure why but seems to be maybe error in codebase, as I have tried many tutorials and solutions and no one provides an explicit working version for a custom delegate (not a shared session) that allows for various configurations for URLSessions.
Post not yet marked as solved
I tested below code:
var c = URLComponents(string: "myscheme://")!
c.host = "my host with space"
let url = c.url!
print(url)
print(url.host)
In Xcode 13.4, the console prints:
myscheme://my%20host%20with%20space
Optional("my host with space")
In Xcode 14, the console prints:
myscheme:
nil
According to URLCompinents.host documentation, it should encode in setter:
The getter for this property removes any percent encoding this component may have (if the component allows percent encoding). Setting this property assumes the subcomponent or component string is not percent encoded and will add percent encoding (if the component allows percent encoding).
Post not yet marked as solved
Hello community!
As I read from https://support.apple.com/kb/SP743?locale=en_US iPhone7 has A10 Fusion chip, which has 4 cores, but [NSProcessInfo processInfo].processorCount returns 2.
Also here it is stated that "Unlike most implementations of big.LITTLE, such as the Snapdragon 820 or Exynos 8890, only one core type can be active at a time, either the high-performance or low-power cores, but not both. Thus, the A10 Fusion appears to software and benchmarks as a dual core chip. "
Another source tells us that: "Meanwhile it should be noted that while A10 technically has four CPU cores – the two Hurricane cores and the two smaller cores – this is not a heterogeneous design, and only two cores are active at once. So for the purposes of high performance benchmarking, this means we're benchmarking the big cores nearly exclusively."
Can anybody confirm this or give the link to apple documentation to prove that?
Thanks!
Post not yet marked as solved
I'm getting some Crash Reports for an app of mine that's on the Mac App Store. A few details:
-All the crash reports are on ARM-64 Macs.
-The call stack shows my app calling NSURL's -getResourceValue:forKey: method with NSURLLocalizedNameKey, which is the last call made by my app before the crash. After that crash logs look like this:
**Thread 0 Crashed:
0 libobjc.A.dylib 0x00000001a623c4b0 objc_retain + 16
1 LaunchServices 0x00000001a6954f68 -[FSNode(PathAndName) nameWithError:] + 72
2 LaunchServices 0x00000001a6a36278 +[_LSDisplayNameConstructor(ConstructForAnyFile) displayNameConstructorWithContextIfNeeded:bundle:bundleClass:node:preferredLocalizations:error:] + 2732
3 LaunchServices 0x00000001a6a357ac +[_LSDisplayNameConstructor(ConstructForAnyFile) displayNameConstructorWithContextIfNeeded:node:error:] + 44
4 LaunchServices 0x00000001a6ae5b20 LaunchServices::URLPropertyProvider::getDisplayNameConstructor(LaunchServices::Database::Context&, FSNode*, LaunchServices::URLPropertyProvider::State*, NSError* __autoreleasing*) + 88
5 LaunchServices 0x00000001a6ae1930 LaunchServices::URLPropertyProvider::prepareLocalizedNameValue(LaunchServices::Database::Context&, FSNode*, __FileCache*, __CFString const*, LaunchServices::URLPropertyProvider::State*, NSError* __autoreleasing*) + 328
6 LaunchServices 0x00000001a6953d6c LaunchServices::URLPropertyProvider::prepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) + 456
7 CoreServicesInternal 0x00000001a8def6f0 prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) + 452
8 CoreServicesInternal 0x00000001a8dec5ec _FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, __CFString const*, void*, void*, __CFError**, unsigned char) + 236
9 CoreFoundation 0x00000001a64546b0 CFURLCopyResourcePropertyForKey + 144
10 CoreFoundation 0x00000001a646b944 -[NSURL getResourceValue:forKey:error:] + 120**
--
I haven't been able to reproduce the issue on my ARM-64 Mac. Not sure what's going with _LSDisplayNameConstructor or if there is a way I can workaround/resolve.
Some of the crashes have the following lines included:
Kernel Triage:
VM - Compressor failed a blocking pager_get
VM - Compressor failed a blocking pager_get
VM - Compressor failed a blocking pager_get
VM - Compressor failed a blocking pager_get
VM - Compressor failed a blocking pager_get
Post not yet marked as solved
We've been working with VMWare on a ticket related to slow upload/download transfers using the VMWare API/SDK on Mac. They believe the root cause is below.
The slow performance is caused by Apple's authentication subsystem (PAM/opendrectoryd) being slow and using a lot of CPU. The security for guestOps file transfer requires an authn check for every packet, packets are limited to ~60k bytes due to the underlying arch; hence every 60k bytes of data has a ~.2 second overhead for the authn. (We see no such delays for Linux or Windows.)
Does anyone have any experience with PAM/opendirectoryd who might be able be help me?
Crashed: com.apple.main-thread
0 libsystem_kernel.dylib 0x7260 __pthread_kill + 8
1 libsystem_pthread.dylib 0x73c0 pthread_kill + 268
2 libsystem_c.dylib 0x20e74 abort + 180
3 libsystem_c.dylib 0x77940 err + 270
4 UIFoundation 0xde800 -[_NSOptimalLineBreaker _softHyphenPenaltyForBreak:].cold.1 + 42
5 UIFoundation 0x70ca4 -[_NSOptimalLineBreaker _breakPenaltyForHyphenationFactor:] + 174
6 UIFoundation 0x70cc8 -[_NSOptimalLineBreaker _breakPenaltyForHyphenationFactor:] + 36
7 UIFoundation 0x70d38 -[_NSOptimalLineBreaker _softHyphenPenaltyForBreak:] + 72
8 UIFoundation 0x70e7c -[_NSOptimalLineBreaker _demeritFromBreak:toBreak:usingExpansionRatio:] + 164
9 UIFoundation 0x725f4 -[_NSOptimalLineBreaker _createNodeWithParent:lineBreak:expansionRatio:] + 152
10 UIFoundation 0x72f84 __50-[_NSOptimalLineBreaker _calculateOptimalWrapping]_block_invoke + 144
11 CoreFoundation 0x6ea4 __CFSetApplyFunction_block_invoke + 28
12 CoreFoundation 0x29344 CFBasicHashApply + 148
13 CoreFoundation 0xd87c CFSetApplyFunction + 320
14 UIFoundation 0xb51f8 _CFSetApplyBlock + 60
15 UIFoundation 0x72a00 -[_NSOptimalLineBreaker _calculateOptimalWrapping] + 472
16 UIFoundation 0x93e8c -[NSParagraphArbitrator _computeOptimalLayout] + 252
17 UIFoundation 0x93ce4 -[NSParagraphArbitrator _optimalLineBreakContextBeforeIndex:lineFragmentWidth:range:] + 84
18 UIFoundation 0xa0b50 -[NSCoreTypesetter _createLineRefForParentLineRef:range:availableWidth:offset:paragraphArbitrator:lineBreakMode:hyphenated:forcedClusterBreak:] + 532
19 UIFoundation 0x1aecc -[NSCoreTypesetter _stringDrawingCoreTextEngineWithOriginalString:rect:padding:graphicsContext:forceClipping:attributes:stringDrawingOptions:drawingContext:stringDrawingInterface:] + 4536
20 UIFoundation 0x161c8 __NSStringDrawingEngine + 1284
21 UIFoundation 0x24cbc -[NSAttributedString(NSExtendedStringDrawing) boundingRectWithSize:options:context:] + 644
22 UIKitCore 0x1462f0 _UIComputedSizeForLabel + 452
23 UIKitCore 0x2676e0 -[UILabel _textRectForBounds:limitedToNumberOfLines:includingShadow:] + 700
24 UIKitCore 0x14e8e0 -[UILabel _intrinsicSizeWithinSize:] + 476
25 UIKitCore 0x259494 -[UILabel intrinsicContentSize] + 280
26 UIKitCore 0x155150 -[UIView _generateContentSizeConstraints] + 52
27 UIKitCore 0x1e68d8 -[UIView _updateContentSizeConstraints] + 244
28 UIKitCore 0x275b98 -[UIView(AdditionalLayoutSupport) _updateSystemConstraints] + 88
29 UIKitCore 0x2c5cc4 -[UIView(AdditionalLayoutSupport) _sendUpdateConstraintsIfNecessaryForSecondPass:] + 348
30 UIKitCore 0x13c5b8 -[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededCollectingViews:forSecondPass:] + 764
31 UIKitCore 0x13c4d4 -[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededCollectingViews:forSecondPass:] + 536
32 UIKitCore 0x13c4d4 -[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededCollectingViews:forSecondPass:] + 536
33 UIKitCore 0x13c4d4 -[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededCollectingViews:forSecondPass:] + 536
34 UIKitCore 0x13c4d4 -[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededCollectingViews:forSecondPass:] + 536
35 UIKitCore 0x13c4d4 -[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededCollectingViews:forSecondPass:] + 536
36 UIKitCore 0x13c4d4 -[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededCollectingViews:forSecondPass:] + 536
37 UIKitCore 0x13c4d4 -[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededCollectingViews:forSecondPass:] + 536
38 UIKitCore 0x13c4d4 -[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededCollectingViews:forSecondPass:] + 536
39 CoreAutoLayout 0x787c -[NSISEngine withBehaviors:performModifications:] + 84
40 UIKitCore 0x1f42fc -[UIView(AdditionalLayoutSupport) _updateConstraintsIfNeededWithViewForVariableChangeNotifications:] + 508
41 UIKitCore 0x3986ec -[UIView(AdditionalLayoutSupport) _updateConstraintsAtEngineLevelIfNeededWithViewForVariableChangeNotifications:] + 388
42 UIKitCore 0x13ff78 -[UIView _updateConstraintsAsNecessaryAndApplyLayoutFromEngine] + 332
43 UIKitCore 0x13989c -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1980
44 QuartzCore 0x3b380 CA::Layer::layout_if_needed(CA::Transaction*) + 500
45 QuartzCore 0x2d238 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 148
46 QuartzCore 0x41834 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 456
47 QuartzCore 0x4abd8 CA::Transaction::commit() + 652
48 QuartzCore 0x2c918 CA::Transaction::flush_as_runloop_observer(bool) + 88
49 UIKitCore 0x42c768 _UIApplicationFlushCATransaction + 52
50 UIKitCore 0x64f310 _UIUpdateSequenceRun + 84
51 UIKitCore 0xc72984 schedulerStepScheduledMainSection + 172
52 UIKitCore 0xc71fcc runloopSourceCallback + 92
53 CoreFoundation 0xb928c CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28
54 CoreFoundation 0xc9dc8 __CFRunLoopDoSource0 + 176
55 CoreFoundation 0x5d2c __CFRunLoopDoSources0 + 244
56 CoreFoundation 0xb4f4 __CFRunLoopRun + 836
57 CoreFoundation 0x1f080 CFRunLoopRunSpecific + 612
58 GraphicsServices 0x1360 GSEventRunModal + 164
59 UIKitCore 0x40afb4 -[UIApplication _run] + 888
60 UIKitCore 0x2116e8 UIApplicationMain + 340
Post not yet marked as solved
A puzzling phenomenon occurs in obtaining the week number.
Please see the attached source.
In Step 0, the correct week number can be obtained according to ISO8601.
In Step 1, by changing minimumDaysInFirstWeek, a new (correct) week number can be obtained.
In Step 2, if I re-set the firstWeekday, for some reason the week number reverts back to the original, even though the value has not been changed.
Shouldn't Step2 return 1 for both weekOfMonth and weekOfYear?
I have verified this with XCode 13.4 playground.
Thanks in advance.
import Foundation
var calendar = Calendar(identifier: .iso8601)
let date = calendar.date(from: DateComponents(year: 2022, month: 1, day: 1))
print("*** Step 0 ***")
print("firstWeekday : \(calendar.firstWeekday)")
print("minimumDaysInFirstWeek : \(calendar.minimumDaysInFirstWeek)")
print("weekOfMonth : \(calendar.component(.weekOfMonth, from: date!))")
print("weekOfYear : \(calendar.component(.weekOfYear, from: date!))")
print("\n*** Step 1 ***")
calendar.minimumDaysInFirstWeek = 1
print("firstWeekday : \(calendar.firstWeekday)")
print("minimumDaysInFirstWeek : \(calendar.minimumDaysInFirstWeek)")
print("weekOfMonth : \(calendar.component(.weekOfMonth, from: date!))")
print("weekOfYear : \(calendar.component(.weekOfYear, from: date!))")
print("\n*** Step 2 ***")
calendar.firstWeekday = 2
print("firstWeekday : \(calendar.firstWeekday)")
print("minimumDaysInFirstWeek : \(calendar.minimumDaysInFirstWeek)")
print("weekOfMonth : \(calendar.component(.weekOfMonth, from: date!))")
print("weekOfYear : \(calendar.component(.weekOfYear, from: date!))")
Result
*** Step 0 ***
firstWeekday : 2
minimumDaysInFirstWeek : 4
weekOfMonth : 0
weekOfYear : 52
*** Step 1 ***
firstWeekday : 2
minimumDaysInFirstWeek : 1
weekOfMonth : 1
weekOfYear : 1
*** Step 2 ***
firstWeekday : 2
minimumDaysInFirstWeek : 1
weekOfMonth : 0
weekOfYear : 52
Post not yet marked as solved
Hi
We are getting following issue on user's end. We are unable to reproduce it. Sharing the logs we have. Please help in this.
iOS : CoreFoundation _CF_forwarding_prep_0
Post not yet marked as solved
Hi,
We are getting this crash on client side. don't know how to reproduce this. please help in this.
CoreFoundation percentEscapeDecodeBuffer
