Overview

I'm stuck in an impossible situation with DeviceActivityReportExtension on iOS 18. THE ISSUE: Configuration that works on device (iOS 18.2): Info.plist has only NSExtensionPointIdentifier Swift code uses u/main attribute App installs and runs perfectly Extension works correctly App Store validation FAILS: "Missing NSExtensionPrincipalClass" Adding NSExtensionPrincipalClass (as validation requests): Device installation FAILS with Error 3002 Error says: "NSExtensionPrincipalClass key is not allowed for this extension point" Cannot test on device Validation would likely pass ENVIRONMENT: Xcode 16.2 iOS 18.2 Extension point: com.apple.deviceactivityui.report-extension EVIDENCE IT'S WIDESPREAD: Apple Forums (3 days ago): https://developer.apple.com/forums/thread/812380 Stack Overflow (1+ year): https://stackoverflow.com/questions/77866230/ ROOT CAUSE: iOS 18 changed this extension to use u/main pattern (no NSExtensionPrincipalClass needed). App Store validation hasn't been updated and still expects iOS 17 configuration. WHAT I'VE TRIED: ✅ All deployment targets set to iOS 18.3 ✅ Code follows Apple's WWDC 2022 guidance ✅ All entitlements correct ✅ Info.plist validated ✅ Clean builds ✅ Works perfectly on device No configuration satisfies both device runtime AND App Store validation. Has anyone successfully uploaded an app with DeviceActivityReportExtension to TestFlight on iOS 18? Any workarounds? This is blocking TestFlight deployment completely.

I'm stuck in an impossible situation with DeviceActivityReportExtension on iOS 18. THE ISSUE: Configuration that works on device (iOS 18.2): Info.plist has only NSExtensionPointIdentifier Swift code uses u/main attribute App installs and runs perfectly Extension works correctly App Store validation FAILS: "Missing NSExtensionPrincipalClass" Adding NSExtensionPrincipalClass (as validation requests): Device installation FAILS with Error 3002 Error says: "NSExtensionPrincipalClass key is not allowed for this extension point" Cannot test on device Validation would likely pass ENVIRONMENT: Xcode 16.2 iOS 18.2 Extension point: com.apple.deviceactivityui.report-extension EVIDENCE IT'S WIDESPREAD: Apple Forums (3 days ago): https://developer.apple.com/forums/thread/812380 Stack Overflow (1+ year): https://stackoverflow.com/questions/77866230/ ROOT CAUSE: iOS 18 changed this extension to use u/main pattern (no NSExtensionPrincipalClass needed). App Store validation hasn't been updated and still expects iOS 17 configuration. WHAT I'VE TRIED: ✅ All deployment targets set to iOS 18.3 ✅ Code follows Apple's WWDC 2022 guidance ✅ All entitlements correct ✅ Info.plist validated ✅ Clean builds ✅ Works perfectly on device No configuration satisfies both device runtime AND App Store validation. Has anyone successfully uploaded an app with DeviceActivityReportExtension to TestFlight on iOS 18? Any workarounds? This is blocking TestFlight deployment completely.

I use Iphone 17 wifi to test the device and mobile phone communicate,but I found the wifi disconnect innormal in hign frequency. This situation is only appears in iphone 17 series, iphone 14 and 15 is ok, so I think iphone 17 wifi chip or software has bugs. the local network disconnect in hign frequency.

