Overview

Apple made them both, and for some reason they are acting like each is speaking a foreign language. Once you plug the iPad in, shouldn't the "trust this computer" kick in and allow the iMac to turn on developer mode? I'm the dumbest person in the world when it comes to Code, but this is a no brainer! And the fact that the iPad is in Developer mode, is the most frustrating part. This needs a fix.

Hello, World I built a deterministic safety layer for FoundationModels called Newton. It validates prompts before inference — if validation fails, generation never happens. It catches jailbreaks, hallucination traps, corrosive frames, and logical contradictions with 94% accuracy on adversarial inputs. All on-device, native Swift, no dependencies. Newton also has a front-facing Intelligent Partner named Ada, and given the incredible integration with FoundationModels and various census data and shape files, this is all available PRIVATE AND OFFLINE. Running on iOS 26 beta today. Happy to demo. https://github.com/jaredlewiswechs/ada-newton — Jared Lewis parcri.net

im facing a problem where everything was working just fine the previous day then overnight I get a email saying I’m terminated for fraud when all my info is my correct information and is up to date I will say this I did have a name change, but that was like three years ago so I’m not sure what is going on or what the problem is . id really love some feedback or ideas on what I should do no

Hello, We are trying to use the new Background Upload Extension to improve uploads of assets (Photos, Live Photos, Videos) in the background in our application. 1-The assets have finished uploading, but I'm unable to retrieve successful records using PHAssetResourceUploadJob.fetchJobs(action: .acknowledge, options: nil). When will the successful records be returned? 2-How to retrieve the system's pending tasks? We want to cancel tasks handed over to the system when returning to the main app to avoid duplicate resource uploads. 3-When we set UploadJobExtensionEnabled = true, will tasks handed over to the system still execute after returning to the main app? Do we need to set UploadJobExtensionEnabled = false upon returning to the main app? If we set UploadJobExtensionEnabled = false, will previously submitted upload tasks be cleared?

Hi everyone. I'm trying to use https://developer.apple.com/documentation/appstoreserverapi/get-transaction-info to retrieve order information. How can I get the refund status of an order through this API? Also, Apple's webhook notification for refunds includes fields like revocationReason and revocationType. Can these be retrieved through the API? I've noticed that some refund orders have these fields when retrieved using get-transaction-info api, but others don't. I don't know the reason for these differences. Could you please explain? Thank you very much.

Hello, We are trying to use the new Background Upload Extension to improve uploads of assets (Photos, Live Photos, Videos) in the background in our application. 1-The assets have finished uploading, but I'm unable to retrieve successful records using PHAssetResourceUploadJob.fetchJobs(action: .acknowledge, options: nil). When will the successful records be returned? 2-How to retrieve the system's pending tasks ? We want to cancel tasks handed over to the system when returning to the main app to avoid duplicate resource uploads. 3-When we set UploadJobExtensionEnabled = true, will tasks handed over to the system still execute after returning to the main app? Do we need to set UploadJobExtensionEnabled = false upon returning to the main app? If we set UploadJobExtensionEnabled = false, will previously submitted upload tasks be cleared?

In trying to convert some Objective-C to Swift, I have a subclass of NSWindowController and want to write a convenience initializer. The documentation says You can also implement an NSWindowController subclass to avoid requiring client code to get the corresponding nib’s filename and pass it to init(windowNibName:) or init(windowNibName:owner:) when instantiating the window controller. The best way to do this is to override windowNibName to return the nib’s filename and instantiate the window controller by passing nil to init(window:). My attempt to do that looks like this: class EdgeTab: NSWindowController { override var windowNibName: NSNib.Name? { "EdgeTab" } required init?(coder: NSCoder) { super.init(coder: coder) } convenience init() { self.init( window: nil ) } } But I'm getting an error message saying "Incorrect argument label in call (have 'window:', expected 'coder:')". Why the heck is the compiler trying to use init(coder:) instead of init(window:)?

