I have make an app for company's employee and released the application in app store in private by providing organisation ID and the application is showing ready for distribution in my developer account. But after this I can't understand how to get the application or the link to have the application for use. And also I already contact to the apple team via mail but from them there is no response. How to procced further?

My builds failed today with this error: Unsupported SDK or Xcode version. Your app was built with an SDK or version of Xcode that isn’t supported. Although you can use beta versions of SDKs and Xcode to build and upload apps to App Store Connect, you need to use the latest Release Candidates (RC) for SDKs and Xcode to submit the app. For details on currently supported SDKs and versions of Xcode, visit: https://developer.apple.com/news/releases. The thing is, I have Xcode Cloud configured to use the latest release. There is a separate configuration for "Latest beta or release", so why is it using the Xcode 16.2 Beta 3 build? This is clearly a beta. If you're going to give me an option to use the latest release, then it should do what it says.

Using the native email ios mail app iPhone 16 pro. When an email arrives the phone will ding or vibrate, but the message notification doesn't appear on lock screen. If you touch the screen from dim to wake then scroll up, the email notification does appear. If the phone is open the notification also appears at the top of screen as it's meant to do. This started yesterday with iOS 18.2 beta 1. It was not resolved with the new update.

Hello, After upgrading to iPad OS 18.1, Rest Finger To Open not working on my device - which is an 9th-generation iPad (10.2 inch) - anymore, now I have to actually press the Home button, only then I can unlock the screen with Touch ID. It was fine on iPad OS 17, where I just need to rest my finger on the Touch ID (or Home button) and it would unlock the device right away, no need to press. I'm sure all the required settings have been checked (please check out the screenshots). Not sure if anyone else is facing this. Hope it's not only me. Please take a look at this and fix it if it's a genuine issue. Thank you.

I encountered a crash in iOS 17 related to CLBackgroundActivitySession, which appears to be due to misleading guidance in an Apple’s WWDC video. Crash sample code: https://github.com/steve-ham/AppleLocationCrash Simplified Reproduction Steps: 1. Open the GitHub sample app. 2. Archive and export (Distribute App -> Custom -> (Release Testing, Enterprise, or Debugging) -> Export). 3. Open the app. 4. Tap enableBackgroundLocation -> select Allow While Using App on the system popup. 5. Tap disableBackgroundLocation. 6. Go to the iOS home screen. 7. Wait for 10 seconds. 8. Reopen the app -> crash occurs. The crash happens because setting CLBackgroundActivitySession to nil does not end the session, despite Apple’s guidance suggesting it should. Below is the exact quote from WWDC 2023, which explicitly states that both calling invalidate() or letting the object get destroyed (i.e., setting to nil) would end the session: WWDC 2023 Discover Streamlined Location Updates (https://developer.apple.com/videos/play/wwdc2023/10180/) “Before starting the updates, you should instantiate a CLBackgroundActivitySession object to start a new session. Note, we are assigning the session to self.backgroundActivity, which is a property and not to a local variable. And this is important because if we used a local variable, then when it goes out of scope, the object it holds would be deallocated, invalidating the session and potentially ending your app’s access to location. Then when we want to end our session, we can do that by sending the invalidate message or by letting the object be destroyed.” I’ve submitted this to Apple for resolution but wanted to share this with the community. This misguidance has caused issues in my app’s release. If Apple could reply to confirm or provide clarification, it would be greatly appreciated. P.S. Even a minimal implementation in viewDidLoad triggers the crash: let session = CLBackgroundActivitySession() print("session (session)")

Hello all, I’ve had the iOS 18 beta since it’s been available, but recently when I updated to iOS 18.2 beta 2 I’ve been experiencing random crashes and frozen screens. I can’t seem to find any common reason for it, as it’s seemingly random. My screen will turn black and show the loading icon like I’ve run out of battery before the screen turns back on showing the Lock Screen. I’ve experienced crashes anywhere from 1-5 times daily for roughly 3-5 days, though the screen has only frozen once and gone completely unresponsive for a solid minute. When it froze I attempted to power off the phone, but all buttons were y responsive as well. After around a minute had passed, the screen went black and it crashed before returning to the Lock Screen and working otherwise fine afterwards. Has anyone else experienced this, or know a potential reason this is happening ?

The interactiveDismissDisabled() function in SwiftUI's Sheet no longer works as expected in iOS 18.1 (22B83). It was working as expected until iOS 18.0.1. Are there any other users experiencing the same issue? struct ContentView: View { @State private var openSheet = false var body: some View { NavigationStack { Button("Open") { openSheet = true } .sheet(isPresented: $openSheet) { SheetView() } } } } struct SheetView: View { @Environment(\.dismiss) private var dismiss var body: some View { NavigationStack { Text("This is the Sheet") .toolbar { ToolbarItem(placement: .cancellationAction) { Button("Cancel") { dismiss() } } } .interactiveDismissDisabled() } } } Supplementary information: In iOS 18.1, even Apple's native Journal app allows users to swipe-to-dismiss the sheet when creating a new entry. Previously, a confirmation dialog would be displayed, but this is no longer the case.​​​​​​​​​​​​​​​​