(Xcode 26.2, iPhone 17 Pro) I can't seem to get hardware tag checks to work in an app launched without the special "Hardware Memory Tagging" diagnostics. In other words, I have been unable to reproduce the crash example at 6:40 in Apple's video "Secure your app with Memory Integrity Enforcement". When I write a heap overflow or a UAF, it is picked up perfectly provided I enable the "Hardware Memory Tagging" feature under Scheme Diagnostics. If I instead add the Enhanced Security capability with the memory-tagging related entitlements: I'm seeing distinct memory tags being assigned in pointers returned by malloc (without the capability, this is not the case) Tag mismatches are not being caught or enforced, regardless of soft mode The behaviour is the same whether I launch from Xcode without "Hardware Memory Tagging", or if I launch the app by tapping it on launchpad. In case it was related to debug builds, I also tried creating an ad hoc IPA and it didn't make any difference. I realise there's a wrinkle here that the debugger sets MallocTagAll=1, so possibly it will pick up a wider range of issues. However I would have expected that a straight UAF would be caught. For example, this test code demonstrates that tagging is active but it doesn't crash: #define PTR_TAG(p) ((unsigned)(((uintptr_t)(p) >> 56) & 0xF)) void *p1 = malloc(32); void *p2 = malloc(32); void *p3 = malloc(32); os_log(OS_LOG_DEFAULT, "p1 = %p (tag: %u)\n", p1, PTR_TAG(p1)); os_log(OS_LOG_DEFAULT, "p2 = %p (tag: %u)\n", p2, PTR_TAG(p2)); os_log(OS_LOG_DEFAULT, "p3 = %p (tag: %u)\n", p3, PTR_TAG(p3)); free(p2); void *p2_realloc = malloc(32); os_log(OS_LOG_DEFAULT, "p2 after free+malloc = %p (tag: %u)\n", p2_realloc, PTR_TAG(p2_realloc)); // Is p2_realloc the same address as p2 but different tag? os_log(OS_LOG_DEFAULT, "Same address? %s\n", ((uintptr_t)p2 & 0x00FFFFFFFFFFFFFF) == ((uintptr_t)p2_realloc & 0x00FFFFFFFFFFFFFF) ? "YES" : "NO"); // Now try to use the OLD pointer p2 os_log(OS_LOG_DEFAULT, "Attempting use-after-free via old pointer p2...\n"); volatile char c = *(volatile char *)p2; // Should this crash? os_log(OS_LOG_DEFAULT, "Read succeeded! Value: %d\n", c); Example output: p1 = 0xf00000b71019660 (tag: 15) p2 = 0x200000b711958c0 (tag: 2) p3 = 0x300000b711958e0 (tag: 3) p2 after free+malloc = 0x700000b71019680 (tag: 7) Same address? NO Attempting use-after-free via old pointer p2... Read succeeded! Value: -55 For reference, these are my entitlements. [Dict] [Key] application-identifier [Value] [String] … [Key] com.apple.developer.team-identifier [Value] [String] … [Key] com.apple.security.hardened-process [Value] [Bool] true [Key] com.apple.security.hardened-process.checked-allocations [Value] [Bool] true [Key] com.apple.security.hardened-process.checked-allocations.enable-pure-data [Value] [Bool] true [Key] com.apple.security.hardened-process.dyld-ro [Value] [Bool] true [Key] com.apple.security.hardened-process.enhanced-security-version [Value] [Int] 1 [Key] com.apple.security.hardened-process.hardened-heap [Value] [Bool] true [Key] com.apple.security.hardened-process.platform-restrictions [Value] [Int] 2 [Key] get-task-allow [Value] [Bool] true What do I need to do to make Memory Integrity Enforcement do something outside the debugger?

