Post not yet marked as solved
Here's what you will have to do:Put the iPad in DFU mode. Do a search for how to put an iPhone X or Xs or 11 into DFU mode. Same button pressings apply.Restore your ipad to the last good version of iPadOS (13.1.2). iTunes will do that automatically after it downloads it.Download the ipsw for iPadOS 13.2 beta 2 and install it via iTunes (if on below Catalina). The ipsw was not there earlier today but is there now.Alternatively you may try to do an OTA update, however earlier today the OTA update for iPadOS 13.2 beta 2 was not verifiable (got the "not connected to the internet" issue even though connectivity was not an issue) so this may not work. I suspect that the full update had issues so that is why it wasn't verifiable.I will be doing it via iTunes restoring using the 13.2 beta ipsw.
There must be issues with it because the the 13.2 beta 2 restore ipsw cannot be downloaded even on a Mac. Does anyone know if it was pulled, or if it was just not there? Or is that it's not explicitly identified as the ipsw for iPad 12.9" latest generation ?EDIT: I just saw that there is a ipsw for 12.9-in. iPad Pro (3rd generation). Not sure if I missed it the first time or if it was just added. Will attempt to update later today.
Post not yet marked as solved
Daniel, Duplicated the issue and confirmed it's a bug on how the picture or video is displayed by the camera app on 13.2 beta. If you go to photos you can look at the picture in any orientation just fine.Thanks,Neal
Hi Jeffree,This is clearly an issue with iOS 13.2 beta and not Xcode. Opening up the console and running my freshly downloaded app from the app store on an iOS 13.2 device, reveals the same issue: Many "kill() returned unexpected error 1" are generated every second if a WKWebView is being displayed.. What process it's trying to unsuccesfully kill is still a mistery. Once I move to another view, the unsuccesfull kill messages stop.Thanks,Neal
You're right. It has to do with WKWebViews. Perhaps after rendering a webpage, iOS tries to kill some process and it fails? It does try many times (over a 1000 times in less than 20 seconds, until the webview is replaced with another component)The same executable if run on iOS < 13.2 does not cause the error message at all.Thanks,Neal
Post not yet marked as solved
Hi Katman,before restoring from backup to your new iPhone 11 pro max you will have to upgrade it to iOS 13.1 beta. Only then will you be able to restore your XS Max 13.1 backup to the new iPhone 11 Pro.Neal
Post not yet marked as solved
I too have observed that if safari or an app with a wkwebview is split paned with an another app and the first app's width is compact, the displayed website will load the mobile version of the site. Ditto for bringing up Safari or a WKWebView app in a compact width popup. Resizing the safari or app w/WKWebView to a regular width causes the desktop version to be loaded.I think this is a feature, but am not 100% certain.Neal
Post not yet marked as solved
Hi Antrix1989,from what I've observed another way to load a mobile version of a given website on iPadOS is to ensure that the browser's width is compact. To achieve this you must use the multi-tasking feature and place safari in a popup or split paned with another app such that Safari now has compact width.Neal
Post not yet marked as solved
The script is a great idea, but the number of managed colors I have is not that many (for now anyway). I cannot believe that this issue has not yet been addressed. Glad to help!
Post not yet marked as solved
Yes you do have to wait until you have the Xcode 11 GM before you can build and deploy an app to the store. No beta builds allowed. You'll make it in time, as you will have the GM before the public gets iOS 13
Post not yet marked as solved
On a legacy iOS project. I have only 2 .xcassets files and [UIColor colorNamed:] always returns either nil or the wrong color on iOS 11. With images iOS 11 now always returns the dark image instead of the any. So perhaps what you say only applies to newly created projects.Regardless, we are down to the wire, not much time left to take care of this issue. Apple's silence on this is slightly worrisome. We can't afford to take the risk that it will not address this so we have a temporary solution.Since our app doesn't use story boards, (Minimal use of .xib files as well). we were able to get around this issue by creating a UIColor category with a new method called XXXcolorNamed:(NSString *)colorName (the *** is our app's prefix). Essentially what we are now doing is calling that method and if on iOS 12 or greater we route to UIColor colorNamed: but if less than iOS 12 then we have a simple NSDictionary where we keep just the Any color accessible with the colorName key. Ditto for images.Thanks,Neal
Post not yet marked as solved
>So if your beta device updated to 13.1, it cannot be debugged with xCode. Or can it be?It can be debugged that's the odd part.
Does anyone on this thread have any iOS 11.x devices that they've tried this on? Trying to determine if this is a simulator issue or a real issue.Thanks,Neal
>I heard that you used UIStackView. Can you put UIBarButtonItem in UIStackView?Hi Mario25,You can't put a UIBarButtonItem in a UIStackView, only UIViews or UIControls, but in my case that was fine, because all of our UIBarButtonItems used real UIButtons and UIControls as custom views. So after migrating to a UIStackview we saved work because we didn't have to create UIBarButtonItem wrappers. Your use case is different in that you still use UIBarButtonItems.
I have as well. I'm not using any Scenes. Is the old app delegate still appropriate for iOS 13 if you choose not use them? We have a 5 year old iOS app so it should work fine without using Scenes and yet we get the background task warningNeal