I remember a long time ago seeing a website that would show every single piece of feedback sent to Apple, not showing the sender. The website looked old but still working. Dies anyone know what it is? Thank you

The current setup restricts the access to the dock from the external monitors, requiring me to switch back to the MacBook screen. This process is inefficient for my workflow as it involves scrolling through multiple monitors, consuming valuable time.

I tend to remember that it is not possible to get a status update for a FB Ticket as long as you are not the one (or part of the team) who created the ticket (for obvious privacy and confidentiality reasons). And based on what I'm reading from some posts in the forum, it's not unusual that a FB ticket declared to be a duplicate of another ticket is not updated when the original ticket is either fixed or closed. So what is the recommendation to be informed about the status of a problem when you know that a FB ticket was already filed by another party (and it's obvious your ticket will be marked to be a duplicate)? File a FB ticket on the same topic with a reference to the original FB ticket and pray? N.B. : this is not a case listed in the https://developer.apple.com/bug-reporting/ page.

If you create a cookie and add to the WKWebViewConfiguration the completionHandler returns 'Cookies synced' suggesting cookie was added with success. However, upon inspection of app in Safari the cookie is not there. This is broken in iOS 18 beta and works in previous versions without issue. Did Apple change the WKWebView API and break this feature? code snippet: NSDictionary* settings = self.commandDelegate.settings; WKWebViewConfiguration* configuration = [self createConfigurationFromSettings:settings]; configuration.userContentController = userContentController; NSMutableDictionary *cookieProperties = [NSMutableDictionary dictionary]; [cookieProperties setObject:@"foo" forKey:NSHTTPCookieName]; [cookieProperties setObject:@"bar" forKey:NSHTTPCookieValue]; [cookieProperties setObject:@"mydomain.com" forKey:NSHTTPCookieDomain]; [cookieProperties setObject:@"mydomain.com" forKey:NSHTTPCookieOriginURL]; [cookieProperties setObject:@"/" forKey:NSHTTPCookiePath]; NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties]; [configuration.websiteDataStore.httpCookieStore setCookie:cookie completionHandler:^{NSLog(@"Cookies synced");}]; WKWebView* wkWebView = [[WKWebView alloc] initWithFrame:self.engineWebView.frame configuration:configuration];

How to report a bug says "With Feedback Assistant available on iPhone, iPad, Mac, and the web, it’s easy to report issues you encounter". The Feedback Assistant User Guide says "Tell Apple about your experience with beta or seed releases". Is Feedback Assistant only intended for reporting bugs in beta software? A year ago I reported a bug in Xcode 14 and now I'm being asked to verify this issue with Xcode 16 Beta 3. I'm not a beta tester and I don't want to install beta software. How should I proceed?

I received an email from Apple saying they couldn't auto-renew my developer subscription, due to a "billing error." I went in and deleted my lone payment method (which looked up-to-date), and created a new one for the same credit card in my developer account for billing. All the information appears correct. I've downloaded the Developer app, where it tells me my developer subscription is good through next month. There's a Renew button underneath. If I click on it, an alert says either "Unknown Error" (first time after launching), or it says "Unable to Continue. Please ensure your device and iCloud account meet our system requirements. Visit https://developer.apple.com/support/app-account/" (subsequent times). These are near-useless error messages. Which doesn't sound like a billing error. I don't pay anything for an iCloud account, nor wish to use an iCloud account. I'm running System 12.1 on my M1 MacBook Pro. After an hour of talking with three different humans at 1-800-MY-APPLE, they couldn't help, basically giving up and telling me to go to developer.apple.com/support/technical. But that's for submitting a TSI (Technical Support Incident) for my own needs as a developer, not for Apple's uninformative software. All I want to do is renew my developer subscription. Something's obviously wrong, but the automated system isn't providing enough information to continue, and the humans at the other end of the phone don't have enough information to help. The last guy I talked with threw up his hands, apologizzed, and then wished that I have a "good day." Any suggestions?