Hello everyone, We are in the process of migrating a high-performance storage KEXT to DriverKit. During our initial validation phase, we noticed a performance gap between the DEXT and the KEXT, which prompted us to try and optimize our I/O handling process. Background and Motivation: Our test hardware is a RAID 0 array of two HDDs. According to AJA System Test, our legacy KEXT achieves a write speed of about 645 MB/s on this hardware, whereas the new DEXT reaches about 565 MB/s. We suspect the primary reason for this performance gap might be that the DEXT, by default, uses a serial work-loop to submit I/O commands, which fails to fully leverage the parallelism of the hardware array. Therefore, to eliminate this bottleneck and improve performance, we configured a dedicated parallel dispatch queue (MyParallelIOQueue) for the UserProcessParallelTask method. However, during our implementation attempt, we encountered a critical issue that caused a system-wide crash. The Operation Causing the Panic: We configured MyParallelIOQueue using the following combination of methods: In the .iig file: We appended the QUEUENAME(MyParallelIOQueue) macro after the override keyword of the UserProcessParallelTask method declaration. In the .cpp file: We manually created a queue with the same name by calling the IODispatchQueue::Create() function within our UserInitializeController method. The Result: This results in a macOS kernel panic during the DEXT loading process, forcing the user to perform a hard reboot. After the reboot, checking with the systemextensionsctl list command reveals the DEXT's status as [activated waiting for user], which indicates that it encountered an unrecoverable, fatal error during its initialization. Key Code Snippets to Reproduce the Panic: In .iig file - this was our exact implementation: class DRV_MAIN_CLASS_NAME: public IOUserSCSIParallelInterfaceController { public: virtual kern_return_t UserProcessParallelTask(...) override QUEUENAME(MyParallelIOQueue); }; In .h file: struct DRV_MAIN_CLASS_NAME_IVars { // ... IODispatchQueue* MyParallelIOQueue; }; In UserInitializeController implementation: kern_return_t IMPL(DRV_MAIN_CLASS_NAME, UserInitializeController) { // ... // We also included code to manually create the queue. kern_return_t ret = IODispatchQueue::Create("MyParallelIOQueue", kIODispatchQueueReentrant, 0, &ivars->MyParallelIOQueue); if (ret != kIOReturnSuccess) { // ... error handling ... } // ... return kIOReturnSuccess; } Our Question: What is the officially recommended and most stable method for configuring UserProcessParallelTask_Impl() to use a parallel I/O queue? Clarifying this is crucial for all developers pursuing high-performance storage solutions with DriverKit. Any explanation or guidance would be greatly appreciated. Best Regards, Charles

