I wouldn't be so sure about the app clip getting an update. If the user launched the app clip again, maybe it would get the latest. The language around it staying on your device for 30 days to me feels like it wouldn't auto update. I would create a feedback for this and ask for clarifying documentation in the App Clip Framework or App Store Connect. Out of curiosity, is the update just to get them new features, or is the old version of the app clip no longer compatible with the backend?

From the error message, it looks like a value of nil is not acceptable. Try adding a UTF8 string value and see if it works then.

Do you need to buy the devices? No. Do you need to provide the screenshots? Yes. I'd look into XCTest and create UI tests that replicate the workflow with the IOT device. If you've structured your views to accept data not hard-coded to the Bluetooth device via CoreBluetooth, you should easily be able to get the screens you need.

@sikandernoori the threshold is not documented, you could ask the performance team at WWDC24 but I doubt you'll get an exact answer. It changes from year to year as you noted--consider it an implementation detail. Regarding Xcode Organizer, depending on what data you're after, you might be better fit to collect MetricKit payloads, ship off device, and do your own analysis. You won't be subject to any aggregation limits, but you do have to manage the data and do some math or visualization by hand.

The list of accounts here is based on what developer programs your Apple ID is invited to and have accepted the invite. If the other developer account already exists, have the account holder or admin invite you to their program. You can't be account holder on more than one account for a given Apple ID last I checked.

This doesn't look right, are you customizing your recordName when creating objects? What are you using to generate your identifier? The recordName is typically in the form of a UUID if you leave things alone and let the system generate identifiers for you. Can you just do a full query of that PNote type in your development container, see your record, click on it, and copy paste that identifier exactly as is into the screenshots you've provided? I've reported issues with console UI for queries and such in the past and gotten a few fixes, perhaps there is something invalid about having a period in your recordName? That having been said however, I haven't come across any documentation describing limitations.

UserDefaults - yes. CloudKit - not today. Why is UserDefaults required to declare a required reason? Apple puts a lot of information in the app's UserDefaults on the systems behalf. The data they put there is not meant for you to be reading. Unfortunate but the current state of the matter. As a result, UserDefaults is one of those very easy APIs that can be use to digitally fingerprint a user and / or their device. Read up on the history of Required Reason API from last years WWDC. All of the required reason APIs are mitigations to prevent user tracking outside of the ATT framework.

I tried again around 8:30 AM Central today, on Sept 10th. The issue still persists. As a workaround I was able to upload a binary that I archived locally with Xcode 16 RC installed on my machine running Sonoma and so far I haven't gotten an automated App Review rejection on my submission so far. They were pretty instantaneous when submitting binaries from Xcode Cloud so I think I'm in the clear. So what is different between Xcode 16 RC in Xcode Cloud and Xcode 16 RC on a local device? Here are all of the DT keys from the app's Info.plist from a local build: <key>DTCompiler</key> <string>com.apple.compilers.llvm.clang.1_0</string> <key>DTPlatformBuild</key> <string>22A348</string> <key>DTPlatformName</key> <string>iphoneos</string> <key>DTPlatformVersion</key> <string>18.0</string> <key>DTSDKBuild</key> <string>22A348</string> <key>DTSDKName</key> <string>iphoneos18.0</string> <key>DTXcode</key> <string>1600</string> <key>DTXcodeBuild</key> <string>16A242</string> And the same from Xcode Cloud: <key>DTCompiler</key> <string>com.apple.compilers.llvm.clang.1_0</string> <key>DTPlatformBuild</key> <string>22A348</string> <key>DTPlatformName</key> <string>iphoneos</string> <key>DTPlatformVersion</key> <string>18.0</string> <key>DTSDKBuild</key> <string>22A348</string> <key>DTSDKName</key> <string>iphoneos18.0</string> <key>DTXcode</key> <string>1600</string> <key>DTXcodeBuild</key> <string>16A242</string> I can't find anything else different in the two resulting archives. The allure to Xcode Cloud is that you don't have to immediately install the latest beta, RC, or public release of Xcode because Apple will. Small price to pay if you want to be a day-zero adopter of iOS 18 I guess. It would be nice to have some more detail on the automated rejection why this is occurring for Xcode Cloud.

