“translate scheme”

[quote='880412022, hasii2021, /thread/818406?answerId=880412022#880412022, /profile/hasii2021'] I put them [in FB22267132] but not sure if this is correct [/quote] That’s cool. When I open the system log snapshot you included (system_logs.logarchive) I see this: type: default time: 2026-03-17 21:32:51.951555 -0500 process: spctl subsystem: com.apple.securityd category: security_exception message: UNIX error exception: 2 type: default time: 2026-03-17 21:32:51.951587 -0500 process: spctl subsystem: com.apple.securityd category: security_exception message: MacOS error: -67068 type: default time: 2026-03-17 21:32:51.951603 -0500 process: spctl subsystem: com.apple.securityd category: security_exception message: MacOS error: -67071 type: default time: 2026-03-17 21:32:51.951615 -0500 process: spctl subsystem: com.apple.securityd category: security_exception message: MacOS error: -67071 This seems like an understandable error cascade: The first error, 2, is ENOENT, which is an error commonly returned by the BSD su

Thanks for this interesting post! I'm not an expert on that field nor that API. Hope one of the engineers on that team can jump into this thread for better info. These specific FigXPCUtilities and FigCaptureSourceRemote logs are almost certainly benign internal framework noise rather than a regression or a flaw in your capture pipeline. Looking up the err=-17281 is a CoreMedia error code that, without knowing here, typically points to a minor XPC synchronization hiccup, a port invalidation, or an asynchronous state mismatch during the setup or teardown of the capture session? I believe this logs are for information only and should be removed. Code paths that silently recovered in older iOS versions often have their log levels elevated in newer releases (or beta releases), resulting in console spam. If your AVCaptureVideoDataOutputSampleBufferDelegate is successfully receiving CMSampleBuffer frames and your preview layer is rendering smoothly. You can safely ignore these logs. If you want to temporarily hide t

Thanks for the post, very interesting you went to an approached that will create a duplicate app instead of localization. I would actually focus on the reason you can’t localize in another language as that API has been proven to be great. I think we should focus on that. Apple’s automated systems and human reviewers are trained to flag apps that look and function similarly to existing apps. I believe the primary goal is to keep the App Store clean the preference is that a single app supports multiple languages and features, rather than having separate apps for different regions or languages. I think on the final result having 2 apps on the same region with different languages. If both apps are available in the same region that could be a really bad experience for the users. Let’s focus on the reason you can’t localize. Localization isn't just translating words; it's adapting the software. Developers extract all hard-coded text in the app and put them into a file called. The app then pulls the correct

I found a fix. You can right click an entry in the catalog and select Mark as Reviewed and it will then create an en.lproj folder and file. In source code view you can bulk edit state : new to state : translated for all English values. On build it will also then remove extractionState : extracted_with_value from each entry and all strings will be in the en.lprog strings file.

I am also having this issue. All strings are LocalizedStringResource and the catalog correctly has all the English translations. However an en.lproj folder is not create when archived.

It is caused by code coverage being injected by test plan that is autogenerated in scheme. Disabling code coverage for driver target and deleting test scheme will fix the problem. However, you might want to have testing with your project. But it looks like any test plan inside same project will inject profile-instr-generate. Not sure how to have testing for main app, and no code coverage flag injected for driver. Seems like bug in Xcode.

Things that give me hope: The response from Apple  above says the word 'both', which is different from other responses on other threads, so it's a human being answering, not a bot Received new developer agreement email from Apple  - something something China something something, so they're alive and well, they must know that we're having this issue The daily barrage of developers raising concerns on this forum about the delays The delay also seems to signify that it's humans reviewing apps, which I much prefer over any 100% automated review system I know a lot of us are waiting, me included, for the fruits of our labor and creativity to be unleashed into the world, and to hopefully earn some money from it. Hold on tight guys, I'm sure it will happen. I know some of us are actually losing money because of this delay. But since we have no other leverage, stay patient. I tell myself a month is nothing in the large scheme of things, right? Right?

Same error, for ~2hrs now. But curl returns successful, confusingly. curl -v https://ppq.apple.com Host ppq.apple.com:443 was resolved. IPv6: (none) IPv4: 17.33.192.136, 17.33.193.105, 17.33.194.109 Trying 17.33.192.136:443... Connected to ppq.apple.com (17.33.192.136) port 443 ALPN: curl offers h2,http/1.1 (304) (OUT), TLS handshake, Client hello (1): CAfile: /Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/certifi/cacert.pem CApath: none (304) (IN), TLS handshake, Server hello (2): (304) (IN), TLS handshake, Unknown (8): (304) (IN), TLS handshake, Certificate (11): (304) (IN), TLS handshake, CERT verify (15): (304) (IN), TLS handshake, Finished (20): (304) (OUT), TLS handshake, Finished (20): SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF ALPN: server accepted h2 Server certificate: subject: CN=ppq.apple.com; O=Apple Inc.; ST=California; C=US start date: Jan 21 17:47:41 2026 GMT expire date: Feb 17 18:28:16 2027 GMT subjectAltName: host ppq.apple.com m

Hi, You may have already tried this given the 10+ submissions, but my first thought is that your app may not function correctly in an IPv6-only environment. App Review Guideline 2.5.5 states, Apps must be fully functional on IPv6-only networks. With that in mind, it may be worth checking the following: Hardcoded IPv4 Addresses: If you are using raw IPv4 addresses (like 192.168.x.x) in your code instead of hostnames (domains), NAT64/DNS64 cannot translate them, causing the connection to fail in an IPv6-only environment. Low-Level Networking APIs: If your app uses low-level BSD socket APIs directly instead of high-level networking APIs (like URLSession), it may fail to handle NAT64 correctly unless properly implemented for IPv6. If you want to test your app in an IPv6-only network, you can simulate this environment using your Mac's Internet Sharing feature with NAT64/DNS64 enabled as a hotspot. The section Test for IPv6 DNS64/NAT64 Compatibility Regularly in Apple's documentation Supporting IPv6 DNS64/