This is from an Xcode generated file. var values: [String] = [] let exp = Expectation() let c = pub.filter { $0 != nil }.map { $0! }.sink( The second line gives an error: "'Expectation' cannot be constructed because it has no accessible initializers". My best guess that Expectation objects come from some other Apple Swift Testing function, but I don't know where.

All system colors are displayed incorrectly on the popover view. Those are the same views present as a popover in light and dark mode. And those are the same views present as modal. And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps. The following screenshot is already in dark mode. All those problem are occured on iOS 26 beta 3.

HealthKit background delivery only triggers when charging. I have set step monitoring to hourly frequency. Despite step changes, callbacks fail to arrive after 3-4 hours on battery, but trigger immediately upon connecting power. Observed for 2 days: background updates are only received when charging. The device is not in Low Power Mode, and Background App Refresh is enabled for the app in Settings.

It’s the small things that make a difference, and the three dots at the top of the screen in Safari and Chrome are such examples. I’ve already accidentally deleted several tab groups by accident and try to relearn browsing is harder than it should be.

Dear Apple Developer Program / App Store Connect Support Team, I’m contacting you to request guidance regarding a Pending Termination Notice on my Apple Developer account. This message is not an appeal, I’m looking for clarification on the appropriate next steps and what options may be available. Could you please advise on the following: If I address any compliance issues identified in the notice and provide supporting evidence upon request, is it possible for Apple to reconsider the pending termination decision or apply a less severe outcome? If the account termination proceeds, will I be eligible to re-enroll in the Apple Developer Program after a period of time? If so, what requirements or review criteria would apply to a future enrollment? If I submit an appeal, what is the recommended way to include supporting evidence (e.g., screenshots/photos or a PDF) to demonstrate that my developer identity information is true, verifiable, and up to date? Thank you for your time and guidance. I want to continue building valuable products to the world, this is what I love doing as an apple fans.

2026（原创）Guideline 4.3(a) - Design - Spam苹果上架iOS审核被拒AppStore卡审解决办法思路，适用于新项目、旧项目多种类型框架多种开发语言代码提交上架AppStore遇到的4.3design 4.3design通俗解释就是苹果上架AppStore被拒后的第四条第三款，设计代码垃圾，不予收录， 原因有很多，但是主要的个人感觉还是提交到app的代码与AppStore库里的代码过于重复， • 可能使用的开源的项目、 • 可能使用第三方库、 • 可能ui设计师复制了别人app的ui、 • 可能新写的代码，但是代码在自己团队里多个项目里重复提交 • 可能电脑的设备信息上传ipa到时候被记录关联 • 可能你的ip上传了多个项目被记录关联 • 可能还有其他因素， 那怎么解决呢？ 首先要知道2个东西， • 一个是苹果审核流程会经过机器审核和人工审核环节，要确认下是机器审核还是人工审核被拒的，尽可能走到人工审核环节。 • 另一个4.3被拒条款也有细微的差异，会比常规模板多出来一句话，详细说明了4.3的问题，下面每个4.3差异化类型一一介绍，要针对差异去整改 先说4.3 design被拒的几种类型 常规4.3design被拒模板 比如下面的是常规的苹果被拒的4.3design设计垃圾的原文，基本说了导致的就是上面的几个因素，主要也是代码资源ui元数据等相似问题。 Guideline 4.3(a) - Design - Spam We noticed your app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences. Submitting similar or repackaged apps is a form of spam that creates clutter and makes it difficult for users to discover new apps. Next Steps Since we do not accept spam apps on the App Store, we encourage you to review your app concept and submit a unique app with distinct content and functionality. Resources Some factors that contribute to a spam rejection may include: Submitting an app with the same source code or assets as other apps already submitted to the App Store Creating and submitting multiple similar apps using a repackaged app template Purchasing an app template with problematic code from a third party Submitting several similar apps across multiple accounts Learn more about our requirements to prevent spam in App Review Guideline 4.3(a). 翻译过来 准则 4.3(a) - 设计 - 垃圾应用 我们注意到您的应用与 App Store 中其他开发者提交的应用在二进制文件、元数据和/或概念上非常相似，仅有细微差别。 提交类似或重新打包的应用属于垃圾应用，会造成应用列表混乱，使用户难以发现新应用。 后续步骤 由于 App Store 不接受垃圾应用，我们建议您重新审视您的应用概念，并提交一个内容和功能独特的应用。 资源 导致应用被拒的因素可能包括： 提交的应用与已提交到 App Store 的其他应用使用相同的源代码或资源 使用重新打包的应用模板创建并提交多个类似的应用 从第三方购买包含问题代码的应用模板 使用多个账户提交多个类似的应用 了解更多关于我们防止垃圾应用的要求，请参阅应用审核准则 4.3(a)。 然后其实4.3design条款还有其他一些， 比如Guideline 4.3(b) - Design - Spam，这类的一般出现在社交和星座罗盘八字类的app，模板基本一样，但是多了一句话，大致内容是appstore上这类的数量太多 Guideline 4.3(b) - Design - Spam Your app primarily includes dating features that duplicate the content and functionality of similar apps in a saturated category. These app features may be useful, informative or entertaining, and your app may include features or characteristics that distinguish it. However, there are already enough of these apps on the App Store. Next Steps We encourage you to reconsider your app concept and submit a new app that provides a unique experience not already found on the App Store. Resources 翻译过来 指南4.3(b) - 设计 - 垃圾邮件 你的应用主要包含约会功能，这些功能与同类应用在饱和领域的内容和功能存在重复。 这些应用功能可能具有实用性、信息性或娱乐性，且您的应用可能包含使其独具特色的功能或特性。然而，App Store上此类应用已琳琅满目。 后续步骤 我们建议您重新考虑您的应用概念，并提交一款能在App Store上独树一帜、提供全新体验的应用。 资源 还有一些Guideline 4.3(a) - Design - Spam,它的模板与常规的一样，但是会多出来一句话，一般以Specifically单词开头，后面的语句不一样， 这类的还好一些，相对来说会指出你的app的问题所在，比如下面的这个被拒里“Specifically, this app appears to be identical to apps already submitted to the App Store from other developers. ”它指出app与其他app的完全一样，不是类似，而是指出了“完全一样”的问题， 那么你就排查下你的代码是否完整一模一样提交过了appstore，app名字和简介是否复制了appstore已经上架的过的app的？ Guideline 4.3(a) - Design - Spam This app duplicates the content and functionality of other apps on the App Store, which is considered a form of spam. Specifically, this app appears to be identical to apps already submitted to the App Store from other developers. Apps that duplicate content or functionality create clutter, diminish the overall experience for the end user, and reduce the ability of developers to market their apps. Next Steps 其他同类的4.3还有一些是icon图标logo一样的、销售地区是一样的，会明确给指出来，这类的只要不是英文太low的都能看明白，然后解决掉指出来的问题即可。 We noticed that your app icon is identical to the icons of other apps already submitted to the App Store. Apps that use the same icon make it difficult for users to find apps and are considered a form of spam. 再来说审核状态，是机器审核还是人工审核， 为什么要说下这2个状态呢？因为一道完整的APP上架基本都是要经过机器预审核+机器模拟审核+人工审核，所以只要机器审核卡住了，那99%大概率这个流程你就走不完，更不用说完整的上架了。 机器审核分为预审核和模拟审核， 预审核就是把ipa上传到AppStoreConnect后，机器扫描ipa里代码的静态库sdk代码是否包含恶意代码、私有api等违规的问题代码，如果有会直接发邮件给开发者邮箱里，告知具体的整改问题，并且这种预审不通过的ipa构建版本是不显示在AppStoreConnect里用来提交审核的构建版本列表里的，并且在TestFlight的构建列表里显示状态是“失败”，这个预审核状态不多说了，一般本机上传完ipa的20分钟内，具体看ipa大小，会收到邮件预审核成功还是失败，如果失败，根据邮件修改后新上传就行。 机器模拟审核，很多app都是卡在这个环节上了，怎么判断是机器模拟审核还是人工审核，这个网上判断方法不少，说法不一，个人总结，没有固定的判定标准，毕竟都是猜和经验判断，个人多年上架总结，要综合判断，主要从下面的几个点判断 • 看下历史记录审核时间，从正在审核到被拒绝状态时间的时长，时长短的大概率是机器模拟审核 • 是看服务器接口是否有app访问，从时间点、app版本、请求ip地区判断请求，如果是大陆运营的app，那么美国区访问接口的话大概率是人工审核 • apple回复你的模板开头是否有以下内容，个人经验判断带有这些字样语句语法开头的回复人工审核的概率比较大 Hello, The issues we previously identified still need your attention. If you have any questions, we are here to help. Reply to this message in App Store Connect and let us know. 既然是综合判断，那么个人经验判断认为以下的情况，仅供参考 大概率机器审核被拒：审核时间短+审核期间无接口访问+无hello开头语句 大概率人工审核被拒：审核时间长+审核时间有接口访问+有hello开头语句 大概率机器审核被拒：审核时间短+审核期间有接口访问+无hello开头语句 大概率人工审核被拒：审核时间长+审核期间无接口访问+有hello开头语句 ok，那么常规的Guideline 4.3(a) - Design - Spam到底怎么解决呢？ 无论是机器审核还是人工审核，既然是重复导致的原因，那么我们对提交给苹果的资源梳理下，把所有重复去掉不就行了， • 1.提交的无非是一个ipa • 2.appstoreconnect里配置的元数据，预览图、简介、等 • 3.提交的电脑设备和网络 解决思路：把上面的信息都更新一遍 1.ipa到代码，包括 • 设计logo • ui（主要是预览图的几张首页图），其他的可以不修改， • 执行代码编译的代码oc、swift、如果是第三方那么就是js、vue、dart等 • 资源文件xml、json和还有图片ui切片， 都换成新的，那简单的就是个混淆工具处理下代码项目，网上很多，作者这里也有一个收费的，需要的可以下载 ipa代码项目混淆工具https://iosuploader.xinxishehui.com/ 2.AppStoreconnect里配置的元数据，包括预览图、简介、名字都换一下新的 3.提交的电脑设备和网络换新的，成本太高的话，可以使用作者的收费软件，通过AppStore上传工具，不携带任何电脑序列号mac等信息，只通过ip传递ipa到AppStoreconnect中心，地址 iOSUploader - IPA上传工具https://iosuploader.xinxishehui.com/ 4.更换包名BundleIdentifier，很重要的一点，AppStoreConnect里新建一个报名BundleIdentifier，也就是新建一个app，去掉已经与4.3相互关联的那个BundleIdentifier包名，这个关联看似不重要，实则也是元数据的一部分，注意包名不要创建太多，一个账号创建多了后会降低权重，轻则延迟审核，重则被封号 5.更换开发者账号，每个开发者账号也跟常规电商账号一样，都有自己的权重，权重高的账号，苹果那边也会给予较高的通过率，作者以前见过最快的3分钟之内机器审核直接通过的案例，但是这个换号一个是成本高，另一个不建议换太多，换太多号跨账号提交代码的话可能会引发app卡审，就是提交后一直处于“正在等待审核”状态，不审核也不反馈被拒问题，一等就是半个月-1个月，最后很大概率可能是封号，所以这个换开发者账号的方案慎重，是个双刃剑 综上所述的步骤你都做到了位，很多app的4.3design被拒状态都可以通过上架到AppStore。 这里值得注意的是，如果昨做完了步骤，还是机器被拒的话，还可以再优化每个环节，主要是源代码ipa处理，一定要争取到达人工审核环节，到了人工审核还是4.3被拒的话，那再考虑下面的方案。 如果都做到位了，还不行？那么既然是人工审核不行，俺么可以考虑申请高级的苹果审核委员会进行申诉，魔法对魔法，等级压制，对本次人工审核进行申诉。 注意既然是高级审核组了，就不是常规的审核流程了，那么它可能会给你解决4.3design被拒，但也可能会对你的app所在的账号层、设备、ip、手机号等一类综合的因素进行审核，如果本身开发环境不怎么好的话，可能会出现意外情况2.3.1隐藏或者其他严重的封号情况，所以这个高级申诉入口慎用 苹果高级审核委员会申诉快捷入口https://developer.apple.com/contact/request/app-review/appeal/ 额，如果所有方案都不行，也可以考虑付费找作者协助上架到AppStore，作者专业上架苹果15年，从iphone3GS手机时代就开始提交上架App，一直提交到现在，作者的经验值一直都在。当然作者也是吃饭的，有不想继续浪费时间在这个问题上的，可以付费找作者直接省心省力协助上架到AppStore，直接私信或者评论区留言 祝愿各位读者都早日渡劫4.3design成功到AppStore， 写文章不易顺便给个赞吧，谢谢链接 协助上架可以咨询微信:AppShangJia666

We’re building a hybrid iOS app using Angular (web) rendered inside a WKWebView, hosted by a native Swift app. Recently, we encountered a crash related to UIKeyboardStateManager in UIKit when switching between text inputs continuously within an Angular screen. Scenario The screen contains several text input fields. A “Next” button focuses the next input field programmatically. After about 61 continuous input field changes, the app crashes. It seems like this may be related to UIKit’s internal keyboard management while switching focus rapidly inside a WebView. crash stack: Crashed: com.apple.main-thread 0 WebKit 0xfbdad0 <redacted> + 236 1 UIKitCore 0x10b0548 -[UITextInteractionSelectableInputDelegate _moveToStartOfLine:withHistory:] + 96 2 UIKitCore 0xd0fb38 -[UIKBInputDelegateManager _moveToStartOfLine:withHistory:] + 188 3 UIKitCore 0xa16174 __158-[_UIKeyboardStateManager handleMoveCursorToStartOfLine:beforePublicKeyCommands:testOnly:savedHistory:force:canHandleSelectableInputDelegateCommand:keyEvent:]_block_invoke + 52 4 UIKitCore 0xa36ae4 -[_UIKeyboardStateManager performBlockWithTextInputChangesIgnoredForNonMacOS:] + 48 5 UIKitCore 0xa160f0 -[_UIKeyboardStateManager handleMoveCursorToStartOfLine:beforePublicKeyCommands:testOnly:savedHistory:force:canHandleSelectableInputDelegateCommand:keyEvent:] + 440 6 UIKitCore 0xa07010 -[_UIKeyboardStateManager handleKeyCommand:repeatOkay:options:] + 5760 7 UIKitCore 0xa2fb64 -[_UIKeyboardStateManager _handleKeyCommandCommon:options:] + 76 8 UIKitCore 0xa2fb08 -[_UIKeyboardStateManager _handleKeyCommand:] + 20 9 UIKitCore 0xa30684 -[_UIKeyboardStateManager handleKeyEvent:executionContext:] + 2464 10 UIKitCore 0xa2f95c __42-[_UIKeyboardStateManager handleKeyEvent:]_block_invoke + 40 11 UIKitCore 0x4b9460 -[UIKeyboardTaskEntry execute:] + 208 12 UIKitCore 0x4b92f4 -[UIKeyboardTaskQueue continueExecutionOnMainThread] + 356 13 UIKitCore 0x4b8be0 -[UIKeyboardTaskQueue addTask:breadcrumb:] + 120 14 UIKitCore 0x4a9ed0 -[_UIKeyboardStateManager _setupDelegate:delegateSame:hardwareKeyboardStateChanged:endingInputSessionIdentifier:force:delayEndInputSession:] + 3388 15 UIKitCore 0xfa290 -[_UIKeyboardStateManager setDelegate:force:delayEndInputSession:] + 628 16 UIKitCore 0xf617c -[UIKeyboardSceneDelegate _reloadInputViewsForKeyWindowSceneResponder:force:fromBecomeFirstResponder:] + 1140 17 UIKitCore 0xf5c88 -[UIKeyboardSceneDelegate _reloadInputViewsForResponder:force:fromBecomeFirstResponder:] + 88 18 UIKitCore 0x4fe4ac -[UIResponder(UIResponderInputViewAdditions) reloadInputViews] + 84 19 WebKit 0xfbe708 <redacted> + 100 20 WebKit 0xfbf594 <redacted> + 340 21 WebKit 0x8a33d8 <redacted> + 32 22 WebKit 0x8cee04 <redacted> + 144 23 WebKit 0x1c83f0 <redacted> + 22692 24 WebKit 0x73f40 <redacted> + 264 25 WebKit 0x162c7c <redacted> + 40 26 WebKit 0x1623b4 <redacted> + 1608 27 WebKit 0x73298 <redacted> + 268 28 WebKit 0x72e48 <redacted> + 660 29 JavaScriptCore 0xdb00 WTF::RunLoop::performWork() + 524 30 JavaScriptCore 0xd744 WTF::RunLoop::performWork(void*) + 36 31 CoreFoundation 0xf92c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 32 CoreFoundation 0xf744 __CFRunLoopDoSource0 + 172 33 CoreFoundation 0xf5a0 __CFRunLoopDoSources0 + 232 34 CoreFoundation 0xff20 __CFRunLoopRun + 840 35 CoreFoundation 0x11adc CFRunLoopRunSpecific + 572 36 GraphicsServices 0x1454 GSEventRunModal + 168 37 UIKitCore 0x135274 -[UIApplication _run] + 816 38 UIKitCore 0x100a28 UIApplicationMain + 336 39 APP1 0xa2ed0 main + 21 (AppDelegate.swift:21) 40 ??? 0x1aa889f08 (シンボルが不足しています) From reviewing the crash log, it appears that the crash occurs inside UIKeyboardStateManager while handling keyboard or cursor updates. Questions Has anyone seen this specific crash pattern involving UIKeyboardStateManager? Are there known UIKit or WebKit bugs related to UIKeyboardStateManager when continuously changing focus between text fields (especially in WKWebView)? Any insights or workarounds would be greatly appreciated. Thanks!

Do you know if there is a work around to animate the reorder of a table without generating ghost rows? here is the code: var id = UUID() var name: String var value: Int } struct ContentView: View { @State var selectedNumber: UUID? @State var sortedBy: [KeyPathComparator<MyNumbers>] = [KeyPathComparator(\.name, order: .reverse)] @State var numbers: [MyNumbers] = { var numbersArray = [MyNumbers]() for i in 0..<100 { numbersArray.append(MyNumbers(name: "\(i)", value: i)) } return numbersArray }() var body: some View { Table(numbers, selection: $selectedNumber, sortOrder: $sortedBy) { TableColumn("names", value: \.name){ number in Text(number.name) } TableColumn("names", value: \.name){ number in Text(number.name) } }.onChange(of: sortedBy) { oldValue, newValue in withAnimation { numbers.sort(using: newValue) } } } } it generates ghost rows when the top row is selected and reorders twice, as you can see in the screenshot, the first six rows has two labels overlapped.

