Post

Replies

Boosts

Views

Activity

Reply to I am not using push notification service, i am only use local notification in my app how to solve this issue
We started getting this warning also when uploading to TestFlight with Xcode 16.3. The app does not use any 3rd party libraries and does not use Push Notifications (and does not implement the above API). Hint to Apple: When we last uploaded with Xcode 16.2, this warning did not occur. This warning started after upgrading to Xcode 16.3.
Apr ’25
Reply to Ultra wide API for WindowGroup?
It is awesome to see. 10240x2880 in a 180° around you. It would be great if our apps could use this also! I haven't seen an API for it yet, it would be great if one exists. In the meantime, I opened FB13945590 (since June actually) suggesting one.
Topic: Spatial Computing SubTopic: General Tags:
Nov ’24
Reply to Build setting variant for Designed for iPad
We also tried using: "EXCLUDED_ARCHS[sdk=iphonesimulator*][arch=arm64]" = "" but it still doesn't get used. The default setting gets used instead. This is making use what is already available to use for user-defined settings. For those, the Xcode UI lets you choose both an SDK and an architecture. But interestingly enough, after testing with a user-defined setting, we found that even then the build doesn't use the correct setting. To test this we added: TEST_SETTING = TEST; "TEST_SETTING[sdk=xrsimulator*]" = "visionOS Sim - Native visionOS app"; "TEST_SETTING[sdk=iphonesimulator*][arch=arm64]" = "visionOS Sim - Designed for iPad"; "TEST_SETTING[sdk=iphonesimulator*][arch=x86_64]" = "iOS Sim - Native iPad"; These can be added manually or via the UI and they do show as separate entries: We also added TestSetting = $(TEST_SETTING) in Info.plist. And log the value: NSLog(@"TEST_SETTING: %@", [[NSBundle mainBundle] objectForInfoDictionaryKey:@"TestSetting"]); Results: Running Apple Vision Pro (simulator): visionOS Sim - Native visionOS app ✅ Running Apple Vision Pro (Designed for iPad): TEST ❌ Running iPad simulator: TEST ❌ So it's clear that there's a bug here. For the destinations that are architecture specific, the default setting is used instead. Created FB13351268
Nov ’23
Reply to Dismiss Live Activities on App Termination
Assuming you're using something like this to end your live activities when the app is being terminated: class func stopLiveActivities() { print("Ending Live Activities") Task { for activity in Activity<TimeoutActivityAttributes>.activities { print("Ending Live Activity: \(activity.id)") await activity.end(nil, dismissalPolicy: .immediate) } } } This will not end the activities, the method returns and allows the app to terminate before the activities get a chance to actually end. Add a semaphore to force it to wait for the activities to end before returning from the method: class func stopSessionTimeoutAsync() { print("Ending Live Activities") let semaphore = DispatchSemaphore(value: 0) Task { for activity in Activity<TimeoutActivityAttributes>.activities { print("Ending Live Activity: \(activity.id)") await activity.end(nil, dismissalPolicy: .immediate) } semaphore.signal() } semaphore.wait() } This works for me (tested with a single activity). With the app in the background and live activity showing, I can force-kill the app and the live activity is removed.
Topic: App & System Services SubTopic: Core OS Tags:
Jul ’23