I am creating a macOs SwiftUI document based app, and I am struggling with the Window sizes and placements. Right now by default, a normal window has the minimize and full screen options which makes the whole window into full screen mode. However, I don't want to do this for my app. I want to only allow to fill the available width and height, i.e. exclude the status bar and doc when the user press the fill window mode, and also restrict to resize the window beyond a certain point ( which ideally to me is 1200 x 700 because I am developing on macbook air 13.3-inch in which it looks ideal, but resizing it below that makes the entire content inside messed up ). I want something like this below instead of the default full screen green When the user presses the button, it should position centered with perfect aspect ratio from my content ( or the one I want like 1200 x 700 ) and can be able to click again to fill the available width and height excluding the status bar and docs. Here is my entire @main code :- @main struct PhiaApp: App { @NSApplicationDelegateAdaptor(AppDelegate.self) var appDelegate var body: some Scene { DocumentGroup(newDocument: PhiaProjectDocument()) { file in ContentView( document: file.$document, rootURL: file.fileURL ) .configureEditorWindow(disableCapture: true) .background(AppColors.background) .preferredColorScheme(.dark) } .windowStyle(.hiddenTitleBar) .windowToolbarStyle(.unified) .defaultLaunchBehavior(.suppressed) Settings { SettingsView() } } } struct WindowAccessor: NSViewRepresentable { var callback: (NSWindow?) -> Void func makeNSView(context: Context) -> NSView { let view = NSView() DispatchQueue.main.async { [weak view] in callback(view?.window) } return view } func updateNSView(_ nsView: NSView, context: Context) { } } extension View { func configureEditorWindow(disableCapture: Bool = true) -> some View { self.background( WindowAccessor { window in guard let window else { return } if let screen = window.screen ?? NSScreen.main { let visible = screen.visibleFrame window.setFrame(visible, display: true) window.minSize = visible.size } window.isMovable = true window.isMovableByWindowBackground = false window.sharingType = disableCapture ? .captureBlocked : .captureAllowed } ) } } This is a basic setup I did for now, this automatically fills the available width and height on launch, but user can resize and can go beyond my desired min width and height which makes the entire content inside messy. As I said, I want a native way of doing this, respect the content aspect ratio, don't allow to enter full screen mode, only be able to fill the available width and height excluding the status bar and doc, also don't allow to resize below my desired width and height.

Hi, Overview I have a Mac app with a settings window. When I add a button it is added to the center. I want it on the trailing edge, I even tried adding it as confirmationAction but doesn’t work. Screenshot Feedback FB21374186 Steps to reproduce Run the project on mac Open the app's settings by pressing ⌘ , Notice that the Save button is in the center instead of the trailing edge Code App import SwiftUI @main struct SettingsToolbarButtonBugApp: App { var body: some Scene { WindowGroup { ContentView() } Settings { SettingsView() .frame(width: 300, height: 400) } } } SettingsView import SwiftUI struct SettingsView: View { var body: some View { NavigationStack { Form { Text("Settings window") } .toolbar { ToolbarItem(placement: .confirmationAction) { // Save button is the center instead of trailing edge Button("Save") {} } } .navigationTitle("Settings") } } }

SwiftUI's colorScheme modifier is said to be deprecated in favour of preferredColorScheme but the two work differently. See the below sample app, colorScheme changes the underlying view colour while preferredColorScheme doesn't. Is that a bug of preferredColorScheme? import SwiftUI struct ContentView: View { let color = Color(light: .red, dark: .green) var body: some View { VStack { HStack { color.colorScheme(.light) color.colorScheme(.dark) } HStack { color.preferredColorScheme(.light) color.preferredColorScheme(.dark) } } } } #Preview { ContentView() } @main struct TheApp: App { var body: some Scene { WindowGroup { ContentView() } } } extension UIColor { convenience init(light: UIColor, dark: UIColor) { self.init { v in switch v.userInterfaceStyle { case .light: light case .dark: dark case .unspecified: fatalError() @unknown default: fatalError() } } } } extension Color { init(light: Color, dark: Color) { self.init(UIColor(light: UIColor(light), dark: UIColor(dark))) } }