Around October 17, our app was removed from the App Store, and we were later informed that our developer account would be terminated within 30 days. This was an unexpected and shocking notice for us. After carefully reviewing Apple’s Developer Guidelines, we conducted a thorough internal investigation and confirmed that we did, in fact, violate certain policies. However, we are unsure whether the Apple Review Team could give us an opportunity to make corrections—otherwise, our new apps will not be able to launch on the App Store in the future. The stated reason for our account termination was: “You provided fraudulent and/or false account information, documentation, or otherwise falsely represented yourself or your submitted app to Apple either during the account enrollment process or after the account was created.” After reviewing this issue, we identified two foolish and critical mistakes on our part: We registered our developer account using our Mainland China company, but used a Hong Kong company’s bank account for payments. (Both companies are under the same management, and we have submitted supporting documentation during our appeal.) Our official website, Privacy Policy, and Terms of Service also displayed the name of our Hong Kong company instead of the Mainland China entity used for registration. Despite these mistakes, we have continued to support our users through email and our Discord community, resolving most issues within 24 hours. We have never deceived our users or the Apple Review Team in any way. For us as developers, providing an excellent user experience has always been our top priority, and we have always aimed to follow Apple’s review and compliance standards closely. We sincerely hope that, given our situation, the Apple Review Team could grant us an opportunity to correct these issues. We will promptly register a new Hong Kong Apple Developer Account, and once our app is reinstated, we will migrate all relevant information to that new account to ensure full compliance moving forward.

