Post not yet marked as solved
Are you hitting this problem while using Xcode? Or hitting the problem when you run code that was created by Xcode?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
It’s hard to say what’s going on here without more context. To start, please post a full crash report, following the advice in Posting a Crash Report.
ps I recommend that you read the following:
SecItem: Fundamentals
SecItem: Pitfalls and Best Practices
The SecItem API is full of pitfalls, and these posts will help you steer clear of them.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
What UI framework are you using?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
This is on iOS, right?
If so, the typical IPC mechanisms are unlikely to work. Most IPC APIs require that both ends of the connection be running, and that’s not the case on iOS. Either App 1 or App 2 will be in the background, and iOS typically suspends an app when it moves to the background.
I talk more about this in iOS Background Execution Limits.
Can you explain more about the context here?
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
You’ve misunderstood how signing for distribution works. A .ipa file is basically a zip archive. Signing that makes no sense. Rather, you have to sign the binary within the zip archive.
The process I recommend is to create an Xcode archive and then export distribution stuff from that. To learn more about this, see Creating distribution-signed code for macOS. While that’s focused on the Mac, the same basic process works for iOS.
If you follow this process then you never need to re-sign a .ipa. That’s good, because doing that is a pain. You have to unpack the .ipa, re-sign the app within that, and then repack the .ipa. DTS doesn’t support this process. Indeed, we don’t support re-signing iOS apps at all. That’s why the above article is focused on the Mac. So, it’s best to avoid this tarpit by staying on the Xcode archive path.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
I was able to fix this issue
Yay!
As to the libapr.dylib, I can’t seem to find a binary to download (and I don’t have time to build it from source). Can you post the binary to a file sharing service and then reply here with the link?
Post the link in the clear, per Quinn’s Top Ten DevForums Tips.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
unable to build chain to self-signed root for signer
See Fixing an untrusted code signing certificate.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
Regarding deleting threads, see here.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
Also, keep in mind that NEHotspotHelper is not designed as a general-purpose Wi-Fi API. Quoting from that post you referenced:
This value only updates in real time for networks that your
hotspot helper is managing, as indicated by the
isChosenHelper property.
If you’re working with normal Wi-Fi networks — rather than a hotspot, where the user must interact with the network to gain access to the wider Internet — you won’t become the chosen helper and thus you won’t get read-time updates.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
The com.apple.rpmuxd job is not part of the base system, because it needs to be separately updated. Consider:
% sudo launchctl print system/com.apple.rpmuxd
system/com.apple.rpmuxd = {
active count = 0
path = /Library/Apple/System/Library/LaunchDaemons/com.apple.rpmuxd.plist
…
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
Yeah, I think you should file a bug about this. Make sure to include a sysdiagnose log taken while the CPU is pinned.
Please post your bug number, just for the record.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
Problems like this are almost always related to optimisation. Consider code like this:
1 import Network
2
3 func main() {
4 let connection = NWConnection(host: "example.com", port: 80, using: .tcp)
5 // … set up state handler and so on …
6 connection.start(queue: .main)
7 dispatchMain()
8 }
9
10 main()
This is likely to work in your Debug build but it’s possible that it might fail in your Release build. That’s because the last reference to connection is on line 6, so the optimiser might release that reference before the call to dispatchMain(). If it does, and nothing else is holding a reference, the underlying object will be deallocated and that’ll cancel the connection.
While this is a trivial example, and unlikely to crop up in anything except a test project, I’ve seen this sort of problem show up numerous times in real apps.
One good way to track this down is to put log point in your deinitialisers for your networking classes. If those log points fire unexpectedly, you know where to start.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
These days my go-to API for asynchronous DNS resolution is DNSServiceGetAddrInfo.
The DNS-SD API is a bit tricky to call from high-level languages. If you’re using Objective-C, check out the DNSSDObjects sample code. If you’re using Swift, see this post. Neither of these call DNSServiceGetAddrInfo, but they show how to use DNS-SD in general.
Oh, and I can’t talk about DNS without my standard warning: If your ultimate goal is to connect to this address, you’re much better off using a connect-by-name API. TN3151 Choosing the right networking API talk about this in some detail.
OTOH, these APIs are fine if you’re not actually connecting, for example, you’re building a DNS debugging tool.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Post not yet marked as solved
I am passing the return value of TISGetInputSourceProperty
after static casting it to CFDataRef to the
CFDataGetBytePtr function.
That is a ‘selector based’ API, that is, the result you get back depends on the selector (propertyKey) you pass in. What key are you using?
As an aside, if you want to trap problems like this early, check the type at runtime using CFGetTypeID:
let tis: TISInputSource = …
let someProperty: CFString = ;
guard let raw = TISGetInputSourceProperty(tis, someProperty) else {
…
}
let data = Unmanaged<CFData>.fromOpaque(raw).takeUnretainedValue()
assert( CFGetTypeID(data) == CFDataGetTypeID() )
…
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Any chance you could push to get the
x-apple.systempreferences URL scheme properly documented?
The best first step here is for you to file a bug against the docs. Please post your bug number, just for the record.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