Hi everyone, I've been building an on-device AI safety layer called Newton Engine, designed to validate prompts before they reach FoundationModels (or any LLM). Wanted to share v1.3 and get feedback from the community. The Problem Current AI safety is post-training — baked into the model, probabilistic, not auditable. When Apple Intelligence ships with FoundationModels, developers will need a way to catch unsafe prompts before inference, with deterministic results they can log and explain. What Newton Does Newton validates every prompt pre-inference and returns: Phase (0/1/7/8/9) Shape classification Confidence score Full audit trace If validation fails, generation is blocked. If it passes (Phase 9), the prompt proceeds to the model. v1.3 Detection Categories (14 total) Jailbreak / prompt injection Corrosive self-negation ("I hate myself") Hedged corrosive ("Not saying I'm worthless, but...") Emotional dependency ("You're the only one who understands") Third-person manipulation ("If you refuse, you're proving nobody cares") Logical contradictions ("Prove truth doesn't exist") Self-referential paradox ("Prove that proof is impossible") Semantic inversion ("Explain how truth can be false") Definitional impossibility ("Square circle") Delegated agency ("Decide for me") Hallucination-risk prompts ("Cite the 2025 CDC report") Unbounded recursion ("Repeat forever") Conditional unbounded ("Until you can't") Nonsense / low semantic density Test Results 94.3% catch rate on 35 adversarial test cases (33/35 passed). Architecture User Input ↓ [ Newton ] → Validates prompt, assigns Phase ↓ Phase 9? → [ FoundationModels ] → Response Phase 1/7/8? → Blocked with explanation Key Properties Deterministic (same input → same output) Fully auditable (ValidationTrace on every prompt) On-device (no network required) Native Swift / SwiftUI String Catalog localization (EN/ES/FR) FoundationModels-ready (#if canImport) Code Sample — Validation let governor = NewtonGovernor() let result = governor.validate(prompt: userInput) if result.permitted { // Proceed to FoundationModels let session = LanguageModelSession() let response = try await session.respond(to: userInput) } else { // Handle block print("Blocked: Phase \(result.phase.rawValue) — \(result.reasoning)") print(result.trace.summary) // Full audit trace } Questions for the Community Anyone else building pre-inference validation for FoundationModels? Thoughts on the Phase system (0/1/7/8/9) vs. simple pass/fail? Interest in Shape Theory classification for prompt complexity? Best practices for integrating with LanguageModelSession? Links GitHub: https://github.com/jaredlewiswechs/ada-newton Technical overview: parcri.net Happy to share more implementation details. Looking for feedback, collaborators, and anyone else thinking about deterministic AI safety on-device.

Here are some tips from App Review for a smooth review experience. We’ve split them into two categories: Before You Submit and After You Submit. We’ve also made an easy-to-follow Submission Guide you can save and reference at any point on your App Store journey. Before You Submit Tips Enable a complete review. Make sure you’ve provided demo accounts or implemented an account demonstration mode before you submit. We’ll need to review the entire app experience, both with and without an account. Provide up-to-date demo account login credentials in the App Review Information section on the app version page in App Store Connect. If your app has multiple account types (such as admin and general users), use the Notes field to provide additional demo account credentials for each account type. If your app requires an authentication code in addition to the login credentials, provide the code in advance in the Notes field. Otherwise, a call may be required to complete the review. Apps that handle sensitive user information, or operate in highly regulated industries, can implement demonstration modes that exhibit full features and functionality while using demonstration data. Use the Notes field in App Store Connect to provide information to App Review. The App Review Information section of App Store Connect includes a Notes field. Provide any information that could be relevant to your submission’s review: Submitting a new app? Tell us about your app's concept, business model, and if your app is designed to only operate in certain locations. Submitting an update? Tell us about what’s changed and where to locate significant new content or features. Connecting to hardware? Attach a video, not a screen recording, that shows both the hardware and the app running on a physical Apple device as they pair and interact. Test your app on physical devices before submitting for review. Use TestFlight to distribute your app for beta testing. App Review evaluates apps the way your users will use them: installed on real devices and connected to networks with real-world conditions. Make sure your pre-submission testing includes running the app on each device platform where it could be used. Users expect the app to function on all the devices where it’s available. TestFlight will help you do quality assurance and beta testing on real devices. Share your beta app with internal testers on your Apple Developer Program account or to external users via an email invite or public link. Configure In-App Purchases for review in the sandbox environment. App Review assesses In-App Purchases in the same sandbox environment Apple provides for testing them. The sandbox lets us use real product data and server-to-server transactions, without incurring any financial charges. Take these steps to prepare your In-App Purchases for review: Accept the Paid Applications Agreement in App Store Connect. Submit the In-App Purchases in App Store Connect that you’d like reviewed. Follow the steps in TN3186: Troubleshooting In-App Purchases availability in the sandbox if your app fails to display your In-App Purchases. Note: In-App Purchases don’t need prior approval from App Review to function in review. Join a Meet with Apple event if you need assistance before you submit for review. Request an App Review appointment through Meet with Apple to chat with an App Review expert about how to prepare for review, ask questions about specific guidelines, and discuss other topics related to the review process. Appointments are subject to availability during your local business hours on Tuesdays and Thursdays. After You Submit Tips Contact App Review if you need assistance with an ongoing submission. If your submission doesn’t pass review and you have questions, contact App Review directly by clicking Reply to App Review in App Store Connect. You’ll receive a reply from a review specialist who’s familiar with your app. You can also use the Reply to App Review message window to request a call with an Apple representative. Include your preferred time and language for the call and we’ll do our best to accommodate your requests. Use the Bug Fix Submissions process to quickly deliver bug fixes and resolve other issues on the next submission. If an update includes bug fixes and is rejected, you will be given the option to resolve the issues on your next submission, as long as there are no legal or safety concerns. App Review will let you know if your submission is eligible by including this note at the top of the rejection message: Bug Fix Submissions The issues we've identified below are eligible to be resolved on your next update. To accept this offer, simply reply to the rejection message in App Store Connect and let App Review know you’ll resolve the issues on the next submission. Share ideas with Apple about how to improve or clarify the App Review Guidelines by submitting guideline feedback. Just as the App Store is always changing and improving to keep up with the needs of customers, the App Review Guidelines may be revised to provide new and updated guidance. If you have ideas for improving or clarifying our requirements you can suggest guideline changes. If your submission was rejected but you believe it follows the App Review Guidelines, consider submitting an appeal to the App Review Board. If your submission didn’t pass review but you have reason to believe it follows the App Review Guidelines, you can submit an appeal to the App Review Board. You can also file an appeal if you think we misunderstood your app or the review was unfair. The App Review Board will contact you as soon as they complete their investigation.