Environment MacOC 26 Xcode Version 26.0 beta 7 (17A5305k) simulator: iPhone 16 pro iOS: iOS 26 Problem NLContextualEmbedding.load() fails with the following error In simulator Failed to load embedding from MIL representation: filesystem error: in create_directories: Permission denied ["/var/db/com.apple.naturallanguaged/com.apple.e5rt.e5bundlecache"] filesystem error: in create_directories: Permission denied ["/var/db/com.apple.naturallanguaged/com.apple.e5rt.e5bundlecache"] Failed to load embedding model 'mul_Latn' - '5C45D94E-BAB4-4927-94B6-8B5745C46289' assetRequestFailed(Optional(Error Domain=NLNaturalLanguageErrorDomain Code=7 "Embedding model requires compilation" UserInfo={NSLocalizedDescription=Embedding model requires compilation})) in #Playground I'm new to this embedding model. Not sure if it's caused by my code or environment. Code snippet import Foundation import NaturalLanguage import Playgrounds #Playground { // Prefer initializing by script for broader coverage; returns NLContextualEmbedding? guard let embeddingModel = NLContextualEmbedding(script: .latin) else { print("Failed to create NLContextualEmbedding") return } print(embeddingModel.hasAvailableAssets) do { try embeddingModel.load() print("Model loaded") } catch { print("Failed to load model: \(error)") } }

