calendar

In my program, I want to add a meeting schedule to the calendar. I use the following code: let event = EKEvent(eventStore: self.eventStore) event.title = title event.startDate = startDate event.endDate = endDate event.isAllDay = allDay event.notes = notes event.location = url? .absoluteString event.url = url event.calendar = self.eventStore.defaultCalendarForNewEvents event.alarms = alarms.map { EKAlarm(relativeOffset: $0) } let editVC = EKEventEditViewController() editVC.event = event editVC.eventStore = self.eventStore editVC.editViewDelegate = self viewController.present(editVC, animated: true, completion: nil) When opening the itinerary in the calendar, the join meeting button cannot appear. I couldn't find any method to set up meetings in EKEvent

So I had a similar problem. I had a calendar-like view where the latest data is at the bottom. By default, it had 12 items in a LazyVGrid (3 rows of 4 items). You could tap show more to expand the size of the view to 600 in height, and also make it scrollable with the top view triggering a fetch of the next page of results. The problem was, the act of resizing this view, and triggering the next page of results was causing the scroll view to jump to the top, rather than staying at the bottom. So essentially it would start loading all pages infinitely. .scrollPosition and the ScrollViewProxy do not seem to work, because at the time of hitting show more the bottom is already visible, so the act of changing the scroll position does nothing. The only workaround I found here was to add a delay long enough for the resize animation and for enough results to load to prevent another page load from triggering. Unfortunately, this was not at all reliable. The only fix I have found was to use .defaultScrollAnchor

Restoring third party access to push mails is critical to ensure iOS remains an open platform with basic work tools such as mail/calendar/contacts. Without push, emails are often received with hours of delay. At an age where we receive all sort of urgent informations via this media (OTP, signin alerts, notifications, etc), maintaining a way to push on IMAP is critical. Using third party clients is simply not an option for anyone who wants to benefit from the stock iOS mail app, which is much more polished and integrated with the OS. I wholeheartedly second this feature request, please can an APNS engineer explicit the roadmap here and explain why this was discontinued, given it no longer required to maintain OSX Server, and only the underlaying APNS infrastructure that’s common to all apps. We need an access to com.apple.mail APNS topic, as IMAP Idle is not an option on mobile devices.

Our app aims to provide a unique, comprehensive, and user-friendly experience for those interested in learning about Chinese metaphysics and Bazi (Four Pillars of Destiny). Below are the key features that make our app distinct: Flexible Bazi Chart Generation: Supports real-time switching between various time standards (True Solar Time, Beijing Time) and allows users to freely adjust the hour pillar. Unlimited Chart Generation: Users can generate unlimited Bazi charts starting from the year 5 AD, suitable for studying and researching more ancient Bazi cases. Four Pillar Date Lookup: Allows for easy and intuitive lookup of the corresponding Gregorian date, with a range from the year 5 AD to 2100 AD. Support for Unknown Birth Time: Helps users who cannot recall their birth time to generate Bazi charts. Customizable Interface Layouts: Users can choose between traditional classic layouts or modern minimalist styles to suit different preferences. AI Image Recognition for Chart Generation: Introduces AI image recogn

openAppWhenRun requires the customer to unlock the device, because the app is being brought to the foreground. A foreground launch of an app implies that it has full access to system resources and the normal environment that an app runs in if launched from their Home screen, including access to data protected by the system according to the device lock status. Think of the authentication policy more for intents that can run in the background without needing the full app in the foreground to achieve the task. For something like checking the weather quickly, that information is public so there isn't a need for someone to authenticate with the device first, but for something more private like checking what's on a calendar for the day, an app may only want to provide that information after ensuring the device is authenticated first. — Ed Ford,  DTS Engineer