DTiPhoneSimulatorErrorDomain Code 2

[quote='877433022, mlgiPhone7plus, /thread/812911?answerId=877433022#877433022, /profile/mlgiPhone7plus'] Could it be okay to leave a note in the Other comments section of the form for the judges to run apps on a live iPhone or iPad? [/quote] Leaving a note is OK, obviously, but I can’t promise that it’ll have any effect. There are two ways to submit your app. One of them guarantees that your submission will be run on device, but it has a significant limitation. I just posted a summary of the current state of affairs here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Right. The submission form has two options: Swift Playground 4.6 or later Xcode 26 or later (with a note saying “Xcode app playgrounds are run in Simulator.”) In the first case, your submission must necessarily be run on an iPad. In the second, your submission will be run on the simulator, not a real device. There are some caveats here: In the first case, the Swift Playground app doesn’t yet include support for the iOS 26 SDK )-: See this thread. In the second case, the form doesn’t currently say whether it’ll be an iPhone on iPad simulator. See this thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thank you so much for the elaborate and helpful reply. I will try to address each point, to try and see how to close in on my problem. I will also attach a sample crash-report. My rule engine is very fast, based on NSPredicates over ObjC custom classes (No core-data etc.). Rule evaluation is completely internal to my daemon, no API calls and no external calls. There IS , however a stage prior to rule evaluation, where I Parse ES messages into my custom ObjC class, and in that stage there are few API calls one of which has given me grief in the past. I need to decide whether a file-system object (from the ES message) is a Document, in my own semantics. A document is any normal file, or -- package directories. If the file-system object exists and is a directory, and it has a file-name extension, I use something like: _isDocument = [[NSWorkspace sharedWorkspace] isFilePackageAtPath:_filePath ]; If it is non-existing (to be created etc.) Then I use this heuristics and API: { // non-existing directory object about

Thank you for your reply. In our case, after the purchase on Device A, the transaction is either verified or not verified, but in both cases finish() is not called. Then the user switches to Device B with the same sandbox Apple ID. Will Device B receive this unfinished transaction via Transaction.updates or any other StoreKit 2 API?

Thank you! For clarification though, I already have an apple ID, which is being used on the computer I'm coding on and I've had it for years. If I go ahead and sign up for a personal developer account, am I able to switch that to my LLC when I do get my DUNS number? That is what I was asking :)

Until 26.4 is generally available, I have found an ugly, but usable, workaround: First perform method swizzling to replace addSubiew:, then in the replacement implementation do nothing when a view is being added to it self This will avoid the crash, but results in a graphic glitch where the selection overlay is opaque over some tabs. Very ugly. To solve this problem: Implement the tab-bar-controller delegate method to detect when customization has ended. When it has ended, set the tab-bar-controller's view-controllers to just the first view-controller, without animation. Then immediately restore the original set of view-controllers, again without animation. This will force the tab-bar to refresh and resolve the graphic glitch from (1) Finally, set the more-view-controller as the selected-view-controller again, since the re-setting of view-controllers in (2) will reset the selected tab. With the above, I do not experience crashes, and there is about 1/2 a second of visual glitching, but thing

Es tut mir leid zu hören, dass Sie Probleme mit der App Store-Leistung auf Ihrer Beta 2 iOS 26.4-Version haben. Hier sind ein paar Schritte, die Sie ausprobieren könnten, um die Situation zu verbessern: Neustart des Geräts: Manchmal kann ein einfacher Neustart helfen, kleinere Softwareprobleme zu beheben. Prüfen auf Updates: Stellen Sie sicher, dass Sie die neuesten Beta-Updates installiert haben. Manchmal werden in nachfolgenden Beta-Versionen Leistungsverbesserungen vorgenommen. Schließen anderer Apps: Stellen Sie sicher, dass nicht zu viele Apps im Hintergrund laufen, da diese die Leistung beeinträchtigen können. Freier Speicherplatz: Prüfen Sie, ob auf Ihrem Gerät noch ausreichend Speicherplatz vorhanden ist. Ein Mangel an Speicherplatz kann die Leistung beeinträchtigen. Temporäre Dateien löschen: Gehen Sie zu Einstellungen > Allgemein > iPhone-Speicher und löschen Sie temporäre Dateien oder Apps, die Sie nicht mehr benützen. Netzwerkverbindung prüfen: Stellen Sie sicher, dass Sie eine stab

The test using a fake job did not cause a crash, only a hang of the ProofProcessor - FAKE1 NSOperation. I'll grab a sysdiagnose the next time this happens, which could be tomorrow. There's currently one user's job that is repeatedly causing an exception to be thrown while sending AppleEvents via ScriptingBridge. It's probably related, but is not causing the same 2 jobs sending AEs and causing the crash situation.

First up, on the bug side, what would be most useful now would be to capture a sysdiagnose after the crash, then upload that log to the bug. A few notes on that: The log doesn't need to be collected all that soon after the bug. I try to collect within a few minutes of the crash, but there really isn't any difference triggering within the next 15+ minutes. Eventually, we start purging log data (losing data), but I've gotten useful data out of logs that were taken hours after the event. It IS important that you not reboot the machine first. Lots of data is purged during that process, to the point where I've basically found those logs useless. PLEASE include information about WHEN the problem occurred. Even better, upload the crash log from the same crash you want to use to look at in the sysdiagnose. The log volume is so high that trying to figure out what happened without a time reference can be extremely slow and time-consuming. Similarly, the crash log should be included in the sysdiagnose, but there are cas

I have found two possible solutions : either (1) use @preconcurrency import Translation instead of just import Translation, and it works magically ; or (2) mark the translationTask closure as @Sendable, and detach to MainActor when needed : .translationTask(configuration) { @Sendable session in do { let responseText = try await session.translate(sourceText).targetText await MainActor.run { // ... propagate back to UI } } catch {} } I'm not sure which is the best solution: #1 is shorter and cleaner but I don't know how it handles concurrency behind the scenes, #2 is more tedious but the isolation path is more clear.