Overview

Post

Replies

Boosts

Views

Activity

Keyboard Toolbar Padding iOS26
When I create a SwiftUI toolbar item with placement of .keyboard on iOS 26, the item appears directly on top of and in contact with the keyboard. This does not look good visually nor does it match the behavior seen in Apple's apps, such as Reminders. Adding padding to the contents of the toolbar item only expands the size of the item but does not separate the capsule background of the item from the keyboard. How can I add vertical padding or spacing to separate the toolbar item capsule from the keyboard?
Topic: UI Frameworks SubTopic: SwiftUI
8
7
603
15h
Developer Program enrollment still pending after payment
Hi everyone, I subscribed to the Apple Developer Program on Tuesday evening, Dec 7th, 2025. The payment has already been charged to my bank account, but my account still shows the status “Pending” with the message “Subscribe your membership”. It’s now been several days, and I haven’t received any confirmation email or any request for additional information. I already contacted Apple Support by email, but I’d like to know if other developers have experienced the same situation and how long it took before their account was activated. Thanks in advance for your help and feedback!
0
0
45
15h
Please allow the "Back to App" breadcrumb to coexist with Live Activities in Compact Mode
Subject: Request to maintain the "Status Bar Breadcrumb" visibility while Dynamic Island is active Hi, I am developing an app using ActivityKit and Dynamic Island. I've noticed a significant UX regression regarding the system status bar behavior. Current Behavior: When a Live Activity is active in the Dynamic Island (specifically in the compactLeading and compactTrailing presentation), the system automatically hides the "Back to [Previous App]" breadcrumb button (the small arrow and app name) in the top-left corner of the status bar. This breadcrumb only reappears when the Live Activity switches to the minimal presentation or is dismissed. The Issue: This behavior makes multitasking cumbersome for users. For example, if a user navigates from Safari to my app and then locks the screen or goes to Home, they expect the "Back to Safari" button to remain accessible. However, because my app's Live Activity is running in the Dynamic Island, the OS removes this navigation shortcut, forcing users to use the app switcher instead. Why this should be changed: Screen Real Estate: On larger devices (e.g., iPhone 15/16 Pro Max), there is significant whitespace in the top-left corner between the time and the Dynamic Island's leading edge. The breadcrumb could easily fit there without overlapping the Live Activity content. Inconsistent UX: Users are confused why the navigation button disappears solely because a background activity is running. Request: Please consider updating the status bar layout logic to allow the "Back to App" breadcrumb to remain visible if there is no physical overlap with the compactLeading view of the Dynamic Island. Thank you.
0
0
35
15h
Swift Student Challenge
Hey, I am looking to participate in the upcoming SSC 2026. I am confused whether I am allowed to submit an idea which is for watchOS. I know the fact that submission would be xcode project and playground correct me if I am wrong but as far as I know, we can develop prototypes for watch on playground. If anyone of you knows about this, please let me know!
1
0
646
18h
Debugger breakpoints not hitting since updating to macOS 26.1
Hi, I have started facing an issue with Xcode since updating to macOS 26.1. The debugger is not stopping at breakpoints in Objective-C code, however breakpoints in Swift file are working fine. I am using Xcode 16.4. For breakpoints in Objective-C files I have started to get this message since the OS update - 'Xcode won't pause at this breakpoint because it has not been resolved.' I have already tried cleaning derived data and build folder. I do not want to upgrade to Xcode 26. Could someone help with the fix? Thanks
0
0
58
19h
Do we still need to comply with SB2420 on Jan 1st for distributing apps in Texas ?
According to this news, we don't need anymore (at least temporarily): https://www.macrumors.com/2025/12/23/texas-app-store-law-blocked/ A Texas federal judge today blocked an App Store age verification law that was set to go into effect on January 1, 2026, which means Apple may not have to support the changes after all. Hope we shall get very rapidly more information from Apple.
1
0
80
19h
Guidance on implementing Declared Age Range API in response to Texas SB2420
I've spent the last few days researching the upcoming laws in Texas and other US states, and how these laws will impact on developers around the world. I want to share what I've learned so far with the community and get feedback on my current understanding. This post is not so much focused on a single API, but more of the bigger picture. Background The law essentially mandates that: (1) app store platforms implement age categorization and verification mechanisms, and (2) developers implement logic to listen to age categorization signals provided by the platform and respond accordingly. You can read the law itself here: https://capitol.texas.gov/tlodocs/89R/billtext/html/SB02420S.HTM Most people seem to be interpreting the law as follows: All developers who distribute apps in the USA are effectively required to implement the new APIs (required by Texas, not by Apple). The penalties are heavy, but it's unclear whether developers would actually be pursued and by whom (e.g. would someone seriously pursue an alarm clock app because it could be accessed by a minor?). Putting aside the ethical, privacy, and legal issues (and the damaging precedents this law sets), most people seem to agree that, from a technical perspective, this is a very silly way to implement age blocking (app store collects the info and passes it to dev, dev is responsible for blocking access). It would make way more sense for the platform to block the app directly for affected users (with optional API support for developers who wish to use it). However, I believe the law has specifically mandated that this is how they expect the system to work, so Apple's hands have been tied. Apple has basically complied with their obligations by providing the relevant APIs to developers. Because the law is vague and open-ended, there are a lot of legal and technical uncertainties about what developers actually need to do to be compliant. Understandably, Apple seems reticent to provide any guidance to developers that could be interpreted as legal advice. Apple's docs simply describe what the APIs do with no guidance on what the overall flow is meant to look like or how and when the APIs should actually be used in practice. Americans familiar with the political situation seem to think there's the possibility of an injunction before this law goes into effect, but that looks increasingly unlikely given that it's two weeks away. Developer solutions Many devs seem to be exploring two main workarounds, at least as temporary solutions: (1) Raise your app's rating to 18+. Putting aside the fact that Texas law would effectively be forcing developers to raise their global age rating (resulting in lost revenue that extends far beyond Texas), it remains unclear whether this solution is actually legally compliant, since the law specifically mandates that apps must implement logic to respond to signals from the platform. (2) Geo-block Texas. Again, it remains unclear if this is compliant because geo-blocking is not 100% accurate and it doesn't actually do what the law says you have to do. It also creates issues if you already have users in Texas, and it means performing additional privacy-hostile checks (i.e., detecting the user's location, even users who are not subject to the law). The DeclaredAgeRange API is actually pretty straight-forward to use – although there is still a lack of documentation on certain edge cases and it's difficult to test. In addition, the new APIs are only available in iOS 26.2, so it's unclear what you need to do if you're still supporting < iOS 26.2. Some people are of the opinion that developers can only reasonably respond to the signals that are available, thus pushing responsibility back to the platforms in regards to earlier OS versions. The API provides a bool (AgeRangeService.shared.isEligibleForAgeFeatures), which allows you to determine if the user is someone to whom age checks need to be applied. https://developer.apple.com/documentation/declaredagerange/agerangeservice/iseligibleforagefeatures I'm not 100% sure, but perhaps the simplest action you can take is to check this bool on launch and block access if it's true. In any case, it looks like this API will be very useful because it means we can avoid applying the checks in other jurisdictions and for grandfathered-in users without needing to implement custom geo-tracking code (albeit only in iOS 26.2+). To implement the API, my current thinking is that, on every launch, I should first check the above bool and, if it's true, do the following: (1) get the App Store age rating with let appStoreAgeRating = await AppStore.ageRatingCode ?? 18, (2) request the user's age with let ageRangeResponse = try await AgeRangeService.shared.requestAgeRange(ageGates: appStoreAgeRating), (3) check that the user has agreed to share their age, (4) check that lowerBound >= appStoreAgeRating, and (5) check that the verification method is not one of the self-declared methods. If this procedure fails, I should block access to the app and provide a link to Apple's support page: https://support.apple.com/en-us/122770 I stress, however, that this is just my current idea and there are some edge cases I'm unsure about. Other issues It is possible to do some basic testing of the API, but only using a sandbox App Store account on a physical device. From the Developer section in iOS Settings, you can select from a few different scenarios, like "Texas user aged 14 without parental consent", etc. There's also a whole separate aspect to this law relating to "significant updates". Everyone seems kinda confused about this, but it seems like the general idea is that, if your app's age classification changes in the future, the app should be responsive to that change. My current interpretation is that if I use the AppStore.ageRatingCode as the age gate (as described above) then that should allow me to comply, but I haven't really looked into this aspect of the law yet. There's also another aspect to this law requiring developers to revoke access to the app when requested by the parent. I have not looked into this yet, but as noted above, it doesn't make sense to me why this is the developer's responsibility given that the platforms already provide solid parental controls. Do I need to something else in addition to what I've sketched out above? It goes without saying, of course, that everything above is not legal advice, and I still have some gaps in my understanding. I would really appreciate any feedback on the above, perhaps with recommendations about better ways to approach this.
9
1
779
19h
AVAudioEngine obtains channel audio data
Currently, I have successfully used ChannelMap to map hardware input channels and obtained audio data from the hardware device's MIC and OTG inputs. Additionally, I have used ChannelMap to map output channels to freely feed data for playback to each output channel. However, I now have a problem. I have a hardware device that only has output channels (no input channels), and the system has set this hardware device as the default playback device. In this case, how can I obtain the audio data being played to the output channels for modification?
0
0
81
20h
Xcode debugger stops at dyld after upgrading to Xcode 26
After upgrading to Xcode 26, started getting an issue where Xcode debugger is stopping at dyld`lldb_image_notifier Does not happen on device. Tried cleaning derived data folder, clean build but no success. what could be the cause? this is from the stack. #0 0x0000000207e0ffa1 in lldb_image_notifier () #1 0x0000000207e11c49 in dyld4::ExternallyViewableState::triggerNotifications () #2 0x0000000207e13a2f in invocation function for block in dyld4::ExternallyViewableState::notifyMonitorOfImageListChangesSim(bool, unsigned int, mach_header const**, char const**) () #3 0x0000000207e10c3b in dyld4::ExternallyViewableState::notifyMonitorOfImageListChangesSim () #4 0x00000001102b9195 in dyld4::ExternallyViewableState::triggerNotifications () #5 0x00000001102b9465 in dyld4::ExternallyViewableState::addImages () #6 0x000000011029dcec in dyld4::RuntimeState::notifyDebuggerLoad () #7 0x00000001102b8065 in dyld4::APIs::dlopen_from(char const*, int, void*)::$_0::operator()() const::'lambda'()::operator()() const () #8 0x00000001102b71fd in dyld4::APIs::dlopen_from(char const*, int, void*)::$_0::operator()() const () #9 0x00000001102b30e3 in dyld4::APIs::dlopen_from () #10 0x00000001199b4c5e in _CFBundleDlfcnLoadFramework () #11 0x0000000119982a1e in _CFBundleLoadExecutableAndReturnError () #12 0x0000000115f081c4 in -[NSBundle loadAndReturnError:] () #13 0x00000001a3c42866 in -[NSBundleAccessibility loadAndReturnError:] () #14 0x000000013cd67fa7 in __50-[AXCodeItem loadWithStrategy:onQueue:completion:]_block_invoke_2 ()
2
0
197
21h
Bug Exists in the ES_EVENT_TYPE_AUTH_UNLINK Event of System Extensions
System Version: 26.1 Device: M1 Mac Mini Steps to Reproduce: Create a UNIX socket file at /tmp/a.sock Execute the command: ln /tmp/a.sock /tmp/b.sock Execute the command: rm /tmp/b.sock Bug Description: At this point, a bug occurs in the ES_EVENT_TYPE_AUTH_UNLINK event of the system extension. The value returned for message->event.unlink.target->path is /tmp/a.sock, while it is expected to be /tmp/b.sock Reproducibility: 100%
0
0
74
21h
iOS App rejected
Guideline 2.5.1 - Performance - Software Requirements The app uses or references the following non-public or deprecated APIs: Iobmobile Classes: • __SwiftValue The use of non-public or deprecated APIs is not permitted, as they can lead to a poor user experience should these APIs change and are otherwise not supported on Apple platforms. Can anyone she some light as to what __SwiftValue even means?
6
0
210
23h
DMG - Background - Broken in Tahoe ?
I am trying to set an image as the background in the window of a DMG. The image is: PNG file; 144x144 resolution; 1138x574 size. In macOS Tahoe, the image is added by: selecting the DMG window; opening the "Show View Options" dialog; clicking on "Picture"; dragging the image file to the small square box labelled "Drag image here"; closing "Show View Options" dialog. The DMG is then ejected. In Disk Utility, the image file is converted to "Read Only image (UDRO)". The converted image file is opened and the background image is visible. The image file is then copied to a MacBook running macOS 12 Monterey and opened. The background image is NOT shown. The image file is copied to a Mac mini running macOS 14 Sequoia and opened. The background image is NOT shown. Have read past online discussions in which it was explained that an image file called "background" should be inside a hidden folder called ".background". The above procedure did not do that. Is that old advice still correct for macOS Tahoe ? Has Tahoe somehow broken the method used for setting the background of a Window ? Is the method used in Tahoe different to past versions of macOS ? If so, is there a way of maintaining compatibility with old versions of macOS ? Is there any documentation on how to set the background image of a DMG window which might explain this behaviour ?? Thanks.
Topic: UI Frameworks SubTopic: General Tags:
0
0
82
1d
[Texas SB 2420] How to Retrieve Parental Consent Status
After reading the news below, we are currently working on updating our app in preparation for the enforcement of Texas SB 2420. https://developer.apple.com/news/?id=2ezb6jhj Based on the information in the announcement, we understand that parents will be able to revoke their consent for apps. However, we are unsure how an app is supposed to obtain or verify the parent’s consent status in the first place. We reviewed the Declared Age Range API and PermissionKit’s Significant Change API, but could not find any functionality related to this. If anyone with expertise on this topic has insight, we would greatly appreciate your guidance. Thank you in advance.
6
0
751
1d
App Widget NSExtensionPrincipalClass found in extension Info.plist
My app is built in flutter and has a native Widget in it. The widget's Info.plist file has the NSExtensionPrincipalClass key that links to the VerseOfTheDayWidgetBundle as string. However the Transport app throws an error: Validation failed (409) Unexpected Info.plist key. Unexpected key NSExtensionPrincipalClass found in extension Info.plist for Payload/Runner.app/PlugIns/VerseOfTheDayWidgetExtension.appex. (ID: 266e2dd8-44b9-4d67-97d9-d7d47013cff9) Now I tried removing the NSExtensionPrincipalClass and but the simulator throws an error asking for the NSExtensionPrincipalClass or Storyboard class but my widget is completely written in SwiftUI and does not have a storyboard which is why I am using the NSExtensionPrincipalClass. I tried to bypass this by creating two info.plist files for my widget (debug and release) this bypassed the security check on Transporter but then the app wouldn't install in TestFlight confirming the same issue as the simulator. I can confirm that my app's info.plist does not have any mention of NSExtensionPrincipalClass. so that isn't what is causing this error. I tried a lot of things but it just wouldn't work, at this point I feel maybe its something wrong with the checks Transporter app. I'm not sure, please guide me. The widget and the app work completely fine on the simulator with the NSExtensionPrincipalClass, its just the Transporter that does not like it being there.
2
2
181
1d
Developer Program enrollment still pending after payment
Hi everyone, I subscribed to the Apple Developer Program on Tuesday evening, November 4th, 2025. The payment has already been charged to my bank account, but my account still shows the status “Pending” with the message “Subscribe your membership”. It’s now been several days, and I haven’t received any confirmation email or any request for additional information. I already contacted Apple Support by email, but I’d like to know if other developers have experienced the same situation and how long it took before their account was activated. Thanks in advance for your help and feedback! — Martin
25
11
2.6k
1d
Apple’s age rating deadline: will apps be blocked after 31 Jan 2026?
Apple sent a final reminder asking developers to complete the updated age rating questions in App Store Connect. Final reminder: Answer the updated age ratings questions. We’re reaching out because you have not provided responses to the updated age ratings questions in the App Information section of your app in App Store Connect. If you don’t answer these questions by January 31, 2026, you won’t be able to submit app updates in App Store Connect. The email says that if the age rating questions are not answered by 31 January 2026, you will not be able to submit app updates. What is not clear is what actually happens after that date. Many of us are in the middle of development and may not be ready to submit a new build before the deadline. The email does not explain whether this means: A) You can still submit updates after 31 January 2026, as long as you complete the age rating questionnaire before submitting, or B) The app becomes locked and cannot be updated at all once the deadline passes This is not stated explicitly in the email, which makes it confusing for me. It would be helpful if Apple could clearly confirm what developers should expect after 31 January 2026, especially for apps that are still undergoing active development. Anyone knows?
6
3
634
1d
Game Center When Opponent Declines Game
Turn-based games: 2 players When an opponent declines a game in the Game Center MatchMaker VC, that player sees that they quit, but no message is sent to the listener about that fact. For the person who started the match, their MMVC shows it's their turn again. Why doesn't Game Center end the match?
0
0
125
1d
waiting for review longer than usual after resubmission
Hello, My app (App ID: 1616628950) is currently in the Waiting for Review state after resubmission. The app was resubmitted on December 24 following a previous rejection related to in-app purchase labeling. The issue has been addressed, and the updated build was submitted accordingly. Normally, our app updates enter review within 1–2 days, so this delay seems slightly unusual. I understand that review times may vary, especially during the holiday period, but I wanted to check in here in case the submission might be stuck or require additional information from our side. There were no major functional or policy-related changes in this update aside from addressing the previously noted issue. Thank you very much for your time and assistance.
0
0
74
1d