Post not yet marked as solved
Yeah I'm seeing the same thing on an iPad pro on 17.2 and Xcode 15.0.1 when logging into TestFlight, no idea what's causing it, it just won't let me use TestFlight.
I think this is a problem at Apples end with the account, I tried a different TestFlight account on the same device and it worked ok
Post marked as Apple Recommended
I was hitting this problem and found Xcode kept trying to connect to other devices that it had used previously, even though I wasn't current debugging with them.
eg, it would try and connect to my personal phone and watch over the wifi network even though I wasn't using them and I had the test device connected via usb. As a workaround i tried two things (not sure about the second one, but it all seems pretty good at the moment).
First thing I think helps the most was go into Window | Devices And Simulators and set the Run Destination for all devices to Never and then go back to just the devices u want to debug to Auto or Always - hopefully this will stop Xcode trying to connect simultaneously to anything it has ever used.
I've also got both ethernet and WIFI running (can't get air drop to work over ethernet, despite Apple saying iOS 17 it does work, and the ethernet interface is much faster generally). So I've changed the priority of the services in System | Network so that ethernet is above WIFI
These two changes seem to help a lot and for me it's back to what it used to be
Post not yet marked as solved
I think I know what problem is, for me it seems that instead of using the usb cable to debug the app on the device, XCode is using WIFI even though I'm selecting a device that is connected over USB
I turned off WIFI and just used ethernet to connect to the network. So Xcode was forced stopped using WIFI to talk to the device, but instead it used the USB cable
Then all the debugging went a lot faster
It seems that Apple have been making changes around Window -> Devices And Simulators. On Xcode 15.0.0 the 'Show run destination' could not be set to Never, but now it works ok.
I'm just guessing but it seems that Xcode is trying to connect over WIFI to all the devices and send all the debugging over WIFI even when usb is connected.
Turning off WIFI on the MBP and using ethernet worked round the issue and debugging to the device went a lot faster....hope this helps!
Post not yet marked as solved
32 gig of memory on an M1 Max MBP and it's awful debugging on Xcode 15, do Apple look at these forums or is it better to leave feedback at https://developer.apple.com/bug-reporting/
Post not yet marked as solved
I'm see these issues but also I'm see extra updates too on Xcode 13.4.1
I have created an environment object that i pass to child screens.
I'm seeing the .onAppear() being called on the parent screen when a child screen updates a field in the environment object
This is really starting to hold up development
Post not yet marked as solved
Did you get a resolution for this, we're hitting the same issue too
So we've had this twice now
The first time Apple fixed it at their end, not sure what they did and then it worked for a while, but then came back
The fix that worked for me today was around the new option to have the app also work on MacOS
In Xcode it was turned off, but in App Store Connect it was turned on.
Simply turning it off solved the problem (we're not using it anyway and I'm not sure how it got turned on, might be a default or me being curious)
But this was enough to cause the problem and the app is in for Review now
Hope this helps somebody
Trev
Post not yet marked as solved
So our project has a deployment Target of iOS11.0The solution that worked for me was to no longer use the description method, this is always dangerous as this could change (and obviously has). I've changed our code to that as shown in my second post and this works fine on both ios12 and ios13
Post not yet marked as solved
So it turns out that the description method on NSData now returns different results.Originally my code was as follows....-(void)pushRegistry:(PKPushRegistry *)regsitry didUpdatePushCredentials:(PKPushCredentials *)credentials forType:(NSString *)type { NSData* deviceToken = credentials.token; NSString* tkn = [NSString stringWithFormat:@"%@", deviceToken];This gave me a token of something like<124686a5 556a72ca d808f572 00c323b9 3eff9285 92445590 3225757d b83967be>which I could then remove the chevrons and spaces and use for the push notification.But now, the same code gives me the following string{length = 32, bytes = 0xd3d997af 967d1f43 b405374a 13394d2f ... 28f10282 14af515f }After spotting this I'm now using- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)devToken { const unsigned *tokenBytes = [deviceToken bytes]; NSString *tkn = [NSString stringWithFormat:@"%08x%08x%08x%08x%08x%08x%08x%08x", ntohl(tokenBytes[0]), ntohl(tokenBytes[1]), ntohl(tokenBytes[2]), ntohl(tokenBytes[3]), ntohl(tokenBytes[4]), ntohl(tokenBytes[5]), ntohl(tokenBytes[6]), ntohl(tokenBytes[7])];which gives me the correct string for the token for push notificationSo the format of the [... description] has changed under iOS13, didn't see that documented anyway!Before anybody mentions, yes, it was a school boy error to use the description methodHope this helps somebodyTrev
