Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

I am working on a Bluetooth Low Energy (BLE) project using the nRF52840 Development Kit (DK), which has been reconfigured to simulate an nRF52805 chip. The firmware is based on Nordic Semiconductor's ble_app_hids_keyboard example, with modifications to implement a BLE HID Gamepad. I am using the S113 SoftDevice and have successfully tested the functionality with Android devices. The gamepad is recognized as a HID device, and it works as expected on Android, verified using the hardwareTester website. However, when I connect the gamepad to an iPhone via BLE, the same hardwareTester website does not respond as it does on Android, indicating that the iPhone does not recognize the device as a gamepad. The BLE connection is established successfully, but it seems iOS does not interpret the HID report descriptor or the BLE HID service correctly. I suspect there might be compatibility issues with the HID descriptor or the GATT attributes for iOS-specific BLE HID requirements. I would like to have some help.

In all the illustrations of win-back offers, I see an example of "Get 3 months off, then $X/month", as seen below. First, I'm not exactly clear how each configuration translates into an actual offer in practice: If I want to offer 3 months off on an annual subscription, ie. only if the user pays for the annual offer (basically a 25% discount), is that possible? If I set a "Free" type, of 3 months, I guess that would allow the user to cancel before paying for the annual, correct? If I set a "Pay up front" type, with a 25% discount, how would that show up to the user on the App Store? Secondly, is eligibility to an offer determined by the user elapsing on the same subscription or any subscription in the same subscription group? Thank you

I have a bunch of images sized 540px on the long side (some portrait, some landscape). The other side could be any size, but will be less than 540. There are no square images. I want to be able to choose a folder containing the images, and want the script to do the following for each image: Place it at the center of the current page of the active indesign document. Scrape the filename from the image (without the extension), apply the pre-existing Paragraph Style 'Caption' to the text, and center the text 36 points (not pixels) below the image. Group the image and the text. Then create a frame with white fill, 540x600 pixels in size, send it to back, center it with the group created above, and group them. I've been pulling my hair out. Just can't get it to work.

I recently used Open core legacy patcher to update my old 2012 Macbook pro to run a new pice of dj software. the update went smooth but now the Dj software wont open just gives me a crash report. Im totally stumped. the crash report. Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [3839] Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 Engine DJ 0x10c9e3d81 0x10c28f000 + 7687553 1 dyld 0x7ff807632729 invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 241 2 dyld 0x7ff80766b34e invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 133 3 dyld 0x7ff80765fb73 invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 543 4 dyld 0x7ff80761a07b dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 249 5 dyld 0x7ff80765ebe8 dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 176 6 dyld 0x7ff807661266 dyld3::MachOFile::forEachInitializerPointerSection(Diagnostics&, void (unsigned int, unsigned int, bool&) block_pointer) const + 116 7 dyld 0x7ff80766b084 dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 390 8 dyld 0x7ff8076325c2 dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 150 9 dyld 0x7ff807638af7 dyld4::JustInTimeLoader::runInitializers(dyld4::RuntimeState&) const + 21 10 dyld 0x7ff807632928 dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&, dyld3::Array<dyld4::Loader const*>&) const + 276 11 dyld 0x7ff807636141 dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const::$_0::operator()() const + 147 12 dyld 0x7ff8076329bc dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const + 90 13 dyld 0x7ff80764e1f7 dyld4::APIs::runAllInitializersForMain() + 277 14 dyld 0x7ff80761f52e dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3433 15 dyld 0x7ff80761e792 dyld4::start(dyld4::KernelArgs*, void*, void*)::$_0::operator()() const + 572 16 dyld 0x7ff80761e27f start + 1727 Thread 1: 0 libsystem_pthread.dylib 0x7ff8079a8bcc start_wqthread + 0 Thread 2: 0 libsystem_pthread.dylib 0x7ff8079a8bcc start_wqthread + 0 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x00006000012acc80 rbx: 0x00006000032b3c90 rcx: 0x00006000012acd00 rdx: 0x000000011008e000 rdi: 0x0000000000000000 rsi: 0x00006000012ac000 rbp: 0x00007ff7b3c5a9f0 rsp: 0x00007ff7b3c5a9c0 r8: 0x0000000000000002 r9: 0x000000000000001b r10: 0x00000000001ff800 r11: 0x0000000000000080 r12: 0x000000010eeae278 r13: 0x000000010c28f6e8 r14: 0x00007ff84a461050 r15: 0x00007ff84a4614a0 rip: 0x000000010c9e3d81 rfl: 0x0000000000010207 cr2: 0x0000000000000000 Logical CPU: 2 Error Code: 0x00000000 Trap Number: 6

