file uri scheme

I'm trying to sign a .app package coming from Py2app. Unfortunately I keep running into the same two issues: The binary is not signed with a valid Developer ID certificate. and The signature does not include a secure timestamp. I tried everything, from recreating the signatures, with different arguments, different keys and certificates, but it keeps complaining with these two errors on a long list of files. For reference I added the python script I use for signing the files. code_singing.py

Hey I’m working on a macOS app that wants to detect the MacBook lid / hinge angle (i.e. how far the screen is open) by directly reading the internal sensor via HID / IOKit (a private / undocumented API). I came across this project: LidAngleSensor — GitHub: https://github.com/samhenrigold/LidAngleSensor?tab=readme-ov-file Before investing too much effort, I’d like to ask the community: Has anyone succeeded in getting such an app accepted on the Mac App Store when it includes sensor-level, private API access like this? What were the reviewer feedback or rejection reasons (if any)? Are there documented cases (positive or negative) where Apple approved or rejected apps for accessing non-public hardware sensors? What’s the risk of getting banned or permanently rejected for integrating this kind of functionality? If you have direct experience (whether it passed or failed), I’d love to hear your stories, strategies, or pointers. Thanks in advance!

I'm looking for answer or documentation on gatekeeper and launching a MacOS app via a url scheme/custom protocol. Our application is delivered via a zip file downloaded from the web. We utilize a url scheme. The act of extracting the app from the zip registers the url scheme with the OS. From previous research/testing we found we had to break the gatekeeper lock (have the user move the app from the downloaded location) to ensure that the url is honored on first launch of the application. To ensure user compliance, we added a check to make sure that the lock has been removed by looking at the quarantine attribute. This flow is not ideal. I am looking for alternatives and was previously under the impression that if we were to move to a DMG then that would provide the user a better user experience for moving it. However, now that I am getting around to looking into it, I am seeing some implied statements that this is not the case and that the quarantine bit will just be moved

Hello, currently I am having trouble releasing an app because it crashes/does not launch on iOS 26.0.1. We have uploaded apps in the past so I tried building one of them with our current toolchain. I use Xcode 16.4, Kotlin version 2.0.0, LibGDX 1.13.1 and robovm/MobiVM 2.3.23. I uploaded the build to TestFlight and tested with physical devices running iOS 18.5 and 26.0.1. It runs fine on 18.5 but refuses to launch on the 26.0.1 device. I cannot retrieve a crash log or .ips file because none is written. When I write a Console log while the app crashes/does not launch I get no hints as to why it does so. Do you maybe have additional ideas as to why it keeps not launching on iOS 26.0.1?

NSHostingSceneRepresentation, introduced in macOS 26, allows calling SwiftUI’s windows and other elements set in a Scene from AppKit. However, while Settings and WindowGroup set in the Scene can be invoked as expected using environment.openSettings() and environment.openWindow(id:) respectively, calling Window or WindowUtility doesn’t work. That is, the app just fails to open the desired window with the provided ID, and no error message or other feedback/crash/freeze appears. I expect that executing the openUtilityWindow(_:)action in the following code will display the UtilityWindow set in the scene. However, the window does not actually open. @main final class AppDelegate: NSObject, NSApplicationDelegate { private let scene = NSHostingSceneRepresentation { UtilityWindow(Utility Window, id: UtilityWindow) { Text(Utility Window) .scenePadding() } } func applicationWillFinishLaunching(_ notification: Notification) { NSApp.addSceneRepresentation(self.scene) } @IBAction func openUtilityWindow(_ sender: Any?) { se

I was stuck on a long train journey this weekend, so I thought I’d use that time to write up the process for installing a launchd daemon using SMAppService. This involves a number of deliberate steps and, while the overall process isn’t too hard — it’s certainly a lot better than with the older SMJobBless — it’s easy to accidentally stray from the path and get very confused. If you have questions or comments, start a new thread in the App & System Services > Processes & Concurrency subtopic and tag it with Service Management. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com Getting Started with SMAppService This post explains how to use SMAppService to install a launchd daemon. I tested these instructions using Xcode 26.0 on macOS 15.6.1. Things are likely to be slightly different with different Xcode and macOS versions. Create the container app target To start, I created a new project: I choose File > New > Project.

I am building a Vision OS app that includes a File Provider and File Provider UI extension. Both work great in simulator. When uploading to TestFlight, this message is shown: Unsupported Platform. The extension bundle [...]/PlugIns/File ProviderUI.appex is not supported for this platform. If I exclude the File Provider UI extension from the build, it is accepted. If I even include a hello-world File Provider UI extension, the error shown above is returned by ASC. There is contradicting documentation on this subject: https://developer.apple.com/documentation/technologyoverviews/app-extensions states that File Provider UI extension is not supported on Vision OS, so that explains ASC behavior https://developer.apple.com/documentation/FileProviderUI (and all other framework docs) states that File Provider UI extension is supported on Vision OS, so that explains why it works on simulator. Now, which of these two is correct? My best guess at this point

Hi, I have been using external NVMe disk since March 2025 with my Mac M1 1TB until recently couple of days agao I updated Mac OS to Tahoe from Sequpoia 15.6. Now Mac OS Tahoe is disconnecting my NVMe automatically saying please eject the disc before disconnecting and suddenly after an hour it reconnects. Right now I have reinstall Mac OS Sequoia and My external NVMe disk is working again. This post is for Mac OS developers to check for APFS drivers on Mac Tahoe as they are messing up with external NVMe SSD. I dont know about others brand of NVMe I am using Transcend inclosure with transcend NVMe 2TB SSD hard disk. Kindly please check as its not NVMe issue its and OS issue. If it was NVMe issue my SSD should also not work with Sequoia but as it is working with Sequoia so it has to be something with Tahoe OS. Kindly review your code about APFS drivers or thunderbold USB C drivers or may be something else linked to APFS file system. I hope this post reaches you and you guys can consider it as help ful.