I am woking on an application which has a built in browser type of feature. The user can browse any url on that webview. We know that iOS mandates to add different privacy usage description for accessing different user sensitive informations such as NSCameraUsageDescription, NSMicrophoneUsageDescription etc. As I am not sure which website an user will browse & what user sensitive datas those websites will ask, how can I anticipate and add that usage description key/value in the plist? Is there any better way to handle this situation? Thanks in advance

I have been reading about DTO (Data transfer object ) since few days. I understood concept that drives it. The concept is to make the domain object decoupled from external APIs or storage objects, by having datasource model. Certainly this will ensure a good separation of concern and make the program somewhat secure from the future change in the data model. But is that the only reason for using it? I see it adds a lot of extra code for something which may happen in future. Has anyone ever used DTOs in there iOS project and have it benefited them? Thanks in advance

I'm developing an ACME server to issue identity certificates to macOS/iOS devices for MDM attestation, following RFC 8555. Per RFC, the client creates an order, performs authorization, verifies the challenge, and finalizes the order by submitting a CSR to the CA. In my setup, the CA sometimes takes longer to issue the certificate (around 50 seconds). According to RFC 8555, if certificate issuance isn’t complete after the /finalize call, the server should respond with an "order" object with a "processing" status. The client should then send a POST-as-GET request to the order resource (e.g., /order/<order_id>) to check the current state. If the CA still hasn’t issued the certificate, the server should return the order object with the same "processing" status and include a "Retry-After" header, indicating when the client should retry. The client is expected to poll the order resource at this specified interval with POST-as-GET requests. However, it seems the Apple ACME client ignores the "Retry-After" header and instead returns the error: "Profile failed - Order status is processing, not yet valid" immediately upon the first poll response with "processing." Apple ACME client deviating from the RFC documentation. Has anyone found a reliable solution to this issue? Ref -https://datatracker.ietf.org/doc/html/rfc8555#:~:text=A%20request%20to%20finalize%20an%20order%20will%20result%20in%20error,to%20the%20%22certificate%22%20field%20of%20the%20order.%20%20Download%20the%0A%20%20%20%20%20%20certificate. To work around this, I’m holding the /finalize call until the CA issues the certificate. This works when issuance is quick (under 20 seconds), but if it takes more than that , the client times out. Interestingly, the Apple ACME client’s timeout appears shorter than the usual 60-second URLSession default.

I'm developing an ACME server to issue identity certificates to macOS/iOS devices for MDM attestation, following RFC 8555. Per RFC, the client creates an order, performs authorization, verifies the challenge, and finalizes the order by submitting a CSR to the CA. In my setup, the CA sometimes takes longer to issue the certificate (around 50 seconds). According to RFC 8555, if certificate issuance isn’t complete after the /finalize call, the server should respond with an "order" object with a "processing" status. The client should then send a POST-as-GET request to the order resource (e.g., /order/<order_id>) to check the current state. If the CA still hasn’t issued the certificate, the server should return the order object with the same "processing" status and include a "Retry-After" header, indicating when the client should retry. The client is expected to poll the order resource at this specified interval with POST-as-GET requests. However, it seems the Apple ACME client ignores the "Retry-After" header and instead returns the error: "Profile failed - Order status is processing, not yet valid" immediately upon the first poll response with "processing." Apple ACME client deviating from the RFC documentation. Has anyone found a reliable solution to this issue? Or does Apple supports asynchronous order finalization? Ref -https://datatracker.ietf.org/doc/html/rfc8555#:~:text=A%20request%20to%20finalize%20an%20order%20will%20result%20in%20error,to%20the%20%22certificate%22%20field%20of%20the%20order.%20%20Download%20the%0A%20%20%20%20%20%20certificate. To work around this, I’m holding the /finalize call until the CA issues the certificate. This works when issuance is quick (under 20 seconds), but if it takes more than that , the client times out. Interestingly, the Apple ACME client’s timeout appears shorter than the usual 60-second URLSession default.