I file a lot of bug reports. I also ask a lot of third-party developers to file bug reports about problems they see. This post is my attempt at collecting together some hints and tips about Apple’s bug reporting process. To file a bug report, use Feedback Assistant. To file an enhancement request, use Feedback Assistant. In the “What type of issue are you reporting?” popup, choose Suggestion. If you’re filing a bug against an API, choose Developer Technologies & Resources at the top level. The technologies popup should then list familiar items, from Accelerate Framework to XPC. If you can’t find the correct item, select “Something else not on this list”. Feedback Assistant is both a website and an app. For details on how to access the app, see Opening the app on the Developer > Bug Reporting page. For lots of great hints and tips about filing bugs, see File effective bug reports. I may repeat some of the info covered by that article, but only where I think it’s particularly important. After filing a bug report, please include the bug number in your DevForums post. Feedback Assistant shows the bug number in both the bug list and the bug detail view. Bug numbers start with FB and continue with a sequence of digits. For example, a recent bug report posted here on DevForums was FB11357055. Including the FB prefix avoids any confusion as to what type of bug number this is. Occasionally you’ll see other types of bug numbers. In release notes they are just in parens, so (99071807), and in DTS documents they have an r. prefix, so (r. 99071807). These are Radar numbers. Radar is the internal bug system here at Apple. Other developers can’t see your bug report. However, posting the bug number is still important for a couple of reasons: It allows Apple folks to quickly track down your issue. If another developer wants to file a related bug, they can reference your bug number in their bug report. You can share bug reports with other members of your team. For details on how to do that, see Collaborating with your team on the Developer > Bug Reporting page. Otherwise you can’t see a bug report filed by another developer, or one filed internally at Apple. One option here is to file your own bug and request that it be marked as a duplicate of the original bug. You’ll then be notified when the original bug is closed. The File effective bug reports article discusses the importance of including a sysdiagnose log with your bug report. I have a few additional tips: Include a sysdiagnose log from the machine that’s having the problem. Sometimes I see folks with an iOS problem include a sysdiagnose log for their development Mac )-: Include a sysdiagnose log even if you attach a test project that reproduces the problem. The contents of the log help with screening, making sure that your bug gets to the right person quickly. And that person will be very grateful to have your test project! If multiple machines are involved — for example, you’re reporting a Handoff problem — include a sysdiagnose log from each machine. Trigger the sysdiagnose log as soon as possible after you see the problem. The sooner you trigger the log, the more likely it is to capture relevant info. If the problem is hard to reproduce, see Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem for hints on how to capture an actionable sysdiagnose log. If you install a debug profile, install it before you reproduce the problem. These profiles typically enable more logging, and you want that logging to be active at the time of the problem. Most profiles activate immediately but some require that you restart. Follow the instructions that came with the profile. When reproducing the problem, make a rough note of the time and include that in your bug report. This doesn’t have to be super precise. Just note down the time, with seconds, shortly after you reproduce the problem. If the bug involves a crash, reproduce the crash outside of Xcode and then take your sysdiagnose log. This means running your code as the user would, so running an app from the Finder on macOS, running an app from the Home screen on iOS, and so on. If you reproduce the crash inside Xcode, the Xcode debugger catches the crash and prevents the system from generating a crash report to include in the sysdiagnose log. File focused bug reports. Imagine you’re seeing two problems, A and B, related to the same API. Don’t file a single bug that covers both A and B. Rather, file separate bugs for A and B. Feel free to reference your A bug in your B bug, and vice versa. Finally, some personal notes: DevForums is not an official support channel. Mentioning a problem here is not the same as filing a bug about it. That’s true even if you’re discussing your issue with an Apple person. Apple is a big company, and it’s very unlikely that the person you’re talking to is directly responsible for fixing your bug. Historically I used to post a lot of Radar links, of the forms rdar:nnn, where nnn includes the bug number. I no longer use these links because I’ve found that they confuses folks. They click the link and wonder why it does nothing. If you post an FB number here, DevForums automatically turns it into a link. However, that link is only useful to you. Other folks can’t access the bug via that link. I’ve filed a bug against DevForums requesting that it only generate this link for the bug’s originator (r. 92946014). In the meantime, I work around this by putting FB numbers in code style, which disables this link generation. If you want to share bug information outside of DevForums, one popular option is Open Radar (https://openradar.appspot.com/). Apple uses a lot of open source and many open source projects maintain their own bug tracker. Two big examples are Swift and WebKit. If your bug originates in such an open source project, consider filing it in the project’s bug tracker. You can then go on to submit a pull request with the fix (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History 2025-08-07 Updated “Developer Technologies & SDKs” to “Developer Technologies & Resources”. 2024-03-07 Made minor editorial changes. 2023-10-26 Added a link to Using a Sysdiagnose Log to Debug a Hard-to-Reproduce Problem. Added a recommendation to file focused bug reports. 2023-06-28 Updated the advice on how to file an API-level bug based on recent changes to Feedback Assistant. Corrected some link titles. 2023-03-21 Added a bunch of bullets to the personal notes section. 2023-03-13 Extended the discussion of seeing other folks’ bugs to make it clear that you can’t see bugs filed internally at Apple. 2022-12-13 Added advice about the “Something else not on this list” option. 2022-09-01 Added a personal notes section at the end. Added a new bullet in the sysdiagnose section about running your app outside of Xcode. Made other minor editorial changes. 2022-08-29 Added a note about filing duplicate bugs. 2022-08-24 First posted.

Dear Apple,I'm an iOS developer and provided feedback in the good old online bug tracker for many years.Decent conversations with Apple egnineers often resulted in bug fixes or updated documentation.The fact that my contributions helped to improve the products was rewarding.So I kept adding reports in the new Feedback Assistant app in macOS Catalina.But ever since (September 2019) I never ever got any response on any ticket.1 month ago I even added a report if Apple even read my reports. Again, no response ever since.So my question on this forum: Is Apple actually reading reports in the new Feedback Assistant?This can either be answered by Apple, or by other Developers that hopefully did response feedback from Apple. Or did not.Best regards,Martijn