Hi All, I have created a Push Notification certificate from my Apple Developer account. After downloading the aps.cer file and adding it to my Keychain, the certificate was added successfully, but the private key is missing. Has anyone encountered a similar issue in the past? What could be causing this problem?

We have in-app purchases live and working fine for standard subscriptions. We also have promotional offers active for existing users (to give existing users a discount as a thank you). Yet, regardless of the user type (existing vs new... we have tested with all types), we get the "Your account is not eligible for this offer" error message when clicking the discounted offer. What is the logic for determining eligibility? I'm trying to debug as it's not clear to me why this message would show up. We are using React Native IAP. In general, how does the eligibility check work? What conditions are being evaluated and compared? And what could break those conditions? I appreciate your help! DDD

Dear Team, we are from Austria and want to test our apple pay on the web implementation via Apple Sandbox. As far as we can see Austria is not on the list that sandbox supports Apple Pay testing for. Can you please advise how can we move forward with testing? We have already created and also tried out our Sandbox account on iPhone 11 and successfully added test cards to the Wallet. Can we expect please in later stage some restrictions due to our region? Thank you in advance. Iveta

SIGPIPE is an ongoing source of grief on Apple systems [1]. I’ve talked about it numerous times here on the forums. It cropped up again today, so I decided to collect my experiences into one post. If you have questions or comments, please put them in a new thread. Put it in the App & System Services > Core OS topic area so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] Well, on Unix-y systems in general, but my focus is Apple systems (-: Debugging Broken Pipes On Unix-y systems, writing to a pipe whose read side is closed will raise a SIGPIPE signal. The default disposition of that signal is to terminate your process [1]. Broken pipe terminations are tricky to debug on Apple systems because the termination doesn’t generate a crash report. For example, consider this code: let (read, write) = try FileDescriptor.pipe() // This write works. try write.writeAll("Hello Cruel World!".utf8) let msg = try read.read(maxCount: 256) … do something with `msg` … // But if you close the read side… try read.close() // … the write call raises a `SIGPIPE`. try write.writeAll("Goodbye Cruel World!".utf8) Note This code relies on some extensions to FileDescriptor type that make it easier to call the pipe and write system calls. For more information about how I set that up, see Calling BSD Sockets from Swift. If you put this in an iOS app and run it outside of Xcode, the app will terminate without generating a crash report. This logic also applies to BSD Sockets. Writing to a disconnected socket may also trigger a SIGPIPE. This applies to the write system call and all the send variants: send, sendto, and sendmsg). IMPORTANT Broken pipe terminations are even more troubling with sockets because sockets are commonly used for networking, where you have no control over the remote peer. It’s easy to reproduce this signal with Unix domain sockets: let (read, write) = try FileDescriptor.socketPair(AF_UNIX, SOCK_STREAM, 0) // This write works. try write.writeAll("Hello Cruel World!".utf8) let msg = try read.read(maxCount: 256) … do something with `msg` … // But if you close the read side… try read.close() // … the write call raises a `SIGPIPE`. try write.writeAll("Goodbye Cruel World!".utf8) However, this isn’t limited to just Unix domain sockets; TCP sockets are a common source of broken pipe terminations. [1] At first blush this API design might seem bananas, but it kinda makes sense in the context of traditional Unix command-line tools. Confirm the Problem The primary symptom of a broken pipe problem is that your app terminates without generating a crash report. Unfortunately, that’s not definitive. There are other circumstances where your app can terminate without generating a crash report. For example, another common cause of such terminations is the app calling exit. There all two ways you can confirm this problem. The first relies on Xcode. Run your app in the Xcode debugger and, if it suddenly stops with the message Terminated due to signal 13, you know you’ve been terminated because of a broken pipe. IMPORTANT Double check that the signal number is 13, the value of SIGPIPE. If you can’t reproduce the problem in Xcode, look in the system log. When an app terminates the system records information about the reason. The exact log message varies from platform to platform, and from OS version to OS version. However, in the case of a SIGPIPE termination there’s usually a log entry containing PIPE or SIGPIPE, or that references signal 13. For example, on iOS 18.2.1, I see this log entry: type: default time: 11:59:00.321882+0000 process: SpringBoard subsystem: com.apple.runningboard category: process message: Firing exit handlers for 16876 with context <RBSProcessExitContext| specific, status:<RBSProcessExitStatus| domain:signal(2) code:SIGPIPE(13)>> The log message contains both SIGPIPE and the SIGPIPE signal number, 13. For more information about accessing the system log, see Your Friend the System Log. Locate the Problem Once you’ve confirmed that you have a broken pipe problem, you need to locate the source of it. That is, what code within your process is writing to a broken pipe? If you can reproduce the problem in Xcode, configure LLDB to stop on SIGPIPE signals: (lldb) process handle -s true SIGPIPE NAME PASS STOP NOTIFY =========== ===== ===== ====== SIGPIPE true true false When the process writes to a broken pipe, Xcode stops in the debugger. Look at the backtrace in the Debug navigator to find the offending write. If you can’t reproduce the problem in Xcode, one option is to add a signal handler that catches the SIGPIPE and triggers a crash. For example: #include <signal.h> static void sigpipeHandler(int sigNum) { __builtin_trap(); } extern void installSIGPIPEHandler(void) { signal(SIGPIPE, sigpipeHandler); } Here the signal handler, sigpipeHandler, forces a crash by calling the __builtin_trap function. IMPORTANT This code is in C, and uses __builtin_trap rather than abort, because of the very restricted environment in which the signal handler runs [1]. With this signal handler in place, writing to a broken pipe generates a crash report. Within that crash report, the crashing thread backtrace gives you a hint as to the location of the offending write. For example: 0 SIG-PIPETest … sigpipeHandler + 8 1 libsystem_platform.dylib … _sigtramp + 56 2 libswiftSystem.dylib … closure #1 in FileDescriptor._writeAll<A>(_:) + 100 3 libswiftSystem.dylib … partial apply for closure #1 in FileDescriptor._writeAll<A>(_:) + 20 4 libswiftSystem.dylib … partial apply for closure #1 in Sequence._withRawBufferPointer<A>(_:) + 108 5 libswiftCore.dylib … String.UTF8View.withContiguousStorageIfAvailable<A>(_:) + 108 6 libswiftCore.dylib … protocol witness for Sequence.withContiguousStorageIfAvailable<A>(_:) in conform… 7 libswiftCore.dylib … dispatch thunk of Sequence.withContiguousStorageIfAvailable<A>(_:) + 32 8 libswiftSystem.dylib … Sequence._withRawBufferPointer<A>(_:) + 472 9 libswiftSystem.dylib … FileDescriptor._writeAll<A>(_:) + 104 10 SIG-PIPETest … FileDescriptor.writeAll<A>(_:) + 28 … Note The write system call is not shown in the backtrace. That’s because the crash reporter is not backtracing correctly across the signal handler stack frame that was inserted by the kernel between frames 1 and 2 [1]. Fortunately that doesn’t matter here, because we primarily care about our code, which is visible in frame 10. I can’t see any problem with putting this code in your development build, or even deploying it to your beta testers. Think carefully before putting it in a production build that you deploy to all your users. Signal handlers are tricky [1]. [1] For all the gory details on that topic, see Implementing Your Own Crash Reporter for more information about that issue. [2] This is one of the gory details covered by Implementing Your Own Crash Reporter. Resolve the Problem The best way to resolve this problem depends on whether it’s being caused by a pipe or a socket. The socket case is easy: Use the SO_NOSIGPIPE socket option to disable SIGPIPE on the socket. Once you do that, writing to the socket when it’s disconnected will return an EPIPE error rather than raising the SIGPIPE signal. For example, you might tweak the code above like so: let (read, write) = try FileDescriptor.socketPair(AF_UNIX, SOCK_STREAM, 0) try read.setSocketOption(SOL_SOCKET, SO_NOSIGPIPE, 1 as CInt) try write.setSocketOption(SOL_SOCKET, SO_NOSIGPIPE, 1 as CInt) Note Again, this is using helpers from Calling BSD Sockets from Swift. The situation with pipes is tricky. Apple systems have no way to disable SIGPIPE on a pipe, leaving you with two less-than-ideal options: Disable SIGPIPE globally. To do this, call signal with SIG_IGN: signal(SIGPIPE, SIG_IGN) The downside to this approach is that affects the entire process. You can’t, for example, use this technique in library code. Switch to Unix domain sockets. Rather than use a pipe for your IPC, use Unix domain sockets instead. As they’re both file descriptors, it’s usually quite straightforward to make this change. The downside here is obvious: You need to modify your IPC code. That might be problematic, for example, if this IPC code is embedded in a framework that you don’t build from source.

When I open Iplaytv on my Apple TV it says refresh needed but I don’t know how

Hi (from France) I have a MacOS application which handles the App Store receipt by requesting at the url "https://buy.itunes.apple.com/verifyReceipt". From the response, I can know what are the inApps bought by the user and that suits for me. I don't know if if I must change something in my code accordingly to this TN3118. Does someone knows the response ? Best regards.

Hi All, I would like to develop a small macOS app using swift. I want to use ImageCaptureCore to access and control connected scanners ( via usb). I followed the official docs and wrote this ScannerManager. The code seems to be working without issues or warnings. I added the Hardened Runtime capability and both com.apple.security.personal-information.photos-library and com.apple.security.device.usb to the .entitlements file. As well added NSCameraUsageDescription to the Info.plist. Problem: None of my scanners do get detected (tested 2 different models). Of course, they are connected and do get recognized by the Image Capture App (and work as expected) and are listed in the systems app, too. When I connect my phone it does get detected by the func deviceBrowser(_ browser: ICDeviceBrowser, didAdd... delegate function. Thats why I believe my code is working but the app is lacking permissions to detect scanners somehow. Does anyone know something about this? I am using macOS 15.1.1 (24B91) on a M1 Pro. Many thanks in advance! class ScannerManager: NSObject, ICDeviceBrowserDelegate, ICDeviceDelegate { let deviceBrowser: ICDeviceBrowser private var currentDevice: ICDevice? private var scannerDeviceDelegate: ScannerDeviceDelegate? var isScanning = false var scanners: [ICDevice] = [] // MARK: - Initialization override init() { print("🚀 Initializing ScannerManager...") self.deviceBrowser = ICDeviceBrowser() super.init() self.deviceBrowser.delegate = self // Log the initial browsed device type mask self.deviceBrowser.browsedDeviceTypeMask = .scanner print("🔍 Starting device browser...") self.deviceBrowser.start() // Enhanced device logging if let devices = deviceBrowser.devices { print("\n📱 Connected devices overview:") print("Total devices found: \(devices.count)") if devices.isEmpty { print("⚠️ No devices currently connected") } else { devices.forEach { device in print("\n📌 Device Details:") print(" - Name: \(device.name ?? "unnamed")") print(" - Type: \(String(describing: device.type))") print(" - Transport Type: \(String(describing: device.transportType))") print(" - Status: \(device.hasOpenSession ? "In Use" : "Available")") print(" - Persistent ID: \(String(describing: device.persistentIDString))") print(" - Location: \(device.locationDescription ?? "Unknown")") print(" - Capabilities: \(String(describing: device.capabilities))") } } } else { print("⚠️ Unable to access device list") } } ...

Hi, I have a problem about "NSPOSIXErrorDomain Code=65 & iOS18 & Xcode 16". I used 'CocoaAsyncSocket', '~> 7.6.5'. It works fine on iOS 15.2， But it's worried on iOS 18.3. Before this, broadcasts can be obtained normally。 I had get socket Multicast Networking. Please help me .

All the cards seem to have expired in Dec 2024: https://developer.apple.com/apple-pay/sandbox-testing/ Are there updated cards? Some gateways only support Mastercard and Discover which all appear expired.

I recently tried Apple TV after using android tv for a long time. The main missing item is having a browser. I could not find one. i tried building Firefox for TVOS, it failed with WebKit not available. Is there a way to build WebKit and package it along with a browser package while building it?

on a span of 4 months we sent 2 for nfc entitlement requests and refused , no reason nothing . i mean all we want is the ability to use nfc on passes nothing else , no idea why this is so complex . with google you don’t even need a developer account and it’s for free , here we pay and we can’t even get the full functionality the passes offer , we got the hardware and the solution but we find out we need an nfc entitlement to allow passes to have nfc ? i mean our use case is very simple instead of having barcode on the passes we want them to be via nfc and we already got the nfc hardware but we find out we need nfc entitlement which we tried requesting but getting refused with no reason at all. at least tell u what is the problem what how to fix it not outright refuse without any reason at all. if anyone got any solution please provide.

Hello. I'm preparing transfer app now but don't understand identifier length. reporence : https://developer.apple.com/documentation/sign_in_with_apple/transferring_your_apps_and_users_to_another_team 1 : xxxxxx.15fbexc6b31e41e78b891803a56b1axx.0247 2: xxxxxx.26ae9x5347f1f4fcebb3ae1b91807b5xx number 1 is The team-scoped user identifier number 2 is transfer identifier but length is different so i scared is it okay?

I have a SwiftData model where I need to customize behavior based on the value of a property (connectorType). Here’s a simplified version of my model: @Model public final class ConnectorModel { public var connectorType: String ... func doSomethingDifferentForEveryConnectorType() { ... } } I’d like to implement doSomethingDifferentForEveryConnectorType in a way that allows the behavior to vary depending on connectorType, and I want to follow best practices for scalability and maintainability. I’ve come up with three potential solutions, each with pros and cons, and I’d love to hear your thoughts on which one makes the most sense or if there’s a better approach: **Option 1: Use switch Statements ** func doSomethingDifferentForEveryConnectorType() { switch connectorType { case "HTTP": // HTTP-specific logic case "WebSocket": // WebSocket-specific logic default: // Fallback logic } } Pros: Simple to implement and keeps the SwiftData model observable by SwiftUI without any additional wrapping. Cons: If more behaviors or methods are added, the code could become messy and harder to maintain. **Option 2: Use a Wrapper with Inheritance around swiftdata model ** @Observable class ParentConnector { var connectorModel: ConnectorModel init(connectorModel: ConnectorModel) { self.connectorModel = connectorModel } func doSomethingDifferentForEveryConnectorType() { fatalError("Not implemented") } } @Observable class HTTPConnector: ParentConnector { override func doSomethingDifferentForEveryConnectorType() { // HTTP-specific logic } } Pros: Logic for each connector type is cleanly organized in subclasses, making it easy to extend and maintain. Cons: Requires introducing additional observable classes, which could add unnecessary complexity. **Option 3: Use a @Transient class that customizes behavior ** protocol ConnectorProtocol { func doSomethingDifferentForEveryConnectorType(connectorModel: ConnectorModel) } class HTTPConnectorImplementation: ConnectorProtocol { func doSomethingDifferentForEveryConnectorType(connectorModel: ConnectorModel) { // HTTP-specific logic } } Then add this to the model: @Model public final class ConnectorModel { public var connectorType: String @Transient public var connectorImplementation: ConnectorProtocol? // Or alternatively from swiftui I could call myModel.connectorImplementation.doSomethingDifferentForEveryConnectorType() to avoid this wrapper func doSomethingDifferentForEveryConnectorType() { connectorImplementation?.doSomethingDifferentForEveryConnectorType(connectorModel: self) } } Pros: Decouples model logic from connector-specific behavior. Avoids creating additional observable classes and allows for easy extension. Cons: Requires explicitly passing the model to the protocol implementation, and setup for determining the correct implementation needs to be handled elsewhere. My Questions Which approach aligns best with SwiftData and SwiftUI best practices, especially for scalable and maintainable apps? Are there better alternatives that I haven’t considered? If Option 3 (protocol with dependency injection) is preferred, what’s the best way to a)manage the transient property 2) set the correct implementation and 3) pass reference to swiftdata model? Thanks in advance for your advice!

We are using PacketTunnel as system extension to establish vpn tunnel. The flow is like: Create a PacketTunnelProvide to establish vpn When tunnel gets connected add excludedRoutes by calling setTunnelNetworkSettings(). Result: The routing table is not getting updated with new excludeRoutes entries. As per setTunnelNetworkSettings() documentation: "This function is called by tunnel provider implementations to set the network settings of the tunnel, including IP routes, DNS servers, and virtual interface addresses depending on the tunnel type. Subclasses should not override this method. This method can be called multiple times during the lifetime of a particular tunnel. It is not necessary to call this function with nil to clear out the existing settings before calling this function with a non-nil configuration." So we believe setTunnelNetworkSettings() should be able to set new excludeRoutes. We could see we are passing correct entries to setTunnelNetworkSettings(): { tunnelRemoteAddress = 10.192.229.240 DNSSettings = { protocol = cleartext server = ( 10.192.230.211, 192.168.180.15, ) matchDomains = ( , ) matchDomainsNoSearch = NO } IPv4Settings = { configMethod = manual addresses = ( 100.100.100.17, ) subnetMasks = ( 255.255.255.255, ) includedRoutes = ( { destinationAddress = 1.1.1.1 destinationSubnetMask = 255.255.255.255 gatewayAddress = 100.100.100.17 }, { destinationAddress = 2.2.2.0 destinationSubnetMask = 255.255.255.255 gatewayAddress = 100.100.100.17 }, { destinationAddress = 11.11.11.0 destinationSubnetMask = 255.255.255.0 gatewayAddress = 100.100.100.17 }, ) excludedRoutes = ( { destinationAddress = 170.114.52.2 destinationSubnetMask = 255.255.255.255 }, ) overridePrimary = NO } MTU = 1298 } The problem is present on macOS Sequoia 15.2. Is it a known issue? Did anyone else faced this issue?

Has anyone had any success enabling Apple Pay checkout for a Google Chrome or Firefox users (macOS or PC)? This was rolled out in iOS 18 but Shopify support hasn't been able to help: https://www.theverge.com/2024/6/13/24177851/apple-ios-18-pay-chrome-scanning-code-wwdc-2024 Thanks

Currently, we use UIDocumentPickerViewController to read the user's connected sdcard. However, this requires the user to select manually, and the event cannot be monitored. But recently I found that ImageCaptureCore's ICDeviceBrowserDelegate can monitor the plug-in and unplug events in the didAddDevice callback, but cannot obtain the path of the storage card. I wonder if there is a way to combine the advantages of both, so that with the user's consent, the card reader events can be monitored and the content can be read directly without the user manually selecting the folder