I am also experiencing issues with a document based app. My app can open and pull apart .ips crash files, or at least that is the new feature I wanted to launch next week. When I share an .ips file from the Settings app on iOS 17.6.1, it works just fine. When I do the same on either iOS 18 RC or iPadOS 18 RC, my app icon shows in the suggested list of apps to share to, but when I select my app it does nothing. Interestingly, I can still share the file to the Files app, and from there when I use the Files app's share sheet, I can successfully launch and trigger my app to grab the data. FB15131454 - Settings: PRODUCTION ISSUE - Sharing an ips file from device analytics does not open my app on iOS and iPadOS 18 RC, works on iOS 17.6.x Ass suggested by @Engineer for completeness, I modified the WritingApp code to support iOS 17 by conditionally compiling all of the views, changing the extension supported to ips and ran it on my iPhone running 17.6.1. While the app doesn't actually do anything with the file, it successfully launches my app from Settings > Analytics. Taking again, the same sample code with modifications, running it on 18 RC, it does not launch the sample application.

Late to the game but for what its worth: FB15133265 - Swift Data / Swift 6: Create mechanism for object identifier that is 'immutable' that satisfies 'expand accessors on variable declared with let'

When you attempt to start a workout from your iPhone on the paired Apple Watch, watchOS will invoke your WKApplicationDelegate. It is up to you with how to process the workout request. It likely wouldn't be appropriate to use HealthKit to trigger this and then not record a workout. You'd have to disclose in your App Store Description that you work with the Health app, you'd have to put that into your privacy policy, have app specific rules, etc. As for 'using HealthKit other than the purposes of HealthKit' See 2.5.1: https://developer.apple.com/app-store/review/guidelines/#software-requirements Apps should use APIs and frameworks for their intended purposes and indicate that integration in their app description. For example, the HomeKit framework should provide home automation services; and HealthKit should be used for health and fitness purposes and integrate with the Health app. If your app is a fitness recording app, absolutely use this. If not, don't. You could look at pushing a configuration via Watch Connectivity framework and WCSession, but that doesn't guarantee the companion watch will launch either. Another approach you might take is to use Core Bluetooth. Have the watch scan, have the iPhone advertise. Again you're playing games. Your best bet, make an Apple Feedback, make your argument for your use case, and ask them to make an API to launch the watch app outside of HealthKit.

@sgonser which application is the source of the workout? Some apps save segments for both kilometer and miles so that it is quick and easy to fetch later based on the users preference and locale. To your earlier comments and question, this might be why you are seeing segments overlap of segments. Namely the Apple Activity app on watchOS does this. I recorded a walk on a beach in Ireland earlier this year. You can see my pace wasn't very high...there were many interesting shells, rocks, and sealife. So from the image above, the first segment is the first 1 KM, the second is the first 1 MI, third is 2nd KM (remainder), and the fourth is the 2nd MI (remainder). The HKStatisticsQuery API is very powerful. Another approach you could take, given another workout apps segments, compute the sum distance of that segment interval. If it is near 1-mi, you know the segment is a mile, otherwise if it is near 1-km, you know it is kilometers. In terms of determining that last segment, look at the segment before which has an end date that matches or roughly matches the start date of the last segment. Don't do math that looks exactly for 1-KM or 1-MI because the odds of the sample data generating exactly a round number are slim at best.

@Kenn25 Which API are you referring to as the 'HealthKit tracker Id'?

@lemessurier I would follow the practices outlined in this video: Testing Tips & Tricks If your goal is to test your logic, this is the way to do it. If your goal is to exercise radio functionality and transmit and receive packets, you should use UI Tests and have your physical device in proximity to your CI machine. As you have likely found out, you cannot instantiate a CBPeripheral, nor can you instantiate CBService, CBCharacteristic, and CBDescriptor. If you're really motivated, you could explore using the mac's Bluetooth to emulate your device. You'd need to create a mechanism to control that 'Mac app' from your XCTest suite. FYI, Process isn't available on iOS, thus you can't run command line tools from an iOS XCTest suite to control your Mac app. Maybe you could get it to work with a local HTTP Server and drive it that way.

@Quappi did you make sure to enable HealthKit Background Delivery in your Signing & Capabilities tab? I don't remember off hand if you try to enable via code and don't have this setting enabled if you get errors or not. This would be the first thing that I would double check. You should also check the docs about background delivery, not all types deliver in the background immediately.