I added a Content Filter to my app, and when running it in Xcode (Debug/Release), I get the expected permission prompt: "Would like to filter network content (Allow / Don't Allow)". However, when I install the app via TestFlight, this prompt doesn’t appear at all, and the feature doesn’t work. Is there a special configuration required for TestFlight? Has anyone encountered this issue before? Thanks!

It has been approximately three weeks since we submitted our app for review via App Store Connect, but it remains "In Review" and the review process has not been completed. For this reason, we also requested an expedited app review to the App Review Team last week. Will the review proceed if we simply wait? Is there any way to check the detailed status of this app review?

We are observing some unexpected behavior in our app when using ASK. Our app is able to successfully discover and set up an accessory via ASK. After the setup completes, the connection to the accessory is managed through CBCentralManager and works as expected. However, when we attempt to discover another accessory afterward, the picker is shown and indicates that accessory discovery is in progress. After approximately 10 seconds, the CBCentralManager delegate reports the Bluetooth state as poweredOff. Once this happens, the state never transitions back to poweredOn. At this point, the only way to reconnect to the device or continue discovery is to relaunch the app. We are wondering if anyone else has encountered similar behavior, or if this is a known or documented limitation/behavior when using ASK in combination with CBCentralManager.

Hi all, Wondering how I would go about creating a plugin/class to support a new (physical/hardware) device with the game controller framework? Between GCVirtualController on iOS and the "KeyboardAndMouseSupport.bundle" I see inside GameController.framework on my Mac, it looks like the framework must be designed to support this but I can't find any documentation. Thanks!

Xcode Cloud builds are hanging forever at the final step, Prepare Build for App Store Connect. This is a common issue that requires some fix in Cupertino. Reporting this in the afternoon of Jan 13, Pacific Time.