I’m not sure what the issue is. I’ve filled in all the information on the Business Agreements page, but the status is still Pending User Info. Does anyone know what information might be missing?

using Version 26.2 (17C52) I often get "Trace file had no SwiftUI data" why so?

Hey Apple Friends, We currently have an enterprise version of our app for debugging and internal distribution. Our release configuration uses our App Store account. However, it appears you cannot add a 'Declared Age Range' to the Enterprise app as a capability making it impossible to debug because we have added the 'Declared Age Range API' locally, but we cannot add it as a capability on the dev portal. Is there any work around for this?

The documentation for isEligibleForAgeFeatures states: Use this property to determine whether a person using your app is in an applicable region that requires additional age-related obligations for when you distribute apps on the App Store. But what does "region" mean? Is this going to return true if the user has downloaded the app from the US App Store? Or will it go further and geolocate the user and identify them as being within a particular relevant state within the US?

Hello! After update both XCode and MacOs I'm not able to distribute iOS app to Apple Store. Unsupported SDK or Xcode version - App submissions must use the latest Xcode and SDK Release Candidates (RC). For details on currently supported versions, visit: https://developer.apple.com/news/releases. What might be the issue?

I've built an iOS app with a novel approach to AI safety: a deterministic, pre-inference validation layer called Newton Engine. Instead of relying on the LLM to self-moderate, Newton validates every prompt BEFORE it reaches the model. It uses shape theory and semantic analysis to detect: • Corrosive frames (self-harm language patterns) • Logical contradictions (requests that undermine themselves) • Delegation attempts (asking AI to make human decisions) • Jailbreak patterns (prompt injection, role-play escapes) • Hallucination triggers (requests for fabricated citations) The system achieves a 96% adversarial catch rate across 847 test cases, with zero false positives on benign prompts. Key technical details: • Pure Swift/SwiftUI, no external dependencies • Runs entirely on-device (no server calls for validation) • Deterministic (same input always produces same output) • Auditable (full trace logging for every validation) I'm preparing to submit to the App Store and wanted to ask: Are there specific App Review guidelines I should reference for AI safety claims? Is there interest from Apple in deterministic governance layers for Apple Intelligence integration? Any recommendations for demonstrating safety compliance during review? The app is called Ada, and the engine is open source at: github.com/jaredlewiswechs/ada-newton Happy to share technical documentation or discuss the architecture with anyone interested. See: parcri.net

I wanted to add a new app and I’m having problems with it. When adding my previous apps or updating them, there were no issues at all. I submitted the app for review and waited two weeks without any response. I removed it and submitted it again, and now I’ve been waiting for several days once more. Is anyone able to help me? I don’t think there’s anything wrong with the app, as it’s just a simple game.

I currently have one subscription group with one approved subscription. It is live in production. I am now adding more subscriptions to the same group. Different tiers and different durations. Is there a way to get these new subscriptions approved by Apple, but not yet have them show as options within the group? Sort of an approved-but-inactive state? There's a timing issue. I don't want the new options to show before the website/app descriptive text supports them. And I don't want the website/app descriptive text to describe purchase options that aren't yet available.